AI 编程狂飙背后：代码库正悄然腐烂

上周，某创业公司 CTO 在 Hacker News 发布了一则直白帖文："我们每周收 1 万美元，专门清理 AI 生成的代码。"评论区瞬间沸腾——超 600 人跟帖，既有共鸣者，也有吐槽派，更不乏被戳中痛点的开发者。

一位工程师留言称，其团队三个月前全面启用 Cursor 编写代码，"当时感觉效率至少提升三倍"，但如今代码库已沦落到"无人敢动"的境地。并非代码无法运行——它们确实能跑——但整体结构宛如用胶水拼凑的乐高城堡，看似完整，稍一触碰便分崩离析。

这并非孤例。你可能也遭遇过类似困境：AI 极速完成某项功能，运行无误，代码表象也合乎逻辑。然而，当你尝试调整边缘逻辑、增加判断条件或重构模块时，却惊觉——这段代码背后竟嵌套着另一段代码，而那部分又调用了三个陌生的函数。你开始质疑：这真的是我主导的项目吗？

本文暂不争论 AI 是否应介入编码——这已是不可逆转的趋势。我们聚焦于：AI 生成的代码为何在"能运行"之外潜藏风险，以及如何规避这些陷阱。

要理解 AI 代码为何易烂，首先需洞察其工作原理。它并非在"设计"你的系统，而是在执行模式匹配。你输入提示词，它便在训练数据中检索相似片段，拼凑出最"合理"的结果。

这意味着两点：

其一，AI 的"合理"仅具统计意义，而非逻辑正确。你的代码中 99% 的逻辑看似无误，但那 1% 的边缘情况——如并发竞争、空值引用、状态未重置——AI 根本无意处理。它只是未在上下文中见过相应的错误处理模式。

其二，AI 缺乏业务语境。它不知某接口如何被调用、某字段未来如何扩展、某函数是否构成系统瓶颈。它仅能依据"该场景下最常见写法"生成代码。而在软件开发中，"最常见"往往并非"最适合你"。

AI 尤其偏爱"超前设计">。你让它写用户注册功能，它可能首版即引入工厂模式、依赖注入、策略模式、事件总线。听起来颇为"专业"，但对初创项目而言，这些抽象皆是负债——它们徒增理解与修改成本，却未带来当下所需价值。

有人将此现象称为"AI 架构镀金"：AI 从训练数据中习得大量优秀开源项目的设计模式，便下意识认为你亦需如此。但问题在于，他人采用这些模式是因项目与团队规模已达阈值，而你处于 MVP 阶段，三个 if 语句即可解决的问题，何须套用策略模式？

真实案例：某团队让 Cursor 生成支付模块，AI 输出了 6 个抽象类、3 个接口、2 个工厂。上线后需添加简单折扣逻辑，开发耗时三天理解该堆抽象，最终发现仅需修改一行判断即可。

优质代码，见其名便知其所为。AI 生成的代码，命名通常"勉强及格"——不错，但亦无亮点。你会频繁见到 processData()、handleRequest()、executeAction() 这类名称。它们未传达任何业务含义。

试想，若代码中写的是 validateOrderAndCharge()，一眼便知功能所在。但若写为 processRequest()，则必须深入实现方能知晓其"处理"何物。当此类命名充斥代码库，每次阅读都化作考古——定位定义、追溯调用链，方能理解逻辑。

一个小实验：若 Cursor 生成的代码中，移除函数名后信息量无损，则命名必有缺陷。优秀命名不仅供人阅读，更是 AI 后续生成的上下文线索。命名糟糕，AI 后续产出亦将随之恶化。

这是当前 AI 代码最危险的特质之一。AI 生成代码时，默认"一切顺利"。它会写入 try-catch，但 catch 块内可能仅放 console.error(e)，甚至空白。它不会考虑数据库连接超时、第三方 API 返回异常、并发写入冲突等真实场景。

更隐蔽的问题在于，AI 生成的错误处理常是"有形式无实质"——看似含异常处理，实则未做任何处置。例如，它可能编写优雅降级逻辑，但降级行为本身又引发新问题。回调中的 catch 捕获异常并返回默认值，而调用方完全不知此次请求实则失败。

真实场景：某 AI 编写的定时任务，捕获所有异常并打印日志后继续执行。表面"健壮"，实则某日依赖数据库写入失败，任务看似正常，数据却全为空。此 bug 潜伏两周方被发现，因其未抛错——仅静默处理错误，返回错误结果。

以下五个信号，若中三项以上，需高度警惕：

五个预警信号 • 代码行数激增，功能却无明显增加 • 审查他人 PR 时，难以提出具体修改建议（因自身亦看不懂 AI 生成部分） • 新需求来临，你宁愿"另起炉灶"（重写），也不愿修改现有代码 • 同一项目中混杂多种风格、多种设计模式 • 单元测试覆盖率随代码量暴增反而下降

这些信号的核心共性在于：你正在为 AI 生成的代码"还债"——投入更多时间理解、调试、修改，而非节省。

切勿一次性向 AI 提交完整功能提示词。任务越大，AI 自由度越高，越易按"训练数据平均值"生成代码，而非贴合你的具体需求。将功能拆为 5-10 个小块，逐块生成，每块生成后立即审查。此举可压缩 AI"过度设计"空间。

先自行定义接口、函数签名、数据结构，再让 AI 填充实现。此举优势在于：架构由你掌控，AI 仅在框架内实施。相比让 AI 从零生成整个模块，此方式代码质量与一致性更优。

实用技巧：先用纯文本或伪代码构建"代码骨架"，注释中标明各函数输入输出及边界条件，再让 AI 依注释要求实现。这相当于为 AI 划定跑道——它可奔跑，但不可起飞。

每次 AI 生成代码后，应执行固定检查清单：核查所有错误路径、所有 catch 块、所有网络调用。自问："若此处返回 null/undefined/异常，调用方将如何？"此习惯可拦截至少 80% 的 AI 代码潜在 bug。

可将此清单纳入 AI 使用规范。例如："AI 生成代码中，错误处理逻辑须与正常逻辑同步审查，不得留待后续统一补全。"

AI 生成代码速度极快——快至其产出垃圾代码的速度亦远超人类。若不定期清理，AI"写代码"速度将远超你"理解代码"速度，技术债将以指数级膨胀。

某团队做法值得借鉴：每两周安排"清理日"，全员审查近两周 AI 生成代码，标记"晦涩命名""冗余抽象""无效错误处理"，随后批量重构。他们发现，前两轮清理重构量巨大，但数轮后 AI 生成代码质量显著提升——因持续反馈使 AI 上下文更精准。

核心观点 AI 编程本身无误——它大幅降低"从零到可运行"门槛，使个人开发者能做的事远超历史任何时期。但问题在于，诸多人在享受 AI 效率红利时，低估其维护成本。 AI 生成的非"代码"，而是"代码草稿"。它对语法理解远超对人类意图理解。若直接将草稿视作终稿提交，你非在加速开发，而是在将"制造 bug"提速数十倍。 判断是否正确使用 AI 的标准很简单：你花在"理解 AI 写了什么"的时间，是否少于花在"思考代码应如何写"的时间。若前者超过后者，你已非在编程——只是在替 AI 擦屁股。

你在用 AI 编程时踩过哪些坑？是命名灾难、过度抽象，还是静默吞异常？ 评论区分享你的经历，共同减少 AI 代码的"隐形债务"。 觉得有用？转发给正在用 AI 编程的朋友。