导读为什么 Prompt 写得再细AI 还是会输出奇怪的结果为什么新项目 AI 很好用历史业务却总是翻车本文作者从信息论出发用一个简单的框架帮你拆解 AI Coding 里的种种困惑——当你不再跟着新概念焦虑而是回到信息和不确定性的底层逻辑很多问题会清晰得多。01 引言AI Coding 的概念更新速度很快。Context Engineering、RAG、Agent Memory、Harness Engineering、SDD……每隔一段时间就有新词出现每个词背后都跟着一批工具、框架和最佳实践。如果每次都从头学很容易陷入一种焦虑不知道哪个值得投入不知道哪个适合自己手头的场景也不确定今天学的东西明天还算不算数本文是作者最近的一些思考以及和大模型讨论的结果尝试从 AI 大模型的本质出发建立一个思考框架。有了这个框架遇到新概念时可以先问两个问题①它在解决哪一层的问题②它对当前场景的信息流动有没有实质帮助答案通常会比预期清晰得多……先从几个具体问题入手——这些问题大家可能都碰到和思考过为什么 Prompt 写得很细AI 还是会输出和预期相悖的结果为什么 AI Coding 在新项目上很好用在历史包袱重的业务上却容易卡住类似 OpenClaw 的对话式 Agent能不能真的只给一份需求文档或链接就完成整个需求的交付OpenClaw、Hermes 这类 Agent 都在做记忆机制记忆越多AI 是更准确还是更容易走神我想用信息论来回答这些问题。这里不是要把 AI Coding 严格建模成一套完整的概率系统而是借信息论提供一个坐标系哪些优化手段真的在对抗熵增哪些只是占满了上下文窗口哪些问题能靠工程手段改善哪些本来就需要人介入。02 信息论视角目前 AI Coding 里公认最好用的模型之一 Claude其名字本身就来自信息论的奠基人克劳德·香农Claude Shannon——他在 1948 年发表的《通信的数学理论》奠定了整个信息论的基础。用香农奠定的信息论来分析 AI Coding 里的信息流动问题算是一个小小的呼应。先看三个概念熵、条件熵、互信息。它们不复杂但很适合描述 AI Coding 里的几个核心变量。2.1 熵可能性的大小熵用来衡量一个变量的不确定性。对随机变量 X 来说熵 H(X) 定义为通俗点说熵就是可能性空间有多大。抛一枚均匀硬币正反面概率各 0.5结果有 1 bit 的信息量。告诉你明天太阳从东方升起信息量接近 0因为它几乎没有不确定性。越不可预测的事情发生时带来的信息越多。放到 AI Coding 里用户说写一个登录函数这件事的熵很高。语言可能是 Python、Go、JavaScript认证方式可能是 Session、JWT、OAuth错误处理也可能有很多种。目标越模糊可能性空间越大。2.2 条件熵看完上下文后还剩多少不确定性条件熵 H(Y \mid X) 描述的是已知 X 之后Y 仍然有多少不确定性。如果 X 是你给 AI 的上下文Y 是它要生成的代码那么 H(YX) 就是模型看完上下文之后还需要自己猜的部分。你只说写一个登录函数剩余不确定性很大。你补充 Python、FastAPI、JWT、参考现有UserService、错误格式沿用ApiError模型能排除大量可能性剩下要猜的东西就少很多。2.3 互信息上下文帮你排除了多少可能性互信息 I(X;Y) 衡量的是观测 X 能获得多少关于 Y 的信息。这条式子很适合解释上下文为什么有用。上下文本身不神奇它有用是因为它能排除错误方向减少模型需要自由发挥的空间。RAG 也是这个逻辑。检索不是把知识库塞给模型而是找到和当前任务互信息最高的片段。一次精准召回能直接告诉模型该用哪个接口、哪个类型、哪个业务约定它减少的是剩余猜测空间。2.4 一个有用的分解把上面的关系换个写法在 AI Coding 的语境里可以粗略理解成H(Y)目标代码本身的全部可能性。I(X;Y)上下文帮模型排除的那部分不确定性。H(YX)模型最后还得靠自己的通用经验去补的部分。这不是说每个代码任务都能被严格塞进这个公式里。真实任务里的 X、Y、用户意图和运行环境很难被完整定义成一个联合分布。但作为工程判断它很有用提升 AI Coding 质量很多时候就是提高上下文和目标输出之间的互信息或者减少模型必须猜的空间。用登录函数的例子看只说写登录函数H(Y) 很大。补充 FastAPI、JWT、数据库模型、错误格式I(X;Y) 变大。token 过期时间、错误文案、日志粒度这些没写清的部分仍然落在 H(YX) 里。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 Coding 的失败不是模型输出发散而是它太自信地遵循了另一个世界的规则。它写的是公开社区里合理的代码不是你当前业务里能跑的代码。这就是复杂历史业务难做的根本原因之一真实约束藏在私有代码和团队经验里而模型先验来自公开语料。P 和 Q 的差距越大越不能指望模型靠猜补齐。3.1.3 两类常见失败这里的重点不是让模型永远更自信而是让它的自信建立在正确约束上。这两类失败的底层机制会在后面的框架总览里做进一步归纳。3.2 修正二上下文并非越多越好——信息密度的边界增加上下文通常是对的但不是越多越好。在理想的信息论模型里加入新上下文 Z 后条件熵不会增加如果 Z 和任务相关它理论上能减少不确定性。问题是LLM 不是理想的条件熵最小化器。它有上下文窗口有注意力分配有检索误差也会被冲突信息带偏。上下文太多会带来两个问题有用信号被冗余内容淹没模型看到了但没用上。无关或矛盾信息引入歧义输出分布反而变乱。评估一个 AI Coding 优化方案可以问两个问题它能不能增加上下文和目标输出之间的互信息它的信息密度够不够高两个问题都成立才是好优化。RAG 的价值有一个前提召回必须足够准。它不是天然提高质量的机制只有召回片段和当前任务强相关时才是在提高单位 token 的有效信息。召回错了反而会把模型带偏。3.2.1 有些上下文会降低有效信息反过来看不是所有输入都会帮 AI。有些做法不是收益低而是明确有害。它们要么降低信息密度要么把错误先验注入模型要么让模型在冲突约束里来回摇摆。最危险的是错误上下文。低密度上下文只是偷走注意力错误上下文会污染方向。比如旧文档说用户状态可以直接改真实代码却已经迁到状态机流程模型看到旧文档后会更自信地走错路。冲突约束也很常见。Prompt 里一边写尽量少改动一边要求彻底重构Rules 里说不要新增依赖任务描述又暗示用新库最快。模型不会真正理解团队优先级它只能在这些约束之间做概率折中最后产出一段每个局部都说得过去、整体却不符合预期的代码。还有一种更隐蔽的问题是让 Agent 扩大任务边界。本来只是修一个字段展示它顺手重构状态管理本来只是补测试它改生产逻辑让测试通过。任务边界一放大H(Y) 就被放大模型自由发挥的空间也跟着变大。所以 AI Coding 里的负面原则可以说得很直接不要给低密度上下文不要给错误上下文不要给冲突约束不要让模型猜业务决策不要跳过验证继续往下跑。这些行为会引导模型在推理时遵循错误的先验使输出更接近假设的 Q 而非真实的 Q。04 框架总览框架由两个核心公式构成分别对应两个独立的失败维度第一个公式描述上下文如何分配任务的不确定性其中 Y 为目标代码X 为输入给模型的上下文H 衡量不确定性的大小I 衡量两个变量之间共享的信息量。H(Y)目标代码的可能性空间由任务本身决定可通过任务拆解缩小I(X;Y)上下文帮模型排除了多少不确定性互信息H(Y \mid X)看完上下文后模型还得靠自己猜的部分条件熵。第二个公式描述模型填补剩余不确定性时的准确度P 是模型在公开语料上训练出的先验分布Q 是当前业务的真实约束分布。两者差距越大模型越会自信地用错误的规则填补空白。两个公式对应两个独立失败维度第一层覆盖层 — 显性上下文消除了多少熵→ 核心指标I(X;Y) / Context}信息密度→ 行动Rules、Skills、MCP、示例、约定显性化、RAG→ 失败表现输出含糊、摇摆、前后不一致H(YX) 太大第二层填补层 — 剩余的熵被正确填补了吗→ 核心指标H(Q,P)→ 行动检索业务代码、显性化私有约定、测试和 review 校准→ 失败表现输出稳定但业务上是错的模型自信地用公开先验填了私有空白两层独立作用第一层决定 H(YX) 的大小第二层决定模型填补 H(YX) 时的方向。上下文再充分私有业务约定里总有模型看不到的部分只要 H(Q,P) 大那些剩余空白就会被错误方向填满。这也是前面两类常见失败的底层解释含糊摇摆是第一层出了问题一本正经地写错是第二层出了问题两者需要不同的处理方式。实际操作上两层都可以通过补上下文来改善但补的内容性质不同第一层补的是任务级信息这次用什么接口、参考哪段代码每次任务都不一样第二层补的是项目级规则我们的状态机约定、错误码规范、兼容层逻辑一次写清楚就能在所有任务里复用。遇到一本正经地写错时继续堆任务上下文往往无效真正需要的是把业务约定显性化、沉淀进 Rules 或项目 Memory。评估任何优化手段先问它针对的是哪一层提高 I(X;Y) 的信息密度还是缩小 H(Q,P) 差距05 用这个框架看几个 AI Coding 问题Q1. 为什么 Prompt 写得很细AI 还是和预期相悖人类意图是高维的。你说“这里做得优雅一点”里面可能包含几十个隐含判断不要影响现有接口、不要引入新依赖、不要改太多文件、保持团队风格、性能别退化、错误提示别太生硬。但 Prompt 是低维表达。你能写进去的只是意图的一部分。这就导致一个很常见的错位你以为自己已经说清楚了模型实际只收到了其中一小块。剩下的空白会由它的通用经验补上。从这个角度看很多 Prompt 技巧并不神秘。它们有效是因为把隐性意图变成了可见上下文给反例是在告诉模型哪些路径不能走。给 Few-shot是在告诉模型当前任务的局部分布长什么样。给验收标准是在告诉模型什么输出算对。给现有代码片段是在告诉模型当前仓库的真实风格和接口。Prompt 的目标不是把话写得漂亮而是尽量减少模型需要猜的部分——即最大化 I(X;Y)把 H(YX) 压到尽可能小。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 和产研角色的变化。一个关于工程系统怎么设计一个关于人的分工如何重塑但底层都是同一件事——让真实约束更多地暴露出来让模型少猜一点。06 框架的延伸工程实践与角色重塑6.1 Harness Engineering把真实约束变成反馈回路前面讲的 Context Engineering、RAG、记忆、SDD都还偏输入侧。Harness Engineering 更进一步它关心的是整个外循环怎么组织。可以把 Harness 理解成让模型作为 Agent 行动起来的外循环系统Harness 计划分解 状态管理 工具编排 验证门控 反馈回路 回退机制 人机交接点模型的内循环是给定上下文预测下一个 token。Harness 的外循环决定什么时候让模型动手、给它什么上下文、让它用哪些工具、怎么检查结果、失败后怎么把反馈塞回下一轮。用信息论看Harness 不是简单给模型更多上下文而是在每一轮生成后把真实世界的约束不断显性化。这也是 Harness Engineering 比单纯 Prompt Engineering 更接近工程系统的原因。Prompt 主要发生在一次模型调用前Harness 关心的是多轮行动里的信息流、验证流和状态流。它的边界也很清楚业务直觉、架构审美、跨系统潜在耦合很多时候没法完全写成自动测试。Harness 能把一部分隐性 Q 转成可执行约束但不能替人恢复那些从来没有被表达出来的意图。6.2 产品、设计、研发的角色变化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. 专业深度的边界在哪里。07 结尾回到开头的问题AI Coding 里的新概念不必一个个追着焦虑。可以先问两个问题它针对的是哪一层是提高覆盖层的信息密度增大 I(X;Y)/|Context|还是校准填补层的方向缩小模型先验 P 与业务真实分布 Q 的差距如果是覆盖层有没有引入无关信息稀释信号如果是填补层业务约定有没有被真正显性化还是仍然留在团队头脑里Context Engineering、RAG、记忆、SDD、Harness Engineering都可以放到这个坐标系里看。上下文不够工程上可以补。模型不了解私有业务可以通过检索、记忆、测试和反馈缩小差距。意图本身没有被表达出来就必须让人介入。边界看清楚之后很多概念就没那么神秘了。它们都在处理同一件事让模型少猜一点让真实约束多暴露一点。这是工程维度上对抗熵增的基本逻辑。