ALP（主动加载策略）：AI上下文图管理的简明模式

在使用Claude Code这类AI助手时，当最初的“蜜月期”过去，一个内在的矛盾便会浮现。我们自然希望AI能全面了解所需的上下文信息——包括用户的个人偏好、代码库惯例、产品知识乃至思维习惯。然而，一股脑地预加载所有内容，亦会带来其固有的问题：不仅令牌成本飙升、响应速度迟缓，更具讽刺意味的是，过多的上下文非但不能提升AI的精确度，反而常常使其判断力大打折扣。核心信号最终淹没在纷繁的噪声之中。

在 ArcBlock，我们团队曾为此种摩擦困扰良久，最终决定抽身出来，着手设计一套解决方案。由此，我们提出了一种名为 ALP（即“主动加载策略”）的模式。它既非产品，也非框架，更非我们意欲销售的任何物品。它仅仅是一种工程模式，旨在规范 AI 助手如何按需加载上下文，而非一次性载入所有上下文。其核心理念十分简单：明确定义何时何地加载何种内容的规则，将其写入 Claude 可读取的文件中，然后让 Claude 在对话过程中遵照执行。仅一个下午的设计投入，便带来了此后持续不断的丰厚回报。

此方案值得探讨之处，并非其设计有多么巧妙——实际上，它刻意避免了过度精巧。真正关键在于，这种模式揭示了一个我们在不同场景下反复印证的原则：制约方能提升效率。通过明确声明各项内容何时加载，我们因此掌控了此前看似混乱无序的部分。更重要的是，随着知识库的不断积累，这份掌控力还将日益增长，带来叠加效应。

我们当时正在解决的问题#

在开展ALP项目之前，我们与Claude Code的协作过程中已累积了一些磨合点。这些问题单个看虽微不足道，但汇集起来却造成了实实在在的阻力。经过数月努力，我们积累了海量的知识文件，其中包括十余种不同产品的产品文档、涵盖从文件系统抽象到身份层等各层面的技术架构笔记、工程洞察与决策记录，以及编码风格与沟通模式的个人偏好。显而易见地，让Claude能够利用所有这些信息是首选方案，然而，如何真正“使其可用”却立刻引发了系列疑问。

最初简单粗暴的解决方案是在每个会话开始时将所有信息加载到上下文。这对于小型知识库尚可应付，但扩展性极差。Token 消耗量不断攀升，响应速度也明显下降，更出乎意料的是，我们发现了一个反直觉的现象：Claude 的输出变得不够聚焦。当向一个 AI 助手提供十二种产品的上下文，而它仅需协助处理其中一项任务时，AI有时会过度“热心”，在不相关的产品间建立联系，或者为了涵盖用户不关心的所有可能性而使其回答变得含糊不清。结果是，更多的上下文反而带来了更多噪音，而非更多有效信号。

然而，更深层的问题不仅仅是效率低下，还在于缺乏任何结构化的记忆系统。每一次会话都像是遇到了一个失忆症患者：我们不得不反复解释需要读取哪些文件，重新确定当前任务，并再次提供本应持续存在的上下文信息。个人专属知识与团队共享知识之间没有清晰的界限，也缺乏让AI学习何种知识在何种情境下是相关的系统。我们真正渴望的是一种类似上下文图谱的系统，它能提供结构化、持久化、可查询的知识，并附带有明确的加载规则。虽然业界已开始探讨这一问题，但我们所需的解决方案必须能与现有工具配合使用，而非依赖未来的平台。

这种摩擦成本不仅耗费时间，也带来了认知负担。每次会话都需要一段心理预热期，以便让Claude重新适应我们当前的工作情境。这段预热过程，无疑分散了我们本应投入实际工作的注意力。此外，由于整个过程缺乏系统性，其结果也往往前后不一。有时我们会忘记为Claude指定重要文件，有时则会加载过多内容，反而混淆了其上下文。我们深知，亟需一种更有效率的解决方案。

规则表：有何必要？#

当我们着手设计解决方案时，我们探讨了若干种各有利弊的方案。其中一种方案是让 Claude 根据对话内容自动推断应加载哪些上下文。这显然极具吸引力——无需手动配置，仅凭其智能行为即可运行。但它也伴随着显而易见的风险。Claude 可能会错误判断哪些内容是相关的，一旦发生此类情况，用户将无从得知其缘由。届时，系统将缺乏审计追踪，无法调整其行为模式，也难以保证透明度。AI 对自身的上下文进行决策，这无异于拱手让出了我们正力图确立的掌控权。

另一种选择是构建一个更复杂的系统——例如，一个基于嵌入的检索系统，我们可以将所有文档向量化，并让 Claude 进行语义查询。这种方法自有其优点，且很可能代表着行业未来的发展方向。然而，就我们当前的迫切需求而言，此举似乎有些过犹不及。它将引入对嵌入模型和向量数据库的依赖，增加基础设施的复杂性，并要求持续的维护。我们希望的系统是能够在短短一下午内完成部署，并能通过文本编辑器轻松修改的。我们需要的是一个能无缝融入现有 Claude Code 范式的方案，而非需要我们为此单独开发新的工具。

