每个文件夹里都应该有一个导读文档，该导读文档记录了所有该文件夹里文件的作用，以及该目录里所有子文件夹的作用，所以每一个文件创建以后也应该更新该导读文档
比较特殊的两个角色是：开发和审核员，这两个角色是跟别的体系走的，同时审核员基本上面对任何一个角色都1对1的情况，比如需求体系，应该有 需求，需求审核员,需求开发，以及需求开发审核员。
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工作空间其中包含：
1. 创建一个全新的AI聊天窗口，并初始化角色，以及告诉他去阅读哪些工作文档
2. 可以使用一个旧的聊天窗口，但是同样需要初始化角色，以及告诉他去阅读哪些工作文档
3. 赋予AI对应的技能，到时候使用对应的AI窗口直接使用对应的技能来跟他聊天
一旦完成上面3项目任务，一个AI就能在具体体系下和项目下进行工作了
说明：所有公共文件和文档都存放在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 都应该遵守该文档
设计核心：体系文件夹，包括项目文件夹都属于整个项目的公共文件夹，它们属于项目组里大家共有的东西，
但是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名叫Andrew,那么就在
项目目录下创建一个 ai-andrew/ 文件夹，该文件夹下就是 AI 的工作空间。工作空间目录必须统一使用 ai-<name>/ 前缀。
1.AI工作空间下应该有一个 工作说明.md 通过该文档能够快速了解如下几点
-- 他的工作职责范围
-- 他的工作环境，以及工作方式和流程
2.AI工作空间里应该还有一个 叫 项目问题反馈.md 文档，该文档是让AI反馈在项目里协作问题的文档，该文档应该也是按append方式进行书写的，这个文档有几个主要作用
-- 汇报AI在整个工作流程里遇到的重要问题（该问题一定要是影响整个项目或者体系内部进展的，小问题，不重要的问题不要在这里汇报）
-- 如果AI是审核员，发现自己审核的事项出现的问题，复返修复多次还是会出现同一个问题（最好大于等于3次），就需要汇报到这个文档里
data里存放全局统一的数据源
核心：项目体系和开发体系是项目创建好就必须自带的体系
-- 可审计，任何人都可以审计在该体系中，该每一个AI的每一个进行中或者历史事项全景包括：
1. 事项的状态
2. 事项的前因，中间关键节点，结果
3. 可以审计和追踪 整个事项的关键步骤和节点和结果，从而挖掘该事项是否进行的有问题，结论是不是错了，流程有没有问题，是否方向错误，是否有bug等等
-- 所有的审计内容在不加大太多工作量的情况下，尽量的要人方便阅读和追踪
-- 数据要留档，所有的成果最后能留档，而不是最终会遗忘消失
1. 该存数据的要存到对应的数据文档或者数据库里
2. 该记录到文档，记录到文档
-- 流程要清晰，这个体系在运作的时候有几个流程，每一个流程谁负责做什么要清晰，其中流程必须包括如下：
1. 该事项流程的起因，背景
2. 流程的关键节点必须可审计（有日志，可复现）
3. 事项的结论
4. 事项的审计
-- 如果审计出了问题，执行者必须把问题修复，并重新执行，直到审计没有任何阻碍性问题或者影响结论的问题为止
-- 事项不能偏离初衷
1.最重要的聊天记录一定要在事项总纲的背景里（因为我发现经常实验员设计的实验跟我跟实验聊天里的要求是不一致的，但是因为审计人员也不知道或者审计要求里
没有强调，导致了聊天的内容 跟实际的实验设计不一致没人提出来，最后做的所有东西都是错的）
体系说明文档，整个体系总介绍文档其中包括：
-- 核心流程
-- 每一个关键文档的作用
事项总纲：用来记录该体系一个完整事项，其中必须包括如下：
1）这个事项的背景由来，原理
2）这个事项的创建人员
3）这个事项的创建时间精确到秒
4）这个事项的希望达成的目标
5）这个事项的状态：暂停，进行中，未开始，完成，取消
6）这个事项当前结论（完成了结论是什么？暂停是因为什么？取消是因为什么？）
7）唯一个事项id(id长度不要太长）
8）事项名
9）事项由来的完整聊天记录
事项计划：用来记录一个事项的具体每一个步骤，其中包括如下：
1）每一个步骤所属的事项名和id
2）每一个步骤的执行人员
3）每一个步骤创建时间精确到秒
4）每一个步骤希望达成的目标
5）每一个步骤状态：暂停，进行中，未开始，完成，取消
6）每一个步骤当前结论（完成了结论是什么？暂停是因为什么？取消是因为什么？）
7）唯一步骤id
8）步骤名
9）对应步骤由来的完整聊天记录（如果没有可以为空）
审计
-- 审计的范围包括：
1）事项，和事项设计（比如实验目标，和对应的实验设计，有些时候是有问题的）
2）事项的执行（执行的过程，或者结论也可能出问题）
工作日志:
数据归档:
临时文件
存储体系
存储体系文档记录了
审计要求
1. 事项整体对，关键流程对，无关紧要的细节不要吹毛求疵，不要加大事项的执行难度
2. 好好分析事项的目标和背景，如果觉得需要防止未来函数，一定要严格审核该事项在执行中是否防止了未来函数
3. 事项的设计，能满足设计的目标就行，无关紧要的细节不要吹毛求疵，不要加大事项拆解步骤或者设计的难度
4. 如审计很复杂，可以分步骤进行审计，并要求把审计流程文档记录下来，按流程进行审计，可以按需起subagent
5. 审计事项的设计和执行的过程是否和事项记录的聊天记录的需求一致，如果不一致一定要反馈出来
6. 审计过程发现文件有乱码一定要报告出来
7. 审计员不仅要审计事项的进行是否合理是否满足客户需求，还要审计事项的设计是否合理
8. 审计员发现自己审核的事项出现的问题，复返修复多次还是会出现同一个问题（最好大于等于3次），就需要汇报到自己项目里工作空间的 项目问题反馈.md 里，记录的信息要主要详细，保证项目管理员
到时候能追踪到具体的事项id以及有问题的步骤等等
9. 如果审核员发现的事项问题，反复修改多次还是反复出现同一个问题，那么在反馈内容里最好能附带解决问题的建议，甚至问题很麻烦的时候可以给完整的解决问题的方案(比如在修代码bug的时候的 代码修复方案）
10. 审核员在审核事项的时候，要以事项为单元（也就是以对应的体系的总纲文档里的一个目标为单元）来整体审查，不能单审查事项的某一个步骤，如在审查过程中发现关键节点有缺失也应该反馈成问题，但是不允许层层加码和吹毛求疵。
所有的审核文档里都检查下一定要保证以下原则：
1. 保证审核的内容的主要内容没问题
2. 对边角料非主要内容，不要吹毛求疵，层层加码，加大执行的难度
3. 一定要考虑执行者的执行难度问题，不要放大小问题
实验体系目前固定成如下：
1. 实验员和实验-开发员目前固定成一个ai
2. 实验员的审核员和 实验-开发员的审核员 也都固定成一个ai, 这个ai对实验的审核 以及 实验开发员 的审核都统一记录在 exp-doc/实验审计报告.md 里
案例分析体系目前固定成如下：
1. 案例分析员和案例分析员-开发员目前固定成一个ai
2. 案例分析员的审核员和 案例分析员-开发员的审核员 也都固定成一个ai, 这个ai对案例分析员的审核 以及 案例分析员开发员 的审核都统一记录在 ana-doc/案例审计报告.md 里
最后因为目前3个体系都需要开发员，但是两个体系的开发员的审核都记录到了别的地方，所以只有需求-开发员、项目工具开发员等独立开发事项的审计员的审计报告会记录到 dev-doc/开发审计报告.md 文档里
