AI Coding 的真正难题不是 AI

大多数人对 AI coding 的理解是错的。

他们以为难题是”让模型写出正确的代码”。好像只要模型再聪明一点，context window 再长一点，事情就会自然变好。

但真正在生产环境里大量使用 AI coding 的人都知道，瓶颈从来不在那里。模型已经足够聪明了。问题是：聪明的模型在一个糟糕的系统里，只会更快地制造高质量的混乱。

这听起来像悖论，但它不是。理解这一点，是理解 AI coding 的起点。

有三个很老的理论——系统论、控制论、信息论——恰好能帮你理解这件事。它们各自问了一个不同的问题：

系统论问：整体是怎么组织的？
信息论问：信号是怎么失真的？
控制论问：跑偏了怎么拉回来？

你不需要读过这三个领域的原始文献。你只需要理解，AI coding 的几乎所有难题，最终都能归到这三个问题中的某一个。

系统问题

先说系统论。

人们讨论 AI coding 时最常犯的错误，是把它当成一个模型选型问题。”用 GPT-4 还是 Claude？””这个模型 SWE-bench 多少分？”这些问题不是无意义，但它们遮蔽了一个更重要的事实：模型只是系统的一个部件。

一个 AI coding 系统至少包含：用户的目标、代码库的现状、文档、prompt、工具链、测试套件、CI 流程、review 机制、部署管道和监控。这些部件之间的关系，比任何单个部件的性能更能决定最终结果。

这就像足球。你可以买世界上最贵的前锋，但如果中场传不出球，后防线乱成一锅粥，门将又不和防线沟通，这个前锋只会变成一个很贵的摆设。

OpenAI 的 agent 指南有一个很精确的表述：agent = 模型 + 工具 + 指令。三者必须协同。如果指令模糊，再强的模型也只是在猜；如果工具不对，再清晰的指令也执行不了。

这引出了系统论最重要的洞见：局部强不等于整体强。

我见过太多这样的案例：一个很强的模型放进一个没有测试、没有文档、没有 CI、没有人工审查的项目里，产出的代码看起来很专业，但一周后你发现架构被悄悄破坏了、命名被偷偷改了、异常处理链路断了。模型不是故意的——它只是在一个没有约束的空间里做了局部最优化。

反过来，我也见过用一个中等模型、但系统结构极好的团队：目标明确、上下文干净、测试充分、反馈快速。他们的产出反而更稳定、更可预测、更少翻车。

教训很清楚：不要投资在找最好的模型上。投资在建最好的系统上。

信号问题

再说信息论。

Shannon 在 1948 年提出了一个模型：信号从信源出发，经过编码，通过有噪声的信道，到达解码器，最后被信宿接收。他关心的核心问题是：信号在这个过程中损失了多少？

把这个模型搬到 AI coding 上，你会发现一个让人不安的对应关系：

你脑子里的需求是信源。你写的 prompt 是编码器。上下文窗口是信道。所有模糊的措辞、缺失的约束、矛盾的文档、无关的日志，都是噪声。模型的内部处理是解码器。最后生成的代码是信宿接收到的结果。

这个类比能解释一个让工程师们反复挫败的现象：你明明说得很清楚了，模型还是做错了。

但你真的说清楚了吗？

Anthropic 有一条建议特别好：把你的 prompt 给一个对任务完全没有背景的同事看，如果他会困惑，Claude 也会困惑。

大多数时候，工程师以为自己在”下达指令”，其实他们在做的事情更接近”在一个有损信道上传输一个编码质量很差的信号”。你的需求里有大量隐含假设，你的 prompt 里有大量歧义，你扔给模型的上下文里有大量噪声。模型不是不聪明，是你的信号到达它时已经面目全非了。

信息论还揭示了另一个被低估的事实：文档在 AI 时代变成了一等公民。

为什么？因为 LLM 不继承默会知识。人类高手可以靠直觉和经验补齐文档里没写的东西，模型做不到。它只能消费外显材料。所以，你的需求文档、设计文档、接口契约、样例输入输出——这些不只是给人看的说明书，它们同时也是给模型看的编码协议。

