代码并不廉价：用软件基础原理提升AI输出效率

作者：AI拉呱（Errol Yan）
定位：AI领域深度内容与实战方法分享

2025年2月，Andrej Karpathy创造了”氛围编码“这个词：描述你想要什么，让AI编写代码，忘记代码存在。这个概念火了。每个人都想相信编码变得像说话一样容易。

一年后，Karpathy重新命名了它。新术语是”智能体工程“。他的解释很尖锐：”用’工程’来强调这其中有艺术、科学和专业知识。”他在几周内从80%手动编码转变为80%智能体编码，并艰难地发现模型是”参差不齐的”——在难题上表现出色，却在明显的问题上绊倒。

数据支持他的观点。GitClear的2025年代码质量研究发现，AI合著的拉取请求比纯人工PR多1.7倍的问题。复制粘贴的代码行在2021年至2024年间从8.3%上升到12.3%。与此同时，AI现在编写GitHub上41%的所有代码，有470万付费Copilot订阅者。

我们产生的代码比以往任何时候都多，但也比以往任何时候都更有bug。这不是生产力繁荣，这是以复利利率累积的技术债务。

Matt Pocock在他的AI Hero会议演讲中直言不讳：”代码并不廉价。坏代码是有史以来最昂贵的。”

他的理由是：如果你的代码库难以更改，你就无法吸收AI的输出。每一个建议、每一个生成的函数、每一次自动重构都会遇到糟糕架构的摩擦。AI不会修复结构性问题，它会放大它们。

核心论点是：AI是乘法器，不是魔杖。它会复合你放在它面前的任何架构。良好的结构在每次交互中返回更多价值。糟糕的结构在每次提示中加速腐烂。

五个软件基础原理将自信交付的团队与淹没在AI生成的意大利面条代码中的团队区分开来。它们都不是新的，但都比以往任何时候都更重要。

1. 构建前先对齐

Karpathy确定了AI编码智能体的四种结构性失败模式。第一种是：”模型代表你做出错误的假设，并在不检查的情况下继续运行。”你以为你要求的是一个简单的API端点，AI却构建了一个带有认证、速率限制和你从未提到的数据库迁移的微服务。

问题不在于AI的能力，而在于你和AI没有共享你正在构建的东西的心智模型。

Frederick Brooks在《设计的设计》中写到了这一点。他称之为”设计概念“——你正在创建的东西的无形共享理论。它不是文档，不是规范文件，而是协作者之间存在的关于他们正在构建什么以及为什么的理解。当两个人结对编程时，他们通过对话自然地构建这个理解。当你向AI提示时，这种共享理解默认不存在。

Pocock的解决方案是一个他称之为”grill me“的Claude Code技能。整个指令只有两行：

无情地采访我关于这个计划的各个方面，直到我们达成共识。沿着设计树的每个分支走下去，逐一解决决策之间的依赖关系。

它走红了，获得了97,000+ GitHub星标。AI会问40、60有时甚至100个问题才满意。它将智能体变成一个不让你跳过思考的对手。

原则：在共享心智模型之前，不要让AI开始编码。先写摘要、定义约束、回答难题。你花在对齐上的20分钟可以节省你花在撤销错误假设上的3小时。

2. 说同一种语言

如果你和AI用相同的词表示不同的意思，那么对计划的对齐是不够的。

Karpathy的第二种失败模式：”过于复杂的解决方案。要求一个10行的函数，得到一个200行的企业框架。”

AI不是恶意的，它只是不知道你的词汇。当你说”handler”时，你是指HTTP处理程序、事件处理程序还是日志处理程序？当你说”service”时，这是微服务、后台工作者还是类？AI猜测，猜错了，然后为那个错误的猜测构建一个200行的纪念碑。

这是软件工程20年前解决的问题。Eric Evans在2003年出版了**《领域驱动设计》**，核心概念是”通用语言“——开发者、领域专家和代码库本身都一致使用的共享词汇。每次对话、每个变量名、每个API端点都使用相同的术语来表示相同的事物。

Evans最近告诉InfoQ：”在有界上下文的通用语言上训练语言模型，与使用通用LLM相比，对于特定需求更加有用。”你的领域术语表现在是提示工程资产。

