Published on

AI 代码 = 自动驾驶？

自动驾驶看上去很酷，但总感觉有点危险。vibe coding 就不一样了——看上去很酷，搞砸了好像也没什么大不了。

但「也没什么大不了」，正是问题所在。

当 AI 开始大规模参与软件开发，一些人觉得「程序员会在六个月内被 AI 取代」，另一些人则固执地不肯撒手让 AI 帮忙。争论还没有结论，但这个问题本身让我联想到了另一个领域。

自动驾驶已经有一套成熟的分级标准。SAE 把它分成 L0 到 L5，从「完全人工驾驶」到「完全无人驾驶」，每一级描述的是同一件事：随着系统能力提升，人类的控制权从哪里退出、退到哪里。

同样的分级，能不能套到代码系统上？

结构上可以。但有一个关键差异，会让整个风险模型发生质变。

一、对齐 SAE：AI 代码决策权的六级模型

首先，对齐 SAE 来得到 AI 代码决策权的六级模型：

Level人类角色AI 角色对应 SAE
L0完全人工编程无自主能力（最多自动补全）L0：完全人工驾驶
L1所有决策 + 所有修改提供建议、补全代码L1：单一辅助功能
L2持续参与 review + 选择实现生成函数 / 模块，需逐步确认L2：转向 + 加速辅助
L3只做语义判断（接受 / 拒绝）基于目标完成 feature，生成 PRL3：系统主导，人类随时接管
L4只监管边界 + 关键路径审批在限定模块内自由修改、自动修 bugL4：特定场景完全自动
L5只定义目标（goals）完整设计 + 实现 + 重构L5：完全无人驾驶

核心结构和自动驾驶完全一致：人类控制权逐步下移，但责任逐步上移。

从 L0 到 L5，人类经历了一个清晰的角色迁移：

写代码的人 → 审代码的人 → 语义守门人 → 只定义目标

这个迁移在自动驾驶里有对应物：

驾驶员 → 监督员 → 紧急接管者 → 乘客

结构是同构的。两者都是 Human-in-the-loop 系统从「执行层」向「责任层」的演化。

二、相似之处：决策粒度上移

两个系统的本质变化是相同的：随着自动化程度提升，人类的决策对象从「如何做」变成「是否允许」。

自动驾驶里：

  • L1–L2：控制方向盘
  • L3–L4：决定「是否允许系统继续运行」

代码系统里：

  • L1–L2：关注函数、变量、实现细节
  • L3–L4：判断「这个变更是否符合系统意图」

在这一点上，两者非常相似。这也是为什么自动驾驶的分级结构可以直接作为模板。

但从这里开始，两个系统就开始分叉了。

三、第一个差异：是否可回滚

自动驾驶是实时控制系统，每一帧决策立即生效，不可撤销。车向左偏了，这一刻的偏移是真实发生过的物理事实。

代码系统不是这样。

每次修改都进入版本控制，理论上可以 revert、rollback、hotfix。代码系统的状态是版本化的，错误不是终点，只是一个可修正的状态。

这一点让人觉得代码系统比自动驾驶「更安全」，因为有退路。

但这个直觉是有缺陷的。可回滚只是说「技术上可以撤销」，不代表「撤销成本低」。随着系统演化，回滚一个决策的代价可能远高于重新实现它。这就引出了第二个差异，也是更关键的那个。

四、更关键的差异：累积性退化

自动驾驶的一次错误判断，如果最终没有产生事故，通常不会影响下一次驾驶。

系统在每一帧重新感知环境，过去的错误不会改变传感器输入，不会修改控制架构。每一次任务结束，状态基本清空。误差不会积累，只会在闭环反馈中被吸收。

代码系统完全不同。

一个不合理的抽象被 commit 了，它就进入了系统结构。其他模块开始依赖它，新功能在它的基础上叠加，测试围绕它编写。这个最初的小错误逐渐变成了系统的一部分，改变了所有未来修改的边界条件。

几次这样的小错误之后，系统仍然能跑，功能仍然正常——但结构已经混乱了。没有人能说清楚为什么某个接口设计成这样。那段核心逻辑？大家心照不宣：「能跑就别碰。」

这就是累积性退化（cumulative degradation）：

