每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/

取决于你问的是谁，AI 驱动的编码要么正为软件开发者带来前所未有的生产力提升，要么就是在产出大量设计粗糙的代码，分散他们的注意力，并为软件项目埋下严重的长期维护隐患。

问题在于，就在当下，我们并不容易判断哪种说法才是真的。

随着科技巨头向大型语言模型（LLMs）投入数十亿美元，编码一直被吹捧为这项技术的“杀手级应用”。微软 CEO 萨提亚·纳德拉和谷歌 CEO 桑达尔·皮查伊都声称，他们公司大约四分之一的代码如今由 AI 生成。而在 3 月，Anthropic 的 CEO 达里奥·阿莫代（Dario Amodei）预测，在六个月内，90% 的代码都将由 AI 编写。这是一个既诱人又显而易见的用例。代码是一种语言，我们需要大量代码，而手工编写代价高昂。并且判断它是否奏效也很容易——运行程序，是否可用立刻便知。

热衷于突破人类瓶颈的高管们正在推动工程师拥抱一个由 AI 驱动的未来。但在与 30 多位开发者、技术高管、分析师和研究人员交谈后，发现，实际图景并不像看上去那样简单。

对一些一线开发者而言，最初的热情正在消退，因为他们不断撞上技术的局限。而且，随着越来越多研究表明所谓的生产力提升可能是海市蜃楼，一些人开始怀疑皇帝是否真的穿了衣服。

不过，进展的速度又让局面更加复杂。新模型持续发布的鼓点意味着这些工具的能力与“怪癖”在不断演变。它们的效用也常常取决于所应用的具体任务，以及围绕它们建立起来的组织结构。所有这一切让开发者在期望与现实之间的落差中艰难导航。

如果借用狄更斯的话，现在是 AI 编程的“最好的时代”还是“最坏的时代”？也许两者兼而有之。

一个快进中的领域
如今很难避开 AI 编程工具。市面上有令人眼花缭乱的产品——既有来自 Anthropic、OpenAI、谷歌等模型开发商的，也有来自 Cursor、Windsurf 等公司、把这些模型包装进打磨精良的代码编辑软件里的。根据 Stack Overflow 2025 年开发者调查，采用速度正在迅速提升，如今有 65% 的开发者至少每周使用一次这些工具。

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

“代理”（agents）——能接受高层次计划并自主构建完整程序的 LLM 驱动编码工具——代表了 AI 编程的最新前沿。这一跃进得益于最新的推理模型：它们能一步步解决复杂问题，并且关键在于，能够调用外部工具完成任务。“这就是模型不仅能‘谈论如何编码’，而是真正‘能够编码’的方式，”Anthropic 编码代理 Claude Code 负责人鲍里斯·切尔尼（Boris Cherny）说。

Ask AI
Why it matters to you?
BETA
以下是 AI 认为这篇报道可能与你相关的原因。这是 beta 功能，AI 会出现幻觉——它可能会有点怪
An industry I care about is
industry
.
Tell me why it matters
了解我们如何使用 AI。

这些代理在软件工程基准测试上取得了令人印象深刻的进步——基准测试用于衡量模型表现。OpenAI 在 2024 年 8 月推出 SWE-bench Verified 基准，用于评估代理在开源代码库中修复真实缺陷的成功率时，最顶尖的模型仅能解决 33% 的问题。一年后，领先模型已能稳定超过 70%。

2 月，OpenAI 创始成员、特斯拉前 AI 总监安德烈·卡帕西（Andrej Karpathy）提出了“vibe coding（氛围编程）”这一术语——指一种由人用自然语言描述软件、让 AI 来编写、打磨与调试代码的方式。社交媒体上到处都是投身这一愿景的开发者，他们声称生产力大幅提升。

不过，尽管一些开发者和公司确实报告了此类效率提升，硬证据却更为复杂。来自 GitHub、谷歌和微软（均为 AI 工具供应商）的早期研究显示，开发者完成任务的速度提升了 20% 到 55%。但咨询公司贝恩在 9 月发布的一份报告则称，现实世界的节省“并不抢眼”。

