夜雨聆风核心要点：AI 让代码产出速度前所未有地快，但清理成本——安全债、质量债、审核疲劳——才是决定长跑胜负的关键。
每个人都用 AI 写代码，但谁在买单？
从创意写作到自动驾驶到药物发现，AI 渗透进了一切。底层有个共同分母——代码。训练 AI 模型需要代码，构建工具和基础设施也需要代码。
GitHub 预测 2026 年将产生 140 亿次提交，相比之前增长 10 倍。构建应用的门槛从未如此之低，但隐藏的清理成本在长期会集中显现。
谁在写 AI 生成的代码？主要分为以下几类：
发明者：OpenAI、Anthropic、Google 等核心 AI 公司和 LLM 背后的团队 研究者：学术实验室和独立研究团队 平台方：GitHub、Hugging Face、Cursor 等分发和工具提供商 工程组织：各类公司内部将 AI 嵌入产品和流程的工程团队 独立开发者：freelancer、开源维护者、第三方应用开发者 公民开发者：PM、设计师、营销人员等之前无编程能力、现在能用 AI 生成代码的人 监管者：制定 AI 使用规则的政府和标准机构 攻击者：从个人到国家层面的威胁行动者
技术特点：为聚焦本文，我们将跳过基础层和分发层，聚焦在"构建层"——工程组织、独立开发者和公民开发者，隐藏成本集中在这里。
共享的收益
AI 让开发者以前所未有的速度构建和交付产品。新的 API 端点在 30 分钟到几小时内完成开发测试上线。
另一个核心收益是开发民主化。工程师处理复杂功能的同时，公民开发者可以构建原型或修复产品中的小问题。
AI 辅助学习、审查和测试也常被忽视——AI 助手已集成到协作平台、代码托管平台和互联网各处。开发者经常在动手编码前先用 AI 助理规划方案。
一位 Webflow 客户分享：健身完、关笔记本、人已离开。同事急需导出完整 CMS 集合为 CSV。在手机上打开 Claude，描述需求。Claude 通过 MCP 连接 CMS，分页拉取全部数据，准确映射每个字段，输出整洁的 CSV。——工具早已就绪，只是大多数人还没连接它们。
但这些收益往往是前置的。成本来得晚，落在远离赞誉的地方。
清理成本全景
工程组织：收益最大，负债也最重
工程组织是 AI 增强的最大受益者，也是积累最大清理成本的一方。
审核疲劳：高风险变更仍需要人类参与审核。审核压力最终落在具备全局上下文的高级工程师身上。
技能退化：重度依赖 AI 的工程师，尤其是早期职业阶段的，容易出现软件工程技能退化。
质量债：在追求速度的过程中，AI 负责的低风险工作容易产生代码重复和微妙的逻辑漏洞。长期来看，对 AI 增强工作的上下文理解会变得薄弱。事故响应时间也可能因缺乏归属感而延长。
供应商集中风险：如果重度依赖的 AI 编码服务出现故障，工程生产力会直接下降。如果产品 AI 集成的供应商挂了，客户会直接感受到痛苦。
运营成本：更高的 token 消耗被美化为更高生产力，但 AI 增强开发的运营成本不容忽视。
整体风险等级：高但分散
独立开发者：风险是个人化的
独立开发者（freelancer、开源维护者、第三方应用开发者）能从 AI 中获益，但风险在于他们个人。
更大的代码量意味着更难审查——因为没有同事可以帮忙。没有法务团队帮你规避版权问题。一个漏洞插件卖给数千客户、一次许可违规、一个有 Bug 的 App Store 发布，都足以让你在一个生态中失去立足之地。
开源维护者面临特别残酷的不对称：
"贡献者花 5 分钟生成一个低质量 AI PR，维护者需要花数小时验证并拒绝它。"
curl 项目在 2026 年 1 月结束了它的漏洞悬赏计划——这种不对称已经不可持续。它不会是最后一个这样做的项目。
整体风险等级：高且个人化
公民开发者：量变引起质变
这是最新的角色类型。PM、设计师、营销人员现在可以自己构建原型和修复小问题，而不再需要排队等工程师。
但他们的代码往往存在质量问题——以解决问题为目的，但缺少测试、错误处理和安全性考量。如果涉及高风险区域（如认证或 PII 数据），需要工程审核。而低风险的改动可能直接进入生产。
关键是：公民开发者在解决问题时，通常不会考虑长期可维护性或事故响应。一旦出问题，原始作者未必有能力调试，修复工作最终落回工程组织。
整体风险等级：中等，但会快速累积
生态问题：平台兜底的隐性成本
独立开发者为生态系统（App Store、Webflow、Shopify、GitHub 市场）构建应用时，隐藏成本出现了二阶效应。
当用户安装了某个应用出问题时，他们指责的是平台，而不是开发者。每个漏网的不良应用都在侵蚀用户对整个生态的信任。
AI 时代，独立开发者交付更快，意味着更多提交和更多审核需求——低质量、不安全的代码的比例在上升。过去可以人工审核所有应用，现在已无法做到。
整体风险等级：高但无声
安全清理账单
更多代码 = 更多 Bug
AI 模型在句法和语义正确性上表现出色，但安全方面的改进缓慢得令人担忧。Veracode 的数据显示，自 2023 年以来，AI 生成代码的安全通过率基本原地踏步。
即使是最新模型，对跨站脚本（XSS）和日志注入等严重漏洞的防范依然不足。AI 编写的代码还会凭空创造出不存在的包名——这正是typosquatting 攻击（依赖名混淆攻击） 的机会。
漏洞窗口已经关闭
当 AI 还在写不安全的代码时，它在攻击能力上已经实现了飞跃。过去 2 年，从漏洞出现到被利用的时间，已经从几个月缩短到几天，很多时候漏洞利用在补丁发布之前就开始了。
Anthropic 最近通过 Project Glasswing 共享了未发布的模型 Claude Mythos——仅针对 Firefox 就发现了 271 个漏洞，包括在人类安全审查中存在了数十年的问题。
Hadrian 的研究团队统计：开源 AI 渗透测试工具从 2023 年 4 月的 5 个增长到了 70 个。这些工具可以不知疲倦地并行工作，寻找互联网上每个软件和代码中的漏洞。
防御者的倦怠
漏洞数量增加了、噪音变大了，但安全团队的人数没增加。Vercel 因一个 AI 工具的 OAuth 令牌被攻破，Mercor 通过开源 AI 网关 LiteLLM 丢失了约 4 TB 数据。
NIST 自身也在动摇——2026 年 4 月，该机构宣布停止充实国家漏洞数据库中的大部分 CVE 条目，理由是 2020 至 2025 年间提交量激增 263%。
注意事项：FIRST 预测 2026 年 CVE 将首次超过 50,000 个。他们的建议是扩大安全运营规模——但大多数组织跟不上。
怎么办：降低清理成本
| P0 | ||
| P1 | ||
| P1 | ||
| P2 | ||
| P2 |
写在最后
AI 增强开发是一场堪比工业革命的代际变革。构建门槛变低了，创新达到了顶峰，整个品类的工作在数月而非数十年内被重新定义。
隐藏成本也是真实的，而且它们往往落在远离速度胜利的地方：工程组织中的审核疲劳、独立开发者的个人声誉风险、生态系统层面的信任损害，以及攻击者以机器速度行动而防御者仍以人类速度运转的安全困境。
核心要点：创造速度与清理速度之间的不对称，正是成本的定义。
长期赢得 AI 生成代码之争的团队，不是那些行动最快的——而是那些从一开始就在为清理做规划的。
文档来源：The clean-up cost of AI-generated code is what the velocity narrative leaves out
原始作者：Ankit Agrawal
本文由 AI 助手整理优化，欢迎关注、分享转载，请注明出处