AI 编程让源代码变得充裕，但验证依然稀缺

Google News 引出了一项关于人工智能与软件的尖锐论断：代码正变成“只写不读”、用后即弃的产物。这一说法捕捉到了一项真实变化。编程智能体生成实现的速度，已快过许多团队理解、审查或安全接纳这些实现的能力。

冲突并不只是人类与机器之间的对立，而是生成速度与组织理解能力之间的矛盾。AI 可以降低产出代码的成本，同时提高证明最终系统依然正确、安全且可维护的成本。

这一差异至关重要，因为最有力的证据并不支持“AI 代码会被迅速丢弃”这样简单的叙事。相反，它指向了一种更深层的逆转：源代码正变得充裕，而规格说明、架构判断、验证和责任追溯仍然稀缺。

Google News 的报道究竟改变了什么

“只写代码”这一论点，让 AI 编程的讨论从打字速度转向对整个软件系统的控制。

这一术语因 Heavybit 普通合伙人 Joseph Ruscio 而获得关注。他在 2026 年 2 月发表的文章 write-only code 描绘了一种企业未来：智能体生成的实现如此之多，以至于人类不再逐行阅读。

“只写不读”并不意味着代码在字面上无法阅读。它意味着，阅读每一行生成代码不再是主要的控制机制。人类转而审查规格、约束、测试、架构和可观察到的行为。

这比“开发者将使用更好的自动补全”更进一步。AI 结对编程者仍假定人类会编写或密切审查实现。编程智能体则可以检查代码库、编辑多个文件、运行命令、执行测试，并在有限人工干预下修订自己的工作。

Google News 突出的文章，也契合了工程会议上已在展开的更广泛讨论。在 QCon London 2026 上，Hannah Foxwell 认为，审查大规模生成代码既不令人愉快，也难以长期持续。

她提出的应对方式是将同行审查前移。在智能体编写实现之前，团队先审查规格、测试策略和架构。InfoQ 的 QCon coverage 将这一建议直接与 Ruscio 的“只写代码”概念联系起来。

因此，真正有意义的事件并非某项产品发布，而是一套连贯的 AI 辅助开发运营模式正在形成。

在这一模式下，开发者定义意图和可接受的边界。智能体将这些边界转化为代码。自动化系统测试结果，而人们则专注于需要业务背景或架构判断的决策。

这一模式改变了审查的单位。一份包含数千行生成代码的拉取请求，作为主要信任边界的价值会降低。重要的工件变成需求、威胁模型、测试套件、依赖策略、部署计划和运行时证据。

一次性 AI 代码处在这一模式更激进的一端。智能体可能生成临时迁移脚本、诊断工具、数据转换器、测试夹具或原型。团队可以在即时任务完成后丢弃源代码。

然而，其影响很少会随文件消失。一个短生命周期脚本仍可能修改数据库、暴露密钥、创建云资源，或将错误假设写入客户数据。源代码或许可以丢弃，后果却可能持久存在。

这正是 Google News 的表述值得关注的原因。它为一种真实转变赋予了令人难忘的名称，但这个名称也可能造成误导。核心问题不是人类是否阅读每一行，而是团队是否保留了足够的证据与知识，来治理这些代码行实际做了什么。

更快的生成速度让工程组织承受压力

AI 让实现成为更廉价的投入，但并不会让软件交付同样变得廉价。

传统工程流程假定，代码生成是一项重要约束。团队分配工作、实现变更、审查拉取请求、运行测试，再将获批构建版本推向生产环境。

编程智能体压缩了实现阶段，但并不会自动压缩产品澄清、安全审查、集成测试、运营准备或组织协调。

Google Cloud 的 DORA 研究将 AI 描述为放大器。它会增强能力强的组织，也会放大陷入困境组织的弱点。2025 DORA report 认为，回报更多取决于周围的组织系统，而非单一工具本身。

这一发现立即给工程负责人带来压力。如果智能体产出更多变更，审查者将面对更长的队列。测试基础设施承受更多负载。平台团队必须支持更多实验、环境和部署尝试。

旧瓶颈并没有消失，而是发生了迁移。实现让位于吸收能力，即组织理解、集成、验证和运营不断增加的变更流的能力。

正是在这里，“只写代码”具有了运营层面的重要性。开发者可以要求智能体添加端点、修复测试、迁移库，或构建一个小型内部应用。每一项请求都可能在开发者尚未充分探索周边系统前，就产出看似合理的代码。

看似合理并不等于正确。生成的代码可能满足提示要求，却违反未文档化的约定；可能重复已有服务、选择不合适的依赖、削弱授权检查，或引入成本高昂的运营路径。