Pocock也为此构建了一个技能。他的”通用语言“技能扫描你的代码库，提取术语，并生成一个充满定义表的markdown文件。他报告说，通过阅读AI的思考轨迹，通用语言不仅改善了规划，还使AI的思考更加简洁。更少的浪费token，更准确的实现。生成的代码实际上与计划的一致。

DDD的有界上下文在这里也适用。在多智能体设置中，不明确的术语所有权会导致”上下文渗透”——智能体互相踩到对方的领域、重复逻辑或互相矛盾的输出。这正是Evans20年前在人类团队中描述的失败模式，现在出现在智能体编排中。

原则：构建术语表，精确定义你的领域术语，在项目文档和提示中引用它。如果AI知道”order”在订单管理上下文中意味着”客户承诺”而不是”排序指令”，它就会停止猜测并开始生成合适的代码。

3. 先测试，小批量发布

你已经对齐了计划，说着相同的语言，AI构建了 exactly 你要求的东西，但它不起作用。

这是最浪费时间的失败模式，因为代码看起来是对的，读起来很好，变量名有意义，但一运行就崩溃，因为AI一次性生成了400行代码，没有检查任何一行。

《程序员修炼之道》称之为”超越你的车灯范围”。反馈的速度是你的速度限制。开得比车灯能照亮的更快，你会撞到你没看到的东西。默认情况下，AI智能体开车时灯是关着的，它们产生大量代码，然后才考虑验证。

Anthropic的最佳实践推荐作者/审阅者模式：”一个Claude编写测试，第二个编写代码来通过测试。”OpenAI的Codex文档说得很清楚：”没有测试，Codex使用自己的判断验证其工作。测试创造外部的真理来源。”

两个平台都得出了相同的答案：测试驱动开发。不是作为一种哲学，而是作为一种迫使AI采取小步骤的机械约束。

先写测试，让AI通过测试，重构。红-绿-重构不是敏捷时代的遗物，它是防止熵的反馈循环。每个周期的成本只是大规模重写成本的一小部分，无论是在token、上下文窗口空间还是你自己的审查时间上。

2025年5月关于AI生成代码的arXiv研究发现，当智能体从孤立脚本转移到多模块系统时，代码异味密度增加。没有测试边界，腐烂随代码库扩展；有了测试边界，每个模块保持诚实。

原则：与AI编码时，TDD不是可选的，它是保持输出可信的速度调节器。写测试，让智能体实现，验证，重复。小周期，高信心。

4. 构建深度模块，而非广度

即使测试通过，构建的是正确的东西，随着代码库的增长，仍然会出现结构性问题。AI开始迷路，找不到正确的文件，误解依赖关系，做出破坏三个模块之外的更改。

John Ousterhout在《软件设计哲学》中描述了这一点。他区分了深度模块和浅度模块：

• • 深度模块在简单接口背后隐藏大量功能，你不需要理解内部就能使用它们。
• • 浅度模块则相反：功能不多，但复杂的接口迫使你理解下面的一切。

AI智能体特别擅长生成浅度模块：许多小文件，每个做一件小事，每个暴露多个函数，每个依赖其他三个小文件。看起来很干净，代码审查时读起来很好，但在下一个AI会话中造成导航噩梦，因为智能体必须穿过几十个相互连接的blob才能理解你的代码实际上做什么。

Pocock在他的演讲中直观地展示了这一点。充满浅度模块的代码库看起来像分散的点，之间有混乱的箭头；同样的代码重组为深度模块后看起来像几个大块，上面有简单的连接。AI导航第二种结构并在其中生成更好的代码，因为它可以在不将每个实现细节加载到上下文窗口的情况下推理接口。

关于AI生成代码异味的arXiv论文实证证实了这一点：随着智能体从孤立脚本转移到多模块系统，代码异味密度增加。LLM在推理时不追踪架构复杂性，模块结构越分散，AI的输出质量越差。

这里也有市场信号。TypeScript在2025年8月成为GitHub的#1语言。部分原因是：类型化、结构良好的代码使AI辅助开发更可靠。开发者正在自我选择有利于AI回报复合的架构，就像多元化投资组合复合市场回报一样。那些坚持无类型、分散代码库的人正在为返工付出代价。

