Berkeley 的AI 编程＂自动驾驶分级＂:三级框架看懂你的团队在哪个 Level

上周和朋友聊天，他说他现在写代码基本靠 AI，"一个项目 70% 都是 AI 写的"。另一个朋友说，AI"写两行就崩，根本靠不住"。

有意思的是，他们用的工具差不多，做的事情也差不多，但描述的却是完全不同的体验。

问题出在哪？不是工具的问题，是我们缺一个共同语言——到底 AI 把编程自动化到了什么程度？Copilot 补全几行也叫 AI 编程，Claude Code 开 PR 也叫 AI 编程，AI 自己决定做什么还叫 AI 编程。这些放在一起讨论，能不乱吗？

昨天（7 月 26 日），Berkeley RDI（负责、去中心化智能研究中心）联合 MIT、Cursor、微软等机构的研究者，提出了一个三级软件自主开发框架。他们直接套用了 SAE 自动驾驶分级的概念，把"AI 写代码"拆成了三个层次。

这不是又一篇画饼的论文。它有具体的数据、明确的边界、和一些让人不安的观察。

为什么要造这个框架？从两个数据点说起

在 Berkeley RDI 看来，软件工程从诞生之初就是围绕一样稀缺资源组织的：会写代码和审代码的人。编程语言、框架、测试系统、组织结构——所有这些都在帮人类用有限的注意力、时间和认知能力，把需求变成可靠的软件。

这个约束正在松动。

光说"松动"不够，文章举了两个数据点，一正一反。

好消息：Anthropic 的 Nicholas Carlini 让 16 个 Claude agents 并行协作，写出了一个可用的 C 编译器。100,000 行代码，用 Rust 写的，能编译 Linux 6.9 内核，能跑 Doom，能编译 QEMU、FFmpeg、SQLite、PostgreSQL、Redis。总成本不到 2 万美元。

听起来很震撼对吧？

但这编译器在社区独立测试时出了问题：所有 C 源文件编译零错误（只有 96 个警告），但在链接阶段产生了 40,784 个未定义引用错误。大量的 extern 声明依赖了系统现有的库，AI 写了外表，但没真的"理解"底层依赖关系。HN 上有开发者评论："CCC 能编译每个 C 文件，但链接器告诉你 4 万个东西找不到——这就像 AI 考试的每一道选择题都答对了，但把它们编成一份完整的答卷就露馅了。"

坏消息：在专门测试持续软件演化的基准（不是一次性的孤立任务）上，前沿的 coding agent 表现得很差——它们能加新功能，但保不住正确性和架构一致性。加一个功能，崩一个老功能，再修老功能，又引入新 bug。而且这些 bug 往往不是明显的错误，而是"测试通过了但逻辑偏了"的那种恶心的 bug。

更麻烦的是核心风险：同一个 AI 既写实现代码又写测试用例。当它写错了实现，大概率也写不对测试。测试通过了，可能只说明 AI 和自己没有矛盾——但和人类的意图已经偏了十万八千里。

这两个数据点放在一起看，Berkeley 的结论是：

Coding agents are becoming capable enough to take on meaningful ownership, but not yet reliable enough for us to treat autonomy as a single, undifferentiated capability.

翻译成人话：AI 写代码的能力已经到了"可以接手"的程度，但远没到"放心交给他"的程度。而且最大的问题是，"自主性"这个词涵盖了太多不同的东西——十几行补全和全自动开发，是两个物种，不应该放在同一个词下面讨论。

三级框架：Code → Pipeline → Demand

直接上表格，这是理解全文的骨架：

L1 — 代码自治（Code Autonomy）

AI 负责把需求变成代码，写出设计文档、代码和注释，开一个完整的 PR。人类不再逐行审查，但还在 PR 级别把关，决定合并与否，负责部署决策。

Berkeley 说，我们今天所有的 AI 辅助编码（Copilot、Cursor、Claude Code 的辅助模式）都只是 L1 的前奏。

关键的转移：人类从"写代码"变成"审代码"。

L2 — 流水线自治（Pipeline Autonomy）

