# AI 工作空间创建指南

创建人员：Codex  
文件职责：指导项目管理员在某个项目中为指定 AI 创建工作空间、分配一个或多个角色，并生成该 AI 的 `工作说明.md` 和 `项目问题反馈.md`。  
管理规范/模板：../../全局规范.md；../project-doc/项目规范.md；../project-doc/项目配置清单模版.md。  
引用文件：../../全局规范.md；../project-doc/项目规范.md；../project-doc/项目环境创建指南.md；../project-doc/项目配置清单模版.md；AI技能使用规范.md；项目问题反馈范本.md。  
记录方式：通用创建指南；AI 工作空间、角色分配、工作说明或校验口径变化时更新本文。

## 1. 使用场景

当项目管理员要把某个 AI 加入某个项目，或给已有 AI 增加 / 调整角色时，按本指南执行。

本指南提供两个功能：

1. 在某个项目里创建该 AI 的工作空间。
2. 根据该 AI 在项目中的一个或多个角色，生成或更新入口索引型 `工作说明.md`，让该 AI 快速知道自己的职责边界、目录入口和必须阅读的体系文档。
3. 创建 `项目问题反馈.md`，供该 AI 反馈项目协作中的重大阻塞、权限/流程问题和反复返修问题；写法参考 `项目问题反馈范本.md`。

本指南不替代项目体系、需求体系、开发体系、实验体系、案例分析体系或数据体系的创建指南。它只负责“AI 人员入场和角色配置”。

## 2. 输入

执行前必须明确：

| 输入项 | 说明 |
|---|---|
| project_root | 项目根目录，例如 `project-x/` |
| ai_name | AI 稳定名称，建议英文名或拼音小写 |
| ai_display_name | 显示名称，可与 ai_name 相同 |
| roles | 一个或多个角色，例如 `需求 AI`、`开发 AI`、`实验员`、`审核员` |
| target_scopes | 角色绑定的体系和目标范围，例如 `实验开发 -> dev/exp-dev/`、`项目审核 -> 项目事项审计报告.md`、`实验审核 -> exp-doc/实验审计报告.md` |
| is_reviewer | 是否承担审核员职责 |
| assigned_by | 指派人 |
| assignment_reason | 指派原因 |

`ai_name` 必须稳定。工作空间目录统一命名为：

```text
ai-<ai_name>/
```

禁止创建裸 AI 名目录，例如 `Andrew/`、`Codex/`。

## 3. 角色和权限口径

角色权限按 `全局规范.md` 和项目根目录 `项目配置清单.md` 执行。

同一个 AI 可以有多个角色，权限取角色权限并集，但必须在 `工作说明.md` 中写清每个角色的边界。

`开发 AI` 和 `审核员` 不能作为裸角色单独落地，必须绑定体系或目标范围。  
如果暂时无法确定开发目标或审核体系，只能登记为“候选角色 / 待绑定 target”，不得作为正式角色落地，也不得给正式写权限。
如果已经正式指派开发角色，必须同步按 `common/dev-doc/开发环境创建指南.md` 创建对应 target workspace；不得留下“正式开发角色已分配但目标工作区待创建”的半成品状态。

| 泛角色 | 正确写法示例 | 绑定范围 |
|---|---|---|
| 开发 AI | 开发 AI（实验开发） | `dev/exp-dev/`；`dev-doc/exp-doc/` |
| 开发 AI | 开发 AI（需求开发） | `dev/pro-dev/`；`dev-doc/pro-doc/` |
| 开发 AI | 开发 AI（案例分析开发） | `dev/ana-dev/`；`dev-doc/ana-doc/` |
| 审核员 | 审核员（项目事项审核） | `项目事项审计报告.md` |
| 审核员 | 审核员（实验审核） | `exp-doc/实验审计报告.md` |
| 审核员 | 审核员（需求开发审核 / 项目工具开发审核） | `dev-doc/开发审计报告.md` |
| 审核员 | 审核员（实验开发审核） | `exp-doc/实验审计报告.md` |
| 审核员 | 审核员（案例分析开发审核） | `ana-doc/案例审计报告.md` |
| 审核员 | 审核员（需求审核） | `pro-doc/需求审计报告.md` 或项目约定需求审核入口 |

审核员不能只读审计报告或审计规范。任何审核员都必须同时读取：