自动驾驶的错误是「时间上可消散的噪声」； 代码系统的错误是「结构上累积的约束」。

前者是误差控制问题，后者是复杂度演化问题。

五、L4 是失控的临界点

理解了累积性退化，我们就能回答一个更具体的问题：

自动驾驶频繁运行在 L4，没什么问题。AI 代码频繁运行在 L4，代码库很可能失控。为什么？

自动驾驶的 L4 是「受约束自治」。它有地理边界（geofencing），有任务边界，状态不累积，每次任务独立。AI 可以自由控制车辆，但它的 action space 很窄——只是方向和速度，不会改变道路本身。更关键的是：L4 自动驾驶某个阶段的小错误，如果最终没有产生事故，基本不会对接下来的自动驾驶产生任何影响。 系统在下一次任务开始时完全重置，错误不留痕迹。

AI 代码的 L4 是完全不同的东西。

在 L4，AI 可以在限定模块内自由修改、重构依赖、自动修 bug。表面上看边界是清晰的，但代码模块之间的边界从来不是物理隔离的。一个「限定模块内」的修改，很可能悄悄改变了接口契约，影响了另一个模块的假设，引入了一个没有人注意到的隐性耦合。

更重要的是：这些修改会累积。

今天一个 L4 操作重构了某个工具函数的签名，下周另一个 L4 操作在它的基础上加了新逻辑，再下个月又一个 L4 操作把它引用到了原本独立的模块里。每一次操作单独看都是「合理的」，但三次叠加之后，系统的抽象边界已经悄悄漂移了。

这就是 L4 在代码系统里的真正风险：不是单次操作失误，而是频繁 L4 操作的累积效应会把系统从「受控演化」推向「结构性漂移」。

自动驾驶不存在这个问题，因为道路不会因为昨天的驾驶决策而改变形状。但代码库会。每一次 AI 的自主修改都在重塑系统的结构，而这个结构是下一次修改的基础，也是下下次修改的基础。

L4 的危险，不在于它的单次输出，而在于它是一个结构自修改系统的入口。

六、L2–L3 是当前最理想的区间

基于以上分析，结论是清晰的：在 AI 参与的代码系统中，L2 到 L3 是性价比最高、风险最低、可持续性最强的工作区间。

为什么是 L2–L3？

L2：人类控制实现层。

AI 写代码，但人类逐行参与 review，所有结构决策由人类做。AI 的输出是草稿，人类是真正的决策者。这个区间的 AI 是「效率工具」，复杂度增长是线性的，抽象边界始终由人类持有。

L3：人类控制语义层。

AI 可以完成一个完整的 feature 或 PR，人类不再看每一行代码，只判断「这个变更是否符合预期行为」。审查对象从代码细节上移到了系统语义。效率显著提升，但人类仍然是语义层的守门人。

两者的共同点是：人类仍然握有抽象边界的定义权。

L4 以上，AI 开始拥有修改抽象边界的能力。人类退出了结构控制，只剩下目标定义。这在今天的代码系统中意味着：没有人能保证系统的演化方向还在可预期的范围内。

七、结论

自动驾驶和 AI 代码系统共享同一个分级结构，但风险语义完全不同。

自动驾驶优化的目标是安全性和连续性，错误是瞬时的，系统状态在每一帧重置，累积性退化不存在。频繁 L4 在这个语境下是合理的。

代码系统优化的目标是可维护性、可理解性和可演化性，错误会进入结构，状态永久累积，复杂度只增不减。频繁 L4 在这个语境下是危险的。

AI 让代码生产成本趋近于零，但同时也让结构错误的产生成本趋近于零。真正的压力因此转移到了：

如何阻止「低成本错误」进入「高成本结构」。

L2–L3 是当前这个阶段最有效的答案——不是因为它最先进，而是因为它保留了人类对系统结构的最终控制权。

自动驾驶的终点是「不需要人」。

但软件系统真正需要的，是有边界的自治（bounded autonomy）。

在工程实践上，这引出了两个值得关注的概念：agent workflow 和 agent harness。前者描述 AI 在任务流程中的决策边界，后者指包裹在模型外层、约束其行为的执行基础设施。两者都是「有边界的自治」的具体落地方向，将来有机会可以展开讨论。