# 体系说明

创建人员：Codex  
文件职责：说明 AI 管理体系的总体结构、核心流程、关键文档、关键角色和审计闭环。  
管理规范/模板：管理体系总说明文档；用于解释 `管理体系说明.vsdx` 的文字含义。  
引用文件：管理系统说明.md；管理体系说明.vsdx；全局规范.md；common/pro-doc/需求规范.md；common/pro-doc/需求规范.md；common/dev-doc/编码规范.md；common/exp-doc/实验规范.md。

## 1. 体系定位

本体系是一个 AI 工作流程管理体系。

它不是单纯的文件夹整理工具，而是用于管理多个 AI、多个项目、多个事项的工作闭环。

核心目标：

1. 让每个事项的背景、目标、过程、结果都可追踪。
2. 让每个 AI 的工作过程可审计。
3. 让关键数据、文档、代码、实验结果不丢失。
4. 让问题能被发现、归因、修复、复验。
5. 让人能快速看懂 AI 做过什么、为什么做、做到哪一步、是否可信。
6. 让新项目保持干净隔离，不把其他项目的路径、业务名词、历史实验和旧模块口径带入当前项目。

一句话：本体系要把 AI 的工作从“聊天驱动的临时产出”变成“可审计、可复盘、可归档、可持续迭代的事项流”。

## 2. 体系组成

体系由以下部分组成：

1. 文档管理体系。
2. 事项管理体系。
3. 执行体系。
4. 审核体系。
5. 数据存储体系。
6. 作业方法论体系。

这些部分不是彼此独立的。一个事项从开始到结束，会同时经过文档、执行、数据、审计和归档。

## 3. 核心流程

`管理体系说明.vsdx` 表达的主流程可以理解为：

```text
事项开始
-> 事项总纲
-> 事项设计 / 事项计划
-> 事项执行流程：N 个步骤
-> 执行 AI 执行步骤
-> 工作日志 / 中间数据 / 结果数据
-> 记录文档 / 归档数据
-> 审核 AI 审计
-> 审计报告
-> 若有问题，反向优化事项执行流程
-> 修复 / 重跑 / 复审
-> 事项完成或暂停
```

这个流程的重点不是“每一步都写很多文档”，而是关键节点必须可追踪。

## 4. 事项开始

事项开始时，必须先明确这件事为什么存在。

事项总纲负责记录：

1. 事项 ID。
2. 事项名。
3. 事项背景和由来。
4. 原理或上游依据。
5. 创建人员。
6. 创建时间。
7. 希望达成的目标。
8. 当前状态。
9. 当前结论。
10. 事项来源聊天记录。

事项总纲是事项治理入口。后续所有计划、执行、日志、结果、审计都应能回到对应事项。

## 5. 事项过程

事项过程由一个或多个步骤组成。

每个步骤至少应记录：

1. 步骤 ID。
2. 所属事项 ID。
3. 步骤名。
4. 执行人员或执行 AI。
5. 创建时间。
6. 本步骤目标。
7. 输入。
8. 输出。
9. 当前状态。
10. 当前结论。
11. 步骤来源聊天记录。

步骤可以是：

1. 写需求。
2. 写代码。
3. 做实验。
4. 跑数据。
5. 做案例分析。
6. 审核结果。
7. 修复问题。
8. 归档结果。

## 6. 执行体系

执行体系负责真正做事。

执行 AI 可以承担：

1. 需求整理。
2. 代码实现。
3. 实验执行。
4. 数据处理。
5. 案例分析。
6. 文档归档。
7. 结果总结。

执行 AI 的产出不能只停留在聊天中。重要结果必须落到：

1. 正式文档。
2. 结果数据。
3. 日志。
4. 归档目录。
5. 数据库或表。
6. 审计报告可引用的位置。

## 7. 审核体系

审核体系负责判断事项是否真的做对。

审核 AI 要检查：

1. 事项目标是否清楚。
2. 事项设计是否能满足目标。
3. 执行过程是否按设计走。
4. 数据和产物是否对得上。
5. 代码或实验是否有真 bug。
6. 是否存在未来函数、样本污染、流程错位、口径替换。
7. 结论是否被过读。
8. 结果是否方便人复核。

审核原则：

1. 抓真问题。
2. 不吹毛求疵。
3. 不把边角料升级成阻断。
4. 不为了“更严谨”层层加码。
5. 只要问题会影响目标、结论、数据、流程或可复现性，就必须指出。

如果审计发现阻碍性问题，执行者必须修复并重新执行，直到问题关闭。

## 8. 数据存储体系

数据存储体系负责保存事项过程和结果。

需要保存的数据包括：

