# 体系创建流程

创建人员：Codex  
文件职责：说明如何创建一个新的通用体系，并保留体系组件的核心目标、原则、模板、创建指南和审计闭环。  
管理规范/模板：全局规范.md；体系说明.md；参考 common/exp-doc/ 和 common/project-doc/ 已落地体系。  
引用文件：全局规范.md；体系说明.md；common/exp-doc/实验规范.md；common/exp-doc/实验环境创建指南.md；common/project-doc/项目规范.md；common/project-doc/项目环境创建指南.md；common/ana-doc/案例分析规范.md；common/ana-doc/案例分析环境创建指南.md。  
记录方式：通用体系创建流程；新增体系创建口径变化时更新。

## 1. 文档定位

本文件给“创建新体系”的 AI 使用。

这里的体系，是指可以被项目按需启用的一组规范、模板、创建指南和审计规则，例如：

1. 项目体系。
2. 实验体系。
3. 需求体系。
4. 开发体系。
5. 数据体系。
6. 案例分析体系。

创建新体系不是简单建一个文件夹，而是要让任意项目管理员能按该体系创建本地环境，让执行 AI 能按规范工作，让审核 AI 能审计结果。

## 2. 核心目标

新体系必须服务以下目标：

1. 让该类事项的背景、目标、过程、结果可追踪。
2. 让该类事项的执行过程可审计。
3. 让关键产物有明确存储位置和入口。
4. 让问题能记录、归因、修复和复审。
5. 让项目能按需启用该体系，不启用时不产生额外负担。
6. 让 common 体系保持通用，不混入具体项目内容。

## 3. 核心原则

创建新体系时必须遵守：

1. **先定边界，再建模板。** 先写清体系负责什么、不负责什么。
2. **模板服务落地。** 每个模板都应对应项目里真实会创建的文件。
3. **规范不等于模板。** 规范说明怎么做；模板是项目实例化时要复制的文件骨架。
4. **创建指南必须能执行。** 任意 AI 按创建指南操作，应能在项目里创建出完整本地体系。
5. **审计必须覆盖设计和执行。** 设计 / 计划要审，执行 / 结果也要审。
6. **证据链必须串起来。** 总纲、设计 / 计划、执行日志、结果、审计、问题记录要能用 ID 或路径互相追踪。
7. **不层层加码。** 只把会影响目标、流程、结论、数据或可复现性的内容设为硬要求。
8. **common 不放项目内容。** 不能把某个项目的路径、样本、结论、业务名词写进通用体系。

## 4. 新体系最小组件

一个完整体系至少应包含：

1. `目录导读.md`：说明本体系目录下有哪些文档，各自做什么。
2. `<体系>规范.md`：说明体系定位、核心流程、文档职责、边界和问题闭环。
3. `<体系>环境创建指南.md`：指导项目管理员在具体项目里创建本地体系。
4. `<体系>总纲模版.md` 或等价账本模板：记录该类事项的背景、目标、状态和结论。
5. `<体系>设计/计划模版.md` 或等价计划模板：记录方案、步骤、输入输出和验收方式。
6. `<体系>执行日志模版.md`：记录实际执行关键节点、输入、输出、偏离和结果。
7. `<体系>审核规范.md`：说明审核范围、设计审核、执行审核、通过标准和阻断标准。
8. `<体系>审计报告模版.md`：记录审核结果、证据、问题和是否允许进入下一阶段。
9. `<体系>问题记录模版.md`：记录问题、影响、修复建议、状态和复验结论。

如果该体系涉及大量数据或结果包，还应补：

1. `<体系>存储体系创建指南.md`：说明数据放哪、怎么存、怎么读、schema 怎么记录。
2. 数据索引或 manifest 模板。

如果该体系是项目体系这类“配置型体系”，可额外包含：

1. 配置清单模板。
2. 变更记录模板。

## 5. 创建步骤

### 5.1 定义体系定位

先回答：

1. 这个体系管理哪类事项？
2. 这个体系的执行者是谁？
3. 这个体系的审核者是谁？
4. 这个体系的结果是什么？
5. 这个体系不负责什么？
6. 项目什么时候应该启用它？

如果这些问题答不清，不应先写模板。

### 5.2 设计核心流程

默认流程应继承管理体系主流程：

```text
来源聊天记录 / 上游依据
-> 总纲记录背景、目标、边界
-> 设计 / 计划记录方法、步骤、输入输出、验收方式
-> 设计 / 计划审计
-> 执行
-> 执行日志记录关键节点、中间数据、结果包
-> 执行审计
-> 问题记录 / 修复 / 复审
-> 结论回写
```

如体系确实不需要完整流程，必须说明简化原因和适用范围。

### 5.3 定义核心文档

为每个核心文档写清：

1. 文件职责。
2. 记录方式：append-only、覆盖式、版本式。
3. 关键字段。
4. 与其他文档如何互相引用。
5. 谁负责写。
6. 谁负责审。

不要创建没人会用的模板。

### 5.4 写环境创建指南

环境创建指南必须让项目管理员能照着做。

至少写清：

1. 需要创建哪些目录。
2. 需要实例化哪些模板。
3. 本地规范如何引用 common 规范。
4. 哪些文件是项目级滚动账本。
5. 哪些文件是结果或数据入口。
6. 创建完成标准。
7. 初始化审计要求。
8. 体系创建校验方案。