1. 被审体系的“怎么做”文档：例如需求规范、实验规范、编码规范、项目规范、案例分析规范。
2. 审核体系的“怎么审”文档：例如需求审核入口、实验审计规范、开发审计规范、项目事项审计报告。
3. 被审对象的账本和证据链入口：例如总纲、设计/计划、执行日志、结果包索引、变更记录、问题记录。
4. 如果审核对象涉及具体目标工作区，还必须列出该目标工作区说明文档，例如 `dev-doc/<target>-doc/开发工作区说明.md`。

如果 `工作说明.md` 只给审核员列了审计报告或审计规范，没有列被审体系规范和被审对象账本入口，则该工作空间创建不合格。

默认角色映射：

| 角色 | 默认职责 | 默认写权限范围 |
|---|---|---|
| 项目管理员 | 管理项目规范、配置清单、项目级账本、体系启用和项目级审计 | 项目根目录；该 AI 工作空间 |
| 需求 AI | 写需求、策略、业务规则等文档 | `pro-doc/`；该 AI 工作空间 |
| 开发 AI（指定体系开发） | 写指定体系的代码、测试、编码方案、开发日志和开发自检 | `dev/<target>-dev/`；`dev/<target>-dev/test/`；`dev-doc/<target>-doc/`；该 AI 工作空间 |
| 实验员 | 设计和执行实验，维护实验文档、实验数据和结果包 | `exp-doc/`；`exp-data/`；该 AI 工作空间 |
| 案例分析员 | 做案例分析，维护案例文档、图片、数据和执行链路 | `ana-doc/`；`ana-data/`；该 AI 工作空间 |
| 数据负责人 | 管理数据字典、数据存储说明和正式数据入口 | `data-doc/`；项目约定数据目录；该 AI 工作空间 |
| 审核员（指定体系审核） | 审核指定体系的设计、计划、执行、证据链和结果边界 | 对应体系审计报告；必要时在问题记录写跨轮索引；该 AI 工作空间 |

审核员可维护自己审核职责对应的本地审核 / 审计规范，例如 `exp-doc/实验审计规范.md`、`ana-doc/案例审核规范.md`、`dev-doc/开发审计规范.md`、`pro-doc/需求审核规范.md`；该权限只用于审核流程和审计口径维护，不代表可以修改被审体系的执行规范、事项计划、执行日志、结果包或主产物。若需要修改执行规范，必须另授体系维护 / 规范维护角色，或创建独立规范维护事项。

组合角色示例：

| 组合角色 | 解释 |
|---|---|
| 需求-开发 | 同一 AI 同时负责需求文档和对应代码实现，角色应写成 `需求 AI；开发 AI（需求开发）` |
| 实验-开发 | 同一 AI 同时负责实验设计/执行和实验相关脚本开发，角色应写成 `实验员；开发 AI（实验开发）` |
| 案例分析-开发 | 同一 AI 同时负责案例分析和案例工具开发，角色应写成 `案例分析员；开发 AI（案例分析开发）` |
| 项目管理员-审核员 | 同一 AI 负责项目配置和项目级审计，角色应写成 `项目管理员；审核员（项目事项审核）` |

### 3.1 组合角色必读文档口径

`工作说明.md` 必须按角色组合列出必读文档，不能只写一个泛化入口。

开发角色必须同时读取开发体系规范和目标体系规范：

| 开发角色 | 必读文档 |
|---|---|
| 需求-开发 | 项目本地 `pro-doc/需求规范.md`、相关需求总纲 / 需求文档 / 需求方案 / 三大需求文档；项目本地 `dev-doc/编码规范.md`、`dev-doc/开发审计规范.md` |
| 实验-开发 | 项目本地 `exp-doc/实验规范.md`、`exp-doc/实验审计规范.md`、相关实验总纲 / 实验设计；项目本地 `dev-doc/编码规范.md`、`dev-doc/开发审计规范.md` |
| 案例分析-开发 | 项目本地 `ana-doc/案例分析规范.md`、`ana-doc/案例分析审核规范.md`、相关案例总纲 / 案例设计或案例流程；项目本地 `dev-doc/编码规范.md`、`dev-doc/开发审计规范.md` |
| 项目工具开发 | 项目本地 `项目规范.md`、`项目配置清单.md`、相关项目事项总纲 / 项目事项计划；项目本地 `dev-doc/编码规范.md`、`dev-doc/开发审计规范.md` |

