微信扫一扫Report Format Discovery
回答“这类报告应该长什么样”。它研究的是报告格式本身，不是正文事实、研究结论或执行计划。
这个 skill 既可以：
- 独立使用：用户单独询问某类报告的标准结构、章节建议、必备元素和写法约束。
- 嵌入 deep research：为
plan.json.report_shape或其他结构化格式规格提供依据。
核心原则
- 格式本身是可研究对象：优先查标准制定者、发布机构、期刊/监管/行业组织的原文。
- 可信来源优先于通用模板：宁可基于 1-2 个高可信来源抽结构，也不要用二手教程拼凑。
- 标准与范例互补：标准说明“应包含什么”，高质量范例说明“实际如何组织”。
- 只抽结构，不抽结论：只产出章节、必备元素、风格约束、反模式和适用场景。
- 输出服从调用场景：独立使用时直接返回格式规格；嵌入工作流时适配调用方要求的字段结构。
适用场景
优先覆盖 deep research 常见的 6 类场景：
- 行业 / 市场 / 竞品 / 趋势研究
- 技术选型 / 架构评估 / 产品方案比较
- 政策 / 法律 / 监管 / 公共事务
- 学术 / 医学 / 社科综述与证据整合
- 尽职调查 / 实体调查 / 风险审查
- 事件追踪 / 时间线还原 / 事实核查
如果用户请求不属于以上场景，也可按“最接近的报告类型”处理，不要强行套模板。
输入
可接受最小输入：
- 用户原始请求；或
{report_dir}/request.md
可选补充输入：
- 明确的
domain - 明确的
genre audience/ 使用场景region- 调用方要求的输出路径或输出 schema
若输入不足，先从请求中推断：
domain：研究领域genre：报告类型，如行业研究、技术选型、政策简报、学术综述、尽调、事件追踪audience：目标读者和使用场景region：中国、美国、欧盟、全球等；无明确要求可留空
执行流程
- 识别报告任务：判断用户要写的是哪类报告，服务什么判断或决策。
- 锁定场景类型：把任务归入最接近的核心场景，不要混用多个主类型。
- 选择可信入口：按场景选择标准、模板、权威指南、真实高质量范例。
- 筛选来源：优先原始来源，剔除教程、营销文、新闻转述和低质量聚合。
- 抽取结构：提取章节、必备元素、图表/表格、语气约束、反模式。
- 判断是否足够：若已有 1-3 个可信来源且结构趋于稳定，即可停止。
- 适配输出：按独立模式或工作流模式输出格式规格。
来源优先级
按场景选入口，不要机械地全搜。
1. 学术 / 医学 / 社科综述
优先级：
- 报告规范或方法学组织：EQUATOR、PRISMA、CONSORT、STROBE、Cochrane、NLM、APA 等。
- 目标领域顶级期刊的 author guidelines / guide for authors。
- 高质量综述论文、官方 handbook 或系统综述教学资料。
2. 行业 / 市场 / 竞品 / 趋势研究
优先级：
- 监管披露模板、交易所披露要求、行业协会标准。
- 头部咨询、投研、产业机构发布的完整研究报告。
- 大型机构、国际组织或统计机构的行业分析框架。
3. 技术选型 / 架构评估 / 产品比较
优先级：
- 官方评估框架、采购/招标模板、架构决策记录规范、云厂商/标准组织最佳实践。
- 高质量技术选型文档、架构评估模板、企业 RFC / ADR 范式。
- 头部工程团队公开的评估矩阵或对比报告。
重点抽取：
- 评估维度
- 比较矩阵
- 约束条件
- 风险与取舍
- 推荐与适用场景
4. 政策 / 法律 / 监管 / 公共事务
优先级：
- 政府、监管机构、法院、国际组织的正式文档或模板。
- 智库、政策研究机构、议会/国会研究服务机构的报告格式。
- 同类政策简报、法律备忘录、监管说明的高质量范例。
5. 尽职调查 / 实体调查 / 风险审查
优先级：
- 监管披露要求、合规审查清单、审计/风控框架。
- 投资、咨询、法律、审计机构常见尽调结构。
- 公开可得的高质量尽调模板或调查框架。
重点抽取：
- 对象概览
- 核心风险类别
- 证据缺口
- 红旗事项
- 结论等级或后续动作
6. 事件追踪 / 事实核查 / 时间线还原
优先级：
- 主流事实核查机构方法说明。
- 调查报道、事件复盘、事故报告、官方通报的结构。
- 新闻编辑手册或调查型报道格式规范。
重点抽取：
- 时间线
- 各方说法
- 已确认 / 未确认事实
- 证据等级
- 后续影响
采信规则
采信来源前，先判断它是否真的能用于抽结构。
正向信号至少命中 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_basissectionsmandatory_elementsstyle
如果本地 schema 更简化，可以压缩字段，但不要丢掉“结构依据”。
质量门槛
sections来自可信来源的结构抽取，而不是凭空生成。- 每个
format_basis都说明可信原因和抽取内容。 mandatory_elements和style能帮助后续研究或成稿判断需要什么材料。- 若不是 fallback，至少有一个可信来源支撑结构。
- 若使用 fallback，必须说明搜索失败原因和回退逻辑。
- 输出必须能被单独使用，而不依赖 deep research 其他阶段。
常见失败
- 使用二手教程替代标准原文。
- 找到真实报告后抽取其结论，而不是结构。
- 把格式规格写成研究计划或终稿大纲。
- 忽略受众和使用场景，套通用模板。
- 为凑来源数量降低可信标准。
- 只适配 deep research，导致单独使用时不可读或不可复用。