这两天你要是只在短视频里逛 AI 编程，会产生一种错觉：写代码这件事已经"解决"了，剩下的人只负责许愿。但 10 月 1 日到 5 日这几天，B 站好几个搬运 AI Engineer Paris 2026 演讲的 UP 主，几乎在同一时间把另一面端了上来：这不是观点之争，是数据。
先看这组被反复引用的遥测。B 站 @量子菠萝_ 在 10 月 4 日的视频里整理了基于 400 余家企业、约 20 万名工程师真实遥测数据的分析：部署频率显著上升，但变更失败率波动加剧；PR 平均行数从 44 行激增至 72 行；而最扎眼的一个数字是——团队 PR 吞吐量只增长了 7.7%。同一天，同一个 UP 主另一期视频里，Arize AI 开发者关系负责人 Laurie Voss 给了另一个口径：AI 让代码产出暴增 7 倍，但交付只涨了 30%。哔哩哔哩哔哩哔哩
这两个数不是一个统计口径，别急着拿来互相打架："产出 7 倍"说的是生成侧,"吞吐量 7.7%"说的是合并侧。但放在一起看，方向完全一致——AI 编程时代，写代码不再是瓶颈，"敢不敢合"才是。
瓶颈到底卡在哪：400 行的悬崖和会说谎的绿灯
人工审查有个残酷的生理限制。Laurie Voss 在演讲里引的研究说得很直白：人工审查超过 400 行代码后，缺陷发现率会断崖式下跌。而 AI 生成的 PR 呢？“动辄上万行”。也就是说，我们默认的那道安全网——“总有人在看代码”——在数学上已经失效了。哔哩哔哩
更麻烦的是，你以为的自动化防线也会说谎。Matt Pocock 在 AI Engineer Paris 2026 的演讲《修复 PR 瓶颈》专门讲了"为什么测试全绿仍可能骗人"：重言式测试（assert 的就是实现本身）和"无法失败的测试"，AI 特别擅长批量制造。Cognition 的 FrontierCode 基准也从侧面验证了这一点：模型在代码生成类评测上分数好看，可一旦换成"这个 PR 值不值得合并"这种真实评估，得分骤降 51%。哔哩哔哩
而 400 家企业的数据还揭了一个尴尬的分布：初级工程师 Token 消耗最高，Staff+ 级的资深工程师反而用更少的 Token 实现了同等的省时效果。工具没有拉平能力差距，它把"会不会提要求、会不会验收"的差距放大了。哔哩哔哩
评论区已经吵成四个阵营，但共识恰恰藏在分歧里
这事儿在中文社区不是"未来可能"，是已经天天在发生。小红书 9 月 20 日一条"你们还会仔细看 ai 写的代码吗？“，144 个赞底下挂了 292 条评论，评论比点赞还多一倍——典型的"没人有答案，但人人都想说”。我把知乎、小红书的讨论归了下类，现在是四个阵营：小红书
逐行人工看派。一位做算法的用户在小红书评论区说得直接：“感觉人工不看不行，只靠ai就会变成一坨复杂的粑粑甚至某个不起眼的深处他真的写错了”。小红书
AI 互审派。听起来最美好，实践者自己先泼冷水：“让 ai 互审，就发现 bug 是修不完的，每次修完所有已知 bug，让另外一个 ai 再审，又能发现几个。最后完全看不懂 ai 关于 bug 的介绍”“一直审，一直有新问题”。还有人验证过：“连同 ai 不同会话互审都是乱七八糟。”
测试过了就行派。“能运行，能过测试，其他 AI 能读懂就通过，别整天搞 0bug 这些不切实际的。”——务实，但请回想上面那段"重言式测试"。
验收前置派。这是我认为目前最接近"可复制"的一派。知乎 10 月 5 日一个回答讲接手 AI 代码的三步，值得逐句看：第一步是"边界清单比代码本身更值得先看"，尤其是权限、生产数据、对外调用这三类——AI 最容易"合规地"走过去；第二步把现状固化成可执行断言，用最小用例覆盖正常和异常路径；最后让 AI 逐条解释每个断言为什么成立，“你只做一件事：找它解释不通的地方”。同一天的另一个回答（在甲方做数字化）说得更狠：“先把验收标准写出来，再让AI写实现。AI最擅长的是「给定明确目标后高速产出」，最不擅长判断「这个目标本身对不对」。所以顺序必须反过来。”知乎知乎
数据指向的解法：不是放弃审查，是给审查重新分工
Matt Pocock 的演讲给出了一个三层结构——自动检查、自动审查、人工审查——正好能把上面四个阵营的合理部分装进去。哔哩哔哩
自动检查：最便宜，但会骗人。所以关键不是加不加测试，而是测试必须"可以失败"——写不出能失败的测试，等于给 AI 开了张免检证明。
自动审查：让审查 Agent 独立于实现 Agent，标准只加载给审查方，不让写代码的那个自己给自己打分。极限案例是开源工具 pstack 作者 Lauren Tan（poteto）：她一个月合并 2000 多个 PR，不逐个 review，改用抽样审查——前提是她的检查层和回滚机制足够硬。哔哩哔哩
人工审查：只留给"单向门"（合并后很难撤销的决策）和影响范围大的变更。风险说明、图表、复盘，让每一次人工审查都在给下一次减负，而不是无限重复劳动。哔哩哔哩
一句话总结这个分工：机器的部分交给不会累的，人眼的部分留给最贵的。
不同人怎么用这份数据：三个判断
如果你是重度 vibe coding 的个人开发者：你短期感受不到 7.7%，因为你自己就是审查方，瓶颈还没暴露。但你已经站在悬崖边——项目一旦给别人接手、或者要长期维护，"能跑但没人敢动"就是今天知乎问题区正在上演的剧本。从今天开始把"验收前置"练成习惯：先写接口契约、边界条件、验收命令，再让 AI 写实现。知乎
如果你是 Review 别人 AI 代码的工程师：记住 400 行悬崖。看到巨型 AI PR，第一反应不该是"打开 diff"，而是"要求拆 PR、要求补风险说明"。审查顺序按边界清单来：权限、生产数据、对外调用，先于业务逻辑。
如果你是团队负责人：别再拿"代码产出量"给 AI 工具算 ROI，那是生成侧的虚荣指标。看吞吐量、看变更失败率、看合并周期。另外算成本时留意两个被低估的变量：初级成员的高 Token 消耗（数据已经证实），以及智能体框架本身的开销——36 氪 9 月的实测显示，用同一个模型，不同 Agent 框架的 Token 成本能相差几十倍。同一个"AI 提效"，在不同团队可能是 30% 的交付提升，也可能是 7.7% 的原地踏步，差别不在模型，在你把审查瓶颈解决到了哪一层。36氪
值得继续盯的信号
AI Engineer 大会后续放出的原始报告和数据集（等更多中文解读落地，交叉验证 7.7% 的口径）；
FrontierCode 这类"是否值得合并"基准的新版本——它第一次把"审"而不是"写"放进了评测；
主流工具是否开始内置 PR 风险说明、自动拆分巨型 PR 的功能——如果有了，说明行业正式承认审查是瓶颈。
代码写得快从来不是新闻了。今年真正的分水岭是：你的团队里，谁在决定"哪些代码值得被合进去"。你现在是靠人肉硬扛，还是已经搭起了三层闸门？评论区聊聊你团队的真实吞吐量变化——比演讲里的 7.7% 更高还是更低，这组民间样本可能比数据更有意思。
