AI 写代码之后，谁来判断哪里不能错

问题从来不是 AI 会不会写代码，而是：哪些东西一旦写成代码，就已经在“替人类做决定”。

一、一个看似合理、但其实危险的直觉

最近常能听到一种判断：

既然大语言模型已经能写代码了，那为什么还要人类审查实现细节？能不能让 AI 直接生成最终程序，人类只看结果，甚至连结果验证都交给 AI？

这个想法在逻辑上并不荒谬，甚至在某些封闭领域已经成立。但一旦放进真实的软件工程环境，问题会立刻暴露。

核心原因只有一句话：

世界本身是不可完全验证的。

二、代码并不是“需求的翻译”，而是“妥协的冻结形态”

很多人下意识认为：

代码 = 把需求写出来

这是一个极其危险的误解。

更接近现实的描述是：

代码，是在某一个时间点，对一组互相冲突的目标所做出的、暂时稳定的选择集合。

这些冲突包括但不限于：

正确性 vs 性能
长期可维护性 vs 交付速度
安全性 vs 易用性
架构纯度 vs 现实历史包袱

这些目标不可能同时最优，于是必须做选择。

当团队说出那句经典的话：

“先这样吧。”

妥协就被冻结进了代码里。

代码不是中立的技术产物，而是：

决策
风险分配
责任边界

的凝固形态。

三、为什么“重构 ≠ 优化代码”，而是“重新解冻妥协”

很多团队把重构理解为：

把代码写得更优雅、更快、更清晰

但真正的重构，几乎总是在做另一件事：

把过去默认接受的选择，重新拿出来谈。

每一次真正的重构，都会重新触碰这些问题：

这个字段为什么允许为空？
这个错误当初为什么被吞掉？
这个接口为什么这样设计？
这个状态为什么是隐式的？

如果一次“重构”：

没有争论
没有重新定义边界
没有重新评估风险

那它大概率只是整理，不是重构。

四、AI 写代码真正擅长的是什么？

一句话概括：

AI 非常擅长解决“怎么写”，但并不擅长决定“该不该这样写”。

AI 的优势前提是：

目标明确
语义稳定
风险可回滚
错误可被测试捕获

也就是说，它最适合处理的是实现不确定性。

但很多事故频发的团队，犯了同一个错误：

用 AI 压缩了本该由人类承担的“语义不确定性”。

五、AI 辅助率很高，但事故频发的真正原因

这些团队通常有非常相似的症状：

PR 合并很快，但线上回滚频繁
代码看起来专业统一，但边界条件混乱
测试很多，但事故总是“没测到那一类”
没有人能完整讲清关键业务链路的判断逻辑

问题不在于 AI 写得不好，而在于：

妥协被自动冻结了，但没有被显性讨论。

AI 写出的代码“看起来合理”，人类就默认接受了其中隐含的选择。

事故发生后才发现：

“我们从来没有明确决定过要这样。”

但代码已经替你决定完了。

六、一个关键判断框架：AI 可替代性 × 事故半径

要正确使用 AI，必须引入一个工程视角的坐标系：

横轴：事故半径（错了会影响多大） 纵轴：AI 可替代性（语义是否稳定、可形式化）

四个区域的结论非常明确：

高替代 × 低事故： UI 样板、DTO、算法、工具函数 👉 AI 写得越多越好
高替代 × 高事故：登录态流转、权限判断、支付前置校验 👉 AI 可写，但必须被严格围栏
低替代 × 低事故：页面交互、弱业务逻辑 👉 人类主导，但风险可控
低替代 × 高事故（绝对禁区）：金融结算、权限最终裁决、合规逻辑 👉 任何黑盒化，都是在埋雷

一句话总结：

凡是出事后需要人出来解释甚至道歉的地方，就不能是黑盒。

七、为什么金融 / 支付系统极度执着于“可读性”

很多工程师不理解：

为什么金融系统代码又慢又啰嗦？

原因很简单：

它们运行在一个“不可逆世界”里。

性能慢，可以优化
逻辑错，可能是法律和信任灾难

所以这些系统优先保证的不是极致性能，而是：

任何一个行为，在事后都能被清楚解释。

在这里，代码首先是证据，其次才是程序。

八、真正低事故率、高 AI 使用率的团队是怎么做的？

这些团队不是少用 AI，而是分清责任。

人类只负责三件事：

不变量：什么永远不能发生
冻结点：哪些决定一旦做出不可回退
事故半径：错了影响谁、如何止血

AI 负责：

实现
补测试
枚举边界
提出方案

但 AI 永远没有“冻结权”。

PR 审查不再问：

“代码写得好不好？”

而是问：

“这里冻结了什么？” “事故半径多大？” “有没有跨越不可黑盒的边界？”

九、一句不太讨好，但非常现实的结论

代码是一种社会技术，不只是计算技术。

只要软件还面向人类、运行在开放世界中，就一定需要：

可读
可解释
可介入

AI 会极大提高实现效率，但它永远不该替人类承担拍板与负责的角色。

最后一行送给工程团队

AI 负责“怎么实现”，人类负责“哪里不能错”。

如果这条边界守不住，事故只是时间问题。