Expert Solution Workflow

---
name: expert-solution-workflow
description: 资产复用工作流。区分"业务专家团"与"解决方案"两类可复用资产的本质差异；遇到业务模块任务先查 expert-lookup，遇到具体技术问题先查 solution-lookup，解决后可复用问题用 solution-capture 沉淀、可复用模块用 expert-team 沉淀。当用户说"查专家"、"有没有现成方案"、"沉淀一下"、"记录解决方案"、"建专家团"，或遇到/解决问题时自动触发。
---

# 资产复用工作流（专家团 + 解决方案）

## 概述

**目的**：让 AI 在遇到问题、解决问题或沉淀知识时，先判断问题类型，再按对应链路查找/沉淀可复用资产，避免重复排查与知识流失。

**功能**：问题分类路由（业务模块类 → expert-lookup，技术问题类 → solution-lookup）；沉淀路由（可复现场景 → solution-capture，可复用模块 → expert-team，一行事实 → update_memory）；ki 项目记忆沉淀。

**使用场景**：
- AI 遇到问题需要查找已有资产时（前置调用 `use_skill("ki-search-first")`）
- AI 解决问题后评估是否沉淀时
- 用户说"查专家"、"查解决方案"、"沉淀一下"、"建专家团"时

## 规则

AI 在遇到问题、解决问题或沉淀知识时，**必须先判断问题类型，再按对应链路查找/沉淀可复用资产**：

| 时机 | 问题类型 | 调用技能 |
|------|----------|----------|
| 遇到问题时 | 业务模块类（使用/接手/排查/修改某模块、跨域任务） | `expert-lookup` |
| 遇到问题时 | 具体技术问题类（报错、配置、部署失败、踩坑） | `solution-lookup` |
| 解决问题后 | 解决过程非平凡（3步以上、试错、查文档） | `solution-capture` |
| 深入掌握模块后 | 模块领域专属且复杂度/规模达标 | `expert-team` |

**两类资产的本质区别**：

- **专家团**：针对**领域**，是"地图"。沉淀某业务模块的全景知识（契约层 C0~C4 + 实现层 implementation/）。回答"这个模块是干嘛的、怎么用、代码怎么组织"。使用时**加载导航**——你仍需读代码/推理（用→导航→确认）。类似顾问：不直接给具体问题的解法，但通过它能知道往哪查、去哪改。
- **解决方案**：针对**场景**，是"菜谱"。沉淀某具体问题的操作配方（单 SKILL.md：场景/问题/步骤/注意事项）。回答"这个报错/配置问题怎么一步步解决"。使用时**直接执行**——按步骤照做，不需重新推理。

**关键判断信号**：

| 场景特征 | 走哪条路 |
|----------|----------|
| 排查模块问题前先懂模块 | 先专家团 → 再查解决方案 |
| 解决完一个可复现问题 | 沉淀为解决方案 |
| 需要持久掌握一个模块（反复使用/排查/交接） | 沉淀为专家团 |

## 执行

### 查找流程（遇到问题时）

```
1. ki-search 项目记忆检索（前置 skill `ki-search-first`，use_skill("ki-search-first") 必做，
   无论是否命中）→ 先看记忆里有什么相关内容
2. 判断问题类型
   ├─ 业务模块类 → use_skill("expert-lookup")
   │    → 有专家？→ 记录命中的专家（暂不加载内容）
   │    → 无专家？→ 记录"无专家"
   └─ 具体技术问题类 → 判断非平凡？
        ├─ 是 → use_skill("solution-lookup") → 有方案？→ 记录命中的方案（暂不加载内容）
        │                                        → 无方案？→ 记录"无方案"
        └─ 否 → 直接解决
3. 带着记忆内容，再加载专家/方案内容 → 交叉参照 → 求解
4. 专家、方案、记忆均未命中 → 查代码库 → 从头排查
```

**非平凡问题判定**（满足任一）：需要 3 个以上步骤；需查找文档/试错/调试；问题可复现；含非显而易见技巧；涉及特定工具/框架的坑。

### 沉淀流程（解决问题后）

```
1. 沉淀前先走 loop-discovery 路由（use_skill("loop-discovery")：证据门/覆盖阶梯/载体选择）
   → 决定是否值得沉淀、选哪个载体
2. 按路由结论选择载体
   ├─ 场景可复现 → use_skill("solution-capture") → 写入 .solutions/ + 更新 INDEX.md
   ├─ 模块可复用（领域专属 + 复杂度/规模达标）→ use_skill("expert-team")
   └─ 一行事实/偏好 → update_memory
3. 判断值得沉淀的，均须做 ki-search 项目记忆沉淀（必须步骤）：
   - 将专家团/解决方案产出的内容**拆分**后**分步骤写入**项目记忆（ki-search 可搜索，
     后续可直接检索复用）
   - 只记录**有价值的关键内容**，不全量复制原文。典型可沉淀信息：
     - **专家团类**：模块关键类/方法的代码位置（如 `OrderService.createOrder` →
       `pkg/order/service.go:120`）、核心设计决策与原因、模块间依赖要点、已知坑
     - **解决方案类**：工具函数的代码位置（如 `utils/time.py::parse_iso8601`）、某个类的
       使用小技巧（如 `HttpClient` 需先 `set_retry` 否则默认无超时）、零碎但关键的踩坑经验
       （如"JDK17 下该库需加 `--add-opens`"）、配置项特殊值
```

**专家团链路**：使用/调用模块 → 加载契约层照用；诊断/排查 → C0+已知坑+数据流导航+读源码；跨域任务 → 多专家协同（≤3）；修改/扩展 → C0+架构导航+读源码。找不到专家时正常读代码，排查后建议用 `expert-team` 沉淀（公共/横切知识不建专家，转存项目记忆）。

**解决方案链路**：按步骤执行 SKILL.md，注意"注意事项"；方案不完全适用时结合实际调整。无现成方案时正常排查，解决后可建议用 `solution-capture` 沉淀。

## 例外

以下情况跳过 `expert-lookup`：
- 问题与具体模块无关（纯技术问题走 solution-lookup）
- 用户明确说"不用查专家"、"直接读代码"

以下情况跳过 `solution-lookup`：
- 问题明显平凡（一行能解决）
- 用户明确说"不用查"、"直接解决"

以下情况跳过 `solution-capture`：
- 解决过程平凡（常规操作）
- 问题一次性、不会再现
- 已有相同解决方案存在且无需更新
- 用户明确说"不用记录"、"跳过沉淀"

以下情况跳过 `expert-team`：
- 模块属公共/横切知识（工具库、代码风格约定、通用封装）
- 模块规模小、逻辑简单（直接读代码或 module-teach 讲解）
- 用户明确说"不用建专家"