# Research Decision

> 对复杂问题进行联网调研，并基于高质量信源输出判断、建议、排查方向或下一步动作。适用于技术选型、方案对比、版本升级、兼容性判断、架构取舍、社区口碑调研、已知问题排查、疑难 bug 冲突分析，以及其他需要上网查证、多方比较、最后给出建议或方向的问题。优先进行中英文双语检索，重视官方文档、官方博客、GitHub issues/discussions/changelog/release notes，再补充社区讨论与第三方资料。重点是信源管理、交叉验证、识别已知问题和处理冲突信息。

- Skill: `dvcrn/research-decision` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add dvcrn/research-decision`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dvcrn/research-decision/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: dvcrn (https://skillmd.com/u/dvcrn)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/dvcrn/research-decision

---


# Research Decision

## 目标

把"联网查资料"转成"有依据的判断与行动建议"。

这个 skill 的重点不是固定模板，而是：

- 管理信源优先级
- 做中英文双语检索
- 交叉验证多方说法
- 识别已知问题、冲突信息和不确定性
- 输出对用户有用的结论、建议、排查方向或下一步动作

默认产出应服务于"决策 / 排查 / 止损"，而不是资料堆砌。

## 核心原则

- 先理解用户真正要解决的问题，再决定更适合输出"决策建议""条件判断"还是"排查方向"。
- 不要依赖单一来源下结论，尤其不能只靠博客、自媒体或单条社区帖。
- 如果存在已知 bug、版本冲突、兼容性风险或社区争议，优先识别风险，再决定是否推荐推进。
- 如果证据不足，不要硬给确定性结论；应明确边界、不确定点和最小验证动作。
- 如果用户信息不完整，也先尽量推进判断，并在结论中写清适用前提或假设。
- **对于版本核查、依赖检查、环境验证等可以快速自动完成的事项，先自己跑一遍命令或查一下文档，把结果直接给用户**，不要让用户自己动手。
- **输出报告必须有信源展示**，每条关键结论都要标注来源类型和链接，方便用户溯源和验证。

## 工作流程

### 1. 收敛问题

先判断用户的问题更像哪类：

- 是否值得采用某个技术 / 工具 / 方案
- 是否要升级 / 迁移 / 替换
- 某个版本、组合、架构是否可用
- 某个 bug、冲突、异常是否已有已知问题或成熟解法
- 社区、官方、维护者对某件事是否存在共识
- 用户真正需要的是结论、排查方向、规避方案，还是止损建议

同时尽量识别这些信息：

- 目标：想解决什么
- 对象：技术 / 工具 / 版本 / 方案 / bug / 冲突点
- 当前上下文：新项目、老项目、生产环境、测试环境、升级中、排障中
- 约束：时间、兼容性、团队经验、迁移成本、风险承受能力
- 用户最关心的结果：稳定性、效率、成本、可维护性、是否有坑、怎么尽快解

### 2. 做中英文双语检索 + 快速验证

至少完成一轮中文检索和一轮英文检索。

**快速验证事项先做：**
- 如果问题涉及版本，先查当前版本（`--version`、`npm list` 等）
- 如果涉及依赖，先检查环境（`pip list`、`composer show` 等）
- 如果涉及文档，先抓官方最新文档
- 这些验证结果直接写在报告里，体现专业性

优先查询这些来源：

1. 官方文档 / 官方博客 / 官方 FAQ / 官方发布说明
2. GitHub issues / discussions / changelog / release notes / migration guide
3. 社区讨论（Reddit、Hacker News、论坛、AnswerOverflow、技术社区）
4. 第三方博客 / 教程 / 自媒体（仅作补充）

默认优先级：

**官方 > issue/changelog > 社区 > 第三方内容**

如果是 bug、冲突、兼容性、升级失败问题，优先查 issue、discussion、release notes、官方 workaround 和社区复现记录。

需要更具体的检索写法时，查看：
- `references/query-patterns.md`
- `references/issue-triage.md`

### 3. 交叉验证并判断信号强弱

使用信源时，按以下顺序判断可信度：

#### 高优先级
- 官方文档
- 官方博客
- 官方发布说明
- changelog / release notes / migration guide
- maintainer 明确回复的 issue / discussion

#### 中优先级
- 普通 issue / discussion
- 高质量社区讨论
- 多人复现的帖子
- 多来源一致的经验总结

#### 低优先级
- 单篇博客
- 自媒体
- 个人经验帖
- 无法确认版本和上下文的内容

关键结论尽量满足：

- 至少有两类来源支撑
- 尽量有一个高优先级来源托底
- 如果没有高优先级来源，要明确标注"证据较弱"或"官方未确认"

如果信息冲突，优先判断：

- 是否来自不同版本
- 是否只在特定环境触发
- 是否后来已修复
- 是否只是文档理想状态与真实使用体验不一致

如果资料明显过旧，或结论主要依赖低优先级来源，要主动降低结论强度。

### 4. 按问题类型调整重点

不要机械套模板，要根据问题类型调整调研重点。

#### 选型 / 替换 / 值不值得用
重点看：
- 官方定位与适用边界
- 是否仍在维护
- release 活跃度
- 社区口碑
- 常见负面反馈
- 替代方案
- 接入或迁移成本

#### 版本升级 / 兼容性 / 生产可用性
重点看：
- changelog / release notes
- breaking changes
- migration guide
- known issues
- regression
- 是否存在回退风险
- 社区是否出现高频踩坑

#### 疑难 bug / 冲突 / 异常
重点看：
- 是否为已知问题
- issue 中是否已有复现
- 是否与特定版本、环境、依赖组合有关
- maintainer 是否确认过
- 是否有 workaround、patch、替代配置
- 是否建议降级 / 升级 / 规避某特性
- 是否值得继续深挖，还是应该尽快绕开

如果是 bug / 冲突问题，优先回答：

- 这是不是已知问题
- 哪些版本 / 环境 / 依赖组合最容易触发
- 有没有 workaround、补丁、替代路径或临时规避方案
- 是否建议升级、降级、锁版本、回滚或缩小使用范围
- 这个问题值不值得继续投入排查，还是更适合止损

更细的 bug / 冲突处理方式，查看 `references/issue-triage.md`。

### 5. 输出判断与下一步动作

不要只总结资料，要把调研结果转成用户可执行的东西。

**重要：输出必须有信源展示。** 每条关键结论都要标注来源（官方/issue/社区/博客）+ 链接，方便用户溯源。

默认尽量输出以下内容中的大部分：

- 结论 / 判断
- 建议方案
- 关键依据（**必须有信源标注**）
- 风险或反例
- 已知问题
- workaround / 替代方案
- 下一步动作
- 回滚或止损条件

如果是决策类问题，优先回答：
- 推荐 / 不推荐 / 条件推荐 / 暂不推荐 / 证据不足

如果是 bug / 冲突类问题，优先回答：
- 更可能的问题方向
- 是否已有已知案例
- 先试什么 workaround
- 是否建议升级 / 降级 / 规避 / 替代
- 何时停止继续排查，转为止损

**报告详细程度：**
- 不要只给一句话结论。用户拿这个 skill 是要评估效果的，第一印象很重要。
- 检索过程、关键发现、证据链都要展示出来，让用户看到你确实做了什么调研。
- 但也不要堆砌信息——重点突出，结构清晰。
- 可以给用户一个"快速版"（一句话结论 + 核心理由）和一个"详细版"（完整报告），让用户选择。

## 输出风格

- 先回答用户最关心的问题，再展开证据。
- 不要做成机械模板填空。
- 不要为了全面而堆太多链接或背景。
- 冲突证据要主动解释，不要原样堆给用户。
- **每条关键结论必须带信源标注**（如：官方文档 / GitHub Issue / 社区讨论 + 链接）。
- 高风险场景默认更保守；低风险探索场景可以更灵活。
- 用户想快速判断时，优先给短结论 + 核心理由 + 下一步。
- 用户明显在排障时，优先给"最可能原因 + 先试什么 + 是否值得继续挖"。

## 底线规则

- 不要只做摘要，必须尽量转化为判断、建议或行动方向。
- 不要基于单一弱来源下结论，关键判断至少做交叉验证。
- **每条结论都要有信源标注**，不能"我觉得"或者"应该是"。
- 发现已知 bug、高频冲突或高风险信号时，优先给规避、替代、验证或止损方案，不要默认硬推。
- 能自动化的快速验证（版本、依赖、环境）先自己做，别麻烦用户。