导读

你是否也曾感到困惑：即使 Prompt 写得像在指导初学者，AI 却依然会给出一个完全出乎意料的结果？新项目上手时，AI 堪称利器，但一旦遇到遗留业务，就频繁出错？

本文从一个看似偏理论的视角——信息论——来剖析 AI 编程（AI Coding）中的各种疑难杂症。听起来可能有些学术，但其核心逻辑十分朴素：当你不再被每几个月冒出的新概念追着跑，而是退回到“信息”和“不确定性”这两个基本词汇上时，许多问题会突然变得清晰起来。

首先列出几个一定会遇到的典型场景，然后我们一起探讨它们背后共通的东西。

01 引言

AI 编程领域的概念更新实在是太快了。Context Engineering、RAG、Agent Memory、Harness Engineering、SDD……每隔一小段时间就会蹦出一个新词，每个词后面还跟着一堆工具、框架和所谓的“最佳实践”。

概念多本身不是问题，问题是这些概念到底要解决什么？先把几个最棘手的具体问题摆出来——这些都是大家在实际工作中大概率遇到过、思考过的：

• 为什么 Prompt 已经写得特别详细了，AI 仍然可能输出一个与你预期完全相反的结果？

• 为什么在新项目上顺风顺水的 AI 编程，到了历史包袱较重的业务上就频频被卡住？

• 像 OpenClaw 这种对话式 Agent，真的能只丢给它一份需求文档或者一个链接，然后等着它把整个需求交付完吗？

• 还有那些 Agent 正在折腾的记忆机制——记忆越多，AI 到底是更准确了，还是更容易走神？

下面这篇文章将用信息论来回答这些问题。这里并不是要把 AI 编程严格建模成一套完美的概率系统，而是借信息论搭建一个“坐标系”：用它能看清楚，哪些优化手段是真正在对抗熵增，哪些只是把上下文窗口堆满了却没什么用，哪些问题靠工程手段能改善，哪些问题本来就必须有人介入。

02 信息论视角

先看三个基本概念：熵、条件熵、互信息。它们并不复杂，但非常适合用来描述 AI 编程里那几个最核心的变量。

2.1 熵：可能性的大小

熵，本质上衡量的是一个变量的不确定性有多大。

对随机变量 X 来说，熵 H(X) 的定义是：

（公式略）

说得更直白一点就是——可能性空间有多大。

抛一枚均匀硬币，正反概率各一半，结果包含 1 bit 的信息量。如果告诉你明天太阳从东方升起，这个信息量就接近于零，因为这件事几乎没有任何不确定性。越不可预测的事情，发生时带来的信息就越多。

放到 AI 编程里，用户说“写一个登录函数”，这件事的熵就很高。语言可能是 Python、Go 或 JavaScript，认证方式可能是 Session、JWT 或 OAuth，错误处理的方式也是五花八门。目标越模糊，可能性空间就越大。

2.2 条件熵：看完上下文后还剩多少不确定性

条件熵 H(Y|X) 说的是：已知 X 之后，Y 仍然剩下多少不确定性。

（公式略）

假设 X 是你给 AI 的上下文，Y 是它要生成的代码。那么 H(Y|X) 就是模型看完你给的上下文之后，仍然需要自己猜的那部分。

你只说一句“写一个登录函数”，剩余不确定性很大。当你补充说“用 Python、FastAPI、JWT、参考现有的 UserService、错误格式沿用 ApiError”，模型就能排除掉大量可能性，剩下需要它自己去猜的东西就少得多了。

2.3 互信息：上下文帮你排除了多少可能性

互信息 I(X;Y) 衡量的是：观察到 X 之后，能获得多少关于 Y 的信息。

（公式略）

这个公式特别适合解释一件事情：上下文为什么有用。上下文本身并不神奇，它之所以有用，是因为它能排除掉错误的方向，减少模型需要自由发挥的空间。

RAG 也是这个逻辑。检索并不是把整个知识库塞给模型，而是找到和当前任务“互信息”最高的那几段内容。一次精准的召回，能直接告诉模型这次该用哪个接口、哪个类型、哪条业务约定——它减少的，本质上是模型的剩余猜测空间。

