为什么 memory bank 会存放在您的 rules 文件夹中
Amazon Q 的项目规则是项目 .amazonq/rules 文件夹中的 Markdown 文件。官方文档直接指明了其目的：规则“描述了您团队的编码标准和最佳实践”，将它们存储在项目中意味着您可以“确保开发人员之间的一致性，无论他们的经验水平如何”。
Memory bank 是一个具有独立目的的独立功能。Amazon Q “可以自动生成 memory bank 文件，提供项目结构、技术栈和产品信息的快速索引”，通过分析关键文件，使其能够理解代码库，“而无需在您每次提问时都分析整个项目”。
这两个功能共享同一个位置。当您生成时，“Amazon Q 会在 .amazonq/rules 下创建一个 memory-bank 子文件夹”，其中包含四个文件：用于概述项目及其功能的 product.md、用于架构 and 文件夹组织的 structure.md、用于技术栈和依赖项的 tech.md，以及用于开发标准和模式的 guidelines.md。
最后一个文件名正是最有趣的地方。guidelines.md 是生成的描述“项目的开发标准和模式”的内容——这与您手写规则所做的工作完全一致。现在两者都在同一个目录树中，并且两者“在您与 Amazon Q 聊天时都会自动用作上下文”。
这并不是一个缺陷。这是一种让手写内容和派生内容占用同一个命名空间的设计，而这种设计的代价是，在最关键的时刻，作者身份变得不可见。这与任何 diff 都无法向您展示的冲突指令层属于同一类问题，只不过在这里，其中一个层是自己编写的。
人们尝试的其他方法
假设 memory bank 可以替代规则。 事实并非如此。两者都被用作上下文。生成 memory bank 会增加文件，但不会废除您编写的文件。
假设 Regenerate 只会影响生成的文件。 这个假设值得去测试，而不是盲目相信。文档中记录的操作是 Regenerate Memory Bank，它重新生成的是 memory bank 文件。之所以要验证而不是假设，是因为边界是您同样在其中写入的文件夹内的一个子文件夹，而唯一能将您的文件标记为“您的”的，就是您放置它们的位置。
因为名字合适而将团队标准放入 guidelines.md。 名字确实合适，但该文件是生成的。写在那里的任何内容都会在重新生成时被覆盖。
为了安全起见关闭 memory bank。 这用一个真正的优势换取了一个归档问题。索引的存在是为了让 Amazon Q 不必在每次提问时都重新读取整个项目，这是非常有价值的。
在面板中关闭文件并认为问题已解决。 Rules 按钮列出了可用的规则，并允许您点击其中一个来为当前聊天会话切换其状态。带有勾选标记的文件“处于活动状态，并将应用于您的对话”；没有勾选标记的文件“在当前会话中处于非活动状态”。这是一个针对每个会话的开关，而不是一个归档决定，它不会改变文件夹中的内容。
依赖面板来显示谁编写了什么。 它只显示名称和勾选标记。生成的文件位于 memory bank 子文件夹下，因此路径就是信号——而且路径是唯一的信号。
解决方案：为手写规则赋予独特的名称并进行独立审查，然后在重新生成后进行验证
该机制只为您提供了一个边界：memory-bank 子文件夹。其他一切都是您强加的约定，而约定只有在有人检查时才起作用。
步骤 1：命名您自己的规则文件，以便从文件名中就能看出作者身份
检查 .amazonq/rules 并重命名您团队编写的内容，使文件名能够表明其来源。可以使用前缀：team-api-conventions.md、team-testing-policy.md、team-security-baseline.md。具体的约定并不重要，重要的是它只有一个词长，并且毫无例外地被应用。
这并不是为了装饰。当四个生成的文件出现在同一个目录树中时，“这是我们的吗”这个问题需要仅凭文件列表来回答，而且是由在设置该文件夹时不在场的人来回答。前缀可以回答这个问题；而一个精心设计的文件名却不能，因为生成的文件名同样也是精心设计的。
在此期间，将属于生成文件的任何内容从您自己的文件中移出。如果您的一条规则描述了文件夹布局，那么这正是 structure.md 的用途，重复它意味着需要维护两次，并最终导致其自身产生冲突。
步骤 2：编写一条规则来控制生成器产生的内容
这是大多数团队都会忽略的部分，而且文档中也有记载。您可以“通过创建自定义项目规则来定制 memory bank 文件的生成方式”。给出的示例是一个指定生成文件的语言和格式的规则。
因此，生成器是可控的，而控制规则与其它所有内容都存放在同一个文件夹中。编写一个文件——在您的前缀下将其命名为 team-memory-bank-policy.md——说明生成的文件应该包含和不应该包含什么。其中两条指令最具价值：保持生成的文件是描述性的而不是规范性的，并且不要重复已经存在于带前缀文件中的团队标准。
第二条指令就是那道篱笆。它在文件系统级别不阻止任何操作。它告诉生成器，某类内容已经在其他地方拥有归属，这是在此设计中您唯一可以表达这一点的地方。
步骤 3：提交、重新生成并阅读 diff
首先提交重命名的文件和策略规则，这样您就拥有了一个干净的基线。然后从 Rules 按钮运行 Regenerate Memory Bank，并在接受任何更改之前阅读生成的 diff。
您需要检查三件事。您的带前缀文件未被触及。四个 memory bank 文件仅在 memory-bank 子文件夹内发生了变化。以及 guidelines.md 没有重新派生出您的策略规则要求其忽略的那些标准版本。
刻意执行一次此操作，并与提交进行对比，您就会通过观察而不是假设来了解边界。在重大重构之后再次执行此操作，因为那是生成器拥有最多新材料、也最有可能重新阐述内容的时候。
保持基线提交可访问。生成的文件本就是为了重新生成而设计的；能够看到重新生成改变了什么，才是确保其安全的关键。
在 MemoryLake 中进行设置
步骤 1 中带前缀的文件是其中持久的一半：您团队达成的协议，用您团队自己的话表达，不是任何生成器产生的，任何重新生成都不应更改它们。MemoryLake 是保存这一半内容的地方，因此它不仅仅由它在某个工具文件夹中的位置来定义。
您自己用自己的话编写这些条目。不会从 .amazonq/rules、Amazon Q memory bank 或任何供应商的存储中读取、写入或删除任何内容。
步骤 1：创建 API 密钥
登录并从控制面板生成一个密钥。该密钥允许智能体读取您编写的条目，无论您恰好处于哪个编辑器或代码仓库中。
步骤 2：上传您的第一批记忆
添加来自带前缀文件的协议，每个条目对应一个决定，并附带原因。原因是规则重写后仍能保留的部分，因为它是告诉下一个人该规则是否仍然适用的关键。
步骤 3：连接您的 AI 和智能体
将您的智能体指向该工作区。团队确定的决定随后即可在完全没有 .amazonq 文件夹的工具中使用，这正是它们成为团队协议而非 Amazon Q 配置的原因。
这在实践中改变了什么
第一个变化是文件列表回答了作者身份问题。在使用前缀之前，“这是我们写的吗”需要了解该文件夹的历史。在使用前缀之后，列表本身就是答案，新团队成员第一眼就能看明白。
第二个变化是，生成器变成了您配置的对象，而不是给您带来意外的东西。策略规则是一个具有巨大影响的小文件，因为它是文档中规定的说明生成文件用途的方式——一旦它存在，memory bank 就会停止向重复阐述标准的方向漂移。
第三个变化是重新生成变得常规化。大多数团队避免使用 Regenerate，因为他们不确定它会触及什么。有了基线提交和前缀约定，diff 可以在几秒钟内给出答案，而在重构后刷新的 memory bank 的价值，要远远高于生成一次后便任其过期的 memory bank。
它还澄清了每会话切换的用途。关闭规则是关于当前对话的决定，而不是关于项目的决定，并且它在会话结束后不会保留。期望面板表达项目策略的团队最终会得到仅持续一次聊天的策略——这一区别值得明确，也是了解哪些指南实际上有效与编写它们是两码事的原因。
如果您在其他工具中也使用过 memory-bank 模式，归档问题是相同的。Cline 将其 bank 保存在自己的目录中，这就是为什么在其中设置一个 bank 主要关乎每个文件中放入什么，而不是谁拥有该文件夹，而当人们不再满足于单个 bank 时所比较的替代方案也主要在这一点上存在差异。
共享 rules 文件夹的最佳实践
使用统一的前缀，绝不破例。 该约定的价值在于，没有前缀的文件在定义上就不是您的。一次例外就会破坏这一特性。
保持策略规则简短，且关注形式而非内容。 它应该说明什么样的事物属于生成的文件。如果它开始包含标准本身，那么您就把您的标准移到了生成器的输入中。
始终针对提交进行重新生成。 diff 是您能获得的唯一观察结果。没有基线，它就无法使用。
让生成的文件进行描述，让您的文件进行规范。 一个写着“API 层位于 src/api”的生成文件是有用的，且刷新成本很低。而一个写着“所有端点必须验证输入”的生成文件则是一项没有人同意该措辞的标准。
将原因写入每个手写规则中。 没有原因的规则以后无法进行评估，因此它要么被永远遵守，要么在挫败中被删除。这与被忽略的规则通常是没人能证明其合理性的规则是同一个原因。
记住该文件夹会传播到其他界面。 相同的 .amazonq/rules 文件夹是文档中记录的与 GitLab 或 GitHub 中的 Amazon Q 配合使用的项目规则位置，在这些地方，规则会“自动”成为项目的上下文。您提交的内容就是在那运行的内容。
当有人离职时审查该文件夹。 手写规则是个人的判断。当这个人离开后，该规则需要一个所有者或被删除，这正是审计您的工具记住了什么在规则变成历史遗迹之前所能发现的事情。
结论
Amazon Q 的 memory bank 是一个存放在尴尬位置的实用功能。它将四个文件写入保存您团队协议的文件夹中，其中一个文件的命名与您的协议所做的工作相同，而管理这两者的面板对它们一视同仁。
解决方法不是避免使用该功能。而是使文件名中的作者身份清晰可辨，使用文档中记录的途径告诉生成器其文件的用途，并针对提交重新生成一次，以便您通过观察而不是假设来了解边界。
然后，将协议本身保存在比单个工具的配置文件夹更广泛的地方。规则是在特定编辑器中执行决定的方式。决定才是值得保留的东西，它的生命周期比文件夹更长——这就是为什么在工具之间迁移的团队会发现，携带规则很容易，而携带推理才是真正的工作。