Back to skills
extension
Category: Development & EngineeringNo API key required

sn-report-format-discovery

发现特定报告类型的结构规范与写作约束;当需要判断“这类报告应该长什么样”、为报告生成章节结构/必备元素/风格约束,或为 deep research 的 `report_shape` 提供依据时使用。适用于行业/市场/竞品分析、技术选型、政策/法律/公共事务、学术/医学综述、尽职调查、事件追踪与事实核查等场景,也可单独用于报告格式研究。

personAuthor: gaclovehubgithub

Report Format Discovery

回答“这类报告应该长什么样”。它研究的是报告格式本身,不是正文事实、研究结论或执行计划。

这个 skill 既可以:

  • 独立使用:用户单独询问某类报告的标准结构、章节建议、必备元素和写法约束。
  • 嵌入 deep research:为 plan.json.report_shape 或其他结构化格式规格提供依据。

核心原则

  • 格式本身是可研究对象:优先查标准制定者、发布机构、期刊/监管/行业组织的原文。
  • 可信来源优先于通用模板:宁可基于 1-2 个高可信来源抽结构,也不要用二手教程拼凑。
  • 标准与范例互补:标准说明“应包含什么”,高质量范例说明“实际如何组织”。
  • 只抽结构,不抽结论:只产出章节、必备元素、风格约束、反模式和适用场景。
  • 输出服从调用场景:独立使用时直接返回格式规格;嵌入工作流时适配调用方要求的字段结构。

适用场景

优先覆盖 deep research 常见的 6 类场景:

  1. 行业 / 市场 / 竞品 / 趋势研究
  2. 技术选型 / 架构评估 / 产品方案比较
  3. 政策 / 法律 / 监管 / 公共事务
  4. 学术 / 医学 / 社科综述与证据整合
  5. 尽职调查 / 实体调查 / 风险审查
  6. 事件追踪 / 时间线还原 / 事实核查

如果用户请求不属于以上场景,也可按“最接近的报告类型”处理,不要强行套模板。

输入

可接受最小输入:

  • 用户原始请求;或
  • {report_dir}/request.md

可选补充输入:

  • 明确的 domain
  • 明确的 genre
  • audience / 使用场景
  • region
  • 调用方要求的输出路径或输出 schema

若输入不足,先从请求中推断:

  • domain:研究领域
  • genre:报告类型,如行业研究、技术选型、政策简报、学术综述、尽调、事件追踪
  • audience:目标读者和使用场景
  • region:中国、美国、欧盟、全球等;无明确要求可留空

执行流程

  1. 识别报告任务:判断用户要写的是哪类报告,服务什么判断或决策。
  2. 锁定场景类型:把任务归入最接近的核心场景,不要混用多个主类型。
  3. 选择可信入口:按场景选择标准、模板、权威指南、真实高质量范例。
  4. 筛选来源:优先原始来源,剔除教程、营销文、新闻转述和低质量聚合。
  5. 抽取结构:提取章节、必备元素、图表/表格、语气约束、反模式。
  6. 判断是否足够:若已有 1-3 个可信来源且结构趋于稳定,即可停止。
  7. 适配输出:按独立模式或工作流模式输出格式规格。

来源优先级

按场景选入口,不要机械地全搜。

1. 学术 / 医学 / 社科综述

优先级:

  1. 报告规范或方法学组织:EQUATOR、PRISMA、CONSORT、STROBE、Cochrane、NLM、APA 等。
  2. 目标领域顶级期刊的 author guidelines / guide for authors。
  3. 高质量综述论文、官方 handbook 或系统综述教学资料。

2. 行业 / 市场 / 竞品 / 趋势研究

优先级:

  1. 监管披露模板、交易所披露要求、行业协会标准。
  2. 头部咨询、投研、产业机构发布的完整研究报告。
  3. 大型机构、国际组织或统计机构的行业分析框架。

3. 技术选型 / 架构评估 / 产品比较

优先级:

  1. 官方评估框架、采购/招标模板、架构决策记录规范、云厂商/标准组织最佳实践。
  2. 高质量技术选型文档、架构评估模板、企业 RFC / ADR 范式。
  3. 头部工程团队公开的评估矩阵或对比报告。

重点抽取:

  • 评估维度
  • 比较矩阵
  • 约束条件
  • 风险与取舍
  • 推荐与适用场景

4. 政策 / 法律 / 监管 / 公共事务

优先级:

  1. 政府、监管机构、法院、国际组织的正式文档或模板。
  2. 智库、政策研究机构、议会/国会研究服务机构的报告格式。
  3. 同类政策简报、法律备忘录、监管说明的高质量范例。

5. 尽职调查 / 实体调查 / 风险审查

