别让AI代码，变成明天的技术债

殳世英 发表于 2026-3-30 20:50:00

<blockquote>
当“氛围编码”的蜜月期结束，我们才发现欠下的债终究要还
</blockquote>
2026年初，一位ID为mo的开发者发表了那篇引爆开发者社区的反思文章《“氛围编码”2年攒下的烂摊子，正在逼我重新手写代码》。
他的经历让无数人感同身受：从最初被AI惊艳，到逐步把更复杂的任务交给模型，再到某天打开完整的代码库逐行通读后惊呆——“这破玩意儿绝不能上线”，最终选择回归手写代码。
与此同时，开源游戏引擎Godot的核心维护者也在公开吐槽：他们正被大量“AI生成的低质量代码”淹没。
那些代码结构完整、注释齐全、描述洋洋洒洒，但提交者可能并不理解自己交上来的内容。维护者Rémi Verschelde无奈地表示：“我也不知道我们还能坚持多久。”
这两件事揭示了一个正在发酵的行业危机：当AI生成代码成为主流，谁来为代码的可维护性负责？
<h1 id="氛围编码的幻灭从惊艳到惊呆">“氛围编码”的幻灭：从惊艳到惊呆</h1>
所谓的“氛围编码”（Vibe Coding），指开发者用自然语言描述需求，让AI生成代码，然后“看是否对上感觉”就行了。这个由特斯拉前AI总监安德烈·卡帕西推广的理念，在过去两年席卷全球开发界。
但mo的经历揭示了这种模式的致命缺陷：AI写的代码片段单独看都没什么问题，但它完全不考虑整体系统，不重视架构的结构性完整，甚至无视相邻代码的设计模式。就像AI给你展示的几个段落确实逻辑通顺，但当你通读整章时，会发现它一团糟——与整本书的上下文、前后章节的衔接都格格不入。
研究机构METR最新发布的研究也证实了这一点：被广泛用于评估AI编程能力的基准测试SWE-bench Verified，可能显著高估了AI在真实软件开发环境中的表现。
在基准测试中被判定为“通过”的AI代码解决方案中，大约一半在实际项目维护者审核时会被拒绝。
维护者将问题分为三类：
<ol>
<li>代码质量不符合项目规范</li>
<li>对现有代码结构造成破坏</li>
<li>以及基本功能错误</li>
</ol>
<h1 id="黑箱问题为什么ai代码难以维护">“黑箱问题”：为什么AI代码难以维护</h1>
<code>Yonatan Sason</code>在《The Black Box Problem》一文中精准地指出了问题的本质：AI生成代码的可维护性危机源于缺乏结构化约束的生成环境。
他观察到，AI生成的代码有几个典型的结构性缺陷：
第一，一切都在一个地方。 AI倾向于选择“快路径”，将多个功能耦合在单一文件中。请求“一个结账页面”，你会得到购物车渲染、支付处理、表单验证和API调用全部挤在一个文件里。它确实能运行，但成了一个“单元”——你无法单独审查、测试或修改任何部分，必须处理整个模块。
第二，隐式依赖与循环依赖。 AI基于上下文窗口中的“共现关系”建立连接，而非声明的架构意图。服务A调用服务B只是因为它们在同一会话中出现，这种耦合关系无处可查。更糟的是，AI常产生循环依赖——A依赖B，B依赖A——几周后删除B会导致A崩溃，无人知晓原因。
第三，缺乏契约。 良好设计的系统有类型接口、API模式、显式边界。AI跳过这些，“契约”只是当前实现恰好做的事。一切正常直到你需要修改其中一部分。
这些缺陷导致了一个悖论：唯一理解代码内部关系的，是当初生成它的那个上下文窗口——这些关系没有在代码库中留下任何痕迹。这就是AI生成代码的“黑箱问题”。
<h1 id="国产方案从工具辅助到工程化落地">国产方案：从“工具辅助”到“工程化落地”</h1>
面对这一挑战，国内科技企业正在给出自己的答案。
2026年2月，华为云正式发布“码道”（CodeArts）代码智能体公测版，定位为“AI编码实干派”。其核心突破在于，将华为30余年软件工程实践经验与千亿级代码库沉淀，提炼转化为AI智能体可精准读取、验证、执行的结构化规范。
这套“规范驱动开发”模式：
<ul>
<li>将编码规范涵盖代码编写、排版格式、逻辑架构等全维度</li>
<li>让代码生成即合规、边写边测</li>
<li>从源头规避代码冗余、逻辑混乱等常见问题</li>
</ul>
业内人士认为，这种模式将开发者从“代码编写者”转变为“规范设计者与AI指挥者”。据业界经验，传统开发中维护期变更成本可达开发期的5至100倍，而规范驱动开发可显著降低这一损耗。
与此同时，浙江大学的Code-A1框架探索了另一条路径：通过对抗性协同进化，让代码模型和测试模型相互对抗、共同提升。代码模型的目标是通过更多测试，测试模型的目标是发现更多缺陷——这种架构分离避免了“自我合谋”的风险，让测试模型可以安全地检查候选代码，生成有针对性的对抗性测试。
实验证明，3B参数的Code-A1模型在测试生成能力上超越了7B的基础模型，说明对抗性协同进化发现缺陷的模式比单纯扩大参数规模更有效。
<h1 id="开源社区的困境当ai代码变成洪水">开源社区的困境：当AI代码变成“洪水”</h1>
然而，技术方案之外，还有一个更根本的问题：谁来审核AI生成的代码？
在开源社区，这个问题尤为尖锐。Godot引擎的遭遇揭示了AI带来的新挑战：
<ul>
<li>PR数量和审查压力飙升——AI让“提交代码”的门槛大幅降低</li>
<li>信任出现“灰色地带”——维护者难以判断提交者是否理解自己交上来的代码</li>
<li>辅导成本急剧增加——将PR调整到可合并状态需要更多时间</li>
</ul>
更微妙的是，部分开发者利用AI批量生成PR，目的并非改善项目，而是为了“刷贡献记录”，为履历增加筹码。
GitHub的母公司微软正是全球最积极推进AI产品化的科技公司之一，这让平台层面的解决方案变得更加复杂。
Verschelde给出的答案其实非常务实：资金支持。如果能有更多资金，就能雇佣更多维护者，承担审核与指导成本。否则，少数核心成员很难长期承受这种“被AI放大”的工作量。
<h1 id="回归理性从生成速度到可维护性">回归理性：从“生成速度”到“可维护性”</h1>
一位资深工程师的观察很到位：“AI就像一个没经验又一根筋的‘菜鸟同事’。有时你告诉它别这么干，它还是这么干。”——谁来告诉AI“该干什么”“什么是对的”？这个人，就是我们。
随着越来越多开发者经历“氛围编码”的幻灭，一种新的共识正在形成：
第一，AI编码工具需要结构性约束。 正如Yonatan Sason所言，“黑箱问题是可解的，但不是靠更好的提示。它需要强制结构化的生成环境：显式组件边界、验证的依赖图、每组件测试、接口契约。”
第二，开发者需要重新定位自身价值。 从“代码工人”进化为“智能体总指挥”。系统如何架构，目标如何设计，边界如何定义——这些仍然是人类思想的“自留地”。
第三，需要重新定义衡量标准。 我们往往用生成速度来衡量AI生产力。但真正的问题是：从AI生成代码到生产，并且下周仍能修改的速度有多快？
<h1 id="结论ai代码不是问题结构化的ai代码才是答案">结论：AI代码不是问题，结构化的AI代码才是答案</h1>
回到标题的问题：AI生成的代码，真的是在帮我们，还是在给明天埋雷？
答案取决于我们如何使用它。如果放任AI在无约束的环境中生成代码，短期看效率飙升，长期看技术债累积，最终陷入mo的困境——“逼我重新手写代码”。
但如果我们在生成过程中就引入结构性约束，让AI在明确的架构边界内工作，结果就完全不同。正如Yonatan Sason所言：
<blockquote>
“AI生成代码不是问题。非结构化的AI生成代码才是问题。”
</blockquote>
<blockquote>
“黑箱是真实的。但它是环境问题，不是AI问题。修复环境，AI就会生成你真正能发布和维护的代码。”
</blockquote>
华为云码道的“规范驱动开发”、浙江大学的Code-A1对抗进化，都在探索如何构建这样的“环境”。但它们只是开始。
真正的挑战在于：我们能否让“可维护性”成为AI生成的第一性原则，而不是事后补救的质量属性？这需要工具厂商、企业组织、开源社区和每一位开发者共同回答。 来源：程序园用户自行投稿发布，如果侵权，请联系站长删除 免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

骆贵发表于前天 16:34

收藏一下不知道什么时候能用到

页: [1]

程序园's Archiver

别让AI代码，变成明天的技术债