Research

---
name: research
description: 当用户要求“研究一下”“系统了解”“讲清楚某个概念/原理”，或任务需要整理概念地图、权威来源、实践路径和风险时使用。不用于单个 API 查询、普通实现或可行性决策
---

# Research / Explain

把陌生或复杂主题讲清楚：先建立概念框架，再给证据、实践路径、边界和风险。它不一定要写文档；只有用户要求沉淀、任务跨多步复用，或内容需要长期保存时才落 Markdown / 脚本

## 不使用场景
- 查询单个 API、配置项、CLI 参数：用 `search`，优先 Context7 MCP
- 判断某个改造是否可行、是否值得做：用 `feasibility`
- 普通代码实现：直接读项目配置和源码后实现
- 大范围并行搜索、交叉验证：组合 `workflow`
- 已知 GitHub 仓库的文件、Issue、PR：用 `github`

## 回答风格

```
先给结论 → 搭概念框架 → 解释因果 → 给例子/诊断方式 → 标出边界和风险
```

- 不把资料堆给用户；先组织成可理解的模型
- 第一遍解释避免术语互相套娃，必要术语第一次出现时说明含义
- 面向操作的问题要给“怎么判断自己属于哪种情况”
- 关键结论必须能追到来源；不确定的地方明确标注
- 如果只是概念解释，直接在回复中讲清楚即可，不默认写文件

## 证据优先级

1. 官方文档 / 标准规范
2. 官方源码 / release note
3. 主流项目真实用法
4. Issue / PR / maintainer comment
5. 博客 / 教程 / 社区帖子

使用 `search` skill 选择工具。对于关键结论，必须附上来源链接或本地文件路径

## 流程

1. 明确问题边界：用户要理解概念、做操作手册、选型背景，还是排查路径
2. 搜索权威来源，记录覆盖范围
3. 建立概念地图：概念、关系、数据流、生命周期或状态机
4. 提炼实践路径：步骤、判断条件、代价、副作用、失败处理
5. 必要时写最小验证脚本
6. 输出结论、证据、未确认点和下一步

## 概念地图

讲概念时优先回答：
- 它解决什么问题
- 它由哪些部分组成
- 这些部分如何协作
- 它和相邻概念的差异是什么
- 什么时候该用，什么时候不该用

可以用 ASCII 图、表格、层级结构表达关系，但不要为了形式写图

## 实践说明

涉及命令、配置、安装、迁移时，每一步都要说明：
- 改变了系统的什么状态
- 为什么要这么做
- 如何验证成功
- 如何回滚或处理常见报错

涉及代价时按需说明：
- **性能影响**：对日常使用有什么影响？量化（几 MB / 几十 MB / 几 GB）
- **磁盘 / 内存开销**：占多少空间？什么条件下会增长？
- **风险**：什么操作是不可逆的？什么场景会出问题？
- **边界**：方案覆盖哪些情况？不覆盖哪些？明确写出来

## 输出级别

- 快速解释：直接在回复里给结论、概念框架、例子、边界
- 标准调研：结构化 Markdown，含来源、实践路径、风险
- 深度调研：Markdown + 可执行脚本 + 验证步骤

只有当用户明确要求沉淀，或内容会被后续任务复用时，才写 `.md` 文件或更新 README

## 自动化

只有当调研结果包含可重复操作、环境检测、批量转换、安装配置或验证流程时，才写脚本

- 脚本要求：
  - **自动检测环境**（设备名、UUID、用户名等），不硬编码
  - **幂等**：重复运行安全，已完成的步骤自动跳过（`[SKIP]`）
  - **`--dry-run`**：预览模式，不做任何修改
  - **`--reset`**：清理模式，回到初始状态
  - **备份关键文件**（如 fstab）再修改
  - **最后打印验证命令 + 预期结果**

## 输出要求

- 关键结论带来源
- 明确已验证、资料结论、未确认点
- 有分支条件时，先给诊断方式，再给对应操作
- 不复述百科，重点给可理解模型和可执行路径