AI写代码的生产力错觉：七成魔法，三成地狱

在 AI 写代码这件事上，整个行业都在经历一场“生产力错觉”。

Cerbos 团队的经历很典型：有人靠 Cursor、Claude Code 加速实验项目，觉得爽到飞起；另一派则冷眼旁观，觉得不过是换了个花哨的 IDE 插件。

在核心产品开发时保持谨慎，但在做一些实验性的小项目、MVP 原型或者自动化工具时，不少同事依赖 AI 写代码来加速。对于这种不要求长期维护的探索型任务，的确能感受到真实的提速。AI 承诺的少些样板代码、少翻文档、快点迭代，在这一类场景下确实兑现了。

但如果你换到真正要上生产的复杂功能，故事马上变了味。

快速满足感 vs 真正交付

AI 给人的第一感受是爽。你输入一段提示，瞬间生成一坨代码，这种即时反馈让大脑分泌多巴胺，就像完成工单或修复 Bug 那一刻。但实验数据却告诉我们：AI 让有经验的开发者平均 慢了19%。更讽刺的是，哪怕事实摆在眼前，他们依旧坚信自己快了。

这就是“生产力安慰剂”。感觉效率爆棚，但实际上只是停留在编辑器里的快感，而非生产环境的结果。

2025年7月，METR 做过一个随机实验。受试者是有经验的开源开发者，一半使用 AI 工具（主要是 Cursor Pro 搭配 Claude 3.5 和 3.7 Sonnet），另一半不用。结果很扎眼：用 AI 的那组平均速度慢了19%。更讽刺的是，实验前大家预测 AI 会让他们快24%，做完后，哪怕数据已经摆在眼前，他们仍然坚信自己快了20%。

这就是典型的生产力安慰剂。

正如安全专家马库斯·哈钦斯写道：大语言模型劫持了大脑的奖励系统，让人感觉自己完成了工作，但实际上只是错觉。堆在编辑器里的绿色小点掩盖了生产中的红色警告。

2025年 Stack Overflow 的开发者调查也印证了这一点：只有16.3% 的开发者认为 AI 让他们“极大提高了生产力”，而最多的人选了“影响不大”。

质量问题：上下文越多，越容易烂尾
速度之外，还有质量。

长时间使用 AI，你会发现一个规律：上下文越多，结果越差。模型会被早前的提示干扰，模型会把之前提示里的垃圾也吸进来，生成“几乎正确但差一点”的废代码,导致“语境Context腐烂”：结果就是看似对但根本解决不了问题的废代码。

Stack Overflow 的调查里，66% 的开发者吐槽 AI 代码“差那么一口气”，45.2% 抱怨调试太耗时。

正如团队里有人说：AI 在重复性任务上或许有用，但在严谨开发里，它就是危险的技术债工厂。

那个传说中的10倍开发效率呢？

坊间最夸张的说法，是 AI 能让开发效率提升 10 倍。但现实是，阻塞开发的从来不是打字，而是设计评审、测试失败、部署延迟。

GitHub 的实验显示，新人用 Copilot 写小型项目确实能快 55.8%。但在大型生产代码里，资深工程师因为检查和修复 AI 输出，往往整体变慢。再加上 Faros AI 的数据：AI 让团队的 PR 数量增加了 47%，但这并不是效率提升，而是上下文切换的代价。

更有意思的是 Faros AI 的数据。他们分析了一万多名开发者的日常活动，发现用 AI 的团队每天多处理9% 的任务，提交的 PR 数量增加了47%。看似更忙，其实是上下文切换更频繁。历史上，这种切换往往意味着过载和效率下降。

安全：最明显的代价

AI 写代码的安全代价不可忽视：
斯坦福早在2023年的研究就发现，AI 用户更容易引入漏洞。
Apiiro 在2024年的报告更惊人：AI 代码产生的权限提升路径增加322%，设计缺陷增加153%，而且更容易暴露密钥和凭证。

更严重的是，AI 工具链本身也可能成为攻击入口。2025 年谷歌 Gemini CLI 被爆出能被远程执行代码，亚马逊 Q 插件甚至在更新里暗藏恶意指令。AI 不仅写出有问题的代码，它自己也可能是新的漏洞源头。

这些 AI 辅助提交的代码进入生产的速度是普通提交的4倍！也就是说，不安全的代码绕过了正常的审查周期。对于要遵守 SOC2、ISO、GDPR 或 HIPAA 的公司，这不仅仅是漏洞，而是合规地雷。

这些事件暴露出一个结构性隐患：AI助手不仅仅是智能补全工具，它们还集成了插件系统、本地运行时环境和云端通信通道，每一个组件都可能成为新的攻击入口。

Jim Gumbley与Lilly Ryan在Martin Fowler平台上发布的架构图清晰描绘了这一扩展后的威胁图谱，涵盖代理程序、MCP服务器、文件系统、持续集成管道与LLM后端之间的复杂交互关系。

新的攻击面：从插件到供应链

AI 编程助手不仅写代码，它们自身也带来新的运行时、插件和扩展。每增加一个环节，就多一个攻击入口。2025年7月，谷歌的 Gemini CLI 就被爆出可以让攻击者远程执行本地代码。再往前，亚马逊的 Q 插件甚至暗藏恶意提示，能删除本地文件、关闭云主机。换句话说，工具链本身成了攻击者的温床。

七成魔法，三成地狱

谷歌工程师奥斯马尼说过：AI 能帮你走到 70%，但最后 30% 是最难的部分。对于新人来说，70% 已经很神奇；但对于老手来说，剩下的 30% 反而比从零写更慢。更糟糕的是，随着模型频繁更新，你今天学到的“使用技巧”可能明天全都失效。

更麻烦的是，随着模型不断更新，你今天摸索出的“使用姿势”明天可能完全失效。工程需要稳定和确定性，而不是飘忽不定的模式。

商业愿景与开发者现实的错位
“十倍效率”的故事，比“瓶颈在评审和测试”更能打动董事会。管理层渴望用 AI 实现少人多产，而开发者清楚，AI 只是减少样板代码，无法跳过系统依赖、QA 流程和设计讨论。

软件开发的本质目标，是交付安全、可靠、可维护的代码。AI 是工具，不是捷径。

总之：AI 写代码确实能带来即时满足和部分提速，尤其在原型和实验项目里。但真实世界里，它更多是一种生产力安慰剂，可能让新人受益，却让老手变慢。更大的隐患在于安全、合规和供应链风险。AI 的故事不该是十倍效率，而是如何在风险可控的前提下，合理发挥七成完成度的价值。

作者背景：本文作者系Cerbos公司技术团队成员，该公司专注于为人类和机器提供精细化权限管理解决方案，在访问控制领域具有深厚技术积累。