审核员角色必须同时读取“自己怎么审”和“被审对象怎么做”：

| 审核角色 | 必读文档 |
|---|---|
| 需求审核员 | 项目本地 `pro-doc/需求规范.md`、`pro-doc/需求审核规范.md`、被审需求事项账本和上游聊天 / 文档证据 |
| 开发审核员 | 项目本地 `dev-doc/编码规范.md`、`dev-doc/开发审计规范.md`、被审开发事项账本、目标体系规范和开发产物证据；审计报告入口按目标体系查看项目配置清单 |
| 实验审核员 | 项目本地 `exp-doc/实验规范.md`、`exp-doc/实验审计规范.md`、被审实验总纲 / 实验设计 / 执行日志 / 结果包 |
| 案例分析审核员 | 项目本地 `ana-doc/案例分析规范.md`、`ana-doc/案例分析审核规范.md`、被审案例账本 / 执行记录 / 图片或数据证据 |
| 项目事项审核员 | 项目本地 `项目规范.md`、`项目配置清单.md`、项目事项总纲 / 项目事项计划 / 项目执行日志 / 项目变更记录 |

如果是组合审核角色，例如“需求-开发-审核员”“实验-开发-审核员”“案例分析-开发-审核员”，工作说明必须同时列出目标体系规范、编码规范、目标体系审核规范、开发审计规范，以及对应目标事项和开发事项的账本入口。不得只列审计报告或只列审核规范。

组合角色必须避免“自己执行、自己无条件通过”的问题。若同一 AI 同时是执行者和审核员，`工作说明.md` 必须要求它在审计报告中明确标注“自审”，并列出可复核证据；重大事项应优先安排独立审核员。

## 4. 功能一：创建 AI 工作空间

### 4.1 创建步骤

在项目根目录执行：

```text
创建 ai-<ai_name>/
创建 ai-<ai_name>/tmp/
创建 ai-<ai_name>/draft/
创建 ai-<ai_name>/worklog/
创建 ai-<ai_name>/工作说明.md
创建 ai-<ai_name>/项目问题反馈.md
```

目录职责：

| 目录 / 文件 | 作用 |
|---|---|
| `ai-<ai_name>/` | AI 私有工作空间根目录 |
| `tmp/` | 临时分析、中间文件、一次性脚本结果 |
| `draft/` | 未进入正式体系的草稿 |
| `worklog/` | AI 私有过程记录，不能替代正式执行日志 |
| `工作说明.md` | 该 AI 在本项目里的角色入口卡和路由说明 |
| `项目问题反馈.md` | 该 AI 私有的项目协作问题反馈入口，只记录影响项目或体系进展的重要问题 |

AI 工作空间里的内容默认不是正式产物。任何内容要进入正式事项，必须迁入对应体系正式目录，并在对应总纲、设计、执行日志、结果索引或审计报告中记录。

### 4.2 项目问题反馈.md 使用边界

`项目问题反馈.md` 是 AI 私有反馈入口，不是正式审计报告，也不是项目级问题主账。它的项目治理规则以 `../project-doc/项目规范.md` 为准，写法参考 `项目问题反馈范本.md`。

适合写入：

1. AI 在项目协作中遇到的重大流程阻塞、权限边界不清、角色配置错误或体系入口缺失。
2. 会影响整个项目或某个体系推进的重要协作问题。
3. 审核员发现同一事项反复返修仍出现同类问题，通常大于等于 3 次，需要提醒项目管理员介入。
4. AI 首次阅读工作说明后发现的职责、权限、入口或规范引用不清问题。

不适合写入：

1. 普通小问题、一次性笔误、个人临时草稿事项。
2. 正式审计结论。正式审计结论仍写对应体系审计报告。
3. 非审计来源且需要项目级闭环的问题。此类问题仍写 `项目问题记录.md`，`项目问题反馈.md` 只可记录“已反馈给项目管理员”的线索。
4. 正式执行日志。正式执行节点仍写项目、需求、开发、实验或案例对应执行日志。

推荐初始化内容直接参考 `项目问题反馈范本.md`。创建项目内 `ai-<name>/项目问题反馈.md` 时，不要求逐字复制范本，但必须保留记录边界、append 写法，以及事项 ID、问题步骤、反复次数、证据路径、修复建议、是否需要完整方案和方案路径等关键追踪字段。

