那天我先问了一个看起来很实际的问题：之前做过的分析，到底有没有真正沉淀下来？如果下一次再遇到同一个应用、同一类函数，能不能直接知道它在哪里、和谁有关、怎样继续使用，而不是重新翻一遍报告？
这个问题之所以停不下来，是因为手头并不是没有成果。每个应用都有自己的索引、锚点表和试错记录，很多结论也写进了报告。可是当问题跨过应用边界，或者换一个问法，查找就重新变成了人工翻目录。材料很多，知识却没有形成一个能被问到的整体。
报告保存下来，不等于知识沉淀
我一开始也容易把“保留报告”当成沉淀。只要原始转储、分析回执和中间文件都还在，似乎以后总能再找回来。但这其实把最费时间的部分留给了未来：重新确认文件属于哪个版本，重新定位符号，重新判断一条调用关系是静态推断还是运行时观察，最后还要重新想起当时为什么相信它。
报告适合解释过程，事实库适合回答问题。两者都重要，但用途不同。报告告诉我当时怎么走到结论；事实库则应该在有人问“这个对象在哪里”“它调用了谁”“已有脚本能不能复用”时，快速给出位置、关系和下一步入口。
真正需要沉淀的不是一堆文件，而是下一次可以直接查询并继续行动的事实。
如果不处理这个差别，后果很具体：中间产物一旦清理，历史分析就只剩一批需要重新阅读的材料；即使材料暂时没清理，每个新问题也会重复消耗定位、比对和解释的时间。知识没有消失，只是没有被组织成能力。
先把分析结果拆成事实
这次我没有直接把所有报告合并成一篇更长的说明，而是先问：一个后续问题最少需要哪些事实才能得到回答？最后拆出的基本单位包括符号、函数、类、字符串交叉引用、调用边、版本和证据来源。
这些事实要按应用和版本组织。应用说明对象属于哪一套系统，版本说明它在哪个时间点成立，证据来源说明它来自静态分析、运行时观察还是已有文档。少了版本，地址和名字很容易被误认为长期稳定；少了证据来源，推断关系就可能被当成已经验证的事实。
关系也不能只记在段落里。我们把模块和偏移作为关系图中的节点，把静态调用边与运行时调用边合并起来。这样做不是为了把图做得复杂，而是为了让“谁调用谁”“从这里怎样走到那里”变成可以检索的关系，而不是藏在某份报告的某一段描述里。
这里最容易误判的是：有名字就算有知识，有地址就算能复用。其实名字只解决了识别，地址只解决了定位。要让结果真正可用，还需要知道它的关联对象、证据强度和复用方式。
事实、含义和入口要分层
只导入结构事实还不够。比如，某个符号位于某个模块的某个偏移，这是一条事实；它可能是文字发送行为的锚点，这是含义；已有脚本可以通过它完成一次操作，这是复用入口。三者混在一起，查询结果会显得热闹，却不容易判断能不能直接拿来用。
所以沉淀层分成了3个层次。第一层是事实导入，把报告和分析产物里的对象与关系转成统一记录。第二层是含义标注，说明这个对象在工作流程中代表什么，以及判断是直接观察还是谨慎推断。第三层是复用入口，记录可以继续执行的脚本、查询方式或验证动作。
沉淀的终点不是“我曾经见过它”，而是“下一次有人问时，我能说明它是什么、证据在哪里、怎样安全地继续”。
我选择分层，是因为这样能保留不确定性。一个静态关系可以进入事实库，但不能因此自动升级成已验证行为；一个版本相关的锚点可以作为候选，也不能被写成跨版本永远稳定。事实、解释和动作各自有边界，后续使用时才不会把猜测当承诺。
用真实问题验收查询能力
沉淀层是否完成，不能只看导入脚本有没有跑通。那只是说明数据进入了某个目录。真正的验收方式，是拿之前实际遇到的问题来问它。
我用符号、导出函数、类和调用关系做了几次查询。返回结果不只包含对象名称，还要能给出它所在的版本和位置、关联对象、证据出处，以及可以直接复用的入口。查询某个发送相关的标识时，应能回到对应的编号和来源；查询时间线导出相关的对象时，应能同时看到不同平台的锚点和可执行的定位入口；查询一个编辑模型时，应能继续展开它与草稿服务、导出方法之间的关系。
查询速度当然有价值，但速度不是唯一标准。更重要的是结果能不能缩短下一步判断。如果它只返回一串名字，仍然要回到报告里人工解释，那只是换了一个搜索框；如果它能返回位置、关系和动作，才算从“查材料”进入“用知识”。
一个事实库是否有效，要用真实问题验证它能否把查找直接接到下一步行动。
错误捷径是把原始材料当长期能力
最容易走的错误捷径，就是把一堆报告和原始转储放进长期目录，然后告诉自己“以后都在这里”。这看起来最省事，因为不用决定哪些内容该结构化，也不用面对证据强弱和版本边界。
但它省下的只是今天的整理时间，转移的是未来每一次查询的成本。更麻烦的是，原始材料越多，人工搜索越容易只命中相似词，却漏掉调用关系、版本差异和复用入口。最后得到的不是错误答案，而是一个看起来足够完整、实际不能迅速行动的答案。
我没有选择继续堆文档，是因为这次问题的核心已经不是“有没有更多材料”，而是“已有判断能不能被再次调用”。把结论拆成事实并不意味着删除报告，反而是给报告增加索引、关系和用途，让解释材料与执行入口互相指向。
把沉淀接进清理流程
最后还需要处理一个容易被忽略的边界：什么时候可以清理中间产物？如果沉淀和清理是两件互不相干的事，就可能出现导入漏项，随后原始证据被删掉，问题直到下次查询失败才暴露。
因此清理流程增加了沉淀检查。没有被提炼的证据，不能直接进入清理；只有事实、来源、版本、关系和复用入口都完成必要登记，相关中间产物才具备被清理的条件。这不是为了永久保存所有东西，而是让删除动作有一个可检查的前提。
这件事让我重新意识到，清理不是存储管理的最后一步，而是知识质量的一次反向验收。如果某份证据还不能被查询、解释或复用，就说明沉淀还没有完成。保留它不是拖延，而是在避免把不可逆的删除建立在“应该已经导入”的猜测上。
下次我会怎么做
下次遇到一轮新的分析，我会先把结果分成4类：可以直接查询的事实，需要补充的含义，能够复用的入口，以及仍然未知或只被静态推断的关系。每一类都保留版本和证据来源，不用一段漂亮的总结掩盖边界。
然后我会用至少一个真实问题验收：能否查到位置，能否展开关联，能否找到下一步动作。如果查询只返回名称，我会把它视为索引未完成；如果返回了关系但没有证据，我会把它标成待验证；如果返回了入口但没有版本限制，我会先补上使用条件。
最后，在清理中间产物之前再做一次对账。事实、含义、证据和复用入口至少要能互相追溯。这样，下一次面对同类问题时，我不必从报告的第一页重新开始，而是先查询已有知识，再只验证仍然不确定的部分。
一个流程成熟的标志，不是它能把一次分析做得多完整，而是下一次能不能少依赖临场记忆。把结论变成可查询知识，真正留下来的就不只是过去做过什么，还有未来可以从哪里继续。