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 的规则补人或删人。每位顾问填一张"顾问卡"：

组建后做覆盖检查（细则在 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，不要换风格。