为什么整理文件可能会让您失去规则文件夹
首先来看看指南的作用。JetBrains 将其描述为常驻简报：“指南允许您向智能体提供持久、可复用的上下文。Junie CLI 从 AGENTS.md 文件中读取指南，并将此上下文添加到它处理的每个任务中。”
然后是文档中引用的发现顺序。“当 Junie CLI 开始一项任务时，它会按以下顺序寻找指南：”首先，“项目根目录中的 .junie/AGENTS.md 文件。”其次，“项目根目录中的 AGENTS.md 文件，如果存在，则与 .junie/playbook.md 以及每个 .junie/rules/*.md 文件结合使用。”第三，“.junie/guidelines.md 文件或 .junie/guidelines/ 文件夹——Junie 的旧版指南格式（仍受支持）。”
将这三行看作一个表格而不是散文，不对称性就显现出来了。与 .junie/playbook.md 和 .junie/rules/*.md 的结合仅在第二条路径中被记录。第一条路径只命名了一个文件。第三条路径命名了旧版位置。如果您有一个规则文件夹和一个 playbook，承载它们的路径是您在项目根目录下作为 AGENTS.md 存放主指南的那条路径——而不是 .junie/ 内部的那条。
这很重要，因为大多数人都是这样来到这里的。首次打开时的导入也有文档记录：“当 Junie CLI 首次打开项目时，它会检查是否有来自其他 AI 智能体的任何指南或记忆文件。如果检测到此类文件，它将建议将指令导入到 .junie/AGENTS.md 中。”对于一个什么都没有的项目，这个建议是合理的。但对于一个已经拥有 .junie/rules/ 文件夹的项目，它会悄无声息地将您转移到官方文档未描述会合并这些文件的路径上。
这一切都不会产生错误。Junie 仍然有指南，仍然遵循它们，并且仍然表现出色。您出于结构原因拆分出来的规则只是不再是简报的一部分，而发现这一点的唯一方法就是阅读这个有序列表。
人们尝试的其他替代方案
将相同的内容放在两个地方。 将规则文件夹的内容复制到 .junie/AGENTS.md 中，从内容能够送达的狭义角度来看是有效的。但这也意味着未来的每一次修改都有两个归宿，其中一个必然会发生偏差。
将所有内容移至旧版位置。 .junie/guidelines.md 和 .junie/guidelines/ 被描述为“Junie 的旧版指南格式（仍受支持）”，但受支持并不等同于它是官方文档所基于的主流路径。它是顺序中的第三个条目，也是人们在搜索“junie guidelines”并找到较旧资料时意外落脚的地方。
假设全局文件可以填补这一空白。 它有自己的职责。“Junie CLI 还支持来自 ~/.junie/AGENTS.md 的全局指南”，在 Windows 上，“全局指南路径为 %USERPROFILE%\.junie\AGENTS.md”。文档明确说明了它的用途：“此文件允许您定义适用于所有项目的个人偏好或组织范围的规则，而无需在每个仓库中重复它们。”个人偏好并不能替代项目的规则文件夹。
为了安全起见，将项目规则复制到全局文件中。 Junie 优雅地处理了无害的情况——“如果全局指南和项目指南内容相同，Junie 会自动去重并仅使用一次该内容”——但近乎重复的内容才是真正的风险，它们是通过优先级而不是合并来解决的。
认定问题在于记忆。 可复用的技能和指令文件回答了“你应该如何工作”的问题，而这与项目记录之间的差距完全是另一个问题，这在为什么智能体技能不是记忆中有所讨论。
解决方案：刻意选择一条路径，然后在文档说明的地方附加 playbook 和规则
步骤 1：盘点这三条路径，看看您的项目处于哪一条
寻找四样东西：.junie/AGENTS.md、项目根目录下的 AGENTS.md、.junie/playbook.md 以及包含 markdown 文件的 .junie/rules/ 文件夹。然后也检查一下旧版组合——.junie/guidelines.md 或 .junie/guidelines/ 文件夹。
将您找到的内容与有序列表进行比对。如果您有 .junie/AGENTS.md，则您处于路径一。如果您有根目录 AGENTS.md 且没有 .junie/AGENTS.md，则您处于路径二，文档将该路径描述为在“如果存在”时结合 playbook 和每个 .junie/rules/*.md 文件。如果您只有旧版文件，则您处于路径三。
最需要仔细审视的情况是这几种文件同时存在——通常是由首次打开导入创建的 .junie/AGENTS.md，加上在此之前就存在的 .junie/rules/ 文件夹，可能还有几个月没人打开过的旧版 guidelines.md。这并不是一个损坏的项目，而是一个文件累积速度快于任何人重新阅读发现顺序的项目的典型表现。
步骤 2：将主简报放在承载您其余配置的路径上
一旦盘点清单摆在您面前，决定就很简单了。
如果您有希望在每个任务中都生效的 .junie/rules/ 文件夹或 .junie/playbook.md，请将主指南放在项目根目录的 AGENTS.md 中——这是文档中描述的会将它们结合起来的路径。这还有一个值得一提的额外好处：根目录 AGENTS.md 是其他智能体寻找的跨工具文件名，因此一个文件即可服务于 Junie 和其他所有工具，这也契合该格式自身被描述为“用于引导编码智能体的开放文件格式”的初衷。
如果您没有规则文件夹，也没有 playbook，那么 .junie/AGENTS.md 就很好，可以保持根目录整洁。只需在某处记录下这个选择，因为一旦有人添加了规则文件夹，该路径就不再匹配您的配置了。
如果您使用的是旧版文件，请将内容移至上述两条适用路径之一，并在仓库中保留简短说明，指出指南现在存放的位置。一个被无故清空的 .junie/guidelines.md 在下一个人看来，就像是一个被误删的文件。
按照 JetBrains 阐述的类别来编写指南本身，因为它们对应了智能体实际上会犯错的问题：一个“快速启动清单”，列出“智能体在执行任何操作之前必须遵循的最关键规则”；“本地开发命令”，以表格形式列出安装、lint、测试、构建和开发服务器条目；“功能开发与决策”；“UI 与架构”；“安全与数据处理”；“测试与贡献”；以及“智能体的非目标”部分，被描述为“明确禁止智能体绝对不能做的事情”。最后一个类别是人们最容易跳过、事后又后悔没写的。其目的显而易见：提供这些信息“有助于 Junie 更好地了解您的环境，避免不兼容的库，并遵循您项目特定的架构模式”。
步骤 3：将全局层级设置为个人范围，其余的交给优先级规则
现在，有目的地放置全局文件。~/.junie/AGENTS.md 应该存放关于您个人而非项目的规则：您喜欢如何表述 commit、您希望在所有地方应用的审查习惯、真正跨越仓库的组织级规范。
这两个层级之间的交互在三种情况下有文档记录，而且它们无聊得令人放心。“如果仅存在全局指南或仅存在项目指南，Junie 将使用可用的指南——不添加额外的注释。”“如果同时存在全局指南和项目指南，Junie 会同时包含两者并进行清晰标记。当发生冲突时，项目级指南始终优先于全局指南。”以及“如果全局指南和项目指南内容相同，Junie 会自动去重并仅使用一次该内容。”
这带来两个实际结果。首先，您不需要进行防御性复制：相同的内容会被去重，而冲突的内容会向项目倾斜。其次，近乎重复的内容才是意外发生的地方。全局行写着“始终添加集成测试”，而项目行写着“仅针对功能开发进行单元测试”，这两者并不相同，因此两者都会被包含，且项目获胜——这是正确的，但除非您去寻找，否则也是隐形的。保持这两个层级在范围上真正不同，才能使优先级成为一项功能，而不是一个谜题。在涉及分层指令文件的任何地方，同样的原则都会带来回报，正如在Copilot 如何对指令文件进行排序中所讨论的那样。
在 MemoryLake 中进行设置
指南是进入每个任务的简报，因此它们必须保持简短，这意味着它们背后的推理必须存在于其他地方。为什么不能使用旧版包、您拒绝了哪个库以及理由是什么、命名规范在保护什么——这些都不属于智能体在每次运行时读取的文件，而这些正是您在决定某条指南是否仍然有效时所需要的。一个您有目的地向其中写入 MemoryLake 条目的存储库，可以保持该记录的可检索性，而不会使简报膨胀。您可以用自己的语言亲自编写这些条目。不会从您的 .junie 目录或任何其他工具的文件中读取、写入或删除任何内容。
步骤 1：创建 API 密钥
登录并在您的工作区设置中生成一个 API 密钥。这是您的智能体和集成所使用的凭据，因此在开始移动任何内容之前，请先创建它。
步骤 2：上传您的第一批记忆
从您的指南所假设的决策开始：为什么技术栈是这样的、哪种方法在争论中落败以及原因是什么、“非目标”部分实际上在防范什么。将每个决策写成简短的独立笔记，以便可以单独检索。
步骤 3：连接您的 AI 和智能体
连接您使用的助手和智能体。这样，推理就会随您同行，而与特定工具使用哪条路径来寻找其指令文件无关。
这在实践中改变了什么
首次打开时的导入变成了一个决定，而不是默认操作。在全新项目中，Junie 提议将其他智能体的文件合并到 .junie/AGENTS.md 中确实很有帮助。但在一个带有规则文件夹的项目中，这是需要暂停并检查您希望处于哪条路径的时刻。
规则文件夹变成了一个真正的结构，而不仅仅是一种归档习惯。只有当您所处的路径是被文档记录为会进行合并的路径时，将指南拆分为 .junie/rules/*.md 才会带来回报；否则，这种拆分只是组织上的，而不是功能上的。这也是为什么刻意合并分散的规则目录是值得的，正如在如何合并 Windsurf 和 Devin 规则文件夹中所讨论的那样。
跨工具共享得到了具体的答案。选择根目录 AGENTS.md 路径可以让您拥有一个 Junie 能读取且其他智能体也能识别的文件，这比维护一个 Junie 专用文件外加一个供其他所有人使用的副本要好得多。
对“智能体实际上在遵循什么”的审查变得更短。写下路径后，答案就是一个路径和一个有序列表，而不是一次调查——这与在哪些 Tabnine 指南正在生效中为另一种工具描述的转变相同。
保持指南易于查找的最佳实践
将路径写进指南本身。在顶部附近写上一行——“指南存放在项目根目录的 AGENTS.md 中；.junie/rules 中的规则会与其结合”——可以免去下一个人重新推导发现顺序的麻烦。
保持全局文件的个人属性。如果 ~/.junie/AGENTS.md 中的某行内容在别人的仓库中会让您感到尴尬，那么它应该属于项目文件。
刻意避免跨层级的近乎重复。相同的内容会被去重；几乎相同的内容会被包含两次并按优先级解决，这比任何一种极端情况都更难推理。
将禁止事项写下来。“智能体的非目标”类别之所以存在，是因为代价最昂贵的智能体错误是它根本不应该做的事情，而不是它做得不够完美的事情。
在任何重构后重新阅读发现顺序。在 .junie/ 和项目根目录之间移动文件会改变您所处的路径，而且这种改变是无声无息的。
重新审视那些生成而非手写的指南。导入或挖掘出的规则是一个有用的起点，但不是一个好的终态，正如在如何处理来自 Qodo 的挖掘规则中所论证的那样。
结论
Junie 通过三条路径寻找指南，而官方文档仅将 .junie/playbook.md 和每个 .junie/rules/*.md 附加到其中一条路径：项目根目录下的 AGENTS.md。.junie/ 内部的路径只命名了一个文件，而旧版组合只是受支持，并非核心。
因此，一旦说清楚，放置决定就很简单了。如果您维护一个 playbook 或规则文件夹，请将主简报放在根目录的 AGENTS.md 中，让文档中记录的合并机制发挥作用。如果没有，请将其保留在 .junie/AGENTS.md 中并记录下该选择。然后将全局文件设置为个人范围，信任优先级规则，并将指南背后的推理保存在不需要塞进智能体在每个任务中都要读取的文件中的地方。