AI生成代码的清理成本:速度叙事背后被遗忘的代价

5 阅读19分钟

\n\n本文探讨了AI生成代码在提升开发效率的同时带来的“清理成本”。分析了从企业到个人开发者面临的质量债、安全漏洞及维护负担,强调了建立AI代码审计与治理体系的紧迫性。

译自:The clean-up cost of AI-generated code is what the velocity narrative leaves out

作者:Ankit Agrawal

世界正在积极利用 AI 让我们的生活变得更加高效和安全——从创意写作到更安全的自动驾驶汽车再到药物发现。这一切背后的共同点是“代码”。我们使用代码来训练和构建 AI 模型,并构建将原始模型转化为实用应用程序的工具。最早的 AI 工具是手写的,但现在 AI 能够以前所未有的速度和规模自动生成更多代码,这是人类无法企及的。各大平台正努力应对 AI 规模的要求,GitHub 预测 2026 年提交量将增长 10 倍,达到 140 亿次。构建应用程序的门槛从未如此之低,但从长远来看,这伴随着隐性的清理成本。

那么,谁在编写 AI 生成的代码,谁在利用它,清理成本又是什么?

AI 生成代码背后的核心用户群体可以归纳为以下几类原型:

  • 发明者 (The Inventors):这些是核心 AI 概念、大语言模型 (LLM) 以及 MCP 等标准背后的个人和公司,包括 OpenAI、Anthropic 和 Google。
  • 研究者 (The Researchers):学术实验室、独立研究小组和基准测试创建者,他们生成了该领域运行所需的长尾想法、人才和评估方法。
  • 平台 (The Platforms):分发商、市场和工具提供商(GitHub、Hugging Face、Cursor、Apple、Webflow),他们的政策和默认设置塑造了其他人可以构建、发布和营销的内容。
  • 工程组织 (The Engineering Orgs):各种规模公司的内部工程团队,他们正在重新思考运营方式,并将 AI 嵌入到产品和员工工作流程中。不仅在科技公司,还包括医疗机构、连锁超市、炼油厂等。
  • 独立开发者 (The Independent Developers):这些是构建新 AI 应用或桥接现有解决方案的高级用户。他们可以是开源开发者、自由职业者,或者是在 Apple App Store 或 Webflow 市场等生态系统中创建应用的第三方开发者。
  • 公民开发者 (The Citizen Developers):这些是非工程师人员(产品经理、设计师、营销人员、分析师),他们以前几乎没有或完全没有编程能力,但现在可以生成运行代码并发布应用程序。
  • 监管者 (The Regulators):政府、标准制定机构和特定行业的监督实体,他们塑造了 AI 的构建、部署和审计方式。他们的决策(欧盟 AI 法案美国行政命令行业规则)日益定义了所有人运营的护栏。
  • 对手 (The Adversaries):从个人到黑客行动主义组织再到国家行为体的威胁者。随着前沿 AI 模型获得严重的攻击能力,攻击与防御能力之间的差距正在迅速扩大。

显示原型如何连接、构建并面临威胁的图表

几乎没有哪种 B2B 或 B2C 解决方案不受 AI 影响,这意味着从字面上看,每个人都是 AI 生成代码的用户。为了让本文保持聚焦,我们将搁置基础层和分发层,放大到构建层:即实际生成、发布和维护代码的工程组织、独立开发者和公民开发者。隐性成本集中在这里,解决这些成本的杠杆也在这里。在我们深入探讨这些隐性成本之前,先预览一下 AI 生成代码的好处。

构建层共享的收益

AI 使构建者能够以从未有过的极高速度进行开发和发布。新的 API 端点在 30 分钟到几小时内就能完成开发、测试和发布,而错误修复和原型开发也能在极短的时间内完成。内部工具和自动化开发也变得更快,提升了整个组织的生产力。这让更精简的团队或独立创业者能够在不增加人手的情况下提高产能。

另一个核心益处是开发的民主化。当工程师专注于复杂功能时,公民开发者可以构建原型或修复产品中的细微问题。

支持 AI 的产品用户也可以通过移动设备更快速地开展工作。

以下是 Webflow 客户分享的一篇 LinkedIn 动态

下班后我去了健身房。笔记本电脑关着,我已经走远了。

一位队友急需将整个 CMS 集合导出为 CSV。数百个项目,包含所有字段。

我在手机上打开了 Claude。

描述了我的需求。Claude 通过 MCP 连接到 CMS,分页拉取了所有内容,正确映射了每个字段,并返回了一个结构整齐、可直接分享的 CSV。

