为什么必须让 AI 自动写代码：三个被忽视的崩溃点

为什么必须让 AI 自动写代码：三个被忽视的崩溃点

——「人 × Agent 协作」系列 · 第 2 篇

上一篇结尾，我们抛出了三个问题。这一篇，正面回答第一个：为什么必须让 AI 自动写代码？

最常见的答案是"提效"。但这个答案太轻了——它解释不了为什么那些已经用上 AI 的团队，反而比没用 AI 之前更焦虑。真实的理由远比"提效"沉重：有些工作，如果不交给 AI，团队就会从内部崩溃。 让我用小布那一个早晨留下的证据，把这件事说透。

先纠正一个流行的误区

在进入正题前，必须先纠正一个流传甚广的误区，否则后面所有讨论都会偏。

很多人把"让 AI 自动写代码"理解为：原来人写 8 小时代码，现在 AI 写，人就可以少写一点。 这是一种把 AI 当"更快的打字员"的理解。

但小布那天早上做的事，没有一件是"写代码"。

他拉取了 6486 条工单、关闭了 17 条幻觉工单、提醒了 112 条超时工单、分析了 65 个文件 4500 行 diff、输出了带 commit 定位和阻断等级的 UX review 报告。这些工作，原来根本就没有人在系统地做。 它们都重要，但都重要却低紧急，永远排在写新功能、修线上故障、开会的后面，最后被默默放弃。

所以"让 AI 自动写代码"这个说法，其实是个误导。更准确的说法是：让 AI 自动接管那些"重要但永远排不上队"的工程工作。 而这些工作之所以排不上队，是因为它们各自对应着一个人扛不住的崩溃点。

崩溃点一：bad case 的洪流

我们的产品是一个 AI 审核系统。它每天在线上替用户做财务单据的审核判断，也就每天都会产生"判错了"的 case——一张本该通过的发票被拦下了，或者一张不合规的报销被放行了。

这些 case 不会自己消失。每一个都需要有人去拉 trace、看日志、定位是规则错了还是模型错了、判断要不要改代码、改成什么样。这是质量改进的唯一燃料：没有 case 分析，就没有产品迭代的方向。

小布的工作目录里，累计了 285 份这样的分析报告。

我们来算一笔账。一个熟练工程师，认真分析一个线上 case——读 trace、对照规则、复现、定位根因——至少需要半小时。285 个 case：

285 × 0.5 小时 = 142.5 小时 ≈ 35 个工作日

也就是说，光是清理已经积压的 case，就需要一个工程师全职干一个多月。而且，这只是存量。我们的系统每天都在产生新 case，存量还没清完，增量又涌进来了。这就像一个浴缸，水龙头一直开着，下水道却细得可怜——水面只会越涨越高。

在没有 AI 之前，团队是怎么"处理"这件事的？答案是：没真正处理过。

我们试过两种"人肉方案"，都失败了。第一种是让一个工程师兼职分析 case，每周挤出半天。结果是这半天永远挤不出来——一旦有线上故障或紧急需求，第一个被让步的就是这件"没有 deadline 的事"。第二种是出了大事故之后集中冲刺，全员停下来分析一批 case、改一批规则，然后……然后就没有然后了，直到下一次事故。case 在某个表格里越积越多，隔一段时间有人看一眼，看不过来就关掉，假装没看见。

这是一种靠事故驱动质量的模式——它不是在改进质量，它只是在事故发生后被动止血。本质上是把问题推迟到爆炸。

小布做的事，与其说是"替人写得更快"，不如说是把这条断裂的质量反馈环重新接上。他每天凌晨 2 点跑一轮，把当天线上产生的 case 自动拉 trace、自动归因、自动写出"这个 case 是因为规则 X 触发了条件 Y、但单据实际属于场景 Z"这样的分析。工程师早上来，看到的已经从"一堆要分析的 case"变成了"已经分析完的 285 份报告，按根因分类好了，你直接决定要不要改、改哪里"。