开发者分析公司 GitClear 的数据表明，自 2022 年以来，大多数工程师产出的“可存续代码”（在数周内不会被删除或重写的代码）大约增加了 10%，这很可能要归功于 AI。但这项增益伴随着多个代码质量指标的明显下降。Stack Overflow 的调查也发现，针对 AI 工具的信任度与正面情绪首次出现显著下滑。更具挑衅性的是，非营利研究机构 METR（Model Evaluation & Threat Research）在 7 月的一项研究显示，尽管有经验的开发者认为 AI 让他们快了 20%，但客观测试却表明他们实际上慢了 19%。

日益增长的失望
对软件咨询公司 Substantial 的首席开发者迈克·贾奇（Mike Judge）来说，METR 的研究可谓一针见血。他曾是 AI 工具的热情早期采用者，但随着时间推移，他对这些工具的局限与仅有温和的生产力提升感到沮丧。“我跟人抱怨说，‘它确实有帮助，但我怎么也找不到让它大幅帮上忙的方法，’”他说。“我老觉得 AI 很笨，但也许我能通过某种魔法咒语把它‘哄’聪明。”

当朋友问起时，贾奇估算这些工具能带来大约 25% 的加速。所以当他看到 METR 研究中开发者给出的类似估计时，他决定自测。六周里，他先猜测任务所需时间，再掷硬币决定是否使用 AI 或手写代码，并对实际耗时计时。让他吃惊的是，AI 让他的中位耗时增加了 21%——与 METR 的结果如出一辙。

这让贾奇开始仔细算账。如果这些工具真能加速开发者，你应当会看到新应用、网站注册、电子游戏以及 GitHub 项目数量的爆发式增长。他花了数小时与数百美元分析所有公开可得的数据，结果处处是一条条水平线。

“这些曲线不应该一路向上、往右走吗？”贾奇说。“这些图上‘冰球杆’曲线在哪儿？我还以为大家都异常高产呢。”他得出的直接结论是：对大多数开发者而言，AI 工具提供的生产力提升非常有限。

接受采访的开发者们普遍认同 AI 工具擅长的领域：产出“样板代码”（在多个位置重复使用、几乎无需改动的可复用代码块）、编写测试、修复 bug，以及向新加入的开发者解释不熟悉的代码。也有多人提到，AI 有助于克服“空白页难题”，先给出一个不完美的初稿来激发开发者的创作思路。它还可以让非技术同事快速做出软件功能原型，减轻本已超负荷的工程师的压力。

这些任务往往枯燥，开发者通常乐于交给 AI。但它们仅占资深工程师工作量的一小部分。对于那些真正体现工程师价值的更复杂问题，许多受访者表示，这些工具还面临重大障碍。

也许最大的难题是，LLM 的“上下文窗口”——本质上就是其工作记忆——容量有限。这意味着它们难以解析庞大的代码库，也容易在长任务中“忘事”。“它会变得非常近视——只看眼前这一小块，”贾奇说。“如果你让它做一打事，它会完成 11 件，然后把最后一件忘了。”

DEREK BRAHNEY
LLM 的“短视”会给人类程序员带来头疼。虽然模型对某个问题给出的回答可能在孤立环境下有效，但软件是由数百个相互关联的模块构成的。如果这些模块在构建时没有考虑到软件的其他部分，很快就会导致一团乱麻、风格不一的代码库，让人难以理解，更重要的是难以维护。

开发者传统上通过遵循“约定”（各项目与团队差异很大的、松散定义的编码指南）来应对这一点。GitClear CEO 比尔·哈丁（Bill Harding）说：“AI 有一种压倒性的倾向：它不理解某个代码库内部既有的约定，因此很可能自己捏造出一个略有不同的解决方式。”

模型也会犯错。和所有 LLM 一样，编码模型容易“幻觉”——这是其工作方式内在的问题。但由于它们生成的代码看起来如此体面，错误反而难以及时发现，广告科技公司 Mediaocean 的软件工程总监刘杰明（James Liu）说。把这些缺点叠加起来，使用这些工具感觉就像在玩“老虎机”——拉下摇杆碰碰运气。“有些项目你会得到 20 倍的速度或效率提升，”刘说，“另一些就会摔个大跟头，然后你花大量时间哄它满足你的心愿，但它就是做不到。”

