开发者说明¶
这页主要给维护者看。它解释的是文档边界,不是训练逻辑本身。
specs/、根目录文档和 docs-site/ 各管什么¶
specs/¶
这里是实现约束来源。规则、数据格式、目录规划、训练边界都以这里为准。
根目录文档¶
根目录文档负责项目入口信息,例如:
- 主 README
- 操作指南
- 配置说明
- 数据目录说明
这些文件本身已经是权威来源,因此文档站优先通过 symlink 接入,而不是再复制一份。
docs-site/¶
这里负责解释。解释的重点是:
- 项目是什么
- 为什么这么设计
- 输入输出怎样流动
- 读者该如何判断运行是否正常
也就是说,docs-site/ 应该帮助读者理解项目,而不是制造第二套事实来源。
为什么这里必须坚持 DRY¶
文档重复最常见的问题不是“占空间”,而是后面没人能确定哪份才是最新的。
对这个项目来说,下面这些内容尤其不能复制两份:
- README 主信息
- 配置字段说明
- 操作步骤
- 文档站自己的 PRD
所以只要已有 Markdown 已经是权威来源,就优先建立 symlink。
哪些内容应该直接写在 docs-site/docs/¶
下面这些页面必须新写,因为它们的职责是解释,不是复述:
- 首页
- 项目概览
- 训练闭环说明
- 数据与恢复说明
- 这页开发者说明
为什么 specs/ 不在本轮做英文同步修改¶
原因不是“英文不重要”,而是 specs/ 本身是开发约束文件,当前你已经明确要求:
specs/不修改specs/保持中文
因此文档站的做法是:
- 在中文开发者页面里说明
specs/的角色 - 在英文侧保留对应入口页和文档站规格页
- 不把
specs/复制成第二套英文实现约束
新增文档时应该怎么判断放哪里¶
判断方法很直接:
- 如果它是项目真相来源,例如配置字段定义、运行入口、正式规范,优先放在原有权威位置,再由文档站接入。
- 如果它是解释性内容,例如原理、边界、输入输出、结果判断,放到
docs-site/docs/。
这样分层后,维护者看到一个页面时,能直接知道这页是在“定义规则”还是在“解释规则”。