管理体系说明

管理体系核心

全局管理

文件管理（文件增，删，改）

文件创建

1. 每一个文件创建以后，文件（临时文件除外）的头部必须包含以下内容
   1）创建人员的签名
   2）该文件的职责，负责记录什么内容
   3）该文件的书写管理规范，以及对应模版
   4）该文件引用的其他关键文件（相对路径）
   5）该引用该文件的，其他文件也要引用它
   6）该文件的记录方式，是append，还是其他，最新的内容是否在最后面
2. 每一个文件创建以后，所在文件夹里的导读文件必须同步更新

3. 每个文件夹里都应该有一个导读文档，该导读文档记录了所有该文件夹里文件的作用，以及该目录里所有子文件夹的作用，所以每一个文件创建以后也应该更新该导读文档

   文件删除

4. 文件改名，或者文件改路径可以认为文件删除和文件增加的组合
5. 所有引用该文件的，文件都要改对（要改路径，要么把引用去掉）
6. 对应的文件夹里导读文档也要更新

文件修改

1. 修改文件不得破坏文件本身的结构
2. 修改完要整体检查一下，减少重复的地方，不一致的地方要修对，有问题可以反馈
3. 文件里不得有任何绝对路径

git管理

AI权限管理

1. 所有的AI在项目里的权限必须跟着角色权限走，当同时拥有多个角色的时候，权限取角色的并集
2. 所有的AI拥有项目的所有文件的和文件夹的读权限
3. 每一个角色拥有该角色绑定的文件夹和文件夹里的文件和子文件夹的写权限，非绑定的文件夹没有写权限
4. 每一个AI在一个项目里有自己的工作目录，AI拥有该工作目录下的所有权限
5. 审核员在核验的时候有证据链上的所有的脚本和代码的执行权限

6. 比较特殊的两个角色是：开发和审核员，这两个角色是跟别的体系走的，同时审核员基本上面对任何一个角色都1对1的情况，比如需求体系，应该有 需求，需求审核员,需求开发，以及需求开发审核员。

   AI角色介绍

7. 开发：绑定路径 /dev/对应的体系 /dev-doc/对应的体系，比如:需求开发 /dev/pro-dev /dev-doc/pro-doc, 实验开发 /dev/exp-dev /dev-doc/exp-doc
8. 需求 ：绑定路径 /pro-doc
9. 实验员：绑定路径/exp-doc /exp-data
10. 案例分析员：绑定路径/ana-doc /ana-data
11. 项目管理员：绑定路径项目根目录/
12. 审核员：审核员必须是对应上面的角色之一的审核员，不绑定业务执行目录，主写对应审核体系的审核 / 审计报告；可维护自己审核职责对应的本地审核 / 审计规范，但不得默认修改被审体系执行规范、事项计划、执行日志、结果包或主产物。比如需求审计员主写 /pro-doc/需求审计报告.md 并可维护 /pro-doc/需求审核规范.md；需求开发审核员主写对应开发审计报告，并可维护对应开发审计规范。
13. 管理管理员：绑定路径管理根目录和 manage-doc/，负责创建项目、启用体系、创建角色、创建会话、更新 MB-X、同步技能和修复框架问题；必须写入管理事项、管理执行日志和管理变更记录。
14. 管理观察员：管理管理员的审核员，主写 manage-doc/管理审计报告.md，可在 manage-doc/管理问题记录.md 写审计问题索引或观察员反馈，可维护管理体系中的审计口径；不得直接修改被审计的管理配置、执行日志和变更记录。

AI工作空间管理

AI 工作空间目录统一使用 ai-<name>/ 命名，<name> 使用稳定英文名或拼音小写。例如 Andrew 的工作空间是 ai-andrew/，Foo 的工作空间是 ai-foo/。禁止直接使用 Andrew/、Foo/ 这类裸 AI 名目录，避免和体系目录、普通业务目录混淆。

规范文档的修改

任何规范文档的修改必须遵守以下原则：
1. 必须有权限修改
2. 修改完必须自检是否跟相关的规范文档有冲突，或者重复的地方
3. 对应的审核员也必须审核这次修改

全局存储体系

设计原则：
1. 全局存储体系里的表，只能增加字段，不得改和删除字段（主要针对已经上线了，被大家使用起来的表）
2. 理论上全局存储体系里的数据，不得有删和改的操作（主要针对已经上线了，被大家使用起来的表）
3. 只有整个体系管理员和被客服授权的AI，才可以修改或者增全局存储体系里的表schema和表里数据
全局存储体系应该有两个文档
1. 全局存储体系.md:该文档介绍清楚，目前有几个数据源，每个数据源是什么数据，之间的关系是什么，如果是数据库，应该包含数据源的账号密码，包括使用全局数据存储体系的规范
2. 全局数据格式.md: 该文档只做一件事，描述清楚每一个全局的表的schema,精确到每一个字段