### 4.3 不能做的事

1. 不得把正式文档长期留在 AI 工作空间里。
2. 不得让 AI 工作空间替代项目执行日志、实验执行日志、开发执行日志或案例执行日志。
3. 不得在 AI 工作空间内创建第二套项目规范、开发规范、实验规范等体系规范。
4. 不得只创建目录，不更新 `项目配置清单.md`。
5. 不得把 `项目问题反馈.md` 当成正式审计报告或项目级问题记录的替代品。

## 5. 功能二：分配角色并生成工作说明

### 5.1 必须更新项目配置清单

给 AI 创建工作空间或调整角色时，必须更新项目根目录 `项目配置清单.md`：

1. 在“AI 角色与权限”表中新增或更新该 AI。
2. 在“目录映射”表中登记 `ai-<ai_name>/`。
3. 如角色涉及开发，必须写清是实验开发、需求开发、案例分析开发或其他具体开发目标，并绑定目标目录；不得只写“开发 AI”。
4. 如角色涉及审核，必须写清是项目事项审核、实验审核、开发审核、需求审核或其他具体审核目标，并绑定审计入口；不得只写“审核员”。
5. 如角色涉及目标开发工作区，必须同步调用开发环境创建指南创建该 target workspace；未创建时，只能登记候选开发角色，不得登记为正式开发角色。
6. 在“变更索引”中追加一条变更 ID。

如果该 AI 的角色涉及尚未启用的体系，必须先由项目管理员决定是否启用体系；未启用体系时，不得给该 AI 写入该体系正式写权限。

### 5.2 必须记录项目级变更

以下情况必须写入 `项目变更记录.md`：

1. 新增 AI。
2. 删除 AI。
3. 新增或调整 AI 角色。
4. 新增或调整 AI 工作空间。
5. 改变审核员身份。
6. 改变默认写权限边界。

同时应写入 `项目执行日志.md`，记录实际创建了哪些目录、改了哪些配置、生成了哪个 `工作说明.md` 和 `项目问题反馈.md`。

如果角色调整本身是一个项目事项，还应在 `项目事项总纲.md`、`项目事项计划.md` 和 `项目事项审计报告.md` 中记录对应事项和审计结论。

### 5.3 工作说明.md 生成要求

`ai-<ai_name>/工作说明.md` 必须是“角色入口卡 + 路由说明”，不得复制各体系规范的大段流程。它必须包含：

1. AI 名称和工作空间。
2. 指派人、指派时间、指派原因。
3. 当前角色列表。
4. 每个角色的职责边界、正式写权限和草稿写入位置。
5. 每个角色必须先阅读的体系文档入口。
6. 当前项目启用 / 未启用的相关体系，以及未启用体系的降级口径。
7. 正式产物目录、草稿目录、临时目录和审计入口。
8. 任务入口路由：接到任务后应该先查哪个配置、再读哪个体系规范。
9. 审核边界：如果该 AI 是审核员，要写清审核体系、审计报告入口和不能直接改被审计产物。
10. 审核规范维护边界：如果该 AI 是审核员，要写清可维护的本地审核 / 审计规范入口，以及不得默认修改的被审体系执行规范入口。
11. 技能使用入口：写清允许使用的技能、显式声明方式、状态变更记录和失败处理口径。
12. 禁止事项和越权边界。

`工作说明.md` 不能替代 `实验规范.md`、`编码规范.md`、`开发审计规范.md`、`项目规范.md` 等体系文档。体系流程变化时，以对应体系文档为准，工作说明只做入口索引。
审核员角色的“必读文档入口”必须同时列出被审体系规范、审计规范 / 审计报告入口、被审对象账本入口。

AI 首次读取或角色变更后重新读取 `工作说明.md` 时，必须在自己的 `worklog/` 中写一条理解反馈，至少回答：

1. 是否能理解自己的角色、权限和正式产物入口。
2. 是否能找到必须阅读的体系文档。
3. 是否有不理解、冲突或不合理的地方。
4. 如果有问题，应该反馈给项目管理员并记录到项目执行日志或对应审计报告。

### 5.4 工作说明.md 推荐模板