AI 跑通从设计到部署的整条流水线。人类不再碰代码——不看、不改、也不审。人类只做两件事：描述高层需求，评价最终行为。

这是一个质的变化。L1 到 L2 不是量变，是跳变。它假设了两个前提，而 Berkeley 直接说这两个前提目前都不成立：

L3 — 需求自治（Demand Autonomy）

AI 不仅构建、测试和部署代码，它自己决定要构建什么。从遥测数据、用户行为、安全告警、依赖变更、系统状态中识别需求，生成任务，执行任务，发布上线。

人类最后一个在开发循环中的角色也消失了。唯一的约束是 AI 的"创始使命"——由人类最初设定的系统目标和边界。

Berkeley 说这个级别的核心挑战是：如何确保 AI 自己生成的需求持续服务于创始使命，而不是在迭代中悄悄重定义它。

三级之外的三个维度

框架不是三个格子往上一套就完事了。Berkeley 的洞察在于，同一个级别的系统可以表现得完全不同，取决于三个额外维度：

规约粒度——一个带复现步骤的详细 bug 报告，和一句"加个多租户支持"，对 agent 的约束完全不同。规约越模糊，系统的"实际自主级别"就越高。

时间跨度——Ticket 级、Sprint 级、Release 级、还是长达数月连续运行。长时间跨度的任务会引出记忆、溯源、回归测试、架构一致性等问题，单次 benchmark 根本测不出来。

监督模式——从共同定义需求 → 逐行审批 → 只审 PR → 策略约束 → 仅监控 → 自动回滚。在可逆性低的高危领域，监督模式必须更保守。

这意味着两个都标称 L1 的团队，一个可能规约写得极细、监督模式是逐行审；另一个可能就是一个大方向+PR 看一眼。"同样是 L1"可能意味着完全不同的风险水平。

最让我在意的观察：跳级（Level-Skipping）

Berkeley 特别指出了当下已经在发生的风险：

一个团队名义上在 L1（代码自治），人类负责审核每一个 PR，但实际中 Agent 生成的变更根本没有人有意义的审查过。团队用了 L2 的实践，却没有 L2 的验证和治理。

这是不是很多团队现在的真实写照？

工程师点一下"合并"就走开了，因为"AI 写的代码我看不懂"。管理层以为有人审，工程师以为 AI 负责——责任在中间落了空。

更隐蔽的是另一种跳级：团队让 Agent 根据遥测数据或外部内容触发生成变更。表面上看，需求还是人提的；实际上，Agent 已经在自主地从数据中"发现需求"了。这不就是 L3 的实践吗？

Berkeley 提出了明确的建议：团队应该显式分级，确认当前级别的问题已经被证明解决后，才能进入下一级。

六个结构性转变

如果实现不再稀缺，软件工程不会只是加速版的今天。Berkeley 预测了六个大的变化：

1. 规约取代代码，成为主要开发产物 写代码变便宜了，但把人类意图精确翻译给 AI 变得更重要。核心能力从写代码变成写规约（Spec）。Berkeley 提出了"规约蒸馏"的概念：未来通过对话、示例、反馈和 AI 协作，AI 持续将这些交互"蒸馏"成结构化的规约。这和最近 Claude Code 不断强调"简短的系统提示词比长篇大论更有用"的趋势一脉相承——重要的不仅是"你怎么告诉 AI 做什么"，更是"你怎么建立一个可持续的规约系统"。

2. 抽象边界变得可渗透 函数、模块、API、服务——这些抽象层级本质上是迁就人类注意力瓶颈的。AI 可以同时看到代码库的上中下游，在更大的搜索空间里做优化：重构时该拆就拆、该合就合、该 inline 就 inline。但这不代表抽象会消失。它们在开发者之间的沟通中仍然重要，只是从"开发者必须遵守的约束"变成了"Agent 可以灵活重组的问题"。一个新问题随之而来：当 Agent 频繁 bypass 抽象层，生成的代码对人类来说还能读懂吗？