体系管理员必须具备的能力

创建一个项目

体系管理员必须能创建一个项目，并植入基础的项目管理体系

在项目里创建一个体系

体系管理员必须能在一个项目里初始化一个体系，要求体系一旦初始化完，指定对应的AI工作人员就能在该体系下，进行工作了，但是该AI工作人员也可以改
该体系下的一些东西，这个完全按自己的期望来，但是不得违反全局规范和对应体系规范

在项目里创建一个AI工作空间

体系管理员可以创建一个AI工作空间其中包含：
1. 创建一个全新的AI聊天窗口，并初始化角色，以及告诉他去阅读哪些工作文档
2. 可以使用一个旧的聊天窗口，但是同样需要初始化角色，以及告诉他去阅读哪些工作文档
3. 赋予AI对应的技能，到时候使用对应的AI窗口直接使用对应的技能来跟他聊天

一旦完成上面3项目任务，一个AI就能在具体体系下和项目下进行工作了

文件夹管理

common

说明：所有公共文件和文档都存放在common文件夹其中包括
1.需求和策略相关的文档存放在pro-doc文件夹比如：
pro-doc/需求规范.md
2.代码相关的的文档存放在dev-doc文件夹比如：
dev-doc/编码规范.md
3.实验相关的文档存放在exp-doc文件夹比如：
exp-doc/实验规范.md
4.数据相关的文档存放在data-doc文件夹比如：
data-doc/数据存储.md
5.案例分析的文档存放在ana-doc文件夹比如：
ana-doc/案例分析规范.md
6.全局规范.md 该文件负责存储所有全局规范和全局约定，所有 AI 都应该遵守该文档
7.manage-doc 存放管理体系规范和模板，用于约束管理根目录中的管理会话、管理管理员、管理观察员和管理级事项。

项目文件夹

设计核心：体系文件夹，包括项目文件夹都属于整个项目的公共文件夹，它们属于项目组里大家共有的东西，
但是AI工作空间，不属于项目公有的东西，AI工作空间属于自己私产，包括最后项目打包上线也不会涵盖AI工作空间的内容。

说明： 一个项目一个文件夹，一个项目一个git仓库，项目相关的所有的文件都存放到对应的项目文件夹
每一个项目根目录下都有一个项目总览.md 该文档里应该记录下来项目的基本信息比如：
1. 项目名，项目创建时间等
2. 项目目标
3. 时间周期
4. 项目的介绍以及背景
5. 其他

项目配置清单

在项目文件夹下有一个项目配置清单.md文件
里面的格式大概如下：
1.AI名：Andrew
角色：开发，实验员; //同时是开发的审核员以及实验员的审核员
工作空间：ai-andrew/
2.AI名：Foo
角色: 开发-审核员，实验员-审核员; //同时是开发的审核员以及实验员的审核员
工作空间: ai-foo/

体系文件夹

1.每一个项目每添加一个体系，那么该项目文件夹里就应该包含该体系所需要的文件夹

已有体系的文件夹说明

1.开发体系
/dev-doc : 存放所有开发相关的文档
/dev:存放所有的代码
/dev/体系文件夹/test: 存放所有测试代码
开发体系比较特殊，因为单独开发没有存在的意义，所以开发是要绑定其他体系的，比如需求开发，实验开发，那对应的文件夹管理就是
/dev/pro-dev/ 需求开发代码 /dev/pro-dev/test 需求测试代码 /dev-doc/pro-doc/ 需求开发文档
2.需求体系
/pro-doc: 存放所有的需求文档
3.实验体系
/exp-doc：存放所有的实验文档
/exp-data：存放所有的实验数据
/exp-data/img：存放所有的实验数据的图片
4.案例分析体系
/ana-doc：存放所有的实验文档
/ana-data：存放所有的实验数据
/ana-data/img：存放所有的实验数据的图片
5.项目体系
直接使用项目根目录

所有文件夹里都有/tmp文件，用来存放对应的临时文件（比如临时文档和临时代码）

AI工作空间

每一个AI，在项目里有一个自己的工作空间，比如AI名叫Andrew,那么就在
项目目录下创建一个 ai-andrew/ 文件夹，该文件夹下就是 AI 的工作空间。工作空间目录必须统一使用 ai-<name>/ 前缀。
1.AI工作空间下应该有一个 工作说明.md 通过该文档能够快速了解如下几点
-- 他的工作职责范围
-- 他的工作环境，以及工作方式和流程
2.AI工作空间里应该还有一个 叫 项目问题反馈.md 文档，该文档是让AI反馈在项目里协作问题的文档，该文档应该也是按append方式进行书写的，这个文档有几个主要作用
-- 汇报AI在整个工作流程里遇到的重要问题（该问题一定要是影响整个项目或者体系内部进展的，小问题，不重要的问题不要在这里汇报）
-- 如果AI是审核员，发现自己审核的事项出现的问题，复返修复多次还是会出现同一个问题（最好大于等于3次），就需要汇报到这个文档里

