跳转至

开发者说明

这页主要给维护者看。它解释的是文档边界,不是训练逻辑本身。

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/

这样分层后,维护者看到一个页面时,能直接知道这页是在“定义规则”还是在“解释规则”。