```markdown
# <AI_DISPLAY_NAME> 工作说明

创建人员：<创建人员>  
文件职责：记录 <AI_DISPLAY_NAME> 在 <PROJECT_NAME> 中的角色入口、职责边界、权限范围和体系文档路由。  
管理规范/模板：../../全局规范.md；../项目规范.md；../项目配置清单.md；../../common/ai-workplace/AI工作空间创建指南.md。  
引用文件：../项目配置清单.md；../项目执行日志.md；../项目变更记录.md；../../common/ai-workplace/AI技能使用规范.md；已启用体系规范。  
记录方式：当前配置说明；角色、权限或工作入口变化时覆盖更新，并在项目变更记录中保留历史。

## 1. 基本信息

| 字段 | 内容 |
|---|---|
| AI 名称 | <AI_NAME> |
| 显示名称 | <AI_DISPLAY_NAME> |
| 工作空间 | ai-<AI_NAME>/ |
| 指派人 | <ASSIGNED_BY> |
| 指派时间 | <YYYY-MM-DD HH:mm:ss> |
| 指派原因 | <ASSIGNMENT_REASON> |

## 2. 当前角色

| 角色 | 职责范围 | 默认写权限 | 关键规范 |
|---|---|---|---|
| <ROLE> | <职责范围> | <写权限范围> | <规范入口> |

## 3. 必读文档入口

| 场景 / 角色 | 先读文档 | 用途 |
|---|---|---|
| 项目基础 | ../项目配置清单.md；../项目规范.md | 确认角色、权限、已启用体系和项目规则 |
| <ROLE_SCOPE> | <体系规范入口> | 按体系规范执行，不在工作说明里重复流程 |

## 4. 目录入口

1. 私有草稿：`ai-<AI_NAME>/draft/`
2. 私有临时文件：`ai-<AI_NAME>/tmp/`
3. 私有过程记录：`ai-<AI_NAME>/worklog/`
4. 私有项目问题反馈：`ai-<AI_NAME>/项目问题反馈.md`
5. 正式产物：<按角色列出正式目录；注明路径是否相对项目根目录>
6. 审计入口：<如有审核角色，列出对应审计报告；注明路径是否相对项目根目录>
7. 审核规范维护入口：<如有审核角色，列出可维护的本地审核 / 审计规范；同时列出不得默认修改的被审体系执行规范>

## 5. 任务入口路由

1. 接到任务后，先查 `项目配置清单.md`，确认自己是否有对应角色和写权限。
2. 根据任务类型进入对应体系文档：项目 / 需求 / 开发 / 实验 / 案例分析 / 数据。
3. 具体流程、日志、审计和交付要求，以对应体系规范为准。
4. 工作说明只提供入口，不复制体系流程。

## 6. 首次阅读反馈

1. 首次读取本文件后，在 `ai-<AI_NAME>/worklog/` 记录理解反馈。
2. 如果有不理解、冲突或不合理的地方，反馈给项目管理员，不要自行脑补执行。
3. 如果问题会影响项目协作、角色权限或体系推进，同步记录到 `ai-<AI_NAME>/项目问题反馈.md`。

## 7. 技能使用入口

1. 技能选择、显式声明、状态变更记录、失败越权处理按 `../../common/ai-workplace/AI技能使用规范.md` 执行。
2. 状态变更类动作必须在回复、消息、执行日志或结构化动作中写明使用的技能或技能别名。
3. 角色间交接、审核、确认、退回、升级时，必须进入正式消息链或正式账本，不得只在聊天窗口声明。
4. 所需技能、目标角色、审核入口或权限不明确时，先反馈项目管理员，不得自行扩大权限。

## 8. 审核边界

如果本 AI 是审核员：

1. 可以读取证据链和运行只读检查。
2. 审计意见写入对应审计报告。
3. 可维护本地审核 / 审计规范，但仅限审核流程、审计口径和阻断标准维护。
4. 不直接改被审计主产物，不默认改被审体系执行规范。
5. 自审必须标注“自审”，并列出可复核证据。

## 9. 禁止事项

1. 不得把工作空间当正式产物目录。
2. 不得越权写未分配体系目录。
3. 不得绕过项目配置清单新增角色或权限。
4. 不得只在聊天里解释职责，不写入本文件。
5. 不得把 `项目问题反馈.md` 当成正式审计报告、正式问题记录或正式执行日志。
```

## 6. 创建 / 分配角色后的校验方案

