| name | roundtable-debate |
| description | 圆桌会议 - 多子Agent协作生成高质量设计文档。触发关键词：圆桌会议、设计文档、生成设计、详细设计、架构设计、plus design、出设计、写设计、深度设计、给我出一份设计、设计评审、圆桌会议plus。输入：PBI需求、设计方案、技术选型。输出：可直接编码的设计文档。核心机制：必须使用runSubagent启动5个独立子Agent，分层执行（4并行+实施派依赖），主Agent组装设计评审文档，6个文件交付。 |
🪑 圆桌会议 v2.0 - 多子Agent协作生成设计文档
通过5个独立子Agent分层执行，输出可直接编码的高质量设计文档。
🎯 核心流程：收集上下文 → 4角色并行分析 → 实施派依赖执行（参考前4个产出）→ 设计评审文档组装 → 发布到飞书（默认）→ 交付
🔴 v2.0 核心改进：
- 分层执行 — 实施派参考前4个角色产出，天然校准质量
- KEY_OUTPUT 标记 — 前4个角色自总结关键信息，实施派精准获取
- 强制检查点 — 每阶段验证文件存在，防止 subagent 不写文件
- 取消核查循环 — 分层执行本身就是最好的校准，省去 40-50% 耗时
🔴 文件持久化机制（避免上下文截断，强制）
⚠️ 所有分析过程必须持久化到文件，不依赖上下文传递！
🔴 核心机制：5个subagent的分析报告可能超过上下文限制，必须写入文件。
📖 详见 references/workspace.md
工作目录
{project}/.copilot-temp/roundtable-{NNN}/ # NNN = 001-999
产出文件（6个文件）
| 文件 | 来源 | 目标读者 |
|---|
01-architecture.md | 架构派🧠 subagent | 开发者 + AI编码Agent |
02-efficiency.md | 效率派⚡ subagent | 开发者 + AI编码Agent |
03-quality.md | 质量派🛡️ subagent | 测试人员 + 开发者 |
04-cost.md | 成本派💰 subagent | 管理层 + 开发者 + coding-agent（CODING_TASK_LIST） |
05-implementation.md | 实施派👨💻 subagent | 开发者 + AI编码Agent（核心参考）+ coding-agent（CODING_IMPL） |
06-design-review.md | 主Agent组装（Phase C） | 评审会议 + 团队文档 |
⚠️ 01-05 由 subagent 生成，06 由主Agent从 DESIGN_REVIEW 标记组装。
不使用融合 subagent（实测每次丢失内容），主Agent用 grep 精准提取。
🔴 关键规则
| 规则 | 说明 |
|---|
| subagent必须写文件 | create_file("${workDir}/0X-xxx.md", content) |
| 禁止从上下文读取 | 上下文会截断，只有文件是完整的 |
| 🚫 禁止询问删除 | 任何阶段都不得询问用户是否删除/清理工作目录或中间文件 |
🔴 必须收集项目上下文（强制，第0步）
⚠️ 开始设计前，必须读取相关expert skill了解现有架构
0.0 检查需求返讲文档（首先执行）
在收集项目上下文之前，先确认是否有最新的需求返讲文档：
检查方式（按优先级）：0. 上游注入 → 如请求中含「[上游注入] 返讲文档: {path}」，直接 read_file(path)，跳过下方所有检查和 askQuestions1. 用户在请求中直接提供了返讲文档内容 → 直接使用
2. 用户提供了返讲文档路径 → 读取文件
3. 用户提到了 PBI ID → 自动检查 .copilot-temp/pbi-{ID}-review.md 是否存在
- 存在 → 读取文件，提示用户确认："已找到 PBI {ID} 的返讲文档，是否使用？"
- 不存在 → 进入下一步
4. 以上都没有 → 使用 ask_questions 对话框询问用户：
- header: "返讲文档"
- question: "是否有最新的需求返讲文档？"
- 选项A: "有，我提供内容或文件路径" (allowFreeformInput: true)
- 选项B（推荐）: "没有，直接基于 PBI 描述进行设计"
将返讲文档内容（如有）作为 contextBlock 的一部分，注入后续所有 subAgent prompt。
0.0b 需求澄清状态检查（ask_questions 引导）
获取到返讲文档后，按以下优先级检查待确认问题：
上游短路：如请求中含「[上游注入] 澄清状态: 全部已确认」→ 跳过此步骤。含「[上游注入] 澄清状态: {N}条待确认(用户已接受风险)」→ 记录为 accepted_risk 并跳过 askQuestions。
检测方式（优先级从高到低）：
- 结构化标记（优先）：搜索
CLARIFICATION_LIST_START 标记 → 解析表格中状态为 🔴待确认 的行 → 精确统计未确认数量
- 文本搜索（降级）：无结构化标记时，搜索「待确认」「待澄清」「需与 PM 确认」关键词
如果发现未澄清问题，使用 ask_questions 对话框提醒用户：
header: "需求澄清"
question: "检测到返讲文档中有 {N} 个待确认问题（{M} 个已确认）：\n\n[列出🔴待确认的问题，含 ID]\n\n⚠️ 未澄清的需求问题可能导致设计方案偏离实际需求，建议先与 PM/相关人士沟通确认。"
options:
- label: "这些问题已经确认过了，继续设计"
description: "口头/线下已确认但文档未更新，可以继续"
- label: "跳过，基于当前理解出设计"
description: "接受风险，后续有偏差再修订"
recommended: true
- label: "暂停，我先去确认这些问题"
description: "先与 PM 沟通，确认后再启动圆桌会议"
🔴 如果没有待确认问题（全部已确认或无问题），或者用户没有提供返讲文档，跳过此步骤。
0.1 检测修订模式
检查同 PBI 是否已有圆桌会议产出：
- 执行
list_dir("{projectRoot}/.copilot-temp")，筛选以 roundtable- 开头的目录
- 如果存在这样的目录，对每个目录：
- 执行
read_file("{目录}/01-architecture.md", 1, 10) 读取文件头几行
- 检查文件内容是否包含当前 PBI ID
- 如果匹配 → 发现同 PBI 已有产出，进入修订模式
- 如果没有匹配 → 首次模式，分配新编号
修订模式 vs 首次模式：
| 项目 | 首次模式 | 修订模式 |
|---|
| 工作目录 | 新建 roundtable-{NNN+1} | 复用已有目录 |
| 执行流程 | Phase A → B → C → D 完整执行 | 定向修改受影响文档 |
| 触发方式 | 默认 | 检测到同 PBI 已有产出时自动询问 |
修订模式询问（使用 ask_questions 对话框）：
先向用户展示已有产出文档列表，然后弹出对话框：
检测到 PBI {id} 已有圆桌会议产出（{workDir}），包含以下文档：
- 01-architecture.md
- 02-efficiency.md
- ...
ask_questions 参数：
- header: "修订模式"
- question: "检测到同 PBI 已有圆桌会议产出，请选择操作方式"
- 选项A（推荐）: "基于已有产出进行修订" (allowFreeformInput: true，用户可输入修改意见)
- 选项B: "重新执行完整圆桌会议（创建新版本）"
修订模式执行流程
读取已有 01-06 文档
↓
分析用户修改意见 → 识别受影响的文档
↓
🔍 如修改意见涉及新的平台API/类/枚举，先搜索获取完整信息
↓
定向修改受影响文档（直接编辑，不重跑整个圆桌）
↓
检查级联影响（如改了01架构，05实施方案可能也要调整）
↓
更新 06-design-review.md 的变更记录
↓
Phase D: 默认重新发布到飞书
⚠️ 修订时保留原文件的 KEY_OUTPUT / DESIGN_REVIEW / CODING 标记结构，仅修改内容。
必须执行的收集步骤（首次模式，共7步）
⚠️ 以下7个步骤全部为自然语言指令，AI 必须按顺序逐步执行，不是示例代码！
🔴 步骤4/5/7 是 Phase 9 新增的核心步骤，禁止跳过。
步骤1：分析 PBI 涉及哪些模块
根据 PBI 标题和描述中的关键词，判断涉及的功能模块（如 [你的平台组件名] 等）。
步骤2：读取涉及模块的 expert skill（了解现有架构）
对每个涉及的模块，执行 read_file("{project}/.github/skills/{模块名}-expert/SKILL.md")。
例如 PBI 涉及 VOI 和 Save → 读取 voi-expert/SKILL.md 和 save-export-expert/SKILL.md。
步骤3：读取平台层 expert skill（了解平台能力）
执行 read_file("{project}/.github/skills/{{PLATFORM_PREFIX}}-{领域}-expert/SKILL.md")。
例如涉及数据保存 → 读取 {{PLATFORM_REPO}}-datasave-expert/SKILL.md。
步骤3B：读取运行时配置文件（了解 FE↔BE 通路映射）
💡 当 PBI 涉及 FE↔BE 通信（如新增 Operation、Widget、消息路由）时，读取 XML 配置文件可精准了解现有通路注册。
3B-1. 自动发现配置文件路径
按以下优先级搜索项目中的 XML 配置目录：
- 标准路径:
file_search("**/appdata/*/config/[你的配置目录]/[配置文件]")
- 匹配 → 配置根目录 =
appdata/{appname}/config/
- 拆分路径:
file_search("**/BE/appdata/*/config/[你的配置目录]/[配置文件]")
- 匹配 → BE 配置 =
BE/appdata/{appname}/config/BE/，FE 配置 = FE/appdata/{appname}/config/FE/
- 均未找到 → 跳过步骤3B，在 contextBlock 标注「⚠️ 未找到运行时配置文件」
3B-2. 读取核心配置文件（找到路径后，读取以下 3 个核心文件）
| 文件 | 包含信息 | 提取重点 |
|---|
[后端配置文件] | FE→BE Operation 路由、Widget/Model 注册 | 与 PBI 模块相关的 <Item> 条目 |
BE/WorkflowController.xml | Controller 级 Operation 链、线程模型 | 与 PBI 相关的 <OperationName> 链 |
[前端命令配置] | BE→FE 消息路由（注意文件名拼写） | 与 PBI 模块相关的 <Handler> 条目 |
可选读取（如 PBI 涉及初始化或 IoC）：[前端配置文件]、FE/EventHandler.xml、[前端容器配置]
3B-3. 提取模块相关条目
从 XML 中筛选与步骤1识别的模块相关的条目（按模块关键词/命名空间匹配），写入 contextBlock 的「运行时配置映射」区段。
🔴 步骤4：判断 PBI 是否涉及平台组件（必须执行）
上游短路：如请求中含「[上游注入] 平台组件涉及: 是({keywords})」→ 直接标记「涉及平台组件 = 是」， 跳过平台特有的继承分析步骤4b 工作区检测和 askQuestions。
检查 PBI 标题/描述是否包含以下任一关键词：
DataLoad / DataSave / ROI / VOI / TissueControl / MaskData / Volume /
Layout / Cine / VRT / Palette / Density / SUV / DataLinkage / ImageTools
- 匹配 → 标记
涉及平台组件 = 是，继续步骤4b
- 不匹配 → 标记
涉及平台组件 = 否，步骤5写N/A，步骤7整体跳过
步骤4b：平台项目工作区检测（涉及平台组件时执行）
当步骤4判定「涉及平台组件 = 是」时，检测用户是否具备平台代码访问能力。
检测流程:
- 检查工作区是否包含
{{PLATFORM_REPO}} 文件夹: list_dir 查看工作区根目录
- 检查
.github/copilot-instructions.md 中是否配置了 Azure DevOps MCP 仓库（搜索 {{PLATFORM_REPO}} 关键词）
判定:
- 本地有
{{PLATFORM_REPO}} → ✅ 可以本地搜索平台代码，继续步骤5
- 无本地但有 DevOps MCP 配置 → ✅ 可以远程搜索，继续步骤5
- 两者都没有 → 使用
ask_questions 提示用户：
header: "平台项目"
question: "检测到此 PBI 涉及平台组件修改（匹配关键词: {匹配到的关键词}），但当前工作区未打开平台项目且未配置 DevOps 远程仓库读取。\n\n缺少平台代码访问将导致设计文档中的平台接口分析不完整，可能遗漏关键依赖。\n\n建议操作："
options:
- label: "我来添加平台项目到工作区"
description: "将 {{PLATFORM_REPO}} 添加到多根工作区后重新执行"
- label: "跳过平台分析，继续设计"
description: "接受风险，设计文档中平台相关分析将基于 Skill 文档描述"
recommended: true
- 用户选择「添加平台项目」→ 暂停执行，输出添加指引（使用 GUI 工具的多根工作区管理功能，或手动打开
.code-workspace 文件添加）
- 用户选择「跳过」→ 在 context-check.md 中标注「⚠️ 未配置平台代码访问」，继续步骤5
🔴 步骤5：提取接口名列表 + 创建 context-check.md（必须执行）
5a. 如果步骤4判定涉及平台组件：从步骤3读取的 平台域专家 Skill 中，提取「核心接口速查」表中的所有接口名和类名，形成接口名列表。
例如：[你的平台接口名], IExportService, ExportConfig, SaveOptions
5b. 执行 create_file("{workDir}/context-check.md", 内容)，写入以下结构：
# 上下文收集检查记录
## PBI 信息
- PBI ID: {id}
- 涉及平台组件: {是/否}
- 匹配关键词: {匹配到的关键词列表，或"无"}
## 接口名列表（步骤5提取）
{从平台域专家 skill 提取的接口名/类名列表，每行一个}
{如不涉及平台组件，写"N/A — PBI 不涉及平台组件"}
## 平台源文件清单（步骤7填写）
{待步骤7完成后填写}
🔴 阻断点：确认 context-check.md 已创建（含PBI信息+接口名列表或N/A），否则不得继续步骤6。
步骤6：搜索项目中的相似实现（发现复用机会）
执行 grep_search("相似功能关键词") 搜索本地项目代码中的相似实现。
🔴 步骤7：搜索平台层源码（涉及平台组件时强制执行，不可跳过）
⚠️ 步骤4标记「涉及平台组件 = 是」时，此步骤为强制步骤，必须执行。
步骤4标记「涉及平台组件 = 否」时，跳过步骤7，直接进入检查点0。
7a. 使用步骤5提取的接口名列表作为搜索关键词
从 {workDir}/context-check.md「接口名列表」区段获取接口名/类名，用于搜索平台源码。
如果接口名列表为空或不足，降级提取：
- Tier 1（首选）：skill「核心接口速查」表中的接口/类名 → 直接使用
- Tier 2（skill 无速查表）：skill「代码搜索建议」或「搜索策略」中的推荐关键词 → 使用
- Tier 3（skill 缺失或极简）：用 PBI 标题/描述中的英文技术术语（如
DataSave、ROI、Export）搜索 {{PLATFORM_REPO}}
🔴 不要在应用代码里搜 平台 引用来提取类名 — using/import 语句只有命名空间（如 {{PLATFORM_NAMESPACE}}.DataSave），没有类名。
7b. 读取平台源码（本地优先 → MCP 降级）
对 7a 中的每个接口名/类名，按以下优先级搜索并读取源码：
路径A — 本地优先（工作区包含 {{PLATFORM_REPO}} 文件夹时）：
- 执行
grep_search("接口名", { includePattern: "**/{{PLATFORM_REPO}}/**" }) 定位文件
- 执行
read_file("命中的头文件.h") — 读取完整头文件签名
- 执行
read_file("命中的实现文件.cpp") — 读取完整实现代码
路径B — MCP 降级（本地没有 {{PLATFORM_REPO}} 时，search_code 在 On-Premise 不可用）：
- 从 expert skill 获取模块路径（如
BitmapPalette/），浏览模块根目录：
mcp_azuredevops_get_file_content({ repositoryId: "{{PLATFORM_REPO}}", path: "/模块名", versionType: "branch", version: "{{PLATFORM_BRANCH}}" })
- 浏览
BE/src/ 和 BE/include/ 子目录，定位 .h 和 .cpp 文件：
mcp_azuredevops_get_file_content({ ..., path: "/模块名/BE/src" })
mcp_azuredevops_get_file_content({ ..., path: "/模块名/BE/include" })
- 读取头文件 + 实现文件（两者都必须读取，仅读头文件不够）：
mcp_azuredevops_get_file_content({ ..., path: "/模块名/BE/include/{{PLATFORM_PREFIX}}-component-xxx/yyy.h" })
mcp_azuredevops_get_file_content({ ..., path: "/模块名/BE/src/yyy.cpp" })
🔴 头文件只有签名，必须读取 .cpp 实现文件才能理解逻辑
7c. 验证检查点（硬阻断 — 不通过则禁止进入检查点0）
确认步骤 7 至少读取了 1 个 {{PLATFORM_REPO}} 平台源文件（.h / .cpp / .cs）。
通过 → 将文件路径列表追加到 {workDir}/context-check.md「平台源文件清单」区段：
## 平台源文件清单（步骤7填写）
- ✅ 已读取 {N} 个平台源文件
- 文件列表:
- {文件路径1} (来源: 本地/MCP)
- {文件路径2} (来源: 本地/MCP)
未通过处理：
- 降级到下一 Tier 的关键词重试 7b
- 如果所有 Tier 均失败 且 MCP 也不可用：
- 在 context-check.md 标注「⚠️ 降级出口：MCP 不可用，平台源码搜索分数 5/15」
- 允许继续（降级通过），上下文中标注「⚠️ 未能获取平台源码，以下分析基于 skill 文档描述」
- 🔴 如果 MCP 可用但未执行搜索、或执行了但未读取任何文件：
- 禁止进入检查点0，必须重新执行步骤 7b
- 显示：
❌ 步骤7c未通过：PBI 涉及平台组件但未读取任何平台源文件，正在重试...
🔴 强制规则：搜索关键词从步骤5接口名列表提取，但最终必须读取平台完整源码（头文件+实现），
不能仅停留在 skill 文档描述层面。参考 #platform-architecture 了解完整搜索策略（本地优先 → MCP DevOps）。
🔴 阻断点：步骤7完成（或因不涉及平台而跳过）后，必须进入检查点0评分，禁止直接启动 runSubagent。
检查点0：上下文收集评分（进入 Phase A 前 — 强制评分）
🔴 在启动任何 subAgent 之前，必须先完成检查点0评分。评分不通过则禁止进入 Phase A。
读取 {workDir}/context-check.md，对照以下评分卡自评：
| 评分项 | 满分 | 评分标准 | 得分 |
|---|
| Expert Skill 阅读 | 5 | 读取了 ≥1 个相关 expert skill（步骤2） | ？ |
| 接口名列表 | 10 | context-check.md 中有从 平台域专家 Skill 提取的接口名列表（步骤5）；不涉及平台=N/A满分 | ？ |
| 平台源码阅读 | 15 | context-check.md 中有 ≥1 个平台源文件路径（路径含 {{PLATFORM_REPO}}/ 或来源标注 MCP:{{PLATFORM_REPO}}）；应用层文件不计分；不涉及平台=N/A满分；降级出口=5分 | ？ |
| 上下文注入准备 | 5 | contextBlock 已构建，包含所有收集的内容 | ？ |
| 总分 | 35 | | ？ |
判定规则：
- 总分 ≥ 25 → ✅ 通过，进入 Phase A
- 总分 < 25 → ❌ 阻断，返回补充缺失步骤
- 不涉及平台组件的 PBI → 接口名列表(10) + 平台源码(15) = N/A，按满分计算
输出格式（必须显示给用户）：
📊 **检查点0：上下文收集评分**
| 评分项 | 满分 | 得分 | 说明 |
|--------|------|------|------|
| Expert Skill 阅读 | 5 | {分} | {读取了哪些skill} |
| 接口名列表 | 10 | {分} | {列出接口名数量，或N/A} |
| 平台源码阅读 | 15 | {分} | {读取了N个文件，或N/A，或降级5分} |
| 上下文注入准备 | 5 | {分} | {contextBlock是否就绪} |
| **总分** | **35** | **{总分}** | {通过/阻断} |
上下文收集产出
| 收集项 | 来源 | 用途 |
|---|
| 现有架构 | expert skill（步骤2） | 确保设计与现有架构一致 |
| 平台能力 | 平台域专家（步骤3） | 避免重复造轮子 |
| 运行时配置 | XML 配置文件（步骤3B） | 了解现有 FE↔BE Operation/消息路由注册 |
| 🔴 接口名列表 | 平台域专家 → context-check.md（步骤5） | 步骤7搜索关键词 |
| 相似实现 | grep_search（步骤6） | 复用现有代码模式 |
| 🔴 平台源码 | 步骤5接口名 → 步骤7 read_file 或 MCP（步骤7） | 了解平台 API 实际签名和内部实现 |
| 项目规范 | expert skill | 遵循命名/组织规范 |
上下文复用原则（提高效率，不限制深入）
💡 主Agent收集的上下文完整注入到每个subAgent的prompt中
上下文注入到 subAgent prompt（强制格式）
⚠️ 主Agent 必须按以下结构构建 contextBlock，注入到每个 subAgent 的 prompt 中。
构建一个 contextBlock 字符串，包含以下内容，用于拼接到每个 subAgent prompt 中：
## 项目上下文（主Agent已收集）
> 💡 **使用原则**：
> 1. 优先使用：以下内容已收集，避免重复搜索相同内容
> 2. 按需搜索：如果你的分析需要更深入的细节，请使用下方搜索工具主动补充
### 现有架构
{步骤2-3读取的 expert skill 内容}
### 相似实现
{步骤6 grep_search 发现的代码片段}
### 运行时配置映射（XML）
{步骤3B 读取的 FE↔BE 配置条目（Operation 注册、消息路由、Widget/Model 绑定）；如未找到配置文件则填"⚠️ 未找到运行时配置文件"}
### 平台源码（{{PLATFORM_REPO}}）
{步骤7读取到的平台层完整源码（头文件签名+关键方法实现）；如不涉及则填"本 PBI 不涉及平台层组件"}
🔴 特别注意：步骤7搜索到的平台源码必须填入上述"平台源码"区域，不能遗漏！
如果步骤5执行了但结果未注入 contextBlock，subAgent 将无法参考平台 API 签名。
搜索指南（附加到 contextBlock 末尾）：
## 🔍 搜索指南（遇到未知信息时必须使用）
🔴 **强制规则**: 你在分析中引用的任何类型、接口、枚举、方法，
如果不在上方"项目上下文"中，**必须先搜索确认**，禁止凭记忆猜测。
可用工具:
1. grep_search("关键词") — 搜索本地工作区代码
2. read_file("路径") — 读取本地文件
3. mcp_azuredevops_get_file_content({ repositoryId: "{{PLATFORM_REPO}}", path: "/模块名", versionType: "branch", version: "{{PLATFORM_BRANCH}}" }) — 浏览平台仓库目录（path="/目录" 返回目录列表）
4. mcp_azuredevops_get_file_content({ repositoryId: "{{PLATFORM_REPO}}", path: "/模块名/BE/src/xxx.cpp", ... }) — 读取平台源码文件
搜索策略: 本地 grep_search 优先 → MCP get_file_content 目录浏览降级
⚠️ search_code 在 On-Premise 不可用，禁止使用
将 contextBlock 注入每个 runSubagent 调用：runSubagent("角色分析", 角色Prompt + contextBlock)
subAgent 行为：
- ✅ 优先基于已有上下文分析
- ✅ 如需更深入细节，主动补充搜索
- ⚠️ 避免重复搜索已有的 expert skill、相似代码等
🔴 必须使用 runSubagent（强制）
"假设我是架构师...现在切换为效率派..."
runSubagent("架构派独立分析", prompt_with_context)
runSubagent("效率派独立分析", prompt_with_existing_code)
runSubagent("质量派独立分析", prompt)
runSubagent("成本派独立分析", prompt)
🔄 分层执行流程
🔴 核心原则：实施派依赖前4个角色的产出，天然形成质量校准。无需额外核查循环。
🔴 强制加载：执行第0步前，必须 read_file("references/context-collection.md") 获取完整收集步骤。
┌─────────────────────────────────────────────────────────────┐
│ 第0步：收集项目上下文（强制，7个步骤） │
├─────────────────────────────────────────────────────────────┤
│ 0.0 检查需求返讲文档（用户提供/询问） │
│ 0.1 检测修订模式（同PBI已有产出？→ 修订 or 新建） │
│ 步骤1-3: 分析模块 + 读取 expert skill + 读取平台域专家 Skill │
│ 步骤3B: 读取运行时配置文件（FE↔BE XML 通路映射） │
│ 🔴 步骤4: 判断是否涉及平台组件（15关键词匹配） │
│ 🔴 步骤5: 提取接口名列表 → 创建 context-check.md │
│ 步骤6: grep_search(相似实现) → 发现复用机会 │
│ 🔴 步骤7: 搜索平台源码（本地优先→MCP降级）→ 硬阻断验证 │
└─────────────────────────────────────────────────────────────┘
↓
🔴 检查点0：上下文评分卡 ≥25/35 → 通过
↓
修订模式？→ 定向修改已有文档 → Phase D
↓ (首次模式)
┌─────────────────────────────────────────────────────────────┐
│ Phase A：4角色独立分析（因工具限制按顺序启动） │
├─────────────────────────────────────────────────────────────┤
│ runSubagent(架构派🧠) → 01-architecture.md + KEY_OUTPUT │
│ runSubagent(效率派⚡) → 02-efficiency.md + KEY_OUTPUT │
│ runSubagent(质量派🛡️) → 03-quality.md + KEY_OUTPUT │
│ runSubagent(成本派💰) → 04-cost.md + KEY_OUTPUT │
│ 🔴 各角色互相隔离，禁止读取对方文件（prompt级硬阻断） │
└─────────────────────────────────────────────────────────────┘
↓
🔴 检查点A：验证 01-04 文件存在且 > 100 bytes + KEY_OUTPUT
↓
┌─────────────────────────────────────────────────────────────┐
│ Phase B：实施派依赖执行（参考 Phase A 产出） │
├─────────────────────────────────────────────────────────────┤
│ 主Agent提取 01-04 的 KEY_OUTPUT 标记内容 │
│ runSubagent(实施派👨💻) → 05-implementation.md │
│ prompt 包含：KEY_OUTPUT 摘要 + 完整需求上下文 │
└─────────────────────────────────────────────────────────────┘
↓
✅ 检查点B：验证 05 文件存在且 > 100 bytes
↓
┌─────────────────────────────────────────────────────────────┐
│ Phase C：设计评审文档组装（主Agent直接执行，非subagent） │
├─────────────────────────────────────────────────────────────┤
│ grep_search(DESIGN_REVIEW标记) → 从01-05提取各区段 │
│ 按 design-review-template.md 结构组装 │
│ create_file → 06-design-review.md │
│ 🔴 Phase C 后处理检查（4项验证，详见下方） │
└─────────────────────────────────────────────────────────────┘
↓
🔴 检查点C：后处理验证通过
↓
┌─────────────────────────────────────────────────────────────┐
│ Phase D：发布到飞书（默认执行） │
├─────────────────────────────────────────────────────────────┤
│ 调用 #lark-doc-generator 批量导入模式 │
│ 逐个上传 01-06 + 创建索引文档 → 返回 7 个飞书链接 │
│ ❌ 飞书不可用时降级为本地交付 │
└─────────────────────────────────────────────────────────────┘
↓
🎯 交付：6个文件 + 飞书链接
🔴 KEY_OUTPUT 标记机制
前4个角色必须在文件末尾添加 KEY_OUTPUT 标记，供实施派精准提取。
标记格式
<!-- KEY_OUTPUT_FOR_IMPL_START -->
## 🎯 关键产出摘要（供实施派参考）
### 核心结论
- [本角色的核心设计结论，3-5条]
### 实施约束
- [影响编码的关键约束，如技术选型、接口规范等]
### 建议关注
- [实施时需要特别注意的点]
<!-- KEY_OUTPUT_FOR_IMPL_END -->
提取方法（主Agent在 Phase B 前执行）
对以下4个文件逐一执行提取：01-architecture.md、02-efficiency.md、03-quality.md、04-cost.md
- 执行
grep_search("KEY_OUTPUT_FOR_IMPL_START", { includePattern: "{workDir}/{文件名}" }) 定位标记的行号
- 执行
read_file("{workDir}/{文件名}", 标记起始行, 标记结束行) 读取标记之间的内容（通常 50-80 行）
- 将4份 KEY_OUTPUT 拼接为一个字符串，注入到实施派 prompt 中
🔴 为什么用标记而不是读全文？ 因为每个文件可能 500-1000+ 行，
全文注入会压缩实施派 prompt 空间。KEY_OUTPUT 提供精准摘要。
🔴 检查点机制
检查点0 已移至「收集步骤」区域（步骤7之后），紧邻其验证对象。
实测发现 subagent 有时不写文件（如 roundtable-001 只生成 3/5），必须强制检查。
🔴 检查点A（Phase A 完成后，强制执行）
对以下4个文件逐一执行 read_file 读取前10行，确认文件存在且内容 > 100 bytes：
{workDir}/01-architecture.md{workDir}/02-efficiency.md{workDir}/03-quality.md{workDir}/04-cost.md
对每个文件执行 grep_search("KEY_OUTPUT_FOR_IMPL_START")，确认标记存在。
如果任何文件缺失、内容太少、或不含 KEY_OUTPUT 标记 → 重新启动对应 subAgent。
🔴 必须显示检查结果：
✅ 检查点A：01 ✓ | 02 ✓ | 03 ✓ | 04 ✓ — KEY_OUTPUT 标记 4/4 存在
🔴 检查点B（Phase B 完成后，强制执行）
执行 read_file("{workDir}/05-implementation.md", 1, 10) 确认文件存在且内容 > 100 bytes。
如果 05 文件缺失或内容太少 → 重新执行实施派 subAgent。
🔴 必须显示检查结果：
✅ 检查点B：05-implementation.md ✓ — 文件存在且内容完整
🔴 检查点C（Phase C 组装后，强制执行）
组装 06-design-review.md 后，执行以下 4 项后处理验证：
C1. Mermaid 时序图验证：
- 执行
grep_search("sequenceDiagram", { includePattern: "06-design-review.md" })
- 缺失 → 从
05-implementation.md 全文搜索 sequenceDiagram 代码块，补充到 §2.1
- 仍无 → 基于已有文字描述就地生成 Mermaid
sequenceDiagram 代码块
C2. Mermaid 类图验证：
- 执行
grep_search("classDiagram", { includePattern: "06-design-review.md" })
- 缺失 → 从
01-architecture.md 全文搜索 classDiagram 代码块，补充到 §2.2
- 仍无 → 基于已有类设计描述就地生成 Mermaid
classDiagram 代码块
C3. 角色标注清理：
- 执行
grep_search("来源:\ |来源标记:", { includePattern: "06-design-review.md", isRegexp: true })
- 命中 → 删除所有
> 来源: / > 来源标记: 开头的行（这些是 AI 组装参考，不应出现在最终文档）
C4. XML 注释验证：
- 执行
grep_search("/// <summary>", { includePattern: "06-design-review.md" })
- 文档中有接口/类定义代码块但无
/// <summary> 注释 → 就地补充 XML 注释
🔴 必须显示检查结果：
✅ 检查点C：后处理验证
C1 Mermaid sequenceDiagram: ✓ 存在 / ⚠️ 已从05补充 / ⚠️ 已就地生成
C2 Mermaid classDiagram: ✓ 存在 / ⚠️ 已从01补充 / ⚠️ 已就地生成
C3 角色标注清理: ✓ 无残留 / ⚠️ 已清理 {N} 处
C4 XML注释: ✓ 完整 / ⚠️ 已补充 {N} 处
执行进度提示
🪑 **圆桌会议 v2.0 启动**
📋 议题: {需求描述}
⏱️ 预计耗时: 1-3分钟
---
📚 **第0步：收集项目上下文**
✅ 读取 xxx-expert → 了解模块架构
✅ 读取 {{PLATFORM_REPO}}-xxx-expert → 提取接口名列表
✅ 搜索现有相关代码 → 发现可复用组件
✅ 搜索平台源码 → 读取 N 个源文件（或 N/A 不涉及平台）
📊 **检查点0：上下文收集评分**
{显示评分卡表格，见检查点0输出格式}
✅ 总分 {X}/35 → 通过
🔄 **Phase A：4角色并行分析**
⭕ runSubagent: 架构派🧠 → 01-architecture.md
✅ 架构派🧠 完成
⭕ runSubagent: 效率派⚡ → 02-efficiency.md
✅ 效率派⚡ 完成
⭕ runSubagent: 质量派🛡️ → 03-quality.md
✅ 质量派🛡️ 完成
⭕ runSubagent: 成本派💰 → 04-cost.md
✅ 成本派💰 完成
✅ **检查点A：01-04文件全部存在**
🔄 **Phase B：实施派依赖执行**
⭕ 提取 KEY_OUTPUT 标记...
✅ 已提取 4份关键产出摘要
⭕ runSubagent: 实施派👨💻 → 05-implementation.md
✅ 实施派👨💻 完成
✅ **检查点B：05文件存在**
🔄 **Phase C：组装设计评审文档**
⭕ 读取 design-review-template.md 模板...
✅ 模板结构已加载
⭕ grep_search DESIGN_REVIEW 标记...
✅ 从01-05提取15个区段
⭕ 组装 06-design-review.md...
✅ 设计评审文档已生成
✅ **检查点C：后处理验证**
C1 Mermaid sequenceDiagram: ✓ 存在
C2 Mermaid classDiagram: ✓ 存在
C3 角色标注清理: ✓ 无残留
C4 XML注释: ✓ 完整
🔄 **Phase D：发布到飞书**
⭕ 逐个上传 01-06 共 6 篇文档...
✅ 6 篇文档上传成功
⭕ 创建索引文档...
✅ 索引文档已创建
📊 **交付评分卡**
{显示评分卡表格}
🎯 **交付完成：6个文件已生成 + 飞书已发布**
├── 01-architecture.md (架构派🧠)
├── 02-efficiency.md (效率派⚡)
├── 03-quality.md (质量派🛡️)
├── 04-cost.md (成本派💰)
├── 05-implementation.md (实施派👨💻) ← 编码核心参考
└── 06-design-review.md (主Agent组装) ← 评审文档
5个子Agent角色
| 角色 | 执行阶段 | 核心产出 |
|---|
| 🧠 架构派 | Phase A (独立) | 架构设计、模块划分、类图、分层定义 |
| ⚡ 效率派 | Phase A (独立) | 实现策略、代码骨架、复用分析、文件组织 |
| 🛡️ 质量派 | Phase A (独立) | 质量设计、验收标准、异常处理、测试用例 |
| 💰 成本派 | Phase A (独立) | 任务拆解(2-8h)、优先级、任务ID、依赖链 |
| 👨💻 实施派 | Phase B (依赖) | 时序图、数据结构、实现骨架、调用链、可编码性检查 |
🔴 实施派在 Phase B 执行，参考前4个角色的 KEY_OUTPUT，天然校准质量。
🔴 Phase A 的4个角色逻辑上相互独立，因工具限制按顺序启动，每个角色的 prompt 中注入隔离规则禁止读取其他角色的已有文件。
📖 Plus模式主控见 references/plus-mode.md（流程概览 + 检查点 + 输出要求）
📖 详细Prompt模板已拆分：references/context-collection.md（第0步）| references/prompts-phase-a.md（Phase A）| references/prompt-phase-b.md（Phase B）
📖 核查清单（参考材料）见 references/checklist.md
输出：可编码设计文档
🎯 标准：开发者可直接按文档编码，无需额外澄清
🔴 输出原则（强制）
⚠️ 最终输出的设计文档必须是干净的、可直接使用的
禁止包含（任一出现即不合格）：
- ❌ 生成信息：
工具: GitHub Copilot、文档生成时间:
- ❌ 角色标注：
来源: 🧠 架构派贡献
- ❌ 中间状态：
改进状态: ✅ 已整合
- ❌ 任何 "原本有问题" "已修改" 等描述
必须包含（缺一不可）：
- ✅ Mermaid时序图（
sequenceDiagram代码块）
- ✅ Mermaid类图（
classDiagram代码块）
- ✅ 接口定义含
/// <summary>注释
- ✅ 文件组织结构（树形目录）
- ✅ 任务拆解粒度2-8h（如
BE-1 (3h): xxx）
- ✅ 数据结构完整字段定义（所有Context/Result类）
- ✅ 实现骨架（核心类方法体含步骤注释）
文档结构（8章节）
- 概述 - 背景、目标、范围
- 架构设计 - 模块划分、数据流（含架构图）
- 详细设计 - 接口定义（完整签名）、数据结构
- 实现策略 - 开发顺序、代码骨架
- 质量保障 - 异常处理、边界条件、测试用例
- 资源与约束 - 工时、依赖、风险
- 开发任务拆解 - 可直接分配的任务条目
- 验收标准 - 功能/性能交付标准
接口定义标准
public interface IExporter
{
ExportResult Export(VOIData voi, string outputPath);
}
任务拆解标准
✅ 正确（每条2-8h）：
- [ ] **BE-1** (2h): 实现IExporter.Export，包含ExportFormat头构建
- [ ] **BE-2** (4h): ExportFormat文件写入，含gzip压缩
- [ ] **FE-1** (3h): SavePanel ViewModel，绑定格式选择
❌ 错误（粒度太粗）：
- [ ] 后端实现导出
- [ ] Phase 1: 40h (5天)
- [ ] 基础架构: 5天
📖 完整模板见 references/output-templates.md
Phase D: 发布到飞书（默认）
触发条件
默认执行。检查点B通过后自动进入 Phase D。
仅在以下情况跳过：
- 用户明确说「不要发飞书」「只要本地」「--local-only」
- 飞书 MCP 不可用 → 降级为本地交付 + 提示用户配置飞书 MCP
💡 参照 pbi-reviewer 步骤5 的「飞书优先、不可用时降级」模式。
🔴 内容完整性规则（禁止截断）
⚠️ 实测教训：AI 曾将设计文档"手动精简/摘要"后再上传飞书，导致关键细节丢失。
上传飞书的内容必须是本地 .md 文件的完整原始内容，禁止以下行为：
- 禁止手动摘要/精简/截断文档内容
- 禁止选择性上传部分章节
- 必须对每个文件执行
read_file("{workDir}/{文件名}") 读取完整内容，然后直接传递给飞书 API
- 如果内容超过飞书 API 单次限制，分段上传，不要删减内容
- 禁止改写/浓缩 Mermaid 代码块（
sequenceDiagram、classDiagram、flowchart 等），必须原样传递
执行流程
检查点B通过
↓
Phase D: 发布到飞书
↓
1. 确认文件: 扫描 .copilot-temp/roundtable-{id}/ 下 01~06 的 .md 文件
↓
1.5 🔴 询问用户上传策略（ask_questions）:
- 选项A（推荐）: 「完整上传全部 6 篇」— 仅移除 HTML 注释标记行，保留全部正文
- 选项B: 「仅上传设计评审主文档（06-design-review.md）」
- 选项C: 「上传全部 6 篇，过滤内部标记段落（KEY_OUTPUT / DESIGN_REVIEW 区段内容）」
> 用户选择 A → 调用 #lark-doc-generator 时传递 filterMode=strip-comments-only
> 用户选择 B → 只上传 06
> 用户选择 C → 调用 #lark-doc-generator 时使用默认过滤规则
↓
2. 逐个上传文档（调用 #lark-doc-generator）:
- 🔴 必须上传 01-06 共 6 篇文档（含 06-design-review.md）（选项B时仅上传06）
- 对每个文件执行 read_file 获取完整内容
- 将完整内容传递给飞书文档创建 API
- file_name 规则: {PBI_ID}_{序号}{简称}（≤27字符）
- 🔴 禁止手动摘要/精简/改写文档内容，必须原文传递
↓
3. 创建索引文档:
- file_name: {PBI_ID}_圆桌会议
- 内容: PBI 基本信息 + 6篇文档的飞书链接 + 每篇文档一句话摘要 + 阅读建议
- 格式: 索引文档包含直接链接，用户点击即可跳转
↓
4. 向用户返回完整链接列表（索引文档 + 6篇子文档）
索引文档模板
# {PBI_ID} 圆桌会议设计文档
## 需求信息
- PBI: {PBI_ID} - {PBI标题}
- 生成时间: {时间}
## 文档列表
| 序号 | 文档 | 链接 | 简介 |
|------|------|------|------|
| 01 | 架构设计 | [查看]({飞书链接}) | {一句话摘要} |
| 02 | 效率分析 | [查看]({飞书链接}) | {一句话摘要} |
| 03 | 质量设计 | [查看]({飞书链接}) | {一句话摘要} |
| 04 | 成本规划 | [查看]({飞书链接}) | {一句话摘要} |
| 05 | 实施方案 | [查看]({飞书链接}) | {一句话摘要} |
| 06 | 设计评审 | [查看]({飞书链接}) | {一句话摘要} |
## 阅读建议
- 评审重点看 06(设计评审文档)
- 开发同学重点看 01(架构) + 05(实施方案)
- 任务拆分看 04(成本规划)
产出物
| 序号 | 文档 | 来源 |
|---|
| 📋 | 索引文档（目录+链接） | 自动生成 |
| 01 | 架构设计 | 01-architecture.md |
| 02 | 效率分析 | 02-efficiency.md |
| 03 | 质量设计 | 03-quality.md |
| 04 | 成本规划 | 04-cost.md |
| 05 | 实施方案 | 05-implementation.md |
| 06 | 设计评审文档 | 06-design-review.md |
交付评分卡（Phase D 完成后，必须显示）
| 评分项 | 满分 | 评分标准 | 得分 |
|---|
| 本地文件 + KEY_OUTPUT | 20 | 01-05 全部存在且含 KEY_OUTPUT 标记 | ？ |
| 05 实施方案 + CODING_IMPL | 20 | 05 包含 CODING_TASK_LIST 和 CODING_IMPL 标记 | ？ |
| 飞书上传 | 15 | 6 篇文档全部成功上传（01-06，每篇2.5分） | ？ |
| 索引文档 | 10 | 索引文档已创建，包含所有 6 篇链接 | ？ |
| 总分 | 65 | | ？ |
判定规则：
- 总分 ≥ 50 → ✅ 交付完成
- 总分 < 50 → ❌ 检查缺失项，修复后重新评分
- 飞书 MCP 不可用 → 飞书上传(15) + 索引文档(10) = N/A，按满分计算
🔴 圆桌会议完成后，工作目录永久保留，禁止询问用户是否清理。 详见 references/workspace.md。
输出格式（必须显示给用户）：
📊 **交付评分卡**
| 评分项 | 满分 | 得分 | 说明 |
|--------|------|------|------|
| 本地文件 + KEY_OUTPUT | 20 | {分} | {5/5文件存在，KEY_OUTPUT完整} |
| 05 + CODING_IMPL | 20 | {分} | {CODING标记存在/缺失} |
| 飞书上传 | 15 | {分} | {N/6成功，或N/A} |
| 索引文档 | 10 | {分} | {已创建/未创建，或N/A} |
| **总分** | **65** | **{总分}** | {交付完成/需修复} |
注意事项
- Phase D 不影响 Phase A/B 的执行，即使 Phase D 失败，设计文档仍然完整交付在本地
- 飞书 MCP 不可用时，提示用户参考
#lark-doc-generator 的备选方案（本地保存/手动复制）
- 如需单独上传已有的圆桌会议文档，可直接使用
#lark-doc-generator 的批量导入模式
标准结尾（交付评分卡之后，自动输出）
---
💡 **下一步 & 对话建议**:
- 设计文档已保存到: `.copilot-temp/roundtable-{NNN}/`
- 如需基于设计文档开始编码，建议**新开对话**输入:
`根据圆桌会议 {NNN} 的设计文档开始编码`
- 在新对话中，AI 会自动读取 `05-implementation.md` 中的 CODING_TASK_LIST 和 CODING_IMPL 标记
- 本次对话已包含大量上下文，继续在此对话中操作可能影响 AI 输出质量
> ⚠️ 新对话不需要重复提供 PBI 描述或返讲文档，所有必要信息已持久化到文件中。
相关资源