2.4 一个有用的分解

把上面的关系换个写法：

（公式略）

在 AI 编程的语境里，可以粗略这样理解：

• H(Y)：目标代码本身的全部可能性。

• I(X;Y)：上下文帮模型排除掉的那部分不确定性。

• H(Y|X)：模型最后还得靠自己的通用经验去补的那部分。

当然，这并不是说每个代码任务都能被严格塞进这个公式里。真实任务里的 X、Y、用户意图和运行环境，很难被完整定义成一个联合分布。但作为工程判断的参考，它非常有用：提升 AI 编程质量，很大程度上就是在做两件事——要么提高上下文与目标输出之间的互信息，要么减少模型被迫去猜的空间。

还用登录函数的例子来看：

• 只说“写一个登录函数”，H(Y) 很大。

• 补充说“用 FastAPI、JWT、数据库模型长什么样、错误格式是什么”，I(X;Y) 就变大了。

• 但 token 过期时间设多久、错误文案怎么写、日志粒度要多细——这些没写清楚的部分，仍然落在 H(Y|X) 里。

AI 最容易出问题的地方，通常就在最后这一块。

（图片位置）

03 理想模型的两个现实修正

信息论确实给出了一个简洁的分解框架，但 LLM 并不是理想的信息处理器。把这个框架落到实际场景里，有两处非常重要的修正：第一，模型填补剩余不确定性时，依赖的是训练时积累的先验知识，而不是你业务的真实分布；第二，即便上下文给够了，注意力机制的限制也决定了信息量不能无限堆叠。

3.1 修正一：低熵不等于正确——模型输出分布 P 与业务真实分布 Q 的差距

可以把 LLM 理解为在做“下一个 token 的预测”——给定当前上下文，模型输出下一个 token 的概率分布。

不过，说“LLM 的本质就是最小化条件熵”，容易说过头。更准确的说法是：训练时，模型通过最小化训练数据分布下的交叉熵，让自己的分布 P 尽量逼近数据的分布 Q；推理时，它在给定上下文之后给出一个概率分布，再通过采样策略从这里面选出最终输出。

这里有一个非常关键的区别：模型很自信，不等于模型说得对。

3.1.1 模型自信：低熵不等于正确

当模型在自己的分布 P 下对某个输出的概率很高时，它会显得特别笃定。它能稳定地写出来某个函数名、某个 API 调用、某种目录结构——因为这些模式在训练数据里非常常见。

但问题在于：你当前仓库里的真实规则，并不一定在训练分布里。

举个例子：模型自信地调用了一个 userClient.getProfile()，因为这个名字非常符合通用的代码习惯；但你的项目里真实存在的是 profileService.fetchByUid()，而且还必须带上灰度参数。模型的输出从语言模式上看非常顺畅，但在当前业务里却是错的。

所以，“低熵”更像是模型的自信度，不等于正确性。模型输出的“内部一致”是指它在多文件、多步骤的生成过程中不自相矛盾——但低熵的输出完全可能内部一致却业务错误，比如自信地调用了一个根本不存在的 API。真正的正确性，要看它是不是贴合了业务里真实的约束条件。

3.1.2 贴合真实约束：交叉熵才是更关键的问题

模型分布 P 和真实业务分布 Q 之间的差距，可以用交叉熵来理解：

（公式略）

这里的 Q 不仅仅是公开互联网代码的规律，它还包括你私有的仓库、业务约定、运行环境、团队审美、历史包袱和测试约束。

不少 AI 编程的失败案例，原因并不是模型输出“发散”，而是它太自信地遵循了另一个世界的规则。它写出的是公开社区里看起来合理的代码，而不是你当前业务里能跑的代码。

这也是复杂历史业务难做的根本原因之一：真实约束藏在私有代码和团队经验里，而模型先验来自公开语料。P 和 Q 之间的差距越大，就越不能指望模型靠猜来补齐。

3.1.3 两类常见失败

（图片位置）

