策划文档规范

提出方：Mukiik 最后更新：2026-10-26

文档存放位置与基本约定

本项目策划文档统一存放于项目仓库根目录下的 design_docs/，按功能或模块建立子目录。
策划文档的命名、提出方标记和章节结构统一遵循本规范。文件移动或重命名时，同步更新相关引用。
功能、玩法和数据设计采用下述五章结构。规范文档、目录索引按实际用途组织，不强行套用字段表和运行逻辑。
文件名和文件夹名使用小写英文，单词之间用下划线分隔，可包含必要的数字。例如 inventory_design.md、quest_examples/。文档标题和正文可使用中文；README.md 等约定文件名保留。
文档标题下方使用“提出方”标记，直接填写GitHub ID，例如“提出方：Mukiik”，无需额外注明平台。多人共同提出时分别列出；AI 辅助编写仍填写实际提出人的账号。
标题下方同时填写最后更新日期，格式为 YYYY-MM-DD。维护人与提出方不同时，可增加“维护人”。提出方待补充的文档视为草稿。

先用一句话概括：让谁能够做什么，解决什么问题。

再按需展开背景和预期体验。避免只写“完善系统”“提升体验”等没有具体对象和结果的目标。

涉及配置、数据结构或持久化数据时，使用以下表头：

字段名	是否主键	字段类型	示例值	是否必填	默认值／缺省处理	用途与规则
`example_id`	是	string	`example_001`	是	无默认值；缺失时拒绝导入	作为主键唯一标识一条记录；同一文件内必须唯一。仅用于说明表格写法，不代表现有业务字段。

填写要求：

按实际功能说明新增、删除、修改、查询，以及需要的触发、结算、中断或恢复流程。无需为不支持的操作编造逻辑。

每项流程写清：

重点描述系统应有的行为，不要求编写具体代码、函数实现或数据库操作语句。

提供 所属仓库 + 仓库内相对路径 + 示例内容。配置表需明确项目正常开发、运行时预期存放的项目内路径，让读者能定位文件并理解实际数据。

注明文件所属的对应项目仓库；路径从该仓库根目录开始，使用仓库内相对路径，不使用个人电脑的绝对路径。
配置表路径从项目仓库根目录开始，指向开发、运行时实际使用或计划使用的配置文件，不能仅提供文档示例的存放位置。若开发时编辑的源表与运行时读取的配置文件不同，分别注明两者的路径及对应关系。
已存在的文件提供可访问链接；尚未落地的路径必须标注“计划路径，文件尚未创建”，不能写成现有文件。
JSON 示例需在代码块外注明所属仓库和配置文件的项目内相对路径；内容应体现该配置文件预期采用的数据结构，可直接解析，不包含注释或省略号，并与第二章的字段定义一致。只展示局部时，注明所属对象或数据节点，以及省略范围。
可以使用其他表格形式；电子表格需注明实际文件路径、工作表名称，必要时补充区域。
示例需覆盖第三章的主要流程，至少给出一份能说明核心规则的样例。正文摘录与实际文件发生变化时同步更新。
不涉及数据文件时，保留本章并注明“不适用”及原因，按需提供操作或状态变化示例。

每条按 前置条件 → 操作 → 预期结果 编写，结果应能直接判断通过或失败。

示例（仅说明写法）：给定一份包含重复 example_id 的输入文件 → 执行导入 → 导入被拒绝，提示重复 ID，已有数据保持不变。