第 7 章：Human-in-the-loop 与新人培养

"AI 不能解决所有问题，AI 不能解决第一公里和最后一公里的问题，这本质上是人的问题。"

延伸阅读：Debug 工作流如何展示人机协作的边界，参见Debugging：在深水区和 AI 一起查 bug。测试体系如何提供安全网以支持人类委托，参见Test–Code 循环：为什么测试代码比功能代码更重要。

1. 第一公里和最后一公里：AI 做不到的两端

在 AI-native 的世界里，有两件事是 AI 做不到、或者说做不好、也不该它做的：第一公里（First Mile）是设计一个真正合理的方案；最后一公里（Last Mile）是在真实环境里把每一行代码都调到正确。

“人类和 AI 的关系是审阅者和执行者的关系，但人无法评估自己都不了解的事物。”

这句话的潜台词是：

• 你不能把一个你都没看懂的系统，交给 AI 去“自动维护”
• 你必须先对系统有足够的理解，才有资格评估 AI 做得好不好

2. Human-in-the-loop 是不可消除的工程成本

很多人会希望有一天能做到“全自动”：
PRD 塞给 AI → AI 自动拆任务 → 自动写代码 → 自动上线 → 自动维护。

实践下来的结论是：

• 这种幻想一旦引入真实、复杂、长寿命的系统，很快就会崩溃
• 你越依赖 AI 自动化、越少有人认真审阅，债务就累积得越快

真正可行、也必须接受的模式是 Human-in-the-loop 全程在场：

• 在需求澄清阶段
• 在关键架构决策时
• 在每一轮大改动和关键路径变更之后

AI 可以帮你完成大量重复性、体力性的、局部性的工作，但对于“整体走向”和“关键决策”，人必须显式签字。

3. 新人培养：AI 带不出来一个真正的工程师

在一个 AI-native 的团队里，新人进来很容易出现两个极端：

1. 被 AI 喂养：一切都问 AI，要什么让 AI 写什么；对系统的真实结构和边界没有建立自己的心智模型；碰到 AI 也搞不定的深水区，就完全失去方向。

2. 完全绕开 AI：担心 AI 出错，不信任 AI；自己一个人手写所有东西；在今天的节奏下很快就会被整体节奏甩开。

一个比较健康的新人培养方式是：

• 把 AI 当成“非常熟练、但不太可靠的助手”
• 要求新人对每一次 AI 改动都做到：
  • 知道它改了哪一块
  • 知道这块在整个系统中的位置
  • 知道这块的测试覆盖和验证方式

“虽然人不用去写代码，但是你一定要知道他到底在改哪一块……不能接受‘误打误撞改对’的结果。”

4. 用 Debug 和测试来训练新人的判断力

对于培养新人来说，最好的训练场景不是“让他写功能”，而是：

• 带他一起 debug 一个真实的深层 bug（参见Debugging：在深水区和 AI 一起查 bug）
• 带他一起补一条关键路径的测试（参见Test–Code 循环：为什么测试代码比功能代码更重要）

在这些场景里，新人必须学会：

• 如何把问题现象讲清楚给 AI 听
• 如何用日志和测试来纠正 AI 的误判
• 如何在 AI 连续两轮都解决不了时，接过接力棒自己读代码
• 如何把最后的“结论性信息”沉淀成文档，而不是把全过程粘贴进去

这一整套过程，就是在训练新人：

• 对系统建立自己的 mental model
• 对 AI 的局限建立直觉
• 对“什么时候该信 AI，什么时候一定要自己亲自看”的边界有判断

5. 团队层面的 Human-in-the-loop 设计

从团队视角来看，Human-in-the-loop 不只是一个“哲学态度”，而应该被设计成一种明确的机制：

• 哪些模块、哪些路径，任何改动都必须有人工 review
• 哪些类型的改动可以“AI + 测试通过即可”
• 哪些决策必须有“书面记录 + 签字”
• 哪些文档和测试是新人入组前必须通读的

只要团队还在写对外可见的代码，只要产品还在对真实用户负责，
Human-in-the-loop 就不可能消失，它只可能被设计得更清晰或更混乱。