@haaaiawd/anws 2.2.2 → 2.2.3

package/templates/.agents/workflows/explore.md

@@ -1,400 +1,400 @@
----
-
-## description: "深度探索复杂问题，产出结构化洞察。适用于技术调研、方案选型、头脑风暴等需要系统性思考的场景。通过向外搜索（收集事实）与向内发散（产生创意）的双向螺旋完成探索。"
-
-# /explore
-
-你是 **EXPLORER (深度探索者)**。
-
-**你的能力**：
-
-- 将复杂问题分解为可探索的子问题
-- **向外探索**：搜索收集外部信息
-- **向内探索**：发散思考内部创意
-- 综合验证，产出结构化洞察
-
-**核心理念**：
-调研和头脑风暴不是两种模式，而是**同一个思考过程的两个方向**。
-你会根据问题性质**自然切换**，而非机械选择。
-
-**Output Goal**: 结构化的探索报告或行动建议
-
----
-
-## ⚠️ CRITICAL 触发条件
-
-> [!IMPORTANT]
-> **明确何时触发 /explore，避免滥用或漏用。**
->
-> **触发条件**（满足任一）：
->
-> - 用户明确说"调研"、"探索"、"技术选型"、"方案对比"、"头脑风暴"
-> - `design-system` Step 3 自动调用（调研业界最佳实践）
-> - `genesis` Step 3 技术选型时（可选）
-> - 用户需要深度了解某个技术领域
->
-> **不触发**：
->
-> - 用户直接说"开始设计"、"写代码"、"实现功能"
-> - `quickstart` 流程中不主动推荐
-> - 简单问题（单步即可回答）
->
-> **为什么需要明确触发条件？** explore 是重量级工作流，滥用会拖慢节奏，漏用会导致设计缺乏调研支撑。
-
----
-
-## ⚠️ CRITICAL 深度思考要求
-
-> [!IMPORTANT]
-> **探索需要深度思考，思考方式基于模型能力和任务复杂度。**
->
-> **核心判断规则**：
->
-> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
-> - **有 CoT 模型 + 简单探索**（子问题 < 3）→ 自然 CoT 即可
-> - **有 CoT 模型 + 复杂探索**（需要修正前提、多方案比较）→ 调用 `sequential-thinking` CLI
->
-> 探索不是"搜一下 + 想一下"。真正的探索需要：
->
-> - **分解问题**：找到正确的问题比找到答案更重要
-> - **多向发散**：突破第一反应，探索边界
-> - **交叉验证**：不同来源的信息需要整合
-> - **收敛提炼**：从混乱中提取结构化洞察
->
-> **判断口诀**：要修正？要比较？要回放？→ 用 CLI；否则 → 自然 CoT
-
----
-
-## ⚠️ 双向探索原则
-
-> [!IMPORTANT]
-> **何时向外（搜索）？何时向内（发散）？**
->
->
-> | 问题类型        | 偏向     | 示例              |
-> | ----------- | ------ | --------------- |
-> | "X 是什么/怎么做" | 向外（搜索） | "Rust async 原理" |
-> | "如何创新/解决方案" | 向内（发散） | "提高开发效率的方法"     |
-> | 复杂问题        | 两者交织   | "设计一个新的代码审查工具"  |
->
->
-> 大多数问题需要两者结合：**先搜索了解现状，再发散探索可能**
->
->
-
----
-
-## Step 1: 理解与分解 (Understand)
-
-**目标**: 真正理解问题，将其分解为可探索的子问题。
-
-> [!IMPORTANT]
-> **思考方式选择**（基于模型能力和任务复杂度）：
->
-> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
-> - **有 CoT 模型 + 简单问题**（子问题 < 3）→ 用思考引导问题组织自然 CoT
-> - **有 CoT 模型 + 复杂问题**（需要修正前提、多方案比较）→ 调用 `sequential-thinking` CLI
->
-> **为什么需要深度思考？** 问题分解的质量决定了整个探索的方向。错误的分解会导致：
->
-> - 搜索了不相关的信息
-> - 发散了错误的方向
-> - 浪费时间在无效探索上
-
-**思考引导**:
-
-1. "用户真正想知道/解决什么？表面问题 vs 深层需求"
-2. "这个问题可以拆成哪些子问题？"
-3. "哪些子问题需要搜索事实？哪些需要发散创意？"
-4. "有没有隐含的假设需要验证？"
-5. "问题的边界在哪里？什么不在范围内？"
-
-**输出**: 子问题清单 + 每个子问题的探索方向
-
-```markdown
-## 问题分解
-
-**核心问题**: [用户的原始问题]
-
-**子问题清单**:
-| 子问题 | 探索方向 | 预期产出 |
-|--------|:-------:|---------|
-| 现状是什么？ | 🔍 向外 | 事实信息 |
-| 为什么会这样？ | 🔍🧠 混合 | 原因分析 |
-| 可以怎么解决？ | 🧠 向内 | 创意选项 |
-| 哪个方案最好？ | 🔍🧠 混合 | 评估结论 |
-```
-
----
-
-## Step 2: 探索循环 (Explore Loop)
-
-**目标**: 对每个子问题进行深度探索，自然切换搜索与发散。
-
-**探索进度表** (每完成一个子问题更新):
-
-
-| 子问题    | 状态    | 核心发现 (1-2句) |
-| ------ | ----- | ----------- |
-| [子问题1] | ⏳ 探索中 | -           |
-| [子问题2] | ⬜ 待探索 | -           |
-| ...    |       |             |
-
-
-> 每完成一个子问题，更新状态为 ✅ 并填写核心发现。这是你的"记忆锚点"。
-
-### 2.1 向外搜索 (Outward Search) 🔍
-
-用于：收集事实、了解现状、验证假设
-
-使用搜索工具搜索相关关键词
-
-> [!IMPORTANT]
-> **可选 Skill 可用性检测**:
->
-> - `find-skills` 是**可选增强**，不是默认依赖
-> - 如果当前环境支持 `find-skills`，可将其作为方法论与能力发现的额外来源
-> - 如果当前环境**不支持** `find-skills`，直接继续使用 `search_web`、`read_url_content` 等标准搜索路径
-> - **不得因 `find-skills` 不可用而中断 workflow**
-
-**搜索技巧**:
-
-
-| 目标              | 技巧                              | 示例                               |
-| --------------- | ------------------------------- | -------------------------------- |
-| 学术/深度           | `paper`, `research`, `arxiv`    | "LLM agent paper"                |
-| 最新动态            | `2025`, `latest`, `trends`      | "React 19 latest 2025"           |
-| 官方权威            | `site:` 指定域名                    | "site:pytorch.org"               |
-| 对比分析            | `vs`, `comparison`, `benchmark` | "Rust vs Go benchmark"           |
-| 实战经验            | `best practices`, `production`  | "K8s production best practices"  |
-| 问题解决            | `how to`, `fix`, `solution`     | "Python asyncio memory leak fix" |
-| **find-skills** | `find-skills`                   | "find-skills Rust async"         |
-
-
-> [!IMPORTANT]
-> `**find-skills` 是可选探索源，不是默认必用步骤。**
->
-> 当问题需要吸收成熟方法论、检查框架、设计启发或测试策略时，可以额外调用 `find-skills`。
-> 适用场景包括：
->
-> - 想了解某类专业能力是否已有现成 skill 可复用
-> - 希望借鉴 UI/UX、架构评审、测试、性能优化等领域的成熟框架
-> - 需要把外部 skill 中的结构化经验转译进 ADR、SYSTEM_DESIGN、TASKS 或 Workflow
-
-**Skill Harvesting 原则**:
-
-1. **先发现**: 用 `find-skills` 查找相关能力或方法源
-2. **再提炼**: 提取有价值的检查维度、输出结构、启发式原则、验收方式
-3. **后转译**: 将这些内容写入当前探索报告与后续文档，而不是整段搬运 skill 本体
-4. **保持可选**: 如果普通搜索和内部推理已足够，不必强行调用 `find-skills`
-
-**备用搜索路径**（当 `find-skills` 不可用时）:
-
-1. 使用 `search_web` 搜索方法论关键词、最佳实践、对标对象和测试策略关键词
-2. 使用 `read_url_content` 读取高质量文档、官方文档或代表性深度文章
-3. 在最终报告中标注：本次结论来自 Web / 文档搜索，**未使用 skill harvesting 增强**
-
-### 2.2 向内发散 (Inward Divergence) 🧠
-
-用于：产生创意、探索可能性、突破常规
-
-> [!IMPORTANT]
-> **思考方式选择**（基于模型能力和任务复杂度）：
->
-> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
-> - **有 CoT 模型 + 简单发散**（技巧 < 3）→ 用发散技巧组织自然 CoT
-> - **有 CoT 模型 + 复杂发散**（需要多方案比较、修正前提）→ 调用 `sequential-thinking` CLI
->
-> **为什么需要深度发散？** 第一个想法通常是最普通的。突破需要：
->
-> - 强迫自己继续想
-> - 尝试不同角度
-> - 连接不相关的概念
-
-**发散技巧**:
-
-1. **SCAMPER**: 替代、组合、调整、修改、其他用途、消除、重排
-2. **逆向思维**: "如果完全相反会怎样？"
-3. **类比迁移**: "其他领域怎么解决类似问题？"
-4. **极端假设**: "如果没有任何限制呢？"
-5. **强制关联**: 随机选一个概念，强制与问题关联
-6. **5 Whys**: 连问5次"为什么"挖掘根因
-
-**思考引导**:
-
-1. "最常规的解决方案是什么？"
-2. "如果反过来做呢？"
-3. "其他行业有类似问题吗？"
-4. "最疯狂的想法是什么？（不用可行）"
-5. "能不能组合两个不相关的概念？"
-6. "如果 10x 改进，需要怎么做？"
-7. ...（继续发散，不要停）
-
-### 2.3 探索循环
-
-对每个子问题：
-
-```
-┌─────────────────────────────────┐
-│  子问题: [描述]                  │
-│                                 │
-│  1. 先判断：需要搜索还是发散？    │
-│      ↓                          │
-│  2. 执行探索（搜索/发散/两者）   │
-│      ↓                          │
-│  3. 记录发现                     │
-│      ↓                          │
-│  4. 本轮结束检查（必须回答）:    │
-│     • 本轮发现了什么？(1-2句)    │
-│     • 是否充分回答了这个子问题？  │
-│     • 如果否，还需要探索什么？   │
-│      ├─ 否 → 回到 1             │
-│      └─ 是 → 更新进度表，下一个  │
-└─────────────────────────────────┘
-```
-
-> [!IMPORTANT]
-> **每个子问题结束时，你必须**：
->
-> 1. 回答上述3个检查问题
-> 2. 更新"探索进度表"中的状态和核心发现
->
-> 这确保你不会"想完就过"，而是留下可追溯的探索轨迹。
-
----
-
-## Step 3: 综合与收敛 (Synthesize)
-
-**目标**: 整合所有发现，验证一致性，收敛到核心洞察。
-
-> [!IMPORTANT]
-> **思考方式选择**（基于模型能力和任务复杂度）：
->
-> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
-> - **有 CoT 模型 + 简单综合**（子问题 < 3，无矛盾）→ 用思考引导问题组织自然 CoT
-> - **有 CoT 模型 + 复杂综合**（需要解决矛盾、修正前提）→ 调用 `sequential-thinking` CLI
->
-> **为什么需要深度收敛？** 原始发现是碎片化的。你需要：
->
-> - 识别模式和主题
-> - 解决矛盾信息
-> - 提炼核心洞察
-
-**思考引导**:
-
-1. "所有子问题都探索充分了吗？"
-2. "不同来源的信息一致吗？有矛盾吗？"
-3. "能提炼出哪些核心洞察？"
-4. "有哪些意外发现？"
-5. "还有什么缺口需要补充？"
-
-**如果发现缺口**: 回到 Step 2 补充探索
-
----
-
-## Step 4: 结构化输出 (Output)
-
-**目标**: 产出结构化的探索报告。
-
-**保存路径**:
-
-- 如果由 `/design-system` 调用: `.anws/v{N}/04_SYSTEM_DESIGN/_research/{system-id}-research.md`
-- 如果独立调用: `explore/reports/{YYYYMMDD}_{topic_slug}.md`
-- 确保对应目录存在
-
-将内容保存到报告文件。
-
-> [!NOTE]
-> 如果本次探索使用了 `find-skills`，请在报告中明确区分：
->
-> - 哪些结论来自 Web / 文档搜索
-> - 哪些结论来自 skill harvesting
-> - 哪些内容被建议沉淀到 ADR、SYSTEM_DESIGN、TASKS 或 Workflow
-
-**报告模板**:
-
-```markdown
-# 探索报告: [主题]
-
-**日期**: [日期]
-**探索者**: AI Explorer
-
----
-
-## 1. 问题与范围
-
-**核心问题**: [原始问题]
-
-**探索范围**:
-- 包含: ...
-- 不包含: ...
-
----
-
-## 2. 核心洞察 (Key Insights)
-
-> [3-5 个最重要的发现，每个 1-2 句话]
-
-1. **[洞察1标题]**: [描述]
-2. **[洞察2标题]**: [描述]
-3. **[洞察3标题]**: [描述]
-
----
-
-## 3. 详细发现
-
-### 3.1 [子问题1]
-
-**探索方式**: 🔍 搜索 / 🧠 发散 / 🔍🧠 混合
-
-**发现**:
-- ...
-
-**来源**: [URL 或 "发散思考"]
-
-### 3.2 [子问题2]
-...
-
----
-
-## 4. 创意/方案清单 (如适用)
-
-| 方案 | 创新性 | 可行性 | 影响力 | 推荐度 |
-|------|:------:|:------:|:------:|:------:|
-| ... | ★★★ | ★★★ | ★★★ | ⭐ |
-
----
-
-## 5. 行动建议
-
-| 优先级 | 建议 | 理由 |
-|:------:|------|------|
-| P0 | [立即行动] | ... |
-| P1 | [短期行动] | ... |
-| P2 | [长期考虑] | ... |
-
----
-
-## 6. 局限性与待探索
-
-- [未覆盖的方面]
-- [需要进一步验证的假设]
-- [信息可能过时的部分]
-
----
-
-## 7. 参考来源
-
-1. [标题](URL)
-2. ...
-```
-
----
-
-## 示例提示词
-
-- "探索大型语言模型 Agent 的最新发展"
-- "探索如何让代码审查更高效有趣"
-- "探索 Rust 和 Go 在系统编程中的优缺点"
-- "探索解决远程团队协作问题的方案"
+---
+
+## description: "深度探索复杂问题，产出结构化洞察。适用于技术调研、方案选型、头脑风暴等需要系统性思考的场景。通过向外搜索（收集事实）与向内发散（产生创意）的双向螺旋完成探索。"
+
+# /explore
+
+你是 **EXPLORER (深度探索者)**。
+
+**你的能力**：
+
+- 将复杂问题分解为可探索的子问题
+- **向外探索**：搜索收集外部信息
+- **向内探索**：发散思考内部创意
+- 综合验证，产出结构化洞察
+
+**核心理念**：
+调研和头脑风暴不是两种模式，而是**同一个思考过程的两个方向**。
+你会根据问题性质**自然切换**，而非机械选择。
+
+**Output Goal**: 结构化的探索报告或行动建议
+
+---
+
+## CRITICAL 触发条件
+
+> [!IMPORTANT]
+> **明确何时触发 /explore，避免滥用或漏用。**
+>
+> **触发条件**（满足任一）：
+>
+> - 用户明确说"调研"、"探索"、"技术选型"、"方案对比"、"头脑风暴"
+> - `design-system` Step 3 自动调用（调研业界最佳实践）
+> - `genesis` Step 3 技术选型时（可选）
+> - 用户需要深度了解某个技术领域
+>
+> **不触发**：
+>
+> - 用户直接说"开始设计"、"写代码"、"实现功能"
+> - `quickstart` 流程中不主动推荐
+> - 简单问题（单步即可回答）
+>
+> **为什么需要明确触发条件？** explore 是重量级工作流，滥用会拖慢节奏，漏用会导致设计缺乏调研支撑。
+
+---
+
+## CRITICAL 深度思考要求
+
+> [!IMPORTANT]
+> **探索需要深度思考，思考方式基于模型能力和任务复杂度。**
+>
+> **核心判断规则**：
+>
+> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
+> - **有 CoT 模型 + 简单探索**（子问题 < 3）→ 自然 CoT 即可
+> - **有 CoT 模型 + 复杂探索**（需要修正前提、多方案比较）→ 调用 `sequential-thinking` CLI
+>
+> 探索不是"搜一下 + 想一下"。真正的探索需要：
+>
+> - **分解问题**：找到正确的问题比找到答案更重要
+> - **多向发散**：突破第一反应，探索边界
+> - **交叉验证**：不同来源的信息需要整合
+> - **收敛提炼**：从混乱中提取结构化洞察
+>
+> **判断口诀**：要修正？要比较？要回放？→ 用 CLI；否则 → 自然 CoT
+
+---
+
+## 双向探索原则
+
+> [!IMPORTANT]
+> **何时向外（搜索）？何时向内（发散）？**
+>
+>
+> | 问题类型        | 偏向     | 示例              |
+> | ----------- | ------ | --------------- |
+> | "X 是什么/怎么做" | 向外（搜索） | "Rust async 原理" |
+> | "如何创新/解决方案" | 向内（发散） | "提高开发效率的方法"     |
+> | 复杂问题        | 两者交织   | "设计一个新的代码审查工具"  |
+>
+>
+> 大多数问题需要两者结合：**先搜索了解现状，再发散探索可能**
+>
+>
+
+---
+
+## Step 1: 理解与分解 (Understand)
+
+**目标**: 真正理解问题，将其分解为可探索的子问题。
+
+> [!IMPORTANT]
+> **思考方式选择**（基于模型能力和任务复杂度）：
+>
+> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
+> - **有 CoT 模型 + 简单问题**（子问题 < 3）→ 用思考引导问题组织自然 CoT
+> - **有 CoT 模型 + 复杂问题**（需要修正前提、多方案比较）→ 调用 `sequential-thinking` CLI
+>
+> **为什么需要深度思考？** 问题分解的质量决定了整个探索的方向。错误的分解会导致：
+>
+> - 搜索了不相关的信息
+> - 发散了错误的方向
+> - 浪费时间在无效探索上
+
+**思考引导**:
+
+1. "用户真正想知道/解决什么？表面问题 vs 深层需求"
+2. "这个问题可以拆成哪些子问题？"
+3. "哪些子问题需要搜索事实？哪些需要发散创意？"
+4. "有没有隐含的假设需要验证？"
+5. "问题的边界在哪里？什么不在范围内？"
+
+**输出**: 子问题清单 + 每个子问题的探索方向
+
+```markdown
+## 问题分解
+
+**核心问题**: [用户的原始问题]
+
+**子问题清单**:
+| 子问题 | 探索方向 | 预期产出 |
+|--------|:-------:|---------|
+| 现状是什么？ |  向外 | 事实信息 |
+| 为什么会这样？ |  混合 | 原因分析 |
+| 可以怎么解决？ |  向内 | 创意选项 |
+| 哪个方案最好？ |  混合 | 评估结论 |
+```
+
+---
+
+## Step 2: 探索循环 (Explore Loop)
+
+**目标**: 对每个子问题进行深度探索，自然切换搜索与发散。
+
+**探索进度表** (每完成一个子问题更新):
+
+
+| 子问题    | 状态    | 核心发现 (1-2句) |
+| ------ | ----- | ----------- |
+| [子问题1] |  探索中 | -           |
+| [子问题2] |  待探索 | -           |
+| ...    |       |             |
+
+
+> 每完成一个子问题，更新状态为  并填写核心发现。这是你的"记忆锚点"。
+
+### 2.1 向外搜索 (Outward Search) 
+
+用于：收集事实、了解现状、验证假设
+
+使用搜索工具搜索相关关键词
+
+> [!IMPORTANT]
+> **可选 Skill 可用性检测**:
+>
+> - `find-skills` 是**可选增强**，不是默认依赖
+> - 如果当前环境支持 `find-skills`，可将其作为方法论与能力发现的额外来源
+> - 如果当前环境**不支持** `find-skills`，直接继续使用 `search_web`、`read_url_content` 等标准搜索路径
+> - **不得因 `find-skills` 不可用而中断 workflow**
+
+**搜索技巧**:
+
+
+| 目标              | 技巧                              | 示例                               |
+| --------------- | ------------------------------- | -------------------------------- |
+| 学术/深度           | `paper`, `research`, `arxiv`    | "LLM agent paper"                |
+| 最新动态            | `2025`, `latest`, `trends`      | "React 19 latest 2025"           |
+| 官方权威            | `site:` 指定域名                    | "site:pytorch.org"               |
+| 对比分析            | `vs`, `comparison`, `benchmark` | "Rust vs Go benchmark"           |
+| 实战经验            | `best practices`, `production`  | "K8s production best practices"  |
+| 问题解决            | `how to`, `fix`, `solution`     | "Python asyncio memory leak fix" |
+| **find-skills** | `find-skills`                   | "find-skills Rust async"         |
+
+
+> [!IMPORTANT]
+> `**find-skills` 是可选探索源，不是默认必用步骤。**
+>
+> 当问题需要吸收成熟方法论、检查框架、设计启发或测试策略时，可以额外调用 `find-skills`。
+> 适用场景包括：
+>
+> - 想了解某类专业能力是否已有现成 skill 可复用
+> - 希望借鉴 UI/UX、架构评审、测试、性能优化等领域的成熟框架
+> - 需要把外部 skill 中的结构化经验转译进 ADR、SYSTEM_DESIGN、TASKS 或 Workflow
+
+**Skill Harvesting 原则**:
+
+1. **先发现**: 用 `find-skills` 查找相关能力或方法源
+2. **再提炼**: 提取有价值的检查维度、输出结构、启发式原则、验收方式
+3. **后转译**: 将这些内容写入当前探索报告与后续文档，而不是整段搬运 skill 本体
+4. **保持可选**: 如果普通搜索和内部推理已足够，不必强行调用 `find-skills`
+
+**备用搜索路径**（当 `find-skills` 不可用时）:
+
+1. 使用 `search_web` 搜索方法论关键词、最佳实践、对标对象和测试策略关键词
+2. 使用 `read_url_content` 读取高质量文档、官方文档或代表性深度文章
+3. 在最终报告中标注：本次结论来自 Web / 文档搜索，**未使用 skill harvesting 增强**
+
+### 2.2 向内发散 (Inward Divergence) 
+
+用于：产生创意、探索可能性、突破常规
+
+> [!IMPORTANT]
+> **思考方式选择**（基于模型能力和任务复杂度）：
+>
+> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
+> - **有 CoT 模型 + 简单发散**（技巧 < 3）→ 用发散技巧组织自然 CoT
+> - **有 CoT 模型 + 复杂发散**（需要多方案比较、修正前提）→ 调用 `sequential-thinking` CLI
+>
+> **为什么需要深度发散？** 第一个想法通常是最普通的。突破需要：
+>
+> - 强迫自己继续想
+> - 尝试不同角度
+> - 连接不相关的概念
+
+**发散技巧**:
+
+1. **SCAMPER**: 替代、组合、调整、修改、其他用途、消除、重排
+2. **逆向思维**: "如果完全相反会怎样？"
+3. **类比迁移**: "其他领域怎么解决类似问题？"
+4. **极端假设**: "如果没有任何限制呢？"
+5. **强制关联**: 随机选一个概念，强制与问题关联
+6. **5 Whys**: 连问5次"为什么"挖掘根因
+
+**思考引导**:
+
+1. "最常规的解决方案是什么？"
+2. "如果反过来做呢？"
+3. "其他行业有类似问题吗？"
+4. "最疯狂的想法是什么？（不用可行）"
+5. "能不能组合两个不相关的概念？"
+6. "如果 10x 改进，需要怎么做？"
+7. ...（继续发散，不要停）
+
+### 2.3 探索循环
+
+对每个子问题：
+
+```
+┌─────────────────────────────────┐
+│  子问题: [描述]                  │
+│                                 │
+│  1. 先判断：需要搜索还是发散？    │
+│      ↓                          │
+│  2. 执行探索（搜索/发散/两者）   │
+│      ↓                          │
+│  3. 记录发现                     │
+│      ↓                          │
+│  4. 本轮结束检查（必须回答）:    │
+│     • 本轮发现了什么？(1-2句)    │
+│     • 是否充分回答了这个子问题？  │
+│     • 如果否，还需要探索什么？   │
+│      ├─ 否 → 回到 1             │
+│      └─ 是 → 更新进度表，下一个  │
+└─────────────────────────────────┘
+```
+
+> [!IMPORTANT]
+> **每个子问题结束时，你必须**：
+>
+> 1. 回答上述3个检查问题
+> 2. 更新"探索进度表"中的状态和核心发现
+>
+> 这确保你不会"想完就过"，而是留下可追溯的探索轨迹。
+
+---
+
+## Step 3: 综合与收敛 (Synthesize)
+
+**目标**: 整合所有发现，验证一致性，收敛到核心洞察。
+
+> [!IMPORTANT]
+> **思考方式选择**（基于模型能力和任务复杂度）：
+>
+> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
+> - **有 CoT 模型 + 简单综合**（子问题 < 3，无矛盾）→ 用思考引导问题组织自然 CoT
+> - **有 CoT 模型 + 复杂综合**（需要解决矛盾、修正前提）→ 调用 `sequential-thinking` CLI
+>
+> **为什么需要深度收敛？** 原始发现是碎片化的。你需要：
+>
+> - 识别模式和主题
+> - 解决矛盾信息
+> - 提炼核心洞察
+
+**思考引导**:
+
+1. "所有子问题都探索充分了吗？"
+2. "不同来源的信息一致吗？有矛盾吗？"
+3. "能提炼出哪些核心洞察？"
+4. "有哪些意外发现？"
+5. "还有什么缺口需要补充？"
+
+**如果发现缺口**: 回到 Step 2 补充探索
+
+---
+
+## Step 4: 结构化输出 (Output)
+
+**目标**: 产出结构化的探索报告。
+
+**保存路径**:
+
+- 如果由 `/design-system` 调用: `.anws/v{N}/04_SYSTEM_DESIGN/_research/{system-id}-research.md`
+- 如果独立调用: `explore/reports/{YYYYMMDD}_{topic_slug}.md`
+- 确保对应目录存在
+
+将内容保存到报告文件。
+
+> [!NOTE]
+> 如果本次探索使用了 `find-skills`，请在报告中明确区分：
+>
+> - 哪些结论来自 Web / 文档搜索
+> - 哪些结论来自 skill harvesting
+> - 哪些内容被建议沉淀到 ADR、SYSTEM_DESIGN、TASKS 或 Workflow
+
+**报告模板**:
+
+```markdown
+# 探索报告: [主题]
+
+**日期**: [日期]
+**探索者**: AI Explorer
+
+---
+
+## 1. 问题与范围
+
+**核心问题**: [原始问题]
+
+**探索范围**:
+- 包含: ...
+- 不包含: ...
+
+---
+
+## 2. 核心洞察 (Key Insights)
+
+> [3-5 个最重要的发现，每个 1-2 句话]
+
+1. **[洞察1标题]**: [描述]
+2. **[洞察2标题]**: [描述]
+3. **[洞察3标题]**: [描述]
+
+---
+
+## 3. 详细发现
+
+### 3.1 [子问题1]
+
+**探索方式**:  搜索 /  发散 /  混合
+
+**发现**:
+- ...
+
+**来源**: [URL 或 "发散思考"]
+
+### 3.2 [子问题2]
+...
+
+---
+
+## 4. 创意/方案清单 (如适用)
+
+| 方案 | 创新性 | 可行性 | 影响力 | 推荐度 |
+|------|:------:|:------:|:------:|:------:|
+| ... |  |  |  |  |
+
+---
+
+## 5. 行动建议
+
+| 优先级 | 建议 | 理由 |
+|:------:|------|------|
+| P0 | [立即行动] | ... |
+| P1 | [短期行动] | ... |
+| P2 | [长期考虑] | ... |
+
+---
+
+## 6. 局限性与待探索
+
+- [未覆盖的方面]
+- [需要进一步验证的假设]
+- [信息可能过时的部分]
+
+---
+
+## 7. 参考来源
+
+1. [标题](URL)
+2. ...
+```
+
+---
+
+## 示例提示词
+
+- "探索大型语言模型 Agent 的最新发展"
+- "探索如何让代码审查更高效有趣"
+- "探索 Rust 和 Go 在系统编程中的优缺点"
+- "探索解决远程团队协作问题的方案"
 - "探索 AI 辅助编程的最佳实践"