Developers Felt 20% Faster With AI. They Were 19% Slower.

凌晨2点，没人知道这段代码的作用

凌晨2点，结账功能瘫痪了。

值班工程师打开故障服务开始查看。罪魁祸首是一个400行的函数，三周前被合并时只用了一个竖起大拇指的emoji作为审核意见。团队里没人写过这段代码。这是AI代理在大约90秒内生成的，当时大家都觉得这很酷。

现在看起来就没那么酷了。

我总是在回想起这个场景，因为有一项研究。2025年，METR对经验丰富的开源开发者进行了一项严格的随机试验。使用AI工具时，他们完成实际任务的时间比平时多了19%。但之后他们猜测AI让自己快了约20%。

（公平地说，那是2025年初的工具，METR后来表示这个数字不能照搬到现在。现在的工具已经改进了。但那种"感觉很快"和"实际速度"之间的差距？我认为这个问题依然存在。）

为了说明，我并不是反对AI。我每天都在使用AI，而且产出比以往任何时候都多。我之所以要诚实讨论成本，是因为没人会在LinkedIn上发这些内容。我会分析数据（包括一些错误传播的热门数据），说明初级开发者正在经历什么，解释为什么大规模的AI提交请求比有bug的请求更让我担忧，以及我最终形成的两个原则。

首先看数据

我花了一个晚上核对那些不断被分享的统计数据。大部分数据都站得住脚。

CodeRabbit在去年12月分析了470个真实的拉取请求，发现AI协作编写的代码有75%更多的逻辑错误，安全问题数量高达人类代码的2.74倍。Harness对500位工程负责人进行调查，67%的人表示现在需要花更多时间调试AI生成的代码。而斯坦福大学的薪资数据显示，22至25岁的开发者现在的工作量几乎比2022年底的峰值低了20%，这才是真正让我失眠的数据。

不过有几组数据我建议停止传播。"63%的开发者花更多时间调试AI代码"这个说法到处可见，但我找不到任何实际研究支持这个数据。如果你还在引用"Stack Overflow流量下降25%"这个数据，那已经是过时信息了。2026年7月该网站新增了约1400个问题。它在2014年最好的月份曾创下超过20万个问题的记录。

有趣的是，Stack Overflow自己发布的2026年开发者调查报告很好地总结了当前的氛围。目前大多数开发者在工作中使用AI，近一半的人只有在能轻松验证结果时才信任AI的输出，仅有6.6%的人会将重要决策交给AI。

把这些数据加在一起，我们得到的结论是：代码总量比以往任何时候都多，但对代码的理解却在减少，我们"节省"的大量时间其实都悄悄花在了清理工作上。

停止寻找工具，开始撰写更清晰的指令

今年我更换AI工具的频率，甚至超过了前五年更换IDE的次数。我猜你也是如此。每隔几周就会有更出色的新工具出现，这让对任何工具保持忠诚都显得有些徒劳。

真正改变我工作效率的其实很普通：我开始给AI代理分配更小的任务。

到2025年底，模型确实有明显提升。但对我而言更大的突破来自于不再让一个代理处理所有工作。现在我会分步骤处理：先制定计划，再设计架构，接着进行开发，最后调试，每个环节都独立进行。

回想你这些年处理的工单，"为登录接口添加限流功能，每分钟五次尝试，返回429状态码"这样的需求是可以完成的。但"让应用更安全"这种模糊要求却可能让你浪费一周时间。AI代理也是如此，区别在于它们不会回来询问你的意图，只会自行猜测。

因此我现在会先撰写计划，真正阅读这份计划（这是人们常忽略的步骤），只有在确认后才会让代理接触代码。

另一个我花时间接受的事实是：这些工具并不具有确定性。十分钟后输入完全相同的提示，可能会得到不同的结果。过去保持对工具的了解只是锦上添花，现在这已成为工作的一部分。上个月有效的方案，这个月可能失效，唯一的方法就是持续学习你的代理行为，就像你学习新同事的思维方式一样。

AI不会告诉你你的基础设计有误

我已多次目睹这种情形以不同形式上演。

有人提出一个小型Web应用的构想，请求AI帮忙开发。一小时后，系统会生成一个包含规范关系数据库的初稿。严格的表结构、外键约束，所有数据都整齐地关联在一起。

但构想很快就会改变，数据证明其本质是混乱且不断变化的，实际需要的是更灵活的方案，比如可以接收任意数据的JSON字段。