1. 中间数据。
2. 结果数据。
3. 样本数据。
4. 图片。
5. 图表。
6. 日志。
7. 数据库表。
8. 数据 schema。
9. 数据索引。

数据存储的目标：

1. 后续能找到。
2. 后续能复核。
3. 后续能复跑。
4. 后续能判断数据来源和生成方式。

临时数据、过程数据、正式结果数据、归档数据应分开管理。

## 9. 作业方法论体系

作业方法论体系负责沉淀“怎么做事”。

常见方法论包括：

1. 实验怎么设计。
2. 需求怎么写。
3. 代码怎么写。
4. 数据怎么存。
5. 案例怎么分析。
6. 审核怎么做。
7. 问题怎么归因。
8. 结果怎么汇报。

方法论不是空泛原则，应来自实际事项中的有效经验和踩坑教训。

## 10. 文档管理体系

所有非临时文件创建后，文件头部应包含：

1. 创建人员。
2. 文件职责。
3. 书写管理规范或模板。
4. 引用的关键文件。

每个文件夹应有导读文档或索引文档，记录本目录下关键文件的作用。

新增正式文件后，应同步更新所在目录导读或索引。

文档引用其他文档时，应尽量使用相对路径，避免依赖单机绝对路径。

## 11. common 目录

`common` 是公共规范和公共资产目录。

当前规划：

1. `pro-doc/`：需求、策略、需求相关规范。
2. `dev-doc/`：开发体系、编码、测试、自检相关规范。开发体系默认随项目创建，但开发必须绑定目标体系或目标事项；代码按 `dev/<target>-dev/` 分账，开发文档按 `dev-doc/<target>-doc/` 分账。
3. `exp-doc/`：实验体系规范和实验文档模板，包括实验总纲、实验设计、执行日志、实验存储体系创建指南、实验审核规范、审计报告、问题记录。项目内应创建本地 `实验规范.md` 和 `实验审计规范.md`，分别引用 common 全局规范。
4. `data-doc/`：数据存储、数据样本、数据库表、图片资产相关规范。
5. `ana-doc/`：案例分析体系规范和模板，包括案例分析规范、案例审核规范、案例总纲、案例分析设计、案例执行日志、案例存储体系创建指南、案例审计报告、案例问题记录。
6. `project-doc/`：项目规范和项目创建模板，包括项目规范、项目配置清单、项目事项总纲、项目事项计划、项目执行日志、项目事项审计报告、项目问题记录、项目变更记录。
7. `全局规范.md`：所有 AI 都必须遵守的全局规则。
8. `体系创建流程.md`：创建新体系时使用的通用流程和完成标准。

公共规范应尽量通用，不绑定某一个具体项目。

### 11.1 实验事项

实验是一种事项类型。

实验事项应继承事项总纲和事项计划的基本字段，但在实验体系里具体落为：

1. `实验规范`：项目本地实验规范，引用 common 的 `实验规范.md`，默认可以没有额外补充规则。
2. `实验审计规范`：项目本地审计规范，引用 common 的 `实验审核规范.md`，默认可以没有额外补充规则。
3. `实验总纲`：项目级实验总账本，记录所有实验背景、由来、原理、目标、状态、当前结论和来源聊天记录。
4. `实验设计`：项目级实验设计账本，合并原“实验设计”和“实验计划”的职责，记录所有实验验证方法和执行步骤。
5. `实验执行日志`：项目级执行账本，记录所有实验实际执行过程。
6. `实验存储体系`：项目级数据存储合同，说明实验数据放哪、怎么存、怎么读、有哪些表和字段。
7. `实验审计报告`：记录设计审核和执行审核结果。
8. `实验问题记录`：记录非审计来源实验问题闭环；审计问题只在需要跨轮跟踪时记录索引。
9. 结论回写：作为实验收尾动作，记录到实验总纲和实验审计报告，不作为必备独立模板。

结果包本身是产物目录，不作为必备模板文档。结果包入口回写到实验总纲和实验设计，结果包内部资产按项目内实验存储体系登记。

实验有两个必须审核的关口：

1. 设计审核：实验设计必须由审核员审核通过后，才能进入执行。
2. 执行审核：实验执行和结果包必须由审核员审核通过后，实验才能标为完成。

审核不通过时，应回到对应阶段修改并复审，不能用“已跑完”代替“已完成”。

### 11.2 案例分析事项

案例分析是一种事项类型。
案例分析事项用于把一套方法论、笔记、规则、现象或样本，落实到具体案例上做全流程复盘、证据链分析和人工可审计记录。

案例分析事项应继承事项总纲和事项计划的基本字段，但在案例分析体系里具体落为：