过去，人类在实现变更的过程中会学习到许多这类约束。他们会遇到别扭的接口、阅读邻近代码、向维护者提问，并发现早期决策存在的原因。

智能体可以跳过这部分学习过程。这通常很有用，但也移除了组织理解的一个来源。实现产出了，却无法保证有人吸收了维护它所需的知识。

负担首先落在资深开发者和维护者身上。他们掌握着区分“局部正确的补丁”和“会对系统造成伤害的改动”所需的背景。当生成速度加快，他们的判断就成为一项共享且日益稀缺的服务。

安全团队也面临类似问题。一次性 AI 代码可能通过原型、内部仪表盘、迁移脚本、支持工具和临时自动化进入系统。这些工件往往绕开了面向客户应用所采用的控制措施。

一个原型可能因为同事开始依赖它而变成永久系统。一次性脚本可能在数月后再次运行。临时凭证可能进入日志。测试数据可能泄露到生产环境。

压力同样会波及初级工程师。如果智能体处理了常规实现工作，较新的开发者就会失去一部分过去借此学习代码库结构、调试和生产纪律的工作。

团队无法仅靠禁止 AI，或要求人类检查每一个生成 token 来解决这个问题。他们需要有意识的学习路径、明确的责任归属，以及更小、更可审查的变更。

可搜索的架构决策记录有助于保留缺失的背景。构建 technical knowledge base 的团队，可以将规格、事故报告和设计约束连接到智能体修改的代码上。

因此，组织压力已经十分明确。AI 编程工具会奖励那些已拥有强大测试、文档化边界、稳定接口和快速反馈的团队；也会暴露那些依赖未写明知识和英雄式审查者的团队。

“只写代码”颠覆了传统审查契约

旧契约认为，人类在阅读代码后信任它；正在形成的新契约则认为，人类在施加约束并完成测试后信任其行为。

数十年来，可维护性意味着另一位工程师可以读懂一个函数、理解其意图，并安全地修改它。命名、结构、注释、模块化和文档都服务于人类理解。

“只写代码”挑战了这一标准背后的经济逻辑。如果智能体能够根据精确规格重新生成组件，保留每一个实现细节的价值可能会下降。

这并不消除可维护性，而是改变了必须维护的对象。

持久资产可能是规格说明，而非当前实现。测试可能成为可执行的意图陈述。接口契约的重要性可能超过内部优雅性。架构规则可能成为机器强制执行的约束，而不再只是文档中的指导。

这种逆转类似于软件抽象层级的早期转变。如今，大多数开发者在发布应用前不再检查生成的机器指令。他们信任编译器、类型系统、测试、操作系统和运行时监控。

AI 生成代码在一个重要方面有所不同：编译器执行的是受限且确定性的翻译；编程智能体则会就设计、依赖、API 和行为作出概率性决策。

这一差异使团队无法将智能体仅仅视为另一种编译器。智能体需要一个约束框架，也就是限制其工作的工具、权限、上下文、测试和反馈循环。

一个良好的约束框架可以拒绝被禁止的依赖、强制模块边界、限制网络访问、运行安全扫描，并在接受变更前要求通过测试。它还可以将生成的编辑控制得足够小，以便进行有意义的 AI 代码审查。

审查本身必须分层进行。快速的自动化检查应覆盖格式、类型、依赖策略、已知漏洞、测试和架构规则。人工审查者应聚焦于意图、权衡、威胁边界和失效模式。

这并不意味着只要测试套件通过，就可以合并一个庞大而不透明的补丁。测试只能验证它们表达的情形，无法保护无人识别的假设。

规格也面临同样的限制。智能体可以遵循详尽请求，却依然构建出错误的产品。需求可能遗漏无障碍需求、保留策略、区域规则或运营约束。

因此，正在形成的审查契约包含多个控制点。人们批准应当改变什么；机器检查已定义约束是否成立；生产遥测揭示最终行为是否符合现实。

每个控制点覆盖不同类别的失败，没有任何一个能够独立满足要求。

这一转变也改变了团队评估开发者生产力的方式。生成的代码行数、完成的任务数和创建的拉取请求数衡量的是活动量。它们并不能说明用户是否获得了价值，也不能说明系统是否变得更难运营。

DORA 后续分析发现，更高的 AI 采用率与更高吞吐量和更大不稳定性都存在关联。其关于 AI delivery tensions 的讨论指出，创建阶段节省的时间往往会重新分配给审计和验证。

这一结果解释了为什么编码可能感觉更快，却不会让交付速度按比例提升。开发者获得的是即时的生成收益，组织承担的则是延迟出现的集成成本。

