cai
2026-06-05 9c703f14d916320bea60d5c9f3db000438fc0f91
废弃 MB-X 体系 YAML 中间产物
3 files modified
6 files deleted
1 files added
693 ■■■■ changed files
common/ai-workplace/AI会话协作语义规范.md 123 ●●●●● patch | view | raw | blame | history
common/ai-workplace/目录导读.md 12 ●●●●● patch | view | raw | blame | history
common/ana-doc/mbx.system.yaml 72 ●●●●● patch | view | raw | blame | history
common/data-doc/mbx.system.yaml 24 ●●●●● patch | view | raw | blame | history
common/dev-doc/mbx.system.yaml 229 ●●●●● patch | view | raw | blame | history
common/exp-doc/mbx.system.yaml 72 ●●●●● patch | view | raw | blame | history
common/pro-doc/mbx.system.yaml 63 ●●●●● patch | view | raw | blame | history
common/project-doc/mbx.system.yaml 82 ●●●●● patch | view | raw | blame | history
common/project-doc/目录导读.md 2 ●●● patch | view | raw | blame | history
common/project-doc/项目规范.md 14 ●●●●● patch | view | raw | blame | history
common/ai-workplace/AI会话协作语义规范.md
New file
@@ -0,0 +1,123 @@
# AI 会话协作语义规范
创建人员:Codex
文件职责:定义 AI 角色会话在阅读项目文档时,如何把“提交审核、退回、交给产品、上报管理员”等自然语言协作字眼转换为正式角色交互动作。
管理规范/模板:../../全局规范.md;AI工作空间创建指南.md。
引用文件:AI工作空间创建指南.md;../project-doc/项目规范.md;../project-doc/项目配置清单模版.md。
记录方式:AI 会话协作语义规范;协作语义、消息意图或角色交互规则变化时更新。
## 1. 定位
本文件定义 `common/` 文档中常见协作语义的统一解释方式。
当项目在 MB-X 管理环境中运行时,AI 角色会话看到“提交审核”“交给审核员”“让产品确认”“退回开发员”“需要项目管理员介入”等字眼,不应只在聊天窗口里口头说明,而应把它们视为正式角色交互动作。
正式角色交互动作必须满足:
1. 能确认当前项目。
2. 能确认当前角色。
3. 能找到目标角色。
4. 能形成可追踪消息。
5. 能写入项目消息链、inbox 或对应正式账本。
6. 能让接收方知道要读哪些证据、执行什么动作、如何反馈。
## 2. 通用处理规则
AI 角色会话处理协作语义时,按以下顺序执行:
1. 确认当前项目、当前角色和当前事项。
2. 读取项目配置清单、当前 AI 工作说明、相关体系规范和通信规范。
3. 判断文档字眼对应的交互意图。
4. 根据项目配置和文档确定目标角色,不得只凭角色名字猜测。
5. 形成包含任务 ID、来源、目标、证据入口、期望动作和风险的消息。
6. 使用当前框架提供的正式通信机制发送消息。
7. 记录或汇报消息 ID、目标角色、目标 inbox 和后续处理要求。
如果无法确认目标角色、审核入口、证据入口或当前角色权限,应暂停发送,并向项目管理员或管理会话反馈不确定项。
## 3. 常见协作语义
| 文档字眼 / 人类说法 | 交互意图 | 目标角色选择 | 输出动作 |
|---|---|---|---|
| 提交审核、送审、给审核员审核、等待审核 | `review_request` | 当前事项所属体系或目标工作区对应的审核角色 | 发送审核请求,附证据入口和待审核点 |
| 审核不通过、退回、要求返修、需要补证据 | `review_feedback` | 被审事项来源角色、负责人或执行者 | 发送审核反馈,说明阻断问题和修复要求 |
| 审核通过、复审通过 | `review_result` | 被审事项来源角色、项目管理员或后续负责人 | 发送审核结论,说明依据和可进入的下一状态 |
| 让产品确认、请需求确认、确认是否符合需求 | `confirmation_request` | 产品角色、需求角色或项目配置中指定确认人 | 发送确认请求,列出确认事项和证据 |
| 产品确认通过、需求确认完成 | `confirmation_result` | 请求确认的来源角色或后续执行角色 | 发送确认结论,说明确认范围 |
| 交给开发、交给实验员、交给分析员、转交执行 | `handoff` | 当前体系或目标范围对应执行角色 | 发送交接消息,说明输入、输出和验收要求 |
| 请补充、需要更多信息、缺少上下文 | `info_request` | 能补充信息的来源角色、产品角色、管理员或上游角色 | 发送补充信息请求,说明缺口和用途 |
| 已补充、信息已更新 | `info_response` | 发起补充请求的角色 | 发送信息回复,给出更新入口 |
| 需要项目管理员介入、上报管理端、流程不清、权限不够 | `escalation` | 项目管理员、管理会话或项目级角色 | 发送升级消息,说明阻塞、影响和建议动作 |
| 已完成、可收口、请归档、进入下一阶段 | `completion_notice` | 项目管理员、下一环节角色或来源角色 | 发送完成通知,说明完成依据和剩余事项 |
| 稍后自查、后续复核、拆分下一步 | `self_message` | 当前角色自身 | 发送自发消息,必须写清终止条件,避免重复循环 |
| 请协作、请配合、联合处理 | `collaboration_request` | 项目配置和当前文档指定的协作角色 | 发送协作请求,说明各自边界和期望输出 |
## 4. 目标角色选择规则
目标角色必须从当前项目上下文中确定,优先级如下:
1. `项目配置清单.md` 中明确指定的角色、AI、审核入口和工作空间。
2. 当前项目 `mbx.project.yaml` 或等价机器配置中已经登记的 role / AI / session 绑定。
3. 当前体系本地规范、工作区说明、事项计划、设计文档中明确指定的负责人或审核人。
4. `common/` 体系规范中规定的默认职责边界。
5. 仍无法确认时,向项目管理员或管理会话发送不确定项,不得自行创造目标角色。
审核目标不得只用“审核员”三个字泛化。必须尽量明确是项目事项审核、需求审核、开发审核、实验审核、案例分析审核、数据审核或其他项目特化审核。
## 5. MB-X 环境下的执行要求
在 MB-X 管理环境中,正式角色交互应使用 MB-X 通信机制。
当前可见人工会话优先使用 `mbx-human-workflow`:
1. 人类说“提交审核”“交给产品确认”等自然语言请求。
2. AI 读取当前上下文、项目配置和本文件。
3. AI 选择交互意图和目标角色。
4. AI 调用 MB-X 发送消息。
5. AI 向人类报告 message id、目标角色和 inbox。
Runtime / daemon 触发的角色消息优先使用 `mbx-role-runtime`:
1. 角色在处理消息或文档时识别协作语义。
2. 角色返回正式 action,由 runtime 执行发送、ack、blocker 或 note。
3. 发送动作必须包含交互意图、目标角色和完整消息内容。
如果当前项目运行在 MB-X 环境中,应优先使用 `mbx-interaction-router` 或等价交互路由 skill 统一完成“文档字眼 -> 交互意图 -> 目标角色 -> MB-X 消息”的映射。人工会话可先规划路由,再确认发送;runtime / daemon 场景由角色返回等价发送 action。
## 6. 消息内容最低要求
任何正式交互消息至少包含:
1. 任务 ID 或事项 ID。
2. 来源角色。
3. 目标角色。
4. 交互意图。
5. 摘要。
6. 背景。
7. 证据入口。
8. 期望动作。
9. 校验或审核要求。
10. 阻塞、风险或不确定项。
11. 希望对方如何反馈。
审核、确认、返修、升级管理端等关键交互不得只发送一句“请审核”或“已完成”。
## 7. 禁止事项
1. 不得把“提交审核”理解为只在当前聊天窗口声明已送审。
2. 不得在无法确认目标角色时随意选择一个看起来像审核员的角色。
3. 不得让执行角色无条件批准自己的工作。
4. 不得绕过项目配置清单和当前体系文档直接写消息。
5. 不得把正式交接只写入 AI 私有工作空间而不进入正式消息链或正式账本。
6. 不得因为文档中只写“审核员”就忽略具体审核体系和审计入口。
## 8. 校验口径
一次协作语义处理合格,至少满足:
1. 交互意图识别正确。
2. 目标角色来自项目配置或当前文档。
3. 消息进入正式通信链或正式账本。
4. 接收方能从消息中找到证据入口和期望动作。
5. 失败或不确定项已反馈给项目管理员或管理会话。
6. 不存在执行者直接无条件批准自己工作的情况。
common/ai-workplace/目录导读.md
@@ -3,7 +3,7 @@
创建人员:Codex  
文件职责:说明 `common/ai-workplace/` 下 AI 工作空间和角色指派相关通用文档的入口。  
管理规范/模板:../../全局规范.md。  
引用文件:AI工作空间创建指南.md;项目问题反馈范本.md。
引用文件:AI工作空间创建指南.md;AI会话协作语义规范.md;项目问题反馈范本.md。
记录方式:目录导读;新增或删除本目录文件时更新。
## 文件清单
@@ -11,13 +11,15 @@
| 文件 | 作用 |
|---|---|
| AI工作空间创建指南.md | 指导项目管理员创建 AI 工作空间、分配角色、生成工作说明和项目问题反馈入口并做校验 |
| AI会话协作语义规范.md | 定义 AI 角色会话如何把“提交审核、退回、交给产品、上报管理员”等文档字眼转换为正式角色交互动作 |
| 项目问题反馈范本.md | 提供 `ai-<name>/项目问题反馈.md` 的参考写法,用于重大协作问题和反复返修问题反馈 |
## 使用顺序
1. 项目管理员先确认项目根目录和 `项目配置清单.md`。
2. 按 `AI工作空间创建指南.md` 创建 `ai-<name>/`。
3. 生成 `ai-<name>/工作说明.md`。
4. 参考 `项目问题反馈范本.md` 创建 `ai-<name>/项目问题反馈.md`。
5. 同步更新 `项目配置清单.md`、`项目执行日志.md`、`项目变更记录.md`。
6. 按指南中的校验方案检查。
3. 读取 `AI会话协作语义规范.md`,把角色间交接、审核、确认、返修、升级等自然语言动作写入工作说明。
4. 生成 `ai-<name>/工作说明.md`。
5. 参考 `项目问题反馈范本.md` 创建 `ai-<name>/项目问题反馈.md`。
6. 同步更新 `项目配置清单.md`、`项目执行日志.md`、`项目变更记录.md`。
7. 按指南中的校验方案检查。
common/ana-doc/mbx.system.yaml
File was deleted
common/data-doc/mbx.system.yaml
File was deleted
common/dev-doc/mbx.system.yaml
File was deleted
common/exp-doc/mbx.system.yaml
File was deleted
common/pro-doc/mbx.system.yaml
File was deleted
common/project-doc/mbx.system.yaml
File was deleted
common/project-doc/目录导读.md
@@ -18,7 +18,7 @@
| 文件 | 类型 | 作用 |
|---|---|---|
| 项目规范.md | 全局项目规范 | 说明项目体系的定位、核心流程、文档职责和边界 |
| 项目规范.md | 全局项目规范 | 说明项目体系的定位、核心流程、文档职责、业务子项目目录和 Git 管理边界 |
| 项目环境创建指南.md | 创建指南 | 指导项目管理员创建新项目和初始化项目体系 |
| 项目总览范本.md | 模板 | 创建项目根目录 `项目总览.md`,记录项目稳定基础信息、目标、周期、背景和关键入口 |
| 项目规范模版.md | 模板 | 创建项目根目录本地 `项目规范.md` |
common/project-doc/项目规范.md
@@ -44,6 +44,20 @@
9. 项目规范只记录项目特化内容,不重复抄写全局规范和体系规范。
10. 项目级管理动作必须有日志和审计入口。
11. 项目内具体事项必须能追到项目目标和启用体系。
12. 当 `mb-ms-doc` 作为工作区管理根目录时,工作区内的业务子项目目录应以 `project-` 开头;每个业务子项目应拥有独立 Git 仓库,不加入 `mb-ms-doc` 仓库管理。
### 2.1 业务子项目目录与 Git 边界
`mb-ms-doc` 仓库保存全局规范、体系模板、公共文档和管理根目录规则,不直接管理具体业务子项目的版本历史。
工作区内的业务子项目按以下口径管理:
1. 业务子项目目录建议统一使用 `project-<name>` 命名,便于管理根目录 `.gitignore` 排除和人工识别。
2. 每个业务子项目应在自身项目根目录内初始化独立 Git 仓库。
3. 业务子项目不得作为普通文件加入 `mb-ms-doc` 仓库提交。
4. `mb-ms-doc` 根仓库应排除 `project-*` 业务子项目目录。
5. 如果历史项目、示例项目或特殊项目暂时不满足 `project-*` 命名,应在项目总览、项目配置清单或项目变更记录中说明原因和 Git 管理边界。
6. 项目管理员创建新项目时,应同步确认项目目录名、独立 Git 仓库、远端地址、提交身份和管理根目录排除规则。
## 3. 核心流程