这里 AI 不可替代的，不是速度，是"不会积压"。 人会累、会忘、会被打断、会优先处理更紧急的事；AI 不会。它每天凌晨 2 点准时跑，不抱怨、不打断、不挑活。一个 case 从产生到有分析结论，稳定在 24 小时内——这是任何一个人都做不到的持续性。

崩溃点二：工单的慢性停滞

第二个崩溃点更隐蔽，因为它不会爆发，只会慢性失血。

小布那天发现，有 112 条指派给人的工单，已经停滞超过 5 天。

这 112 条不是某一天突然冒出来的。它是每天漏一点、忘一点慢慢积出来的。一条工单被指派给某个开发者，开发者当天在开会；第二天有线上故障要处理；第三天有个更急的需求插进来；第四天他请了假；第五天，这条工单已经从"今天要做的事"沉到了记忆的底部。

人会忘。这不是态度问题，是认知的物理限制。人的工作记忆容量有限，注意力会被紧急事项不断抢占，而"一条已经在那躺了三天的工单"永远不会触发人的紧迫感——因为它没变，它就那么静静地躺着。

最讽刺的对照是：小布判断"智能体卡单"的阈值是 24 小时。也就是说，一个 AI 处理的工单如果 24 小时没动，他会立刻捞起来处理或转派；而人处理的工单，平均要等到停滞 5 天才会被注意到。后者是前者的二十分之一效率。

这不是人的错。让人每天逐一检查自己名下的几十条工单、判断哪些该推进、哪些该催——这件事本身就不该由人来做。它是纯粹的机械核查，毫无判断价值，却极度消耗注意力。

在没有小布之前，团队尝试过很多"人肉方案"：每周开站会过一遍工单、设一个项目经理专门催进度、在群里 @ 人提醒。这些方案都失败了，因为它们都在消耗另一种稀缺资源——人的注意力和会议时间——来弥补第一种稀缺资源的不足，本质是拆东墙补西墙。

小布的做法截然不同。他每天 9 点跑一轮，把所有停滞超期的工单自动整理成清单，只发一条消息给工单负责人，消息开头是一句加粗的总结：

本轮共有 112 条超过 5 天未更新的工单，清单如下……

人需要做的，只是看这一条消息，然后决定推进哪几条。整件事从"每天被动核查几十条工单"压缩成"每天看一条摘要消息"。 这才是 AI 真正的价值：它不替人决策，它把需要人决策的信息，从噪音洪流中过滤出来，精准投递到人的注意力里。

崩溃点三：AI 自己制造的噪音

第三个崩溃点最微妙，也最能说明问题。

那 17 条被自动关闭的"模型幻觉"工单，需要先解释清楚它们到底是什么。

这些工单本身是真实的 bad case——线上确实发生了审核错误，单据确实被误判了。分诊 agent 拿到这些 case 后，会做一次归因排查：规则有没有问题？代码逻辑有没有问题？上下文管理有没有串扰？如果三项都排除，剩下的结论只有一个——这次错误是 AI 模型自己犯的，打上"模型幻觉"标签。

问题来了：这类 case 没有工程上可行动的修复项。规则没问题，你改不了规则；代码没问题，你改不了代码；上下文没问题，你改不了上下文。错误的根源在模型本身的能力边界，而模型不是研发团队当下能动的。如果把这些 case 留在研发队列里，它们会一直挂着，既没人能处理，又占据看板位置、污染工作量统计，让真正有修复项的 case 被淹没。

让人去逐条复核"这条到底是不是模型幻觉、还有没有工程抓手"，是对人类注意力最纯粹的浪费。因为复核这件事，需要的是对照规则、代码、上下文做交叉验证——这恰恰是分诊 agent 已经做过一遍的工作，再让人做一遍只是重复劳动。

小布的逻辑很直接：凡是已经被分诊 agent 归因为"模型幻觉"、且当前没有工程修复项的 case，一律自动关闭，并维护到一个专门的清单里。关闭不代表忽视——这些 case 会被归类统计，用于衡量模型的能力上限和错误趋势，是后续模型迭代的输入。但它们不该占用研发当下的注意力。

