edit | blame | history | raw

AI 会话协作语义规范

创建人员：Codex
文件职责：定义 AI 角色会话在阅读项目文档时，如何把“提交审核、退回、交给产品、上报管理员”等自然语言协作字眼转换为正式角色交互动作。
管理规范/模板：../../全局规范.md；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。

技能选择、显式声明、状态变更记录、失败越权处理和性能口径按 AI技能使用规范.md 执行。角色不得在未声明技能的情况下发送正式消息、ack 消息、提交审核或升级管理端。

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. 不存在执行者直接无条件批准自己工作的情况。