Deep Research（深度调研 8 步法）

将用户提出的模糊主题，通过系统化方法转化为高质量、可交付的调研报告。

核心理念

• •结论来自机制对比，不是"我感觉像"
• •先钉牢事实，再做推导
• •资料权威优先，L1 > L2 > L3 > L4
• •中间结果必须保存，便于回溯和复用

工作目录与中间产物管理

工作目录结构

调研开始时，必须在 ~/Downloads/research/ 下创建以主题命名的工作目录：

~/Downloads/research/<topic>/
├── 00_问题拆解.md          # Step 0-1 产出
├── 01_资料来源.md          # Step 2 产出：所有查阅的资料链接
├── 02_事实卡片.md          # Step 3 产出：抽取的事实
├── 03_对比框架.md          # Step 4 产出：选定的框架和填充
├── 04_推导过程.md          # Step 6 产出：事实→结论的推导
├── 05_验证记录.md          # Step 7 产出：用例验证结果
├── FINAL_调研报告.md       # Step 8 产出：最终交付物
└── raw/                    # 原始资料存档（可选）
    ├── source_1.md
    └── source_2.md

保存时机与内容

保存原则

1. •即时保存：每完成一个步骤，立即写入对应文件，不要等到最后
2. •增量更新：同一文件可多次更新，新内容追加或替换
3. •保留过程：中间文件即使内容后来被整合到最终报告，也要保留
4. •便于恢复：如果调研中断，可以从中间文件恢复进度

Trigger Conditions

当用户想要：

• •深入了解某个概念/技术/现象
• •对比两个或多个事物的异同
• •为决策收集信息和依据
• •撰写调研报告或分析文档

关键词：

• •"深度调研"、"深度研究"、"深入分析"
• •"帮我调研"、"调研一下"、"研究一下"
• •"对比分析"、"概念对比"、"技术对比"
• •"写调研报告"、"出调研报告"

与其他 Skill 的区分：

• •需要可视化图谱 → 使用 research-to-diagram
• •需要写作输出（文章/教程） → 使用 wsy-writer
• •需要素材整理 → 使用 material-to-markdown
• •需要纯调研报告 → 使用本 Skill

Workflow（8 步法）

Step 0: 问题类型判断

首先判断调研问题属于哪种类型，选择对应策略：

Step 0.5: 时效敏感性判断（BLOCKING）

在开始调研前，必须判断问题的时效敏感性，这将决定资料筛选策略。

时效敏感性分类

🔴 极高敏感领域特别规则

当调研主题涉及以下领域时，必须执行特殊规则：

触发词识别：

• •AI 相关：大模型、LLM、GPT、Claude、Gemini、AI Agent、RAG、向量数据库、提示工程
• •云原生：Kubernetes 新版本、Serverless、容器运行时
• •前沿技术：Web3、量子计算、AR/VR

强制执行的规则：

1. •

   搜索时带时间约束：

   • •使用 time_range: "month" 或 time_range: "week" 限制搜索结果
   • •优先查询 start_date: "YYYY-MM-DD" 设置为 3 个月内
2. •

   官方源优先级提升：

   • •必须首先查阅官方文档、官方博客、官方 Changelog
   • •GitHub Release Notes、官方 X/Twitter 公告
   • •学术论文（arXiv 等预印本平台）
3. •

   版本号强制标注：

   • •任何技术描述必须标注当前版本号
   • •示例：「Claude 3.5 Sonnet (claude-3-5-sonnet-20241022) 支持...」
   • •禁止使用「最新版本支持...」这类模糊表述
4. •

   过时信息处置：

   • •超过 6 个月的技术博客/教程 → 仅作为历史参考，不可作为事实依据
   • •发现版本不一致 → 必须核实当前版本后再使用
   • •明显过时的描述（如「未来将支持」但现在已支持）→ 直接丢弃
5. •

   交叉验证：

   • •高敏感信息必须从至少 2 个独立来源确认
   • •优先级：官方文档 > 官方博客 > 权威技术媒体 > 个人博客
