researchlisted

# 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`**：清理模式，回到初始状态 -