写好文档从来就重要。但在 AI coding 时代，写好文档从”应该做”变成了”不做就会翻车”。

纠偏问题

最后说控制论。

控制论的核心非常简单：定目标，测状态，算偏差，做修正。循环往复。

在 AI coding 里，这意味着什么？

意味着 AI coding 的核心能力不是生成，而是纠偏。

这个判断和大多数人的直觉相反。人们看到 LLM 能秒出一整个文件的代码，会觉得”生成”才是核心价值。但生成是便宜的——而且越来越便宜。真正昂贵的是判断生成结果对不对。

这就是为什么 TDD 在 AI 时代突然变得合理了。

很多工程师以前不喜欢 TDD，不是因为不知道测试重要，而是因为在人工时代，写实现已经够痛苦了，测试被当成额外负担。但 AI 时代翻转了这个等式：实现的成本塌陷了，验证的价值就相对飙升了。

TDD 本质上不是”先写测试”。它是先把”什么算正确”用机器可判定的形式写出来，然后才允许系统去搜索实现。用控制论的术语说，就是先设定参考值，再打开反馈回路。

控制论还有一条关键原则：反馈必须快。

反馈太慢的控制系统，和没有控制差不多。导弹如果每十秒才测一次位置，它就会飞到不知道哪里去。

AI coding 也一样。模型生成的速度极快，如果唯一的反馈点是”PR 合并后线上出故障”，那中间的所有偏差都在高速累积。更好的做法是把反馈层层前置：lint 在本地拦，单测在提交前跑，契约测试在 CI 里拦，trace grading 在部署前做，人工 review 作为最后一道门。

每多一层反馈，偏差就少累积一步。

真正的竞争力

把这三个视角合在一起，你会得到一个关于 AI coding 的统一认识：

AI coding 的真正操作对象不是代码，而是一个生成的可能性空间。系统论决定这个空间的形状，信息论决定空间里的信号质量，控制论决定空间的收敛速度。

一个模型很强但系统很差的项目，就像一台高马力发动机装在一辆没有方向盘的车上——跑得越快，偏得越远。

一个系统很好但模型一般的项目，就像一辆底盘扎实的车装了一台够用的发动机——不会飙出最高速度，但能稳定地到达目的地。

你应该选哪个？

如果你是在做 demo，选前者。如果你是在做工程，选后者。

方法论的重心迁移

这篇文章真正想说的，其实是一个更大的判断：

软件工程的方法论重心正在从”实现”迁移到”治理”。

传统时代的工程师是实现者：理解需求，手写代码，调试发布。AI 时代的工程师更接近于系统设计者、信息架构师和反馈回路工程师。

这不意味着写代码能力不重要了。它意味着写代码能力被纳入了一个更高阶的框架。最终，最有价值的工程师不是那个手写最多代码的人，而是那个能——

把复杂目标变成清晰的系统结构
把模糊意图变成高保真的信号
把不稳定的生成纳入可控制的反馈回路

的人。

你可能觉得这些话太抽象。那我给你五个明天就能做的具体动作：

在让 AI 写代码之前，先写测试。不是因为测试高尚，而是因为它能让你更快地知道 AI 写的东西对不对。
写 prompt 之前，先把它给一个对任务没有背景的同事看。如果他困惑了，改 prompt，不要改同事。
反馈做短。能在本地验证的别等 CI，能在单测里抓的别等联调。
文档当工程资产写，不当行政材料写。因为模型真的在读它。
复盘 AI coding 失败时，区分三类原因：系统问题（边界没划清）、信号问题（信息失真）、反馈问题（测试没覆盖）。别只说”模型不行”——这句话几乎没有信息量。

结尾

三论不是老知识。它们是理解 AI coding 的底层语法。

系统论告诉你：别只看模型，看整体。
信息论告诉你：别只怪模型蠢，先看你的信号有多脏。
控制论告诉你：别指望一次说清，建反馈回路。

AI coding 的真正难题不是 AI。是你围绕 AI 建的那个系统。