体系创建校验方案必须是可执行的轻量检查清单，至少覆盖：

1. 目录和核心文档是否存在。
2. 本地规范是否引用 common 规范且不削弱 common 硬约束。
3. 项目配置或体系配置是否登记完成。
4. 起因、计划 / 设计、执行日志、审计报告、问题记录是否能通过 ID 串起来。
5. 是否没有混入其他项目内容、旧路径、旧结果包或旧业务结论。
6. 校验结果写入哪个审计报告。
7. 校验不通过时如何修复和复审。

### 5.5 写审核规范

审核规范必须覆盖两关：

1. 设计 / 计划审核：检查目标是否清楚、方案是否能满足目标、是否和来源聊天一致。
2. 执行审核：检查执行是否按设计走、关键节点和数据是否可追踪、结论是否成立。

审核规范还必须写清：

1. 必查项。
2. 必须阻断的问题。
3. 不应阻断的边角料。
4. 审核员权限边界。
5. 审计报告写到哪里。
6. 问题如何闭环。

审核员权限边界必须区分“审核规范维护”和“被审对象修改”：

1. 审核员可以维护自己审核职责对应的本地审核 / 审计规范，用于修正审核流程、审计口径和阻断标准。
2. 审核员不默认修改被审体系执行规范、事项计划 / 设计、执行日志、结果包或主产物。
3. 如确需修改执行规范，应创建规范维护事项，或额外授予体系维护员 / 规范维护员角色，并记录原因、影响范围和复审入口。

### 5.6 写模板

模板开头必须包含：

1. 创建人员。
2. 文件职责。
3. 管理规范 / 模板。
4. 引用文件。
5. 记录方式。

模板应尽量使用占位符，不写具体项目内容。

### 5.7 建立目录导读

目录导读必须列出：

1. 本体系定位。
2. 文件清单。
3. 推荐使用顺序。
4. 哪些文件是规范。
5. 哪些文件是模板。
6. 哪些文件是创建指南。

新增或删除文件时同步更新目录导读。

### 5.8 自测创建

体系创建完后，必须至少找一个测试项目按环境创建指南完整实例化一次。

自测要检查：

1. 指南是否足够，不靠记忆也能创建。
2. 必需文档是否齐全。
3. 本地规范是否只引用 common，不复制正文。
4. 起因、计划、执行、审计、问题是否能串起来。
5. 是否混入其他项目内容。
6. 是否有绝对路径或乱码。
7. 是否按体系创建校验方案跑过，且校验结论写入审计报告。

发现指南漏项，应修 common 指南和模板，而不是只修测试项目。

## 6. 体系文档命名建议

默认命名：

```text
common/<体系>-doc/
  目录导读.md
  <体系>规范.md
  <体系>环境创建指南.md
  <体系>总纲模版.md
  <体系>设计模版.md
  <体系>执行日志模版.md
  <体系>审核规范.md
  <体系>审计报告模版.md
  <体系>问题记录模版.md
```

如果该体系更适合“计划”而不是“设计”，可使用 `<体系>计划模版.md`。

如果设计和计划职责高度重叠，应合并，不要人为拆成两个模板。

## 7. 体系启用后的项目本地文件

项目启用体系后，通常应创建：

1. 本地体系规范：引用 common 规范，记录项目补充。
2. 本地体系审核规范：引用 common 审核规范，记录项目补充。
3. 总纲账本。
4. 设计 / 计划账本。
5. 执行日志。
6. 审计报告。
7. 问题记录。
8. 必要的数据 / 结果目录。

项目本地规范默认可以很短，不复制 common 正文。

## 8. 什么时候不要新增体系

以下情况不应创建新体系：

1. 只是一个单次任务，用项目事项即可管理。
2. 只是某个体系下的一个模块，应放在现有体系内。
3. 没有独立执行流程。
4. 没有独立审计方式。
5. 没有多个项目复用价值。
6. 只是为了放几个文件而建文件夹。

## 9. 常见错误

1. 只写规范，不写环境创建指南。
2. 模板和规范职责混在一起。
3. 创建指南依赖 AI 记忆，不够可执行。
4. 本地项目规范复制 common 正文，后续产生冲突。
5. 审计只审结果，不审设计 / 计划。
6. 执行日志只写开始和结束，不记录中间关键节点。
7. 结果包没有入口，后续找不到。
8. 把某个项目的历史路径、样本、结论写进 common。
9. 为了严谨加太多 gate，导致体系难用。

## 10. 完成标准

一个新体系创建完成，至少满足：

1. common 下有独立体系目录。
2. 目录导读存在。
3. 体系规范存在。
4. 环境创建指南存在。
5. 核心模板齐全。
6. 审核规范和审计报告模板存在。
7. 问题记录模板存在。
8. 已用测试项目完整实例化过。
9. 自测发现的问题已回补到 common 文档。
10. 未发现具体项目内容污染 common。
11. 环境创建指南包含体系创建校验方案，且测试项目已按该方案校验通过。

## 11. 一句话

创建新体系的核心不是多建文件，而是让一类事项有稳定入口、可执行流程、可审计证据链、可复用模板和可闭环问题记录。