“LLM 即编译器” 是一个你的代码库无法承受的隐喻

这个说法非常诱人：用英语描述行为，模型生成代码，然后交付。提示词（Prompts）变成了源码，产物变成了目标，而 LLM 就像是一个前端界面更友好的 gcc 坐镇其中。如果这个框架成立，那么软件工程的其余部分——评审、重构、架构——都将成为提示词质量的下游产物。但事实并非如此。那些基于这种假设构建的代码库，正以一种现在看来极其乏味的模式走向失败：在大约第六个月，没人能解释为什么某个特定函数长成那样，而且每一次增量变更都会引发一波重复代码。

编译器隐喻才是根本原因，而不是“氛围感编程”（vibe coding）、模型质量或提示词技巧。这是一个范畴错误，它悄无声息地让团队逃避了那些能保持代码库长年连贯性的工作。当你认为模型是编译器时，生成的代码就变成了实现细节，就像汇编语言是 C 程序的实现细节一样。而当你实际在带领一个由非确定性、上下文受限的协作成员组成的团队时，生成的代码才是资产——而提示词比起源码，更像是 Slack 消息。

编译器究竟承诺了什么

我们有必要从字面意义上理解什么是编译器，因为这个隐喻的大部分修辞力量都源于其模糊性。编译器接收一种具有明确语法的正式语言的确定性输入，并产生一个产物，除了少数有据可查的标志位外，该产物在多次运行中是字节级一致的。两名工程师编译同一个提交（commit）会产生相同的二进制文件。从源码行到生成指令的映射是可追溯的；从语言特性到运行时语义的映射是明确规定的；对编译器的更改受到标准组织、回归测试套件和发布说明的约束。你可以扔掉二进制文件并重新生成它，而不会产生任何意外。

这一切对于 LLM 来说都不成立。Temperature 设置为 0 也救不了你，因为提示词的任何微小改动——一个新的示例、重新排序的指令、重新排版的空格——都会让你偏离固定点。模型本身并不受你控制：权重会根据提供商的节奏而非你的节奏而改变，三个月后同样的提示词可能会产生结构明显不同的代码。没有标准组织，没有关于“当你要求‘优雅处理速率限制’时 GPT-5 意味着什么”的规范，也没有任何保证能让你通过原始提示词重新生成一个模块，并恢复到与你仓库中现有内容接近的状态。

这不是在钻牛角尖。这是决定生成的代码具有权威性还是提示词具有权威性的关键。在编译器的世界里，源码是权威，二进制文件是可丢弃的。在 LLM 的世界里，生成的代码是权威——它是实际执行的内容，是你的测试所验证的内容，是你的轮值工程师在凌晨 3 点阅读的内容——而提示词只是代码生成过程中的一种有损的、一次性的副产物。那些倒置了这一关系的团队，将提示词视为源码而将代码视为二进制产物，最后发现自己无法回答“为什么这个函数要执行 X 操作”，只能回答“因为模型就是这么生成的”。

故障模式在第六个月左右显现

这种损害并非立竿见影，这正是其阴险之处。早期的速度看起来惊人。一个本需两周才能完成的功能在两天内就交付了。利益相关者注意到了这一点。仓库中生成代码的比例不断攀升。接着，大约在产品规模大到每一次变更都会触及模型几个月前编写的代码时，三种模式同时浮出水面。

第一种是重复逻辑的扩张。GitClear 对 2025 年 2.11 亿行变更代码的分析发现，复制粘贴的代码在变更行数中的比例从 2021 年的 8.3% 上升到了 2024 年的 12.3%，且重复的五行以上代码块出现的频率跳升了约 8 倍。在同一时期，与重构相关的变更行数比例从 25% 下降到不足 10%。其机制是机械性的：模型看不到你的整个代码库，因此它无法建议“复用 lib/money.ts 中的 parseCurrency”。它会直接生成一个新的 parseCurrency 函数，而按下 Tab 键接受建议比将其提取出来要容易得多。将这种情况乘以一年的时间，你就会得到同一个概念的五个实现，每个实现都略有不同，全部发布到了生产环境，而且彼此之间都无法被发现。

第二种是不利于入职的隐晦性。生成的代码往往在局部是正确的，但在全局上是匿名的。它解决了被提示的任务，但没有携带任何人类编写代码通过争论、修改和由于名字出现在 blame 记录行上而产生的环境压力所积累的“原因”。当一名新工程师问“为什么这个重试循环是这种形状，而不是两个文件之外的那个样子”时，答案通常是没有答案——这两个循环是由两个不同的工程师在两周内通过两个不同的提示词生成的，没人在意这个选择。Birgitta Böckeler 在软件工程文献中对此的描述非常犀利：智能体“没有社会责任感，对一个 300 行的函数没有审美厌恶，也没有‘我们这里不那样做事’的直觉”。代码评审是历史上沉淀这些直觉的机制。当评审被压缩为“是否通过 CI”时，这种传承就中断了。