这里的重点，不是让模型永远更自信，而是让它的自信建立在正确的约束之上。这两类失败的底层机制，在后面框架总览的部分会做进一步归纳。

3.2 修正二：上下文并非越多越好——信息密度的边界

增加上下文通常是对的，但并不是越多越好。

在理想的信息论模型里，加入一个新的上下文 Z 之后，条件熵不会增加：

（公式略）

如果 Z 和任务相关，它理论上能减少不确定性。问题在于，LLM 不是理想的条件熵最小化器。它有自己的上下文窗口，有注意力分配的限制，有检索误差，也会被冲突信息带偏。

上下文太多，会带来两个问题：

• 有用的信号被冗余内容淹没——模型虽然看到了，但实际用不上。

• 无关或矛盾的信息引入歧义，反而让输出分布变得更乱。

（图片位置）

评估一个 AI 编程优化方案，可以问两个问题：

1. 它能不能真正增加上下文和目标输出之间的互信息？

2. 它的信息密度够不够高？

两个问题都得成立，才是好的优化。

（图片位置）

RAG 的价值有一个前提：召回必须足够准。它本身并不是天然提高质量的机制；只有当召回片段和当前任务强相关时，它才是在提高单位 token 的有效信息量。召回错了，反而会把模型带偏。

3.2.1 有些上下文会降低有效信息

反过来看，不是所有输入都会帮到 AI。有些做法不仅收益低，而且是明确有害的。它们要么降低了信息密度，要么把错误的先验注入了模型，要么让模型在冲突的约束之间来回摇摆。

（图片位置）

最危险的是错误上下文。低密度上下文只是“偷走”注意力，而错误上下文会直接“污染”方向。比如旧文档里说“用户状态可以直接改”，但真实代码已经迁到了状态机流程，模型看到旧文档之后，会更有自信地走错路。

冲突约束也很常见。Prompt 里一边写着“尽量少改动”，一边又要求“彻底重构”；Rules 里说“不要新增依赖”，但任务描述又在暗示用新库最快。模型并不会真正理解团队的优先级，它只能在这些约束之间做概率上的折中，最后产出的代码是每个局部都说得过去、整体却完全不符合预期的。

还有一种更隐蔽的问题，是让 Agent 把任务边界越放越大。本来只是修一个字段的展示，它顺手就重构了整个状态管理；本来只是补一个测试，它顺手就改了生产逻辑让测试通过。任务边界一放大，H(Y) 就被放大了，模型自由发挥的空间也跟着膨胀。

所以，AI 编程里的负面原则可以说得非常直接：不要给低密度上下文，不要给错误上下文，不要给冲突约束，不要让模型自己去猜业务决策，不要跳过验证继续往下跑。这些行为会引导模型在推理时遵循错误的先验，让输出更接近“假设的 Q”，而非“真实的 Q”。

（图片位置）

04 框架总览

整个框架由两个核心公式构成，分别对应两个独立的失败维度。

第一个公式描述的是：上下文如何分配任务的不确定性。

（公式略）

其中 Y 为目标代码，X 为输入给模型的上下文；H 衡量不确定性的大小，I 衡量两个变量之间共享的信息量。

• H(Y)：目标代码的可能性空间——由任务本身决定，可以通过任务拆解来缩小；

• I(X;Y)：上下文帮模型排除了多少不确定性（互信息）；

• H(Y|X)：看完上下文之后，模型还得靠自己猜的那部分（条件熵）。

第二个公式描述的是：模型填补剩余不确定性时的准确度。

（公式略）

P 是模型在公开语料上训练出来的先验分布，Q 是当前业务的真实约束分布。两者差距越大，模型就越容易自信地用错误的规则去填补空白。

两个公式对应的两个独立失败维度：

第一层：覆盖层——显性上下文消除了多少熵？

• 核心指标：I(X;Y) / |Context|（信息密度）
• 行动：Rules、Skills、MCP、示例、约定显性化、RAG
• 失败表现：输出含糊、摇摆、前后不一致（H(Y|X) 太大）

第二层：填补层——剩余的熵被正确填补了吗？