data

data里存放全局统一的数据源

体系说明

已经有的体系模版

核心：项目体系和开发体系是项目创建好就必须自带的体系

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

管理体系是 MB-X 管理根目录的体系，不是业务子项目体系。它用于纳管管理会话：管理管理员负责执行管理动作，管理观察员负责审核管理管理员。管理体系公共规范和模板放在 common/manage-doc/；实例化后的管理账本放在管理根目录 manage-doc/。

体系组件

核心目标和原则

-- 可审计，任何人都可以审计在该体系中，该每一个AI的每一个进行中或者历史事项全景包括：
1. 事项的状态
2. 事项的前因，中间关键节点，结果
3. 可以审计和追踪 整个事项的关键步骤和节点和结果，从而挖掘该事项是否进行的有问题，结论是不是错了，流程有没有问题，是否方向错误，是否有bug等等
-- 所有的审计内容在不加大太多工作量的情况下，尽量的要人方便阅读和追踪
-- 数据要留档，所有的成果最后能留档，而不是最终会遗忘消失
1. 该存数据的要存到对应的数据文档或者数据库里
2. 该记录到文档，记录到文档
-- 流程要清晰，这个体系在运作的时候有几个流程，每一个流程谁负责做什么要清晰，其中流程必须包括如下：
1. 该事项流程的起因，背景
2. 流程的关键节点必须可审计（有日志，可复现）
3. 事项的结论
4. 事项的审计
-- 如果审计出了问题，执行者必须把问题修复，并重新执行，直到审计没有任何阻碍性问题或者影响结论的问题为止
-- 事项不能偏离初衷
1.最重要的聊天记录一定要在事项总纲的背景里（因为我发现经常实验员设计的实验跟我跟实验聊天里的要求是不一致的，但是因为审计人员也不知道或者审计要求里
没有强调，导致了聊天的内容 跟实际的实验设计不一致没人提出来，最后做的所有东西都是错的）

1. 体系说明文档，整个体系总介绍文档其中包括：
   -- 核心流程
   -- 每一个关键文档的作用

