ARTICLE · 1166794
为什么AI总要等我说继续
“确认。”
“同意。”
“请继续。”
最近一段时间，这几个词成了我用 AI 开发时最常输入的内容。
三个项目同时推进，我得隔一会儿就过去看一眼。这个要我批准下一步，那个让我确认修复方案，另一个又停在某个环境问题上。
我甚至试过睡前提前排上几条“同意”。第二天起来，它们还是早已停下了。
我原本想让 AI 多干活，自己腾出手做别的事。结果，一天被切成了很多小块：刚把注意力放到另一件事上，又得回来处理一个确认。
最难受的还不是忙，而是有些内容我看完也没有新的判断，回复一句“同意”，它才能继续。
我到底是在管理项目，还是在给 AI 当启动按钮？
后来，我们没有继续加角色、改提示词，而是回头查了一件事：那些我以为早就安排好的目标，到底是写在文档里，还是已经变成了系统实际执行的设置？
一 我曾经见过它长时间自己干活
最初，我用一个会话推进开发。后来让几个会话分别负责开发、测试等工作，搭起了一条研发流水线，希望 AI 先把能查的问题查出来，别都留到我真机测试时才发现。
按我的使用感受，这套分工确实起过作用。我需要亲自发现的问题减少了，也见过 AI 在交代任务后，长时间连续推进。
正因为见过，我才相信它应该可以。
进入新版本后，项目有需求文档，有分工。我觉得只要和负责统筹的那个会话——也就是我说的“主控”——把变化商量清楚，它就会分解任务、安排工作、接着推进。
我一直在检查“目标有没有说清楚”，却很少追问：换了阶段或主控会话后，支撑它继续工作的那套机制，还在吗？
二 我甚至试过提前把同意发出去
后来，情况慢慢变了。
在我的体感里，很多时候 AI 干上几分钟、十几分钟，就会停下来。有的停顿很合理，比如需要账号登录，或者某项操作确实超出了授权范围。但也有些时候，我看不出自己到底需要决定什么。
于是，我开始改提示词：能自己处理的自己处理，不要每一步都问我；把诊断、修复和复测合并起来，不要刚查出原因就停。
我也反复检查研发流水线的分工和规则，希望它少一些交接，多一些实际推进。
甚至在睡前，我会给几个会话安排好任务，提前排上几条“批准”“同意”。
结果第二天起来一看，它们还是早早停下了。
提前发“同意”没有真正解决问题，也不能替代对后续具体操作的授权。但那时候，我确实已经被反复确认磨得有些着急了。
再后来，我尝试用手机远程操控电脑。心想，至少不用一直坐在桌前，躺下之后也能让工作继续。
新的麻烦又来了：通知一会儿响一下，影响睡觉；电脑锁屏会影响某些操作；有时电脑上弹出一个窗口，还得我回去点按钮。
我没有从协作里抽身，只是把盯电脑变成了盯手机。
这些事让我开始怀疑：是项目越来越复杂，AI 已经做不动了？是会话太长，它忘记目标了？还是我把研发流水线搭得太复杂，反而把它困住了？
这些问题值得查。但还有一件更基础的事，我一直没有检查。
三 这次我们查的不是代码
我们先拿企业知识库项目做试验，把范围内的诊断、修复和复测合成一个完整工作包，同时重新启用 Codex 的原生 Goal，也就是 /goal。
先解释一下：它不只是聊天里写一句“你的目标是……”，而是由工具保存、绑定到具体会话的持续任务目标。
一轮工作结束后，如果这个目标还处于激活状态、预算允许，也没有其他阻塞，Codex 可以继续核对进展、选择下一步，而不必每次都等我再发一条消息。
我记得，早期开发时就用过它。这不是发现了一个从来不知道的新功能，而是回头检查一个我以为一直还在起作用的功能。
企业知识库重新调整后，我的第一感觉是：它确实能连续做更多事情了。不过，这次也同时合并了授权范围，还不能分清各项调整分别起了多大作用。
于是，我又让 Codex 查另外两个项目：它们现在的原生 Goal 还在吗？
10 月 11 日上午，查到的结果很明确：小程序项目和数据智能体项目当时的主控会话，都没有原生 Goal 记录。
文档里有目标。聊天里也谈过目标。但支撑会话自动续跑的原生目标，核查时并不存在。
如果不实际查询，我还会以为它早就配置好了，继续去改那句“不用每次问我”。
这次我才把三件事分开：
需求和设计文档（Spec 等）：约定做什么、什么结果才算合格。 研发流水线：安排谁来开发、谁来检查、怎样交接。 原生 Goal：支撑这个会话在一轮结束后继续朝目标推进。
前两项齐备，不代表第三项已经生效。原生 Goal 绑定具体会话，换了主控，不能想当然地认为它也接上了。
现在还不能确定，两个项目的 Goal 究竟在哪一步没有接续。能确认的是，我此前没有核实这件事；授权和环境造成的停顿，也仍要分别处理。
我以为自己已经把目标交给了 AI，实际上却一直在亲手推动它的下一步。
四 批准了新任务也不等于Goal已经恢复
再回到先做试验的企业知识库项目，排查还发现了第二个容易漏掉的地方。
企业知识库当天早上 6:28 创建了原生 Goal，连续进行了诊断、修复和验证。约定的两轮验证做完、这批工作允许的 58 次本地模型调用用尽后，产品目标仍未达成。7:11，它被标记为 blocked，也就是受阻。
不是整个账号的额度用光了，而是这批工作事先约定的尝试上限到了。
这次停下是应该的。不能因为我希望它继续，就让它无限试下去。
随后，我批准了新的方案和工作包，AI 也接着干了。可到了上午 10:08 再查，旧 Goal 仍处于受阻状态，并没有自动变成新工作包的目标。
人以为已经翻篇了，原生目标却还停在上一页。
所以，不能只查“有没有 Goal”，还得查两件事：它是不是对应现在要做的工作？它现在是否处于激活状态？
聊天里的一句“批准”，可能让新一轮工作开始，却不等于原生 Goal 已经同步更新。
五 以后开工前我会先查这五件事
这次之后，我准备把检查放到每个版本、每个完整工作包的开头。
这里说的工作包，不是“先查一下原因”，也不是一句“把整个项目做完”，而是一段有明确结果、可以验收的工作。
比如，修好一个已知故障，补上能复现它的测试，完成复测，再把实际结果交回来。范围内这些步骤应该尽量连着做，而不是每一步都重新等我启动。
如果你也在反复点“继续”，不妨先检查下面五件事：
结果说清楚了吗？ 最后要交付什么，拿什么证明完成，而不只是列一串动作。 原生 Goal 真的存在吗？ 让 AI 查询实际状态，不要只看同名文档或它口头说“目标明确”。 它对应当前工作吗？ 旧目标可能已经结束或受阻，新任务不一定自动接续。 包内能自主做到哪里？ 诊断、修复、复测和结果回传要一起说明允许的范围；费用、数据、发布等边界仍须保留。 它为什么停下来？ 等密码、预算用尽、权限不足，和普通步骤做完后等待下一句指令，不是同一类问题。
如果使用的工具没有原生 Goal，也可以检查它是否提供类似的持续任务机制。名称未必一样，关键是别把“模型知道我要什么”当成“工具会自动继续做”。
这不是要求给每个小动作都建一个 Goal。相反，我希望少一些碎片任务，多一些范围清楚、能够完整交回结果的任务。
六 我还不能说问题已经解决了
10 月 11 日傍晚定稿前，我们又查了一次：三个主控都已有原生 Goal 记录，其中两个处于激活状态，一个仍然受阻。
设置补上了，不等于协作已经顺畅。目前的改善仍是初步使用感受，还没有可对比的统计结果，不能说三个项目都已恢复正常。
登录、系统弹窗和必要的产品取舍，也不会因为开启 Goal 就消失。
接下来，我想观察的不是 AI 一次能跑多久，而是：我少回复了多少次没有实质判断的“同意”，它独立交回了什么结果，以及剩下的停顿是否真的需要我。
毕竟，持续运行很久但没有交付，并不是我要的效果。
把这件事写出来，也不怕大家笑话。我确实在搭角色、改规则、优化提示词上花了不少精力，却漏查了一个重要的原生状态。
这次复盘让我记住了：流程搭好了，还要检查它是否真的按我们设想的方式运行。
我仍然希望 AI 能让我少守在电脑前。但现在，我会先确认目标、授权和续跑状态接上了，再去判断这套协作方式到底行不行。
你用 AI 开发时，最经常在哪一步被叫回来？是需要你作决定，还是只差你说一句“继续”？