AI编程的落地真相调查，30位一线开发者给出了答案

（来源：麻省理工科技评论）

如果你现在去问一个程序员怎么看 AI 编程，可能会得到两种截然不同的回答。

可能有人认为，AI 编程将把软件开发者的生产力推到前所未有的高度；也可能有人批评它只会源源不断地产出设计糟糕的代码，不仅耗尽开发者的注意力，还会让软件项目在长期维护上埋下严重隐患。现阶段，我们很难说哪种判断更接近事实。

在科技巨头向大语言模型（LLM）投入数十亿美元之后，编程已成为这项技术最受推崇的杀手级应用。微软 CEO 萨蒂亚·纳德拉和谷歌 CEO 桑达尔·皮查伊都声称，他们的公司如今大约四分之一的代码由 AI 生成。3 月，Anthropic 的 CEO 达里奥·阿莫代伊还预测，六个月内 90% 的代码都将由 AI 编写。

这种判断听起来似乎既诱人又顺理成章：代码也是一种语言，我们需要大量代码，而人工编写的成本很高；并且代码是否可用也很容易验证，只要运行程序就能立刻看出它是否能正常工作。

科技公司的高管们看中 AI 突破人类效率瓶颈的潜力，正在推动工程师更积极地拥抱 AI 驱动的未来。《麻省理工科技评论》在与 30 多位开发者、科技公司高管、分析师与研究人员交流后发现，实际上现实远没有宣传中那么简单。

随着一次次碰到技术瓶颈，一部分一线开发者的最初热情正在消退。而随着越来越多研究显示，所谓的生产力提升可能只是“幻象”，也有人开始质疑：皇帝是不是根本没穿衣服。

不过，进步速度本身也让问题变得更复杂。新模型的发布的节奏紧密不断，这些工具的能力与脾气都在不停演化；而它们的实际效果，往往取决于具体任务，以及组织围绕它们搭建的流程与结构。所有这些因素叠加起来，让开发者不得不在预期与现实之间的混乱落差中摸索前行。

借用狄更斯的名言来形容 AI 编程：这是最好的时代，还是最坏的时代？

也许两者都是。

一个高速变化的领域

如今，几乎没有开发者能完全绕开 AI 编程工具。相关产品已经多到让人难以分辨优劣：既有 Anthropic、OpenAI、Google 这样的模型开发者提供的工具，也有 Cursor、Windsurf 这类公司把模型封装进打磨精致的代码编辑软件里。根据 Stack Overflow 的 2025 年开发者调查，这些工具正被迅速采用：65% 的开发者如今至少每周使用一次。

AI 编程工具大约在 2016 年出现，但随着 LLM 的到来得到了加速。早期版本几乎只是给程序员做自动补全，提示下一步该敲什么；而今天，它们已经可以分析整个代码库、跨文件编辑、修复 bug，甚至生成解释代码如何工作的文档。所有这些都可以通过聊天界面，用自然语言提示来引导完成。

智能体（agents）是 AI 编程的最新前沿：这类由 LLM 驱动的自主编程工具可以接收一个抽象的目标，然后独立构建完整程序。实现这一跃迁的关键，是最新的推理模型（reasoning models）：它们能把复杂问题拆成步骤逐一解决，更重要的是，还能访问外部工具来完成任务。Anthropic 编程智能体 Claude Code 的负责人 Boris Cherny 说：“正因为如此，模型才是真正在写代码，而不是只会聊编程。”

在软件工程基准测试（用来衡量模型表现的标准化测试）上，这些智能体取得了令人印象深刻的进展。OpenAI 在 2024 年 8 月推出 SWE-bench Verified 基准，为评估智能体在开源代码库中修复真实 bug 的成功率提供了一种方法；当时最强模型只能解决 33% 的问题。一年后，领先模型的得分已稳定超过 70%。

2 月，OpenAI 创始成员、特斯拉前 AI 负责人 Andrej Karpathy 提出了 vibe coding（氛围编程）一词，指的是一种做法：人们用自然语言描述软件需求，让 AI 编写、完善并调试代码。社交媒体上充斥着认同这种愿景的开发者，他们宣称自己的生产力获得了巨大提升。

但尽管一些开发者和公司报告了这样的效率提升，更“硬”的证据却更为复杂。来自 GitHub、Google 和 Microsoft（它们也都是 AI 工具供应商）的早期研究发现，开发者完成任务速度快了 20% 到 55%。不过，咨询公司贝恩（Bain & Company）在 9 月的一份报告中形容，真实世界的节省效果“并不显著”。

