提出方：Mukiik
最后更新：2026-11-01
目的与范围
让项目成员能够集中查找同一主题的不同设计，并沿文档链接了解跨主题关系，避免文档增多后散落、重复或难以定位。
本规范约定策划文档的存放、导航、引用和维护方式；正文格式、命名及提出方标记遵循策划文档规范，框架正文结构遵循框架类文档规范。
按主题存放
策划文档统一存放于 design_docs/，以稳定的设计主题建立子目录。同一主题的定义、规则、流程等不同方面集中存放，便于一起查阅和维护。
- 目录名称表达主题，例如物品、场景对象及二者的关系；不单纯按“框架”“详细设计”等文档类型聚合无关主题。
- 单主题框架与该主题的详细设计放在一起。
- 跨主题框架如果讨论一个独立的关系主题，可以建立对应主题目录；通过链接引用各主题的详细设计，不要求被引用文档迁入该目录。
- 文档在主要维护主题下只保留一份，其他主题通过链接引用。不要因多重归属复制正文。
- 新主题有实际内容时再建目录，不预建空目录或空白文档。
- 初期保持浅层结构；当某个方面积累了多篇需要一起管理的文档，再拆为子主题目录。不规定固定篇数，也不要求为每篇文档单独建文件夹。
以下为结构示意，不代表这些目录和文件均已创建：
design_docs/
├─ README.md
├─ conventions/
├─ scene_object_item_relations/
│ ├─ scene_object_item_framework.md
│ └─ assets/
├─ items/
│ ├─ README.md
│ ├─ item_definition.md
│ ├─ item_stacking.md
│ └─ item_processing.md
└─ scene_objects/
├─ README.md
├─ scene_object_definition.md
└─ scene_object_interaction.md
入口与阅读导航
design_docs/README.md 作为策划文档总入口，链接到规范和已有主题入口，并简述各主题的范围；不重复罗列所有下层文档。
一个主题包含多篇文档时，用 README.md 或已有框架文档作为入口，说明各篇负责什么及推荐阅读顺序。已有框架能够承担导航时，不再维护内容相同的第二份索引。
同一篇文档可以出现在多个主题入口中。文件夹负责集中存放，入口和正文链接负责表达关联与阅读顺序，阅读路径不必与目录层级完全一致。
框架图的元素与线条可通过索引表指向解释文档：每个元素或线条一行，包含名称、一句话说明和文档链接。尚无对应文档时统一标记“暂未设计”，不创建无内容的占位文件或失效链接。
引用与唯一来源
- 内部引用使用标准 Markdown 相对链接，路径相对于当前文档，使用
/并保留文件扩展名。 - 链接文字应能识别目标主题；必要时用一句话说明引用关系，不仅列出文件路径。
- 一个定义或规则应有明确的维护来源。其他文档简述关系并链接到来源，不复制整套规则。
- 引用其他主题时保留原文档位置，不通过复制文件制造新的维护版本。
- 文件名应能辨认主题与内容；目录入口可使用
README.md，具体正文优先使用有主题含义的名称。
附件管理
配图、图表源文件及其他正文附件存放于所属主题的 assets/。附件较多时可在其中按所属文档分组。
图表的可编辑源文件与阅读用图片使用一致的基础名称，例如 scene_object_item_relationship.drawio 和 scene_object_item_relationship.svg。正文嵌入图片，同时提供源文件链接；修改图表后同步更新二者。
多个文档引用同一附件时保留一份维护来源。移动正文前检查附件是否被其他文档共用，再决定一并移动或仅修改引用路径。
新增与维护
新增文档前先查找已有主题和相同用途的文档，决定补充现有内容还是新增一篇；新增后在相应入口或框架索引中补上链接。
移动、重命名或拆分文档时，同步更新指向它的链接、它内部的相对链接，以及图片与源文件引用。完成后检查目标是否存在；引用具体标题时还要检查标题锚点。
文档被替代或废弃时，明确标记状态及替代文档，并更新导航入口，避免多份文档同时被当作当前规则。
本规范中的结构示意不要求立即批量迁移现有文件；实际整理时按上述规则处理相关文档及引用。
与阅读工具的关系
Obsidian 可辅助浏览链接、查看反向引用和按属性筛选，但文件夹与普通 Markdown 链接仍是项目文档的基础，文档应能在 Typora、代码编辑器及仓库网页中阅读。
属性或标签可辅助记录文档类型、相关主题等多重分类，不替代主题入口，也不强制每篇文档配置复杂元数据。项目中的说明与导航不依赖特定插件才能理解。