2. 事项总纲：用来记录该体系一个完整事项，其中必须包括如下：
   1）这个事项的背景由来，原理
   2）这个事项的创建人员
   3）这个事项的创建时间精确到秒
   4）这个事项的希望达成的目标
   5）这个事项的状态：暂停，进行中，未开始，完成，取消
   6）这个事项当前结论（完成了结论是什么？暂停是因为什么？取消是因为什么？）
   7）唯一个事项id(id长度不要太长）
   8）事项名
   9）事项由来的完整聊天记录

3. 事项计划：用来记录一个事项的具体每一个步骤，其中包括如下：
   1）每一个步骤所属的事项名和id
   2）每一个步骤的执行人员
   3）每一个步骤创建时间精确到秒
   4）每一个步骤希望达成的目标
   5）每一个步骤状态：暂停，进行中，未开始，完成，取消
   6）每一个步骤当前结论（完成了结论是什么？暂停是因为什么？取消是因为什么？）
   7）唯一步骤id
   8）步骤名
   9）对应步骤由来的完整聊天记录（如果没有可以为空）

4. 审计
   -- 审计的范围包括：
   1）事项，和事项设计（比如实验目标，和对应的实验设计，有些时候是有问题的）
   2）事项的执行（执行的过程，或者结论也可能出问题）

1. 工作日志:

2. 数据归档:

3. 临时文件

4. 存储体系
   存储体系文档记录了

5. 整个体系的数据存储地址，以及各个表的schema说明，详细到每一个字段的介绍
6. 图片应该怎么存储
7. 数据样本怎么存储到数据样本文档

审核员体系

审计要求
1. 事项整体对，关键流程对，无关紧要的细节不要吹毛求疵，不要加大事项的执行难度
2. 好好分析事项的目标和背景，如果觉得需要防止未来函数，一定要严格审核该事项在执行中是否防止了未来函数
3. 事项的设计，能满足设计的目标就行，无关紧要的细节不要吹毛求疵，不要加大事项拆解步骤或者设计的难度
4. 如审计很复杂，可以分步骤进行审计，并要求把审计流程文档记录下来，按流程进行审计，可以按需起subagent
5. 审计事项的设计和执行的过程是否和事项记录的聊天记录的需求一致，如果不一致一定要反馈出来
6. 审计过程发现文件有乱码一定要报告出来
7. 审计员不仅要审计事项的进行是否合理是否满足客户需求，还要审计事项的设计是否合理
8. 审计员发现自己审核的事项出现的问题，复返修复多次还是会出现同一个问题（最好大于等于3次），就需要汇报到自己项目里工作空间的 项目问题反馈.md 里，记录的信息要主要详细，保证项目管理员
到时候能追踪到具体的事项id以及有问题的步骤等等
9. 如果审核员发现的事项问题，反复修改多次还是反复出现同一个问题，那么在反馈内容里最好能附带解决问题的建议，甚至问题很麻烦的时候可以给完整的解决问题的方案(比如在修代码bug的时候的 代码修复方案）
10. 审核员在审核事项的时候，要以事项为单元（也就是以对应的体系的总纲文档里的一个目标为单元）来整体审查，不能单审查事项的某一个步骤，如在审查过程中发现关键节点有缺失也应该反馈成问题，但是不允许层层加码和吹毛求疵。
所有的审核文档里都检查下一定要保证以下原则：
1. 保证审核的内容的主要内容没问题
2. 对边角料非主要内容，不要吹毛求疵，层层加码，加大执行的难度
3. 一定要考虑执行者的执行难度问题，不要放大小问题

技能

1. 文档文件（不包含数据，代码等文件）创建，删除，修改技能(属于全局规范.md);参考章节 文件管理（文件增，删，改）
   下面所有的技能都不得违反全局规范.md的要求
2. 项目创建技能 以及 项目体系创建技能; 参考 章节体系管理员必须具备的能力 （属于common\project-doc\项目环境创建指南.md)
   下面所有的技能都不得违反全局项目规范.md的要求 和 本地项目规范.md的要求
3. AI工作空间创建 以及 AI角色分配技能; 参考 章节体系管理员必须具备的能力（属于common\ai-workplace\AI工作空间创建指南.md)
4. 实验技能（包括实验设计，到实验执行）; （属于common\exp-doc\实验规范.md 以及 项目本地 exp-doc\实验规范.md 两个共同作用的技能 )
5. 实验审核技能（包括实验设计审核，以及实验全流程审核）;（属于common\exp-doc\实验审核规范.md 以及 项目本地 exp-doc\实验审计规范.md 两个共同作用的技能 )
6. 需求文档编写技能(包括需求方案文档，以及需求文档修改和书写）;（属于common\pro-doc\需求规范.md 以及 项目本地 pro-doc\需求规范.md 两个共同作用的技能 )
7. 需求审核技能(包括需求方案文档以及需求文档修的审核）;（属于common\pro-doc\需求审核规范.md 以及 项目本地 pro-doc\需求审核规范.md 两个共同作用的技能 )
8. 写代码技能（包括编码方案设计，到代码书写）;（属于common\dev-doc\编码规范.md 以及 项目本地 dev-doc\编码规范.md 两个共同作用的技能 )
9. 代码审核技能（包括编码方案设计到代码书写的审核）;（属于common\dev-doc\开发审计规范.md 以及 项目本地 dev-doc\开发审计规范.md 两个共同作用的技能 )
10. 案例分析技能（包括案例分析设计，案例分析全流程）;（属于common\ana-doc\案例分析规范.md 以及 项目本地 ana-doc\案例分析规范.md 两个共同作用的技能 )
11. 案例分析审核技能（包括案例分析设计，案例分析全流程审计）;（属于common\ana-doc\案例审核规范.md 以及 项目本地 ana-doc\案例审核规范.md 两个共同作用的技能 )
12. 管理体系创建和管理控制技能（包括管理根目录初始化、项目创建、体系启用、角色创建、会话创建、MB-X 更新和 skill 同步）;（属于common\manage-doc\管理体系规范.md、common\manage-doc\管理环境创建指南.md 与 MB-X 管理类 skill 共同作用的技能 )
13. 管理观察审核技能（包括管理事项计划审核、执行审核、变更审核、框架更新审核和复审）;（属于common\manage-doc\管理体系规范.md、common\manage-doc\管理审计报告模版.md 与管理观察员工作说明共同作用的技能 )

体系特殊说明

实验体系目前固定成如下：
1. 实验员和实验-开发员目前固定成一个ai
2. 实验员的审核员和 实验-开发员的审核员 也都固定成一个ai, 这个ai对实验的审核 以及 实验开发员 的审核都统一记录在 exp-doc/实验审计报告.md 里
案例分析体系目前固定成如下：
1. 案例分析员和案例分析员-开发员目前固定成一个ai
2. 案例分析员的审核员和 案例分析员-开发员的审核员 也都固定成一个ai, 这个ai对案例分析员的审核 以及 案例分析员开发员 的审核都统一记录在 ana-doc/案例审计报告.md 里

最后因为目前3个体系都需要开发员，但是两个体系的开发员的审核都记录到了别的地方，所以只有需求-开发员、项目工具开发员等独立开发事项的审计员的审计报告会记录到 dev-doc/开发审计报告.md 文档里