为什么你编写的 Knowledge 条目从未出现
首先从检索模型开始，因为它与指令文件的通常工作方式相反。Cognition 自己的提示直接指出：“Devin 会在相关时检索 Knowledge，而不是一次性或在开始时全部检索。请务必使你的检索触发器与内容高度相关。”
因此，触发器描述不是元数据。它是大门。新手指南重复了这一点，并阐明了良好触发器的形式：“Knowledge 是根据你设置的 Trigger（触发器）进行检索的。触发器越具体（例如 Knowledge 适用于哪个文件、仓库或任务类型），检索效果就越好。”
这与拼接进每个提示词的规则文件设计截然不同，并且它具有不同的失效面。过长的规则文件会被稀释。而触发器模糊的 Knowledge 条目则会被跳过。指令文件在整个类别中被悄无声息地忽略的原因是一个相关的问题，我们在为什么智能体忽略你的指令文件中讨论过。
一个条目可能无法到达会话还有另外三个原因，这些都有文档记录。
它没有被固定到任何地方。 Cognition 将固定（pinning）描述为覆盖手段：“未固定到任何仓库：仅当 Devin 认为 Knowledge 与你当前的上下文相关时，才会检索该 Knowledge。”固定到特定仓库后，行为会完全改变——“只要 Devin 在该特定仓库中工作，就始终使用该 Knowledge。”固定到所有仓库，则“该 Knowledge 会自动应用于 Devin 在任何会话中工作的每个仓库。”新手指南明确了这一决策规则：“如果你希望 Devin 在任何会话中工作时都检索该 Knowledge 笔记，请确保将其固定到所有仓库。”
它被禁用了，可能是被文件夹禁用了。 条目可以针对个人进行关闭：“每个知识条目都可以针对每个用户单独启用或禁用。禁用知识条目会阻止 Devin 在你的会话中检索它，而不会将其从组织中删除。”文件夹会继承该开关——“当一个文件夹被禁用时，其中所有的知识条目在你的会话中都会被禁用。”看到该条目起作用的同事并没有反驳你；他们只是启用了不同的条目集。
它的范围与你想象的不同。 新条目默认处于一个级别：Organization Knowledge（组织知识）条目“对组织的所有成员可见，并且是新知识条目的默认范围。”Enterprise Knowledge（企业知识）条目“适用于你企业中的所有组织”，而将其提升需要权限——“提升需要企业知识管理权限，且仅适用于属于企业的组织中由用户创建的知识条目。”
在编写任何内容之前，还有一件事值得了解：你的一些 Knowledge 是在没有你的情况下生成的。“Devin 将根据已连接仓库的现有 README、文件结构和内容自动生成仓库知识，”并附带访问限制——“如果你不给 Devin 访问仓库的权限，它就不会生成任何相关的 Knowledge。”Cognition 的第一个新手步骤就是检查这些材料：“审查任何自动生成的 Knowledge，并验证其 (a) 完整性和 (b) 准确性。”
而且 Devin 还会不断提出更多建议。“Devin 将根据你在聊天中的反馈自动建议要记住的 Knowledge，”你可以自行编辑和忽略，并且它“除了建议新知识条目外，还可以建议对现有知识条目进行更新。”
人们尝试的其他替代方法
编写一个涵盖所有内容的长 Knowledge 条目。 这可以理解，但它对检索模型起到了两次反作用。Cognition 的指导原则恰恰相反：“创建针对一个工作流或操作的特定 Knowledge。Devin 会阅读整个 Knowledge 内容，因此请保持其全部相关且最新！”以及“尽可能将你的 Knowledge 拆分为更小的条目。”单个综合条目需要一个能够以某种方式描述其中所有内容的触发器描述。
将内容移入 playbook（剧本）。 Playbook 是一个不同的工具，Cognition 对这种划分异常直接：“大多数最佳实践、风格指南或其他特定于项目的指令应该通过使用 Knowledge 与 Devin 共享。我们建议在创建 Playbook 之前阅读关于 Knowledge 的文档，以了解哪种方法更适合你的需求。”用他们的话说，playbook “就像是针对重复任务的自定义系统提示词”——你在开始会话时附加它。他们还指出这并不是一个简单的选择：playbook “目前需要技巧来编写”。
将所有内容放在仓库中的 Markdown 文件中。 合理的直觉，但它遇到了文件扩展名的限制。Devin “将根据代码库中的专用文件自动拉取和更新 Knowledge，包括 .rules、.mdc、.cursorrules、.windsurf、CLAUDE.md 和 AGENTS.md”，随后是限制：“请注意，Devin 不会自动拉取更通用的文件类型，如 .md。”以其所持规范命名的文件与名为 notes 的文件行为是不同的。
每次都在提示词中重复指令。 这是掩盖问题的权宜之计。它确实有效，所以没有人去修复触发器，而重复也永远不会结束。Cognition 自己关于什么属于 Knowledge 的建议恰恰相反：“我们建议将你发现自己经常重复的提示词或 playbook 的各个方面包含进来。”
假设会话只是丢失了上下文。 有时确实如此，但这是一个不同形式的另一个问题，在当 Devin 忘记任务上下文时中有所描述。一个从未被检索到的 Knowledge 条目根本就没有进入过会话，谈何丢失。
用 skills（技能）代替 Knowledge。 这也是一个具有实际权衡的真实选择，我们在将 Devin 记忆移入技能中对此进行了规划。它并没有消除检索问题；它只是转移了问题。
解决方案：在关键地方使检索具有确定性，并验证一次
三个步骤。前两步需要十分钟，可以将整个功能从概率性转变为可预测性。
步骤 1：将你的条目分类为触发式和常驻式
梳理你拥有的内容，并对每个条目问一个问题：这适用于特定类型的任务，还是适用于仓库中的每个会话？
特定于任务的条目保留其触发器并获得更清晰的描述。遵循 Cognition 自身关于良好触发器命名的提示——哪个文件、哪个仓库或哪种任务类型。“部署”是一个类别。“任何涉及 infra 仓库下的发布流水线或部署脚本的内容”是一个触发器。
仓库范围的条目则进行固定。固定到特定仓库可以使该条目在 Devin 在该仓库中工作时始终被使用，从而将触发器排除在等式之外。将“固定到所有仓库”保留给真正适用于所有地方的极少数事物，因为固定在那里的每个条目都会在每个会话中被读取。
对于你想手动召唤的少数条目，分配一个宏（macro）——“一个以 ! 开头的简短标识符”，你在提示词中输入它。Cognition 指出，宏“只能包含字母、数字和连字符，并且在你的组织内必须是唯一的。”
步骤 2：运行一个会话并阅读 Accessed Knowledge
这是验证步骤，而且它是存在的。Cognition 记录了它：“Devin 会在会话中告诉你它使用了哪些 Knowledge”——在会话聊天的 Accessed Knowledge 标题下可见。
选择一个你为其编写了条目的任务，运行它，然后观察。如果该条目被列出，说明触发器有效。如果没有，你现在就知道了 Knowledge 问题和触发器问题之间的区别，这种区分使得其他一切都可以被修复。然后检查明显的干扰因素：该条目是否对你启用、其文件夹是否启用、它是否处于你预期的范围。
规则触发模式正在成为智能体配置的标准组成部分，而不是一个奇特的设计，比较另一个厂商如何建模相同的选择是快速建立直觉的方法——我们在选择 Windsurf 规则触发模式中阐述了其中一种。
步骤 3：将推理保留在检索无法决定其命运的地方
Knowledge 是编码智能体的检索层，它在这方面做得很好。规范背后的决策——你首先尝试了什么、什么地方出了问题、为什么会存在这个规则——并不是由任务触发的。它们是你想在六个月后自己阅读的东西，可能是在一个不同的工具中。
将这些内容保存在检索规则无法管辖的地方。一个其原因仅隐含在条目内容中的规范，是下一个人会推翻的规范。
在 MemoryLake 中进行设置
持久的部分需要一个不受触发器描述限制的归宿。MemoryLake 是一个你特意将这些决策写入其中的存储库，它与任何单个智能体的检索规则分开，并且可以从你连接的每个助手中读取。你自己用自己的语言编写这些条目。没有任何内容会从 Cognition 的系统或任何其他厂商的存储库中读取、写入或删除——你的 Knowledge 条目、playbook 和仓库完全保持在它们自己的控制之下。
步骤 1：创建 API 密钥
从控制面板生成一个密钥。正是它让云端智能体、终端助手和聊天客户端能够访问相同的事实集，而无需各自保留自己的版本。
步骤 2：上传你的第一批记忆
从原因而不是规则开始：为什么部署顺序是这样的、哪种方法被排除以及基于什么理由、谁拥有该服务以及需要告诉他们什么。Knowledge 条目承载指令；它们很少承载论据，而论据正是防止指令被覆盖的关键。
步骤 3：连接你的 AI 和智能体
将你的工具指向该层，以便这些事实在工作开始时加载，而不是取决于描述是否匹配。然后用唯一有意义的方法进行测试：向另一个助手询问其中一个决策。如果它做出了回答，你的推理就不再局限于单一厂商的检索路径中了。
这在实践中改变了什么
第一个改变是“Devin 忽略了我的 Knowledge”变成了一个可测试的断言。Accessed Knowledge 会告诉你使用了什么。要么条目被检索到了，要么没有，而修复方法也不同。
第二个改变是，固定（pinning）变成了一个深思熟虑的选择，而不是一个你跳过的字段。固定到仓库后，对于任何始终适用于那里的内容，检索就不再需要主观判断了。
第三个改变是你的条目变得更短了。一旦检索取决于描述内容的触发器，每个工作流一个条目就成了自然的形态，而 Cognition 正是这样推荐的。
第四个改变是，自动生成和自动建议的 Knowledge 不再是背景噪音。Devin 会根据 README、文件结构和仓库内容生成仓库知识，并根据你的聊天反馈建议新条目。审查这两者是维护工作，而另一种选择则是堆积一堆无人阅读的条目。
第五个改变是，你的持久推理不再取决于文件扩展名和范围级别。跨工具起作用的重要材料属于一个跟随你的层——这就是我们在将项目文档转化为 AI 记忆中所阐述的观点。
Devin Knowledge 的最佳实践
在编写内容之前先编写触发器。 如果你无法描述何时应该获取一个条目，那么该条目可能应该拆分为两个条目。
每个条目一个工作流。 Cognition 的指导原则是针对一个工作流或操作，并在可能的情况下进行拆分，因为一旦检索到，整个条目都会被读取。
固定无条件生效的内容。 仓库范围的规范不应该在每个会话中去竞争相关性。
为仓库内上下文使用专用的文件扩展名。 Devin 从命名的专用文件列表中拉取内容，不会自动拉取通用的 Markdown，因此扩展名是设计的一部分。
在重写任何内容之前检查启用状态。 针对每个用户的禁用和文件夹级别的开关，是解释为什么某个条目对别人有效而对你无效的最简单原因。
审查建议，不要默默接受。 Devin 会提出新条目和对现有条目的更新，它们在保存前是可编辑的，这显然是有原因的。
将论据保留在条目之外。 指令存在于 Knowledge 中；而它存在的原因应该保存在每个工具都能读取的地方。
结论
Devin 的 Knowledge 系统文档齐全，但略微有些反直觉。条目不会在会话开始时加载；它们是在工作与它们的触发器相关时被检索的，并且每个条目都需要一个触发器描述。这单一的设计决策解释了大多数写得很好的条目似乎被忽略的情况。
Cognition 还记录了停止依赖检索的方法。将条目固定到特定仓库，当 Devin 在那里工作时它就会始终被使用。固定到所有仓库，它就会应用于每个会话。分配一个宏，你就可以按名称召唤它。会话聊天中的 Accessed Knowledge 视图会告诉你 Devin 实际使用了什么，从而将怀疑转化为核实。
有两个界限值得记住：Devin 会自动从特定的专用文件列表中拉取 Knowledge，而不是从通用的 Markdown 中拉取；此外，针对每个用户或每个文件夹的禁用意味着你同事的会话和你的会话运行的并不是同一套内容。
将你的条目分类为触发式和常驻式，对照 Accessed Knowledge 验证其中各一个，并将规则背后的推理保存在检索触发器无法决定你是否能看到的地方。