开发者分析公司 GitClear 的数据显示，自 2022 年以来，大多数工程师产出的“更耐久的代码”（即不会在几周内被删除或重写的代码）大约增加了 10%，这很可能得益于 AI。但这种提升伴随着多项代码质量指标的明显下滑。Stack Overflow 的调查也发现，人们对 AI 工具的信任和正面情绪首次出现显著下降。

更具挑衅意味的是，非营利研究机构 Model Evaluation & Threat Research（METR）在 7 月的一项研究显示：经验丰富的开发者认为 AI 让他们快了 20%，但客观测试表明他们实际上慢了 19%。

日益增长的幻灭感

对软件咨询公司 Substantial 的首席开发者 Mike Judge 来说，METR 的研究戳中了他的痛点。他曾是 AI 工具的热情早期用户，但随着时间推移，他越来越受挫于这些工具的局限，以及它们对自己生产力带来的有限提升。他说：“我会跟人抱怨，因为我觉得，它确实在帮我，但我就是搞不清怎样才能让它真正大幅帮到我。”他还说：“我总觉得 AI 很笨，但也许只要我找到正确的‘咒语’，就能把它骗得聪明一点。”

朋友问起时，Judge 曾估计这些工具大概能让他提速 25%。所以，当他在 METR 研究中看到开发者给出类似估计时，决定亲自测试。连续六周，他先估算一项任务需要多久，再抛硬币决定用 AI 还是手写代码，然后计时。令他惊讶的是，AI 让他的速度中位数下降了 21%，与 METR 的结果如出一辙。

这促使 Judge 自己动手做了一次数据分析。他推理说，如果这些工具真的让开发者大幅提速，那么应该能看到新应用、网站注册、电子游戏，以及 GitHub 项目数量出现爆发式增长。他花了几个小时、又花了几百美元，分析所有公开可得的数据，结果发现各项曲线几乎都“横着走”。

Judge 说：“这难道不应该向右上方飙升吗？这些图里所谓的‘冰球杆曲线’在哪里？我以为大家都变得异常高产。”他认为，一个显而易见的结论是：对大多数开发者而言，AI 工具提供的生产力提升并不大。

接受《麻省理工科技评论》采访的开发者总体上认可 AI 工具擅长的地方有：生成样板代码（boilerplate code）（指几乎无需修改、在多个地方重复使用的可复用代码片段）、编写测试、修复 bug，以及向新开发者解释陌生代码。有几位指出，AI 能通过提供一个并不完美的初版来帮助解决空白页问题，从而激发开发者的思路。此外，它还可以让非技术同事快速做出功能原型，减轻本就过载的工程师负担。

这些任务往往枯燥，开发者通常乐于把它们交给工具。但其只占资深工程师工作量的一小部分。对于那些更复杂、真正体现工程师价值的难题，许多开发者告诉《麻省理工科技评论》，这些工具仍面临显著挑战。

也许最大的问题在于，LLM 只能在上下文窗口（context window）里容纳有限的信息，这本质上就是它们的工作记忆。这意味着它们很难解析大型代码库，也容易在耗时更长的任务中忘记自己在做什么。Judge 说：“它会变得非常短视，只盯着眼前那一小块。你让它做十二件事，它会做完十一件，然后把最后一件给忘了。”

LLM 的这种“近视”，会让人类程序员非常头疼。LLM 针对某个问题给出的代码，也许单独运行没问题，但软件由成百上千个相互连接的模块组成。如果生成的模块没有考虑软件的其他部分，很快就会导致代码库纠缠不清、前后不一致，让人类难以理解，更重要的是难以维护。

传统上，开发者会通过遵循既定传统（conventions）来应对这一点：也就是一些定义并不严格、但在不同项目与团队之间差异很大的编码准则。

GitClear 的 CEO Bill Harding 说：“AI 有一种压倒性的倾向，即不理解一个代码库里已经存在的既定传统。于是，它很可能会自己想出一种略有不同的解法版本。”

模型也会直接出错。和所有 LLM 一样，编程模型容易产生幻觉，这是它们工作方式内生的问题。但广告技术公司 Mediaocean 的软件工程总监 James Liu 说，因为它们输出的代码看起来非常像模像样，错误反而更难被发现。把这些缺陷叠加起来，使用这些工具的体验就很像拉一台单臂老虎机的把手。Liu 说：“有些项目里，你能在速度或效率上得到 20 倍提升；但在另一些事情上，它会彻底翻车，然后花大量时间试图让它实现你想要的愿望，结果它就是做不到。”