实际的分界线不在于代码是手写还是生成，而在于变更是否受到治理。

在沙箱中运行的孤立转换任务里，受治理的可弃用 AI 代码可以是合理选择。即使每一行看起来都很常规、并且会在代码库中保留多年，未经治理的生成代码仍可能带来危险。

证据令“可弃用 AI 代码”论断变得更复杂

在所有真实开发场景中，AI 编写的代码并不必然短命、低质量，或总能更快产出。

Musfiqur Rahman 和 Emad Shihab 在 2026 年发布的一篇预印本研究考察了 201 个开源项目中的逾 20 万个代码单元。他们的代码存续研究得出了一个与“可弃用代码”叙事相悖的结论。

在线级别上，智能体编写代码的修改率低 15.8 个百分点，修改风险也比人类编写代码低 16%。换言之，观察到的 AI 代码存续时间更长。

这并不能证明 AI 代码更好。代码可能因为正常运行而未被修改，也可能因为无人使用，或维护者不愿触碰而保持不变。仅凭存续时间无法区分这些解释。

该研究还发现，智能体编写代码的修正性修改比例略高，为 26.3%，而人类代码为 23%。不同智能体之间的差异，超过了智能体与人类之间的总体差异。

这些结果表明，来源标签过于粗糙。模型选择、任务类型、代码库质量、人工监督和组织实践，可能比初稿是否由 AI 生成更重要。

另一项实验得出了另一个令人不安的结论。METR 招募了 16 名经验丰富的开发者，他们在自己熟悉、成熟的开源代码库中工作。该试验涵盖 246 个真实问题，并随机允许或禁止使用 AI 工具。

使用 2025 年初 AI 工具的开发者，完成分配问题所花时间多了 19%。这项生产力试验还发现了显著的认知差距。

参与者在完成工作前预计 AI 会让他们快 24%。之后，尽管实际测得的是速度变慢，他们仍相信 AI 让自己快了 20%。

研究人员警告，不应将该结果泛化到所有开发者或任务。他们的参与者非常熟悉大型代码库，而所使用的工具也仅代表快速变化市场中的一个特定时期。

即使存在这些限制，这项研究仍揭示了关于可弃用 AI 代码论断中的一个关键弱点。快速生成不等于快速完成。提示、等待、检查、修正和集成都可能消耗看似获得的收益。

开发者情绪进一步印证了这一谨慎判断。Stack Overflow 的 2025 年调查显示，AI 使用持续上升，而信任度却在下降。只有 29% 的受访者信任 AI 的准确性，低于早期调查中约 40% 的水平。

其开发者信任分析称，超过 84% 的受访者正在使用或计划使用 AI 工具。采用率与信心正朝相反方向发展。

这些发现并未否定“只写不读”的代码。它们澄清了这种做法所需的条件。

首先，重新生成必须确实比理解和修复当前实现更便宜。对于小型适配器或测试夹具而言，这比对支付账本更有可能成立。

其次，规范必须捕捉到足够多的真实需求。只描述理想路径的提示词无法支持安全地重新生成。

第三，环境必须能够检测不可接受的行为。没有测试、策略检查、访问控制和运行时可观测性，团队无法区分成功生成与看似合理的失败。

第四，必须有人对结果负责。智能体无法为宕机、隐私违规或安全事件承担责任。无论作者身份如何变化，人类和组织的责任依然存在。

因此，持怀疑态度的解读至关重要。“可弃用”可能成为忽视设计质量和文档的便利借口。团队可能以为日后可以重新生成某个组件，却发现它真正的规范只存在于生产行为和员工记忆中。

代码或许可以廉价地重建，而上下文依然昂贵且难以恢复。

可弃用源代码可能留下持久的安全与数据影响

删除生成的源代码，并不会逆转该源代码所执行的操作。

设想一名开发者要求智能体创建一次性的客户数据迁移程序。该脚本读取旧架构、转换记录，并将其写入新服务。

团队可能会在迁移后删除该脚本。但被修改的记录仍然存在，任何损坏字段、泄露的标识符、不完整的审计条目或意外授予的权限也同样存在。

生成的基础设施脚本会带来相同问题。它可能创建公开的存储桶、权限过宽的服务账户或长期有效的凭据。删除文件并不一定会删除相应资源。

临时的内部应用也常常会变成永久应用。销售团队开始使用一个生成的仪表板，运营团队依赖其输出，最初的开发者则转去负责另一个项目。

原本可弃用的 AI 代码如今支撑着一项业务流程。它可能没有负责人、依赖策略、备份计划、无障碍审查或事件处置流程。