6. •

   官方下载/发布页面直接验证（BLOCKING）：

   • •必须直接访问官方下载页面验证平台支持（不依赖搜索引擎缓存）
   • •使用 mcp__tavily-mcp__tavily-extract 或 WebFetch 直接提取下载页面
   • •示例：https://product.com/download 或 https://github.com/xxx/releases
   • •搜索结果中关于「即将支持」「Coming soon」的描述可能已过时，必须实时核验
   • •平台支持是高频变动信息，不可从旧资料推断
7. •

   产品特定协议/功能名称搜索（BLOCKING）：

   • •除了搜索产品名，必须额外搜索该产品支持的协议/标准名称
   • •常见需要搜索的协议/标准：
     • •AI 工具类：MCP、ACP（Agent Client Protocol）、LSP、DAP
     • •云服务类：OAuth、OIDC、SAML
     • •数据交换：GraphQL、gRPC、REST
   • •搜索格式："<产品名> <协议名> support" 或 "<产品名> <协议名> integration"
   • •这些协议集成往往是差异化功能，容易被主文档遗漏但在专门页面有说明

时效性判断输出模板

## 时效敏感性评估

- **调研主题**：[主题]
- **敏感级别**：🔴极高 / 🟠高 / 🟡中 / 🟢低
- **判断依据**：[为什么是这个级别]
- **资料时间窗口**：[X 个月/年]
- **优先查阅的官方源**：
  1. [官方源 1]
  2. [官方源 2]
- **需要核实的关键版本信息**：
  - [产品/技术 1]: 当前版本 ____
  - [产品/技术 2]: 当前版本 ____

📁 保存动作：将时效性评估追加到 00_问题拆解.md 末尾

Step 1: 问题拆解与边界界定

把模糊主题拆成 2-4 个可调研的子问题：

• •子问题 A：「X 是什么、怎么工作的？」（定义与机制）
• •子问题 B：「X 与 Y 的关系/差异在哪些维度？」（对比分析）
• •子问题 C：「X 在什么场景下适用/不适用？」（边界条件）
• •子问题 D：「X 的发展趋势/最佳实践？」（延伸分析）

⚠️ 研究对象界定（BLOCKING - 必须明确）：

在拆解问题时，必须明确定义研究对象的边界：

典型错误：用户问「大学生课堂问题」，却收录了针对「中小学生」的政策——适用对象不匹配会导致整个调研失效。

📁 保存动作：

1. •创建工作目录 ~/Downloads/research/<topic>/
2. •写入 00_问题拆解.md，包含：
   • •原始问题
   • •判断的问题类型及理由
   • •研究对象边界定义（人群、地域、时间、层级）
   • •拆解后的子问题列表
3. •写入 TodoWrite 跟踪进度

Step 2: 资料分层与权威锁定

按权威性给资料分级，优先消费一手资料：

L4 社区来源的具体化（产品对比调研必查）：

原则：

• •结论必须能追溯到 L1/L2
• •L3/L4 只作辅助和验证
• •L4 社区讨论用于发现"用户真正关心什么"
• •记录所有信息来源

⏰ 时效性筛选规则（根据 Step 0.5 的敏感级别执行）：

高敏感领域的搜索策略：

1. 第一轮：官方源定向搜索
   - 使用 include_domains 限定官方域名
   - 示例：include_domains: ["anthropic.com", "openai.com", "docs.xxx.com"]

2. 第二轮：官方下载/发布页面直接验证（BLOCKING）
   - 直接访问官方下载页面，不依赖搜索缓存
   - 使用 tavily-extract 或 WebFetch 提取页面内容
   - 核验：平台支持、当前版本号、发布日期
   - 这一步必须做，搜索引擎可能缓存过时的"Coming soon"信息

3. 第三轮：产品特定协议/功能搜索（BLOCKING）
   - 搜索产品支持的协议名称（MCP、ACP、LSP 等）
   - 格式：`"<产品名> <协议名>" site:官方域名`
   - 这些集成功能往往不在主页展示，但在专门文档中有说明

4. 第四轮：限时广泛搜索
   - time_range: "month" 或 start_date 设为近期
   - 排除明显过时的来源

5. 第五轮：版本核实
   - 对搜索结果中的版本号进行交叉验证
   - 发现不一致立即查阅官方 Changelog

