夜雨聆风未来已经来了。只是分布不均。这句话用在AI的ROI(投资回报率) 上，再准确不过。
--Deputy CTO,DX Justin Reock
这是Justin Reock，开发者体验平台 DX 的Deputy CTO，在QCon AI大会上的演讲。他的团队基于DORA、SPACE、DevEx 等研究框架，跟踪了上百家公司的AI落地效果。
注：DX (getdx.com)是一个为软件开发团队提供“工程智能化”分析平台的科技公司。它的核心产品是帮助技术管理者衡量和提升开发人员的生产力与工作效率。2025年9月被知名软件公司 Atlassian（旗下拥有Jira、Confluence、Bitbucket等产品）收购。
结论是让人警醒的：有些公司的AI带来了20%以上的质量提升。另一些公司出现了20%以上的质量下降。 平均值完全掩盖了全貌。
而MIT NANDA研究组的最新发现是：95% 的AI试点以失败告终。（具体参看麻省理工精彩报告的总结：麻省理工的一份报告干崩美股！？）
这不是一个"AI有没有用"的问题。这是一个"为什么同一把工具，结果天差地别"的问题。
一、矛盾的数据：10% 提升 vs 19% 下降
先看数据有多矛盾。
Google声称工程师使用AI后整体产出提升了约10%——考虑到Google本身就是工程效能领域的顶尖组织，这听起来合理。
但METR研究——虽然样本量小且有方法论瑕疵——显示参与实验的工程师整体产出下降了19%。更有意思的是：METR研究中的每一位工程师都感觉自己更高效了。"定性数据说，我真的觉得我产出更多了。但定量数据说，你没有。"
这就是AI时代的第一个陷阱：主观感受和客观产出之间的鸿沟。
DORA社区的报告相对冷静。25%的AI采纳率增长对应了：
文档质量：+7.5% 代码质量：+3.4% 代码审查速度：+3.1% 审批速度：+1.3% 代码复杂度：-1.8%
"适度但至少是正面的影响。"
（注：DORA（DevOps Research and Assessment，即DevOps研究与评估团队）是一个专注于研究软件交付与运维性能的研究项目。DORA报告地址:https://dora.dev/ai/gen-ai-report/report/）
DX自己的数据验证了这些数字：中等以上AI使用者相比非使用者，变更信心高 2.6%，代码可维护性高 2.2%，变更失败率低 0.11%（0.11% 听起来不多，但行业基准是 4%，所以这个降幅有意义）。但这些全是平均值。
二、真正的问题：平均值背后的瀑布落差
Justin做了一件很少有人在报告中做的事：把数据按公司拆分。
结果像一道瀑布。
同一张图里，有的公司在"变更信心"上提升了超过20%，有的公司下降了超过 20%。代码可维护性一样——一些团队的代码变紧致了，另一些在变混乱。变更失败率最严重的公司，缺陷是行业基准的50% 以上。
最高的柱子——你绝对不想站的地方——是 2% 的变更失败率提升。对比行业基准 4%，意味着比你以前多发了 50% 的缺陷。
这个方差背后有一个清晰的模式。
结果差的公司，有一些共性（Justin 称之为"反模式"）：
缺乏教育和赋能 — 不只是培训材料，还包括安全实验的时间和心理空间 自上而下的强制令 — "全公司100%AI使用率"毫无意义，只会触发Goodhart 定律 心理安全感下降 — 人们开始博弈指标，而不是真正用好工具
把技术开关打开，然后期待用户魔法般地变得熟练——这在任何技术上都不成立。AI 同样需要学习。
三、学习曲线：先下降，再上升
Justin发现了一条极其一致的学习曲线——与你是初级还是高级、大企业还是小创业公司无关。
从零采纳到轻度采纳，几乎普遍地导致质量和产出双双下降。
然后进入中度和重度采纳阶段，曲线回升，最终超过起点。
我们确实看到了收益。但有一条我们必须准备的、清晰的学习曲线。
这解释了为什么 95% 的试点失败。大多数组织在曲线的最底部就放弃了——"AI 让事情变糟了"——然后切掉项目。
他们没有坚持走到曲线上升那一段。
DORA的贝叶斯后验分布分析进一步揭示了哪些策略能帮你撑过这段曲线：
清晰的AI政策（90% 置信度，强正面效益）——明确什么能用什么不能用 给时间学习（紧随其后）——不是"这是材料，自己去看"，而是带沙箱的沉浸时间 缓解"被替代焦虑"（80% 置信度）——作为领导者，主动说清楚：这是增强，不是替代
清晰的 AI 政策是第一位的。比起强制培训，明确"我们可以用这技术做什么"的正面影响大得多。
四、恐惧管理：别让工程师在恐惧里工作
Justin给了几个让恐惧降下来的硬数据：
SWE-bench 最高分是 44%。 一年半前是 34%。模型在特定任务上能完成不到一半——增长的斜率已经开始放缓。
最严格的测试里，最高分的模型能完成 44% 的任务。没有人机循环的 44%。这不构成"员工替代策略"。这些数字太低。
然后是Google著名的亚里士多德项目——十年前的研究，结论是：
心理安全感是高绩效团队最重要的特征。
不是顶尖工程师的组合。不是经验丰富的管理者。不是无限算力。是心理安全。
在这个不确定的时代——尤其是对初级开发者和刚入行的工程师——这一点比以往任何时候都更核心。Justin的建议是主动说清楚：
这不是成本削减的故事。这是吞吐量的故事。任何看过《目标》或《凤凰项目》的人都明白：你不应该优先成本，你应该优先吞吐量。吞吐量才是商业机器的职责。
五、度量的艺术：眼镜蛇效应和Goodhart定律
Justin花了相当篇幅讲一个寓言——眼镜蛇效应。
一个皇帝有眼镜蛇问题。他出了悬赏：交 100 条死蛇，拿钱。人们开始养殖眼镜蛇，屠杀，交差，领钱。皇帝发现了这个套路，取消了悬赏。养殖户把活蛇全放了。眼镜蛇问题比以前更严重。
当一个度量变成目标，它就不再是好的度量。这就是Goodhart定律。
在AI的语境里：如果目标是"100%的AI使用率"，工程们会在周一用AI更新一下README，然后日报表上就全绿了。但实际产出没有任何变化。
正确做法是Justin提出的DX AI度量框架——三层，从左到右是成熟度曲线：
第一层：利用度（最基础）
日活用户、周活用户 AI 辅助的 PR 占比 AI 生成的代码占比 分配给 Agent 的任务数
第二层：影响力（真正重要）
AI 驱动的时间节省 PR 吞吐量（但要计入复杂度，不是数 PR 数） 可感知的交付速度 代码可维护性 变更信心 变更失败率
第三层：成本
Token消耗
利用度指标告诉你"发生了什么"。影响力指标告诉你"这些投资有没有起作用"。基础指标才是最终衡量标准。
Justin反复强调了一个原则：永远不要在任何单一指标上过度索引。 PR 吞吐量本身不说明问题——你可以一周更新十次 README，PR 吞吐量看起来棒极了。需要理解变更的复杂度和价值。
度量方法也要打组合拳：
遥测数据（GitHub/GitLab API）——客观但只说"发生了什么" 体验采样（PR 表单加一个字段："用 AI 做这个 PR 了吗"）——轻量、纵向可追踪 定期调查——但要防止调查疲劳，周期应该等于"在你们文化里能注意到改善所需的时间"
六、技术杠杆：系统提示词和温度
在合规和信任层面，Justin给了两个具体的技术杠杆。
杠杆一：系统提示词的反馈闭环
不同平台叫法不同（Copilot 叫 system prompt，Cursor 叫 Cursor Rules，Claude 叫 Agent Markdown）——本质是每次提示词附带的规则集，引导模型的行为。
关键是建立反馈闭环。不是写一次系统提示词就完了。是需要有人专门守门——当模型行为出问题时，收集反馈、更新规则、保持规则的时效性。
Justin给了一个简单例子：模型在用Spring Boot 2.6 之前的版本，产出含废弃方法的代码。反馈闭环就是：把"永远输出 Spring 3.0+ 的代码"追加进系统提示词，再追加"输出不确定时不要编造代码，只给方法和思路"。
杠杆二：温度控制
温度 = 熵 = 随机性。当模型在选下一个token时，不选概率最高的那一个——加了随机性。
低温度（如 0.0001）：相同输入 → 逐字相同的输出。适合严格代码生成。 高温度（如 0.9）：同样的 prompt → 两个都正确但完全不同的解法（一个用 HTML + CSS，一个用 Canvas + JavaScript）。
严格的代码生成 + 明确的系统提示词 → 低温度。头脑风暴、内容生成 → 高温度。
七、超越代码生成：整合整个SDLC(软件生命周期)
Justin引用了DORA最新报告中的一个关键数据：在规模化组织里，工程师每周真正坐下来写代码的时间只有五到六小时。
DX对135,000名工程师的调查发现，AI 每周帮他们省了约 3.4 小时。但看看什么吞噬了更多时间：中断频率、上下文切换源、会议密集型日程、开发环境苦力、构建和测试周期。
在非瓶颈上节省一个小时，根据约束理论，价值为零。代码生成通常不是瓶颈。
真正有创意的公司在整条SDLC上部署 AI：
Morgan Stanley — 构建了DevGen.AI Agent，自动消化遗留代码（mainframe、COBOL、Perl），产出反向工程规格文档直接交给开发团队。每年节省近 300,000 小时，消除了反向工程步骤。
Zapier — 文化本身就高度自动化，但现在 bot 数量超过了人类员工。日常站会从每周五次减到两次。入职时间从 30 分钟降到两周。而且他们在加速招聘——因为知道可以让单个工程师的产出增加 10-15%。
我喜欢这个态度。他们没有因为 AI 裁员，他们因为 AI 在扩招。
Canva — 用智能体生成PRD。PM 用自然语言直接产出 epic 和 story 进 Jira，原型进Figma。而且这些PRD是用对开发者友好的语言生成的——减少了 PM 和工程师之间反复澄清的摩擦。
Faire — 自动化了低复杂度的代码审查（配置变更、单行修改等），每周 3,000 个 PR review 由 Agent 完成第一轮反馈，直接放在 PR comment 里。不替代完整 review，但处理了所有第一轮。
Spotify 2.0 — SRE 在事故处理的前几分钟经常在收集上下文、翻阅 runbook 上耗费宝贵时间。现在 Agent 在事故检测到的瞬间把相关信息发到 Slack。帮助 Spotify 处理了 90% 的故障。
八、员工成功：AI 不会抢你的工作，但用 AI 的人会
Justin说了一句全场最直接的话：
AI不会来抢你的工作。但一个很擅长AI的人可能。
DX做了一项研究：找了那些每周至少用AI省下一小时的工程师，让他们把最有价值的用例从高到低排出来。
工程师们的第一名是——堆栈追踪分析。Justin自己写了二十多年Java，逐行看过几千行堆栈。现在是工具的第一类行为——构建失败，它自己去看堆栈。
接着是：重构现有代码、生成函数的主体逻辑。
DX还发现了一个有趣的指标：到第10个PR的时间——一个新工程师从加入项目到被合并的第10个PR要多久。用好了AI，这个时间直接减半。
初级工程师的使用率更高、上手更快，因为他们不像我这样的OG开发者，需要先忘掉旧习惯再学新肌肉。但长期来看，高级工程师省下的总时间更多——因为他们能用经验识别 AI 代码里的问题。
作为领导者，Justin的建议是：
现在有一个机会：帮助你的员工获得一套可能贯穿他们整个剩余职业生涯的新技能。好的上下文工程、好的提示词工程、理解如何构建智能体——这些技能在未来很多年里都会有价值。这技术看起来不会消失。
结尾：吞吐量，不是成本
Justin 整场演讲的核心，也许可以浓缩成一件事：
任何看过《目标》的人都知道——你应该优先的是吞吐量，不是成本。
AI落地的成功与失败，区别不在于技术本身。区别在于领导者如何框定这个故事：
这是替代工具还是增强工具？ 这是成本削减还是吞吐量释放？ 度量是用来排名还是用来改进？ 有没有给学习留出专属时间和安全空间？
如果你收集了数据却不用它来持续改善开发者体验，那你就没有把它用到最好。
而那个最诚实的提醒是：95% 的试点会失败。 但这不意味着 AI 没用。这意味着大多数组织还没有学会怎么在上面建立学习、度量、反馈和信任的系统。
参考资料
原文来自 Justin Reock @QCon AI 2024 演讲《Leadership in AI-Assisted Engineering》，2024 年。Justin Reock 是 DX (getdx.com) 的 Deputy CTO，20 年以上软件工程经验，专注开发者体验与生产力的度量和改进。
https://www.infoq.com/presentations/ai-assisted-engineering/
