AI 编码缺的不是计划，而是验收

在开始做 OpenNori 之前，我已经反复遇到同一个问题，并逐渐形成了一个判断：

AI 编码缺的不是更长的计划，而是一个让人能判断“这件事到底算不算完成”的验收层。

很多 agent 已经很会写代码了。它能读文件、改实现、跑测试、修报错，甚至能自己拆任务、自己推进很久。

但越是这样，一个更基础的问题就越明显：

它完成的，到底是不是你想要的完成？

Agent 最危险的能力，是太容易继续

人给 agent 一个目标：

帮我把设置页做完整。

它通常不会停下来问“完整是什么意思”。它会根据当前上下文补全一个合理版本，然后开始执行。

这个过程很流畅，也很危险。

因为“设置页做完整”在不同人眼里可能完全不是一件事：

• 是只展示已有字段，还是可以编辑？
• 保存成功后要不要有反馈？
• 保存失败怎么恢复？
• 刷新页面后怎么证明数据真的保存了？
• 权限不足时页面应该怎么表现？
• 手机号、头像、密码这些高风险字段算不算在内？

如果这些问题没有被确认，agent 依然可以写出一个看起来不错的页面。

只是它完成的是它脑子里的版本，不一定是用户能接受的版本。

以前 AI 不够强时，这个问题没那么刺眼。因为它跑不远，人很快会接管。

现在 agent 能跑得越来越远，问题反而变严重了：它可以在一个错误的完成定义上，非常努力地跑很久。

计划解决不了验收问题

很多人会说，那就先让 agent 写计划。

计划当然有用。但计划解决的是“准备怎么做”，不是“什么叫做完”。

一个计划可能写得很完整：

1. 新增表单字段
2. 接入保存接口
3. 增加 loading 状态
4. 添加错误提示
5. 运行测试

这仍然没有回答几个关键问题：

• 用户从哪里进入这个页面？
• 哪些字段可编辑，哪些字段只读？
• 保存成功后用户看到什么？
• 保存失败后用户还能不能恢复？
• 什么证据能证明这件事完成了？
• 哪些判断必须由人来做，不能由 agent 自己宣布？

计划是执行前的路线图。

验收标准是完成后的判断依据。

AI 编码真正容易缺失的，恰恰是后者。

我想要的不是任务列表，而是验收契约

这个判断后来长成了 OpenNori。它的核心想法很简单：

把一个自然语言目标，变成一份人能审阅、agent 能执行、结果能复查的验收契约。

这里的“契约”不是法律意义上的东西，也不是繁琐流程。它只是要求在动手前，把完成判断说清楚。

一个好的验收标准，不应该写成：

设置页 CRUD 可用。

这句话太空了。

它应该更接近：

用户从个人中心进入设置页，修改昵称并点击保存后，可以看到明确的成功反馈；刷新页面后，新昵称仍然显示；如果保存接口失败，页面保留用户输入并展示可理解的错误提示。

这才是人能判断的东西。

它包含了入口、动作、可见结果、持久化、失败边界和证据方向。

我在工具内部会把这种验收标准简称为 AC，也就是 Acceptance Criteria。但对大多数读者来说，直接叫“验收标准”更好。缩写不是重点，重点是把“做完”的含义从 agent 的自我理解里拿出来，放到人可以审阅的地方。

每次只推进一个缺口

只有验收标准还不够。

另一个关键思想是：不要让 agent 一口气把所有事情跑到底。

更稳的方式是让它每次只推进一个当前缺口：

读取当前状态
找到当前缺口
推进一轮
提交证据
遇到人类决策就停下

这也是后来进入 OpenNori 的 Loop Engineer 思想。

它不是让 agent 变成一个永不停机的自动化机器。恰恰相反，它要求 agent 知道什么时候该停。

好的 agent 不应该每次都问人下一步做什么。那样人还是在遥控。

但它也不应该遇到所有问题都自己替人决定。那样人会失去完成定义和风险判断权。

我想要的节奏是中间态：

• 能自动推进的执行问题，agent 自己推进。
• 需要证据的地方，agent 自己收集。
• 涉及验收标准、架构偏离、风险豁免、最终接受的地方，agent 必须停下来。

所以好的 AI 编码系统，不是让 agent 永不停机，而是让它知道什么时候该停下来等人判断。

证据和决策必须分开

AI 编码里还有一个常见混乱：把证据和决策混在一起。

测试通过，是证据。

页面截图，是证据。

接口返回 200，是证据。

Git diff 很小，是证据。

但这些都不等于“用户接受了”。

证据只能说明某个判断有依据，不能替用户做判断。

比如一个页面通过了所有测试，但布局很挤，文案很难懂，移动端按钮遮住了内容。agent 可以提供截图、浏览器记录、UI observation log，但最终“这个体验是否可以接受”，仍然是人的判断。

再比如一个功能客观上完成了，但偏离了项目原本的技术约束。agent 可以说明偏离原因、影响范围和替代方案，但不能自己批准这个风险。

这个思想要守住的边界就是：

Agent 负责推进和提交证据。
人负责定义完成和接受结果。

这个边界一旦模糊，agent 就会很容易把“我已经做了很多”包装成“这件事已经完成”。

完成报告不是总结，而是判断界面

很多 agent 的最终回复像工作日志：

我修改了 A、B、C 文件。
我新增了 X 逻辑。
我运行了测试，全部通过。

这些信息有价值，但还不够。

人真正需要的是一个完成判断：

• 当前目标是什么？
• 当前缺口解决了吗？
• 哪些验收标准已经通过？
• 哪些证据可以复查？
• 是否还有风险？
• 是否需要用户做决定？
• 下一步是继续、接受、豁免，还是回退？

所以完成报告不应该只是“我做了什么”的总结。

它更应该像一个判断界面：把证据、风险和需要人的决策摆清楚，让用户可以决定是否接受。

这也是我为什么不想把 OpenNori 做成一个流程归档工具。

流程归档关心发生过什么。

验收报告关心现在能不能接受。

两者很不一样。

OpenNori 不想替代人

我不希望 OpenNori 变成一个更重的项目管理系统，也不希望它变成 agent runtime。

它不负责让 agent 接管一切。

它只补一层很薄但很关键的东西：

目标 -> 验收标准 -> 当前缺口 -> 证据 -> 完成判断

人仍然用自然语言说目标。

Agent 仍然负责编码、验证、修复、整理报告。

OpenNori 只是把这个问题持续摆到中间：

这件事，用户到底凭什么判断完成？

如果这个问题没有答案，就不该急着实现。

如果证据不够，就不该宣布完成。

如果需要人做判断，agent 就不该替人判断。

人的位置会更靠前

AI 越能执行，人越不应该被拖进每一个细节。

但这不代表人要退出。

人的位置会更靠前：定义目标、划定边界、确认验收标准、判断风险、接受结果。

Agent 的位置会更靠后：读取上下文、推进当前缺口、运行验证、提交证据、整理报告。

这不是把工作全部交给 AI。

这是把执行交给 AI，把判断留在人手里。

我开始做 OpenNori，想解决的就是这个界面问题。

不是让 AI 编码更热闹，而是让 AI 编码更可接受。

如果只记一句话，我希望是：

AI 编码真正需要补上的，不是更长的计划，而是人能判断完成的验收契约。