原则：审核代码库中的浅度模块，将相关代码包装成具有简单接口的深度模块，在边界处测试。AI不需要看到一切，它需要看到正确的接口。

5. 设计接口，委托实现

如果前四个原则保护AI输出的质量，这个原则保护你。

自从AI编码工具成为工作流程的一部分以来，如果你感觉比以往任何时候都更精神疲惫，请举手。你不是一个人。Pocock在他的会议观众中问了同样的问题，几乎每个人都举手了。

疲惫来自试图审查一切：每个生成的函数、每个重构的类、每个智能体创建的新文件。你发布的代码比以往任何时候都多，但你的大脑仍然是理解所有代码的瓶颈。

Kent Beck的建议是：”每天投资于系统设计。”

规格到代码的运动则相反，它放弃设计，将代码库视为可从提示重新生成的一次性输出，这就是你最终审查400行你没写、几乎看不懂的代码的原因。

替代方案是灰盒模型：你拥有接口，拥有边界处的测试，让AI处理模块内部的内容。对于非关键模块，你不需要审查每一行实现，你需要验证契约是否有效。

这就是Karpathy所说的新核心技能是”判断——委托什么、如何指定、如何快速审查”。你写更少的代码不是因为懒惰，而是因为你把时间花在架构、接口和验证上，这是战略层面。

Pocock将其描述为战术程序员和战略程序员之间的区别。AI是战术程序员，是在实地进行代码更改的中士；你是思考系统设计、模块边界和各个部分如何组合的人。这不是降级，而是晋升。

Anthropic的内部数据显示，在大规模重构任务上有2-3倍的生产力提升。但这些提升来自足够信任架构以自信委托的团队，而不是审查每一行生成代码的团队。

原则：写接口，指定契约，将实现委托给AI，通过测试验证，而不是逐行代码审查。你的工作是系统设计，让智能体处理其余部分。

工具包：从原则到实践

没有工具的原则只是建议。以下是你今天可以安装的工具。

Pocock将他的技能作为开源仓库发布，每个技能直接映射到上述原则：

• • grill-me 在AI写任何东西之前强制共享理解（原则1）
• • ubiquitous-language 扫描你的代码库并构建领域术语表（原则2）
• • tdd 每个模块强制执行红-绿-重构循环（原则3）
• • improve-codebase-architecture 识别浅度模块并将它们包装成深度模块（原则4）
• • writer-prd 在PRD中指定模块更改和接口契约（原则5）

但这些原则不仅仅是一个开发者的观点。主要平台独立构建基础设施来强制执行相同的想法。

Anthropic的Claude Code使用CLAUDE.md作为对齐契约，支持限定于孤立任务的子智能体和干净的上下文窗口，并推荐作者/审阅者模式，其中一个智能体编写测试，另一个编写实现。OpenAI的Codex使用AGENTS.md用于相同目的，带有明确的”完成时”标准，在智能体认为任务完成之前强制测试验证。GitHub Copilot的智能体模式构建你的仓库的语义索引（比2025年初提高37.6%的检索准确率），并支持自定义智能体和提示文件作为可重用的蓝图。

三个平台，相同的结构性答案：对齐文档、测试循环、模块化边界。它们都收敛了，因为它们都撞到了同一堵墙：模型能力不是瓶颈，代码架构才是。

贯穿始终的主线

Brooks在1975年写了关于共享设计概念的内容，Evans在2003年发表了通用语言，Ousterhout在2018年画了深度模块图，Beck几十年来一直在说”每天投资设计”。

Karpathy在几周内、在压力下、使用地球上最强大的AI模型构建时发现了相同的教训。Pocock将它们提炼成病毒式传播的技能，因为成千上万的开发者认出了自己的痛苦。

这些都不是新知识，这就是关键。

一个聪明的提示给你一个好的输出，一个结构良好的代码库给你一千个。每个干净的接口、每个强制执行的测试边界、每个深度模块都会复合后续每次AI交互的价值。跳过架构，你就是在复合债务。

关注 AI拉呱

如果这篇内容对你有启发，欢迎关注「AI拉呱」，获取更多 AI 前沿洞察、实战教程与趋势解读。

下期在看

下期将继续带来该主题的进阶拆解与实操案例，建议先收藏本文，避免错过更新。