贾奇怀疑这就是工程师常常高估生产力增益的原因。“你只记得中大奖的那些瞬间。你不会记得自己连续两个小时在不停地往老虎机里塞筹码，”他说。

而且如果开发者对任务不熟悉，这种问题会更糟。贾奇记得曾让 AI 帮忙配置微软的一项云服务 Azure Functions，他之前从未用过。他估计两小时能搞定，但折腾了九个小时后只好认输。“它一直带我钻各种兔子洞，而我对这个主题了解不够，无法指出‘嘿，这不合逻辑’，”他说。

债务开始累积
达特茅斯学院工程创新教授杰弗里·G·帕克（Geoffrey G. Parker）表示，开发者常常在开发速度与代码可维护性之间做权衡——这会产生所谓的“技术债”。每一次走捷径都会增加复杂度，让代码库更难管理，并积累必须最终通过重构来“偿还”的“利息”。随着这笔债务越滚越大，添加新功能和维护软件会越来越慢、越来越困难。

在大多数项目中，积累技术债不可避免，但 GitClear 的哈丁说，AI 工具让时间紧任务重的工程师更容易抄近路。而 GitClear 的数据表明，这一现象正在规模化发生。自 2022 年以来，公司观察到“复制粘贴”代码量显著上升——这表明开发者在重用更多代码片段，很可能是基于 AI 的建议——与此同时，从一个位置移动到另一个位置的代码量显著下降，而这种“移动”通常出现在开发者清理代码库时。

随着模型改进，它们产出的代码变得越来越冗长且复杂，代码质量检测工具公司 Sonar CEO 塔里克·肖卡特（Tariq Shaukat）说。这确实在减少显而易见的 bug 与安全漏洞，但代价是增加了“代码异味”（code smells）——那些更难界定、却会导致维护问题与技术债的缺陷。

Sonar 的最新研究发现，在领先 AI 模型生成的代码中，此类问题占到 90% 以上。“容易发现的问题正在消失，剩下的是更为复杂、需要很久才能定位的问题，”肖卡特说。“这正是我们目前对这个领域的担忧。你几乎会被一种虚假的安全感所麻痹。”

如果 AI 工具让维护代码变得越来越困难，那可能带来重大的安全影响，乔治城大学的安全研究员季洁西卡（Jessica Ji）说。“越难以更新和修复，某个代码库或代码片段随着时间推移变得不安全的可能性就越高，”她说。

她还指出了一些更具体的安全担忧。研究者发现了一类令人担心的“幻觉”，即模型在代码中引用并不存在的软件包。攻击者可以利用这一点，创建带有漏洞的同名包，模型或开发者可能在不知不觉中将其纳入软件。

LLM 也易受“数据投毒攻击”影响：黑客会在模型的公开训练数据集中投放恶意数据，从而改变模型在特定触发词下的行为，例如生成不安全的代码。10 月，Anthropic 的研究发现，即便只投放 250 份恶意文档，也能在不受模型规模影响的情况下为 LLM 植入这种“后门”。

已然“皈依”的人
尽管存在这些问题，但大概已经没有回头路了。微软旗下代码托管平台 GitHub（生产一款广受欢迎的 AI 编程工具 Copilot，别与微软同名产品混淆）的首席运营官凯尔·达伊格尔（Kyle Daigle）说：“很可能手指在键盘上逐行写代码的时代——正在迅速离我们远去。”

Stack Overflow 的报告发现，尽管对这项技术的信任在下降，但过去三年里使用率却持续且迅速地攀升。Stack Overflow 高级分析师 Erin Yepis 表示，这说明工程师们在清醒认识风险的情况下也在利用这些工具。报告还发现，重度用户往往更为热情，并且有超过半数开发者并未使用最新的编码代理，这也许解释了为何许多人对这项技术仍感到不那么惊艳。

最新一代工具可能会令人眼前一亮。软件开发机构 Twenty20 Ideas 的 CTO 特雷弗·迪利（Trevor Dilley）说，他曾在 AI 编辑器的自动补全里找到些许价值，但只要尝试更复杂的任务，它们就会“灾难性地失败”。然而在 3 月，与家人度假时，他让新发布的 Claude Code 处理自己的一个业余项目。它在两分钟内完成了一个需要四小时的任务，而且代码比他自己写的还要好。

