AI Coding 的底层框架：一切优化都是在对抗熵增

AI Coding 的概念更新速度很快。Context Engineering、RAG、Agent Memory、Harness Engineering、SDD……每隔一段时间就有新词出现，每个词背后都跟着一批工具、框架和最佳实践。

🤔如果每次都从头学，很容易陷入一种焦虑：不知道哪个值得投入，不知道哪个适合自己手头的场景，也不确定今天学的东西明天还算不算数🤯

本文是作者最近的一些思考以及和大模型讨论的结果，尝试从 AI 大模型的本质出发，建立一个思考框架。

有了这个框架，遇到新概念时可以先问两个问题：①它在解决哪一层的问题？②它对当前场景的信息流动有没有实质帮助？答案通常会比预期清晰得多……

先从几个具体问题入手——这些问题大家可能都碰到和思考过：

• 为什么 Prompt 写得很细，AI 还是会输出和预期相悖的结果？

• 为什么 AI Coding 在新项目上很好用，在历史包袱重的业务上却容易卡住？

• 类似 OpenClaw 的对话式 Agent，能不能真的只给一份需求文档或链接，就完成整个需求的交付？

• OpenClaw、Hermes 这类 Agent 都在做记忆机制，记忆越多，AI 是更准确，还是更容易走神？

我想用信息论来回答这些问题。这里不是要把 AI Coding 严格建模成一套完整的概率系统，而是借信息论提供一个坐标系：哪些优化手段真的在对抗熵增，哪些只是占满了上下文窗口，哪些问题能靠工程手段改善，哪些本来就需要人介入。

目前 AI Coding 里公认最好用的模型之一 Claude，其名字本身就来自信息论的奠基人克劳德·香农（Claude Shannon）——他在 1948 年发表的《通信的数学理论》奠定了整个信息论的基础。用香农奠定的信息论，来分析 AI Coding 里的信息流动问题，算是一个小小的呼应。

先看三个概念：熵、条件熵、互信息。它们不复杂，但很适合描述 AI Coding 里的几个核心变量。

熵用来衡量一个变量的不确定性。对随机变量 X 来说，熵 H(X) 定义为：

通俗点说，熵就是可能性空间有多大。

抛一枚均匀硬币，正反面概率各 0.5，结果有 1 bit 的信息量。告诉你明天太阳从东方升起，信息量接近 0，因为它几乎没有不确定性。越不可预测的事情，发生时带来的信息越多。

放到 AI Coding 里，用户说写一个登录函数，这件事的熵很高。语言可能是 Python、Go、JavaScript，认证方式可能是 Session、JWT、OAuth，错误处理也可能有很多种。目标越模糊，可能性空间越大。

条件熵 H(Y \mid X) 描述的是：已知 X 之后，Y 仍然有多少不确定性。

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

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

互信息 I(X;Y) 衡量的是：观测 X 能获得多少关于 Y 的信息。

这条式子很适合解释上下文为什么有用。上下文本身不神奇，它有用是因为它能排除错误方向，减少模型需要自由发挥的空间。

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

把上面的关系换个写法：

在 AI Coding 的语境里，可以粗略理解成：

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

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

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

这不是说每个代码任务都能被严格塞进这个公式里。真实任务里的 X、Y、用户意图和运行环境很难被完整定义成一个联合分布。但作为工程判断，它很有用：提升 AI Coding 质量，很多时候就是提高上下文和目标输出之间的互信息，或者减少模型必须猜的空间。

用登录函数的例子看：

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

• 补充 FastAPI、JWT、数据库模型、错误格式，I(X;Y) 变大。

• token 过期时间、错误文案、日志粒度这些没写清的部分，仍然落在 H(Y｜X) 里。

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

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

我们可以把 LLM 理解为对于下一 token 预测。即给定当前上下文，模型输出下一个 token 的概率分布：

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

这带来一个关键区分：模型很自信，不等于模型说得对。

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

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

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

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

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

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

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

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

很多 AI Coding 的失败不是模型输出发散，而是它太自信地遵循了另一个世界的规则。它写的是公开社区里合理的代码，不是你当前业务里能跑的代码。

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

3.1.3 两类常见失败

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

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

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

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

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

• 有用信号被冗余内容淹没，模型看到了但没用上。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• H(Y \mid 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) 差距？

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

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

但 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 Coding，真正困难的不是让模型写代码，而是让模型知道哪些地方不能按通用经验写。

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

在真实的复杂业务场景中，中间没有人的介入，很难跑通。

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

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

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

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

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

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

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

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

这里也可以用信息密度看：

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

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

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

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

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

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

上面四个问题，构成了这个框架最直接的应用场景。但同一个坐标系还可以用来看两个最近被反复讨论的话题：Harness Engineering 和产研角色的变化。

一个关于工程系统怎么设计，一个关于人的分工如何重塑，但底层都是同一件事——让真实约束更多地暴露出来，让模型少猜一点。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

回到开头的问题，AI Coding 里的新概念不必一个个追着焦虑。可以先问两个问题：

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

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

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

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

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