Anthropic CEO 称 AI 将在 3-6 个月内编写 90% 的代码 — 证据显示了什么
- Aisha Washington
- 6月6日
- 讀畢需時 11 分鐘
已更新：6月18日
为什么“AI 编写 90% 的代码”这一说法至关重要
一句话如何波及市场、团队和新闻编辑室
在 2025 年 3 月，Anthropic CEO Dario Amodei做出了一个引人注目的预测：AI 可能会在三到六个月内编写 90% 的代码。这一言论迅速在科技动态和商业版面上传播，引发了股市波动、工程组织内部的 Slack 辩论，以及报道开发者工具和企业风险的记者们提出的一系列紧迫问题。对于许多读者来说，这一主张压缩了一个熟悉的模式：AI 的每一次重大进步，既激发了对生产力提升的乐观情绪，也引发了对安全、就业和治理的焦虑。
多家新闻机构报道了 Anthropic 的预测，随后的几篇后续报道质疑了该主张的时间表和范围；本文综合了这些对话以及已发表的研究和安全审计，以提供一个务实的视角。
“AI 编写 90% 的代码”在功能和输出方面究竟需要什么
从单文件补全到全项目交付
说 AI 将“编写 90% 的代码” 是对一系列能力的简写，这些能力远超许多开发者已经依赖的自动补全功能。为了达到这一水平，系统需要在以下维度持续产生生产级的输出：
多文件项目综合：设计、生成和更新多个源文件的能力，以确保整个应用程序能够按预期编译和运行。
准确的 API 编排：正确调用库、遵循身份验证流程并编排模块，使运行时行为符合规范。
可靠的测试与 CI 集成：生成覆盖关键路径的单元测试和集成测试，并与构建系统及持续集成流水线集成。
保持行为一致的安全重构：在不引入回归缺陷的情况下修改现有代码库，并生成能通过现有测试套件的变更集。
默认安全模式：避免常见漏洞（注入、反序列化不安全、不安全的依赖使用），并遵守许可和溯源限制。
目前，这些能力中的许多在现有工具中尚处于萌芽阶段。开发者经常在 IDE 插件和云端工具中使用行内自动补全、单函数生成和单元测试建议，这降低了处理小型局部任务的阻力。例如，在编辑器扩展和云端 IDE 中，提供函数级脚手架或建议测试用例的工具已非常普遍。但在这些产品级功能与可靠交付完整的、多模块系统的能力之间，仍存在巨大差距。
在评估相关声明时，请观察输出的实际特征：生成速度（生成一个模块需要多长时间）、生成模块的大小和复杂度（单函数 vs. 服务层）、语言和框架支持、依赖管理（AI 是否选择了兼容的库版本？），以及随附测试的质量和覆盖率。一个生成单个文件的华丽演示固然令人印象深刻，但并不等同于一个能够编排二十个服务的变更、更新 infra-as-code 并通过生产测试的系统。
洞察：记者应询问厂商，其演示是否包含完整的端到端流程——包括编译、测试套件和部署步骤——还是仅限于单文件预览。
关于当前能力和失效模式的研究基准，请参阅衡量代码合成与补全的学术评估，这些评估强调了模型在小范围内的优势，以及在跨大上下文和有状态系统推理时的弱点关于代码生成模型的研究。对 Amodei 言论及随之而来的辩论的报道，也有助于界定公众的反应和预期WindowCentral 总结了该预测及其背景。
核心结论：令人印象深刻的单文件结果并不等同于生产级的项目生成；请要求提供编译、测试通过率和依赖解析的证据。
AI 生成代码的基准测试、安全率和模型性能
基准测试衡量了什么以及遗漏了什么
基准测试（Benchmarks）是我们拥有的最具体的信号，但正确解读它们至关重要。学术界和工业界的评估通常衡量诸如根据 docstring 合成短函数、补全部分编写的代码或为孤立方法生成单元测试等任务。这些测试体现了模型在局部推理、模式匹配和 API 熟悉度方面的能力。然而，它们很少衡量端到端的软件交付——例如编译大型项目、运行集成测试或确保生产系统中的运行时安全。
已发布的模型基准测试显示，在 token 级补全和通过合成单元测试方面有稳步提升，但这些进步并不能直接转化为完全可信的、系统级的替代方案。对于研究人员来说，代码生成文献中总结的基准测试提供了一种标准化的模型比较方式，但它们在上下文长度、长程依赖以及跨文件的语义正确性方面也存在已知的盲点参见代码生成研究摘要。
安全性是一个独立但具有决定性的约束条件。多项分析和测试练习发现，生成的代码中有相当一部分包含缺陷——从不安全的默认设置到开启攻击面的逻辑错误。一份关于此类发现的报告指出，在测试样本中，近一半的 AI 生成代码包含安全问题，这为重视安全和合规性的生产系统带来了不小的采用障碍近一半的 AI 生成代码存在安全缺陷。
在比较供应商的说法时，记者和工程师应要求提供以下指标：
模型架构和规模，以及训练语料库及其出处（使用了哪些代码以及采用了哪些许可证）的说明。
大型项目的延迟和吞吐量（生成或重构多模块系统需要多长时间）。
在标准基准测试和具有代表性的企业代码库（而非仅仅是玩具数据集）上的测试通过率。
通过独立安全审计或红队演练衡量的经验性漏洞率。
供应商声明中通常缺失的关键规格，例如训练数据来源（训练样本的来源）、发现漏洞时模型的更新机制，以及是否提供针对正确性或修复的 SLA 级保证。这些差距至关重要，因为企业在受监管环境中部署代码时，需要可追溯性和可预测的行为。
洞察：安全发现不仅是学术性的，它们应该影响采购和 QA 政策。当供应商声称已具备生产就绪能力时，请索要独立的红队或蓝队报告。
核心结论：基准测试显示了局部任务的真实进展；安全分析显示了大规模应用下的真实风险。两者都必须纳入评估体系。
推广时间线与市场采纳度 —— AI 在 3-6 个月内编写 90% 的代码现实吗？
时间线与现实世界的阻力
Amodei 的时间线（3 到 6 个月）引发了媒体的迅速放大和一些尖锐的反驳。报道范围从对预测的直接报道到将其描述为炒作的怀疑观点；一些行业人士认为，考虑到当前的限制，90% 这一数字并不现实。Benzinga 和 WebsitePlanet 等渠道迅速报道了这一预测，帮助该声明触达了投资者和开发者群体。Benzinga 对 Amodei 预测的报道 和 WebsitePlanet 对该声明的摘要。
市场采纳信号则更为审慎。企业正迅速试点并采用 AI 编程助手来处理生产力任务，许多团队报告在样板代码编写和常规重构方面取得了具体的效率提升。Financial Times 关于企业采纳情况的报道强调了企业兴趣的日益增长，但同时也强调，采纳并不等同于全面取代人工创作；大多数组织仍保留人工参与，以负责审查、合规和集成工作 FT 关于采纳趋势的报道。
法规和标准也减缓了大范围部署。在受监管行业运营的企业必须符合采购规则、安全标准，以及有时特定的行业合规机制。现有的 ISO 标准和持续进行中的标准制定工作建立了治理预期，工具在被委以关键代码库重任之前必须满足这些预期 ISO 标准背景。同样，主要市场中待定的立法和采购框架要求进行可追溯性和风险评估，这使集成进度增加了数月之久。
记者应重点关注的实际推广障碍包括集成工作（将 AI 输出连接到 CI/CD 流水线中)、合规性检查（许可证溯源和数据隐私）、安全审计（自动化和人工审查），以及更新 QA 流水线以验证生成的输出。这些流程很容易使时间线超出原始模型准确率提升所需的范畴。
行业反应中也包含了一些谨慎的声音；例如，Linus Torvalds 的反应——在某些报道中称 90% 这个数字是“炒作”——说明了管理大型复杂代码库的从业者所持的怀疑态度India Today 报道称，批评意见。
核心结论： 模型性能的快速提升固然重要，但考虑到治理、集成和安全等现实因素，三到六个月的时间表过于乐观。
当前 LLM 编程工具与 90% 这一说法之间的差距
当今的助手工具在哪些方面表现可靠，以及在哪些方面存在不足
当前的 LLM 编程工具擅长特定的、有界限的任务：自动补全、生成简短的辅助函数、创建样板代码以及为孤立单元建议测试。开发者利用这些功能来加速日常工作并快速构建原型。然而，当模型必须跨大型代码库进行推理、管理有状态交互或做出需要长期上下文的架构级设计决策时，其性能表现就会受限。
研究对比显示，模型代际更迭在基准任务上带来了显著提升，但同时也呈现出一种模式：在跨文件推理和安全稳健性等方面的进展陷入停滞 代码生成研究。与此同时，安全测试凸显了持续存在的漏洞：独立分析发现，高比例的生成代码片段包含缺陷，这一问题在各大主流模型中普遍存在 TechRadar 的安全调查结果。
记者在报道厂商发布的消息时，应将宣称的指标与学术基准进行比对。请厂商提供：
在标准及企业级基准测试中的测试通过率。
来自独立审计机构的实证漏洞率。
上下文长度处理能力（模型能合理考虑的代码库范围）。
针对生成代码的版本和依赖解析策略。
全自动化的替代方案已经非常实用且被广泛采用。人工在环（Human-in-the-loop）工作流——即由 AI 提议修改，再由开发者进行审查和完善——将模型的高速与人类的判断力结合在一起。与 AI 进行结对编程（Pair-programming）能让开发者始终掌控设计和系统层面的权衡。针对公司自有代码库微调小型模型的专用流水线，可以通过使输出符合内部标准和许可来降低某些风险，尽管这会带来额外的运营和数据治理开销。
洞察：将供应商规格与学术基准测试及独立安全报告进行对比，对于获得可信的覆盖范围至关重要。
核心结论： 如今的 LLM 工具是强大的助手，而非工程团队的开箱即用替代品；特定领域的微调和人工监督仍然至关重要。
实际应用与开发者影响 —— 如果 AI 编写了 90% 的代码，团队和生产系统将面临怎样的真实体验
工程组织内部的运营现状
如果 AI 生成了大部分代码，团队可能会看到即时且结构性的变化。短期内，许多组织将通过自动化重复性任务获益：搭建新服务脚手架、生成 API 客户端或创建测试存根。这些收益通常体现为样板代码开发速度的提升。
但这伴随着权衡。组织将需要新的 QA 检查点：针对 AI 输出的专门安全扫描、在发现可疑模式时终止构建的更严格 CI/CD 门禁，以及增强的许可证溯源检查。可能会出现新的角色，例如 AI 审计员或模型评估工程师，其职责是验证和管理生成的代码。开发者的技能要求也将发生转变：编写有效提示词（Prompt Engineering）、评估模型输出以及安全集成 AI 建议的能力将成为工作职责的一部分。
安全研究提供了警示性证据：在 AI 生成的代码 中，漏洞密度增加和不安全的默认设置出现率不容小觑，这意味着团队必须投入资金建立检测和缓解流水线 AI 代码安全缺陷分析。在实践中，各公司正在采取缓解措施，例如在敏感组件中使用更小的微调模型、应用针对 AI 输出优化的自动化静态分析，以及对关键路径强制执行人工签核。
实际的用户影响各不相同。一些团队报告称在常规任务上的迭代速度更快，而另一些团队则发现，对复杂模块的审查开销和重做抵消了最初的速度提升。对于招聘和组织设计，优先级可能会从纯粹的实现技能转向系统设计、审查和模型评估能力。
洞察：即时生产力的标题（“更快的编码”）经常低估了保持系统安全和可维护性所需的额外下游工作。
核心结论： 预计在样板代码和模板上会有显著的生产力提升，但对于复杂的、生产关键型代码，审查和安全开销也会相应增加。
常见问题
关于“AI 编写 90% 代码”说法的常见问题
Q1：AI 真的能在 3-6 个月内编写 90% 的代码吗？
简短回答：目前没有明确的公开证据支持在这一时间框架内，针对多样化的真实世界代码库实现 90% 的全生产级代码生成。该预测虽被广泛报道，但从业者和分析师普遍持怀疑态度，且基准测试和安全性研究结果也限制了这一结论的成立Anthropic CEO 的预测报道 以及 行业内的反对意见已被记录。
Q2：目前阻碍 AI 生成 90% 代码的最大技术限制是什么？
限制因素包括：大型代码库的上下文窗口限制、生成代码中持续存在的安全漏洞、集成流程中不可靠的测试覆盖率，以及将生成结果集成到现有系统中的困难。学术评估清晰地描绘了这些差距 代码生成研究.
Q3: 将 AI 生成的代码投入生产环境安全吗？
如果不采取保护措施，则不安全。研究表明，生成的代码片段中存在显著的漏洞率，因此企业在接受 AI 生成的更改之前，应采用安全扫描、人工审查、来源检查以及更严格的 CI/CD 门控。关于生成代码的安全调查结果.
Q4: 新闻编辑室应如何审查供应商关于“AI 将编写大部分代码”的说法？
Q5: 如果 AI 开始编写大部分代码，有哪些相关的政策和标准？
现有的 ISO 工作和新兴的立法框架与 AI 的部署及采购相互交织。企业应关注相关 ISO 软件/AI 指南以及国家采购规则等标准，这些标准会影响生成代码的验证和治理方式ISO 标准背景以及更广泛的立法讨论。
“AI 编写 90% 代码”这一说法对开发者和生态系统意味着什么
理性的预测与务实的后续步骤
证据描绘了一个清晰的模式：代码生成模型在特定任务上取得了显著进展，并将继续重塑开发者的工作流，但我们掌握的数据和审计结果并不支持在各种复杂系统中立即实现 90% 的生产就绪型 AI 编写代码。模型架构和部署工具的快速迭代将推动生产力的显著提升——特别是在样板代码、测试脚手架和小型服务模板方面——但软件工程中更困难的部分目前仍需大量人工投入。
在未来的几个月和几年里，请关注几个预示真实结构性变化的信号：衡量多模块生成与集成的可重复独立基准测试、供应商关于训练数据来源和漏洞修复的透明披露，以及经过审计的、显示在安全性不变或提高的前提下显著缩短生产交付时间的开发案例。监管和标准工作也将影响实际落地——受监管行业的公司在将 AI 生成的代码视为常规流程之前，将需要可证明的可追溯性和审计能力。.
对于组织而言，明智的态度是采取适应性策略：在风险较低的领域（如内部工具、原型开发、自动生成的测试套件）积极试点，投资于审查和扫描基础设施，并培养提示词设计和模型评估方面的技能。对于报道供应商宣称内容的记者，最好的提问应是具体化的：要求查看编译产物、测试通过记录、独立的安全性审计，以及关于模型如何处理许可和来源的清晰解释。
未来的发展并非非黑即白。AI 将成为开发者的效能倍增器，加速某些任务并改变其他任务。与此同时，安全性、治理和系统性思维将变得更加重要，重塑角色定义和组织优先级。这种双重性——速度与谨慎并存——是任何关于 AI 编写大部分代码的头条新闻背后的实际现状。如果你寻求报道或应对这些转变，请要求可复现的证据，优先考虑安全性，并将独立基准测试作为衡量变革的下一个有意义的指标。
Anthropic 的预测及其媒体反响、财经媒体报道的更广泛采用趋势，以及对模型优势和安全风险的技术分析，共同指向一个实际的结论：对供应商给出的时间表保持理性的怀疑，并将可衡量、可审计的结果作为衡量真正生产就绪程度的标准。
