提交涨了三成，关闭的需求没多一件

季度复盘会上，工程负责人放了两张图。第一张是代码提交数，从引入编码智能体的那个月开始往上翘，到季度末涨了三成。第二张是需求看板，已关闭需求的曲线平得像一把尺子。会议室安静了几秒，没有人说这不可能，因为两张图都是真的。

这种沉默在 2026 年下半年很常见。工具供应商给出的提速数字是真的，工程师的体感也是真的，可是到季度末结算，交付出去的东西没有变多。原因不在某个环节失灵，而在于两件被当成同一件事的事被分开了看：写代码的速度，和一个功能真正上线的速度。

十月底一份用真实工程数据做的研究，把这个裂缝量化了。它的结论值得每个准备续约 AI 编码工具的技术负责人读一遍，因为结论直接改写了这笔钱该怎么算。

数据说的是同一件事

哈佛的两位研究者 Fiona Chen 与 James Stratton 用 Jellyfish 的团队产出数据做了一次观察研究，覆盖 2021 年到 2026 年 3 月、700 多家软件公司、超过 70 万名员工、约 3 亿条工作事件，包括提交、合并请求和 Jira 里的需求记录。他们用双重差分法比较了各家公司在引入编码助手与编码智能体前后的变化。

代码端的数字很陡。引入编码智能体之后，代码总行数平均上升 30%，提交数上升 20%，合并请求数上升 23%。任何一个盯仪表盘的人看到这三条曲线都会认为工具成功落地了。

需求端的数字是平的。Jira 里 issue 与 epic 的关闭率没有统计显著的变化。研究者还检查了一个很容易被忽略的解释：会不会是团队把需求拆小了，用更多的关闭数掩盖工作量不变？他们的答案是排除了这一可能，被关闭需求的规模与复杂度在引入工具前后没有结构性漂移。

下游的数字则明显变重。代码评审的平均时长上升，合并请求更可能需要返工，评审人留下的评论更多。研究者把这组结果概括为一句话：编码阶段省下的时间，被生产流程下游的约束吸收了。

需要说清这份研究能撑住什么。它是观察性研究，公司何时引入工具由自己决定，不是随机分配，双重差分能处理一部分混杂，但处理不掉同期发生的其他变化，比如组织调整或者需求结构变化。所以它的结论适合用来校准你自己的账，不适合用来断言整个行业的生产率。厂商公布的提速数字与它并不矛盾，两者量的是不同的东西：厂商量一个任务从开始到完成，这份研究量一个组织一个季度的交付。

一个需求关闭要三样东西

要理解为什么写得更快不等于交得更多，得把一次关闭拆到底。一个需求从打开到关闭，中间需要三样东西同时成立。

第一样是验收条件：怎么算做对了，由谁在什么条件下签收。它通常写在需求描述里，写得越模糊，关闭那一刻的争议越大。

第二样是证据：到哪里能看到它对。可能是一次通过的测试、一段录屏、一张对账表、一份第三方回执。证据的形态决定了验证这件事要花多少时间。

第三样是责任人：如果错了，谁的名字在记录上。这一样没有技术替代品，因为它的本质是把后果绑到一个人身上。

智能体把第一样和第二样起草得极快。它能读代码库写出验收条件，能跑测试生成证据，能在合并请求里补齐上下文。第三样它做不了，因为责任不能委托给一个可以随时重跑的东西。

于是组织里真正增加的东西，是待验收的面积。一个合并请求从 40 行变成 400 行，评审人要读的量涨了十倍，而他能给出的责任判断并没有变快。这就是研究里那条评审时长曲线的来源：它不是人的效率下降，是被要求负责的面积扩张了。

待验收面积是怎么涨起来的

把这条链拆成五步，就能看清为什么它必然发生，而不是某家公司管理不善。

第一步，生成成本下降，产出量上升。第二步，待验收的条目在队列里堆积。第三步，为了不让队列爆炸，抽样比例被下调，或者评审时长被压缩。第四步，单位评审注意力下降，漏过的缺陷与不合规改动比例上升。第五步，返工与线上修复把省下来的工时吃回去，账面交付量回到原点。

这条链有个残酷的性质：前两步是好事，报表上看得见；后三步是坏事，报表上看不见。所以组织会持续处在一个自我感觉良好的状态里，直到某一次线上事故把第五步暴露出来。

还有一个放大器。智能体写出来的代码风格统一、注释齐全、测试覆盖看起来完整，这些特征会让评审人降低警觉。人的注意力是按信号分配的，一份看起来规整的合并请求，被认真读的概率低于一份明显粗糙的。研究里评审评论变多，一部分原因就在这里：读得越细，发现的问题越多，而发现问题的成本落在同一个人身上。

换成关闭口径，这笔账怎么算

把度量换掉，只需要两个数：一段时间内关闭了多少需求，以及每个需求值多少钱。剩下的都是成本项。

月度增量价值等于关闭需求数乘以单件业务价值。总成本等于推理与工具订阅费，加上评审工时乘以全载人力成本，加上返工工时乘以同一系数。

举一个能算出来的例子。一个十人团队，原来每月关闭 40 个需求，单件业务价值按 8 万元计。引入智能体后，工具与推理每月 3 万元，评审工时从 120 小时涨到 210 小时，按全载每小时 400 元计是 8.4 万元，返工 60 小时是 2.4 万元，三项合计 13.8 万元。

