AI渐进编程之十一：海狮做对了喂小鱼，Agent 做对了喂什么？

前一篇我们讲的是 open_issues.md。
那一篇的重点是：把暂时不能解决、但又不能忘掉的问题留下来。
这一篇继续往下，讲的是另一件同样重要的事：

当一轮任务做对了，系统怎么明确知道“这次是对的”？

这本书把这个问题交给验收。

但这里的验收，不只是“检查有没有错”，
更重要的是给 Agent 一个明确的正反馈：

• 这条路是对的
• 这次修改是有效的
• 这个边界守住了
• 这轮可以结束了
• 下一轮可以基于这个结果继续

1. 为什么要有“通过信号”？

很多系统的问题，不是不会改，
而是改对了也不知道自己改对了。

如果没有明确的通过信号，AI 很容易出现两种情况：

第一种，改对了还继续乱改

它已经把问题修好了，
但因为没有明确的确认，下一轮又开始怀疑自己，继续扩大修改范围。

第二种，误把“差不多”当成“通过”

它看到一点局部改善，就以为已经完成，
但实际上关键路径还没验证，隐藏问题还在。

所以，本书强调的不是“看起来不错”，
而是要把“这次确实做对了”写成可检查的结果。

2. 正反馈不是夸奖，而是确认路径有效

这里要说得严谨一点。

我们说“肯定 Agent”，
不是说要像人一样鼓励它、安慰它，
而是说要给系统一个明确的工程信号：

• 本轮动作有效
• 当前路径可继续
• 这次修改没有越界
• 验证已经通过
• 可以进入下一状态

也就是说，正反馈不是情绪反馈，
而是成功确认。

它的作用是告诉系统：
“这条路已经被验证过了，可以保留。”

3. 购物车程序里的“通过信号”是什么？

还是用购物车结算程序来举例。

假设这轮任务是：

修复空购物车结算时的异常行为。

这轮任务做完以后，验收不能只说：

• “看起来没问题”
• “应该修好了”
• “大概可以了”

而要明确检查这些东西：

• 空购物车时是否返回安全错误
• 正常购物车是否仍然能结算
• 是否没有调用支付接口
• 是否没有创建错误订单
• 是否只改了授权范围内的文件
• 是否把剩余风险写回状态

如果这些都通过了，
这轮才算真正完成。

这就是程序里的“通过信号”。

4. 一条好的通过链应该长什么样？

程序任务里的正反馈，最好写成一条完整链。

以空购物车修复为例，可以这样看：

输入

购物车为空。

动作

调用 checkout 流程。

期望结果

返回安全错误，而不是继续走支付或下单逻辑。

期望副作用

• 不创建订单
• 不扣款
• 不触发异常路径扩散
• 不影响正常购物车流程

通过条件

• 空购物车路径通过
• 正常购物车路径仍然通过
• 修改范围没有越界
• 剩余风险已经记录

这条链的意义在于：
它不仅告诉 AI 这次“做了什么”，
还告诉 AI 这次“为什么算做对了”。

5. 为什么通过信号比“感觉对了”更重要？

因为 AI 很容易在局部上“看起来对”，
但整体上还是不稳。

比如：

• 它把空购物车处理成固定返回值，表面能跑
• 它改了结算逻辑，但顺手影响了正常路径
• 它补了一个测试，但没有真正验证业务语义

这些都可能让系统误以为“任务完成了”。

所以本书强调：
通过信号必须是可检查的，不是靠印象判断的。

6. current_task.md 里怎么写通过条件？

在程序项目里，current_task.md 里的验收条件，最好直接写成可执行描述。

比如：

## Task
Fix the empty-cart checkout path in `checkout/service.py`.

## Goal
Return a safe failure when the cart is empty,
while preserving normal checkout behavior.

## Allowed
- `checkout/service.py`
- `tests/test_checkout.py`
- `revision_log.md`
- `open_issues.md`

## Forbidden
- `auth/*`
- `payment_gateway/*`
- `docs/*`
- unrelated modules

## Acceptance
1. Empty-cart checkout returns a safe error.
2. Normal checkout still passes.
3. No payment request is sent for empty carts.
4. Only allowed files are changed.
5. Any remaining edge cases are recorded in `open_issues.md`.

这份验收的重点不是写得好看，
而是它能直接告诉下一轮：

• 这次要检查什么
• 哪些算通过
• 哪些不算通过
• 哪些问题先别硬解

7. 通过之后，状态要怎么回写？

验收通过以后，系统不能只停在“通过了”。
还要把这个结果写回状态。

比如：

• revision_log.md 记录这次为什么改、怎么验证、结果是什么
• open_issues.md 关闭已经解决的问题，保留真正还没处理的部分
• project_map.md 如果长期认知发生变化，也要更新
• current_task.md 结束当前轮任务，准备下一轮

这一步很重要。
因为正反馈不只是“当场通过”，
而是要把通过的结果沉淀成下一轮可以继续使用的事实。

8. 为什么程序的通过更容易让系统收敛？

因为程序的通过信号比较明确：

• 测试通过了
• 断言满足了
• 错误码正确了
• diff 没越界
• 副作用可接受

这些信号很适合用来判断：

• 这条路径是不是对的
• 这次修改是不是稳定的
• 下一轮是不是可以继续往前走

所以，程序项目很适合先讲验收。
因为它能把“做对了没有”变成实际可检查的结果，
而不是停留在“看起来差不多”。

9. 一个最小的正反馈模板

如果把程序里的“通过信号”压缩到最小，可以先写成这样：

acceptance:
  - empty_cart_returns_safe_error: true
  - normal_checkout_still_passes: true
  - payment_gateway_not_called_for_empty_cart: true
  - no_out_of_scope_files_changed: true
  - remaining_risks_recorded: true

这个模板很短，
但它已经足够让 AI 明白：

• 什么叫做做对了
• 什么叫做没越界
• 什么叫做还要继续跟进
• 什么叫做下一轮继续前进

10. 本章小结

这一章想讲清楚的核心是：

验收不只是检查错误，更是给 Agent 一个明确的通过信号。

在购物车程序里，验收不是一句“修好了就行”，
而是要明确：

• 空购物车处理正确
• 正常结算没有被破坏
• 修改范围守住了
• 剩余问题被记录了
• 这次路径可以保留为“有效路径”

有了这样的正反馈，Agent 才知道这轮不是白忙，
而是真的在朝正确方向收敛。
这也就是第十篇和第十一篇连起来的意义：

• 第十篇：把没解决的问题留下来，让系统还有继续做下去的动力
• 第十一篇：把做对的结果确认下来，让系统知道哪条路是有效的

下一章，我会继续讲：程序项目里的工作台应该怎么搭，才能把代码、状态和人类视图分开。