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