夜雨聆风团队用 AI 写代码，真正要看的不是席位数
一个团队开始上线 AI 编程工具时，最容易看的指标通常是这些：
开通了多少人。
用了多少 token。
生成了多少代码。
合并了多少 PR。
这些指标不是完全没用。
但它们很容易让人过早下结论。
因为“开通了工具”和“工具真的改变了工作”，中间隔着很长一段距离。
席位数只能说明工具被打开了
很多 AI coding rollout 的第一步，是给一批开发者开通 Claude Code、GitHub Copilot CLI、Cursor，或者类似工具。
这一步当然重要。
没有 access，就没有使用。
但 access 只能说明公司买了席位、开了权限、允许大家尝试。
它还不能回答更关键的问题：
谁在第一周之后还继续使用？
他们用它做什么任务？
review 负担是下降了，还是转移到了别人身上？
产出的代码更容易维护，还是只是更多？
成本有没有花在值得的任务上？
这些问题，才更接近 rollout 是否真的有效。
最近有一个值得看的研究
2026 年 7 月 1 日，一篇 arXiv 论文研究了 Microsoft 在 2026 年早期上线 Claude Code 和 GitHub Copilot CLI 的情况。
这篇研究比较有价值的地方，不是简单说“AI 让开发更快”，而是尝试看更具体的问题：
谁第一次使用？
谁后面继续使用？
使用是怎么在团队里扩散的？
输出有没有变化？
研究里有一个很容易被拿去做标题的数字：
采用这些命令行 AI coding agents 的工程师，合并的 PR 大约比反事实估计多 24%。
这个数字很有意思。
但论文也很明确地提醒：合并 PR 只是输出的代理指标，不等于它创造的价值。
这句话其实比那个 24% 更重要。
因为很多团队真正容易误判的地方就在这里。
PR 变多，不一定代表业务价值变多。
代码变多，不一定代表系统变好。
开发者觉得快了，不一定代表团队整体交付变稳了。
更好的问题是：哪些工作真的变了
我觉得团队评估 AI 编程工具时，可以少看一点“有没有用”，多看一点“用在什么地方才有用”。
比如：
它是不是帮助开发者更快读懂陌生代码？
它是不是帮忙找到修改位置，而不是直接生成一大段没人想 review 的代码？
它是不是帮忙补测试、整理边界情况、做重复迁移？
它是不是让 senior engineer 更快完成可控工作？
还是说，它让不理解代码的人也能提交改动，然后把 review 和修复负担转给工程团队？
这几种情况都可以叫“用了 AI coding agent”。
但它们不是同一种 adoption。
前者可能是真正的杠杆。
后者可能只是把问题往后推。
成本控制也不能只靠一刀切
另一个容易出现的误判，是成本。
AI coding agent 的 token、订阅和 API 成本确实可能上升很快。
所以公司开始限额、降级、限制模型使用，这都可以理解。
问题是，如果没有任务级证据，成本控制很容易变成粗暴削减。
低价值的生成应该被限制。
但高价值的代码阅读、迁移、排错、测试设计、复杂变更前的探索，也可能一起被砍掉。
这就像没有看清哪条生产线在产出好东西，只是因为电费上来了，就把所有机器都关小。
预算安全了，不代表工作变好了。
更合理的做法，是把成本和任务价值连起来看。
哪些任务值得用更强模型？
哪些任务用便宜模型或 autocomplete 就够？
哪些任务应该让 AI 做分析和草稿，但不能直接交付？
哪些任务现在根本不该交给 Agent？
这比单纯看 token 总量更接近管理问题本身。
一个轻量的 rollout 证据框架
我不认为团队需要一套很重的 AI 生产力仪表盘。
很多仪表盘最后会变成新的形式主义。
但至少应该有几个轻量证据：
第一，持续使用。
不是谁第一周试了，而是谁在新鲜感过去后还会回来用。
第二，任务匹配。
不是“用了 AI”，而是用在读代码、写测试、迁移、排错、review 前检查，还是直接生成大段改动。
第三，review 负担。
AI 生成更多代码以后，review 时间是减少了，还是增加了？
第四，质量和维护。
合并后的代码，后续是不是更容易改、更容易解释、更少返工？
第五，成本和价值。
花掉的模型预算，能不能对应到团队愿意继续保留的任务结果？
这五个问题不需要每天汇报。
但如果一个团队完全回答不了，就不应该太快说 rollout 成功。
最后真正要看的是什么
AI 编程工具的组织采用，不能只看采购动作。
也不能只看使用量。
更不能只看 PR 数量。
它真正改变的是工作生产方式：
谁可以尝试技术改动。
谁负责 review。
谁理解最后的代码。
哪些任务值得交给 Agent。
哪些结果可以被团队继续维护。
所以更好的 rollout 问题不是：
我们给多少人开通了工具？
而是：
哪些工作真的变好了？
谁在持续使用？
review 和维护成本有没有被看见？
产出的东西，团队愿不愿意负责？
如果这些问题能回答，团队就可以更冷静地决定权限、预算、培训和 guardrails。
如果回答不了，就只是在猜。
AI 编程工具的下一阶段，不会只属于买了最多席位的团队。
更可能属于那些能看清楚一件事的团队：
Agent 到底改变了真实工作，还是只是制造了更多看起来像工作的产物。
参考
arXiv: Adoption and Impact of Command-Line AI Coding Agents arXiv: Overeager Coding Agents