当智能体被赋予广泛权限时，这一风险会进一步扩大。能够运行 shell 命令、访问网络服务、查询数据库和发布变更的编码智能体，其影响远大于自动补全工具。

权限提示提供的保护有限。人们会逐渐习惯于批准，尤其是在工具频繁发出请求时。更强的防线是确定性的隔离措施。

智能体应仅获得完成任务所需的最小文件系统、网络、凭据和部署访问权限。高风险操作应在隔离环境中进行，并配有清晰的日志和到期规则。

团队还应区分可逆与不可逆操作。生成本地文件通常是可逆的；发送消息、删除生产数据、轮换共享密钥或更改外部账户则未必如此。

系统在允许不可逆操作前，应要求更强的证据。这类证据可能包括试运行、人工批准、变更预览、备份确认或策略评估。

AI 代码审查必须检查副作用，而不只是源代码风格。审查者应询问程序读取哪些数据、联系哪些系统、改变哪些状态，以及如何回滚该操作。

溯源同样重要。团队需要知道是哪种模型或智能体生成了变更、它收到什么规范、调用了哪些工具、运行了哪些测试，以及由谁批准了结果。

这份记录并非官僚式装饰。当生成的实现后来被替换或删除时，它能帮助调查人员重建故障经过。

供应链风险会带来另一种持久影响。智能体可能基于名称相似性或过时示例选择依赖项。即使最初的代码已经消失，该软件包仍可能在很久之后引入漏洞或许可义务。

代码库控制措施可以阻止未知软件包、要求锁定文件、扫描许可证并限制安装来源。智能体应在这些控制措施之内运行，而不是为了方便绕过它们。

目标并不是永久保留所有可弃用源代码，而是保留解释和治理源代码影响所需的证据。

当环境被隔离、输入受到控制、输出经过验证且生命周期得到强制执行时，临时程序可以真正保持临时性。缺少这些条件时，“临时”描述的只是一种意图，而非一种属性。

Google News 读者接下来应关注什么

“只写不读”的未来将由验证经济学决定，而不是由代码生成演示决定。

首先应关注的信号是，组织是否将审查前移。规范、测试计划、威胁模型和架构约束，应在智能体开始实现前获得更正式的关注。

这种转变的证据将强化“只写不读代码”的论点。团队会将意图视为持久工件，将实现视为其可替换的表达形式。

如果拉取请求持续膨胀，而审查实践保持不变，那么这一论点作为运营模式就会被削弱。它只会描述代码量，而无法解决由此带来的理解问题。

第二个信号是，交付指标能否与个人生产力同步改善。组织应衡量交付前置时间、变更失败率、恢复时间、漏出缺陷和运维负担。

生成更多代码并不代表成功。以稳定的生产行为交付更多已完成功能才是成功。

DORA 的研究表明，AI 可以提高吞吐量，同时也会增加不稳定性。如果两个维度都持续改善，就说明测试、平台工程和治理正在追上生成速度。

持续的不稳定性则会支持相反结论。这意味着组织生成实现的速度，超过了它们能够安全吸收的速度。

第三个信号是，编码智能体是否获得更强、可衡量的隔离约束。应关注默认沙箱化、受限凭据、机器可读策略、完整工具日志，以及对不可逆操作的强制批准。

这些控制措施会让可弃用 AI 代码更安全，因为即使人类不检查每一行，它们仍能约束代码的影响。它们也会为企业委派更大型的任务提供可信基础。

如果与智能体相关的数据泄露、未经授权的变更或被遗弃的内部应用增加，就会暴露这一模式的弱点。这将表明，弃用降低了可见性，却没有减少后果。

读者也不应把每种 AI 编码工作流都视作同一类别。生成的单元测试、代码库迁移和自主执行的生产变更，带来的风险各不相同。

恰当的监督程度取决于数据敏感性、可逆性、系统关键程度和对验证的信心。团队需要明确的类别，而非一种放之四海而皆准的审批流程。

Google News 让一个颇具挑衅性的说法进入视野，但这个说法应当是分析的起点，而不是终点。代码可以变成只写不读，而不必变得无人负责；它可以变得可替换，而不必毫无后果。

实际挑战在于，让意图、约束、测试、溯源和运维证据比任何单一实现都更持久。实现这一平衡的团队，可以从更廉价的生成中获益，同时不放弃控制权。

无法描述这些控制措施的团队，在称其代码为“可弃用”之前应当暂停。他们应该问一个更难的问题：如果没有任何人完整阅读这一实现，什么可靠的系统能在客户发现问题之前捕捉到错误？