6. 第六轮：社区声音挖掘（BLOCKING - 产品对比调研必做）
   - 访问产品的 GitHub Issues 页面，查看热门/置顶 issue
   - 搜索 Issues 中的关键功能词（如 "MCP"、"plugin"、"integration"）
   - 查看最近 3-6 个月的讨论趋势
   - 识别用户最关心的功能点和差异化特性
   - 这一步的价值：官方文档往往不会强调"别人没有而我有"的功能，但社区讨论会

社区声音挖掘的具体操作：

GitHub Issues 挖掘步骤：
1. 访问 github.com/<org>/<repo>/issues
2. 按 "Most commented" 排序，查看热门讨论
3. 搜索关键词：
   - 功能类：feature request, enhancement, MCP, plugin, API
   - 对比类：vs, compared to, alternative, migrate from
4. 查看 issue 标签：enhancement, feature, discussion
5. 记录高频出现的功能诉求和用户痛点

价值转化：
- 高频讨论的功能 → 可能是差异化亮点
- 用户抱怨/请求 → 可能是产品短板
- 对比讨论 → 直接获取用户视角的差异分析

资料时效性标注模板（追加到资料来源记录）：

- **发布日期**：[YYYY-MM-DD]
- **时效状态**：✅当前有效 / ⚠️需验证 / ❌已过时
- **版本信息**：[如适用，标注涉及的版本号]

工具使用：

• •优先使用 mcp__plugin_context7_context7__query-docs 获取技术文档
• •使用 WebSearch 或 mcp__tavily-mcp__tavily-search 进行广泛搜索
• •使用 mcp__tavily-mcp__tavily-extract 提取具体页面内容

⚠️ 适用对象核查（BLOCKING - 收录前必查）：

每收录一条资料前，必须核查其适用对象是否与研究边界匹配：

不匹配的资料处理：

• •适用对象完全不匹配 → 不收录
• •部分重叠（如「学生」包含大学生）→ 收录但标注适用范围
• •可类比参考（如中小学政策可作为趋势参考）→ 收录但明确标注「仅作参考」

📁 保存动作： 每查阅一个资料，立即追加到 01_资料来源.md：

## 资料 #[序号]
- **标题**：[资料标题]
- **链接**：[URL]
- **层级**：L1/L2/L3/L4
- **发布日期**：[YYYY-MM-DD]
- **时效状态**：✅当前有效 / ⚠️需验证 / ❌已过时（仅参考）
- **版本信息**：[如涉及特定版本，必须标注]
- **适用对象**：[明确标注该资料针对的群体/地域/层级]
- **与研究边界匹配**：✅完全匹配 / ⚠️部分重叠 / 📎仅作参考
- **摘要**：[1-2句关键内容]
- **与子问题关联**：[对应哪个子问题]

Step 3: 事实抽取与证据卡片

把资料转化为可核验事实卡片：

## 事实卡片

### 事实 1
- **陈述**：[具体事实描述]
- **出处**：[链接/文档章节]
- **置信度**：高/中/低

### 事实 2
...

关键纪律：

• •先钉牢事实，再做推导
• •区分「官方说的」和「我推测的」
• •遇到矛盾信息，标注并保留双方
• •标注置信度：
  • •✅ 高：官方文档明确说明
  • •⚠️ 中：官方博客提及但未正式文档化
  • •❓ 低：推测或来自非官方来源

📁 保存动作： 每抽取一条事实，立即追加到 02_事实卡片.md：

