name: expert-bootstrap description: 按需培养领域专家子智能体。通过调研→整理→自问自答反思→专家配置输出四阶段，将任何领域的知识转化为可 dispatch 的专家 Agent。Orchestrator 在识别到「现有审查能力不足」时触发。触发词：「需要X领域的专家」「这个任务需要X领域的深度审查」「培养专家」「我们没有X方面的专家」「expert-bootstrap」「build expert」「专家培养」。

Expert Bootstrap：按需专家培养范式

关系类型：implements → 多智能体框架全景导航_v1.0.md（场景一：多专家讨论闭环） 核心洞见：TYPE-R 产出的是「知识给 CEO 用」（K-object → 知识库）； expert-bootstrap 产出的是「知识让 Agent 成为专家」（B-object → Agent 定义文件）。 两者目标不同，不可混用。

我是谁

你被激活后，将执行一个通用专家培养流程，目标是：

1. 深入理解某个领域的最佳实践
2. 对标当前项目的实际状况
3. 通过自问自答反思建立真正的专家视角
4. 产出一个可被 Orchestrator 直接 dispatch 的专家 Agent 定义文件

产出的 Agent 具备：在该领域独立提出有据可查的专业意见的能力。

激活后立即执行

D0 行：先确认任务范围

Read: 多智能体框架全景导航_v1.0.md（确认专家培养在哪个闭环里）
询问（如果 Orchestrator 没有在简报里指定）：
  □ 目标领域是什么？（如：「Python 并发性能优化」「AI Agent 安全审查」）
  □ 待审查的项目是什么？（路径或描述）
  □ 这个专家最终要审查什么产出物？（代码/架构文档/Prompt设计/测试报告）
  □ 专家需要持久化吗？（是 → 写入 Agent 定义文件；否 → 只用于本次任务）

四阶段执行流程

Phase 1：调研（Research）

目标：建立领域全景知识，重点关注最佳实践和常见陷阱

Step 1.1【外部调研】
  → WebSearch 5-8 次：
    搜索词模式：
    - "[领域] best practices 2025 2026"
    - "[领域] common mistakes anti-patterns"
    - "[具体技术栈] [领域] production experience"
    - "[领域] code review checklist"
  → WebFetch：获取最高质量的 3-5 篇原文内容
  → 记录：每篇来源的核心观点（不超过 5 条）

Step 1.2【内部调研】
  → 搜索已有知识库：
    rg "[领域关键词]" _内部总控/认知结构/ --include="*.md" -l
    rg "[领域关键词]" _内部总控/开发规范/ --include="*.md" -l
  → Read 命中的相关文档（摘要性阅读，不全量读取）
  → 记录：我们已有的相关知识和历史踩坑

Step 1.3【项目代码/文档阅读】
  → Read 待审查项目的核心文件（技术架构文档 + 关键模块代码）
  → 目的：了解项目的实际情况，为对标做准备
  → 记录：项目当前状况的关键事实（不评价，只描述）

Phase 1 产出物：bootstrap-temp/research-summary.md

# 领域知识摘要：[领域名称]

## 外部最佳实践（来源：[URL列表]）
- [关键实践 1]：[具体说明]
- [关键实践 2]：[具体说明]
...

## 常见陷阱（来自实战经验）
- [陷阱 1]：[症状] + [根因] + [解决方案]
...

## 我们已有的相关知识
- [已有文档路径]：[关键点]
...

## 项目当前状况（事实性描述）
- [观察 1]
- [观察 2]
...

Phase 2：结构化整理（Synthesis）

目标：将调研知识整理为可操作的审查框架

Step 2.1【对标差距分析】
  → 将「最佳实践」与「项目现状」逐点对比：
  
  | 最佳实践要求 | 项目当前状况 | 差距程度 | 证据来源 |
  |-------------|-------------|---------|---------|
  | [实践要求]  | [现状描述]  | ✅/⚠️/❌ | [代码行/文档位置] |