如果关闭数从 40 涨到 50，增量价值是 80 万元，成本 13.8 万元，这笔投入划算得毫无争议。如果关闭数还是 40，增量价值是 0，成本是净新增的 13.8 万元。同一套工具，同一批人，两种结论，差别只在有没有量关闭数。

这个算例真正的用处，是它把讨论的顺序扭过来了。多数团队的顺序是先看工具演示、再算 token 预算、最后才问交付有没有变。正确的顺序是先取关闭数，如果它不动，工具再便宜也不该扩大采购，因为你在为一个不产生交付的环节付费。

把验收条件做成机器可判的，只有三种形态：接口契约，输入输出对得上；对账样本，结果跟一个独立来源对得上；可回放日志，过程能被重放核对。这三样写进需求单，关闭就能自动发生。写不进去，通常说明这个需求本身还没有想清楚，先别开工。

还有一个容易漏的成本项：评审工时的价格上涨是隐性的。资深工程师的时间被大量占用来读别人的产出，这部分时间原本用于架构决策或者带人。账面上它不出现，因为它没有被记在任何一张工单里。把它按全载成本折进去，很多看起来划算的项目会立刻变得平庸。

什么时候提交量是对的指标

说清边界，否则这套算法会变成反对一切工具的理由。有四类工作，提交量与交付量高度一致，用提交量考核没有问题。

原型与探索。目的是尽快看到可能性，没有验收条件可言，写出来的东西本来就会被丢掉。内部脚本与一次性数据处理。用完即弃，验收成本接近于零。文档与知识整理。正确性由读者当场判断，不需要额外证据链。还有重构中那些行为不变的部分，测试通过就是全部证据。

反过来，四类工作里提交量会系统性高估交付。受监管的生产变更，任何一行改动都要能追溯到审批。跨团队接口，验收依赖另一方的时间表。数据迁移，错误不报错只是数字错。面向客户的功能，验收标准由市场而不是由代码决定。

还有一个容易被忽略的边界。同一个团队内部，验收成本的差异可以很大。运维脚本和客户功能放在同一个产能指标下考核，结果一定是脚本越写越多、功能越交越少，因为脚本好过关。指标统一的地方，工作会向低验收成本的一端漂移。

判断规则很简单：问一句验收要花多久。如果验收比生产还贵，那么生产提速没有意义，该优化的是验收，而不是买更快的模型。

我们自己的账

我们自己的产线就是这个逻辑的极端版本，所以可以拿出来当对照，而不是当范例。

网站上的中英文文章由智能体起草，但一篇草稿要变成线上内容，必须过四道机器门：中文正文不少于 3,300 字、英文不少于 1,500 词；结构化定义与问答组件齐全；文章校验脚本零错误；类型检查与完整构建通过，再由持续集成跑一遍。任何一道没过，产出就是零，不进任何统计。到今天线上是 349 篇成对文章，这个数字是过关数，不是生成数。生成的草稿数量是它的好几倍，我们没有把它们算进产能，因为读者看不到的东西不算交付。

内部任务队列用的是同一套账。到今天累计 3,173 张任务单，其中 2,975 张已关闭，24 张还在挂着。过去三十天关闭 254 张，平均 1.8 天关一张。我们报产量只报关闭数，因为一旦按创建数报，系统会迅速学会生产没人需要的东西，而这在数据上看起来很繁荣。

这不是最佳实践宣称，是我们自己踩过之后的记账方式。它带来的一个副作用值得说：因为它只认关闭，起草环节的产出被刻意压低了估值，团队不会为了刷数量去写注定被拒的草稿。

我们的判断

我们的判断是，AI 编码工具的投资回报问题，眼下主要不是工具问题，是记账问题。组织把产能记在了最便宜、最容易上涨的那一端，也就是提交，于是每一轮工具升级都会呈现为一次看起来真实的增长。真正的约束在完成定义上：一个需求算不算关，取决于验收条件有没有写死、证据在不在、责任人签不签。这三样，模型替不了你。

这也解释了一个反复出现的现象：同一款工具，有的团队交付翻倍，有的团队交付不变。差别通常不在提示词水平，在于前者的验收条件是机器可判的，后者的验收条件要开会定。前者把模型接进了一条能自动关闭的流水线，后者把模型接进了一个需要人点头的会议室。

三个动作可以本周做完。第一，取四个数放进一张表：过去六个季度的提交数、合并请求数、需求关闭数、平均关闭周期。哪个在动，一眼能看出来。第二，给试点团队的每个需求写死验收条件与证据位置，并把 AI 生成从完成定义里删掉，生成只是过程，不是交付。第三，把评审工时按全载成本计入 AI 预算，否则你会同时得到一个漂亮的回报率和一个变慢的组织。

留给买家的问题是：在你的仪表盘上，AI 的产出记在哪一栏？如果答案是一提交、行数或者对话次数，那么下一次工具升级，你会再次看到增长，而组织什么也没有多拿到。

参考来源

Ars Technica, AI coding agents generate more code, but not more software（2026 年 10 月，含代码行数 30%、提交 20%、合并请求 23% 与需求关闭率无显著变化的数据）

InfoQ, Study Finds AI-generated Code Fails to Boost Productivity Due to Downstream Bottlenecks（2026 年 10 月，研究口径与样本规模）

Definition of done, Wikipedia（本文使用的完成定义概念）