### 6.1 工作空间校验

检查：

1. `ai-<ai_name>/` 存在。
2. `ai-<ai_name>/tmp/` 存在。
3. `ai-<ai_name>/draft/` 存在。
4. `ai-<ai_name>/worklog/` 存在。
5. `ai-<ai_name>/工作说明.md` 存在。
6. `ai-<ai_name>/项目问题反馈.md` 存在，并说明写法参考 `common/ai-workplace/项目问题反馈范本.md`。
7. 没有创建裸 AI 名目录。
8. 工作空间内没有项目规范、体系规范、开发账本、实验账本等重复体系文件。

### 6.2 项目配置清单校验

检查 `项目配置清单.md`：

1. “AI 角色与权限”表中有该 AI。
2. 角色列表与本次指派一致。
3. “是否审核员”与本次指派一致。
4. 工作空间路径为 `ai-<ai_name>/`。
5. 默认写权限范围与角色匹配。
6. “目录映射”中有 `ai-<ai_name>/`。
7. “变更索引”中有本次角色 / 工作空间变更 ID。
8. 不存在裸 `开发 AI` 角色；所有开发角色都绑定具体体系和目标工作区。
9. 不存在裸 `审核员` 角色；所有审核角色都绑定具体审核体系和审计入口。

如果工作说明中的角色和项目配置清单不一致，以 `项目配置清单.md` 为事实源，必须修正 `工作说明.md`。

### 6.3 体系启用和权限校验

检查：

1. 需求 AI 写权限对应的 `pro-doc/` 是否已启用；未启用时只能写工作空间草稿。
2. 实验员写权限对应的 `exp-doc/`、`exp-data/` 是否已启用；未启用时只能写工作空间草稿。
3. 案例分析员写权限对应的 `ana-doc/`、`ana-data/` 是否已启用；未启用时只能写工作空间草稿。
4. 开发 AI 的目标开发工作区是否已经创建；正式开发角色不得停留在 target_workspace 未创建状态。
5. 审核员角色是否有对应审计报告入口。

不得因为给 AI 分配角色，就绕过体系启用流程或提前写正式目录。

### 6.4 工作说明校验

检查 `工作说明.md`：

1. 是否写清 AI 名称、工作空间、指派人、指派原因。
2. 是否列出所有角色。
3. 是否写清每个角色的职责范围。
4. 是否写清每个角色的写权限范围。
5. 是否引用全局规范、项目规范、项目配置清单和相关体系规范。
6. 是否写清正式产物与工作空间草稿的边界。
7. 如果是审核员，是否写清审核边界。
8. 如果是多角色，是否写清角色冲突处理和自审口径。
9. 如果是开发 AI，是否写清开发体系、目标工作区、开发文档目录和目标未创建时的权限状态。
10. 如果是审核员，是否写清审核体系、审计报告入口、审核规范维护边界和不得直接修改被审计产物。
11. 如果是审核员，是否同时列出被审体系规范、审计规范 / 审计报告入口、被审对象账本入口。
12. 是否要求 AI 首次阅读后在 `worklog/` 记录理解反馈和疑问。
13. 是否写清 `项目问题反馈.md` 的入口和边界：只反馈重大协作问题，不替代正式审计报告、问题记录或执行日志。
14. 是否说明 `项目问题反馈.md` 的写法参考 `common/ai-workplace/项目问题反馈范本.md`。
15. 是否引用 `common/ai-workplace/AI技能使用规范.md`，并写清技能显式声明、状态变更记录、消息交互和失败越权处理口径。

组合角色还必须按角色类型做专项校验：