规则表方法之所以脱颖而出，是由于其具备简洁和透明这两大特性。具体而言，它是一个位于 claude.md 文件中的 Markdown 表格，用以将触发条件映射至文件路径。当 Claude 检测到与“AFS”或“文件系统架构”相关的对话时，它会查询该表格，找到匹配规则，并加载 technical/afs.md 文件。当我们撰写博客文章时，它会加载我们的写作风格偏好；而当我们进行架构评审时，它则会导入我们的工程见解。这些规则是显式的——你只需阅读便能准确理解其将如何运作。它们具备可编辑性——只需修改 Markdown 文件中的一行，其行为逻辑便会随之更新。它们具有人类可读性——新团队成员可以快速查阅表格，并立即掌握上下文加载的工作原理。整个过程无“魔法”可言，不存在黑箱操作，更没有由机器学习模型做出不透明决策的情况。

我们最终确定的格式刻意保持极简。一个包含两列的表格：触发条件和文件路径。触发条件是自然语言描述——Claude 会对其进行解释，这赋予了我们灵活性，无需复杂的模式匹配。文件路径是相对于已知根目录的。就是这样。以下是一个代表性示例：

简洁性是特性，而非缺陷。我们本可以设计出更具表现力的系统——例如触发器的布尔组合、优先级权重、时间条件。但表现力的每一次提升都会增加认知负担。当前的简洁版本足以应对我们90%的场景，而对于剩余的10%，我们总是可以明确地指示Claude加载所需内容。对规则语言进行过早优化，恰恰是我们力求避免的那种过度工程。

README 文件的作用#

规则表能够指导 Claude 何时加载文件，但它无法帮助 Claude 在真正着手加载详细文档之前，判断某个主题是否具有实际关联性。如果每个文件内容都十分充实，你自然不希望 Claude 仅凭猜测就加载其中三四个。相反，你期望有一种更轻量级的方式，让 Claude 能够针对你的知识库进行模式匹配，并就实际所需做出明智的判断。

正因如此，README 文件才显得至关重要。我们知识库中的每个目录都设有一个 README，它充当着一个高度浓缩的索引。以产品目录为例，每个产品的 README 都包含一句简介——这既能提供足够的信息让 Claude 判断主题关联性，又不会让其在阅读 README 本身时耗费过高成本。而在技术文档方面，README 则会用一两句话概述每个架构组件。这些并非为人所撰写的文档（尽管对人而言也颇有助益），而是专为 Claude 设计的索引。

这便构成了我们所称的“两层加载策略”。第一层级：Claude 通过阅读 README 文件，摸清整体状况；此举成本低廉——仅需数百个 token，便可迅速掌握目录内包含的知识概览。第二层级：Claude 会基于 README 文件内容和当前的会话语境，判断并仅加载实际所需的特定文件。这种策略就好比您在阅读书籍时，会先查阅目录再深入特定章节；亦或是操作系统在进行路径解析时，通过目录元数据来避免读取整个文件内容。

README这种方法还能有效化解一个微妙问题：误匹配。若缺乏这一概要层，当Claude识别到“讨论身份”之类的触发词时，它可能会误以为需要加载我们的DID文档。然而，实际对话可能是在探讨非技术范畴内的品牌身份或用户身份。此时，README便能为Claude提供充足的上下文，助其准确辨别语境。例如，当其中呈现“DID + 能力：使用可验证凭证的去中心化身份验证”等内容时，Claude便能据此判断对话的真实意图。这种轻量级的语义匹配之所以能自然而然地发生，正是因为Claude作为一种语言模型，我们只需为其提供必要的背景信息，便能确保其做出精准匹配。

为此编写高质量的 README 是一项值得培养的技能。目标是在最少的 token 中实现最大的信息密度。每个词都应有助于 Claude 进行模式匹配。避免使用“此目录包含”之类的样板短语——Claude 自然知道这是一个目录索引。开篇应着重指出将在相关对话中出现的独特术语。设想只用一句描述每个项目，然后精简该句子，去除所有冗余信息。在撰写这些摘要上投入的时间，都会在 Claude 每次做出更明智的加载决策时，获得丰厚回报。

优先级覆盖与团队动态#

在最初单独使用ALP时，其设计理念极为简洁：个人知识文件存储在专属目录下，而规则则置于各自的 claude.md文件中。然而，随着团队协作的深入，新的需求应运而生。我们期望能够构建人人可访问的共享知识体系——例如产品文档、技术架构和公司战略等。与此同时，我们也希望个体用户可以对这些共享知识进行定制或扩展，且无需分叉整个系统。此外，我们也希望各项目能够拥有独立的上下文，这些上下文既可以区别于个人默认设置，也能有别于团队的通用配置。

