Day 010|当 AI 能自己干活,真正稀缺的是“验收标准”

昨天写 Day 009 时，我留下了一个判断：

Prompt 优化的是一次交互，顶级 Builder 优化的是 AI 完成任务的整个运行环境。

Context、Rules、Skills、Hooks、Tests、Subagents……

当这些东西逐渐搭起来以后，会出现一个很有意思的变化：

AI 开始真的可以自己干活了。

不是你说一句，它写一段。

而是你给它一个任务，它自己读代码、找文件、修改、运行命令、看到报错、继续修，再重新测试。

人可以慢慢退出执行循环。

但人退出以后，一个新的问题马上冒出来：

AI 到底什么时候应该停？

假设今天我要做一个注册页面。

最简单的任务描述可能是：

做一个用户注册页面。

这句话对人来说似乎已经够清楚了。

但如果把它交给一个可以连续工作半小时甚至几个小时的 Agent，问题就来了。

什么叫「做完」？

有邮箱和密码输入框算做完吗？

注册接口能调用算做完吗？

错误提示算不算？

移动端要不要适配？

重复邮箱怎么办？

密码规则是什么？

Loading 状态有没有？

接口失败以后怎么恢复？

页面长得和设计稿差多少可以接受？

TypeScript 有没有报错？

测试要不要通过？

这些问题以前其实一直存在。

只是过去写代码的人和验收的人往往是同一个人。

程序员做到某一步，看一眼页面，心里自然知道：

差不多了。

很多判断没有被写下来。

它们藏在人脑里。

AI Agent 出现以后，这部分隐性的东西突然暴露出来了。

因为 AI 不知道什么叫「差不多」。

这也是我现在觉得很有意思的一件事。

我们一直以为 AI Coding 最大的瓶颈，是 AI 会不会写代码。

但模型越来越强以后，另一个瓶颈开始浮出来：

人能不能准确描述什么叫“正确”。

这和写需求还不完全一样。

需求描述的是：

我要什么。

验收标准描述的是：

我凭什么知道你已经做对了。

这两个东西看起来很接近，实际上完全不同。

「做一个搜索功能」是需求。

「输入关键词后 300ms 内出现结果；空结果有提示；网络失败允许重试；搜索条件刷新页面后保留；现有测试全部通过」才逐渐接近可执行的验收条件。

前者告诉 AI 往哪走。

后者告诉 AI：

什么时候可以停。

这也是为什么 Tests、Evals、Lint、Type Check、Build、Screenshot Diff 这些东西，在 Agent 工作流里的位置会越来越重要。

以前我们把测试理解成代码质量工具。

现在它还有另一层作用：

测试正在变成 AI 的反馈系统。

没有测试时，Agent 写完代码以后，只能问自己：

「看起来对不对？」

于是它生成一版，觉得差不多，然后告诉你任务完成。

最后还是人打开页面。

点一遍。

发现按钮没反应。

再把错误告诉 AI。

AI 修改。

人再检查。

看起来用了 Agent，其实人依然没有离开循环。

只是从写代码的人，变成了一个不停点「再改一下」的 QA。

但如果验收条件可以被机器读取，循环会完全变掉。

目标→ AI 实现→ Test 失败→ AI 读取结果→ 修改→ 再 Test→ Pass

人不需要参与每一次失败。

这时候 Agent 才开始拥有真正意义上的自主性。

不是因为它更聪明了。

而是因为它终于知道：

错在哪里。

软件工程里有一个挺有意思的概念，叫 Oracle Problem。

这里的 Oracle 不是数据库公司，而是「判定答案是否正确的机制」。

很多问题最难的部分，并不是生成一个答案。

而是判断这个答案到底对不对。

AI 把这个问题放大了很多倍。

因为生成能力正在快速变便宜。

今天让 Agent 给我写五个实现方案，并不困难。

真正麻烦的是：

哪一个方案可以上线？

哪一个破坏了已有逻辑？

哪一个只是 Demo 能跑？

哪一个在数据量上来以后会炸？

哪一个虽然测试通过，但用户体验很差？

生成速度越快，验收能力的重要性反而越高。

因为以前一个工程师一天写 300 行代码，你还能认真 Review。

未来几个 Agent 并行跑，一下午给你提交几千行 Diff。

如果质量判断还停留在「我打开看看」，人很快会成为整个系统里最慢的节点。

所以我现在越来越觉得：

AI 把 Coding 自动化以后，Builder 的工作不会消失，而是会向上移动到 Specification 和 Evaluation。

这里还有一个容易混淆的地方。

验收标准不等于「多写测试」。

有些东西很好验证。

比如：

接口返回 200。

单元测试通过。

Build 成功。

没有 Type Error。

这些属于机器特别擅长判断的东西。

但另一些标准没有那么容易写成 assert()。

比如：

这个页面是不是让人一眼看懂？

这个交互是不是太绕？

这个文案有没有让用户困惑？

这个产品方案是不是解决了最重要的问题？

这个功能值不值得做？

这时候人依然非常重要。

只不过人的角色变了。

以前人负责生产答案。

以后很多时候，人负责定义评价答案的尺度。

我甚至觉得，这会成为 AI Builder 很核心的一项能力：

把模糊的“我觉得这样比较好”，逐渐翻译成 AI 可以检查的信号。

有些信号是 Test。

有些是 Eval。

有些是设计稿 Diff。

有些是性能阈值。

有些是用户行为。

还有一些实在无法自动化，就明确标记：

这里必须由人判断。

不是所有判断都应该交给 AI。

但至少我们要知道，判断发生在哪里。

从这个角度再回头看 Prompt，会发现一个很微妙的变化。

很多人现在还在努力把 Prompt 写得越来越详细：

「你一定要认真。」

「请充分思考。」

「写完后检查三遍。」

「确保代码健壮、优雅、可维护。」

这些要求读起来很正确。

但它们最大的问题是：

没有反馈信号。

什么叫健壮？

什么叫优雅？

什么叫充分思考？

AI 很难从这些词里知道自己到底差了多少。

相比之下：

npm test 必须全部通过。

Lighthouse Performance ≥ 90。

接口 P95 < 300ms。

视觉 Diff 超过阈值就继续修改。

禁止新增 TypeScript Error。

核心流程必须覆盖这 6 个 User Story。

这些要求反而没那么「高级」。

但 Agent 真能拿它们工作。

我越来越喜欢这种思路：

少告诉 AI“你要做好一点”，多告诉它“我怎么知道你做好了”。

这件事最后会反过来改变产品经理、设计师和工程师写需求的方式。

以前一份 PRD 很容易写成：

支持用户管理。

优化体验。

提高稳定性。

改善加载速度。

增强安全性。

这些词在人类团队里还能靠会议、经验和默契把空白补上。

Agent 不会天然拥有这些默契。

所以当越来越多执行工作交给 Agent，模糊需求的成本反而会变高。

一个好的任务定义，可能会越来越像这样：

Goal：

我们想得到什么结果。

Constraints：

哪些事情绝对不能发生。

Evidence：

用什么证据证明结果正确。

Stop Condition：

满足什么条件以后可以停止。

我觉得最后这一项特别重要。

因为过去绝大多数软件流程，都默认「人会知道什么时候该停」。

未来未必。

当 Agent 可以一直运行、不断修改、不断优化的时候，停止条件本身就是系统设计的一部分。