返工率暴涨 861% 之后，AI 写代码最贵的成本是「没人审」——内容生产也该装 review 闸门

现状之痛：我用 AI 写稿快一年，最怕的不是写得慢，是写得快。快到你来不及想「这篇到底能不能发」，它已经躺在草稿箱里了。代码圈先撞上这堵墙：GitClear 的年度报告里，AI 辅助下的代码量涨了 4 倍，可带来的价值只多了 12%；Faros 的调研更直接——代码返工量（churn）最高涨了 861%，缺陷率从 9% 爬到 54%。写得越快，返工越多，这就是「生成变便宜」的代价。可大多数人还在用老办法对付新问题：让写的人自己多看两遍。

读完你将：拿到一个可落地的判断框架——为什么生成变便宜之后，判断才是稀缺品；代码圈的 merge gate 是怎么把 review 从「人盯」变成「代码拦」的；以及我把同一套逻辑装进内容生产后，0 号闸门和 17 项写作门禁是怎么从一次次事故里长出来的。全部有真实命令和输出，照着抄就能用。

前一篇聊 Agent Skills 时我写下一句话：技能会过期，会维护的技能才保值。今天把同一个问题往前推一步——当 AI 批量产出成为默认动作，什么在替你把关？

一、861% 的返工，是一个时代的拐点信号

先看代码圈发生了什么。

GitClear 的年度报告盯了一年 AI 辅助编程的仓库，结论是：代码提交量涨了大约 4 倍，但能对应到价值提升的改动只多了 12%。Faros 的调研把账算得更细：AI 辅助团队的代码 churn（写完又返工改动的量）最高涨了 861%，缺陷率从 9% 爬到 54%，无审查合并涨了 31.3%。

这几个数字放在一起，指向一个反常识的结论：生成变便宜了，判断才是稀缺品。 代码本身在通胀——提交变多、返工变多、没人看过的合并也在变多。Addy Osmani 在《Agentic Code Review》里反复讲同一件事：写代码的成本塌下去之后，理解代码的成本没有跟着塌，AI 一分钟产出的东西，人要一小时才看得完。

代码冗余不是 AI 的错，是管道里少了东西。

二、代码圈的答案：把 review 装进管道，而不是寄望于人

GitClear 的数据里藏着一个更难堪的事实：不是开发者变懒了，是 review 这个动作在流程里没有位置。合并请求堆成山，人只有下班前那点时间，点「approve」的速度越来越快——这不是个别人偷懒，是系统性地把检查压给了最贵、最稀缺的资源：人的注意力。我把这种现象叫审查失真：看是看了，什么都没看出来。

代码圈被返工负债咬疼之后，答案不是「大家认真点」，而是 merge gate：把检查从人的自觉，编译成管道里的硬约束。

# 代码仓库的 CI 门禁：不通过，禁止合并（示意）
ci run --lint --unit-test --build
if [ $? -ne 0 ]; then
  echo "merge blocked: CI failed"
  exit 1
fi

merge gate 和人工 review 的分工很明确：凡是能写成规则的，机器先拦一遍；拦不住的语义问题，才轮到人。review 不是被取消了，是被挪到了机器筛过之后——人看的每一眼，都花在机器看不出来的地方。

三、内容的同构危机：AI 写稿变便宜之后，谁在审？

把上一节的「代码」换成「内容」，你会发现每个词都成立。

我的内容生产系统跑了 276 天，一天一篇的节奏，AI 起草、工具配图、脚本推送。量是上去了，问题也来了，而且和代码圈长得一模一样：

9 月 7 日，标题写的是 Kill Switch 法案，正文却是另一篇 DeepSeek Harness 的全文——标题和正文错配，我自己复查了两遍都没发现；
更早一次样板事故：改造文章时丢了一个代码块围栏，结果「此刻的你」、金句、签名全部被吞进代码块，微信里渲染成一片灰底代码；
9 月 8 日，配图里的 icon 压住了文字、卡片溢出边框，老板一眼看出来，我在生成脚本里却看不出来。

这三类事故有一个共同点：它们都不是「写错」，而是「没被检查出来」。AI 把内容生产的产能放大了十倍，检查产能没跟上，坏内容就会像无审查合并一样，悄悄沉到读者面前才爆。

把 review 从「人盯」编译成「闸」，内容才敢批量产。 这是我被返工教育了 276 天后最想说的一句话。

四、把 review 编译成闸：0 号闸门怎么长出来的

我们的答案不是更长的检查清单，是把清单编译成脚本，再嵌进推不动的地方。

第一版门禁其实是文档：我把写作规则写成十几条注意事项，每次发文前「记得检查」。结果和所有靠自觉的规则一样——记得的时候有用，忙起来就忘。真正让它起作用的，是把它从提示词里搬进代码里。

