团队里每个人每天都在用智能体写代码、跑实验、查问题。问「它们有没有让我们更快」，答案永远是「有」。这个答案没有信息量。真正的问题是：快在哪一段，慢在哪一段，我怎么知道。
代码量是最容易测、也最容易骗人的数字
最先能拿到的指标是产出：多少行代码、多少次提交、多少个实验。这些数字一定在涨，因为智能体最擅长的就是把「写出来」这一步做快。但写出来不等于做对，做对不等于做了值得做的事。一个团队如果只看这条曲线，会把自己带到一个每天都很忙、方向却越来越模糊的地方。
我后来的做法是先不问「多少」，先问「什么」。
先给工作分类，再谈加速
我借了一套公开的分类，把研发工作拆成六段：决定做什么，设计方案，写代码和数据，跑起来，分析结果，沟通结论。然后把团队交给智能体的任务逐条归进去。
分完立刻能看出两件事。第一，智能体的产出压倒性地集中在「写代码」和「跑起来」，尤其是排查基础设施问题。以前要等人帮忙的事，现在自己就能问出来。第二，「决定做什么」和「设计方案」几乎没有交给智能体，也不该交。加速的是执行，不是判断。
这个结论不新鲜，但把它量出来之后，团队讨论的方式变了。再有人说「让智能体来做」，第一个问题变成「这件事属于哪一段」。属于后四段的，放心交；属于前两段的，先想清楚谁负责。
干预率，才是真正的信号
第二个有用的量是干预率：一件任务从交出去到可用，中途人插手了几次。
它比成功率诚实。成功率会随着任务变简单而上涨，干预率不会。一件跨越几个小时的任务，就算最后成功了，中途也大概率被人拉回来过一两次。这些干预就是系统能力的边界，边界在哪里，比边界内跑得多快重要。
我要求团队把干预记下来，不是为了打分，而是为了看模式。同一类任务反复在同一个地方需要人插手，说明那里缺一条约束，或者缺一个工具。这时候该做的不是继续插手，而是把插手的动作变成检查器或者工具，让下一次不需要人。这和我在另一篇里写的「报告不是终点」是同一件事。
测量本身要克制
有两个陷阱要避开。
一是把测量做成考核。一旦干预率和绩效挂钩，人就会少记干预，数字立刻失真。它只能是团队看自己的镜子，不能是管人的尺子。
二是把容易测的当成重要的。产出量最容易测，判断质量最难测，而后者才决定团队走向哪里。一套只测前者的仪表盘，会系统性地把资源引向看起来最忙的方向。
所以我现在的仪表盘只有三行：任务按六段的分布，各段的干预率，以及哪些干预已经变成了检查器。第三行是最重要的，它记录的是团队在变强，还是在原地重复。
结论
智能体有没有加速团队，不能靠感觉回答，也不能靠代码量回答。先把工作分类，再看每一类里人插手了几次，最后看这些插手有多少被固化成了系统的一部分。三步做完，答案就不再是「有」，而是一张能指导下一步投入的地图。