…..

Webflow MCP + Claude 是我在生产工作流中使用过的最好的桥梁之一。每个项目,每个字段,零数据丢失。

工具已经准备好了。大多数人只是还没把它们连接起来。

另一个经常被少谈及的显著益处是 AI 增强的学习、审查和测试。AI 助手现在已集成到协作和文档平台、代码托管平台以及广泛的互联网中。这降低了学习陌生技术的门槛,使理解现有代码和架构变得更加容易且省时。构建者通常在实际执行前花费时间与 AI 助手一起规划工作。

与人类不同,AI 不会疲倦或需要睡眠,并且可以复用 AI 开发和审查的最佳实践,保持一致性和模式感知。对于初级开发者团队,AI 可以通过及早发现明显错误来提高底线。

上述益处是巨大的,也是 AI 被如此广泛采用的原因。然而,其中一些收益往往是前置的,我们需要时间才能看到长期的隐性成本。这些成本往往产生在远离胜利和荣誉的后端。

构建层的清理成本

工程组织

工程组织一直是 AI 增强的最大受益者,但从长远来看,他们也是积累最大清理成本的群体。

对于高风险变更,人类仍需参与其中。组织内审查大多数高风险代码的审查负担落在了具有上下文理解能力的资深工程师身上。

过度依赖 AI 的工程师,尤其是职业生涯早期的工程师,容易出现软件工程技能的退化。如果他们的想法不是源于自己,他们可能也难以晋升到职业生涯的下一个阶段。

AI 生成代码的另一个巨大隐性成本是质量债。在追求快速交付且由 AI 负责低风险工作或审查的过程中,代码容易出现重复和微妙的逻辑缺陷,这些缺陷可能会在以后被利用。从长远来看,这也会导致对 AI 增强工作的上下文理解减弱。由于对受影响区域缺乏所有权和理解,事故处理时间可能会变得更长。

工程组织还可能受到 AI 供应商集中化带来的可用性问题的影响。如果严重依赖的 AI 编码供应商发生故障,工程生产力就会下降。如果用于产品 AI 集成的供应商宕机,客户就会感到痛苦。如果产品完全依赖 AI 而没有人工工作流,AI 供应商的宕机就是你的宕机。

AI 带来的生产力提升并非免费。AI 增强开发存在巨大的运营成本,且大多数公司仍然不了解 AI 预算编制。每个开发者更高的 Token 消耗量被美化为更高生产力的标志,这可能导致浪费性支出。

最后但同样重要的是安全成本,这值得单独列出一节。

总体风险水平:高且分散

独立开发者

独立开发者(自由职业者、OSS 维护者、第三方应用开发者)可以从采用 AI 中获得显著收益,但这也会对他们的个人品牌带来风险。由于代码量巨大,且没有同行进行审查或清理代码,审查变得更加困难。没有法律团队来防止你的工作中或来自你工作的版权侵权。无意的错误或差评可能会导致自由职业者在平台上被禁言,或者开发者的应用被踢出生态系统。发布给数千名客户的一个漏洞插件、自由职业交付物中的一次许可违规或 App Store 上的一个错误版本,都可能损害开发者在该生态系统中的地位。

“贡献者只需五分钟即可生成一个低质量的 AI 拉取请求,而维护者则需要数小时来验证和拒绝它。”

开源维护者面临着一种尤为残酷的不对称性:贡献者只需五分钟即可生成一个低质量的 AI 拉取请求,而维护者则需要数小时来验证和拒绝它。curl 项目在 2026 年 1 月结束了其漏洞赏金计划,因为这种不对称性已变得难以为继;它绝不是最后一个这样做的项目。

总体风险水平:高且关乎个人

公民开发者

这是最新的原型,涵盖了产品经理、设计师、营销人员和分析师。公民开发者现在可以原型化并展示他们的想法,而不是要求别人来构建。他们还可以修复代码中经常被视为低优先级但能改善客户生活质量的小问题。这些开发者现在还可以构建以前需要证明其合理性并优先分配开发资源的内部工具。

然而,来自公民开发者的代码通常带有质量问题。虽然代码解决了问题,但可能包含代码重复、缺乏测试、错误检查或日志记录,且没有安全考虑。如果他们的工作涉及身份验证或 PII 数据等高风险领域,工程审查将帮助他们解决这些问题并传授行业技巧。较轻量和低风险的变更可能会直接进入生产环境。虽然来自公民开发者的糟糕代码不太可能让公司倒闭,但高度集中的此类变更从长远来看会降低代码质量。