AI不会察觉到这点，它从不会停下来指出"等一下，这个数据模型已经不再适用了"。它只会继续在原有架构上叠加新功能，让每个新增特性都围绕原始设计艰难嵌套。每次修改都会让系统变得更慢、更脆弱，直到获取最新版本时感觉就像在别人搭建的积木塔上玩俄罗斯方块。

解决问题的关键不是更巧妙的提示词，而是有人必须做出决策：放弃原有数据库，从两个简单表重新开始。一个表记录所有历史变更，另一个保存当前状态。一旦AI被告知这是新的架构方向，代码立刻变得简洁明了。

这就是我对"氛围编程"的主要担忧。这些工具擅长在现有基础上构建，却极不擅长指出现有基础存在错误。总需要有人来承担这个责任。

在维护老旧代码库时情况会更复杂。绿地开发（Greenfield）很简单：你描述需求，系统能快速实现90%。最后10%才是系统开始老化的地方，每个真实项目都积累了数年的历史包袱：未完成的重构、被遗忘的决策。AI在开始修改前仍难以真正理解这些历史。过去我们通过文档、设计评审和代码阶段门禁来处理这些问题。这些习惯依然重要，可能对AI代理而言比对人类开发者更重要。

AI让优秀团队更出色，也让混乱团队更混乱

Google's 2025 DORA report 调查了近5000名技术人员，其中让我印象深刻的一句话是：AI就像一个放大器。它不会修复团队，而是放大团队已有的状态。

如果系统是松耦合的且反馈循环快速，就能看到显著提升。如果所有模块纠缠在一起且发布需要数周，几乎看不到任何收益。DORA还发现，目前AI的采用与更快的交付速度同时出现，但也伴随着生产环境中的更多不稳定性。

GitClear的数据 指向了同样的结论。他们分析了2020年至2024年间2.11亿行修改代码，2024年是复制粘贴代码行数首次超过移动代码行数的年份。移动代码行数基本上是他们衡量重构的代理指标。换句话说，代码重复越来越多，而整理优化却越来越少。

你可能在自己的代码库中见过这种情况。AI会生成第四个validateEmail函数，而不是使用已有的三个。所有函数都能正常工作，这正是没人删除它们的原因，直到有一天你需要修改规则，不得不找到所有四个函数。

如果团队本身架构松散、测试薄弱且评审仓促，AI不会拯救你。你只会更快地重复同样的错误。

构建原型，但不要直接发布

我真心为产品经理和领域专家现在能够快速搭建想法的粗糙版本感到高兴。他们不再需要撰写需求文档并希望工程师能准确理解，而是可以亲自点击操作、体验卡顿环节，带着明确需求现身。仅这一点就能节省数周时间。

风险在于我们的一种老习惯：第一个原型会悄悄变成生产系统。AI让这种做法更加诱人，因为现在原型可以在一个下午完成并看起来已经完成。

但它其实并未完成。请将其视为草图，然后进行彻底重构或根据学到的经验重新构建。

我推荐以下工作流程：将杂乱的原型视为探索故事的方式，而不是直接发布的产物。一旦明确实际要构建的内容，使用AI帮助将其转化为正式需求文档。然后丢弃原型，仅根据需求文档重新构建。这样你就能摆脱上百次迭代中残留的代码、死胡同和孤立文件，同时保留所有学到的经验。

我还建议明确指定一位有经验的人员负责最终的“发布”决策。这个人需要提出那些无聊但关键的问题：如果这个功能失效，还会导致什么问题？它是否涉及登录、支付或客户数据？目前，这个人通常是AI输出与生产环境之间唯一的实际检查点，因此这应该是某人的正式职责，而不是时间允许时才临时处理的事情。

当团队开始并行运行多个代理（一个负责规划，一个负责构建，一个负责调试）时，这个角色会变得更加重要。职位名称变得模糊，工程师最终会成为掌控全局并在最后做决策的人。

团队规模也会变小。过去需要十个人完成的工作，现在可能只需要两到三个人：一个人负责构思想法，一个人负责引导代理，一个人负责生产环境。

对于任何不能接受失败的场景，我会借鉴安全关键领域工程（如航空软件领域）的做法：无论代码由谁编写，所有变更都必须经过严格的审核流程。重点不在于增加测试量，而在于验证AI生成的代码是否真正实现了你的意图。

初级开发者并未失去工作，而是失去了成长土壤

这部分内容最难表述，因为我仍记得自己作为初级开发者时，从那些琐碎无聊的任务中学习到的宝贵经验。