• 核心指标：H(Q,P)
• 行动：检索业务代码、显性化私有约定、测试和 review 校准
• 失败表现：输出稳定但业务上是错的（模型自信地用公开先验填了私有空白）

这两层独立发挥作用。第一层决定了 H(Y|X) 的大小，第二层决定了模型填补 H(Y|X) 时的方向。上下文再充分，私有业务约定里总会有模型看不到的部分；只要 H(Q,P) 大，那些剩余空白就会被错误的方向填满。

这也是前面“两类常见失败”的底层解释：含糊摇摆是第一层出了问题，一本正经地写错是第二层出了问题，两者需要完全不同的处理方式。

实际操作中，这两层都可以通过补充上下文来改善，但补充的内容性质不同：第一层补的是任务级信息——这次用什么接口、参考哪段代码——每次任务都不一样；第二层补的是项目级规则——我们的状态机约定是什么、错误码规范是怎样的、兼容层逻辑怎么处理——一次写清楚就能在所有任务里复用。当遇到“一本正经地写错”的情况时，继续堆任务上下文往往没什么效果，真正需要做的，是把业务约定显性化，沉淀进 Rules 或者项目 Memory 里去。

评估任何优化手段时，先问清楚它针对的是哪一层：是在提高 I(X;Y) 的信息密度，还是在缩小 H(Q,P) 的差距？

（图片位置）

05 用这个框架看几个 AI 编程问题

Q1. 为什么 Prompt 写得很细，AI 还是和预期相悖？

人类意图是高维的。你说“这里做得优雅一点”，里面可能包含了几十个隐含判断：不要影响现有接口、不要引入新依赖、不要改太多文件、保持团队风格、性能别退化、错误提示别太生硬……

但 Prompt 是低维的。你能写进 Prompt 里的，只是你意图的一小部分。

这就导致了一个非常常见的错位：你以为你已经说清楚了，模型实际上只收到了其中的一小块。剩下的空白，会自动由模型自己的通用经验去补上。

从这个角度看，很多 Prompt 技巧其实并不神秘。它们之所以有效，是因为它们把隐性的意图变成了可见的上下文：

• 给反例，是在告诉模型哪些路径不能走。

• 给 Few-shot 示例，是在告诉模型当前任务的局部分布长什么样。

• 给验收标准，是在告诉模型什么输出算对。

• 给现有代码片段，是在告诉模型当前仓库的真实风格和接口。

Prompt 的目标不是把话写得漂亮，而是尽量减少模型需要猜的部分——也就是最大化 I(X;Y)，把 H(Y|X) 压到尽可能小。

Q2. 为什么新业务更容易，复杂历史业务更难？

新项目对 AI 友好，并不只是因为代码量少。更关键的原因是：新项目的真实约束，往往更接近模型在训练中见到的公开模式。

比如一个从零开始的 React + FastAPI 项目，只要没有引入太多私有规则，模型的通用经验就够用了。目录怎么放、接口怎么写、状态怎么管理、测试怎么组织——网上有大量相似的样本。模型的分布 P 和这个项目的真实分布 Q，重合度比较高。

历史业务正好相反。它的难点不在于代码量大，而在于隐性规则多：

• 这个字段为什么不能改名。

• 这个接口为什么必须兼容一个旧客户端。

• 这个工具函数为什么看起来绕，但不能替换成标准库。

• 这个错误码为什么不能用更合理的新枚举。

• 这段代码为什么必须按某个看起来不自然的顺序执行。

这些信息通常不在公开训练数据里，也不一定写在文档里。对模型来说，它们不是“复杂知识”，而是“不可见知识”。不可见知识再重要，也不会自动进入上下文。

从框架来看，历史业务面对的是双重困境：隐性规则无法进入上下文，I(X;Y) 对最关键的约束几乎为零；同时，模型先验 P 和业务真实分布 Q 差距大，H(Q,P) 很高，模型会自信地用公开模式去填补那些空白。

所以，历史业务里的 AI 编程，真正困难的地方不是让模型写代码，而是让模型知道哪些地方不能按通用经验来写。

