Signal #14：别只看出码率了，AI Coding 的指标正在变

如果一个团队的 AI 生成代码占比越来越高，出码率也在上升，但 PR 吞吐量没有明显变化，返工还是很多，验证和 review 压力也没降下来，那你很难说：研发效率真的因为 AI 提升了。

这也是我最近越来越强烈的一个感觉：
AI Coding 的评价口径，正在从“AI 写了多少代码”，转向“AI 承接了多少真实研发工作”。

过去一段时间，很多团队衡量 AI Coding，最常用的还是代码层指标：AI 生成代码占比、代码采纳率、活跃用户数、出码率提升了多少。

这些指标仍然有价值。它们回答的是一个很基础的问题：AI 有没有真的进入开发过程。

但问题在于，今天很多团队使用 AI IDE 或 Coding Agent，早就不只是“让它补几行代码”了。更常见的使用方式，是通过对话让它修改文件、实现需求、修 bug、补测试、处理 review feedback，甚至把一段更完整的任务交给它。

一旦使用方式变了，评价方式就会开始滞后。

如果我们还主要用代码层指标去理解 AI 的价值，往往只能看到“它参与了写代码”，却不一定能看到“它有没有真正改变研发流程”。

这周 GitHub 在官方更新《Copilot usage metrics API adds cohorts for AI adoption》里，新增了 ai_adoption_phase。

它不再只是统计谁在用 Copilot，而是开始把用户分成几个阶段：

这个变化值得注意。

因为它背后问的，已经不是“你有没有用 AI”，而是：

你还停留在代码生成阶段，还是已经开始让 Agent 进入任务执行、多入口协作，甚至更接近真实研发流程的阶段？

更关键的是，GitHub 这套分层背后对应的统计项，也不只是代码生成和接受情况，还包括 PR created、merged、reviewed，以及 median time-to-merge 这类更接近研发流程的指标。

这说明平台方也开始意识到：
AI Coding 的成熟度，不能只看“生成了多少代码”，还要看它到底进入了哪一种工作方式。

换句话说，评价对象正在从“代码生成工具的使用情况”，迁移到“Agent 对研发流程的参与程度”。

如果说 GitHub 代表的是“评价口径的变化”，那另一类信号则更直接：一些平台已经开始用研发产出来表达 Agent 的价值，而不是只说它写了多少代码。

比如 Cursor 这周发布的客户案例《Faire doubles PR throughput with Cursor Cloud Agents》。

它强调的不是代码采纳率，而是：

这套表达方式已经很不一样了。

它不再是“AI 帮开发者多写了一些代码”，而是：
AI 开始承接任务、推进 PR、压缩迁移成本，并直接影响工程产出。

OpenAI 这周的案例《How Ramp engineers accelerate code review with Codex》也有类似意味。Ramp 用 Codex 加速 code review，让工程师更快获得有实质内容的 PR feedback。这里 AI 的价值也不是“又写了多少代码”，而是进入了 review 和协作环节，开始影响研发流转速度。

所以我觉得，一个很清晰的变化正在出现：

AI Coding 的价值衡量，正在从“代码生成参与度”，转向“任务承接能力”和“流程推进能力”。

“出码率”不是没用。它依然是一个重要指标，尤其是在 AI 落地早期。

因为在那个阶段，团队首先要回答的是：大家到底有没有把 AI 用起来？AI 有没有实际参与代码生产？

但问题是，出码率天生更接近“代码生产”这一层，而不是“研发交付”这一层。

代码是研发流程的一部分，不是全部。

一个任务最终能不能高质量交付，除了生成代码，还取决于很多环节：需求理解是不是准确，上下文有没有找对，修改范围是否可控，测试是否补全，验证是否通过，review feedback 能不能被吸收，最终是否能稳定合并。

所以你会看到一种越来越常见的情况：

问题往往不在“AI 没写代码”，而在于：
它虽然参与了代码生产，却还没有稳定进入任务推进和流程闭环。

这也是为什么，只看出码率，开始不够了。

如果沿着这个方向看，我觉得下一阶段 AI Coding 的指标，可能会越来越清晰地分成三层。

比如：

这一层回答的是：AI 有没有被用起来，以及它是否参与了代码生产。

比如：

这一层回答的是：AI 有没有进入真实研发任务。

比如：

这一层回答的是：AI 有没有真正改善研发系统。

这三层指标的含义完全不同。

代码层指标看的是“参与了多少”，
任务层指标看的是“承接了多少”，
结果层指标看的是“最终改善了什么”。

很多团队现在的状态，其实不是没有指标，而是指标还主要停留在第一层。

这件事放到企业研发提效里，其实更明显。

在 AI 落地早期，看活跃用户数、代码采纳率、出码率，很正常。因为第一步确实是让工具先被用起来。

但如果 AI 真的开始进入研发流程，那么企业最终关心的问题一定会变成：

这些问题，比“AI 生成了多少代码”更接近研发效率本身。

指标迁移之后，另一个问题也会随之出现：当 AI 不再只是个人工具，而开始进入团队工作流，企业就必须关心它是否可控、可治理。比如 Vercel 这周发布的《Team-wide provider allowlist on AI Gateway》这样的更新也值得留意。平台方一边在补 Agent 的能力，一边也在补治理、边界和组织级使用方式。因为一旦 AI 不再只是个人工具，而开始进入团队工作流，企业最终一定会要求它的价值，能够落到更接近流程和结果的指标上。

AI Coding 的早期问题，是 AI 能不能写代码。
后来问题变成，AI 写出来的代码能不能被接受。
而现在，一个新的问题正在变得更重要：

AI 能不能稳定承接真实研发工作，并最终转化成可验证的工程产出。

所以，出码率仍然重要，但它已经不是终点。下一阶段，企业更需要关注的，可能是任务承接率、PR 吞吐量、返工轮次、验证通过率、人工介入次数，以及从需求到交付的周期变化。

当指标开始从代码层走向任务层、结果层时，AI Coding 才算真正从一个“会写代码的工具”，进入企业研发系统。