“我当时就想，哇哦，”他说。“对我来说，那就是转折点。从此再也回不去了。”此后，迪利联合创办了一家名为 DevSwarm 的初创公司，正在打造能让多个代理并行协作开发软件的工具。

开源社区知名开发者阿明·罗纳彻（Armin Ronacher）表示，挑战在于，这些工具的学习曲线“浅而长”。直到 3 月他还对 AI 工具不以为然，但在 4 月离开软件公司 Sentry 创办初创企业后，他开始试验代理。“我基本上花了几个月的时间只做这件事，”他说。“现在，我写的代码有 90% 是由 AI 生成的。”

要达到这一步，需要大量试错，以弄清哪些问题会绊倒工具、哪些问题它们能高效处理。罗纳彻说，只要有合适的“护栏”，如今的模型可以解决大多数编码任务，但这些护栏会非常依赖具体任务和具体项目。

要最大化这些工具的价值，开发者必须放弃对“每一行代码”的控制，把注意力放在整体软件架构上，IndeVets（兽医人力配置公司）的首席技术官尼科·韦斯特戴尔（Nico Westerdale）说。他最近几乎完全靠给模型下提示、而非自己写代码，构建了一个 10 万行代码的数据科学平台。

韦斯特戴尔的流程从与模型进行长时间对话开始，以拟定详细的构建计划与方法。随后他引导模型一步步执行。模型很少在第一次尝试中就把事情做对，往往需要持续“驯服”，但如果你强迫它遵循定义明确的设计模式，模型就能产出高质量、易维护的代码，他说。他会逐行评审，他认为这些代码与他职业生涯中产出的最佳代码旗鼓相当：“我觉得这绝对是革命性的，同时它也令人沮丧、很难用，是一种不同的思维方式，而我们才刚刚开始习惯它。”

不过，尽管个别开发者正在学习如何有效使用这些工具，要在庞大的工程团队中获得稳定一致的结果要困难得多。谷歌产品管理高级总监瑞安·J·萨尔瓦（Ryan J. Salva）说，AI 工具会放大你工程文化中的好与坏两面。如果流程扎实、编码模式清晰、最佳实践定义明确，这些工具就会发光。

DEREK BRAHNEY
但如果你的开发流程很乱，它们只会放大问题。同样重要的是把这些“部落知识”（隐性经验）制度化，让模型能够有效利用。“我们需要做大量工作来建立上下文，把那些藏在我们脑子里的经验‘挖’出来，”他说。

加密货币交易所 Coinbase 一直高调拥抱 AI 工具。8 月，CEO 布莱恩·阿姆斯特朗（Brian Armstrong）因透露公司解雇了不愿采用 AI 工具的员工而登上新闻头条。但 Coinbase 平台负责人罗布·维托夫（Rob Witoff）告诉《麻省理工科技评论》，尽管他们在某些领域看到了巨大的生产力提升，整体影响却参差不齐。对于诸如重构代码库、编写测试这类较简单的任务，AI 驱动的工作流可实现高达 90% 的加速。但在其他任务上的增益更为温和，而且为推行新流程所造成的扰动往往抵消了编码速度的提升，维托夫说。

一个因素是，AI 工具让初级开发者能产出更多代码。与几乎所有工程团队一样，这些代码需要他人（通常是资深开发者）进行评审，以发现 bug 并确保符合质量标准。但如今 churn 出来的代码量很快就让中级员工的评审能力饱和。“我们几乎每个月都在经历这样一个循环：把栈底的某件事自动化，又给更高层带来更大压力，”他说。“然后我们就开始考虑把自动化应用到更高层的那部分。”

贝恩的合伙人王珏（Jue Wang）说，开发者实际上只有 20% 到 40% 的时间在编码，因此即便编码环节显著提速，折算到整体效率上的增益往往也比较温和。开发者的其余时间花在分析软件问题、处理客户反馈、产品策略以及行政事务上。若要获得显著的效率提升，公司可能需要把生成式 AI 应用于所有这些其他流程上，而这仍在推进中，王珏说。

快速演化
用代理来编程与以往的工作方式有着戏剧性的差异，因此公司面临一些“出牙期”问题并不奇怪。这些产品也非常新，且几乎每天都在变化。“每隔几个月，模型就会改进一次，编码能力发生大的跃迁，你就得重新校准，”Anthropic 的切尔尼说。

