多数网站不允许被内嵌预览——若下方空白或出现错误页，请改用上方「复制网址」或「开新分页 ↗」。
灯塔文摘 · LIGHTHOUSE DIGEST
*——AI／Agentic 时代的工程产出衡量，错在哪，以及小团队该怎么做*
2025 年，METR 做了一件简单的事：找 16 位资深开源开发者，在他们自己平均待了五年的成熟项目里，随机指派 246 个任务——一半可以用 AI 工具，一半不行。
开工前，开发者预测 AI 会让他们快 24%。做完之后，他们回想，觉得自己快了 20%。
实测结果是慢了 19%。
感觉与事实之间差了将近 40 个百分点。而这些人不是新手，是在自己最熟的代码里工作的资深工程师。
这个研究后来被过度引用，也被过度反驳。它的边界很清楚：样本只有 16 人、工具是 2025 年初的版本、任务都在成熟程序库里。它不能证明「AI 让人变慢」。METR 自己在 2026 年 2 月宣布要改实验设计，因为新一轮出现了严重的自我选择偏误——太多开发者拒绝参加「不能用 AI」的那一组。
但它证明了另一件更麻烦的事：在 AI 辅助的工作里，人对自己速度的判断是不可靠的。
而几乎所有关于「工程师产出」的讨论，都建立在某种形式的速度直觉上。
当我们说「AI 时代不能再用工时衡量工程师」，这句话对。用投入时数当个人绩效分数，早就被业界丢进垃圾桶——2023 年 McKinsey 发表「你可以衡量开发者生产力」之后，Kent Beck 与 Gergely Orosz 联手写了一篇逐字反驳，称那套框架「错得离谱、注定反噬」。SPACE 框架（GitHub、微软、维多利亚大学，2021）更早就破除了三个迷思：生产力不等于活动量、生产力不只关乎个人、单一指标永远不够。
问题出在替代方案。
当工时被拿掉，最直觉的填补是缺陷相关的指标：遇到几个 bug、多快修好、多快发现走错路。这听起来比工时「实质」得多——工时衡量投入，bug 衡量结果。
但它更糟，而且糟在三个不同的层次。
第一，缺陷数与能力没有稳定关系，有时甚至反向。 GitClear 分析了 2.11 亿行代码变更（2020–2024，涵盖 Google、微软、Meta 等项目），发现重构码的占比从 2020 年的约 25% 掉到 2024 年的不到 10%，复制粘贴的代码首度超过搬移的代码，重复的代码区块在 2024 年增加约八倍，而「两周内被改掉或回退」的churn 较 AI 普及前约翻倍。这是一个结构性的结果，不是个别工程师能力差。做探索性工作的人、碰新颖问题的人、写得多的人，bug 本来就多。
第二，它会被立刻操弄。 这不是理论。文献里的具体案例包括：把「开启中的 bug 数」当指标，导致工程师开始草率关票；把「关闭的 bug 数」当目标，导致一张票被拆成五张；把测试覆盖率当目标，导致大量不验证任何有意义行为的测试。Goodhart 法则在工程指标上不是隐喻，是每次都会发生的事。
第三，也是最关键的：在 agent 大量参与的项目里，bug 已经无法归属于人。 当三成到七成的代码由模型生成，「这个 bug 是谁的」这个问题失去了意义。版本控制的足迹不再支撑任何关于理解程度的推论。
所以 DORA 官网明文列出反模式：这些指标是给应用或服务层级用的，不要做跨团队比较，不要设成目标。DX 的 Core 4即使把「每位工程师的 diff 数」纳入，也明确声明不在个人层级追踪、必须用开发者体验指数对冲、且不得挂勾奖励。
这里是我认为多数讨论没有走到的地方。
前 OpenAI 研究长 Bob McGrew 在描述 agentic 软件工程能做什么时说得很直白：修一个 bug、做一次重构——这类工作需要的品味相对少，而且结果明确。
把这句话和上面的指标问题并置，会得到一个不舒服的结论：
我们想拿来衡量人的那些东西——bug 数、修复速度、缺陷率——描述的正是 agent 已经做得不错、而且会越来越好的那一半工作。
那另一半是什么？
Anthropic 在谈 agent evals 时给了一个很好的答案：eval 的价值在于「迫使产品团队明确定义什么叫成功」。两位工程师读同一份规格，对边界情况会有不同解读；eval 套件消解这个歧义。Thoughtworks 的 Birgitta Böckeler 从另一个方向指到同一点：AI 时代的高价值工作是设计「harness」——指引加上传感器——并守住可维护性。
也就是说，人的差异落在：问题定义的品质、上下文工程、eval 设计，以及判断哪些决策是不可逆的。
这四样没有一样会出现在 DORA 的四个指标里。
还有一个更基本的问题，而它几乎不被提起。
DORA、SPACE、DX Core 4 都很好。但它们的数据要从 CI/CD 管线、事件追踪系统、部署遥测、工单系统里捞出来，而且需要足够的样本数才有统计意义。
台湾一家八人的设计工程公司，这些一项都没有。一家精品顾问公司没有。一个带着 agent 群工作的独立开发者没有。
而这些不是边缘案例——在 AI 大幅降低了「一个人能做多少事」的门槛之后，世界上有大量的软件与系统工作正在这个信封之外发生。
对他们来说，主流的量测文献不只是用不上，而是会误导。强行套用一个为三百人工程组织设计的框架到八个人身上，得到的数字没有意义，但看起来很有意义——这比没有数字更危险。
那该量什么？
我的答案是四个指标，全部可以用试算表加上既有工具收集，不需要任何遥测基础设施：
一、每周可展示的可运作成果数。 取代部署频率。连续两周为零，就是有问题。
二、重工率。 交付后被打回、返修，或上线七天内需要修正的比例。这是小公司版的变更失败率，用人工标记就能做。
三、客户回报问题的趋势。 不看绝对值，看趋势，特别看「同一个问题重复回报」——那是根因未解的信号。
四、采用率与可追溯性。 目标用户里有多少人真的在用，以及系统的回答能不能追溯到来源。
第四项是四个里面最重要的，理由值得说清楚。在 AI 导入项目里，采用率几乎是投资报酬的最大杠杆——40% 采用率与 85% 采用率之间，净现值可以差三到四倍。而采用率下滑最常见的原因不是功能不好，是用户无法确认答案从哪来，于是恢复手动核对。这个模式很好认：导入后前两周使用量冲高，然后掉下来。
最后一块，给做 AI 导入、agent 建置、知识系统部署的人。
各家机构对 AI 项目失败率的估计方法不同、数字不一，但根因的诊断高度一致。RAND 访谈了 65 名工程师后把首要原因写得很清楚：业界关系人经常误解或误传「要用 AI 解决的是什么问题」，导致部署出来的模型被优化到错误的指标上，或根本不符合整体业务流程。Gartner 预测到 2027 年底会有超过四成的 agentic AI 项目被取消，理由是成本失控、商业价值不明、风险控制不足。MIT 的 Project NANDA 研究则发现，只有约 5% 的集成型 AI 试点真的产出数百万等级的价值，绝大多数没有可衡量的损益影响。
翻译成一句话：失败的不是技术，是没有人在开始之前说清楚成功长什么样。
OpenAI 在其 Forward Deployed Engineering 的职缺描述里，把这件事写得比任何顾问方法论都具体：设置影响假设、基准线与 KPI，运行部署前后的量测，并向高层赞助者回报。Palantir 对其 Delta 工程师的定义同样直接——他们以「对客户目标的影响」衡量成功。
所以一份 AI 部署的成功契约，至少要有这几样：用客户的话写的问题陈述；部署前的基准线量测；双方同意且可归因的成功指标与门槛；共同定义的「第一个真正有用的结果」及其达成日期；明订的量测方法与归因方式；客户端在推广与训练上的责任。
其中「部署前的基准线」是最常被跳过、也是失败率最高的一项。没有基准线，事后所有的成效叙述都只是叙述。
如果部署的是 agent 系统，还要多一条：验收不能用单次成功率。 学术上有一个好用的区分——pass@k 是「跑 k 次至少成功一次」的几率，衡量能力上限；pass^k 是「跑 k 次全部成功」的几率，衡量可靠度下限。用户对一个要被信任的系统，期待的是每次都对，不是五次里有一次对。pass@5 很高但 pass^5 很低的系统，是「会做但不稳定」——对信任而言，那比不会做更糟。
写完这些，我要说一个和上面所有内容方向相反、但我认为更重要的观察。
在小团队与个人的实务里，我看到最顽固的失效模式不是 bug，不是速度，也不是品质。
是计划写完了，第一个动作没有发生。
完整的网站规格，站是空的。建好的社群基础建设，零个成员。写给投资人的一页纸，错过的里程碑。十三项交付清单，当周一项未启动。完整的系统架构，五个关键设计问题悬着没答。
失效点永远落在「计划存在」与「第一个动作发生」之间。这不是思考能力的问题，是交接的问题——计划变成了一个令人满足的终点，而不是发射台。
而一个以产出量、文档数、交付件数为进度证据的量测系统，会精确地喂养这个失效模式。你会越量越勤奋，越量越不动。
所以如果只能留一个指标，我会留这个：
从「决定要做」到「第一个实际动作发生」之间，过了多久。
以及更有价值的那一栏：超过期限没动的时候，写下一行「为什么没动」。
累积十笔，你会看到自己真正的阻塞在哪里。通常不是能力，不是时间，是某个没被写出来的犹豫。
那一行字，比任何仪表板都准。
全部 21 件来源，依支持的段落分组，逐一可点开查看原文。