3. 软件从静态产物变成动态演化系统 静态版本变成过去式。未来的软件可能融合多种形态：确定性安全核心 + 神经网络自适应边缘 + 持续在线进化，甚至是一次性的——用完即弃，因为重新生成比维护更便宜。想想你现在的项目，有多少逻辑是"写的时候知道后面会改但没时间重构"的？当生成成本趋近于零，这个权衡就彻底变了。

4. 质量保证从审代码变成认证 Agent Berkeley 特意指出了这个核心风险：同一个 AI 既写实现代码又写测试，测试通过了可能只说明 AI 和自己没有矛盾。真正的独立性要求不同目标、不同架构的验证 agents、可信的评估机制、以及裁决分歧的原则性协议。以后审计的不再是"这个 PR 质量如何"，而是"产生这个软件的系统是可信的吗"——包括 Agent 的规约、技能、记忆、决策溯源和通信协议。

5. 多 Agent 协调不再像人类组织 今天的大多数多 Agent 系统还在模仿人类公司：经理分配任务、专家执行、审核者检查、自然语言沟通。Agent 真正的能力边界完全不同——可以在毫秒级 fork/merge 执行上下文、共享完整状态、扩展到百万级并发。HN 上有个评论说得好："当 10,000 个 Agent 在协作出问题时，谁来负责？这可能比技术问题更难。"

6. 团队变小，治理变重 实现变便宜了，团队可以更精干，但人类在架构、规约、评估、安全、治理上的投入反而更重。独立审计、认证机构、信任评估服务会像今天的云服务一样常见。软件工程教育也会更多教规约设计、验证方法、安全治理，少教手写代码的技巧细节。

框架的边界——我不完全同意的地方

这个框架很有用，但我想说几个自己的看法。

一、自动驾驶的类比并不完美。

驾驶是相对封闭的问题——道路有物理规则，交通法规明确，成功的定义（安全到达目的地）清晰。软件工程是开放问题——需求在不断漂移，目标在持续重定义，"成功"取决于你和谁聊。

每次用自动驾驶级别来做类比，暗示了一个"越级越好"的隐含导向。但有些软件永远不应该也不需要在 L3。一个银行核心系统在 L0 运行二十年，可能比在 L2 运行一年更安全。

二、"创始使命"真的能约束住 AI 吗？

这是 L3 最脆弱的一环。一个系统运行几年后，初始使命文档怎么可能约束住数百万次决策？这和"AI 对齐"的根本问题是一样的——规约捕获取舍，取舍需要价值观，价值观来自人。而人的价值观本身就会变。

三、这篇论文的作者中，有 Cursor 的核心研究员（Alex Gu 等）。

不是贬低研究的价值，但值得注意这个"战略位置"。一个将 AI 编程分级为"L1 还没到"的框架，恰好是 Cursor 这类产品的能力范围（AI 补全 + PR 审核）。给行业一个"你们还在 L1"的共同认知，对商业化是非常有利的。

这不是阴谋论——有利益关联不等于研究不靠谱。但下次引用这份框架时，想想它的服务对象是谁。

四、还有一个不太舒服的地方。

框架把"开发者"的角色描绘得过于单一——仿佛所有开发者都在做同一类工作。但现实中，有嵌入式开发者（你的 AI 能编译 C，但能看懂示波器波形吗？）、有基础设施开发者（数据库内核、操作系统、网络协议栈）、有行业专家型开发者（金融领域的定量分析、医疗影像处理）。对这些领域来说，AI 自主开发的路径会和 Web 开发完全不同。这个框架更像是为"CRUD + API"类开发量身定做的。

你现在的团队在 Level 几？

看完这个框架，我试着给自己打了个分：

整体评价：L0.5，卡在了辅助阶段。

你的团队呢？这篇文章的目标不是给出一个标准答案，而是提供一个分类工具。下次别人跟你说"AI 编程"的时候，你可以问一句——

"你说的 AI 编程是几级的？"

能问出这个问题，就已经比大多数人的认知深一层了。

你的团队现在在 AI 开发的 Level 几？5 年内能到 Level 2（全流程自动化）吗？欢迎留言说说你的情况。