# 开发者自认快了20%，实测却慢了19%？把官方指南里“人的职责”当效率争议的参照系

一个反直觉的数字AI 编程到底让开发者变快还是变慢了这可能是当前软件行业最有争议的问题之一。一方面Stack Overflow 的 2025 年开发者调查显示65% 的开发者至少每周使用 AI 编程工具GitHub、Google 和 Microsoft 的早期研究普遍报告开发者完成任务的速度提升了 20% 到 55%。另一方面非营利研究机构 METR 做了一项有意思的研究让经验丰富的开发者使用 AI 工具完成真实任务结果发现——开发者主观上认为 AI 让自己快了 20%但客观计时显示他们实际上慢了 19%。同一个群体、同样的工作主观感受和客观测量给出了完全相反的结论。这不是简单的“谁说错了”而是暴露了一个更根本的问题我们到底在用什么口径测量“效率”本文不打算给 AI 编程下结论而是尝试提供一个新的参照系把厂商官方指南中明确列出的“人的职责”拿出来对照——这些职责环节恰恰是主观计时里最容易被漏掉、被低估的工时来源。官方指南里哪些活儿是“人的职责”以《AI 编程开发者实用指南》Kimikimi.com/resources/ai-in-programming为例这份文档按软件开发生命周期SDLC四个阶段逐项列出了 AI 能提供的支持和对应的“人的职责”SDLC 阶段AI 可提供的支持人的职责定义与设计澄清需求、暴露未解决的约束、比较设计方案、梳理系统依赖确定产品范围批准技术取舍构建与集成把已批准的方向转化为文件级计划、实现限定范围的变更、更新关联测试确认设计被正确表达保持所有权边界不被破坏验证与发布组织基于需求的检查、排查失败、准备发布步骤、识别回滚条件判断证据是否充分并授权面向生产环境的操作运维与维护把事故与近期变更关联、汇总服务证据、更新技术文档、梳理维护工作诊断业务影响、确定后续工作的优先级、在真实条件下验证变更这份文档在结语里也点明了立场“决定发布什么、证据是否充分的仍然是开发者。”换句话说即使在厂商自己写的指南里AI 的角色也是“处理限定范围的请求并返回供检查的结果”而不是替代人对范围、正确性和发布决策负责。关键在于“人的职责”那一列全部是认知型、决策型、检查型的工作——批准取舍、确认设计、判断证据、诊断业务影响。这些工作不产出代码行不产生 git diff但实实在在消耗工时。为什么自报效率会与实测相反有了这个参照系主观与客观的矛盾就不难解释了。可以从三个角度看1. 感知锚点不同写在屏幕上的 vs. 花在脑子里的开发者自报效率时最自然的锚点是“代码生成速度”。AI 几秒钟吐出一段完整实现对比过去手写半小时这种体感差距是真实且巨大的。但 METR 式的客观测量计的是端到端任务总时长——包括写提示词、审查生成代码、排查 AI 理解偏差、运行测试、回滚不满意的方案。指南里“验证与发布”阶段的人的职责是“判断证据是否充分”。这个判断可能占掉整个任务一半的时间但它看起来不像“干活”自报时很容易被忽略。2. 漏记的工时恰好集中在“人的职责”环节按官方指南的划分以下几个环节的工时最容易被主观估算漏掉构建与集成阶段“确认设计被正确表达”。AI 生成的代码“看起来太像模像样了”腾讯云开发者社区的那篇《AI编程的真实面貌》文章里引用 Mediaocean 软件工程总监 James Liu 的话说有些项目能得到 20 倍效率提升另一些则会“彻底翻车然后你花大量时间试图哄它实现你想要的愿望”。错误越隐蔽审查成本越高——而审查时间常常不算进“AI 帮我省的时间”里。验证阶段“授权面向生产环境的操作”。指南的常见问题部分给出了具体做法对照独立的验收标准检查结果、审查安全边界和数据处理、运行既定测试再补充针对性用例、使用受限权限并在生产操作前要求审批。每一条都是耗时操作。定义与设计阶段为了一次“限定范围的请求”开发者需要先准备好清晰的指令、附上相关仓库文件和运行时证据。这段上下文准备时间在“AI 秒出代码”的叙事里是完全隐形的。3. 任务类型决定了偏差方向Mediaocean 的引语也解释了为什么不同研究会得出不同结论任务与 AI 能力匹配时效率大幅提升不匹配时反而拖慢。主观自报往往被高光时刻拉高客观测量则包含了“哄 AI”的谷底时刻。实践建议给自己的效率测量“补上人的职责”如果你想在团队里认真回答“AI 到底有没有让我们更快”可以参考以下做法按 SDLC 四阶段记工时而不是按“写代码 vs. 其他”记。至少把“准备上下文/指令”“审查生成代码”“排查 AI 偏差”“验证与授权”单独成项否则 METR 式的偏差必然出现。用端到端任务计时作为基准。选取定义清晰的、有独立验收标准的任务从需求确认到验证通过全程计时与历史基线对比。把审查成本显性化。AI 生成的代码错误更难被肉眼发现指南建议“对照独立的验收标准和仓库已安装的版本检查结果”——这些检查项应计入任务工时并作为质量门禁而非可选步骤。区分“生成时间”与“接受时间”。让团队成员自报效率时明确问的是哪一段避免拿代码生成速度代表整体交付效率。适用范围与局限需要诚实地说明这套分析框架的边界METR 的研究有明确范围限制其结论来自经验丰富的开发者、特定类型的熟悉任务不能直接外推到初学者、全新技术栈或大型迁移任务。不同人群和任务类型下主观与客观的偏差方向可能不同。官方指南的“人的职责”是一种规范性描述即“应该怎么做”不等于所有团队实际花在这些环节上的真实工时分布。它适合作为检查清单而不是实测数据。早期厂商研究20%–55% 提升的测量口径差异较大与 METR 的端到端任务计时不可直接比较。引用任何效率数字前先问一句它计的是哪一段结语AI 编程效率之争与其说是在争论模型强不强不如说是在争论测量口径主观自报倾向于锚定“代码出现在屏幕上的速度”而客观计时覆盖了“判断证据是否充分”的全部代价。把官方指南里那一列“人的职责”当作参照系恰好能解释两者为何相反也能提示哪些工时最容易被漏记。决定发布什么、决定证据是否足够的仍然是开发者——这意味着开发者的判断时间不会因为 AI 的存在而消失只会转移形态。认真计量这部分时间才是回答效率问题的第一步。参考资料《AI 编程开发者实用指南》Kimikimi.com/resources/ai-in-programming《AI编程的真实面貌当65%开发者拥抱AI效率神话为何仍存争议》腾讯云开发者社区参考资料以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中资料内容与适用范围以原始页面为准。AI 编程开发者实用指南AI编程的真实面貌当65%开发者拥抱AI效率神话为何仍存争议-腾讯云开发者社区-腾讯云