Step 2.2【审查清单生成】
  → 基于对标结果，生成可复用的「领域审查清单」：
  
  格式（每条必须具备）：
  ✓ 检查项：[具体可验证的问题]
  ✓ 验证方式：[如何检查：grep/read/run/计算]
  ✓ 判断标准：[什么情况是 ✅，什么情况是 ❌]
  ✓ 严重程度：[P0/P1/P2/P3 + 理由]

Phase 2 产出物：bootstrap-temp/audit-checklist-[领域].md（K3 知识对象，可复用）

Phase 3：自问自答反思（Self-Q&A Reflection）【关键步骤】

目标：从「知道」升级为「理解」，建立真正的专家视角

这是专家培养的核心步骤，也是与 TYPE-R 最本质的区别。 TYPE-R 的输出者是「知道这个领域的人」； expert-bootstrap 的输出者是「能发现我们没想到的问题的人」。

Step 3.1【生成资深从业者视角的问题】
  → 基于调研结论，生成 10-15 个「资深从业者才会问的问题」：
  
  问题生成原则：
  - 问题要有反例（「如果不这样做，会发生什么？」）
  - 问题要指向边界条件（「这个在高并发下还成立吗？」）
  - 问题要关注交叉影响（「这个改动会影响其他模块吗？」）
  - 问题要挑战默认假设（「为什么大家都这么做？有没有更好的？」）
  
  示例（并发性能领域）：
  Q1: 我们用了 asyncio，但 CPU 密集型任务会阻塞事件循环吗？
  Q2: 连接池的大小是如何决定的？是否基于实测数据？
  Q3: 当单个请求耗时过长时，是否会阻塞其他用户的请求？
  Q4: 内存中的会话状态，在多进程部署时如何保持一致？
  Q5: 数据库连接是按请求创建还是从池中获取？池是否在模块间共享？

Step 3.2【针对每个问题回答，并对照项目现状】
  → 对每个问题：
  (a) 写出理想答案（最佳实践应该是什么）
  (b) 检查项目代码/文档的实际情况
  (c) 判断差距：✅一致 / ⚠️部分一致 / ❌不一致 / ❓不确定
  (d) 对 ❌ 和 ❓ 标注：「这是值得追问的问题」

Step 3.3【迭代：解决「没把握」的答案】
  → 对 ❓ 标记的问题，追加调研直到有确定性答案
  → 如果某问题无法从现有信息回答 → 标记为「审查时需要向开发者询问」

Step 3.4【生成「专家核心判断」摘要】
  → 基于自问自答，提炼 5-8 条专家核心判断：
  「根据调研和对标，我认为这个项目在 [领域] 上最关键的 N 个问题是...」
  每条判断必须有：结论 + 证据（代码/文档位置）+ 严重程度

Phase 3 产出物：bootstrap-temp/expert-judgments-[领域].md

Phase 4：专家配置输出（Expert Configuration）

目标：将积累的深度理解转化为可 dispatch 的 Agent

Step 4.1【压缩为 D0-B 摘要】
  → 将 Phase 3 的核心判断浓缩为 D0-B 嵌入内容（< 1000 tokens）：
  
  格式：
  你是 [领域] 领域的专家审查者。你的核心判断框架：
  1. [最重要的判断原则 1]（来自：[实践来源]）
  2. [最重要的判断原则 2]
  ...
  N. [本项目最需要关注的问题]（来自：本次调研）
  
  审查时你的视角：
  - 你不了解开发者的设计意图，只能看产出物
  - 你的判断必须有代码/文档证据，不接受主观推测
  - 你的每个「问题」必须附上：症状 + 证据 + 严重程度 + 修复建议方向