优先级:

  1. 监管披露要求、合规审查清单、审计/风控框架。
  2. 投资、咨询、法律、审计机构常见尽调结构。
  3. 公开可得的高质量尽调模板或调查框架。

重点抽取:

  • 对象概览
  • 核心风险类别
  • 证据缺口
  • 红旗事项
  • 结论等级或后续动作

6. 事件追踪 / 事实核查 / 时间线还原

优先级:

  1. 主流事实核查机构方法说明。
  2. 调查报道、事件复盘、事故报告、官方通报的结构。
  3. 新闻编辑手册或调查型报道格式规范。

重点抽取:

  • 时间线
  • 各方说法
  • 已确认 / 未确认事实
  • 证据等级
  • 后续影响

采信规则

采信来源前,先判断它是否真的能用于抽结构。

正向信号至少命中 2 项:

  • 来自官方机构、期刊、标准组织、监管机构、国际组织或公认头部机构。
  • 是 PDF 原文、官方页面、author guidelines、handbook、checklist、template 或完整报告。
  • 有明确标题层级、目录、章节说明、checklist 或必备元素列表。
  • 有发布机构、日期、版本号、DOI、文档编号或法规编号。
  • 内容足够完整,能抽结构,而不是只有摘要。

命中任一负向信号则丢弃:

  • “如何写报告”的个人教程或营销文章。
  • 新闻稿、媒体摘要、二手转述。
  • 内容聚合站、论坛回答、博客搬运、低质量下载站。
  • 正文过短,无法看到结构。
  • 来源身份不明或无法确认发布机构。

不要为了凑来源数量降低采信标准。

搜索退出

  • 理想情况:采信 2-3 个来源后停止。
  • 如果只有 1 个高可信标准来源,也可以输出格式规格,但要说明来源有限。
  • 如果 6-8 轮搜索仍无可信来源,回退到通用结构,并说明回退原因。
  • 不要重复搜索同一个入口;换关键词、机构类型或报告类型视角。

抽取内容

只抽这些内容:

  • 报告类型名称和适用场景
  • 推荐或强制章节结构
  • 每个章节必须包含的元素
  • 非章节必备元素,如矩阵表、方法说明、风险清单、流程图、摘要格式
  • 风格和约束,如客观语气、证据等级、披露口径、是否区分事实与判断
  • 对后续研究或成稿会产生约束的结构要求

不要抽这些内容:

  • 来源报告的具体结论
  • 与用户主题无关的行业观点
  • 正文事实材料
  • 正式引用编号或参考文献列表

输出模式

根据调用场景输出,不强绑单一文件名。

模式 A:独立使用

如果用户只是问“这类报告应该怎么写 / 应该有哪些章节 / 有没有标准结构”,直接在对话中或按用户指定路径输出格式规格。

推荐结构:

{
  "genre": "报告类型",
  "domain": "研究领域",
  "audience": "目标读者",
  "format_basis": [
    {
      "type": "standard_guideline | official_template | real_exemplar | domain_convention | fallback",
      "name": "来源名称",
      "url": "来源 URL,如有",
      "credibility_reason": "为什么可信",
      "what_extracted": "从中抽取的结构要点"
    }
  ],
  "sections": [
    {
      "name": "章节名",
      "required": true,
      "purpose": "该章节承担什么功能",
      "elements": ["必须包含的内容"],
      "source_basis": ["对应 format_basis.name"]
    }
  ],
  "mandatory_elements": ["必须包含的非章节元素"],
  "style": {
    "tone": "写作风格",
    "tables_or_figures": ["推荐的表格或图"],
    "domain_specific_metrics": ["领域特有指标或口径"],
    "anti_patterns": ["不应做的事"]
  },
  "fallback_used": false,
  "fallback_reason": null
}

模式 B:deep research / planning 内嵌

如果调用方需要把结果放进 plan.json.report_shape,保留至少这些信息:

  • format_basis
  • sections
  • mandatory_elements
  • style

如果本地 schema 更简化,可以压缩字段,但不要丢掉“结构依据”。

质量门槛

  • sections 来自可信来源的结构抽取,而不是凭空生成。
  • 每个 format_basis 都说明可信原因和抽取内容。
  • mandatory_elementsstyle 能帮助后续研究或成稿判断需要什么材料。
  • 若不是 fallback,至少有一个可信来源支撑结构。
  • 若使用 fallback,必须说明搜索失败原因和回退逻辑。
  • 输出必须能被单独使用,而不依赖 deep research 其他阶段。

常见失败

  • 使用二手教程替代标准原文。
  • 找到真实报告后抽取其结论,而不是结构。
  • 把格式规格写成研究计划或终稿大纲。
  • 忽略受众和使用场景,套通用模板。
  • 为凑来源数量降低可信标准。
  • 只适配 deep research,导致单独使用时不可读或不可复用。