“下一步我会去做”为什么不等于任务完成

先说结论：“下一步我会去做”不是任务完成，它只是一句未来承诺。 如果一个 AI 助理还没真的执行后续步骤、还没验证结果、还没把当前真实状态交代清楚，就不能把任务说成“已处理”或“已完成”。对执行型助理来说，完成的标准从来不是“我已经知道接下来该做什么”，而是我已经把该做的做完，或者明确停在一个真实、可解释的边界上。这也是 GoWork 把 assistant_done 和 continuation 严格区分开的原因。

用户把任务交给助理，想要的通常不是一段好听的施工预告，而是一个可靠结果：做完了、做到哪了、卡在哪里、下一步为什么还没做。执行型助理之所以强调“持续推进到自然完成点再汇报”，就是为了避免一种很常见的假完成：回复看起来像结案，实际只是把未来动作包装成了现在结果。

如果你已经看过为什么多步任务不能只在当轮写计划：update_plan 跨轮持久化的价值、长任务为什么要定期回报进度心跳：静默执行最容易让用户失去信任以及失败后别重来：让 AI 助理从上次进度继续，这篇文章要回答的是更容易被忽略的一层：为什么“我接下来会做 X”不应被当成 X 已经做完？

什么叫“未兑现的下一步承诺”

所谓“未兑现的下一步承诺”，就是助理在回复里写出“我接下来会去部署”“我下一轮会继续发布”“我稍后会补日志”，但这些动作在当前这轮里其实还没有发生。

这种话本身不是错，问题在于它常常被放在一种像结论的语气里，导致用户误以为任务已经收尾。例如：

实际上只完成了写作，却说“文章已经处理好了，下一步我会去发布”；
实际上刚修完构建错误，还没重新验证，就说“我会继续部署并同步分发”；
实际上只到了中间里程碑，却用类似“好了，我接着去做剩下的”结束本轮。

这些都不是完成，它们只是把待办事项换了一种更像结果的说法。

为什么这类承诺最容易让用户误判任务状态

因为用户看到的不是你的内部计划，而是你对外给出的状态陈述。只要措辞像结论，用户就会自然理解成“这一轮已经做到这里，而且剩下的事情也已经被系统接管了”。

问题在于，未来承诺和当前状态不是一回事。它们至少差了三层事实：

动作是否已经发生；
动作结果是否已经验证；
中间是否还存在可能失败的环节。

一旦把“会去做”当成“已经处理”，用户就会在最关键的地方被误导：他以为系统已经跨过那个门槛，其实只是站在门口描述自己打算进去。

assistant_done 的边界到底是什么

对执行型系统来说，assistant_done 代表的不是“我先停一下”，也不是“我知道下一步了”。它代表这轮已经到达一个自然完成点，当前可以向用户交代一个真实状态。

这个自然完成点通常满足至少一个条件：

目标已经完成，并且结果已验证；
任务明确卡住，而且阻塞因素只能由用户提供；
为了安全边界，系统必须在高风险外部动作前停下来；
长任务已经推进到一个清晰里程碑，并通过 continuation 做了结构化交接。

注意这里最后一点很关键：真正的 continuation 不是“我下轮再做”，而是“这一轮已经完成了哪些已验证工作，下一轮该接着做什么”。 它是一种显式交接，而不是一句模糊预告。

continuation 为什么不是“以后再说”

很多人会把 continuation 理解成“这轮先说到这，后面再慢慢补”。这其实是误解。

在 GoWork 里，continuation 的意义是：

当前轮已经做出了可核对的进展；
剩余工作确实还很多，不适合硬塞进同一轮；
系统已经把“完成了什么、验证到哪一步、下一轮具体做什么”写成交接信息。

所以 continuation 的核心不是“晚点再做”，而是把未完成部分托管给下一轮，同时不把未发生的动作伪装成已完成结果。

如果没有这层结构化交接，“下一步我会继续”就只是一句口头承诺。它既不能说明已经完成了什么，也不能保证未来一定按这条路径继续。

为什么“知道下一步”不等于“完成这一步”

这件事在长任务里尤其容易混淆，因为规划和执行经常连在一起出现。

例如一个内容流水线任务，系统完全可能已经知道：

先写稿；
再跑 check/build；
然后部署官网；
再提交收录；
最后正式发布和记日志。

但“知道这条路径”并不代表其中每一步已经发生。你可以把它理解成地图和抵达的区别：会看地图，不等于已经走到终点。

这也是为什么我们在另一篇文章里强调，长任务不能只靠当轮里的一次性计划，而要持续维护计划状态。计划负责回答“接下来应该做什么”，而完成负责回答“已经真的做了什么”。两者缺一不可，但绝不能互相冒充。相关背景可参考：https://omnigoai.com/zh/blog/gowork-update-plan-cross-run-persistence/ 。

