AI通宵编码卡在确认提示，开发者为何总被'y/n'困住一整夜

凌晨两点，屏幕微光映在空荡的书桌上，终端最后一行静止不动：Do you want to proceed? (y/n)。光标持续闪烁，风扇低鸣运转——AI仍在运行，却已停摆整整一夜。

这不是系统崩溃，没有报错日志，不消耗Token，也不产生任何可观测的异常信号。它只是安静地等待一个回车键，而操作者早已沉入梦乡。这种‘零成本卡死’现象，在使用Claude Code等AI编程工具执行长周期任务时频繁发生，成为开发者夜间自动化工作的隐形陷阱。

许多开发者误以为启用--permission-mode auto即可实现完全无人值守。事实上，该模式仅是一张“门禁卡”，而非“免死金牌”。它能自动放行常规操作，但面对四类典型交互场景时，仍会主动刹车并等待人工介入：

白名单之外的外部命令：如冷门系统工具或需特殊权限的CLI指令，AI因安全策略拒绝执行；

交互式安装流程：npm、pip或apt在依赖安装时突然弹出配置确认或协议同意提示；

敏感破坏性操作：例如批量删除未暂存文件、覆盖主干代码等高风险动作；

子程序自身输入请求：某脚本启动后自行输出“Press any key to continue”，此时提问主体已非AI本身，而是底层进程。

图中清晰划分了Auto Mode的实际能力边界：左侧为可自动通行的操作集合，右侧四堵“墙”构成真实世界的阻塞点。关键结论在于：确认提示是唯一一种“不花钱、不报错、却死守整夜”的停摆形式。

其一，物理层面无效——深夜静音环境下，一声微弱提示音无法唤醒熟睡者；

其二，语义层面混淆——任务完成、卡在确认框、程序死循环刷屏，三者均可能触发相同响铃，导致告警疲劳。用户最终对所有提示麻木，真正需要干预的时刻反而被忽略。

更深层的问题在于：日志滚动 ≠ 正在工作，屏幕静止 ≠ 已停止。编译过程可能耗时15分钟无输出，也可能陷入无限重试循环；而确认提示则表现为完全静默的等待状态。仅靠外层监控程序观察终端活动状态，无法识别文字内容本身的变化。

为解决这一痛点，开源工具Polter引入了“总管（Supervisor）”机制——一个驻留在终端内部、永不睡眠的自动化协作者。

总管并非接入更强模型，而是利用原生CLI环境，通过内存级终端读取接口（terminal_read）实时捕获其他会话窗口的纯文本输出。相比截图+OCR方案，该方法避免了颜色、高亮、边框等视觉干扰，确保对关键提示语（如y/n确认行）的精准识别。

其核心能力体现在三方面：

值得注意的是，该机制不替代开发者决策，而是将“必须人工确认”的环节转化为“可预设规则响应”的自动化步骤。例如，可配置“对所有非破坏性确认默认回复y”，或对特定路径下的删除操作强制拦截并通知。

除确认卡顿外，AI编程另一高频返工原因是上下文丢失。当任务跨度较长（如通宵重构），模型难以维持对早期设计文档、接口约定与测试策略的持续记忆。

对此，行业实践中逐渐形成一套可复制的工作流：三份文档 + 小步提交。

三份文档指：

图中对比揭示问题本质：传统会话式交互一旦中断，上下文即清零；而结构化文档使任务具备“可恢复性”。配合Git的小步提交策略（见下图），可进一步降低风险：

工作区→暂存区→已提交，每一步均可通过git restore --staged或git reset --hard回退。当AI生成结果偏离预期时，开发者能快速定位到最近一次有效提交点，而非从头开始。

此类问题暴露出当前AI编程工具在“长周期自主执行”能力上的结构性短板。尽管大模型在单步代码生成上表现优异，但面向工程化落地的任务连续性保障机制仍显薄弱。

值得留意的是，类似思路已在其他领域初现端倪：

然而，真正的突破可能不在于提升模型理解力，而在于重构人机协作范式：将AI定位为“可中断、可恢复、可审计”的协作者，而非试图模拟人类连续思维的黑盒执行器。

对于一线开发者而言，短期可行策略仍是组合使用：

对长任务启用结构化文档管理；

利用Polter等工具处理确认阻塞；

严格遵循小步提交与版本回溯规范。

通宵编码本应解放人力，而非制造新的守夜压力。当确认提示不再成为深夜的无声拷问, AI才真正迈入工程可用的门槛。