## 事实 #[序号]
- **陈述**：[具体事实描述]
- **出处**：[资料#序号] [链接]
- **适用对象**：[该事实适用于哪个群体，继承自资料或进一步细化]
- **置信度**：✅/⚠️/❓
- **关联维度**：[对应的对比维度]

⚠️ 事实陈述中的适用对象：

• •如果事实来自「部分重叠」或「仅作参考」的资料，陈述时必须明确标注适用范围
• •错误示范：「教育部禁止手机进课堂」（未说明针对谁）
• •正确示范：「教育部禁止中小学生将手机带入课堂（不适用于大学生）」

Step 4: 建立对比/分析框架

根据问题类型，选择固定的分析维度：

通用维度（按需选用）：

1. •目标/解决什么问题
2. •工作机制/流程
3. •输入/输出/边界
4. •优势/劣势/取舍
5. •适用场景/边界条件
6. •成本/收益/风险
7. •历史演进/未来趋势
8. •安全/权限/可控性

概念对比型专用维度：

1. •定义与本质
2. •触发/调用方式
3. •执行主体
4. •输入输出与类型约束
5. •确定性与可重复性
6. •资源与上下文管理
7. •组合与复用方式
8. •安全边界与权限控制

决策支持型专用维度：

1. •方案概述
2. •实现成本
3. •维护成本
4. •风险评估
5. •收益预期
6. •适用场景
7. •团队能力要求
8. •迁移难度

📁 保存动作： 写入 03_对比框架.md：

# 对比框架

## 选定的框架类型
[概念对比型/决策支持型/...]

## 选定的维度
1. [维度1]
2. [维度2]
...

## 初步填充
| 维度 | X | Y | 事实依据 |
|------|---|---|----------|
| [维度1] | [描述] | [描述] | 事实#1, #3 |
| ... | | | |

Step 5: 参照物基准对齐

确保对比的各方都有清晰、统一的定义：

检查清单：

• • 参照物的定义是否稳定/公认？
• • 是否需要查证，还是可用领域常识？
• • 读者对参照物的理解是否与我一致？
• • 有无歧义需要先澄清？

Step 6: 从事实到结论的推导链

显式写出「事实 → 对照 → 结论」的推导过程：

## 推导过程

### 关于 [维度名称]

1. **事实确认**：根据 [来源]，X 的机制是...
2. **对照参照物**：而 Y 的机制是...
3. **结论**：因此，X 与 Y 在此维度上的差异是...

关键纪律：

• •结论来自机制对比，不是"我感觉像"
• •每个结论都能追溯到具体事实
• •不确定的结论要标注

📁 保存动作： 写入 04_推导过程.md：

# 推导过程

## 维度 1：[维度名称]

### 事实确认
根据 [事实#X]，X 的机制是...

### 对照参照物
而 Y 的机制是...（来源：[事实#Y]）

### 结论
因此，X 与 Y 在此维度上的差异是...

### 置信度
✅/⚠️/❓ + 理由

---
## 维度 2：[维度名称]
...

Step 7: 用例验证（Sanity Check）

用一个典型场景验证结论是否成立：

验证问题：

• •按我的结论，这个场景应该怎么处理？
• •实际上是不是这样？
• •有没有反例需要说明？

回查清单：

• • 初稿结论是否与 Step 3 的事实卡片一致？
• • 有没有遗漏的重要维度？
• • 有没有过度推断？
• • 结论是否可操作/可验证？

📁 保存动作： 写入 05_验证记录.md：

# 验证记录

## 验证场景
[场景描述]

## 按结论预期
如果用 X：[预期行为]
如果用 Y：[预期行为]

## 实际验证结果
[实际情况]

## 是否有反例
[有/无，如有则描述]

## 回查清单
- [x] 初稿结论与事实卡片一致
- [x] 无遗漏重要维度
- [x] 无过度推断
- [ ] 发现问题：[如有]

## 需要修正的结论
[如有]

Step 8: 可交付化处理

让报告老板能读、能转述、能追溯：

交付三件套：

1. •一句话总结：可在会上直接复述
2. •结构化章节：用小标题切开推导链
3. •证据可追溯：关键事实附出处链接

📁 保存动作： 整合所有中间产物，写入 FINAL_调研报告.md：

• •从 00_问题拆解.md 提取背景
• •从 02_事实卡片.md 引用关键事实
• •从 04_推导过程.md 整理结论
• •从 01_资料来源.md 生成参考文献
• •从 05_验证记录.md 补充用例

报告输出结构

# [调研主题] 调研报告

## 摘要
[一句话总结核心结论]

## 1. 概念对齐
### 1.1 X 是什么
[定义 + 为什么存在]
### 1.2 Y 是什么（参照物）
[作为对比基准]

## 2. 工作机制
[X 怎么运行，这是核心差异点]

## 3. 联系
[共同解决的问题，3-4 点]

## 4. 区别
[按维度逐项对比，突出决定性差异]

## 5. 用例演示
[把抽象落地到具体场景]

## 6. 总结与建议
[可复述的结论 + 可操作的建议]

## 参考资料
[所有引用的来源链接]

利益相关者视角

根据受众调整内容深度：

输出文件

默认保存位置：~/Downloads/research/<topic>/

必须生成的文件（按流程自动产生）：

可选文件：

• •raw/*.md - 原始资料存档（内容较长时保存）

方法论速查卡

┌─────────────────────────────────────────────────────────────┐
│                    深度调研 8 步法                           │
├─────────────────────────────────────────────────────────────┤
│ 0. 判断问题类型 → 选择对应框架模板                            │
│ 1. 问题拆解 → 2-4 个可调研子问题                             │
│ 2. 资料分层 → L1官方 > L2博客 > L3媒体 > L4社区              │
│ 3. 事实抽取 → 每条带出处、标置信度                            │
│ 4. 建立框架 → 固定维度，结构化对比                            │
│ 5. 参照物对齐 → 确保定义统一                                  │
│ 6. 推导链 → 事实→对照→结论，显式写出                          │
│ 7. 用例验证 → Sanity check，防止纸上谈兵                     │
│ 8. 交付化 → 一句话总结 + 结构化章节 + 证据可追溯              │
├─────────────────────────────────────────────────────────────┤
│ 报告结构：定义→机制→联系→区别→用例→总结                       │
│ 关键纪律：结论来自机制对比，不是"我感觉像"                     │
└─────────────────────────────────────────────────────────────┘

使用示例

示例 1：技术概念对比

用户：帮我深度调研 REST API 和 GraphQL 的区别

执行流程：

1. •判断类型：概念对比型
2. •拆解问题：定义、机制、适用场景、优劣势
3. •查阅官方规范（REST论文、GraphQL官方文档）
4. •抽取事实卡片
5. •用8维度对比框架分析
6. •用实际项目场景验证
7. •输出结构化报告

示例 2：技术决策支持

用户：我们应该选 PostgreSQL 还是 MongoDB？帮我调研一下

执行流程：

1. •判断类型：决策支持型
2. •补充问题：用户的业务场景、数据特点、团队经验
3. •查阅官方文档和性能基准
4. •用决策维度框架分析
5. •给出场景化建议
6. •标注风险和前提条件

示例 3：趋势分析

用户：AI Agent 的发展趋势是什么？深入分析一下

执行流程：

1. •判断类型：趋势分析型
2. •梳理历史演进脉络
3. •收集一手资料（论文、官方公告）
4. •识别驱动因素
5. •分析当前格局
6. •审慎预测趋势（标注不确定性）

来源周全性要求（Source Verifiability）

核心原则：报告中引用的每一条外部信息，用户都必须能够直接验证。

强制执行的规则：

1. •

   URL 可访问性：

   • •所有引用链接必须是公开可访问的（无需登录/付费墙）
   • •如引用需要登录的内容，必须标注 [需登录]
   • •如引用学术论文，优先提供 arXiv/DOI 等公开版本
2. •

   引用精确定位：

   • •对于长文档，必须指明具体章节/页码/时间戳
   • •示例：[来源: OpenAI Blog, 2024-03-15, "GPT-4 Technical Report", §3.2 Safety]
   • •视频/音频引用需标注时间戳
3. •

   内容对应性：

   • •引用的事实必须能在原文中找到对应陈述
   • •禁止对原文进行过度推断后当作"引用"
   • •如有解读/推断，必须明确标注"基于 [来源] 推断"
4. •

   时效性标注：

   • •标注资料的发布/更新日期
   • •对于技术文档，标注版本号
   • •超过 2 年的资料需评估是否仍然有效
5. •

   不可验证信息的处理：

   • •如信息来源无法公开验证（如私人通信、付费报告摘要），必须在置信度中标注 [来源受限]
   • •不可验证的信息不能作为核心结论的唯一支撑

质量检查清单

完成报告前，检查以下项目：

• • 所有核心结论都有 L1/L2 级别的事实支撑
• • 没有使用"可能"、"大概"等模糊词而不标注不确定性
• • 对比维度完整，没有遗漏关键差异
• • 有至少一个实际用例验证结论
• • 参考资料完整，链接可访问
• • 每个引用都可被用户直接验证（来源周全性）
• • 一句话总结清晰可复述
• • 结构层次清晰，老板能快速定位

⏰ 时效性检查（高敏感领域 BLOCKING）

当调研主题属于 🔴极高 或 🟠高 敏感级别时，必须完成以下检查：

• • 已完成时效敏感性评估：00_问题拆解.md 中包含时效性评估章节
• • 资料时效性已标注：每条资料都有发布日期、时效状态、版本信息
• • 无过时资料作为事实依据：
  • •🔴极高：核心事实来源均在 6 个月内
  • •🟠高：核心事实来源均在 1 年内
• • 版本号已明确标注：
  • •技术产品/API/SDK 相关描述均标注了具体版本号
  • •没有使用「最新版本」「目前」等模糊时间表述
• • 官方源已优先使用：核心结论有来自官方文档/博客的支撑
• • 交叉验证已完成：关键技术信息从至少 2 个独立来源确认
• • 下载页面已直接验证：平台支持信息来自官方下载页面实时提取，非搜索缓存
• • 协议/功能名称已搜索：已搜索产品支持的协议名称（MCP、ACP 等）
• • GitHub Issues 已挖掘：查看了产品的 GitHub Issues 热门讨论
• • 社区热点已识别：识别并记录了用户最关心的功能点

典型社区声音遗漏错误案例：

❌ 错误：仅依赖官方文档，报告中 MCP 只作为普通功能点一笔带过 ✅ 正确：通过 GitHub Issues 发现 MCP 是社区最热议的功能，在报告中重点展开分析其价值

❌ 错误：「Alma 和 Cherry Studio 都支持 MCP」（没有分析差异） ✅ 正确：通过社区讨论发现「Alma 的 MCP 实现与 Claude Code 高度一致，这是其核心竞争力」

典型平台支持/协议遗漏错误案例：

❌ 错误：「Alma 仅支持 macOS」（基于搜索引擎缓存的 "Coming soon" 信息） ✅ 正确：直接访问 alma.now/download 页面，核验当前实际支持的平台

❌ 错误：「Alma 支持 MCP」（只搜索了 MCP，遗漏了 ACP） ✅ 正确：同时搜索 "Alma MCP" 和 "Alma ACP"，发现 Alma 还支持 ACP 协议集成 CLI 工具

典型时效性错误案例：

❌ 错误：「Claude 支持 function calling」（未标注版本，且可能指的是旧版本能力） ✅ 正确：「Claude 3.5 Sonnet (claude-3-5-sonnet-20241022) 通过 Tool Use API 支持函数调用，最大支持 8192 tokens 的工具定义」

❌ 错误：「根据 2023 年的博客，GPT-4 的上下文长度是 8K」 ✅ 正确：「截至 2024 年 1 月，GPT-4 Turbo 支持 128K 上下文（来源：OpenAI 官方文档，2024-01-25 更新）」

⚠️ 适用对象一致性检查（BLOCKING）

这是最容易被忽略、也是最致命的检查项：

• • 研究边界已明确定义：在 00_问题拆解.md 中有清晰的人群/地域/时间/层级界定
• • 每条资料都标注了适用对象：01_资料来源.md 中每条资料都有「适用对象」和「与研究边界匹配」字段
• • 不匹配的资料已正确处理：
  • •完全不匹配的资料未被收录
  • •部分重叠的资料已标注适用范围
  • •仅作参考的资料已明确标注
• • 事实卡片中无对象混淆：02_事实卡片.md 中每条事实的适用对象与研究边界一致
• • 报告中无对象混淆：最终报告中引用的政策/研究/数据，其适用对象与研究主题一致

典型错误案例：

研究主题：「大学生课堂不抬头问题」 错误引用：「2025年10月教育部发文禁止手机进课堂」 问题：该政策针对的是中小学生，不是大学生 后果：读者误以为教育部禁止大学生带手机，严重误导

打包输出（BLOCKING）

调研完成后，将工作目录打包：

tar -czvf ~/outcome.tar.gz -C <parent_dir> <workspace_name>

• •如 ~/outcome.tar.gz 已存在，直接覆盖
• •告知用户打包完成及文件位置

最终回复规范

调研完成后，向用户回复时：

✅ 应该包含：

• •一句话核心结论
• •关键发现摘要（3-5 点）
• •打包文件位置（~/outcome.tar.gz）
• •如有重大不确定性，标注需要进一步验证的点

❌ 禁止包含：

• •过程文件列表（如 00_问题拆解.md、01_资料来源.md 等）
• •详细的调研步骤说明
• •工作目录结构展示

原因：过程文件是给后续回溯用的，不是给用户看的。用户关心的是结论，不是过程。

版本历史

• •

  v1.6 (2026-01-12): 新增社区声音挖掘机制

  • •新增「L4 社区来源的具体化」表格，明确 GitHub Issues/Discussions/Reddit/HN 等来源
  • •搜索策略从 5 轮扩展到 6 轮，新增「社区声音挖掘」轮次
  • •新增「社区声音挖掘的具体操作」指南
  • •质量检查清单新增：GitHub Issues 已挖掘、社区热点已识别
  • •新增典型社区声音遗漏错误案例
  • •来源：Alma vs Cherry Studio 调研中 MCP 功能重要性被低估的教训——官方文档不会强调"别人没有而我有"，但社区讨论会
• •

  v1.5 (2026-01-12): 增强高敏感领域调研准确性

  • •新增规则 6「官方下载/发布页面直接验证」- 必须实时访问下载页面，不依赖搜索缓存
  • •新增规则 7「产品特定协议/功能名称搜索」- 必须搜索 MCP、ACP 等协议名称
  • •搜索策略从 3 轮扩展到 5 轮，新增下载页面验证和协议搜索轮次
  • •新增「最终回复规范」章节 - 禁止在回复中列出过程文件
  • •质量检查清单新增：下载页面验证、协议搜索检查项
  • •新增典型错误案例：平台支持遗漏（Alma Windows）、协议遗漏（Alma ACP）
  • •来源：Alma vs Cherry Studio 调研中遗漏 Windows 支持和 ACP 功能的教训
• •

  v1.4 (2026-01-12): 添加时效敏感性判断机制

  • •新增 Step 0.5「时效敏感性判断」，将问题分为 4 个敏感级别（极高/高/中/低）
  • •🔴极高敏感领域（AI/大模型等）强制执行：6 个月时间窗口、官方源优先、版本号强制标注
  • •Step 2 新增「时效性筛选规则」和「高敏感领域搜索策略」
  • •资料来源模板新增：发布日期、时效状态、版本信息字段
  • •质量检查清单新增「时效性检查」章节
  • •来源：用户反馈科技类调研容易引用过时信息导致误导
• •

  v1.3 (2026-01-11): 添加来源周全性要求（Source Verifiability）

  • •新增「来源周全性要求」章节，包含 5 条强制执行规则
  • •URL 可访问性、引用精确定位、内容对应性、时效性标注、不可验证信息处理
  • •质量检查清单新增「每个引用都可被用户直接验证」条目
  • •来源：用户要求确保外部引用可直接验证
• •

  v1.2 (2026-01-11): 增加适用对象核查机制

  • •Step 1 新增「研究对象界定」，要求明确人群/地域/时间/层级边界
  • •Step 2 新增「适用对象核查」，收录资料前必须验证适用对象匹配
  • •Step 3 事实卡片模板新增「适用对象」字段
  • •质量检查清单新增「适用对象一致性检查」章节
  • •来源：课堂抬头率调研中误引中小学政策的教训
• •

  v1.1 (2025-01-11): 增强中间产物管理

  • •新增「工作目录与中间产物管理」章节
  • •每个步骤明确保存动作（📁 标记）
  • •中间文件从"可选"改为"必须"
  • •标准化文件命名和目录结构
• •

  v1.0 (2025-01-11): 初始版本

  • •基于 Claude Skills vs 函数 调研案例提炼
  • •8 步法完整流程
  • •5 种问题类型框架
  • •多维度对比模板