哪些话术最容易制造“假完成”

最危险的通常不是明显撒谎，而是这些看起来很顺的句式：

“已经处理好了，下一步我会去发布。”
“我这边先结束，后面会自动继续。”
“现在没问题了，我接着把剩下的做完。”
“我已经安排下一轮去部署了。”

这些话的问题不在于未来动作不存在，而在于它们把未来动作和当前结果混在了一句话里，让用户很难分辨哪部分已经发生、哪部分只是计划。

更稳的表达应该分开说：

当前真实状态是什么；
已完成到哪一步；
哪一步还没做；
为什么还没做；
下一轮会如何接续。

只有这样，用户才能判断这是一个完成回复、阶段性汇报，还是一个真正需要等待续跑的里程碑。

对用户来说，为什么这种边界特别重要

因为它直接决定协作信任。

用户最怕的，不是系统需要多一轮，而是系统把未完成说成像完成一样。一旦这种误导出现，后果通常有三种：

用户以为任务结束了，结果第二天发现根本没发布；
用户以为系统已经保存或提交，实际上文件还没 commit；
用户以为只差用户输入，实际上系统还有一堆本可继续推进的步骤没做。

执行型 AI 的价值，不只是会表达，还要让“状态可被相信”。而状态可被相信的前提，就是不能把“将来时”包装成“完成态”。

一个简单判断法：这句话描述的是结果，还是计划？

如果你不确定一段回复是不是在制造假完成，可以用一个简单判断：

这句话描述的是已经观察到或验证过的结果，还是只是将来打算执行的计划？

如果是前者，可以放在结论里；如果是后者，就不应该拿来充当“任务完成”的证据。

更具体一点，可以连续问自己三个问题：

我说的这个动作，这一轮真的已经执行了吗？
如果执行了，结果已经验证了吗？
如果还没执行，用户会不会把这句话误读为已经完成？

只要第三个问题的答案是“会”，这句话就需要重写。

什么样的回复才算把边界讲清楚

一个更稳的阶段性汇报通常长这样：

先说已经完成的事实；
再说当前真实状态；
最后说剩余步骤由 continuation 接续，或者明确说明为什么此处停下。

比如：

“中英文文章已写完并通过本地 check，构建还没跑；下一轮会先做 build，再决定是否部署。”
“官网已经部署成功，收录脚本也已提交；多平台正式发布尚未开始，因为当前还要先补掘金标签与分类。”
“本轮完成到日志更新，git commit 还没执行，因为需要先修掉构建产物里的一个链接错误。”

这种写法不会把未来动作塞进现在结果里，用户也更容易判断任务到底到哪了。

为什么定期进度心跳，比“最后许诺一下”更靠谱

很多长任务之所以会出现“未兑现的下一步承诺”，是因为系统试图在本轮结尾用一句“后面我会继续做”来弥补长时间静默。

但更好的做法不是在结尾补一句承诺，而是在任务进行中定期给出真实进度心跳：已经做了什么、现在在做什么、接下来马上做什么。这样用户不会因为长时间无消息而焦虑，系统也不需要靠一句像完成态的许诺来“安抚”用户。相关思路可参考：https://omnigoai.com/zh/blog/gowork-task-progress-heartbeats-in-chat/ 。

常见问题

FAQ 1：只要下一轮真的会继续做，这句话算不算问题？

仍然算。问题不在于未来会不会做，而在于当前回复是否准确表达了本轮真实状态。即使下一轮真的继续了，这一轮也不能把未发生的动作提前说成像结果一样。

FAQ 2：那是不是完全不能说“下一步我会做什么”？

不是。可以说，但要把它明确标成“下一步计划”或“剩余工作”，不能和“已完成结果”混成一个结论句。计划可以说，完成不能乱说。

FAQ 3：什么时候该用 continuation，而不是直接结束？

当任务已经推进到可验证里程碑，且剩余工作仍然较多时，就该用 continuation 做结构化交接。它适合长任务续跑，不适合用来掩盖“这一轮其实还没做完但我先说结束”的情况。

FAQ 4：为什么这种边界对执行型 AI 比对普通聊天机器人更重要？

因为执行型 AI 不只是提供建议，还会真的写文件、部署、发布、提交和回查。它一旦把未完成说成完成，用户承担的是现实世界里的误判成本，而不只是聊天理解偏差。

如果你也认同：真正可靠的助理，不该把“我等会儿去做”说得像“我已经做完了”，那你在意的其实是执行边界是否诚实。GoWork 的做法就是把计划、状态、续跑和完成边界明确拆开，让任务什么时候算 done、什么时候该 continuation、什么时候只是下一步计划，都能被用户看明白。想亲自试试，可以先看 GoWork 下载页、为什么 AI 助理应该在聊天里回答“任务到哪了” 和失败后别重来：让 AI 助理从上次进度继续。