前言：AI编程工具越来越强，但每次任务结束，工程判断就无法跨任务流动，代码留下了理由却蒸发了。本文深度拆解Forge团队如何用带结构的知识对象、读取准入与沉淀准入两道门，破解知识蒸发难题，让项目记住自己为什么变成今天这样，实测探索路径缩短一半以上。
前两天我用Claude Code改一个老项目的bug，改到一半，它突然问我，这个函数为什么不复用隔壁模块那个现成的实现。
我愣了一下。
因为那个现成的实现，三个月前我们试过，跟上游系统的数据格式对不上，改了三天最后放弃了，换成了现在这套手写的。但这事儿代码里一个字都没写，当时讨论的对话早就没了，只有我还记得。
我跟Claude Code解释了一遍，它说好的明白了，然后继续改。
关掉对话，第二天再打开，它又问了同样的问题。
我当时就有点无语。不是怪它，它确实没做错什么，代码都在，它读得懂，但它不知道为什么代码长这样。它每次都像一个新来的实习生，能力很强，但啥背景都不知道。
这个事儿其实困扰了我挺久的。AI编程这件事，模型越来越强，Claude Code、Cursor、Codex这些工具也越来越好用，但有一个问题一直没解决，就是每次任务结束，这次任务里形成的判断，下次就用不上了。
后来我看到一个挺有意思的复盘，是Forge团队写的，他们专门做AI Coding的工程化框架。他们把这个问题拆得特别细，我觉得值得聊聊。
Forge团队给这个问题起了个名字，叫工程判断的跨任务流动。听着挺学术，你想想看其实就是，你做一次任务的时候，脑子里形成了一堆判断，这个接口为什么这样设计，那个方案为什么被排除了，这条限制到底防过什么问题。这些判断在需求讨论、代码评审、跟AI的来回探索里慢慢形成。但功能一上线，这些判断就停在当时的上下文里了。
代码留下了，理由蒸发了。
他们引用了一个软件架构领域的研究，管这个叫knowledge vaporization，知识蒸发。代码能告诉你系统现在怎么工作，但很少能告诉你它为什么变成这样，什么变化会让现在的设计不再成立。
我有时候觉得这个比喻特别准。就像你去看一栋老房子，砖瓦都在，但你不知道为什么这面墙这么厚，可能是以前防过什么，可能是结构需要，但没人记了。你只有拆的时候才发现，哦，原来这面墙还承重。
Forge团队说，工程判断从形成到再次使用，要跨过三个断点。
第一个断点，代码留下了结果，理由慢慢消失。Agent可以重新读代码，但它很难从最终实现里还原，曾经比较过哪些方案，排除了哪些路径，选择成立的条件是什么。代码回答「现在是什么」，不总能回答「为什么如此」。
测试也一样。测试能证明某个行为在给定条件下成立，但通常不会解释团队为什么选择这条依赖方向，或者哪个替代方案曾因维护成本被放弃。理由如果只存在于Review和对话里，时间久了就只能靠参与者回忆。
第二个断点，任务交付了，经验没有进入下一次任务。一次任务可能已经确认了接口边界、故障根因或验证路径，但这些判断常常只存在于对话和参与者记忆里。任务结束，代码提交了，经验却没有成为下一个开发者和下一个Agent可以共同访问的资产。
这个跟新同学接手老项目一模一样。代码都在，文档也不少，但他还是会不断问，为什么这里没有按常见写法做。熟悉项目的人知道答案，也许是为了兼容历史技术债务，也许是上游系统只能这样配合，也许是更漂亮的重构能省几行代码但会同时触碰五条已经稳定的链路。新人可以通过踩坑慢慢补齐，但Agent的困难在于，每个新任务都可能重新从「新人第一天」开始。
= =
每次都从第一天开始。你想想这个有多离谱。
第三个断点，知识保存了，却没有真正进入决策。就算团队把任务总结写进Wiki，后续任务也未必知道它存在，是否仍然正确，适用于哪里。个人用AI的时候，使用者还能靠自己的记忆补足，多人协作里，知识的生产者、使用者和审阅者往往不是同一个人。「某个Agent曾经知道」不等于「团队下一次仍然能够使用」。
他们还引用了一篇叫Lost in the Middle的论文，说相关信息在长输入中的位置会显著影响模型的利用效果。就算一条知识被系统选中了，Agent也可能没打开正文，或者读到了但没有改变任何判断。
三个断点连起来，问题才清楚。不是保存越多越好，系统要识别有价值的经验，放到正确的任务里使用，再用当前代码和验证结果继续校正。
说到这个，比较骚的事是Forge团队自己也是踩了一堆坑才想明白这件事的。他们的方案不是一开始就设计好的，是真实任务一步步逼出来的。
最开始他们的想法特别简单，会话结束后别什么都丢。于是搞了个Daily日志，每天追加，不限格式，不需要预先分类。
这一步解决了「留下来」，但很快暴露了三个问题。
事实和猜测混在一起。同一份记录里可能同时出现确认的代码事实、临时推断和待验证线索，后来的任务没法区分哪些结论已经站住了。
没有稳定身份。一个判断如果分三次补充，只能追加三段文字，没法落回同一条知识进行修正。
只能增长不能收敛。记录越来越多，后续任务在里面找有用信息的成本也越来越高。
长期记忆研究对这个困境有直接的解释，难点从来不只是保存和召回，还包括更新、拒绝和遗忘。旧结论可能被新证据推翻，也可能只是在新范围内不再适用，缺少长期价值的内容如果持续累积，会让筛选成本不断升高。Daily日志恰好把这三件事全回避了，它没有机制区分「该留」和「该忘」。
我自己的感受是，这个坑太真实了。我自己用Claude Code的时候也有类似的习惯，让它在对话里记一些东西，但回头翻的时候发现，有用的和没用的全混在一起，根本分不清哪些还能信。说实话我也不确定那些记录到底帮没帮上忙，可能大部分时候就是自我安慰。
于是Forge团队做了第一个架构转折。不再问「怎么多保存一些」，而是问「一条信息要带哪些属性，后续任务才敢用它」。
答案是，稳定身份让后续任务能够修正同一条知识，适用范围限制结论被带到哪里，证据记录判断的来路，状态区分草稿、活跃和已归档，修正历史保留每一次变更。
知识从「日志里的一段话」变成了带结构的独立对象。
但对象越来越多以后，两个对称问题同时出现了。读取侧，存得越来越多不等于当前任务都该读，全量塞入上下文只会把噪声和成本一起带进来。写入侧，一次任务有新经验不等于都应该写进去，低价值经验会增加后续筛选成本。
于是出现了两道准入门。读取准入先选择可能相关的知识，再由Agent结合当前代码判断适用性。沉淀准入则在开发与验证结束后，判断新经验应该被拒绝、合并、新建，还是交由人工复核。
关键决策是，系统需要两道门而不是一道。只有读取准入，知识库会膨胀到难以维护。只有写入准入，好知识也可能淹没在无关推荐里。
后来他们又发现一个问题。最初他们把规则写进Prompt和Skill，让Agent自己遵守，该读什么、怎么写、结构应该长什么样。但真实任务很快暴露了问题。对象ID分配、文件路径选择、字段校验、状态迁移，这些有明确规则的机械动作，如果每次都靠模型自由输出，错误既频繁又难排查。而「这条经验是否值得保留」「两段知识是否在说同一件事」这种判断需要项目上下文，写不成确定性规则。还有些强约束和证据未闭合的冲突，让AI单方面决定风险太高，需要人来确认。
于是职责被拆成三层。AI做语义判断，确定性执行层做机械动作，人处理高风险团队事实。
这个分工我觉得特别对。混在一起的时候每一层的错误都很难定位，拆开以后失败点才容易追溯。这跟做工程是一样的，你把不同职责混在一起，出了问题你不知道是哪个环节的锅。
他们把知识对象分成了几种角色。导航知识回答「从哪里开始读」，模型知识回答「这些代码共同表达什么」，操作手册回答「这类任务通常怎样完成」，诊断知识回答「出现异常后应该怎样找到原因」，决策理由回答「当时为什么这样选」，约束规则回答「当前哪些选择可以继续进入讨论」。
每种角色解决不同的问题，但它们合在一起，覆盖了一个Agent在项目里需要的各种上下文。
但知识保存下来，不代表它会在下一次任务里自动发挥作用。他们把这层机制叫知识运行时，两扇门，读取准入和沉淀准入。
读取准入的第一道判断不是相关性，而是消费资格。未完成的骨架不进入正常推荐，明确停用的知识退出正常消费，结构不完整的对象不能作为有效知识。这些资格判断是纯确定性的一段代码，AI不参与。
通过资格门以后，系统再依据当前任务已经暴露出的文件、模块、概念等事实信号缩小范围，达到相关性门槛的对象进入有限的推荐候选。一条知识如果没有获得正向相关性证据，不会仅仅因为角色重要就被塞进推荐集合。
读到知识以后，仍然要回到当前代码验证。知识对象的写入时间总是早于当前任务，代码可能已经动过，模块关系可能已经变化。长期知识保存的是过去某次任务里被证据支撑过的判断，代码才是当前项目的实际状态，二者不一致时以代码为准。
这个设计我特别欣赏。读了不等于用了，Agent打开了正文不代表它必须采纳。Agent明确表示「这条判断在本次任务中已经不成立」，其实也可以认为是一次有价值的消费。
任务结束后，沉淀准入默认不写入。判断一条候选是否有资格改变长期知识，按顺序问五个问题，这是不是未来还会再次遇到的判断，有没有当前代码或任务结果作为证据，离开这次任务以后它还能独立成立吗，是否已经完整到足以让下一次任务理解，长期知识里是不是已经存在同一个判断。
能不增加就不增加，能修正已有对象就不再创建一个新版本。大多数任务的绝大部分候选会停在不沉淀，修复拼写、执行已有操作手册、验证代码中显而易见的事实，都不应该因为任务完成就制造长期知识。
这个原则太重要了。说真的，我见过太多知识库系统死在「什么都往里塞」上。Forge团队这个「默认不写入」的设计，反而是最清醒的。
那实际效果怎么样呢。他们跑了一堆真实任务来看。
约70%的任务中，可以从执行轨迹里看到项目知识被实际读取，并继续影响了后面的探索、方案或实现判断。在探索排查类任务中，也能观察到历史经验帮助Agent更早收窄排查范围。
近30%的任务最终明确判断无需产生新的长期知识，40%以上的任务在完成验证后形成了已有知识的更新或新的知识对象。
知识进入任务并没有让Agent更依赖历史结论，相反，历史知识更像是在探索开始前提供了一层项目经验，最终判断仍然需要回到最新的代码里重新确认。
按照真实任务轨迹进行反向复盘，如果没有这些已经沉淀下来的项目经验，Agent还需要额外完成代码入口定位、重新梳理调用关系、历史方案确认或排查范围收敛。这部分探索路径通常可以缩短一半以上。
一半以上。
你敢信？？？
我第一次看到这个数字的时候确实有点震惊。不是因为数字本身有多大，而是因为这意味着，过去那些已经在这个项目里探索、比较和验证过的事情，本来不应该因为换了一次任务就全部重新发现。
这让我想到一个更大的事儿。
迈克尔·波兰尼在1966年写过一本书叫《个人知识》，里面有个概念叫「隐性知识」，tacit knowledge。他说人类的知识里，能说出来的只是冰山一角，大量知识是「我们知道但说不出来的」。骑车的人知道怎么保持平衡，但说不清楚原理。老师傅知道这块料该怎么下手，但写不成操作手册。
工业革命之前，知识传承靠的是学徒制。徒弟跟着师傅干几年，不是听课，是在一起干活的过程中，把那些说不出来的判断一点点「泡」进去。这种传承方式慢，但它是完整的，因为徒弟不光学了「怎么做」，还学了「为什么这么做」。
后来有了文档、有了操作手册、有了SOP，知识传递变快了，但也变薄了。你拿到了步骤，但丢了判断。
回到Forge Memory这事儿上，你想想看，它其实是在AI时代重新解决这个老问题。不是把所有对话都存下来，那只是存了步骤。而是把那些「为什么这么做」的判断，变成有身份、有边界、有证据、可以被修正的独立对象，让下一个Agent在需要的时候能找到它，用了之后还能根据当前代码验证它还成不成立。
不是让AI记住更多，是让项目记住自己为什么变成今天这样。
我觉得这才是真正有意思的地方。模型会继续变强，Agent也会越来越擅长读代码、调工具、完成任务。但只要每次任务仍然从当前代码和通用能力重新开始，团队过去已经付出过的工程判断成本就仍然会不断丢失。。。
真正能够持续积累的系统，应该让Agent不只是「会做这一次」，而是让项目在一次次任务之后，越来越知道自己为什么会变成今天这样，也越来越知道下一次应该从哪里继续。
回到开头那个场景。我用Claude Code改那个老项目，它问我为什么不复用隔壁模块的实现。我跟它解释了一遍，它说好的。第二天它又问了一遍。
如果有一天，它不用再问了，因为它已经知道了，而且知道的不是我随口说的，而是有证据、有边界、可以被验证的判断。
那一天，AI编程才真正从「每次从第一天开始」变成「从上次结束的地方继续」。
磨平一些信息差。
/ 注意，本项目仅在 SyncMein 的500人小群分享。
/ 谢谢你看完了我的文章，我们下次再见吧。
/ 作者：明察
/ 投稿或爆料，请联系邮箱：mingcha@gqmg.com
暂无评论内容