第三种是意图与产物之间的漂移。CodeRabbit 最近对 470 个开源拉取请求（PR）的分析报告称，AI 共同创作的 PR 包含的“重大”问题大约是人类编写的 1.7 倍，其中配置错误多出 75%，安全漏洞多出 2.74 倍。2024 年的 DORA 报告在研究了更大规模的人群后发现，AI 采用率越高，交付吞吐量和系统稳定性反而越低——这与编译器隐喻所预测的完全相反。一项针对 810 万个拉取请求的学术研究将 AI 工具的使用与实测技术债务增加 30–41% 联系起来。这些发现没有一个是关于模型在单个任务上出现严重错误的，而是在于提示词所暗示的内容与代码实际执行的内容之间存在上千个微小的偏差，这些偏差的累积速度超过了任何人的调和能力。

这种隐喻悄然取消的工程纪律

一旦你接受了编译器的框架，一系列工程实践就会悄然消失，因为它们似乎不再适用。你不会对 rustc 的输出进行代码审查。你不会重构你的目标文件。你也不会为链接器编写架构文档。如果 LLM 是编译器，那么审查、重构和架构维护就成了你已经“毕业”而不再需要的仪式。

具体的后果是可以预见的。审查纪律退化为对 diff 的匆匆一瞥和点赞，因为审查者隐含地将模型的输出视为值得信赖的翻译，而不是初级工程师的初稿。重构的节奏会崩塌，一方面是因为每个 Sprint 生成的代码量让团队无力进行合并整合，另一方面是因为重构一个几乎没人理解的模块感觉就像是在做无偿的考古工作。架构判断被外包给了模型的默认设置，也就是说，外包给了训练分布恰好偏向的任何形状——通常是最通用的，而不是最适合你系统约束的。

品味成为了悄无声息的牺牲品。资深工程师如果反对一个 300 行的函数，或者坚持要求新功能复用现有的抽象而不是新建一个平行的抽象，他是在进行一种模型无法复制的高水平判断工作，因为这不是翻译任务。这是策展。这是对只有你的团队才知道的内部语法的执行。编译器隐喻中没有策展的位置；gcc 没有品味。如果你的组织采纳了这个隐喻，它就不再为品味而招聘，不再在审查中奖励品味，也不再保护行使品味所需的时间。两年后，代码库就成了 2025 年模型默认设置的纪念碑。

诚实的框架：一位多产的初级工程师

真正符合失效模式的框架，是在大规模交付 AI 辅助代码的从业者中悄然出现的那个：LLM 是一位快速、多产的初级工程师，上下文背景不完整，且不承担任何责任。这种说法对技术而言不那么动听，但作为一种工作假设却更有用。

在这个框架下，被编译器隐喻取消的纪律回归了，而且是带着威慑力回归的。生成的代码被作为生成的代码进行审查，而不是作为编译产物——这意味着审查者会寻找他们在初级工程师的 PR 中寻找的相同问题：误诊的需求、早熟的抽象、被忽视的现有工具、看起来合理但错误的错误处理。重构是有计划地安排的，而不是寄希望于它自动发生。开发者体验（DX）代码腐烂研究建议团队在每个 Sprint 中分配 10–20% 的时间用于维护；在编译器隐喻下，这个数字是零，因为没有什么需要维护的。架构审核关卡——“这个新模块是否符合它所在目录的约定”——变成了流水线中的明确步骤，通常由专门配置为关注一致性而非正确性的第二次 AI 传递来执行。

在初级工程师框架下，Prompt 不再是源代码。它是在会议中给出的一条指令，像任何其他口头指令一样具有有损性和上下文依赖性。你不会像提交代码那样把它提交到仓库。代码本身才是必须存活下来的产物，而“六个月后，当有人必须修改这段代码时，他们能做到吗？”才是你真正优化的目标——而不是“今天的 Prompt 是否生成了可运行的代码”。

这种框架还澄清了一个常见的错误：将模型视为单个初级工程师，而不是一群轮换的角色。每一次生成都是一个没有记忆的新大脑。如果你不会让十个不同的外包人员在没有共享架构师、没有代码审查交集的情况下各自编写一个功能，那么也不要让十个不同的 LLM 会话这样做。在人类工程中阻止这种情况的团队约定——阅读每一个 PR 的技术主管、早于功能出现的架构文档、每个季度的重构 Sprint——正是你需要保持的约定。

限制隐喻的范围

编译器隐喻并非一无是处。对于生成代码的那一刻，它是准确的：你给出了输入，得到了输出，在单次交互中，这种抽象是成立的。错误在于将其延伸到下游的所有环节。生成的代码不是可丢弃的二进制文件；它是你的团队将要与之共存的代码。Prompt 不是源代码；它是一份备忘录。模型不是编译器；它是一个协作者，具有特定的优势模式和特定的、会自信犯错的模式。

那些到 2027 年仍能保持可维护性的团队，是那些限制了隐喻范围的团队。他们让隐喻仅描述一行代码是如何产生的，并拒绝让它描述这段代码应该如何被审查、重构、拥有或架构。六个月之墙并非不可避免，但要避开它，需要在文档编写、流程制定和人员配置中坚信——LLM 是你团队中的一名工程师，而不是取代其余所有人的编译器。