别再让 Agent 猜：开始之前，先把“完成”写出来

很多 AI 项目不是做不动，而是停不下来。

你对 Agent 说：“把登录体验优化一下。”

它很快开始工作：改了按钮，补了错误提示，调整了会话逻辑，又顺手整理了几个相关模块。你看见大量文件变化，也看见测试通过，可真正打开产品时，那个最影响用户的问题也许仍然存在。

这时双方都很难判断下一步。

Agent 会继续寻找还能改进的地方。你会继续补充“再看看这里”“这个也顺便处理一下”。任务越做越大，完成却越来越远。

问题不一定出在执行能力。更常见的原因是：开始之前，没有人说清楚什么叫完成。

一个没有终点的任务，只能靠感觉停下

“优化一下”“做得更好”“把它完善”“检查有没有问题”，都可以表达方向，却不能判断结果。

方向告诉 Agent 往哪边走，完成标准告诉它走到哪里停。

没有完成标准，Agent 只能用自己的经验补题。它可能把“登录体验更好”理解成界面更漂亮，也可能理解成错误处理更完整、代码更整洁或会话更安全。这些都可能有价值，却未必是你此刻真正要解决的问题。

更麻烦的是，任务结束时你也没有共同的验收依据。

测试绿了，算完成吗？ 代码提交了，算完成吗？ 页面看起来更顺眼，算完成吗？ 用户终于能顺利登录，才算完成吗？

如果答案只能在最后临时决定，返工几乎已经写进任务里。

完成标准不是实现清单

很多人意识到要“说清楚”之后，会给 Agent 一张很长的技术清单：

  • 修改某个组件；
  • 新增一个状态；
  • 调整一个接口；
  • 补三条测试；
  • 重构一段重复逻辑。

这比一句“优化一下”具体，但它仍可能把实现步骤误当成结果。

用户并不关心登录页内部新增了几个状态。用户关心的是：输入正确凭据后能进入产品；输入错误时知道哪里不对；刷新页面后不必重新登录。

好的完成标准描述的是可观察结果，而不是提前替 Agent 写完实现方案。

它应该让你在任务结束时直接回答“是”或“否”，而不是再进行一轮解释。

写出三个可观察的完成条件

开始一个任务前，先问三个问题。

1. 用户最后能完成什么动作？

不要写“登录模块已优化”，写：

用户输入正确凭据后，可以进入工作台。

这句话把注意力放回真实动作。至于用哪种状态管理、改哪个函数，交给 Agent 在执行中处理。

2. 哪个关键边界必须成立？

主路径能走通还不够。你还需要写出最容易被忽略、但会改变结果的边界。

例如：

输入错误凭据时，页面给出明确提示，不清空用户已经填写的账号。

边界不是为了把所有异常一次写完，而是为了守住本轮最重要的用户体验和责任范围。

3. 用什么证据证明它真的完成？

不要只写“测试通过”。写清楚验证对象：

在真实浏览器中完成一次正确登录、一次错误登录和一次刷新恢复；三个结果都符合预期。

证据必须对准最终结果。用户实际使用的是生成后的页面，就验证生成后的页面；用户实际点击的是登录按钮，就验证真实点击链路。

同一个任务，改写前后差在哪里

模糊版本：

优化登录体验。

可执行版本：

目标：让已有账号顺利进入工作台。

完成条件一：正确凭据可以进入工作台。

完成条件二：错误凭据会显示可理解的提示，并保留已填写账号。

完成条件三：登录后刷新页面，仍保持登录状态。

验证：在真实浏览器中分别完成正确登录、错误登录和刷新恢复。

保留边界：不改变现有账号体系和登录入口。

第二个版本没有规定必须改哪个文件，也没有替 Agent 设计技术方案。它只是让目标、终点、证据和边界同时可见。

这会改变整个执行过程。

Agent 知道先检查哪条真实路径，知道什么改动与目标无关，也知道什么时候应该停止。你不需要在任务末尾重新发明验收标准，更不必靠文件数量判断工作是否充分。

完成标准也保护你不被“顺手优化”带走

Agent 很擅长发现相邻问题。它可能看到重复代码、旧依赖、不统一的命名和另一处可改进的交互。

发现问题没有错，但本轮是否处理，应该由当前目标决定。

完成标准像一道清晰的光圈：光圈内的问题必须闭环；光圈外的问题可以记录，却不能悄悄接管任务。

这并不是限制 Agent 的能力，而是让能力集中到一个真实结果上。

当本轮三个条件都成立，任务就可以结束。若出现新问题，再根据它对当前结果的影响决定是立即修复，还是进入下一环节。项目由此不再依赖“还有没有东西能改”，而依赖“承诺的结果是否已经成立”。

SoloMap 把完成标准放在执行之前

SoloMap 的路线图环节不只是一个任务标题。一个环节可以带着目标、完成标准、边界和历史交接进入 Agent 对话，让本轮执行从一开始就共享同一个终点。

Agent 仍然负责调查、实现和验证。你仍然负责决定什么结果值得完成。

两者之间不需要靠漫长聊天不断校准，而是先用可观察条件建立共同判断，再让执行开始。

现在花 15 分钟，重写你手上的一个任务

找出任务列表里最模糊的一项。它可能叫“优化首页”“完善支付”“处理性能问题”或“把这个功能做完”。

不要先启动 Agent。先写下：

  1. 用户最终能完成的一个动作；
  2. 必须守住的一个关键边界；
  3. 能证明结果成立的三个可观察条件；
  4. 你会亲自查看的验证证据。

然后删掉那些只是实现猜测、却没有改变用户结果的条目。

如果另一个人只看这几句话，就能判断任务什么时候完成、什么不能被顺手改变，你已经为 Agent 画出了终点。

先定义完成，不是减慢开始。它是在开始之前，避免整个项目朝错误的终点加速。