Q3. 对话式 Agent 能不能只给需求文档就完成整个交付？

在真实的复杂业务场景里，如果中间没有人介入，基本不可能跑通。

原因不是模型能力不够，而是这条链路本身存在一个信息上的上限。数据处理不等式给出了一个非常硬性的限制：

（公式略）

根据数据处理不等式，信息在经过多步处理之后，只会损耗，不会增加。需求文档里没有表达出来的意图，Agent 在后续的步骤里是无法恢复的。

真实的复杂业务里，大量关键约束属于填补层的问题——兼容逻辑、历史包袱、团队默认的业务边界——这些东西往往没有被写进任何文档，也没有被编码进任何测试。H(Q,P) 的差距非常大，模型只能用公开先验去填，而公开先验在这里大概率是错的。

理论上，Agent 可以通过检索代码、跑测试、看日志、根据失败结果再重试来弥补一部分覆盖层的缺口。但填补层的缺口——那些从来没有被表达出来的业务意图——是自动化真正的边界。越过这条线，就必须有人介入。

所以，衡量一个 Agent 系统的关键，不是模型会不会写代码，而是它有没有办法识别哪些缺口是可以自动弥补的，哪些必须升级给人。能把这两类缺口分开的系统，才能在复杂业务里稳定落地。

Q4. 记忆越多，AI 越准确还是越容易走神？

记忆越多不一定越准，关键在于召回的记忆是否和当前任务强相关。

从理想模型来看，相关信息越多，条件熵就越低。但真实的 LLM 有注意力的限制，记忆系统也有检索误差。召回太多低相关性的记忆，会稀释真正有用的信号；召回过期的记忆，还会把模型带到旧规则里去。

这里也可以用信息密度来评估：

（公式略）

记忆系统的竞争力不在于存了多少东西，而在于每次能不能召回少量高密度的信息。

设计记忆机制时，可以优先看三件事：

• 存什么：存犯错记录、业务约定、架构决策、偏好边界，少存流水账。

• 怎么检索：宁可少召回几条强相关的记忆，也不要塞一堆弱相关的背景。

• 何时遗忘：过期的 API、废弃的模式、错误的经验要清理。这些东西不会直接降低互信息，但会把模型先验 P 往错误的旧规则上推，放大 H(Q,P) 的差距，让模型更自信地走错路——这属于填补层的污染，比低密度信息的危害更大。

OpenClaw、Hermes 这类 Agent 的记忆机制，本质上是在做信息密度的优化，而不是在比谁存得多。

上面四个问题，构成了这个框架最直接的应用场景。但同一个坐标系，还可以用来看看最近被反复讨论的两个话题：Harness Engineering 和产研角色的变化——一个是关于工程系统怎么设计，一个是关于人的分工如何重塑，但底层都是同一件事：让真实约束更多地暴露出来，让模型少猜一点。

06 框架的延伸：工程实践与角色重塑

6.1 Harness Engineering：把真实约束变成反馈回路

前面讲的 Context Engineering、RAG、记忆、SDD，都还偏向输入侧。Harness Engineering 更进一步，它关心的是整个外循环怎么组织。

可以把 Harness 理解为让模型作为一个“Agent”行动起来的外循环系统：

Harness = 计划分解 + 状态管理 + 工具编排 + 验证门控 + 反馈回路 + 回退机制 + 人机交接点

（图片位置：AI Coding 的底层框架：一切优化都是在对抗熵增）

模型的内循环是“给定上下文，预测下一个 token”。Harness 的外循环决定什么时候让模型动手、给它什么上下文、让它用哪些工具、怎么检查结果、失败之后怎么把反馈塞回下一轮。

从信息论的角度看，Harness 并不是简单地在给模型更多的上下文，而是在每一轮生成之后，把真实世界的约束不断地显性化。

（公式略）

这也是 Harness Engineering 比单纯的 Prompt Engineering 更接近工程系统的原因。Prompt 主要发生在一次模型调用之前，而 Harness 关心的是多轮行动里的信息流、验证流和状态流。