1. `案例分析规范`：项目本地案例分析规范，引用 common 的 `案例分析规范.md`，默认可以没有额外补充规则。
2. `案例审核规范`：项目本地案例审核规范，引用 common 的 `案例审核规范.md`，默认可以没有额外补充规则。
3. `案例总纲`：项目级案例分析总账本，记录所有案例分析事项的背景、来源聊天记录、方法论来源、目标、状态、结论和结果入口。
4. `案例分析设计`：项目级案例设计账本，记录案例选择口径、分析流程、证据要求、图片要求、数据产物和验收方式。
5. `案例执行日志`：项目级执行账本，记录每个案例从候选来源、筛选、关键判断、操作动作、结果复核到结论回写的关键节点。
6. `案例存储体系`：项目级案例数据存储合同，说明案例数据、图片、结果包、表结构和读取方式。
7. `案例审计报告`：记录案例设计审核、执行审核、证据链审核和复审结果。
8. `案例问题记录`：记录非审计来源案例问题、影响、修复建议和复验结论；审计问题只在需要跨轮跟踪时记录索引。

案例分析有两个必须审核的关口：

1. 设计审核：案例分析设计必须由审核员确认目标、口径、来源聊天记录、方法论和证据要求一致后，才能进入执行。
2. 执行审核：案例执行日志、结果包、图片证据、关键数据和结论必须由审核员确认可追踪后，案例事项才能标为完成。

案例分析必须同时包含设计流程和执行流程。
设计流程负责冻结目标、案例选择口径、分析步骤、证据要求和验收方式。
执行流程负责按冻结设计逐案例执行，并保留候选来源、入选理由、背景证据、关键判断、操作动作、结果复核、数据路径和图片路径。
执行日志不能只写 summary，必须让审核员能沿着单个案例的证据链重走一遍。

案例分析的核心不是“写总结”，而是保留完整痕迹：为什么选这个案例、每一步看了什么证据、用了什么规则、做了什么判断、结果如何、结论有没有过读。

案例结果包本身是产物目录，不作为必备模板文档。结果包入口、核心表、图片目录和审计结论应回写到案例总纲、案例分析设计、案例执行日志和案例审计报告。

### 11.3 开发事项

开发是一种事项类型，也是一套默认随项目创建的基础体系。

开发体系不单独承载业务目标，它必须绑定其他体系或目标事项。常见绑定关系：

1. 需求开发：实现需求体系产出的需求、正式需求和业务规则。
2. 实验开发：实现实验脚本、数据处理、回测、图表、校验工具。
3. 案例分析开发：实现案例图表、账本、回放、审计辅助工具。
4. 项目工具开发：实现项目初始化、索引、检查、归档工具。

开发目录按目标体系分账：

1. 代码目录：`dev/<target>-dev/`。
2. 测试目录：`dev/<target>-dev/test/`。
3. 开发文档目录：`dev-doc/<target>-doc/`。

例如：

1. 需求开发：`dev/pro-dev/`，`dev/pro-dev/test/`，`dev-doc/pro-doc/`。
2. 实验开发：`dev/exp-dev/`，`dev/exp-dev/test/`，`dev-doc/exp-doc/`。
3. 案例分析开发：`dev/ana-dev/`，`dev/ana-dev/test/`，`dev-doc/ana-doc/`。

开发事项遵守 `common/dev-doc/编码规范.md`。轻量代码可以走轻流程；多模块、长流程、公共模块、重跑缓存、性能风险或失败代价高的开发，必须先写代码编写方案，方案审核通过后再实现。

开发审核覆盖方案审核、实现审核和测试验收。审核员发现的问题主记录写开发审计报告；非审计人员发现的问题进入开发问题记录或对应体系的问题记录。

## 12. 项目目录

每个项目一个文件夹。

每个项目原则上一个独立 git 仓库。

项目相关的需求、代码、实验、数据、案例、结果，都应放在对应项目目录下。

公共规范放在 `common`，项目特有内容放在项目目录。

## 13. 事项状态

建议统一使用以下状态：

1. `未开始`：事项已登记，还未执行。
2. `进行中`：正在执行。
3. `待审核`：执行完成，等待审核。
4. `审核中`：审核 AI 正在审计。
5. `需修复`：审核发现阻碍性问题。
6. `修复中`：执行 AI 正在修复。
7. `完成`：审核通过，事项闭环。
8. `暂停`：因数据、需求、资源或方向问题暂停。
9. `取消`：事项不再执行。

状态必须能解释原因。不能只写“暂停”或“完成”，不写为什么。

## 14. 问题闭环

问题应至少分为：

1. 需求问题。
2. 代码问题。
3. 数据问题。
4. 流程问题。
5. 实验设计问题。
6. 审计问题索引。
7. 待归因问题。