1. 需求-开发角色：`工作说明.md` 必须同时列出 `pro-doc/需求规范.md`、相关需求事项账本或需求文档入口、`dev-doc/编码规范.md`、`dev-doc/开发审计规范.md`、`dev/pro-dev/`、`dev-doc/pro-doc/`。
2. 实验-开发角色：`工作说明.md` 必须同时列出 `exp-doc/实验规范.md`、`exp-doc/实验审计规范.md`、相关实验总纲 / 实验设计入口、`dev-doc/编码规范.md`、`dev-doc/开发审计规范.md`、目标实验开发工作区。
3. 案例分析-开发角色：`工作说明.md` 必须同时列出案例分析规范、案例审核规范、相关案例账本入口、`dev-doc/编码规范.md`、`dev-doc/开发审计规范.md`、目标案例开发工作区。
4. 需求-开发-审核员：`工作说明.md` 必须同时列出需求规范、需求审核规范、编码规范、开发审计规范、需求审计报告、`dev-doc/开发审计报告.md`、需求事项账本入口、开发事项账本入口；不得只列审计报告或只列审核规范。
5. 实验-开发-审核员：`工作说明.md` 必须同时列出实验规范、实验审计规范、编码规范、开发审计规范、`exp-doc/实验审计报告.md`、实验事项账本入口、开发事项账本入口和实验开发工作区；不得把审计入口写成 `dev-doc/开发审计报告.md`。
6. 案例分析-开发-审核员：`工作说明.md` 必须同时列出案例分析规范、案例审核规范、编码规范、开发审计规范、`ana-doc/案例审计报告.md`、案例事项账本入口、开发事项账本入口和案例分析开发工作区；不得把审计入口写成 `dev-doc/开发审计报告.md`。
7. 任一组合审核员：必须列出它要审核的每个体系的“怎么做”文档和“怎么审”文档。如果漏任一体系规范，校验不通过。

### 6.5 项目级日志和变更校验

检查：

1. `项目执行日志.md` 记录了创建工作空间、生成工作说明、更新配置清单的动作。
2. `项目变更记录.md` 记录了 AI 新增 / 角色调整 / 工作空间调整。
3. 如果该动作被作为项目事项管理，`项目事项总纲.md`、`项目事项计划.md` 和 `项目事项审计报告.md` 能串起来。

### 6.6 通过标准

全部满足以下条件，才算完成：

1. 工作空间目录完整。
2. `工作说明.md` 可让该 AI 快速了解职责边界、目录入口和应该阅读的体系文档。
3. `项目问题反馈.md` 已创建，且用途边界清楚，并说明写法参考 `common/ai-workplace/项目问题反馈范本.md`。
4. `项目配置清单.md` 已更新，并且与 `工作说明.md` 一致。
5. 项目执行日志和项目变更记录已记录影响。
6. 未启用体系没有被越权写入正式权限。
7. 目标开发工作区没有被误创建成第二套开发体系。

## 7. 变更影响说明

新增 AI 或调整角色会影响项目：

1. 改变项目可执行角色。
2. 改变默认写权限范围。
3. 可能触发体系启用或目标开发工作区创建。
4. 可能改变审核员安排。
5. 可能影响后续事项的责任归属。

因此，任何 AI 工作空间创建和角色指派都不能只在聊天里完成，必须落到：

```text
项目配置清单.md
-> ai-<name>/工作说明.md
-> ai-<name>/项目问题反馈.md
-> 项目执行日志.md
-> 项目变更记录.md
-> 必要时进入项目事项总纲 / 计划 / 审计报告
```

## 8. 常见错误

1. 只创建 `ai-<name>/`，没更新项目配置清单。
2. 只更新项目配置清单，没生成 `工作说明.md` 或 `项目问题反馈.md`。
3. 给 AI 分配实验员角色，但项目未启用实验体系。
4. 给开发 AI 写了 `dev/` 全目录权限，而不是绑定目标开发工作区。
5. 在 `dev-doc/<target>-doc/` 下复制第二套开发账本。
6. 审核员直接修改被审计产物。
7. AI 工作空间里堆放正式产物，正式账本找不到。
8. 角色变更没有写项目变更记录。
9. 只写“开发 AI”，没有写清实验开发、需求开发或案例分析开发等具体开发范围。
10. 只写“审核员”，没有写清项目事项审核、实验审核、开发审核或需求审核等具体审核范围。
11. 正式指派了开发角色，但没有同步创建对应 target workspace。
12. 在 `工作说明.md` 里复制体系规范细节，导致工作说明变成第二套规范。
13. 审核员只列审计规范或审计报告，没列被审体系规范和被审对象账本入口。
14. AI 首次读取工作说明后没有留下理解反馈，导致后续误解无法追踪。
15. 把 `项目问题反馈.md` 当成正式审计报告、正式问题记录或正式执行日志。

## 9. 一句话

AI 工作空间创建不是单纯建目录，而是“人员入场 + 角色授权 + 工作说明 + 项目问题反馈入口 + 项目配置清单 + 变更记录 + 校验”的完整动作。