Judge 怀疑，这正是工程师经常高估生产力提升的原因。他说：“你会记住中大奖的时候；但是，你不会记得自己坐在那里往老虎机里塞筹码塞了两小时。”

如果开发者对任务并不熟悉，问题可能更严重。Judge 记得自己曾让 AI 帮忙配置微软的云服务 Azure Functions，而他此前从未用过。他以为大概需要两小时，但九小时后他放弃了。他说：“它不断把我带进一个又一个死胡同，而我对这个主题了解不够，甚至没法对它抱怨‘嘿，这完全不合逻辑’。”

技术债正在被快速堆高

达特茅斯学院工程创新教授 Geoffrey G. Parker 表示，开发者不断在开发速度与代码可维护性之间做权衡，从而产生所谓的“技术债（technical debt）”。每一次走捷径都会增加复杂度，让代码库更难管理，并累积需要通过重构来偿还的“利息”。随着技术债越堆越高，新增功能与维护软件都会变得更慢、更难。

Harding 说，在大多数项目里技术债的累积几乎不可避免，但 AI 工具让时间紧张的工程师更容易走捷径。GitClear 的数据表明，这正在以规模化的方式发生。自 2022 年以来，公司观察到复制粘贴代码的数量显著上升，这表明开发者复用更多代码片段，很可能来自 AI 的建议；与此同时，“代码从一个地方移动到另一个地方”的数量下降得更厉害，而这种移动往往发生在开发者清理、整理代码库时。

代码质量检查工具公司 Sonar 的 CEO Tariq Shaukat 说，随着模型不断改进，它们生成的代码变得越来越冗长、越来越复杂。这会减少明显 bug 和安全漏洞的数量，但代价是代码异味（code smells）增加，也就是更难精准定位、却会导致维护问题与技术债的缺陷。

Sonar 的最新研究发现，在领先 AI 模型生成的代码中，这类问题占其发现问题的 90% 以上。Shaukat 说：“容易发现的问题正在消失，剩下的是更复杂、需要花时间才能找出来的问题。这正是我们目前对这个领域最担心的地方，你几乎会被哄进一种虚假的安全感里。”

乔治城大学的安全研究员 Jessica Ji 表示，如果 AI 工具让代码越来越难维护，可能会引发严重的安全问题。Ji 说：“更新和修复越困难，代码库或任何一段代码随着时间推移变得不安全的可能性就越大。”

她说，还存在更具体的安全担忧。研究人员发现了一类令人不安的“幻觉”：模型会在代码里引用并不存在的软件包。攻击者可以利用这一点，创建同名但含有漏洞的软件包，随后模型或开发者可能在不知情的情况下把它们引入软件中。

LLM 也容易遭受数据投毒攻击（data-poisoning attacks）：黑客向模型训练所用的公开数据集注入数据，以不良方式改变模型行为，例如在特定短语触发下生成不安全的代码。Anthropic 在 10 月的一项研究中发现，无论模型规模多大，只需要 250 份恶意文档就可能向 LLM 引入这种“后门”。

开始转向拥抱 AI 的人

不过，尽管存在这些问题，现实可能已难以回头。微软旗下代码托管平台 GitHub 的首席运营官 Kyle Daigle 说：“很可能，用键盘手工敲下每一行代码的日子，正在迅速成为过去。”GitHub 出品了一款流行的 AI 工具 Copilot（不要与微软同名产品混淆）。

Stack Overflow 的报告发现，尽管人们对这项技术的不信任在加深，但过去三年里使用率仍快速且持续增长。Stack Overflow 的高级分析师 Erin Yepis 表示，这意味着工程师在利用这些工具时，对风险保持相对清醒的认知。报告还发现，高频用户往往更热情；而超过一半的开发者并未使用最新的编程智能体，这也许解释了为什么许多人仍对这项技术感到“不过如此”。

但最新工具也可能带来醍醐灌顶的体验。软件开发机构 Twenty20 Ideas 的 CTO Trevor Dilley 说，他曾觉得 AI 编辑器的自动补全有点价值，但一尝试更复杂的事情就会失败。后来在 3 月，他和家人度假时，让刚发布的 Claude Code 去处理他的一个业余项目。它在两分钟内完成了一项原本要四小时的任务，而且代码比他自己写的还要好。