审计人员发现的问题，主记录写入对应审计报告；问题记录只在需要跨轮跟踪或跨事项汇总时保留索引。

非审计人员发现的问题，主记录写入对应问题记录。

每个问题应记录：

1. 问题 ID。
2. 所属事项。
3. 问题类型。
4. 证据。
5. 影响。
6. 修复建议。
7. 当前状态。
8. 复验结论。

问题关闭必须有复验，不应只因为“已经改了”就关闭。

## 15. 反向优化流程

当审计发现流程本身有问题时，不只修当前事项，还要反向优化流程。

例如：

1. 需求总是写不清，就补需求规范。
2. 代码总是散修，就补编码方案规范。
3. 实验总是过读，就补实验规范。
4. 数据总是丢，就补数据存储规范。
5. 审核总是吹毛求疵，就补审核规范。

反向优化的目标是减少同类问题重复发生。

## 16. 当前已有公共规范

当前已建立：

1. `体系创建流程.md`
2. `pro-doc/目录导读.md`
3. `pro-doc/需求规范.md`
4. `pro-doc/需求环境创建指南.md`
5. `pro-doc/需求审核规范.md`
6. `pro-doc/需求规范.md`
7. `pro-doc/需求总纲模版.md`
8. `pro-doc/需求设计模版.md`
9. `pro-doc/需求方案文档范本.md`
10. `pro-doc/需求架构文档范本.md`
11. `pro-doc/需求模块说明文档范本.md`
12. `pro-doc/需求核心流程文档范本.md`
13. `pro-doc/需求执行日志模版.md`
14. `pro-doc/需求审计报告模版.md`
15. `pro-doc/需求问题记录模版.md`
16. `pro-doc/需求文档范本.md`
17. `dev-doc/目录导读.md`
18. `dev-doc/编码规范.md`
19. `dev-doc/开发环境创建指南.md`
20. `dev-doc/编码方案范本.md`
21. `dev-doc/开发事项总纲模版.md`
22. `dev-doc/开发事项计划模版.md`
23. `dev-doc/开发执行日志模版.md`
24. `dev-doc/开发审计规范.md`
25. `dev-doc/开发审计报告模版.md`
26. `dev-doc/开发问题记录模版.md`
27. `exp-doc/实验规范.md`
28. `exp-doc/目录导读.md`
29. `exp-doc/实验总纲模版.md`
30. `exp-doc/实验设计模版.md`
31. `exp-doc/实验执行日志模版.md`
32. `exp-doc/实验存储体系创建指南.md`
33. `exp-doc/实验审核规范.md`
34. `exp-doc/实验审计报告模版.md`
35. `exp-doc/实验问题记录模版.md`
36. `project-doc/项目规范.md`
37. `project-doc/项目环境创建指南.md`
38. `project-doc/项目规范模版.md`
39. `project-doc/项目配置清单模版.md`
40. `project-doc/项目事项总纲模版.md`
41. `project-doc/项目事项计划模版.md`
42. `project-doc/项目执行日志模版.md`
43. `project-doc/项目审计规范.md`
44. `project-doc/项目事项审计报告模版.md`
45. `project-doc/项目问题记录模版.md`
46. `project-doc/项目变更记录模版.md`
47. `ana-doc/目录导读.md`
48. `ana-doc/案例分析规范.md`
49. `ana-doc/案例分析环境创建指南.md`
50. `ana-doc/案例存储体系创建指南.md`
51. `ana-doc/案例总纲模版.md`
52. `ana-doc/案例分析设计模版.md`
53. `ana-doc/案例执行日志模版.md`
54. `ana-doc/案例审核规范.md`
55. `ana-doc/案例审计报告模版.md`
56. `ana-doc/案例问题记录模版.md`

实验体系不再强制提供实验导读模板；项目实验入口由项目总索引或 `实验总纲.md` 承担。项目默认不创建单实验独立总纲、独立设计或独立执行日志文件，而是追加到项目级三本账本。

后续建议补齐：

1. `data-doc/数据存储规范.md`
2. `审计规范.md`
3. `事项管理规范.md`

## 17. 体系的关键判断标准

一个事项做得好不好，不只看有没有产物。

应看：

1. 目标是否清楚。
2. 过程是否可追踪。
3. 数据是否可复核。
4. 结论是否有边界。
5. 审计是否能发现真问题。
6. 问题是否能闭环。
7. 成果是否被归档。
8. 人是否能快速理解前因后果。

## 18. 一句话

本体系的核心是：用事项总纲记录起因和目标，用事项计划管理步骤，用执行体系产出结果，用数据存储体系保存证据，用审核体系发现真问题，用反向优化机制改进流程，最终让 AI 工作可审计、可复盘、可归档、可持续迭代。