当公民开发者向生产环境贡献代码时,他们通常专注于解决特定问题,而不是考虑长期的可维护性或事件响应。如果以后出了问题,原作者可能没有足够的深度进行调试,修复工作通常会落在工程组织身上进行测试和发布,增加了他们的工作量。

总体风险:中等,但积累速度很快

生态系统问题

我们刚刚讨论了不同原型及其自身范畴内的隐性成本。然而,当独立开发者为大公司拥有的生态系统或平台构建产品时,会产生二阶效应。这不仅包括 Apple 和 Google 的应用商店,还包括来自 Webflow、Shopify 和 GitHub 等的市场生态系统。生态系统所有者对个人开发者编写的 AI 生成代码负有共同责任

当客户安装应用并出现问题时,他们会责备平台,而不是开发者。这是因为市场审查并允许该应用存在于其生态系统中。每一个蒙混过关的劣质应用都会降低客户对整个生态系统的信心

借助 AI,独立开发者现在发布作品的速度更快,导致生态系统所有者的提交量和审查量增加。这包括大量低质量和不安全代码的提交。过去,我们能够手动审查所有应用;然而,考虑到 AI 增强后的提交率,这已不再可能。新兴生态系统现在正投入更多资源于自动化审查、安全指南和开发者教育。

除了新的应用提交,已获批的应用现在也在 AI 的帮助下进化。开发者正在提交功能增强的更新版本,但伴随着我们上面讨论过的类似问题:需要更高权限、不安全代码或许可证污染。生态系统所有者现在必须在不破坏与开发者社区的社会契约的情况下处理这一问题。

GitHub 既是企业解决方案又是社区代码托管平台,由于其 AI 产品产生并在其平台上托管的海量 AI 生成代码,正面临基础设施和弹性挑战。这表明大型生态系统正在努力应对扩展问题和不断增加的运营成本

总体风险:高但隐蔽

显示每个原型的隐性成本和风险水平的表格

安全清理账单

代码越多,漏洞越多

AI 模型经过多年的进化,在语法和语义正确性方面表现出色。然而,在没有提供安全指南的情况下,安全基准测试的改进速度缓慢。

绘制 LLM 发布日期与安全通过率关系的图表

来自 Veracode 2026 春季生成式 AI 代码安全更新 的图表显示,自 2023 年以来,AI 生成代码的安全通过率(红色显示)基本保持平稳

鉴于现在越来越多的代码是由 AI 生成的(OpenAI 声称这一比例已升至 80%),Veracode 发布的这一趋势令人担忧。最新的 AI 模型产生的代码在严重漏洞的安全通过率上仍然很低,例如跨站脚本 (XSS) 和日志注入攻击。这些模型在 Java 等编程语言的安全得分也很低。

AI 对软件依赖项的幻觉似乎有所改善,但根据研究,AI 编写的代码仍然会虚构包名或拼错包名,抢注攻击者利用这一机会进行供应链攻击

补丁窗口已关闭

虽然 AI 模型正忙着编写不安全的代码,但它们的攻击能力却出现了戏剧性的飞跃。漏洞研究的门槛降低了,且 AI 模型的推理能力已达到甚至超过顶级安全研究人员的水平。仅在过去两年中,从系统中存在漏洞到其被利用的时间已从几个月缩短到几天,在许多情况下,甚至在补丁发布之前攻击就开始了

来自 Zero Day Clock 的图表展示了利用时间从数年缩短到数小时

来自 Zero Day Clock 的图表展示了利用时间从数年缩短到数小时

Anthropic 最近在 Project Glasswing 计划下与世界上最关键的软件供应商合作,并分享了其未发布的模型 Claude Mythos。 Mythos 仅在 Firefox 中就发现了 271 个漏洞,其中包括存在了数十年且经受住人类安全审查的问题。

虽然 Mythos 只是一个起点,但开源领域正在快速追赶。Hadrian 的研究团队已编录了 70 个开源 AI 渗透测试工具,高于 2023 年 4 月的 5 个。这些工具可以不知疲倦地并行工作,寻找互联网上每一段软件和代码中的漏洞。

防御者职业倦怠

随着代码、漏洞和利用程序的增多,安全从业者正面临严重的职业倦怠。虽然漏洞数量和噪音有所增加,但安全人员编制并未增加。安全从业者现在花费更多时间处理零日漏洞,这些漏洞通常源于近年来频繁发生的包供应链事件。

