Last Updated: 2026-03-28 # AI 写代码很强，又微妙地不行 *——AI 为什么会写出技术债很高的项目，这或许是当前阶段程序员的救赎* --- 最近半年，我的代码已经全部由 AI 来写了。进步肉眼可见，但用得越多，越觉得它处于一个很偏颇的状态：某些方面极其擅长，甚超过绝大多数人类；某些方面又微妙地做不好。 尤其是大型项目，AI 现在真的写不好。它很容易写出"当下能跑、长期难以维护"的代码——功能实现了，但技术债堆得很快，几个月后项目就变成谁也不想碰的 AI Slop。而且不是"还不够强"的问题——我觉得背后有一些结构性的原因，短期内不太容易解决。 这篇文章想聊聊 AI 不擅长的那部分。这或许也是当前阶段程序员的救赎。 --- ## 一、AI 的能力边界 AI 写代码很强。凡是**边界清晰、上下文自包含**的任务，它都做得很好：写一个函数、实现一个算法、搭一个 demo，水平超过绝大多数程序员。修一个边界明确的 bug、根据清晰的 spec 实现一个功能、生成样板代码——这些它都又快又好。逻辑非常复杂但集中在单文件内的代码，比如一两千行的算法实现，它也能处理得相当漂亮。 但一旦涉及十几个文件、跨模块调用、需要长期迭代的业务系统，它的项目组织能力就急剧下降了。 具体怎么"下降"？不是说它写不出来——代码能跑，测试能过，功能能上线。问题在于它写代码的**方式**：它倾向于在不同模块里重复实现类似的逻辑，而不是提取共享的抽象；它不会在文件之间维持一致的设计模式；它不会主动考虑未来的扩展性——当前需求能满足就行。几个月之后，代码库就会变成一个没人敢动的黑盒：模块之间耦合太紧，改一个地方不知道会影响什么，加一个功能得改十个文件。 还有一个容易被忽视的问题：**AI 没有长期记忆。** 人在一个项目里踩过坑之后，即使过了几个月，还会保持警觉——知道这个模块容易出问题、那个接口有坑。AI 不会。每次对话开始，它对项目的理解都是从零开始的。除非你把每个已知问题都写成文档塞进上下文，否则它会反复犯同样的错误。而把所有细碎的坑都文档化并不现实——它们遍布项目各个角落，就算写下来了，你也不可能每次都全部塞给它。 有人尝试用"多 Agent 分工"来解决——让几个 AI 分别扮演架构师、程序员、产品经理，模拟人类团队协作。这在现阶段可能是一种解法，但我觉得不是最好的方向。人类需要分工，是因为不同的人擅长不同的事情。AI 不一样——它其实擅长所有事情，但同时又在某些地方微妙地做得不好。它的问题不是某道题答不出来，而是**局部优秀但全局缺乏一致性**：每个函数写得对，但函数之间的关系没人设计过；每次需求都实现了，但实现的方式之间没有一致性。这不是靠分工就能补齐的。 --- ## 二、人也有类似的局限性 在分析 AI 的问题之前，先承认一件事：技术债不是 AI 时代的新问题，人类在这方面的表现也不怎么样。 Ward Cunningham 在 1992 年提出"技术债"的比喻：走捷径来加速交付，相当于借债，利息会累积。《The Pragmatic Programmer》里引入了"破窗效应"：一扇破窗不修，很快所有窗户都会被打破。项目里一旦出现一段没有类型的代码、一个不清晰的命名，后来的人就会照着写，直到整个项目都变成这样。 人当然也意识到了这个问题，应对方式主要两种： **第一种是流程约束。** Code Review、CI/CD、静态检测、单元测试——用机制来拦截质量问题。这些东西有一个共同特点：**设置成本一次性，维护成本接近零，但补装成本极高。** 如果一开始就配好，后面的人保持下去是很容易的。但如果一开始没有，后面想补就极难了——给一个完全没有单测的项目引入单测，不是因为写单测难，而是**没有单测的代码通常也不是可测试的代码**：耦合太紧、副作用到处飞、没有接口抽象。"引入单测"实际上等于"重构整个项目使其可测试"。 **第二种是架构设计。** 经验丰富的架构师会在项目初期就引入各种机制来抑制技术债的产生——合理的模块划分、清晰的接口定义、统一的设计模式。好的架构不只是让代码"好看"，而是让正确的做法同时也是最省力的做法，偏离反而需要额外的 effort。这是最强的反技术债机制。 但无论是哪种，都面对同一个问题：**投入产出比。** 在 deadline 压力下，人总是会放弃这些东西。排期紧的时候，Code Review 先不做了；功能急着上线，单测以后再补；架构的事等稳定了再说。一旦这些机制在紧急阶段被跳过，后续再捡起来的阻力就很大——流程断了一次就容易断第二次，代码烂了一块就容易烂一片。这不是某个人的问题，是人性使然。 --- ## 三、表现相似，原因不同 AI 和人都会写出技术债，但深入去看，原因截然不同。 **人靠不住，原因有两层。** 一方面是能力问题——不是每个团队都有经验丰富的架构师，很多时候技术债的积累是因为写代码的人本身就不知道怎么做更好。另一方面，即使水平够，也有激励结构的问题——短期收益（快速交付）立刻可见，长期代价（维护困难）延迟显现。人总是高估短期、低估长期，加上外部压力，这个倾向就被放大了。 **AI 靠不住，是训练机制的问题。** 这又分几个层面： **训练数据的统计偏差。** 互联网上最多的 Python 代码是脚本——快速实现的、一次性的、不需要长期维护的。对于脚本来说，"技术债"这个概念本身就不存在，第一要义是跑起来，引入类型系统和架构模式反而多余。但这些代码大量进入训练数据后，模型学到的默认模式就是"脚本风格"。 不是说训练数据里没有好代码——《Clean Code》、《A Philosophy of Software Design》这些书的内容肯定在里面，模型也确实"知道"这些原则。但这些书的 token 数量，和 GitHub 上实际代码的 token 数量比起来，差了好几个数量级。模型在预训练阶段学到的是"多数人实际怎么写"，不是"少数书里说应该怎么写"。 **架构决策的不可见性。** 即使是好的大型开源项目，GitHub 上能看到的也只是代码的最终状态，不是架构决策的过程。你看不到"为什么选择这个模块划分"、"为什么这里加了一层抽象"、"当时考虑了哪些替代方案又放弃了"。最有价值的架构决策往往存在于公司内部的 design doc、架构评审会议、甚至口头约定里——这些内容根本不在互联网上。模型学到的是 what，不是 why。 **RL 阶段造不出合适的 reward。** 强化学习需要可量化的奖励信号。代码能不能跑——可以量化。测试过不过——可以量化。"这段代码三个月后好不好维护"——怎么量化？ 技术债的危害是**延迟显现**的。写的时候没问题，跑起来没问题，三个月后需求变了才炸。要构造衡量这个的 reward，需要模拟项目的时间演进，这在当前的训练流程里做不到。不是 RL 阶段没有单独训练这个维度，而是**这个维度的 reward 根本造不出来**。 所以结果是：AI 能写出"互联网平均水平"的代码。而"平均水平"在一个需要长期维护的大型项目里，就意味着技术债的持续积累。 --- ## 四、AI 时代，旧问题被放大了 传统软件工程里，人也会放弃约束、积累技术债。但好歹有个自然的"刹车"：人写代码本来就不快，排期本来就不短，Code Review 和架构评审虽然被吐槽，但至少还在做。 AI 把这个平衡打破了。 有了 AI 之后，外界默认你的效率更高，需求排期变短。我在重写项目时发现，写出一个能用的功能只需要一天，但要把它优化到架构合理、未来可持续扩展，还需要再花一天。 关键的区别在于：**第一天我只需要下指令让 AI 跑；第二天需要高频介入，和 AI 反复讨论方针，才能保证不跑偏。** 出于人的惰性，大家往往跳过第二天。能跑了就行。 这种现象不只发生在经验不足的人身上。资深程序员也容易写出 AI Slop——以前没有 AI，每行代码都是亲手写的，写好架构对自己后续开发有利，所以有动力去做。有了 AI 之后，代码不是自己一行行写的，对它的"所有权感"变弱了；外界期望更高了，留给思考架构的时间更少了。AI 生成的代码能跑了，缺少动力再去优化它。 现在甚至有一种论调：Code Review 不用做了，AI 写得太快太多，review 会拖慢效率。架构虽然重要，但顾不上了——反正以后 AI 更强了应该能改好。 这就产生了一个恶性循环：AI 加速了开发，传统的约束机制显得"拖慢效率"，开始被跳过——但新的约束机制还没建立起来。传统软件工程里，人是被生产事故教训之后，才慢慢建立起 CI/CD 和自动化测试的。AI 时代加速了开发流，但这个"踩坑 → 建立约束"的循环还没走完。 **技术债的积累速度跟上了 AI 写代码的速度，但消化技术债的能力没有跟上。** --- ## 五、现在能做什么 我看到两条路径，一条短期可行，一条长期但不确定。 ### 短期：把约束编码成 AI 可以遵守的规则 最直接的是**把约束前置**。在新项目第一天就引入静态类型检查、代码规范检测、单元测试（以我做的 Python 项目为例，就是 Pyright、Ruff、Pydantic 这套工具链）。这不只是对人的约束，更是对 AI 的约束——AI 看到静态检查报错会主动修正，有了类型定义，它生成的代码自然会沿着这个结构走。Toolchain 在 AI 时代的角色变了：从"辅助人的工具"变成了"约束 AI 的守门人"。 更进一步，架构经验可以被 **Skill 化**。现在的问题是：优秀的项目实践大多停留在资深架构师的脑子里，依赖组织里碰巧有这样的人。但如果能把这些实践写成可复用的上下文——比如一份详细的 CLAUDE.md 或一个 Agent Skill——那无论是经验不足的程序员，还是因为 AI 高速发展而倾向于偷懒的资深程序员，只要引用它，就能让 AI 获得高水平架构师的约束。 这是一种知识分发机制：**把"属人的"架构经验变成"可复用的"**。如果某个 Skill 能成为社区的事实标准，就像 ESLint 配置或 Dockerfile 模板一样被广泛引用，那"AI 写不好大型项目"的问题至少能被大幅缓解。 ### 长期：把架构质量纳入模型训练 短期方案是上下文注入——在推理阶段告诉 AI 应该怎么做。长期的方案是权重注入——在训练阶段就让 AI 知道怎么做。 理论上，如果能用另一个模型来评估代码的可维护性，作为 RL 的 reward 信号，这条路是可行的。但如前面分析的，"架构质量"的 reward 极难定义——它高度依赖上下文，标注者之间分歧大，而且需要模拟项目的时间演进才能真正评估。 还有一种可能：AI 的上下文窗口足够大、能力足够强，能一次性把整个项目、所有调用方、所有历史决策都读进去，那很多限制可能自然消失。但这是假设，不是现在。 --- ## 结语 AI 写代码很强，但强得很微妙。它能快速实现功能，却不擅长识别技术债、阻止它累积、在正确的时机做正确的架构决策——这些也是"写代码"的一部分，只是需要的判断力来自踩过坑的经历。而这些经历，既没有被系统地编码进训练数据，也还没有被大规模地 Skill 化和共享。 所以现在的 AI 更像是一个极其高效的执行者：你给它明确的约束，它能写得又快又好；你不给约束，它会以人类做不到的速度把项目带向熵增。 经验丰富的架构师在这个阶段仍然不可替代——不是因为他们比 AI 写代码更快，而是因为他们知道**什么时候该慢下来**。