现在每个写作任务结束后，跑的是这一道命令：

python3 /root/hermes-harness/scripts/writing_gates.py article-ta-review-gate.md
# expect: 17/17 PASS -> 可推送

而这道命令又被嵌进了推送脚本的开头，成了 0 号闸门——想推文章？脚本先替你跑一遍门禁，不过就 exit，物理上绕不过去：

import subprocess, sys
gate = subprocess.run(
    ["python3", "/root/hermes-harness/scripts/writing_gates.py", md_path],
    capture_output=True, text=True, timeout=120)
if "PASS" not in gate.stdout:  # gate zero: no pass, no publish      # gate zero: no pass, no publish
    print("blocked: writing gates failed")
    sys.exit(1)

门禁不是一次设计出来的，是从事故里一条一条长出来的。每次出事故，复盘完就把根因编译成一条新检查：标题错配的事故后，立了标题-正文一致性自查；围栏吞签名的事故后，立了代码块围栏配平检查；配图压字的事故后，立了配图布局像素验证——每张图生成完都要跑一遍布局验证器，机器直接量右缘距、底缘距、有没有压到结论条。根因进 error-ledger（症状、根因、解法、状态四段式，74 条只增不删），检查项进门禁，门禁从 0 长到 17。每晚 21:00 的复盘任务再把当天新错误回灌一遍，闭环不靠记忆，靠定时任务。

五、同构落地：merge gate 和 publishing gate，同一套逻辑

把代码仓库和内容工厂放在一起看，结构几乎是镜像的：

代码靠 merge gate 把返工挡在合并前，内容靠 publishing gate 把翻车挡在发布前。两个闸门做的事完全一样：能写成规则的，机器先拦；机器拦不了的，才留给人的判断。

边界也得说清楚。我们的 17 项门禁拦得住格式、拦得住布局、拦得住围栏，但拦不住「标题和正文是不是同一件事」这种语义问题——它靠的是写完后的自查协议和发布前的人工终审。所以这道闸不是要取代人，是要把人从「看格式」里解放出来，集中精力看机器看不出来的东西。

真正的 review 不是看一遍，是让坏东西根本过不了闸。 判断依然稀缺，只是稀缺资源终于被用在了它该用的地方。

结尾

861% 的返工不会自己消失，4 倍代码换 12% 价值的故事，也会在内容圈重演一遍——AI 让每个人的产出都变多了，多到没人看得过来。

谁先把判断编译进管道，谁就拿到这个时代的复利：机器负责快，人负责对。

此刻的你

一句话读懂：生成变便宜之后，判断才是稀缺品；把 review 从「人盯」编译成「闸」——机器先拦能写成规则的错，人只看机器看不出来的语义，内容才敢批量产。

三个认知

返工才是生成时代的真实账单：GitClear 4 倍代码只换 12% 价值、Faros 返工量 +861%，写的速度不等于交付的速度；AI 放大产能的同时放大检查缺口。
审查失真比写得差更危险：不是没人 review，是 review 在流程里没有位置——把检查压给人最稀缺的注意力，结果就是「看是看了，什么都没看出来」。
门禁要从事故里长出来：规则写在提示词里等于没写；每次事故把根因编译成一条可脚本验证的检查，嵌进推不动的地方，门禁才会从 0 长到 17。

你应该带走的真正价值

价值一（技术人/团队场景）：拿到「检查分层」的落地判据——能写成规则的给机器（lint、单测、格式、布局像素验证），写不成规则的留给人；把 CI merge gate 的逻辑原样搬进任何 AI 产出管道。
价值二（内容生产场景）：一套可直接照抄的 0 号闸门写法——推送脚本开头先跑门禁，不过就 exit；加粗的检查项清单可以是你自己的 5 条、10 条，从第一个真实事故开始长。
价值三（长期机制场景）：错误账本四段式（症状/根因/解法/状态）+ 每晚定时回灌，不需要新工具，一本 append-only 账本加一个 cron，就能让「今晚的错误明天变成检查项」。

三步行动

步骤	动作	验证
1	盘点你最近三个月被返工最多的 3 类错误，给每类写一条能脚本验证的检查	每条检查都能用一条命令跑出 PASS/FAIL
2	把检查嵌进你的发布/合并入口，不通过就 exit	绕过检查直接发布，被物理拦截一次
3	建一本四段式错误账本，挂一个每晚复盘定时任务	一个月后账本 ≥10 条，门禁 ≥5 项

金句：机器负责快，人负责对——谁先把判断编译进管道，谁就不用在下班后替 AI 返工。

魏无记