一项随机对照试验（RCT）发现：允许使用 AI 的情况下，资深开源开发者完成真实任务的时间竟然增加了 19%。 这与大家的直觉——“AI 一定能提速”——完全相反，也和各大厂、工具商的营销说法不一致。 本文将从方法、数据、原因和建议四个层面，深入拆解这个现象。
一、为什么这项研究值得认真看？
过去两年，围绕 “AI 能否显著提升开发者效率” 的结论大多来自：
- 官方 Demo / 产品演示
- 人工构造的 benchmark（往往是小代码段、算法题、LeetCode 风格问题）
- 针对初学者 / 中级开发者的场景
但这次不一样，这项研究有三个非常重要的特征👇：
- 对象是真正的高级开发者：参与者是长期在大型开源项目中活跃的贡献者，掌握 1M+ 行代码规模的代码库，平均项目 star 22k+。也就是说，他们本身的效率已经很高，不是“不会写所以要靠 AI”的群体。
- 任务是真实的、他们本来就会做的事：不是“写个二分查找”这种实验题，而是实际项目中的 bug 修复、新特性、重构。
- 研究方法是 RCT（随机对照试验）：同一类任务，有的分到“允许用 AI”，有的分到“不能用 AI”，可以对比。
所以，这不是“AI 不行”，而是**“在资深开发者 + 真实代码库 + 2025 年初的 AI 工具组合”这个特定条件下，AI 的收益没有大家想象那么高，甚至还可能是负的。**
二、研究设计：怎么做到“说服力强”？
1. 参与者
- 16 位开发者，全部是有多年开源经验的资深贡献者；
- 他们参与的项目：大型、真实、复杂、多人协作的开源仓库；
- 项目特征：22k+ star、百万级代码量、长期维护、非玩具项目。
2. 任务来源
不是研究者出题，而是开发者自己列出“这个项目现在真实需要做的任务”； 类型包括：
- bug 修复
- 新功能开发
- 代码重构 / 清理
- 文档与实现不一致的修补
- 与历史设计兼容的改动
这非常关键：任务是“他们真的会去做的事”，所以不会因为题目太简单或太理想化，导致 AI 显得特别厉害。
3. 分组方式
每个任务被随机分配到两个组之一：
- ✅ AI 允许使用组（可用 Cursor Pro + Claude 3.5/3.7 Sonnet 等）
- ❌ AI 禁止使用组（纯手写 + 传统工具）
开发者知道自己在哪一组，但研究者控制分配，避免“选任务偏好”。
4. 开发环境与记录
- 每个任务大约耗时 2 小时；
- 过程全程有屏幕录制；
- 开发者需要自行报告时间；
- 有高额激励：150 美元/小时 → 有动力认真做。
三、核心发现：为什么“允许用 AI 反而更慢”？
1. 数据先说话
| 场景 | 开发者预测平均耗时（小时） | 实际观察平均耗时（小时） | 时间差异 |
|---|---|---|---|
| ✅ AI 允许使用 | 1.8 | 2.14 | +19% |
| ❌ AI 禁止使用 | 1.8 | 1.8 | 0% |
这里有两个非常值得玩味的点：
- 开发者认为 AI 会提速约 24%（从 1.8h 降到更低）
- 但实际却反过来：多花了 19% 时间
- 更反直觉的是：即便体验了变慢，他们仍然觉得“AI 让自己快了 20%” 🤯
这说明了一个非常现实的问题： 👉 开发者对 AI 提效的主观感受，显著高于 AI 的客观实际效果。 👉 也就是说，AI 有很强的“生产力幻觉”（productivity illusion）。
四、为什么会变慢？——5 个主要拖累因素
研究一共排查了约 20 个可能的影响因素，最后归纳出 5 个最有可能导致效率下降的原因。下面我按“真实开发者视角”来拆开说。
1. 🧠 Prompt 工程的隐性成本
“为了让 AI 写一段我满意的代码，我要写一段给 AI 看的文档。”
- 资深开发者习惯“直接写代码”；
- 但 AI 要求你先说清：
- 代码在哪一层？
- 依赖谁？
- 要不要兼容已有接口？
- 当前项目风格是 OOP 还是 FP？
- 这就变成：要写代码前先写说明书。
在简单任务中，这个开销很容易超过“自己写”的时间。
📌 结论：AI 不是没帮上忙，而是“让你多了一步与 AI 沟通的工作”，在中等粒度的任务里，这步是贵的。
2. 🧩 AI 生成代码的“理解 → 验证 → 整合”成本
AI 很擅长“写一段看起来对的代码”，但在真实项目中要做到这几件事：
- 这段代码真的能跑吗？
- 它符合这个项目的边界定义吗？
- 它有没有破坏既有行为？
- 它能通过 CI 吗？
- 它是不是和以前的实现风格不一致？
这时候问题来了： 👉 AI 写的代码可能没错，但你得花时间去理解它。 👉 对一个熟悉项目的资深开发者来说，自己写往往比理解别人写的更快。 👉 而 AI 在这里，就成了“别人”。
3. 🐛 AI 引入的新错误要你来收拾
AI 代码不是一定错，但它常常会：
- 忽略边界条件
- 假定有个不存在的 helper
- 用了仓库里没有的 util
- 写了一个“看起来像是以前写过的模式”但其实没有
这类错误的特点是： 👉 人写的时候不会犯，因为人知道这个项目以前怎么写的； 👉 AI 犯了以后，你要去定位 + 回溯 + 修正 + 再次运行； 👉 这套流程比“我自己写一段”要长。
所以，AI 有时并不是帮你少写代码，而是帮你多造了一个你必须修的坑。
4. 🌀 幻觉（Hallucination）导致的“错误路径”
这是所有生成式 AI 目前都躲不开的点：它非常擅长一本正经地胡说八道。
- 它说项目里有这个方法，其实没有；
- 它说可以用某个 API，其实版本不对；
- 它说这个库支持这个参数，其实要装插件；
- 它说可以自动生成迁移文件，其实你项目用的不是这个 ORM。
这类错误可怕的地方在于： 👉 它不是“明显的语法错”，而是“误导你走错方向” 👉 你要花时间排查 “到底是我错了还是它错了” 👉 这就变成了 “AI → 人 → 项目 → 文档 → AI” 的往返查询 👉 而这个上下文切换，会严重拉低专家的速度。
5. 🔁 上下文切换成本
对熟练开发者来说，高效率往往来自于长时间在同一上下文中保持专注。 而引入 AI 后，工作模式会变成：
- 看代码
- 想修改
- 打开 AI
- 描述上下文
- 收到不完美回答
- 再补充描述
- 再次生成
- 回到编辑器
- 手动合并
- 跑测试
- 回去改 prompt …
这就导致了一个很现实的现象： AI 工具的交互式特征，和资深开发者的“深度专注型工作流”有天然冲突。 所以不是 AI 不行，而是 AI 目前的交互范式更适合“半懂不懂的人”而不是“非常懂的人”。
五、那 AI 完全没用吗？——不是的，是“场景错配”
从研究里我们也能看出，AI 在这几个方面还是有价值的：
- 快速生成初版代码骨架
- 写接口定义、DTO、测试样板、CRUD 模板
- 解释陌生代码块
- “这段 2019 年写的 util 是干嘛的？”
- 做知识检索 / 代码语义搜索的入口
- “仓库里哪里用了这个枚举？”
- 当文档缺失时，做“猜测性补文档”
- 给你一个大概的理解框架
但是！这些价值更多是： 👉 补足“文档不全 / 人员交接 / 历史包袱”的场景 👉 而不是“在你最擅长的任务上进一步提速”。
也就是说：
- 对新手 / 中级 / 新入职开发者 → AI 很可能是生产力放大器
- 对长期维护同一大型代码库的专家型开发者 → AI 可能是节奏打断器
六、优缺点概览（基于这次 2025 年初能力的 AI 工具）
| 工具名称 / 类别 | 优点 | 缺点 |
|---|---|---|
| 2025 年初主流 AI 辅助开发工具组合 （如 Cursor Pro + Claude 3.5/3.7 Sonnet） | 1. 能快速生成代码草稿和框架； 2. 能解释复杂、历史久远的代码； 3. 能做项目内“代码搜索 + 结构化解读”； 4. 能做 PR 总结、变更说明、提交信息自动生成； 5. 能指导不熟悉项目的开发者上手； | 1. 在资深开发者真实任务上出现效率下降（+19%）； 2. 需要大量 prompt 迭代 才能得到合格输出； 3. 生成代码需要人类再验证与重构 → 增加时间； 4. 存在 幻觉与不准确引用 → 走错路要回头； 5. 与“高专注、深度上下文”的资深开发者工作流不完全匹配； 6. 频繁工具切换 → 认知负荷增大； 7. 容易制造“自己变快了”的错觉，但指标不支持。 |
七、怎么用这结论？——给三类人的建议
1. 👨💻 给开发者（尤其是你这种已经很熟项目的人）
- 不要盲目把“所有任务”都用 AI 做；
- 适合 AI 做的：重复性、结构性、非核心业务的代码；
- 不适合 AI 做的：涉及项目深层约束、历史兼容、跨模块影响的改动；
- 最佳策略：局部用 AI，而不是整活式用 AI；
- 给自己做一次“小范围 A/B 测试”，看看到底哪些任务是真的被 AI 提速了。
2. 🛠 给 AI 工具开发者
- 现在的 AI DevTools 太“聊天化”，对专家不够“嵌入式”；
- 未来应该做的是：
- 自动识别项目架构 → 自动补上下文，而不是每次都要用户解释；
- 输出的不只是代码，还要输出**“为什么这样写”**；
- 出现幻觉时能自我回退 / 自检；
- 和 IDE、CI、Repo 的集成要更深，减少上下文切换；
- 支持团队级别的**“约定学习”**，而不是只懂通用最佳实践。
3. 🧪 给研究者 / 技术负责人
- 不要只看官方 demo，要看真实仓库 + 真实任务 + 真实开发者；
- RCT 是目前看 AI 真实效能的好方法，应继续做；
- 要分层看人群：新手、中级、专家 → AI 效果不是一条直线；
- 要跟踪模型版本：这项研究是 2025 年初能力的快照，半年后可能完全不同。
八、重要启示：为什么大家“感觉变快了”但其实没变快？
这是本文最有价值的发现之一。
AI 有很强的“体验性提效” → 你觉得自己掌控了更多上下文、写得更优雅、查得更快 → 但客观时间没下降，甚至上升了。
原因包括：
- AI 一直在“陪你思考”，于是你感觉“我没卡住”；
- AI 会不断给你新方向，于是你误以为自己“在推进”；
- 从人类心理学上说，被动阅读比主动构建更轻松，所以你会误以为更高效；
- 但真实世界的考核指标是：最终任务完成时间 / PR 合并时间 / 缺陷率，而不是“做的时候爽不爽”。
👉 所以：AI 工具的 UX 很容易制造“假提效”，管理者要警惕。
九、结论
1. 核心结论
在 2025 年初的真实能力水平下，AI 工具对资深开源开发者的真实生产力并没有形成提升，反而让任务完成时间增加了 19%。
- 这与开发者本人“AI 会提速 20–25%”的主观认知明显不一致；
- 因此，在企业 / 团队级别推广 AI 开发工具时，必须做情境化验证，不能只看市场宣传。
2. 本质原因
- 当前 AI DevTools 仍然是“生成式 + 会话式”范式；
- 对初学者是能力补全；
- 对专家是流程打断 + 认知负荷增加。
3. 展望
- 这次研究的结果是一个时间点快照——代表的是“2025 年初”的 AI 能力；
- 模型、上下文窗口、代码理解代理、Repo-level RAG、自动运行环境如果在 2025 下半年继续提升，这个结论是可能被推翻的；
- 也就是说：现在的 AI 是“可以用”，但还没到“默认要用”的程度。......