他说：“我当时就想，对我来说那一刻才是真正的转折点。从这里开始就回不去了。”此后，Dilley 联合创办了名为 DevSwarm 的初创公司，开发能够调度多个智能体并行开发同一软件的系统。

知名开源开发者 Armin Ronacher 认为，难点在于这些工具的学习曲线“起步很浅，但路很长”。到 3 月为止他对 AI 工具仍不以为然，但 4 月他离开软件公司 Sentry 去创业后，开始试验智能体。“我基本上花了好几个月什么都不干，就只做这个。”他说，“现在，我写的代码里 90% 都是 AI 生成的。”

要达到这种程度需要大量试错，以弄清楚哪些问题容易把工具绊倒，哪些问题它们能高效处理。Ronacher 说，只要有合适的护栏，当下模型可以应对大多数编程任务，但这些护栏往往与具体任务和项目高度相关。

兽医人力公司 IndeVets 的 CTO Nico Westerdale 表示，要把这些工具用到极致，开发者必须放弃对每一行代码的控制，把注意力转向整体软件架构。他最近构建了一个数据科学平台，代码量达 10 万行，几乎完全是通过提示模型来完成，而不是自己逐行编写。

Westerdale 的流程从与模型进行一段较长对话开始，用来形成“要做什么、怎么做”的详细计划；接着，他再引导模型一步步执行。模型很少一次就能做对，需要持续“拽着走”，但 Westerdale 说，只要你强制它遵循明确的设计模式，模型就能生成高质量、易维护的代码。他会审查每一行，并表示这些代码不比他过去产出的任何作品差：“我觉得它完全是革命性的。当然，它也很让人挫败、很难、是一种不同的思考方式，而我们才刚刚开始适应。”

但当个体开发者逐渐学会有效使用这些工具时，要在大型工程团队里获得一致的效果就难得多。Google 产品管理高级总监 Ryan J. Salva 说，AI 工具会放大工程文化中的优点与缺点：如果你有强流程、清晰的编码模式、定义明确的最佳实践，它们就能大放异彩。

但如果你的开发流程本来就混乱，它们只会把问题放大。同样关键的是把组织内部的经验知识制度化、文档化，让模型能够有效调用。Salva 说：“为了建立足够的上下文、把那些口耳相传的隐性知识从我们脑子里拿出来，有大量工作要做。”

加密货币交易所 Coinbase 一直高调谈论自己对 AI 工具的采用。CEO Brian Armstrong 在 8 月披露公司解雇了不愿使用 AI 工具的员工，一度引发关注。但 Coinbase 的平台负责人 Rob Witoff 告诉《麻省理工科技评论》，尽管他们在某些方面看到了生产力的巨大提升，但整体效果却并不均衡。对重构代码库、编写测试这类更简单的任务，AI 驱动的工作流最高能实现 90% 的提速；但对其他任务，提升更有限，而且改造既有流程带来的扰动往往会抵消编码速度的增长，Witoff 说。

其中一个因素是，AI 工具让初级开发者能够产出更多代码。像几乎所有工程团队一样，这些代码必须由其他人（通常是更资深的开发者）进行评审，以发现 bug 并确保符合质量标准。但如今被“卷”出来的代码量之大，正在迅速压满中层人员审查变更的能力。Witoff 说：“我们几乎每个月都在经历这样一个循环：我们在技术栈更底层自动化了一件新事，于是更上层就承受更大压力。然后我们又开始考虑把自动化应用到更上层的部分。”

贝恩合伙人 Jue Wang 说，开发者真正用于写代码的时间只有 20% 到 40%，所以即便编码本身大幅提速，整体收益也往往更为有限。开发者其余时间要用于分析软件问题、处理客户反馈、产品策略以及行政事务。Jue 表示，要获得显著的效率提升，公司可能也需要把生成式 AI 应用于这些其他流程，但这仍在推进之中。

飞速迭代

用智能体来编程与以往工作方式差异巨大，所以公司会遇到“长牙期”的问题并不意外。况且这些产品都很新，几乎每天都在变。Anthropic 的 Cherny 说：“每隔几个月模型就会变强，编码能力会出现一次大的阶跃式提升，你就必须重新校准自己的使用方式。”

例如，Anthropic 在 6 月为 Claude 引入了内置的规划模式（planning mode），后来也被其他提供商效仿。10 月，公司又让 Claude 在需要更多上下文或面对多种可行解法时向用户提问。Cherny 指出，这有助于它避免“直接自作主张地认为某条路径最好”的倾向。