VercelMercor 是这些安全事件趋势的最新受害者。Vercel 因 AI 工具的 OAuth 令牌被盗而遭到入侵,Mercor 则通过 LiteLLM 开源 AI 网关泄露了约 4 TB 的数据,在此过程中暴露了 OpenAI、Anthropic 和 Meta 的训练方法。这两起事件都指向同一个根源——AI 工具已成为新的供应链攻击面,安全从业者正在竞相缩小攻击者与防御者之间的能力差距。

云安全联盟 (CSA) 最近发表了一篇论文,敦促安全领导者建立一个能够应对 Mythos 的安全计划,并为职业倦怠做好准备,因为预计漏洞披露的数量将超过以往任何时候。他们建议安全团队增加产能,并采用智能体工作流 (agentic workflows) 进行安全评估和事件处理。

伴随着安全事件,漏洞赏金领域也发生了变化,“脚本小子”开始利用 AI 发现并报告漏洞。公共漏洞赏金计划现在看到的 AI 垃圾信息 (slop) 多于严肃的报告。即便使用 AI,分类甄别带来的倦怠感也已非常严重,以至于 curl- 和 HackerOne 赞助的互联网漏洞赏金计划已被暂停。

领先的安全非营利组织 FIRST 最近发布预测,称 2026 年 CVE 数量将首次突破 50,000 个。他们对组织的指导意见是扩大安全运营规模,但大多数组织都跟不上。

NIST 本身也快支撑不住了。2026 年 4 月,该机构宣布停止对国家漏洞数据库 (NVD) 中大多数 CVE 的富化工作,理由是 2020 年至 2025 年间提交量激增了 263%。这家支撑全球漏洞元数据的机构正在公开表示无能为力。这预示着其他类似的漏洞数据生态系统未来也将面临困境。

我们能做些什么:降低清理成本

清理成本是真实存在的,没有一劳永逸的解决方法。管理这一成本的团队和生态系统都有一些共同模式,具体取决于成本落在何处。以下是针对危害最大的风险类别的优先处理方案。

优先级风险领域该怎么做
P0安全与补丁差距对 AI 生成的代码保持与人类编写代码相同的审视,理想情况下应更严。在每个 PR 上运行支持 AI 的 SAST、DAST 和 SCA,包括在开发者机器上。在安装新发布的包之前增加冷却期,以缓解供应链接管风险。针对供应链等已知类别建立事件响应手册。最重要的是,衡量已修复的发现,而不是已发现的数量。
P1审查者疲劳与所有权缺口停止以代码行数或 PR 数量衡量工程产出。转而衡量缺陷率、事故频率和修复时间。建立明确的服务和包所有权,确保“没人在凌晨 2 点可以说这段代码不是我写的”。按风险对 PR 进行分类,以便资深审查者关注重要的变更,而不是处理海量队列。
P1生态系统与市场治理在市场提交内容发布前投入自动化分析。制定明确的 AI 披露政策和第三方开发者指南。建立考虑到第三方来源的事件响应路径。现在就开始规划审查自动化,因为 AI 之前的审查流程将无法扩展。
P2公民开发者护栏是护栏,而非守门。提供预先审核的 AI 工具、沙箱环境,以及在部署时进行自动安全和政策检查。定义明确的交接路径,当公民构建的应用发展到需要工程团队接管时。
P2工程师技能退化将 AI 使用与明确的推理产物(设计文档、决策记录)相结合。将 AI 视为现有技能的倍增器,而不是替代品。

我们的处境

AI 增强开发是工业革命规模的代际转变。正如机器重塑了人类构建的内容及其构建方式,AI 正在重塑软件的创建方式以及谁可以创建软件。构建的门槛很低,创新处于巅峰,整个工作类别正在以月而非以十年为单位重新定义。

隐性成本也是真实的,而且它们往往产生在远离速度红利的地方。我们讨论了工程组织内的审查者疲劳、独立开发者的个人声誉风险、发布多年后显现的质量问题、出问题时整个生态系统的信任受损,以及攻击者以机器速度移动而防御者仍以人类速度操作的安全格局。创造速度与清理速度之间的不对称性,正是成本的定义所在。

“创造速度与清理速度之间的不对称性,正是成本的定义所在。”

从长远来看,在 AI 生成代码竞赛中获胜的团队和生态系统并不是那些跑得最快的,而是那些在疯狂背后建立了章法的团队。赢家是那些从第一天起就开始考虑清理策略的人。AI 将继续延伸我们的想象力边界。问题在于,围绕它的实践能否进化的足够快以跟上步伐。

*本文最初于 2026 年 5 月 12 日发布在 webflow.com。*全 工智能