# Storm Research

> 多视角＋逐条核查的中文研究简报（STORM 研究法 · 场景版）。先自动识别题目属于哪类决定（买东西选工具 / 自媒体选题 / 学业职业 / 人生决策 / 亲密关系 / 命理解读 / 趋势研究），加载对应的场景包，再按用户的真实处境自动匹配 4–6 位顾问组成评审团（每位写明代表谁、负责哪个子问题、只接受哪类证据、必须交出什么、只有 TA 会问的问题），并行调研 → 分歧地图 → 中文 HTML 简报 → 核查 Agent 把每条引用拿回原始来源比对。所有子 Agent 的任务与提示词都用中文，便于在后台实时查看。只要用户说"storm research / storm 一下 / 用 STORM / 顾问团会诊 / 评审团 / 多视角研究 / 帮我做个研究简报"，或在做一个花钱、选型、选题、升学择业、辞职创业、感情家庭、命理解读这类需要多角度判断的问题并希望有依据的结论，都应使用本 skill，即使没有点名。简单查一个事实不要用，太重。

- Skill: `fanko1217/storm-research` (Agent Skill, multi-file: 13 files)
- Install (CLI): `npx skillmds@latest add fanko1217/storm-research`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fanko1217/storm-research/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: fanko1217 (https://skillmd.com/u/fanko1217)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/fanko1217/storm-research

---


# Storm Research（场景版）

## 这个 skill 做什么

把一个问题变成一份经过核查、多视角的中文 HTML 简报。它和原版 STORM 的最大区别是：**视角不是写死的，而是先识别题目属于哪类决定、加载对应的场景包，再按"这个问题 + 这个人"自动匹配评审团。** 原版固定的 5 个视角（实践者/学者/怀疑者/经济学家/历史学家）只是思路；在"买一台电脑"这类决定上，固定视角会漏掉用户真正的主要用途，学者视角也常常无文献可引。

完整跑完四个阶段，不跳步。它比一次网页搜索重得多，这是故意的。

## 依赖

只用 Claude Code 内置工具：`Agent`（内置 `general-purpose`）、`Write`，以及子 Agent 内部的网页搜索/抓取，外加本文件夹里的 `report-template.html` 和 `references/`。不需要外部脚本或付费服务。

## 阶段 0：界定问题

1. 问题来自 `$ARGUMENTS`；没有就问一句要研究什么。
2. 用一句话复述你的理解，然后**把问题拆成 2–4 个子问题**，并标出每个子问题的性质——这决定了需要什么样的顾问和能核查到什么程度：
   - **事实**：可以直接查证（价格、规格、条款）
   - **可计算**：给定条件就能算出来（内存够不够、多久回本）
   - **周期判断**：一半可查、一半靠规律（现在买还是等）
   - **预测**：无法核实，只能核实支撑它的事实（以后会不会涨）
3. **整理读者的真实处境**：从对话、记忆、用户提供的材料里收集——预算、所在地区、已有设备、日常主要工作负载、硬性限制。缺了会改变结论的关键项，用一句话问；其余用合理默认并在报告里写明。
4. **上下文开关**（决定哪些信息交给顾问团）：
   - **背景事实**（预算、设备、工作负载、地区）默认交给所有顾问——报告要贴合这个人，这是本 skill 的意义。
   - **用户已有的决定或倾向**（例如"我已经下单了 A"）默认**不交**，这就是"盲测模式"：顾问团独立判断，事后再和用户的决定对照，避免顾问顺着用户说。只有用户明确说"告诉它们我的选择 / 帮我复核这个决定"时才切到"知情模式"。
   - 在报告的 meta 行写明本次用的是哪种模式。
5. **识别场景**：读 `references/scenes/README.md`，按"要做的决定"判断题目属于哪个场景（最多一个主场景 + 一个副场景），再读对应的场景包。场景包决定：候选顾问库、证据规则、盲测要藏什么、报告结尾怎么写、有没有特殊边界。都不像时，说明"没有匹配的场景包，现场推导"，按 `panel-design.md` 第一节从零推导。两个场景都说得通、且会导致不同结论时，用一句话问用户。
6. 生成 kebab-case 的 `topic-slug` 作为文件名。

## 阶段 1：自动匹配评审团

从场景包的候选顾问库里挑 4–6 位（默认 5 位，最多 6 位），**把每一位改写到这道题的具体对象上**：候选库里的"主用途实测派"，落到 Mac Studio 题上就是"剪辑和渲染工程师"。副场景最多借 1–2 位。再按 `references/panel-design.md` 的规则补人或删人。每位顾问填一张"顾问卡"：

| 字段 | 含义 |
|---|---|
| 名称 | 中文，一看就懂，如"剪辑和渲染工程师" |
| 代表谁 | 站在谁的立场说话 |
| 负责的子问题 | 对应阶段 0 的哪一个 |
| 只接受的证据 | 具体到来源类型，如"苹果官网规格页、上一代机型的导出实测" |
| 必须交出 | 至少一个可核查的东西：数字（"两档导出耗时差"）、可观察的行为（"吵架后多久和好"）或一个小实验；按场景包的规定 |
| 只有 TA 会问的问题 | 这位顾问独有的探索角度，一句话，如"我每天最常做的那件事，它快了多少？"。它决定这位顾问往哪个方向深挖，也是报告里"支持 / 质疑"的来源 |

组建后做覆盖检查（细则在 `panel-design.md`）：每个子问题至少一位顾问负责；读者每一项主要工作负载至少一位顾问代表；至少一位"泼冷水"的顾问（不做/不买行不行）；涉及花钱时至少一位算钱的顾问。

**把识别结果和评审团发在聊天里**：先一行写"识别场景：X（依据：……）"，再用一张表列出名称 / 代表谁 / 负责的子问题 / 只有 TA 会问的问题，让用户看到为什么是这几位、各自从什么角度切入。默认发完直接开跑；如果用户说过"先让我确认顾问团"，就停下等确认。

## 阶段 2：顾问团并行调研

在**一条消息里**同时派出所有顾问，每位一个 `general-purpose` Agent。

- 每个 Agent 调用的 `description` 用中文，格式 `顾问·<名称>`（如"顾问·剪辑和渲染工程师"），这样用户在后台任务列表里一眼能认出是谁。
- 提示词**全部用中文**，套用 `references/prompts.md` 里的"顾问提示词模板"，把顾问卡、问题、读者背景（按阶段 0 的开关）、今天的日期填进去。用中文是为了让用户点开任何一个后台 Agent 都能直接看懂它在干什么。

全部返回后，在聊天里写 2–3 行：顾问们往哪个方向收敛、最尖锐的分歧是什么。原始简报不要贴进聊天（Agent 已经返回过了）。

## 阶段 3：画分歧地图（在主会话里做，不派 Agent）

只根据顾问简报，整理出：

1. **直接冲突**：哪几位顾问说了相反的话，写出具体冲突的说法，而不只是话题。
2. **证据强弱**：谁的证据最硬、谁最弱，按 `panel-design.md` 里的证据等级说明理由。
3. **能化解最大分歧的那个问题**：一个可以用数据回答的问题。
4. **所有人都同意的事**：连对立方都承认的，这是最可能成立的结论。
5. **盲点**：没有任何顾问覆盖到的角度，它变成报告里的"缺失的视角"和"前沿问题"。

特别检查两类假冲突——本次实跑中两个"冲突"最后都是它们：
- **比较基准不同**：A 说贵 $1,500、B 说贵 $200，可能都对，只是和不同的价格比。
- **测试条件不同**：两个速度数字差一倍，可能是量化方式、机器配置、软件版本不同。

## 阶段 4：写中文 HTML 简报

1. 读 `report-template.html`，照着克隆，CSS 原样保留，不要重写样式。
2. 填满所有部分：
   - **本次顾问团**：先写识别出的场景，再列出每位顾问的名称、代表谁、负责的子问题、只有 TA 会问的问题、依据的证据来源。让读者知道每个结论是从哪个角度来的。
   - **60 秒摘要**：先讲已确定的事实，再讲有争议的解读，最后讲张力所在。
   - **5 条关键发现，按可信度排序**：每条带 1–10 分（阶段 5 定分），以及"支持/质疑/已更正"标签。
   - **隐藏的关联**：只有把所有视角放在一起才看得出的联系。
   - **依赖的假设 / 缺失的视角**：阶段 3 的盲点。
   - **具体该怎么做**：3–6 条，针对读者的真实处境，要具体。**写法按场景包的"报告结尾"**：买东西写买哪档与反转条件；选题写做 / 换包装 / 不做；学业职业写本周小实验；人生决策写里程碑与止损线；亲密关系写一起聊的问题，不下判决。
   - **哪些话可以放心说**：可以直接说 / 要加前提 / 不要说，阶段 5 之后填。
   - **前沿问题**：那个一旦回答就会改变结论的问题。
   - **证据来源**：每条引用带核查状态标签。
3. 写到 `storm-reports/{topic-slug}-briefing.html`（相对当前工作目录，没有就建）。

## 阶段 5：对抗式自查 + 逐条核查（不能跳过）

这一步是本 skill 和普通报告的区别。

**5a. 自查（主会话里做）**：给 5 条发现逐条打可信度分并说明理由；找出最薄弱的一环以及怎么验证它；做偏差检查（哪位顾问主导了结论、谁被低估了）；给整体一个诚实的评级。

**5b. 逐条核查（并行 Agent）**：把引用按主题分成 4–6 组，在一条消息里每组派一个 `general-purpose` Agent，`description` 用 `核查·<主题>`，提示词用 `references/prompts.md` 里的中文"核查提示词模板"。

**5c. 按核查结果修改报告**：
- 改掉错误的数字、标题、日期、出处；
- 证据变薄的，下调分数；预印本、转述链、有争议的说法移进"待观察信号"；
- 在原文里找不到的说法直接删掉，并计入"删除"；
- 填写核查横幅（`N 条核查 · X 条伪造 · Y 条更正 · Z 条降级 · W 条删除`）和每条引用的状态标签；
- 根据核查结果填写"可以放心说"三栏。

## 交付

1. 最终文件：`storm-reports/{topic-slug}-briefing.html`（核查后的版本）。
2. 用系统默认方式打开：macOS `open <path>`。
3. 在聊天里给出：文件路径、核查统计、所有顾问都同意的那条结论、前沿问题、以及"可以说 / 别说"的简要清单。如果用的是盲测模式、且用户已有决定，最后加一句：顾问团的结论与用户的决定一致还是相反，理由是什么。

## 原则

- **只用真实研究。** 每个视角、每条引用都要能追到一个真实抓取过的来源。不编研究、不编数字、不编网址。核实不了的，降级或删除。
- **顾问团是作者组建的。** 报告里要写明这一点。多位顾问意见一致只是很强的假设，不是领域共识。
- **核查是必需的。** 没做阶段 5 的报告不算 Storm 报告，核查横幅必须如实。
- **可信度 = 证据质量，不是把握程度。** 等级见 `panel-design.md`。
- **先查今天，不信记忆。** 新产品、价格、政策的变化速度远超训练数据；把今天的日期写进每个子 Agent 的提示词，要求它们先上网核实。
- **场景包的特殊边界优先。** 例如亲密关系场景里一旦出现控制、威胁、暴力等红线信号，停止会诊，只给安全建议；命理场景只核查排盘和引文，不给预测，也不对健康、投资、法律下结论。
- **成本。** 每次约派出 9–12 个 Agent（4–6 位顾问 + 4–6 个核查），这是正常的。不要超过 6 位顾问。
- **版式。** 白底、专业，沿用模板 CSS，不要换风格。