最重要的是，Anthropic 增加了一些功能，让 Claude 更擅长管理自己的上下文。Cherny 说，当它接近工作记忆的上限时，会自动总结关键细节，并基于这些总结开启一个新的上下文窗口，从而在效果上拥有一个“无限”的窗口。Claude 还可以调用子智能体（sub-agents）处理更小的任务，这样它就不必把项目的所有方面都同时装在“自己脑子里”。公司声称，其最新模型 Claude 4.5 Sonnet 现在可以连续自主编码超过 30 小时，而不会出现明显的性能衰减。

软件开发中的新方法也可能绕开编程智能体的其他缺陷。MIT 教授 Max Tegmark 提出一种他称为 vericoding 的概念，可能让智能体从自然语言描述出发生成完全没有 bug 的代码。它基于形式化验证（formal verification）方法：开发者为软件建立数学模型，从而无可辩驳地证明其功能正确。这种方法用于飞行控制系统、密码学库等高风险领域，但由于成本高、耗时长，一直限制了其更广泛的应用。

Tegmark 说，LLM 数学能力的快速提升带来一个诱人的可能性：模型不仅能产出软件，还能给出无 bug 的数学证明。“你只要给出规格说明，AI 就会返回可被证明正确的代码，”他说，“你不需要碰代码，甚至都不必看代码。”

根据 Tegmark 团队一项未经同行评审的研究，在 Dafny（为形式化验证设计的语言）中大约 2,000 个 vericoding 题目上测试时，表现最好的 LLM 解决了超过 60%。这一结果是在“开箱即用”的通用 LLM 上实现的，Tegmark 预计，如果针对 vericoding 做专门训练，得分可能会快速提升。

但出乎意料的是，AI 生成代码的速度也许反而能缓解可维护性的担忧。商业软件巨头 Intuit 的首席工程师 Alex Worden 指出，维护之所以困难，往往是因为工程师在不同项目间复用组件，形成一团依赖关系：一次改动会在整个代码库里引发连锁反应。过去复用代码能节省时间，但在一个 AI 几秒钟就能生成数百行代码的世界里，这种必须复用的动力已经消失了。

因此，他主张可弃用代码（disposable code）：每个组件都由 AI 独立生成，不必考虑它是否遵循某种设计模式或约定；然后再通过 API（让组件彼此请求信息或服务的一组规则）把它们连接起来。Worden 说，由于每个组件的内部实现不依赖代码库的其他部分，就可以在不产生更大影响的情况下将其替换或移除。

他说：“行业仍在担心人类如何维护 AI 生成的代码。但我怀疑人类还会看代码、或在乎代码多久。”

程序员的人才梯队正在变窄

不过在可预见的未来，人类仍需要理解并维护支撑项目运行的代码。而 AI 工具最隐蔽、也最棘手的副作用之一，可能是能胜任这项工作的人才池在缩小。

一些早期证据表明，人们对 AI 摧毁岗位的担忧可能并非空穴来风。斯坦福大学最近的一项研究发现，在 2022 年到 2025 年间，22 到 25 岁软件开发者的就业人数下降了近 20%，这与 AI 编程工具的兴起时间相吻合。

资深开发者也可能遇到困难。游戏基础设施开发公司 Companion Group 的工程师 Luciano Nooijen 在日常工作中大量使用 AI 工具，因为公司免费提供；但当他开始一个无法使用这些工具的副业项目时，他发现自己竟在过去本能完成的任务上频频卡壳。“我感觉自己很蠢，因为以前凭直觉就能做的事变成了手工操作，有时甚至很笨重。”Nooijen 说。

与运动员仍要做基础训练类似，他认为保持编码“手感”的唯一方式，就是定期练习那些苦活累活。这也是他基本弃用 AI 工具的原因，尽管他承认背后也还有更深层的动机。

Nooijen 和《麻省理工科技评论》采访到的其他开发者之所以抵触 AI 工具，部分原因在于他们认为：这些工具正在掏空工作中他们热爱的那部分。“我进入软件工程行业，是因为我喜欢和计算机打交道，我喜欢让机器按我想要的方式做事。”Nooijen 说，“但如果只是坐在那里，看着原本属于我的工作被代劳，那一点也不好玩。”

https://www.technologyreview.com/2025/12/15/1128352/rise-of-ai-coding-developers-2026/