AI写代码,人已经review不过来了…

过去三个月，我所在研发组全面启用了 AI 辅助编程。速度提升非常显著——原本一两周一个发布版本，现在的节奏是朝着”一天一个版本”在推进。组里所有人都说这是好事。从某种意义上，确实是好事。

但同一时间发生的另一件事，组里没有人愿意公开讨论。

研发自己 review 不过来 AI 写的代码了。测试也测不过来了。

这两件事最初被当成”流程跟不上”来处理——加 reviewer、扩测试人员、上自动化覆盖。试过两个月之后，我们都明白了：这不是流程问题。这是一个新的问题，旧的工程纪律没有给它准备答案。

把过去三十年软件工程的责任链画出来长这样：开发者写代码，签字；reviewer 审代码，签字；测试 owner 跑测试用例，签字；发布 owner 推上线，签字。每一道签字背后，是一个具体的人对自己经手的那一段做”我已尽到合理注意义务”的承诺。出事的时候，这条链能干净地把责任切到某一节，不至于让整个团队一起背。

这条链是软件工程能在过去三十年里支撑起银行系统、电商系统、医疗系统、社交平台的核心制度成果。它不只是技术安排，是组织安排——它让一个一千人的工程团队能够在出事的时候依然知道事情该归到谁身上，不至于陷入”大家都有责任就等于大家都没有责任”的瘫痪。

AI 编程对这条链的冲击不在两端，在中间。

开发者那一头还在——总要有人提交 PR。发布 owner 那一头也还在——总要有人按下发布键。但中间两环，review 和测试，物理上跟不上了。

一个工程师一天 review 不完十个工程师配合一群 Agent 一天的产出。代码量翻三倍五倍十倍，review 这件事所需要的认知精力没有翻——人的眼睛和大脑还是同一对眼睛和同一个大脑。测试用例的编写速度本来就比代码慢，加速十倍之后只会落得更远。这件事不能靠”再招几个人”解决，因为代码生成速度还会继续往上走，而 review 的人均速度是有上限的。

中间断了，会发生什么？

事情的进展是：reviewer 开始假装看过了。代码量多到一定程度，理性的应对就是只看 diff 的前 20 行、看一眼 commit message、看一眼有没有触及核心模块，然后点 approve。测试 owner 也开始假装跑过了——只跑关键链路的回归，新模块的覆盖率默认它”应该没问题”，因为没有时间去把它做到真没问题。

谁都没有撒谎。每个人都在自己被允许的时间窗口里做了能做的事。但这条链上原本承诺的”我已尽到合理注意义务”，每一节都开始打折扣。等到事故发生的时候，没有任何一个人是干净的。

可问题是：也没有任何一个人是有责任的。开发者会说我用 AI 是公司鼓励的；reviewer 会说我物理上看不过来；测试 owner 会说我的资源跟不上版本节奏；发布 owner 会说我凭什么为我不熟悉的代码负责。每一句都是真的。每一句都让追责无处落脚。

这是组织层面的责任链断裂——不是某个人不愿意担责，是这条链的结构在新节奏下没法继续兑现它原本的承诺。

到这里有一个问题需要回答：那为什么没出事？

短答：因为还没到时候。

长答：所有靠加速吃红利的系统，在第一次大事故来临之前都看起来在赚钱。这跟金融市场上的高频交易、跟 2008 年之前的次级抵押贷款、跟 2010 年那次 Knight Capital 在 45 分钟里因为算法错误亏掉 4.4 亿美元的情况，结构是一样的——速度本身在创造价值，所以谁都不愿意第一个踩刹车；但速度也在累积一种”看不见的负债”，这个负债以”责任承诺打折”的形式存在，平时看不见，到出事那一刻一次性还清。

我们组目前是欠债状态。我猜很多组都是。区别在于谁先撞上那次大事故。

我跟几个其他厂的同行聊过，确认这不是我们一家的特例。所有重 AI 编程的研发组都在朝同一个方向走——速度的 OKR 是硬指标，没有人愿意第一个说”慢一点”，因为第一个说慢一点的人会先被绩效惩罚。这是一个标准的囚徒困境：每个人都知道集体停下来更好，但每个人都没有动力做那个先停的人。

这种状态会怎么收场？我能想到的有三种走向。

第一种：某家公司先出大事。一个 AI 写的金融订单接错了一个 API、一个 AI 生成的 SQL 把生产库的某张表覆盖了、一个 AI 调试的支付逻辑把退款金额多算了三个零——任何一种 catastrophe 级别的事故。出事之后整个研发节奏紧急回缩，一段时间内”AI 编程”会变成内部的脏词，所有发布都要走人工双复核。这个回缩可能持续半年到一年，然后慢慢松动，但回不到之前那个不管不顾的速度。

第二种：某家公司先动手立规矩。一家头部公司主动把”AI 生成代码占比”和”重大事故率”做关联监控，把”超过某个比例必须人工 review”写进硬流程，自己先承担慢半拍的代价，但避免了被事故倒逼的难看。这种选择需要一个能扛短期 OKR 压力的领导者。这种领导者很稀缺，但不是不存在。

第三种：某个工程师先被推出去顶责。组织在事故发生时找不到干净的责任切口，但又必须给一个交代——最容易的解法是把链条最末端那个能被切的人切下去。这个人可能是 reviewer，可能是发布 owner，可能就是那个最后一个 commit 的开发者。被切的那个人未必做错了什么——他做的事跟之前一百次发布做的事没有区别——但这次出了事，需要有人承担。这是 Uber ATG 撞死 Elaine Herzberg 之后那个安全员被判刑的逻辑在另一个领域的复制：当系统找不到合适的责任承接者时，默认解法是把责任切到链条最末端那个能被切的人身上。

三种走向不互斥。最有可能的是它们以某种顺序依次发生：第一家被推出去顶责的工程师 → 第一次大事故 → 行业级别的回缩 → 一两家公司开始主动立规矩 → 新的责任链慢慢摸索出来。这个过程会持续两到三年。

写到这里，我意识到最让我不安的不是这个过程本身——任何新工具进入生产体系都会经历一轮责任链重建——而是这个过程在我们组里已经开始，但没有人公开承认它正在开始。

会上所有人都说要拥抱 AI 编程。会下没有人愿意为 AI 写的代码签字。这两句话同时为真，构成了过去三个月我看到的最清楚的一种集体心理状态。它不会自己消失。它会一直累积，直到第一次真的出事。

那次出事之后，被推出去的那个工程师，未必是写得最差的那个。可能就是那个倒霉的、当天值班的、最后一个 approve 的人。他会成为整个组织从”装作没看见”过渡到”开始想办法”的那个代价。

我不知道在我们组里那个人是谁。我也不希望知道。但我知道这个角色一定会有，因为责任链断了之后，组织必须先找到一个临时的承接点，才能开始重建。在新的责任链长出来之前，这个承接点就是某个具体的人。