0、导言

最近被一个实践AI Coding的朋友问了个问题。概括一下是：在真实业务场景规模的项目中，如何组织大量的Context（各种文档类材料），以及如何优化AI工具对其的利用。

目前对于这个问题，我感觉好像还并没有很好很自动的方式。特别是实际项目开发中大量的需求沟通和材料是增量的。以及组织中很多人写文档经常会丢三落四，很多信息实际上都在会议记录中（原文文字稿，不是总结）。

这种材料的获取不算难，把所有收到的文档、会议记录、规范等都丢到一个目录或基于向量数据库召回的系统中就可以。但召回的效果应该是比较糟糕的，虽然我没有实测过，但我估计召回率应该比较差，无论是使用目前AI Coding工具常使用的grep类检索还是向量检索。

我的回答总结为三点：

• 这个Context中应该包含哪些信息？所有人类开发者工作时候需要的信息都需要放入其中。跟PM沟通时候提的问题和回答都应该放在这个Context中。（我之前写的：你说过的所有的话都应该写到某个文档中）

• Context不能只是简单堆砌，而是要维护一个系统当前状态的文档快照。Context中放的每个材料不应该只是个增量补丁或者旧的信息，而是要融合为一个直接反映当前系统的最新文档体系。

• 需要针对性地给Context目录（也包括代码目录）构建逐层的语义说明文档作为一个语义索引。为了方便AI能够快速根据内容量较少的语义索引来了解下一步应该查询什么关键词或读取哪些其他材料文件。

后两点概括一下是：优化Context中的内容质量（排除过时和错误信息），优化召回过程的成本。

后者我认为目前是最佳实践，不是本文的议题，本文主要讨论前者。

1、维护反映最新情况的文档体系

（本节开始不再针对于上述AI Coding场景，而是对更一般的有大量Context且在持续有新材料加入的场景进行讨论。）

1.1、必要性？

对于有一定信息洁癖的人来说，这是一个自然的Context组织方式。但这种方式是否必要仍然需要大量讨论。

我个人目前也不是很确定这是否就是最佳实践。首先它就违背一个我觉得已经很普适的原则：如果在LLM应用的workflow中，如果中间环节并不是直接的业务需求（例如用户需要或审计），那么应该尽量移除该中间结果的产出，直接融合前后两步，除非增加该中间环节确实能够改善最终效果。

但如果抛开这种经验公式，直接分析这个场景的话，维持一个当前信息的快照确实可以显著降低目前LLM/Agent召回和理解Context片段的难度，并能避免错误采纳了过于陈旧的信息。

1.2、溯源

在后LLM时代，信息是过剩的，认真的信息处理系统都需要具有信息溯源的能力，甚至是默认对所有信息都进行溯源。阻碍它的只有成本。

对于本文描述的范式，这也是一样的，既然要对所有材料进行重新组织，那么也大概率需要对于结果文档中所有的信息确保能够溯源，确保的方式就是提供所有信息的来源。

当然溯源只是确保了历史上确实存在有某个版本/时间，有过这个信息，但不能说明没有更新的信息把它覆盖了，或者说有大量相反的信息可以推翻它。

1.3、可行性

对于目前的前沿模型，做可靠的信息处理和溯源并没有太大的问题。LLM模型在一次回答中可能会有错误或者疏漏，但再让它自我反思检查一次就足以消除大部分的问题，让整体的可靠性达到一个可接受的水平。

在强制进行全覆盖的溯源标记之后，信息错误或凭空出现的问题概率就更加低了。

但这种多轮的内容重新处理的LLM推理成本和时间是很难无视的。

1.4、历史演变

如果只保留最新版本的材料，那么就无法响应一类请求：某两个时刻对应的版本差异是什么？虽然这好像是一个很长尾的需求，但我身边确实存在有这种需求的人。

在这个框架下，解决方案就是保存所有历史完整快照。注意这不是要保存所有增量补丁。

类似于你比较第三版和第五版的新华字典，而不是拿第四版的修订说明和第五版的修订说明。

2、评论

2.1、没人愿意支付成本

实际上，产出当前系统的最新完整说明是一个不错的适合AI的需求。因为手工维护这种当前快照的文档很反人类，但确实人又对此有需求：无论是新人熟悉，或者是忘记细节时候进行查阅。

但如果这件事成本较高的话，很少有人愿意为此支付成本。构建库的成本很少有人愿意支付，在查询时，也是希望AI能够直接根据各种原始材料产出对应于query的当前局部快照说明。

但对于AI系统的构建者来说，似乎没有这么免费的午餐。没人进行实现的整理，很难有准确又高效地响应用户的请求。这无论对人还是对于AI来说都不现实。而这就是本文的主题：AI系统内是否应该维护这样的当前信息最新快照。

2.2、运筹领域的启示

但对于一个认真的信息处理应用来说。发现各种信息材料中的冲突/不一致，或者是在各种约束、条件、信息下进行推理和规划，则对于内部表示有着更高的要求。

如果没有一个内部统一的表示，那么应该如何知道已经出现了冲突或者明显风险呢？一种思路是每次新增信息时都对于已有材料进行冲突判定。但直接的冲突检测还算容易，想要知道已经出现“既要、又要、还要”但已经没有可行方案是无法靠这种方式实现的。

我们如何知道一个约束问题仍然有可行解？这个问题你放在运筹规划领域来看答案是很自然的：找到一个可行解。找到一个可行解说明需要某种程度上求解了这个问题。

对应到本文的场景下，我觉得这大致对应到：产出一个当前最新情况的完整快照，并发现有冲突的信息。对于其中的约束问题和风险，如果需要还要再进行分别的推理分析。

结语

我目前仍然不清楚这是否是最佳实践，或者说对于追求质量的系统来说，这是否算最佳实践。

但我觉得似乎方案的选择是需要在每个场景正经讨论的。