体系创建流程
创建人员：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 使用。
这里的体系，是指可以被项目按需启用的一组规范、模板、创建指南和审计规则，例如：
- 项目体系。
- 实验体系。
- 需求体系。
- 开发体系。
- 数据体系。
- 案例分析体系。
创建新体系不是简单建一个文件夹，而是要让任意项目管理员能按该体系创建本地环境，让执行 AI 能按规范工作，让审核 AI 能审计结果。
2. 核心目标
新体系必须服务以下目标：
- 让该类事项的背景、目标、过程、结果可追踪。
- 让该类事项的执行过程可审计。
- 让关键产物有明确存储位置和入口。
- 让问题能记录、归因、修复和复审。
- 让项目能按需启用该体系，不启用时不产生额外负担。
- 让 common 体系保持通用，不混入具体项目内容。
3. 核心原则
创建新体系时必须遵守：
- 先定边界，再建模板。 先写清体系负责什么、不负责什么。
- 模板服务落地。 每个模板都应对应项目里真实会创建的文件。
- 规范不等于模板。 规范说明怎么做；模板是项目实例化时要复制的文件骨架。
- 创建指南必须能执行。 任意 AI 按创建指南操作，应能在项目里创建出完整本地体系。
- 审计必须覆盖设计和执行。 设计 / 计划要审，执行 / 结果也要审。
- 证据链必须串起来。 总纲、设计 / 计划、执行日志、结果、审计、问题记录要能用 ID 或路径互相追踪。
- 不层层加码。 只把会影响目标、流程、结论、数据或可复现性的内容设为硬要求。
- common 不放项目内容。 不能把某个项目的路径、样本、结论、业务名词写进通用体系。
4. 新体系最小组件
一个完整体系至少应包含：
目录导读.md：说明本体系目录下有哪些文档，各自做什么。<体系>规范.md：说明体系定位、核心流程、文档职责、边界和问题闭环。<体系>环境创建指南.md：指导项目管理员在具体项目里创建本地体系。<体系>总纲模版.md 或等价账本模板：记录该类事项的背景、目标、状态和结论。<体系>设计/计划模版.md 或等价计划模板：记录方案、步骤、输入输出和验收方式。<体系>执行日志模版.md：记录实际执行关键节点、输入、输出、偏离和结果。<体系>审核规范.md：说明审核范围、设计审核、执行审核、通过标准和阻断标准。<体系>审计报告模版.md：记录审核结果、证据、问题和是否允许进入下一阶段。<体系>问题记录模版.md：记录问题、影响、修复建议、状态和复验结论。
如果该体系涉及大量数据或结果包，还应补：
<体系>存储体系创建指南.md：说明数据放哪、怎么存、怎么读、schema 怎么记录。- 数据索引或 manifest 模板。
如果该体系是项目体系这类“配置型体系”，可额外包含：
- 配置清单模板。
- 变更记录模板。
5. 创建步骤
5.1 定义体系定位
先回答：
- 这个体系管理哪类事项？
- 这个体系的执行者是谁？
- 这个体系的审核者是谁？
- 这个体系的结果是什么？
- 这个体系不负责什么？
- 项目什么时候应该启用它？
如果这些问题答不清，不应先写模板。
5.2 设计核心流程
默认流程应继承管理体系主流程：
来源聊天记录 / 上游依据
-> 总纲记录背景、目标、边界
-> 设计 / 计划记录方法、步骤、输入输出、验收方式
-> 设计 / 计划审计
-> 执行
-> 执行日志记录关键节点、中间数据、结果包
-> 执行审计
-> 问题记录 / 修复 / 复审
-> 结论回写
如体系确实不需要完整流程，必须说明简化原因和适用范围。
5.3 定义核心文档
为每个核心文档写清：
- 文件职责。
- 记录方式：append-only、覆盖式、版本式。
- 关键字段。
- 与其他文档如何互相引用。
- 谁负责写。
- 谁负责审。
不要创建没人会用的模板。
5.4 写环境创建指南
环境创建指南必须让项目管理员能照着做。
至少写清：
- 需要创建哪些目录。
- 需要实例化哪些模板。
- 本地规范如何引用 common 规范。
- 哪些文件是项目级滚动账本。
- 哪些文件是结果或数据入口。
- 创建完成标准。
- 初始化审计要求。
- 体系创建校验方案。
体系创建校验方案必须是可执行的轻量检查清单，至少覆盖：
- 目录和核心文档是否存在。
- 本地规范是否引用 common 规范且不削弱 common 硬约束。
- 项目配置或体系配置是否登记完成。
- 起因、计划 / 设计、执行日志、审计报告、问题记录是否能通过 ID 串起来。
- 是否没有混入其他项目内容、旧路径、旧结果包或旧业务结论。
- 校验结果写入哪个审计报告。
- 校验不通过时如何修复和复审。
5.5 写审核规范
审核规范必须覆盖两关：
- 设计 / 计划审核：检查目标是否清楚、方案是否能满足目标、是否和来源聊天一致。
- 执行审核：检查执行是否按设计走、关键节点和数据是否可追踪、结论是否成立。
审核规范还必须写清：
- 必查项。
- 必须阻断的问题。
- 不应阻断的边角料。
- 审核员权限边界。
- 审计报告写到哪里。
- 问题如何闭环。
审核员权限边界必须区分“审核规范维护”和“被审对象修改”：
- 审核员可以维护自己审核职责对应的本地审核 / 审计规范，用于修正审核流程、审计口径和阻断标准。
- 审核员不默认修改被审体系执行规范、事项计划 / 设计、执行日志、结果包或主产物。
- 如确需修改执行规范，应创建规范维护事项，或额外授予体系维护员 / 规范维护员角色，并记录原因、影响范围和复审入口。
5.6 写模板
模板开头必须包含：
- 创建人员。
- 文件职责。
- 管理规范 / 模板。
- 引用文件。
- 记录方式。
模板应尽量使用占位符，不写具体项目内容。
5.7 建立目录导读
目录导读必须列出：
- 本体系定位。
- 文件清单。
- 推荐使用顺序。
- 哪些文件是规范。
- 哪些文件是模板。
- 哪些文件是创建指南。
新增或删除文件时同步更新目录导读。
5.8 自测创建
体系创建完后，必须至少找一个测试项目按环境创建指南完整实例化一次。
自测要检查：
- 指南是否足够，不靠记忆也能创建。
- 必需文档是否齐全。
- 本地规范是否只引用 common，不复制正文。
- 起因、计划、执行、审计、问题是否能串起来。
- 是否混入其他项目内容。
- 是否有绝对路径或乱码。
- 是否按体系创建校验方案跑过，且校验结论写入审计报告。
发现指南漏项，应修 common 指南和模板，而不是只修测试项目。
6. 体系文档命名建议
默认命名：
common/<体系>-doc/
目录导读.md
<体系>规范.md
<体系>环境创建指南.md
<体系>总纲模版.md
<体系>设计模版.md
<体系>执行日志模版.md
<体系>审核规范.md
<体系>审计报告模版.md
<体系>问题记录模版.md
如果该体系更适合“计划”而不是“设计”，可使用 <体系>计划模版.md。
如果设计和计划职责高度重叠，应合并，不要人为拆成两个模板。
7. 体系启用后的项目本地文件
项目启用体系后，通常应创建：
- 本地体系规范：引用 common 规范，记录项目补充。
- 本地体系审核规范：引用 common 审核规范，记录项目补充。
- 总纲账本。
- 设计 / 计划账本。
- 执行日志。
- 审计报告。
- 问题记录。
- 必要的数据 / 结果目录。
项目本地规范默认可以很短，不复制 common 正文。
8. 什么时候不要新增体系
以下情况不应创建新体系：
- 只是一个单次任务，用项目事项即可管理。
- 只是某个体系下的一个模块，应放在现有体系内。
- 没有独立执行流程。
- 没有独立审计方式。
- 没有多个项目复用价值。
- 只是为了放几个文件而建文件夹。
9. 常见错误
- 只写规范，不写环境创建指南。
- 模板和规范职责混在一起。
- 创建指南依赖 AI 记忆，不够可执行。
- 本地项目规范复制 common 正文，后续产生冲突。
- 审计只审结果，不审设计 / 计划。
- 执行日志只写开始和结束，不记录中间关键节点。
- 结果包没有入口，后续找不到。
- 把某个项目的历史路径、样本、结论写进 common。
- 为了严谨加太多 gate，导致体系难用。
10. 完成标准
一个新体系创建完成，至少满足：
- common 下有独立体系目录。
- 目录导读存在。
- 体系规范存在。
- 环境创建指南存在。
- 核心模板齐全。
- 审核规范和审计报告模板存在。
- 问题记录模板存在。
- 已用测试项目完整实例化过。
- 自测发现的问题已回补到 common 文档。
- 未发现具体项目内容污染 common。
- 环境创建指南包含体系创建校验方案，且测试项目已按该方案校验通过。
11. 一句话
创建新体系的核心不是多建文件，而是让一类事项有稳定入口、可执行流程、可审计证据链、可复用模板和可闭环问题记录。