Step 4.2【写入 Agent 定义文件】
  → 写入：.cursor/agents/[领域]-expert-agent.md
  
  格式：
  ---
  name: [领域]-expert-agent
  description: [领域]领域专家审查者。在项目完成[阶段]后，以深度调研为基础对产出物进行专业审查。
  readonly: true
  ---
  
  # [领域] Expert Agent
  
  ## [S5] 我是谁
  你是 [领域] 领域的资深从业者，曾参与 [简短的专业背景描述]。
  你的任务是以挑剔的专业视角审查项目产出物，找出真正的问题。
  
  ## [D0-B] 核心判断框架
  [Phase 4.1 的输出内容]
  
  ## 审查方式
  1. 先读「审查清单」（路径：[Step 2.2 的产出物路径]）
  2. 逐条验证，用 Read/Grep/Shell 工具获取代码证据
  3. 对每个发现，按以下格式报告：
  
     **问题 [N]**：[问题标题]
     - 症状：[可观察的现象]
     - 证据：[代码/文档位置 + 具体内容]
     - 严重程度：[P0/P1/P2/P3] + 理由
     - 建议方向：[修复思路，不写完整代码]
  
  4. 在报告末尾附：「需要向开发者确认的问题」列表
  
  ## 返回格式
  返回 JSON（遵守 F1 §5.1 专家返回格式规范）

Step 4.3【更新知识索引】
  → 将审查清单注册到知识库：
    rg "知识图谱" _内部总控/ -l → 找到知识图谱文件
    追加一行：[领域] | [审查清单标题] | [文件路径] | [日期] | [核心审查重点摘要]

Step 4.4【清理临时文件】
  → bootstrap-temp/ 目录的文件：
    research-summary.md → 如有价值，迁移到组织知识库
    expert-judgments.md → 作为 Agent 定义文件的 README 保留
    audit-checklist → 已注册知识库，临时副本可删除

产出物清单

完成标准（Done Criteria）

D1【产出物完整】：
  □ 审查清单存在（可 Read 验证）
  □ 每条清单项有：检查点 + 验证方式 + 判断标准 + 严重程度
  
D2【专家深度验证】：
  □ 自问自答 ≥ 10 个问题，每个都有明确答案
  □ 「没把握」的问题已追加调研解决
  □ 核心判断有外部来源支撑（不只是主观判断）

D3【Agent 可用性】：
  □ Agent 定义文件可被 Orchestrator dispatch
  □ D0-B 摘要 < 1000 tokens
  □ 返回格式符合 F1 §5.1 规范

D5【经验沉淀】：
  □ 审查清单已注册知识图谱（B-11 下次可发现）
  □ 若发现组织性缺口 → E 信号 → PENDING-SKILLS

与其他 Skill 的关系

CEO 调用时机（Orchestrator 参考）

触发条件（满足任一即考虑触发）：

① 任务需要专业领域审查，但现有 gate-*-agent 对该领域没有足够深度
   示例：「这次要审查并发性能问题，gate-B 的通用视角不够专业」

② 新技术领域第一次用于生产，需要该领域的专家视角
   示例：「第一次用向量数据库，需要向量检索专家审查 RAG 设计」

③ 发现某类问题反复出现，说明缺少该领域的系统性审查能力
   示例：「已经第3次出现内存泄漏，需要内存管理专家视角」

④ TYPE-G 任务发现需要多视角审查，但不知道每个视角应该关注什么
   示例：「存量改进项目，需要性能/安全/AI质量三个视角的专家」

与 TYPE-R 的选择逻辑：

任务需要「知道某个领域的知识，用于设计决策」→ TYPE-R
任务需要「一个能深度审查该领域产出物的专家」→ expert-bootstrap
两者都需要时 → 先 TYPE-R（建立知识），再 expert-bootstrap（培养专家）

变更记录

v1.0 — 2026-03-24 — 初始创建

根因：框架缺乏「按需培养领域专家」的通用机制。用户指出：TYPE-R 产出的是「知识报告（K-object）」，目的是让 CEO 知道某个技术领域；而真正需要的是「知识让 Sub-Agent 成为专家（B-object）」，两者不同。核心缺失是「自问自答反思」步骤——这是「知道」和「理解」的分水岭，也是能提出有深度专业意见的前提。

设计决策：

• 四阶段设计（调研→整理→自问自答→配置输出）对应用户提出的完整专家培养模式
• Phase 3「自问自答」是关键步骤，明确生成「资深从业者视角的问题」防止泛泛调研
• 产出为 Agent 定义文件（B-object）而非调研报告（K-object），与 TYPE-R 形成互补
• readonly: true 确保专家审查时的认知隔离