上周，UC Berkeley 教授 Dawn Song 抛出了一个挺扎手的问题。

当 AI 已经能读仓库、写代码、跑测试、开 Pull Request，软件工程下一步该讨论什么？

她给出的方向是「责任转移」。过去我们问 AI 能帮工程师写多少代码。现在要问的是，一条软件生命线里，人类愿意让 AI 负责到哪一步。

这两个问题看着只差几个字，组织方式却差得很远。

我看到这里时，第一反应是，很多团队已经把手伸到了第二个问题里，制度还停在第一个问题上。

代码有人签字。

可签字的人，未必真的看懂了。

Dawn Song 团队在《Towards Autonomous Software Development》中，把软件开发自治分成了三级。

Level I 是 Code Autonomy。AI 负责系统设计和实现，交付完整的 Pull Request。人类决定做什么，按 PR 粒度审查，盯住测试、安全审计和部署。

Level II 是 Pipeline Autonomy。AI 从设计一路做到测试、审计和部署。人类描述高层需求，再验收系统行为，不逐行读代码。

Level III 是 Demand Autonomy。AI 连「该做什么」也自己判断。它从用户行为、遥测数据、安全公告和依赖变化里发现需求，持续修改系统。

这套框架还只是 position paper 提出的分类法，算不上行业标准。它有一个很实用的地方，终于把「Agent 很自主」这种模糊话拆开了。

AI 写完一个函数，和 AI 决定上线一个功能，显然承担着不同的风险。

Berkeley 软件开发自治矩阵

图片来源：Berkeley RDI，Towards Autonomous Software Development

Berkeley 团队专门提醒了一种已经出现的做法，level-skipping。

流程图上，团队还在 Level I。每个 AI Pull Request 都安排了人工 review。真实情况却可能是，变更越来越大，生成越来越快，reviewer 扫一眼测试绿灯就合并。

组织已经按 Level II 的速度在跑，验证能力、权限制度和事故责任仍停在 Level I。

这会制造一种很奇怪的安全感。

仓库有审批记录，CI 也全绿，表面上每个环节都有人管。可实现和测试如果来自同一个 Agent，二者可能一起误解需求。Berkeley 论文里的原话很克制，测试通过可能证明的是一致性，未必证明正确性。

说实话，这比一段明显写错的代码麻烦。明显错误会报警，彼此吻合的错误会一路拿到通行证。

别急着把问题归结成「AI 代码质量差」。公开研究给出的画面更复杂。

METR 在 2025 年做过一项随机对照实验。16 名经验丰富、长期参与目标开源仓库的开发者，完成了 246 个真实 issue。允许使用 Cursor Pro 和当时的 Claude 3.5/3.7 Sonnet 后，任务平均耗时增加了 19%。

更有意思的是，开发者事前预计 AI 能提速 24%，做完后仍觉得自己快了 20%。

METR 开发者预期与实际耗时

图片来源：METR，Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

这个结果有清楚的边界。它测的是 early-2025 工具、熟悉大型开源项目的资深开发者、平均两小时左右的维护任务。拿它证明「AI 编程都更慢」会过头。

它真正提醒我们的，是主观效率感靠不住。Agent 写得飞快，工程师花在提示、等待、检查和返工上的时间，常常没被算进那几秒钟的生成动画里。

Google Cloud 的 2025 DORA 报告提供了另一个角度。报告汇总近 5,000 名技术从业者的问卷和 100 多小时定性资料。90% 的受访者已在工作中使用 AI，超过 80% 认为生产力提高，仍有 30% 对 AI 生成的代码几乎不信任或完全不信任。

DORA 观察到 AI 采用与软件交付吞吐、产品表现正相关，与交付稳定性仍为负相关。这里是相关关系，不能写成因果结论。报告给出的解释很朴素，变更量上去后，薄弱的自动化测试、版本控制和反馈回路会被放大。

DORA AI 能力模型

图片来源：Google Cloud DORA，State of AI-assisted Software Development 2025

代码产量增加后，review、测试、发布和事故响应会接住新的压力。

责任没有消失，只是搬家了。

我更愿意把软件责任拆成六段来看。

这张表里，AI 可以拿到很多执行权。问责权仍然要落到具体的人和组织角色上。

原因也很现实。模型没有劳动合同，不承担赔偿，不会面对客户，也不会在凌晨三点决定是否停止一条赚钱但持续伤害用户的业务链路。

公司可以说「这是 Agent 自己做的」，客户和监管者大概率不会接受这句话。

一套好用的自治政策，不该按模型名字制定。Claude、Codex、Gemini 会不断升级，今天写下的能力判断很快过期。政策应该盯住任务本身。

第一道门是可观察。

每次变更要留下输入规格、模型与工具版本、权限调用、代码差异、测试证据和部署结果。没有完整 Trace，事故复盘只能靠猜。

第二道门是可回滚。

小批量变更、feature flag、权限限时、写操作白名单、自动回滚阈值，这些东西看着没有 Agent demo 酷，真出事时全靠它们救命。

第三道门是可独立验证。

验证方要与生成方保持足够独立。可以是不同模型、确定性规则、人工抽查，也可以是专门的安全测试系统。高风险服务不能只让同一个 Agent 自己出题、自己答题、自己判卷。

NIST 的 SSDF 已经给了一个可复用的工程骨架。它把安全开发分成 Prepare the Organization、Protect the Software、Produce Well-Secured Software、Respond to Vulnerabilities 四组，并要求跟踪组件来源、软件安全需求、风险和设计决策。

NIST 安全软件开发框架

图片来源：NIST Secure Software Development Framework

换到 Agent 场景里，就是先准备组织和运行环境，再保护代码、上下文与凭据，持续验证产物，最后把漏洞响应和事故责任写进值班表。

同一家公司里，内部报表工具可以靠近 Level II，支付系统可能长期停在 Level I 以下。统一喊一句「全面拥抱 Agent」没有工程意义。

更可行的做法，是给每个系统建一张自治档案，至少写清五项内容。

1. 允许 AI 负责到哪个生命周期环节
2. 单次任务的最大权限和影响半径
3. 必须由谁批准生产变更
4. 出错后多久能回滚，谁有一键关停权
5. Trace、测试证据和审批记录保留多久

我的判断是，未来优秀的软件团队会少看一项指标，AI 写了多少代码；多看一项指标，多少变更在没有扩大事故概率的前提下完成了闭环。

责任交给 AI 的上限，也不该由模型排行榜决定。

它取决于组织能看见多少、撤回多快、验证多独立，以及出事时有没有一个真实的人站出来。

你所在的团队现在更接近哪个状态？AI 辅助、Code Autonomy，还是流程写着有人 review，实际上已经悄悄跳级了？