这个例子之所以重要，是因为它揭示了一个更深的真相：AI 系统产出的某些问题，当前根本没有工程解。 你不能用传统的"每个 bug 都要修"的思维去管理 AI 的产出。唯一的出路，是让 AI 先把"可修的"和"不可修的"分开，把不可修的归档、把可修的留下——这是本系列第 3 篇"用 AI 治理 AI"要讲的核心。

三个崩溃点的共性

把三个崩溃点放在一起看，会发现一个惊人的共性：

它们的共同特征是：重要，但不紧急；高频，但低单次价值；有套路，但需要持续性。

这三件事，恰恰是人类注意力最不擅长的领域。人的注意力是为"低频、高价值、需要深度判断"的事设计的——架构决策、业务取舍、复杂调试、创造性问题求解。让人的注意力长期浸泡在"高频低价值的机械核查"里，不仅浪费，而且会反过来削弱人做高价值判断的能力——这是注意力被磨损的必然结果。

所以，"为什么必须让 AI 自动写代码"的真正答案，不是"AI 更快"，而是：

AI 接管的是那些不该占用人类注意力的工作。把这些工作交出去，不是为了让人闲下来，而是为了保护人最稀缺的资源——做高价值判断的能力。

一个反直觉的验证

如果这个论点是对的，那应该有一个可观察的验证：用上 AI 之后，人做的事应该变得更高价值，而不是更少。

这正是我们观察到的。

小布的 bug-fix 记录里，能看到他独立修复了一批真实工单——某个接口的幂等问题、某个缓存隔离缺陷、某个提示词失真。但请注意：这些修复不是凭空冒出来的。每一个修复的背后，都是 285 份 case 分析里某一份指出了根因，是某条超时工单暴露了流程断点，是某条"模型幻觉"case 帮研发排除了一个错误方向（既然模型本身没错，那问题一定在别处）。

换句话说，AI 把 case 分析、工单核查、噪音清理这些事扛走之后，人和 AI 一起做的事，质量反而上去了。因为人终于有时间，把一个 bug 的根因想透、把一个规则的边界测全、把一次回归的影响范围评估清楚，而不是在 285 个 case 的洪流里疲于奔命。

这和 Cloudflare 公开的数据遥相呼应。他们用 7 个专业 AI agent 做代码 review，覆盖 5000 多个仓库、4.8 万个 MR，而工程师只在 0.6% 的情况下需要 override AI 的判断[^cf]。这并不意味着 AI 比 0.6% 更聪明——真正的含义是，AI 把 99.4% 的机械判断扛走之后，人那 0.6% 的 override，才显得格外精准、格外有分量。

[^cf]: Cloudflare 工程博客《Orchestrating AI Code Review at scale》，数据统计区间 2026-03-10 至 2026-04-09（30 天）：5,169 个仓库、48,095 个 MR、131,246 次 review 运行，break glass 288 次（0.6%），中位 review 时长 3 分 39 秒，平均成本约 1.19 美元。https://blog.cloudflare.com/ai-code-review/

回到那句话

文章开头，我纠正了一个误区：AI 不是"更快的打字员"。现在，让我用一句话把这一篇的核心收束起来：

让 AI 自动写代码，本质是在做一道注意力的减法——把不该由人扛的，从人的肩上卸下来。

bad case 洪流、工单停滞、噪音清理——这三个崩溃点，是任何依赖 AI 的产品团队迟早都会撞上的。撞上之后只有两条路：要么用人肉去扛，扛到团队疲态尽显、质量改进停滞；要么用另一层 AI 去治理，把机械工作交出去，把人的注意力还给高价值判断。

我们选了第二条路。但这条路立刻引出一个新的、更棘手的问题：

当 AI 每天产出 4500 行代码、65 个文件的 diff，人，怎么 Review 得过来？

这是本系列第 3 篇的主题：用 AI 治理 AI 的产出。我们会拆解那套把全量 diff 压缩成"几个需要人判断的头部问题"的分级门禁体系，并对比 Cloudflare 的多 Agent 评审架构。

下篇见。

一句话结论

让 AI 自动写代码的真正价值，不在"更快"——它在于把不该占用人类注意力的机械高频工作交出去，保护人最稀缺的能力：做高价值判断。