返回 Skill 列表
extension
分类: 开发与工程无需 API Key

sn-research-planning

深度研究的精简计划;当需要仅基于 request.md 生成 plan.json,一次性完成研究定界、报告格式发现、结构设想、维度拆解、关键问题、搜索策略、依赖、执行顺序和完成标准时使用。

person作者: gaclovehubgithub

Research Planning

产出 plan.json。它同时承担定界、报告形态约束和执行地图,用来指导 sub_reports/*.md 和最终 report.md 的生成;不是研究结论预设。

行为边界

做:

  • request.md 识别研究目标、边界、受众、用途、时间/地域和假设。
  • 在需要时先做报告格式发现,再设计有依据的报告形态。
  • 设计轻量报告形态:终稿章节、结构依据、必须产出的表格/图/比较项、写作约束。
  • 把关键问题拆成可执行研究维度。
  • 让每个维度都能独立落盘为一个子报告。
  • 明确每个维度要回答什么、用什么方法、产出什么材料。
  • 为每个维度指定搜索策略和充分性标准。
  • 排出合理执行顺序和真实依赖。

不做:

  • 不写研究结论。
  • 不把终稿章节直接复制成研究维度。
  • 不做单独的 briefing.mdblueprint.jsonsynthesis.md
  • 不做资料综述或事实展开。
  • 不制造不必要的并行/依赖复杂度。

输入

  • {report_dir}/request.md

规划流程

  1. 锁定目标:从 request.md 提取最终报告要服务的判断。
  2. 界定范围:写清对象、时间、地域、受众/用途、排除项和执行假设。
  3. 判断是否需要格式发现:如果用户已明确给出报告结构,或报告类型非常标准且约束明显,可直接进入下一步;否则先做一次轻量格式发现。
  4. 发现报告格式:必要时读取 sn-report-format-discovery,识别报告类型、可信结构来源、必备章节、强制元素和风格约束,再压缩进 plan.json.report_shape
  5. 设定报告形态:给出终稿章节建议、结构依据、必备元素、适合的表格/图和写作约束。
  6. 抽取问题:把关键问题分成基础事实、机制/原因、比较、影响、风险、趋势或建议类问题。
  7. 设计维度:按“可独立研究、可回答问题、可贡献终稿”的标准合并或拆分维度。
  8. 定义任务:为每个维度写清 key_questionsmethodsearch_strategyexpected_outputdepends_on
  9. 定义搜索充分性:说明需要覆盖哪些来源类型、至少几轮检索、哪些关键问题必须交叉确认。
  10. 排序执行:先做定义、事实、背景和口径类维度,再做比较、解释、影响、判断类维度。
  11. 写完成标准:明确什么条件下可以从分维度研究进入终稿写作。

报告格式发现

规划阶段不要求每次都单独研究格式,但在下列情况应主动做一次格式发现:

  • 用户只说“做个研究报告”,没有给章节结构。
  • 报告类型强依赖领域规范,如政策、法律、监管、学术/医学综述、尽调、技术选型。
  • 目标读者或使用场景会显著影响结构,如对外汇报、投决支持、内部选型、监管沟通。
  • 你不确定终稿应该优先呈现结论、时间线、比较矩阵、风险清单还是方法说明。

可以直接从 request.md 推断 genredomainaudienceregion;若这些信息不足以稳健决定结构,再读取 sn-report-format-discovery

发现格式时只需要回答 4 件事:

  1. 这份报告最接近哪一类报告。
  2. 这类报告通常必须有哪些章节。
  3. 哪些非章节元素必须在终稿中出现,如对比表、时间线、风险矩阵、方法说明。
  4. 这些结构判断的依据是什么;如果没有找到高可信依据,回退逻辑是什么。

格式发现的结果要压缩进 plan.json.report_shape,用于约束后续维度设计;不要另写独立格式文件,除非调用方明确要求。

维度设计准则

一个好维度应同时满足:

  • 能独立产出 sub_reports/{id}.md
  • 有 2-5 个具体 key_questions
  • 与其他维度边界清楚,重叠可解释。
  • report.md 有明确贡献。
  • 有明确搜索入口和停止条件。
  • 不预设结论,只定义要查明什么。

普通研究控制在 3-5 个维度;复杂研究最多 8 个维度。维度过多时优先合并同类问题。

输出

写入 {report_dir}/plan.json

{
  "research_goal": "一句话目标",
  "scope": {
    "objects": ["研究对象"],
    "time_range": "时间范围",
    "region": "地域范围",
    "audience_or_use": "目标读者或用途",
    "exclusions": ["明确不做什么"],
    "assumptions": ["执行假设"]
  },
  "report_shape": {
    "format_basis": [
      {
        "type": "standard_guideline | official_template | real_exemplar | domain_convention | fallback",
        "name": "结构依据名称",
        "credibility_reason": "为什么可信",
        "what_extracted": "从中抽取了哪些结构约束"
      }
    ],
    "sections": ["终稿建议章节"],
    "mandatory_elements": ["必须产出的表格、图、清单或比较项"],
    "style": "写作口径和语气约束"
  },
  "completion_criteria": ["完成标准"],
  "change_notes": [],
  "dimensions": [
    {
      "id": "d1",
      "name": "维度名称",
      "description": "研究范围和边界",
      "key_questions": ["必须回答的问题"],
      "method": "检索、比较、案例分析、数据梳理、时序还原等",
      "search_strategy": {
        "source_types": ["应覆盖的来源类型"],
        "seed_queries": ["起始检索词或检索方向"],
        "freshness_requirement": "是否需要最新信息及时间范围",
        "sufficiency": ["判断搜索足够的条件"]
      },
      "expected_output": "该维度子报告应提供给终稿写作的材料",
      "depends_on": [],
      "status": "pending"
    }
  ],
  "execution_order": ["d1", "d2"]
}

字段要求

  • research_goal:一句话说明整个研究要服务什么判断。
  • scope:必须覆盖对象、时间、地域、受众/用途、排除项和当前假设;未知项显式写明。
  • report_shape.format_basis:说明报告结构依据来自哪里。若调用过 sn-report-format-discovery,至少保留 1 个依据;若未调用,也要写明是“用户指定结构”或“通用领域惯例”。
  • report_shape.sections:是终稿结构建议,不是研究维度。
  • report_shape.mandatory_elements:列出终稿必须支撑的比较表、时间线、风险清单、指标矩阵、流程图等。
  • report_shape.style:说明报告语气、确定性表达和不确定性处理方式。
  • completion_criteria:列出进入终稿写作前必须满足的条件。
  • change_notes:初始为空数组;研究过程中如调整维度或执行顺序,把原因追加到这里,不单独写日志文件。
  • id:使用稳定短 ID,如 d1d2
  • description:说明研究范围和不包含什么。
  • key_questions:写成可回答的问题,不写成标题。
  • method:说明该维度适合怎么研究。
  • search_strategy.source_types:列出要覆盖的来源类型,如官方文件、监管公告、学术论文、行业报告、公司披露、产品文档、新闻报道、社区讨论等。
  • search_strategy.seed_queries:给出 3-6 个起始检索方向,而不是只写一个关键词。
  • search_strategy.freshness_requirement:说明是否必须查最新资料;涉及市场、政策、产品、公司、价格、法律、人物时必须要求最新核查。
  • search_strategy.sufficiency:写清停止条件,如“每个关键问题至少有材料支撑”“核心事实来自两个独立来源”“没有新信息增量后停止”等。
  • expected_output:说明子报告要贡献事实、比较、框架、判断依据、风险清单或场景分析中的哪一种。
  • depends_on:只写真实依赖;没有依赖则为空数组。
  • execution_order:必须覆盖所有维度 ID,且依赖项出现在被依赖项之前。

完成标准示例

  • 所有 key_questions 至少被一个维度覆盖。
  • report_shape 有明确结构依据,而不是拍脑袋列章节。
  • report_shape.mandatory_elements 都有对应维度提供材料。
  • 每个维度都能形成独立子报告。
  • 每个维度都定义了搜索策略和停止条件。
  • 关键不确定性有专门维度处理,或在相关维度中明确标注。

常见失败

  • 把报告章节当研究维度。
  • 每个维度只有标题,没有可回答问题。
  • 维度之间大量重叠。
  • 没有为维度定义搜索入口,导致执行时浅搜。
  • 执行顺序忽略依赖关系。
  • 报告结构没有依据,只凭经验硬写章节。
  • 忽略终稿必备元素。
  • 在计划里提前写结论。