企业官网建设流程全解析

一个反直觉的数字

AI 编程到底让开发者变快还是变慢了？这可能是当前软件行业最有争议的问题之一。

一方面，Stack Overflow 的 2025 年开发者调查显示，65% 的开发者至少每周使用 AI 编程工具；GitHub、Google 和 Microsoft 的早期研究普遍报告，开发者完成任务的速度提升了 20% 到 55%。另一方面，非营利研究机构 METR 做了一项有意思的研究：让经验丰富的开发者使用 AI 工具完成真实任务，结果发现——开发者主观上认为 AI 让自己快了 20%，但客观计时显示他们实际上慢了 19%。

同一个群体、同样的工作，主观感受和客观测量给出了完全相反的结论。这不是简单的“谁说错了”，而是暴露了一个更根本的问题：我们到底在用什么口径测量“效率”？

本文不打算给 AI 编程下结论，而是尝试提供一个新的参照系：把厂商官方指南中明确列出的“人的职责”拿出来对照——这些职责环节恰恰是主观计时里最容易被漏掉、被低估的工时来源。

官方指南里，哪些活儿是“人的职责”？

以《AI 编程：开发者实用指南》（Kimi，kimi.com/resources/ai-in-programming）为例，这份文档按软件开发生命周期（SDLC）四个阶段，逐项列出了 AI 能提供的支持和对应的“人的职责”：

这份文档在结语里也点明了立场：“决定发布什么、证据是否充分的仍然是开发者。”换句话说，即使在厂商自己写的指南里，AI 的角色也是“处理限定范围的请求并返回供检查的结果”，而不是替代人对范围、正确性和发布决策负责。

关键在于：“人的职责”那一列，全部是认知型、决策型、检查型的工作——批准取舍、确认设计、判断证据、诊断业务影响。这些工作不产出代码行，不产生 git diff，但实实在在消耗工时。

为什么自报效率会与实测相反

有了这个参照系，主观与客观的矛盾就不难解释了。可以从三个角度看：

1. 感知锚点不同：写在屏幕上的 vs. 花在脑子里的

开发者自报效率时，最自然的锚点是“代码生成速度”。AI 几秒钟吐出一段完整实现，对比过去手写半小时，这种体感差距是真实且巨大的。但 METR 式的客观测量计的是端到端任务总时长——包括写提示词、审查生成代码、排查 AI 理解偏差、运行测试、回滚不满意的方案。

指南里“验证与发布”阶段的人的职责是“判断证据是否充分”。这个判断可能占掉整个任务一半的时间，但它看起来不像“干活”，自报时很容易被忽略。

2. 漏记的工时恰好集中在“人的职责”环节

按官方指南的划分，以下几个环节的工时最容易被主观估算漏掉：

• 构建与集成阶段：“确认设计被正确表达”。AI 生成的代码“看起来太像模像样了”，腾讯云开发者社区的那篇《AI编程的真实面貌》文章里引用 Mediaocean 软件工程总监 James Liu 的话说，有些项目能得到 20 倍效率提升，另一些则会“彻底翻车，然后你花大量时间试图哄它实现你想要的愿望”。错误越隐蔽，审查成本越高——而审查时间常常不算进“AI 帮我省的时间”里。
• 验证阶段：“授权面向生产环境的操作”。指南的常见问题部分给出了具体做法：对照独立的验收标准检查结果、审查安全边界和数据处理、运行既定测试再补充针对性用例、使用受限权限并在生产操作前要求审批。每一条都是耗时操作。
• 定义与设计阶段：为了一次“限定范围的请求”，开发者需要先准备好清晰的指令、附上相关仓库文件和运行时证据。这段上下文准备时间，在“AI 秒出代码”的叙事里是完全隐形的。

3. 任务类型决定了偏差方向

Mediaocean 的引语也解释了为什么不同研究会得出不同结论：任务与 AI 能力匹配时效率大幅提升，不匹配时反而拖慢。主观自报往往被高光时刻拉高，客观测量则包含了“哄 AI”的谷底时刻。

实践建议：给自己的效率测量“补上人的职责”

如果你想在团队里认真回答“AI 到底有没有让我们更快”，可以参考以下做法：

1. 按 SDLC 四阶段记工时，而不是按“写代码 vs. 其他”记。至少把“准备上下文/指令”“审查生成代码”“排查 AI 偏差”“验证与授权”单独成项，否则 METR 式的偏差必然出现。
2. 用端到端任务计时作为基准。选取定义清晰的、有独立验收标准的任务，从需求确认到验证通过全程计时，与历史基线对比。
3. 把审查成本显性化。AI 生成的代码错误更难被肉眼发现，指南建议“对照独立的验收标准和仓库已安装的版本检查结果”——这些检查项应计入任务工时，并作为质量门禁而非可选步骤。
4. 区分“生成时间”与“接受时间”。让团队成员自报效率时，明确问的是哪一段，避免拿代码生成速度代表整体交付效率。

适用范围与局限

需要诚实地说明这套分析框架的边界：

• METR 的研究有明确范围限制：其结论来自经验丰富的开发者、特定类型的熟悉任务，不能直接外推到初学者、全新技术栈或大型迁移任务。不同人群和任务类型下，主观与客观的偏差方向可能不同。
• 官方指南的“人的职责”是一种规范性描述，即“应该怎么做”，不等于所有团队实际花在这些环节上的真实工时分布。它适合作为检查清单，而不是实测数据。
• 早期厂商研究（20%–55% 提升）的测量口径差异较大，与 METR 的端到端任务计时不可直接比较。引用任何效率数字前，先问一句：它计的是哪一段？

结语

AI 编程效率之争，与其说是在争论模型强不强，不如说是在争论测量口径：主观自报倾向于锚定“代码出现在屏幕上的速度”，而客观计时覆盖了“判断证据是否充分”的全部代价。把官方指南里那一列“人的职责”当作参照系，恰好能解释两者为何相反，也能提示哪些工时最容易被漏记。

决定发布什么、决定证据是否足够的仍然是开发者——这意味着开发者的判断时间不会因为 AI 的存在而消失，只会转移形态。认真计量这部分时间，才是回答效率问题的第一步。

参考资料

• 《AI 编程：开发者实用指南》（Kimi，kimi.com/resources/ai-in-programming）
• 《AI编程的真实面貌：当65%开发者拥抱AI，效率神话为何仍存争议？》（腾讯云开发者社区）

参考资料

以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中；资料内容与适用范围以原始页面为准。

• AI 编程：开发者实用指南
• AI编程的真实面貌：当65%开发者拥抱AI，效率神话为何仍存争议？-腾讯云开发者社区-腾讯云