例如，6 月 Anthropic 在 Claude 中引入了内置的“规划模式”；此后其他供应商也跟进复制。10 月，该公司还让 Claude 在需要更多上下文或面临多种可能方案时，可以主动向用户提问，切尔尼称这有助于避免模型仅凭想当然就选择一条路径的倾向。

最重要的是，Anthropic 增加了使 Claude 更好地管理自身上下文的功能。当接近工作记忆极限时，Claude 会总结关键信息并以此开启新的上下文窗口，切尔尼称这等效于给了它一个“无限”的上下文。Claude 还能调用子代理来处理更小的任务，因此它不再需要把项目的所有方面都“装在自己脑子里”。该公司声称其最新模型 Claude 4.5 Sonnet 现在可以在没有明显性能退化的情况下，连续自主编写代码超过 30 小时。

新的软件开发方法也可能绕开编码代理的其他缺陷。麻省理工学院教授马克斯·泰格马克（Max Tegmark）提出了他所谓的“vericoding（可证编码）”，这可能允许代理从自然语言描述直接产出完全无 bug 的代码。它建立在“形式化验证”的方法之上：开发者为软件创建数学模型，以无可辩驳地证明其行为正确。这一方法已用于飞控系统、密码库等高风险领域，但成本高、耗时长，限制了更广泛的使用。

LLM 在数学能力上的快速提升，打开了一个令人心动的可能：模型不仅能生成软件，还能给出证明其“无 bug”的数学证明，泰格马克说。“你只需给出规格说明，AI 就把可被证明正确的代码返回给你，”他说。“你不必去碰代码，甚至永远不必看代码。”

在大约 2000 道 Dafny（为形式化验证设计的语言）的可证编码问题上测试时，表现最好的 LLM 解出了 60% 以上，根据泰格马克团队未经过同行评审的研究。这个成绩是在使用“现成”LLM 的情况下获得的，而泰格马克预计，若针对可证编码进行专门训练，分数将快速提高。

反直觉的是，AI 生成代码的速度之快，实际上可能缓解可维护性顾虑。财务软件巨头 Intuit 的首席工程师亚历克斯·沃登（Alex Worden）指出，维护之所以困难，常常是因为工程师在多个项目间复用组件，从而形成错综复杂的依赖网络，一个变动会在代码库中引发连锁反应。过去复用代码能为开发者省时，但在一个 AI 能在几秒钟内生成上百行代码的世界里，这种必要性不复存在，沃登说。

因此，他倡导“可抛弃代码”——每个组件都由 AI 独立生成，而不考虑是否遵循既定的设计模式或约定。它们通过 API 相互连接——API 是一组规则，允许组件相互请求信息或服务。每个组件的内部实现不依赖于代码库的其他部分，因此可以在不影响整体的情况下直接替换，沃登说。

“业界仍在担心人类维护 AI 生成的代码，”他说。“我在想，人类还会看代码、在乎代码多久呢？”

收窄的人才管道
在可预见的将来，人类仍需要理解并维护支撑其项目的代码。而 AI 工具最阴险的副作用之一，可能是让具备这种能力的人越来越少。

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

资深开发者也可能面临困难。视频游戏基础设施开发商 Companion Group 的工程师卢西亚诺·努因（Luciano Nooijen）在日常工作中大量使用 AI 工具（由公司免费提供）。但当他启动一个没有这些工具可用的副业项目时，发现自己在以前驾轻就熟的任务上也开始举步维艰。“我感觉自己变笨了，以前的本能变成了手动操作，有时甚至很繁琐，”努因说。

就像运动员仍需做基础训练一样，他认为维持对编码的“直觉”的唯一方式就是定期练习这些“苦功”。这也是他基本放弃 AI 工具的原因之一，尽管他也承认，背后还有更深层的动机。

努因采访的其他一些开发者之所以对 AI 工具持保留态度，部分原因在于，他们觉得这些工具正在掏空他们热爱这份工作的那部分。“我进入软件工程这个领域，是因为我喜欢和计算机打交道。我喜欢让机器去做我想让它做的事，”努因说。“坐在那里看着我的工作被替我完成，这一点也不好玩。”