一项针对6200万名美国工人的哈佛大学研究发现，在引入AI的公司中，初级员工数量在六个季度内减少了约9%，而高级员工数量几乎未变。美国政府数据也颇具启示性：被归类为"计算机程序员"（即按他人需求编写代码）的岗位数量自1980年以来首次降至最低点，降幅达27.5%。而"软件开发人员"（负责决定构建什么以及如何构建）的岗位数量则几乎没有变化。

因此我认为公司并非不再需要新工程师，而是失去了原本可以分配给他们的工作。修复小bug和构建简单界面曾是初级开发者的学习方式，而如今这些工作在AI面前只需数秒即可完成。

如果我现在开始职业生涯，会将精力放在理解系统架构上：各组件如何衔接、第一周的决策为何会在第六个月引发问题。语法现在变得廉价，你可以在一小时内让AI生成iOS应用草案或设计logo。判断这个应用是否应该存在、会破坏什么，这才是价值所在。

我认为计算机科学课程也应回归基础，而非反复教授同一种语言。飞行员学习的是空气动力学，而非单纯学习按钮操作，这就是他们能应对手册未涵盖的突发状况的原因。

你已经在LinkedIn上看到这种趋势。那些真正取得AI进展的人，往往具备扎实的计算机科学基础，他们从问题和目标出发，愿意尝试不同方法达成目标。而那些将身份完全绑定在某种语言或框架上的人，听起来更像是被排除在核心工作之外。

对于已经入职的初级开发者，一个可行的中间方案是沙盒原型开发。给他们真实的AI探索问题（远离生产环境），并评审他们的学习成果。这能将热情引导到有价值的方向，同时教会他们如何正确指导AI代理，这正在迅速成为核心技能。

令人鼓舞的是，IBM表示将在2026年将美国初级岗位招聘量翻三倍，包括软件开发人员，这是在将初级岗位重新设计为围绕客户服务和AI输出验证等工作。并非所有公司都会这么做，但这证明初级岗位可以被重新设计，而非被取消。

某些AI变更需要更谨慎的审视

当AI代理提交变更时，在开始阅读前判断变更类型会很有帮助。大致可分为六种类型：

• 新增代码：全新文件或函数，未修改现有代码。通常问题不大。

• 现有逻辑修改

• 代码、配置或数据删除

• 跨多个文件的大规模重构

• 类似重命名和格式调整的整理工作。单独来看无害，但擅长掩盖真正重要的变更。

• 静默行为变更，这才是真正危险的。API开始返回略微不同的结果，前端就会崩溃，但构建时却不会报错。

如果你不明确限制代理可以操作的范围，一个任务可能会横跨所有六个类别。而最后一个通常是由客户而非测试发现的。

关于那些2000行的PR

代理特别热衷于重写代码。你要求一个小的修复，很容易就得到跨越15个文件的2000行代码。这在站会上看起来很厉害，老实说，我觉得工具本身也在助长这种现象。

问题是，模型优化的是看起来正确的结果。而优秀的工程师优化的是能解决问题的最小变更。这两个目标并不一致。

我原本以为重大AI变更会被撤销的频率更高。但数据却显示并非如此。Greptile分析了数十万份PR：有些代理的撤销率甚至低于人类，有些则更高，但大体量的代理PR撤销频率与人类的大PR并无显著差异。谷歌对352万次代码变更的研究也发现AI变更的撤销率略低。成本体现在审查环节。同一项谷歌研究发现，AI变更引发的阻塞性审查意见是人类的1.92倍。Faros 2026年报告覆盖了22000名开发者，发现审查时间中位数增长超400%，31%的PR甚至完全跳过了审查。

因此我的担忧不是巨型AI PR会明显失败，而是它们不会失败。它们会被批准，或者完全跳过审查，因为周四下午4点没人能真正审查完那么大的diff，而所有人都默默希望测试能发现问题。

我真正坚持的两条规则

我把代理当作一个喝了第四杯浓缩咖啡的非常能干的新员工来对待。敏捷、敏锐、有时鲁莽，绝对不能独自接触生产环境。

第一条规则是将diff控制在约50行。如果结果远超这个规模，我不会尝试审查。我会直接丢弃，收紧需求重新运行，这几乎总是比理清一团乱麻更快。50行的代码是我能读懂并真正负责的。任何远超这个规模的代码，我只能点击"批准"。

选择适合团队的数字，然后在CI中设置硬性检查。如果PR超出限制，就自动退回并要求更清晰的需求说明。巨大的diff通常意味着需求模糊，而非工作量庞大。

