实现可以自动化，评估也可以自动化。但判断，始终只能由人来做。
这是“AI 原生软件工程”系列的第四篇。
本文接续上一篇：AI 原生软件工程（三）：软件即搜索。
第一篇追问，我们如何形成理解。
第二篇追问，我们如何获得正确性。
第三篇提出，软件正在变成一种搜索过程。
但有一个危险的误解，必须说清楚：
只要有智能体、验证框架和约束，
软件就能自行生产出来。
事实并非如此。
在第二篇里，约束帮助我们获得正确性。
在第三篇里，约束塑造了实现方案的搜索过程。
这一篇要继续追问：谁来为约束本身负责？
谁来决定该优化什么，
该拒绝什么，
又有哪些东西从一开始就值得做？
开始采用 AI 辅助的软件开发流程后，我注意到一个出乎意料的现象。
实现能力越强，判断反而越有价值。
起初，我觉得这有些反常。
AI 越强，人的决策不应该越不重要吗？
结果恰恰相反。
实现不再是瓶颈。
方向才是。
氛围编程：好用，直到失控 链接到标题
大多数开发者都经历过这样的过程。
一开始，你只有一个简单的想法：
把 X 做出来。
AI 生成代码。
你稍作调整。
跑通了。
于是继续往下做。
一个个小胜利不断累积。
项目也渐渐变大。
直到某个时刻，问题突然一股脑冒了出来：
- 架构渐渐偏离原来的方向
- 抽象层越堆越多
- 调试越来越慢
- 对系统的信心彻底崩塌
系统依然能运行。
但已经没人说得清，它为什么能运行。
项目陷入一种奇怪的状态：
好像一切都能推倒重来。
却没有任何东西真正处于掌控之中。
我把这叫作氛围编程。
并不是因为 AI 不好。
而是因为，每一步进展都不再对应一个经过认真权衡的决定。
测试通过带来的错觉 链接到标题
面对这种问题，一个常见的回答是：
多加一些测试就好了。
我也这样做过。
验证框架确实让流程更可靠。
验收关卡也确实让产出更稳定。
但后来我意识到：
通过评估，不等于真正交付了价值。
比如：
目标：
提高点击率
结果：
激进的通知推送
指标：
有所提升
后果：
用户流失
系统确实正确地完成了优化。
错的是目标本身。
这不是工程执行出了问题。
而是判断出了问题。
约束本身也是人的决定 链接到标题
在这个系列前面的文章里，我提出过：
约束塑造搜索的方向。
我现在依然认同这一点。
但约束本身，也是人做出的选择。
总得有人决定：
优化什么
忽略什么
接受哪些取舍
重视哪些失败
这些都不是客观给定的答案。
做出这些决定，需要：
- 对具体情境的理解
- 对结果负责的意识
- 价值判断
- 经验
正是在这里，工程仍然高度依赖人。
AI 时代，责任归属为何更重要 链接到标题
在传统软件开发中，责任往往会自然落到具体的人身上。
代码由你来写。
也由你来维护。
所以你自然会觉得，自己应当对它负责。
智能体式工作流削弱了实现与责任之间的联系。
如今的流程变成：
提示
-> 生成
-> 审查
-> 合并
结果是，没人真正对实现负责。
于是，一个危险的缺口出现了：
手握决定权，却不了解实现。
进度不断向前，却无人承担责任。
因此，必须明确由谁负责。
判断发生在边界上 链接到标题
我开始换一个角度理解人的判断。
人不需要事事决定。
真正需要人决定的，是边界。
比如：
这个功能是否应该存在？
怎样的取舍可以接受？
性能达到什么程度才算够用？
哪些风险可以承担？
哪些事情绝不能发生？
正是这些边界，定义了整个系统。
边界之内的其余工作，都可以委托出去。
工程师的新角色 链接到标题
或许，工程师并没有变得不那么重要。
只是职责正在向少数更关键的事情集中。
过去的要求是：
理解一切
这不可能做到。
现在的责任是：
做出正确的决定
依然很难。
甚至可能更难。
我现在遵守的原则 链接到标题
使用 AI 时，每次准备合并代码之前，我都会问自己三个问题。
如果出了问题，我知道该从哪里着手调试吗？
我愿意公开为这个设计辩护吗？
如果 AI 明天就消失，我仍然愿意接受这份成果吗？
只要有一题的答案是否定的，我大概就还没有理解得足够深入。
结语 链接到标题
未来，AI 或许会生成绝大多数软件。
验证框架或许能检查绝大多数行为。
评估循环或许能让绝大部分正确性检查自动完成。
但仍然要有人回答一个问题：
这个系统应该存在吗？
而这个问题，很少只是技术问题。
判断力，或许会成为工程领域最后一项无法委托出去的能力。