本解决方案采用的是优先级链机制，这与设计精良的系统中的配置方式如出一辙。其包含三个层级，按以下顺序检查：首先是项目级覆盖，其次是用户级覆盖，最后是插件默认值。具体而言：

1. ./.claude/arcblock-context/ - 当前目录中的项目专用覆盖配置
2. ~/.claude/arcblock-context/ - 用户主目录下的自定义覆盖配置
3. Plugin default - 团队共享知识库，以 Claude Code 插件形式提供

当 Claude 需要加载 products/arcsphere.md 时，它会首先检查是否存在项目层级的覆盖文件。如果没有，则会检查是否存在用户层级的覆盖文件。如果两者都不存在，它将回退到插件的默认设置。这意味着团队得以维护一份权威文档——即代表官方产品定位和技术决策的版本——同时，个人可以根据自身需求扩展或覆盖特定文件。例如，深入研究某个产品的开发人员，可能会拥有一份该产品更丰富的个人版本文档；而探索新方法的团队成员，则可以用实验性笔记覆盖某份技术文档。所有这些改动都不会影响到其他任何人。

这种覆盖机制还建立了一种自然的贡献流。当某个个人覆盖被证明有价值时，开发者可以通过拉取请求将其贡献回共享插件。这种覆盖机制始于个人实验，通过实际应用得到验证，进而升格为共享知识。当变更需要共享时，它们将通过审查流程向上整合；而无需共享的个人笔记则保持私有。这比让每个人直接编辑共享代码库要清晰得多，避免了协调开销和潜在的冲突变更风险。

对于考虑采用这种模式的团队而言，核心洞见在于优先级链应与组织的信任模型相契合。项目级覆盖具有最高优先级，原因在于项目特定的上下文信息最为即时且直接——例如，当您处理特定代码库时，其自身约定应凌驾于通用默认设置之上。其次是用户级覆盖，因为个人工作流程的重要性不容忽视——若用户为自身使用发现更佳的产品描述方式，则不应受到阻碍。而插件默认值则以共享真理，即代表团队共识的文档，为整个系统奠定坚实基础。一旦我们清晰阐明这一排序逻辑，其合理性便不言而喻；然而，考虑到不同团队可能拥有差异化的信任模型，明确阐释其背后的缘由仍十分必要。

采用 ALP 后，改变了什么#

这项改变带来的直接且可衡量的益处正如预期：响应速度更快，因为Claude无需处理不相关的上下文；token用量更低，因为文件按需加载而非预先加载；输出内容更聚焦，因为当专注于某项任务时，Claude的注意力不再分散到众多产品上。这些效率提升固然真实存在，但它们也是本次改变中最不值得一提的部分。你能节省token，响应体验更为迅捷，成本也略有下降。不过如此。

更为显著的转变发生在行为与文化层面。在ALP问世前，我们将人工智能的上下文视为一个信息桶——把所有已知内容倾倒其中，寄望于AI能自行甄别出相关信息。ALP之后，我们开始将上下文视作一个精心设计的系统。我们拥有哪些知识？每项知识何时是适用的？各项知识之间又该如何相互关联？知识库由此成为我们主动策划而非被动累积的对象。鉴于克劳德（Claude）将使用这些文档，我们开始以截然不同的方式编写它们。我们开始考量信息密度，深知README文件将充当索引的角色。设计ALP规则的过程，促使我们清楚地阐明所掌握的知识及其重要性所在。

对于团队而言，ALP 填补了大多数由AI增强的工作流程中长期缺失的一环：一种共享知识的自然结构。每当有新成员加入团队，他们只需安装一个插件，即可立即获得对团队产品文档、技术架构和战略背景的访问权限——这些知识是按需加载的，而非事先一次性灌输。新成员无需再询问“X 的文档在哪里”，因为 Claude 已然知晓这些文档位于何处以及何时需要加载。规则表本身便可视为一种元文档，一份清晰标示了现有知识构成及其相关应用场景的地图。因此，新员工的入职过程得以显著加速，因为该知识系统是显性且易于发现的，而非隐秘且支离破碎的。

这一模式也改变了我们对人工智能能力与人类系统之间关系的认知。ALP 本身并不精妙——其本质仅是一个 Markdown 表格和一些命名约定。然而，它却蕴含了一个极富价值的原则：约束赋能效率。通过接受显式加载规则的约束，我们获得了精确上下文所带来的高效性。通过接受 README 索引的约束，我们则实现了两层加载的高效率。这一原则同样体现在优秀的软件架构、Unix 哲学以及高效的组织设计之中。约束并非全然是限制——它们更是构建自由的基石。我们发现，当我们审慎考量并合理设定人工智能工具的约束时，其效能反而得以增强，而非削弱。ALP 便是这一宏大模式的一个缩影，却是一个具体而可感的明证。