三副眼镜看 AI 编程：为什么你的代码”看起来对了”却总出事
一、一个被低估了六十年的老工具箱
1948 年，Claude Shannon 发表了信息论的奠基论文。同一年，Norbert Wiener 出版了《控制论》。再往前几年，Ludwig von Bertalanffy 已经在推销他的一般系统论。这三个人各干各的，互相之间未必认同，但后来被中文学术圈捆在一起，称为”三论”。
这个并称其实有争议——钱学森就批评过，说这种并列太粗糙。但争议本身不重要。重要的是：这三套理论，恰好提供了三副不同焦距的眼镜，而 AI coding 碰巧需要你同时戴上这三副。
你可能会想：1948 年的东西，跟我今天用 Claude Code 写项目有什么关系？
关系大了。而且不是那种”知识分子硬拗”的关系，是那种”不理解这三个视角，你在 AI coding 里踩的坑就会一直踩下去”的关系。
二、先用三十秒把三论讲清楚
系统论问的是：这东西整体是怎么组织起来的？哪些部件在互相影响？边界画在哪？
信息论问的是：信号从发出到接收，中间丢了什么？噪声从哪儿混进来的？
控制论问的是：事情开始跑了以后，怎么发现它跑偏了，又怎么把它拉回来？
就这么简单。但这三个问题一旦叠加到 AI coding 上，杀伤力极大。
因为 AI coding 偏偏同时具备三个特征：它是一个复杂系统（不只是模型，而是人 + 模型 + 工具 + 代码库 + 测试 + 部署的整体）；它天然有信息失真（你说的话模型未必懂，模型做的事你未必察觉）；它非确定性地波动（同样的输入，今天能跑，明天可能翻车）。
这就是为什么三论突然变得有现实感。不是你去找它，是 AI coding 把你推到了它面前。
三、系统论：别只盯着模型——那只是冰山一角
很多人理解 AI coding，起点是”哪个模型最强”。
这不能说错，但太窄了。就好像问”哪个发动机最好”，却不看底盘、变速箱、悬挂、轮胎和路况。
系统论会逼你把镜头拉远。一个 AI coding 系统至少包含：用户目标、代码库、文档、提示词、工具链、测试、CI、review 流程、部署管道、监控机制，以及人和模型之间那个微妙的交互契约。真正决定结果的，往往不是某个点最强，而是这些部件之间的接缝有没有漏风。
OpenAI 的 agent 指南把 agent 的基本形态概括成三样东西：模型、工具、指令。你看，这已经很系统论了。一个 agent 能不能工作，不在于其中哪一项单独有多猛，而在于三者有没有咬合成一个整体。
这里有一个反直觉的结论：一个 90 分的模型放进 60 分的系统，不如一个 75 分的模型放进 85 分的系统。
为什么？因为强模型在弱系统里只会更快地产出高质量的错觉。它把函数写得漂亮极了，但破坏了架构；把 bug 修掉了，但引入了回归；帮你加了功能，但顺手改坏了日志链路。没有清晰的边界定义，没有完备的测试，没有人工审查，模型越强，翻车越隐蔽。
所以系统论给 AI coding 的第一课是：别搞模型崇拜，去搞系统设计。
问自己：这个系统的部件如何协同？知识如何沉淀？故障如何暴露？出错后如何恢复？一旦这样提问，你就已经站在了正确的地面上。
四、信息论：你以为你在下指令，其实你在做编码
这是我觉得三论里对 AI coding 最有穿透力的一个视角。
Shannon 模型里有六个环节：信源、编码器、信道、噪声、解码器、信宿。把它类比到 AI coding——
- 你脑子里的需求，是信源。
- 你写的 prompt、文档、示例，是编码器。
- 上下文窗口、工具调用、检索结果，是信道。
- 模糊措辞、缺失约束、冲突文档、无关日志、过长上下文，全是噪声。
- 模型的内部处理，是解码器。
- 最后吐出来的代码，是信宿收到的结果。
这当然是类比，不是 Shannon 原意。但它能解释一个让人抓狂的现象：你明明讲过了，模型还是做错。
为什么？因为你不是在”下命令”，你是在做”编码”。你的意图要经过语言表述、上下文组装、信道容量限制、噪声干扰，才能到达模型的”解码器”。中间任何一环出问题，结果就失真。
Anthropic 的 prompt 最佳实践里有一句话特别到位：把你的 prompt 给一个对任务几乎没背景的同事看，如果他会困惑，Claude 也会困惑。
这句话的信息论翻译是：你的编码器输出的信号，连人类解码器都解不对，凭什么指望 LLM 解码器能行？
这个视角还能解释另一件事：为什么文档在 AI 时代突然变重要了？
过去很多高手靠默会知识工作——架构意图在脑子里，隐含规范在经验里，边界条件靠直觉兜。LLM 不继承默会知识。它吃的是外显材料。所以，需求文档、设计文档、ADR、接口契约、样例输入输出、错误码说明——这些不只是给人看的说明书，它们也是给模型看的编码协议。
谁能把默会知识转成高保真、低歧义、可复用的表达，谁就掌握了信息论意义上的优势。
再补一个容易踩的坑：上下文不是越多越好，而是信噪比越高越好。 Anthropic 建议编码任务一开始就提供完整上下文，把相关代码片段一次性给全——但”完整”不等于”把仓库垃圾一股脑扔进去”。关键是让模型在最少噪声下接触到最关键的信息。过量且无组织的信息，会把信号淹没。
所以信息论给 AI coding 的第二课是：结果之所以乱，常常不是末端的问题，而是信号在前面就已经失真了。 工程师最该升级的，不是”写更花哨的 prompt”，而是设计更高质量的编码结构。
五、控制论：既然拦不住波动，那就别拦——去设计纠偏回路
这是三论里最实用的一副眼镜。
控制论的核心操作只有四步：定目标、测状态、算偏差、做修正。恒温器是这样工作的，导弹制导是这样工作的，自动驾驶也是这样工作的。
把它翻译到 AI coding：先定义”正确”长什么样（测试、验收标准）；再测量模型实际产出（跑测试、review 代码）；识别偏差（哪些测试挂了、哪些风格不对）；然后通过再提示、重跑、补约束、人工介入等方式修正。
这就是为什么 TDD、eval、review、CI、回归测试、trace，本质上都是控制论装置。它们不是”附加管理”，而是系统稳定性的核心硬件。
这里有一个特别关键的洞见：AI 时代，实现的边际成本在暴跌，而验证的边际价值在暴涨。
想想看：过去人工写代码，实现是最痛苦的部分，测试容易被当成拖后腿的成本。现在 LLM 可以秒出代码，真正贵的不是生成，而是确认。TDD 之所以在 AI 时代突然变得顺理成章，不是因为工程师突然变保守了，而是因为经济学翻转了——生产便宜了，质检就值钱了。
控制论还会提醒你一个容易忽略的点：反馈必须足够快。
反馈太慢，系统就会在错误轨道上跑很远。AI coding 时代尤其如此——模型生成速度极快，如果你把唯一反馈点放在”集成测试结束后”或”PR 合并前”，那你其实是在允许错误高速累积。更好的做法是把反馈层层前置：lint 是一层，类型检查是一层，单测是一层，契约测试是一层，trace grading 是一层，人工 review 又是一层。多层反馈的目的不是苛刻，而是降低单次偏离的代价。
所以控制论给 AI coding 的第三课是：不要妄图靠一次 prompt 把一切说死，去设计一套能持续修正的反馈结构。
六、三副眼镜合在一起看：你管理的不是代码，是”可能性空间”
单独戴任何一副眼镜，你都只能看到一部分。三副一起戴，画面就完整了：
系统论决定了这个空间的边界和部件——有哪些工具、文档、规则、角色、回路。
信息论决定了空间里的信号质量——目标有没有传清、约束有没有丢、上下文有没有被污染。
控制论决定了空间的收敛机制——当输出偏离目标时，系统如何把它拉回来。
一个模型非常会生成，但只要系统边界模糊、信息编码糟糕、反馈回路稀薄，它就会在错误方向上高效前进。反过来，一个不是榜单冠军的模型，如果系统结构清楚、信号高保真、控制回路密实，它反而能持续产出稳定价值。
这就引出了一个更大的判断——
七、时代判断：从”制造代码”到”治理生成”
传统时代，工程师的核心形象是”实现者”——理解需求，亲手编码，调试发布。
AI 时代，这个形象在变。工程师越来越像一个系统设计者 + 信息架构师 + 反馈回路工程师。
软件工程的重心，正在从”如何制造代码”转向”如何治理生成”。
治理什么？
- 治理部件关系——系统论。
- 治理语义传输——信息论。
- 治理偏差收敛——控制论。
你对 TDD、评测、工作流、验证这些词越来越有感觉，不是因为你变保守了，而是因为你在直觉上抓到了 AI 时代最稀缺的东西：不是生成能力，而是让生成收敛为可靠产物的能力。
八、五个你明天就能做的事
理论再好，不落地就是空转。收缩成五个动作：
第一，把 TDD 扩展成广义测试驱动。 验收清单、API 样例、错误码断言、边界 case、回归场景表，都是”先定义正确，再驱动生成”。
第二，设计阶段优先考虑可测性。 你的模块如果副作用太重、输入输出不可观察，后面 AI 再强也难合作。
第三，把文档当编码协议。 需求文档、设计文档、ADR 不是项目装饰品，它们是减少信息失真的工具。谁先把默会知识写成模型能理解的材料，谁先建立优势。
第四，把反馈回路做短。 能在本地检查的不等 CI，能在单测发现的不等联调，能在 eval 复现的不靠线上事故学习。
第五，复盘时用三论分类。 别只说”模型今天状态不好”。问自己：这是结构问题（边界没划清）？信息问题（文档失真）？还是反馈问题（测试没覆盖）？一旦这样分类，抱怨就变成了工程改进项。
九、一句话收尾
如果把整篇压缩成一句话：
AI 时代的软件工程，就是在一个高能力、高波动的生成系统中，通过好的系统结构、清晰的信息编码和密实的反馈回路，把”可能正确”不断压缩成”稳定正确”。
三论不是老知识。它是 AI 时代的工程母语——只不过你今天才有了足够的实感去听懂它。