第二条规则是秘密信息完全禁止接触。环境变量、API密钥、令牌、密码：除非我亲自监督，否则绝不让代理接触这些内容。将一个密钥粘贴到提示词里，到会话结束时你可能发现它被硬编码到十几个文件中。因此所有秘密信息必须在任何AI工作开始前就存入保险库或通过环境变量引用。CodeRabbit的建议也强调类似原则：将凭证处理集中管理，禁止硬编码密码，并对每个PR运行安全扫描。

一些小习惯多次拯救了我：

• 让代理先写测试用例再开发功能
• 在代码检查器中启用重复代码检测，让第四个validateEmail函数立即被标记

• 阅读计划本身，而不仅仅是代码差异，因为大多数糟糕的代码都源于糟糕的计划

总有人要为这一切买单

廉价的代码往往会在后期变得昂贵。我将其视为快时尚软件——上线时看起来很棒，但几个月后就开始分崩离析。

影响远不止于我们自己的代码仓库。Tailwind 的流行度前所未有，但2023年初其创始人在GitHub上写道文档流量下降了约40%，随后又表示收入下降了约80%。人们选择向AI提问而非查阅文档，因此永远看不到那些为项目提供资金的付费产品。四名工程师中有三人被裁员。Stack Overflow是许多人的编程启蒙地，如今收到的问题量仅为过去的零头。AI学习的来源正在因AI本身而枯竭，而关于下一代模型将从何处学习，目前尚无人能给出好的答案。

还有物理层面的成本。国际能源署预计到2030年，数据中心的用电量将达到约945太瓦时，是当前的两倍多，略高于日本一年的用电量，其中AI是最大的推动力。再加上冷却所需的大量用水。

我们至今支付的代价从来就不是真实的代价。风险投资资金一直在为每一份我们消耗的资源买单，但这种局面已经开始瓦解。GitHub Copilot在6月停止按请求数计费，改为按token计费，Gartner现在预测到2028年，AI编码成本将超过普通开发人员的薪资。

这次调整的规模可能有多大？无人知晓，但我们可以看到情绪转变的速度有多快。2025年1月，当DeepSeek发布一个价格低廉且功能强大的模型时，Nvidia单日市值蒸发约5930亿美元，创下华尔街任何公司单日市值跌幅记录。与此同时，支出仍在持续攀升。Zylo 2026年指数发现，企业对原生AI应用的支出在一年内翻了一番，其9月更新数据显示增幅高达334%。2000年互联网泡沫破裂时，科技行业的规模仅为现在的零头。如今的冲击将波及一个规模更大、对AI依赖更深的领域。

DeepSeek事件带来希望的一面在于，效率可以快速提升。能够以更少资源实现更多功能的模型在成本方面是最佳消息，而我们迫切需要这些模型，因为目前实现人们承诺的一切所需的能源和硬件还远未到位。

我认为AI不会消失。美国和中国在AI上的投入太大，不可能让它消失，我的猜测是，基础AI计算最终会被对待得像道路或电网一样成为基础设施。但“不限量使用”的阶段正在结束，那些在模糊提示和大规模重写上消耗token的团队将最先感受到冲击。

那么我们又该如何应对？

对2027年的一项预测：我们将开始看到专为AI代理而非人类开发者设计的编程语言。这种趋势已经在小范围内出现。今年5月，Vercel Labs开源了Zero，这是一种专为代码代理设计的实验性语言，其编译器能够通过结构化的机器可读指令与代理进行通信。虽然目前还处于早期阶段，且仍由人类设计，但可以预见其发展方向。

坦白说，尽管有上述种种挑战，我最近在构建项目时获得的乐趣是过去几年从未有过的。我可以在周六早晨萌生一个想法，到当天晚上就能看到可运行的原型。而就在不久之前，实现这样的成果需要一个小团队和整个季度的时间。

那么AI究竟是帮助了开发者还是在伤害他们？答案是两者都有，具体取决于开发者的习惯。那些系统化思考、保持变更最小化并在最终决策时保留人类判断的团队表现优异。而那些优先交付初稿、批准无人阅读的代码差异的团队，正在积累尚未意识到的隐患。

这又让我回到那个凌晨2点的警报。问题的解决方案从来都不是"减少使用AI"。真正关键的是确保当凌晨2点出现故障时，团队中至少有一个人真正理解其工作原理。

_你被要求审查的最大的AI生成PR是什么？我很好奇实际应用中会出现多糟糕的代码。_

希望你享受了本次分享并学到了新知识。我始终欢迎在LinkedIn上收到建议和讨论。欢迎通过私信与我联系。

期待下次分享，祝你探索愉快！