"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 的团队里，新人进来很容易出现两个极端：
被 AI 喂养：
- 一切都问 AI，要什么让 AI 写什么
- 对系统的真实结构和边界没有建立自己的心智模型
- 碰到 AI 也搞不定的深水区，就完全失去方向
完全绕开 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 + 测试通过即可”
- 哪些决策必须有“书面记录 + 签字”
- 哪些文档和测试是新人入组前必须通读的