它的边界也很清楚：业务直觉、架构审美、跨系统的潜在耦合——很多时候没法完全写成自动测试。Harness 能把一部分隐性的 Q 转成可执行的约束，但不能替人恢复那些从来没有被表达出来的意图。

（图片位置）

6.2 产品、设计、研发的角色变化

Harness 解决的是系统怎么设计的问题，但信息密度的问题同样在重塑人的分工。

传统软件开发也可以看成一条信息传递链：

（图片位置）

每经过一次转译，信息都可能发生损耗——这是纯 Agent 自动化链路里不可逆的约束（见 5.3 节）。但人工协作的链路有一个根本的区别：每个角色都会从链路之外注入自己的领域经验和隐性知识。PRD 没写清楚的地方，设计师会凭用户洞察补上；设计稿没有表达完整的地方，研发会凭技术判断来填补。这种外部注入，是人介入的核心价值，也是人工协作可以局部弥补信息损耗的原因——这和 Agent 只能用链路内已有的信息往下传是不同的。当然，外部注入并不能彻底消除损耗，只是减缓了它：研发团队没有真正理解到的部分，代码仍然会偏离。

（图片位置）

AI 编程改变的，是执行的成本。代码生成变快之后，真正影响结果的环节变成了：谁能把意图高密度地表达出来，谁能验证输出是否贴合真实的约束。

这会让产品、设计、研发之间的边界变得越来越模糊。能写清楚规格的人、能提供高质量验收标准的人、能把隐性业务规则变成可执行检查的人，都会变得更加关键。SDD 可以看作这种变化的一种具体形态：先把意图压缩成高密度的规格，再让 AI 去做实现。

这种趋势还在沿着两个方向继续演化。

一是不同角色开始交付同一种产物。传统链路里，PM 交付 PRD、设计师交付视觉稿、研发交付代码——产物形态不同，转译几乎不可避免。但 Figma Make、Claude design 这类工具正在打破这条分工线：设计师可以直接从设计稿生成可运行的代码，PM 可以从原型草稿直接输出前端页面。这意味着信息链路中的一个转译节点被消除了——不再是“设计稿交给研发再翻译成代码”，而是设计稿本身就是代码。从信息论的角度看，这减少了一次转译的损耗，但也把更多的隐性约束（性能要求、兼容边界、可维护性）推迟到了更后面的环节。谁来承担这部分 H(Q,P) 的差距，是在新的角色分工里一个还没有被充分讨论的问题。

二是一人公司正在成为可能。当执行成本大幅下降，一个人可以同时承担 PM、设计、研发、测试的职能——不是因为每件事都做得最好，而是因为 AI 补足了单人在不同领域的技能短板。这个模式的信息优势非常明显：意图不需要跨角色传递，I(Context; intent) 天然就是最大的，转译的损耗几乎为零。代价是：一个人同时扮演多个角色，往往也意味着某些角色的专业判断被压缩了，H(Q,P) 在特定领域反而可能更大。一人公司并不是角色分工的终点，它揭示了一个新的权衡问题：信息传递的成本和专业的深度之间，边界到底在哪里。

07 结尾

回到开头的问题。AI 编程里的那些新概念，其实不必一个一个追着去焦虑。可以先问两个问题：

1. 它针对的是哪一层？是提高覆盖层的信息密度（增大 I(X;Y)/|Context|），还是校准填补层的方向（缩小模型先验 P 与业务真实分布 Q 的差距）？

2. 如果是覆盖层，有没有引入无关的信息把信号稀释了？如果是填补层，业务约定有没有被真正显性化，还是仍然留在团队成员的脑子里？

Context Engineering、RAG、记忆、SDD、Harness Engineering——都可以放到这个坐标系里来看。

上下文不够，工程上可以补。模型不了解私有业务，可以通过检索、记忆、测试和反馈来缩小差距。但意图本身就没有被表达出来，就必须让人介入。

边界看清楚之后，很多概念就没那么神秘了。它们都在处理同一件事：让模型少猜一点，让真实约束多暴露一点。这就是工程维度上对抗熵增的基本逻辑。