deep-research

深度研究

核心系统指令

目的： 通过 8 阶段流程（界定范围 → 制定计划 → 检索 → 交叉验证 → 综合 → 评议 → 优化 → 整理），提供带有引用依据且经过验证的研究报告，并对来源可信度进行评分，同时逐步管理上下文。

上下文策略： 此技能采用 2025 年上下文工程最佳实践：

• 缓存静态指令（本节）
• 渐进式披露（仅在需要时加载参考资料）
• 避免“中间丢失”（将关键信息放在开头或结尾，而不是埋在中间）
• 使用明确的章节标记进行上下文导航

---

决策树（首先执行）

Request Analysis
├─ Simple lookup? → STOP: Use WebSearch, not this skill
├─ Debugging? → STOP: Use standard tools, not this skill
└─ Complex analysis needed? → CONTINUE

Mode Selection
├─ Initial exploration? → quick (3 phases, 2-5 min)
├─ Standard research? → standard (6 phases, 5-10 min) [DEFAULT]
├─ Critical decision? → deep (8 phases, 10-20 min)
└─ Comprehensive review? → ultradeep (8+ phases, 20-45 min)

Execution Loop (per phase)
├─ Load phase instructions from [methodology](./reference/methodology.md#phase-N)
├─ Execute phase tasks
├─ Spawn parallel agents if applicable
└─ Update progress

Validation Gate
├─ Run `python scripts/validate_report.py --report [path]`
├─ Pass? → Deliver
└─ Fail? → Fix (max 2 attempts) → Still fails? → Escalate

---

工作流（澄清 → 规划 → 执行 → 验证 → 报告）

自主性原则： 此技能独立运行。根据查询上下文推断假设。仅在出现关键错误或查询难以理解时停止。

1. 澄清（极少需要——优先自主处理）

默认：自主推进。根据查询信号推导假设。

仅在存在关键歧义时提问：

• 查询难以理解（例如，“研究那个东西”）
• 要求相互矛盾（例如，“快速完成 50 个来源的超深度分析”）

如有疑问：按标准模式继续。若结果不正确，用户会进行调整。

默认假设：

• 技术类查询 → 假设受众是技术人员
• 比较类查询 → 假设需要平衡的观点
• 趋势类查询 → 除非另有说明，否则假设关注最近 1–2 年
• 大多数查询默认使用标准模式

---

2. 规划

模式选择标准：

• 快速（2–5 分钟）：探索、概览、时间敏感的查询
• 标准（5–10 分钟）：适用于大多数场景，兼顾深度与速度［默认］
• 深度（10–20 分钟）：重要决策，需要全面验证
• 超深度（20–45 分钟）：关键分析，严谨性最高

宣布计划并执行：

• 简要说明：所选模式、预计耗时、来源数量
• 示例：“开始标准模式研究（5–10 分钟，15–30 个来源）”
• 无需等待批准，直接继续

---

3. 执行（阶段执行）

所有模式均执行：

• 阶段 1：SCOPE——定义边界（方法）
• 阶段 3：RETRIEVE——并行执行搜索（5-10 次并发搜索 + Agent）（方法）
• 阶段 8：PACKAGE——使用模板生成报告

Standard/Deep/UltraDeep 均执行：

• 阶段 2：PLAN——制定策略
• 阶段 4：TRIANGULATE——每项主张至少核验 3 个来源
• 阶段 4.5：OUTLINE REFINEMENT——根据证据调整结构（WebWeaver 2025）（方法）
• 阶段 5：SYNTHESIZE——生成新见解

Deep/UltraDeep 均执行：

• 阶段 6：CRITIQUE——红队分析
• 阶段 7：REFINE——弥补不足

关键：避免“中间信息丢失”

• 将关键发现放在各部分的开头和结尾，不要埋在中间
• 使用明确的标题和标记
• 结构：摘要 → 详情 → 结论（而不是把详情夹在中间）

渐进式上下文加载：

• 按需加载 方法论 的相关部分
• 仅在阶段 8 加载模板
• 不要将所有内容内联——请引用外部文件

反幻觉协议（关键）：

• 基于来源：每项事实性主张都必须立即引用具体来源 [N]
• 明确区分：区分事实（来自来源）和综合分析（你的分析）
• 明确标记：对于基于来源的陈述，使用“根据 [1]……”或“[1] 报告称……”
• 未经标注不得推测：将推断标注为“这表明……”，而不是“研究表明……”
• 引用前核验：如果不确定来源是否确实提到 X，切勿伪造引用
• 不确定时：应说明“未找到关于 X 的来源”，而不是编造参考资料

并行执行要求（对速度至关重要）：

阶段 3 RETRIEVE——必须并行搜索：

1. 拆分查询：在进行任何搜索之前，将查询拆分为 5-10 个相互独立的搜索方向
2. 同时启动所有搜索：在一条消息中通过多次工具调用启动所有搜索（不得顺序执行）
3. 监控 FFS 模式的质量阈值：
   • 跟踪来源数量和平均可信度评分
   • 达到阈值后继续执行（按模式而异，详见方法论）
   • 在后台继续搜索，以获取更多深入信息
4. 使用 Task 工具启动 3-5 个并行 Agent，开展深入调查

正确执行示例：

[Single message with 8+ parallel tool calls]
WebSearch #1: Core topic semantic
WebSearch #2: Technical keywords
WebSearch #3: Recent 2024-2025 filtered
WebSearch #4: Academic domains
WebSearch #5: Critical analysis
WebSearch #6: Industry trends
Task agent #1: Academic paper analysis
Task agent #2: Technical documentation deep dive

❌ 错误（顺序执行）：

WebSearch #1 → wait for results → WebSearch #2 → wait → WebSearch #3...

✅ 正确（并行执行）：

All searches + agents launched simultaneously in one message

---

4. 核验（始终执行）

步骤 1：引用核验（捕获伪造来源）

python scripts/verify_citations.py --report [path]

检查项：

• DOI 解析（核验引用是否确实存在）
• 标题/年份匹配（检测元数据是否不匹配）
• 标记可疑条目（2024 年及之后但没有 DOI、没有 URL 或核验失败）

如果发现可疑引用：

• 手动检查已标记条目
• 删除或替换伪造来源
• 重新运行，直到检查无误

步骤 2：结构与质量验证

python scripts/validate_report.py --report [path]

8 项自动检查：

1. 执行摘要长度（50-250 个词）
2. 必需章节齐全（另建议包含：主张表、反面证据）
3. 引用格式为 [1]、[2]、[3]
4. 参考文献与引用相匹配
5. 不含占位文本（TBD、TODO）
6. 字数合理（500-10000）
7. 至少 10 个来源
8. 不含失效的内部链接

如果检查失败：

• 尝试 1：自动修复格式/链接
• 尝试 2：手动检查并更正
• 失败 2 次后：停止 → 报告问题 → 询问用户

---

5. 报告

关键：生成全面、详尽的 Markdown 报告

文件组织（关键——确保易于访问）： 1. 在 /code 中创建有序文件夹：

• 始终创建专用文件夹：/code/[TopicName]_Research_[YYYYMMDD]/
• 从研究问题中提取简洁的主题名称（移除特殊字符，使用下划线或 CamelCase）
• 示例：
  • “psilocybin research 2025” → /code/Psilocybin_Research_20251104/
  • “compare React vs Vue” → /code/React_vs_Vue_Research_20251104/
  • “AI safety trends” → /code/AI_Safety_Trends_Research_20251104/
• 如果文件夹已存在，则使用该文件夹；如果不存在，则创建该文件夹
• 这样可以确保文件井然有序，便于访问

2. 将所有格式保存到同一文件夹：

Markdown（主要来源）：

• 保存到：[Documents folder]/research_report_[YYYYMMDD]_[topic_slug].md
• 同时将副本保存到：/code/research_output/（内部跟踪）
• 提供包含所有发现的完整详细报告

HTML（McKinsey 风格 — 始终生成）：

• 保存到：[Documents folder]/research_report_[YYYYMMDD]_[topic_slug].html
• 使用 McKinsey 模板：mckinsey_template
• 设计原则：锐利转角（无 border-radius）、低调的企业配色（navy #003d5c、gray #f8f9fa）、超紧凑布局、信息优先的结构
• 在顶部放置关键指标仪表板（提取 3-4 项关键量化发现）
• 使用数据表展示密集信息
• 基础字号 14px，间距紧凑，不使用装饰性渐变或颜色
• **归因渐变（2025）：**将每个引用 [N] 包裹在 <span class="citation"> 中，并嵌套显示来源详情的工具提示 div
• 生成后自动在浏览器中打开

PDF（专业打印版 — 始终生成）：

• 保存到：[Documents folder]/research_report_[YYYYMMDD]_[topic_slug].pdf
• 使用 generating-pdf skill（通过 Task 工具和 general-purpose agent）
• 采用专业排版，包含页眉和页码
• 生成后在默认 PDF 查看器中打开

3. 文件命名规范： 所有文件使用相同的基本名称，便于匹配：

• research_report_20251104_psilocybin_2025.md
• research_report_20251104_psilocybin_2025.html
• research_report_20251104_psilocybin_2025.pdf

长度要求（通过渐进式组装，不限长度）：

• 快速模式：2,000+ 字（基准质量门槛）
• 标准模式：4,000+ 字（全面分析）
• 深度模式：6,000+ 字（深入调查）
• 超深度模式：10,000-50,000+ 字（无上限 — 根据证据所需，尽可能全面）

不限长度的实现方式： 渐进式文件组装允许生成任意长度的报告，方法是逐节生成。 每个章节都会立即写入文件（避免输出 token 限制）。 复杂主题有很多发现？生成 20、30、50 项以上发现都不受限制！

内容要求：

• 将 template 作为精确结构
• 按适当深度生成每个章节（深度由证据决定，而非字数目标）
• 包含具体数据、统计数字、日期和数值（避免含糊表述）
• 每项发现都要用证据展开多个段落（按需撰写）
• 为每个章节投入专注的生成精力
• 不要写摘要 — 撰写完整分析

写作标准：

• **叙事驱动：**使用流畅的散文写作。每项发现都要讲述一个完整的故事：开篇交代背景，中段呈现证据，结尾说明影响
• **精准：**精心斟酌每个词语，让其承载明确意图
• **精炼：**不写冗余内容，避免花哨语法和不必要的修饰语
• **清晰：**将精确数字融入句子中（“该研究表明，死亡率降低了 23%”），而不是单独列在项目符号中
• **直接：**直接陈述发现，不加修饰
• **高信噪比：**信息密集，尊重读者的时间 要点符号政策（防疲劳执行）：
• 谨慎使用项目符号：仅用于不同类别的列表（产品名称、公司名录、编号步骤）
• 绝 NEVER 将项目符号用作主要内容呈现方式——它们会割裂思路
• 每个发现部分都需要实质性的散文段落（至少 3–5 段）
• 示例：不要写“• 市场规模：24 亿美元”，而应写“2023 年，全球市场规模达到 24 亿美元，这得益于消费者需求增长和监管利好因素 [1]。”

防疲劳质量检查（应用于每个部分）： 完成一个部分前，请确认：

• 段落数：主要部分（## 标题）至少包含 3 段
• 散文优先：项目符号内容占比低于 20%（流畅散文须占至少 80%）
• 无占位内容：不含“Content continues”“Due to length”“[Sections X-Y]”
• 证据充分：包含具体数据点、统计数字和引述（而非笼统表述）
• 引文密度：主要论点所在句子中包含引文

**如果任一项未通过：**在进入下一部分前重新生成该部分。

来源归属标准（防止捏造的关键要求）：

• 即时引用：每项事实性陈述后都须在同一句中附上 [N] 引文
• 直接引用来源：事实性陈述使用“根据 [1]……”或“[1] 报告称……”等表述
• 区分事实与综合分析：
  • ✅ 正确：“治疗组的死亡率下降了 23%（p<0.01）[1]。”
  • ❌ 错误：“研究显示死亡率显著改善。”
• 避免模糊归属：
  • ❌ 绝不使用：“研究表明……”“研究显示……”“专家认为……”
  • ✅ 始终使用：“Smith 等人（2024）发现……”[1]、“根据 FDA 数据……”[2]
• 明确标示推测：
  • ✅ 正确：“这表明可能存在一种作用机制……”（分析，而非事实）
  • ❌ 错误：“其作用机制是……”（未附引文却作为事实陈述）
• 承认不确定性：
  • ✅ 正确：“未找到直接涉及 X 的来源。”
  • ❌ 错误：为填补空缺而捏造引文
• 模板模式：“[包含数字/数据的具体论点] [引文]。[分析/影响]。”

交付给用户：

1. 执行摘要（直接在聊天中提供）
2. 整理后的文件夹路径（例如：“所有文件已保存至：/code/Psilocybin_Research_20251104/”）
3. 确认已生成以下三种格式：
   • Markdown（源文件）
   • HTML（麦肯锡风格，已在浏览器中打开）
   • PDF（专业打印版，已在查看器中打开）
4. 来源质量评估摘要（来源数量）
5. 后续步骤（如适用）

生成工作流：渐进式文件组装（长度不限）

阶段 8.1：设置

# Extract topic slug from research question
# Create folder: /code/[TopicName]_Research_[YYYYMMDD]/
mkdir -p /code/[folder_name]

# Create initial markdown file with frontmatter
# File path: [folder]/research_report_[YYYYMMDD]_[slug].md

阶段 8.2：渐进式章节生成

**关键策略：**使用 Write/Edit 工具逐节生成内容并写入文件。 这样既可以生成不限长度的报告，又能让每次生成都保持适度。

输出令牌数限制保护措施（关键——Claude Code 默认值：32K）：

Claude Code 默认限制：32,000 个输出令牌（每次技能执行总计约 24,000 个单词） 这是一个硬性限制，无法在技能内更改。

这意味着：

• 总输出（你的文本 + 所有工具调用内容）必须少于 32,000 个令牌
• 32,000 个令牌约等于最多 24,000 个单词
• 留出安全余量：总输出目标不超过 20,000 个单词

各模式下报告的实际篇幅：

• Quick 模式：2,000–4,000 个单词 ✅（远低于限制）
• Standard 模式：4,000–8,000 个单词 ✅（远低于限制）
• Deep 模式：8,000–15,000 个单词 ✅（谨慎控制即可完成）
• UltraDeep 模式：15,000–20,000 个单词 ⚠️（接近限制，需密切监控）

对于超过 20,000 个单词的报告： 用户必须多次运行技能：

• 第 1 次运行：“生成第 1 部分（第 1–6 节）”→ 保存为 part1.md
• 第 2 次运行：“生成第 2 部分（第 7–12 节）”→ 保存为 part2.md
• 用户手动合并文件，或要求 Claude 合并文件

自动续写策略（真正不限长度）： 当单次运行生成的报告超过 18,000 个单词时：

1. 生成第 1–10 节（保持在 18K 个单词以内）
2. 保存续接状态文件，并保留上下文
3. 通过 Task 工具启动续接 Agent
4. 续接 Agent：读取状态 → 生成下一批内容 → 如有需要，启动下一个 Agent
5. 递归续接，直到全部完成

这样即可实现无限长度，同时遵守每个 Agent 32K 的限制

初始化引用追踪：

citations_used = []  # Maintain this list in working memory throughout

章节生成循环：

模式： 生成章节内容 → 使用 Write/Edit 工具写入该内容 → 继续下一节 每次 Write/Edit 调用只包含一个章节（≤2,000 个单词）

1. 执行摘要（200–400 个单词）

   • 生成章节内容
   • 工具：Write(file, content=frontmatter + 执行摘要)
   • 追踪已使用的引用
   • 进度："✓ 执行摘要"

2. 引言（400–800 个单词）

   • 生成章节内容
   • 工具：Edit(file, old=last_line, new=old + 引言章节)
   • 追踪已使用的引用
   • 进度："✓ 引言"

3. 发现 1（600–2,000 个单词）

   • 生成完整发现内容
   • 工具：Edit(file, append 发现 1)
   • 追踪已使用的引用
   • 进度："✓ 发现 1"

4. 发现 2（600–2,000 个单词）

   • 生成完整发现内容
   • 工具：Edit(file, append 发现 2)
   • 追踪已使用的引用
   • 进度："✓ 发现 2"

... 对所有发现继续执行（每项发现调用一次 Edit 工具，每次 ≤2,000 个单词）

重要： 如果有 10 项发现，每项 1,500 个单词，则发现部分共计 15,000 个单词 这没有问题，因为每次 Edit 调用只有 1,500 个单词（低于每次工具调用 2,000 个单词的限制） 文件总长度会达到 15,000 个单词，但没有任何单次工具调用超出限制

4. 综合与洞见

   • 生成：源陈述之外的新颖洞见（综合所需篇幅不限）
   • 工具：Edit（追加到文件）
   • 追踪：提取引用，并追加到 citations_used
   • 进度："已生成综合 ✓"

5. 局限与注意事项

   • 生成：反面证据、缺漏、不确定性（深度适当）
   • 工具：Edit（追加到文件）
   • 追踪：提取引用，并追加到 citations_used
   • 进度："已生成局限 ✓"

6. 建议

   • 生成：即时行动、后续步骤、研究需求（深度适当）
   • 工具：Edit（追加到文件）
   • 追踪：提取引用，并追加到 citations_used
   • 进度："已生成建议 ✓"

7. 参考文献（重要——包含所有引用）

   • 生成：完整的参考文献，包含 citations_used 列表中的每条引用
   • 格式：[1]、[2]、[3]……[N]——每条引用都要有完整条目
   • 核验：检查 citations_used 列表；如果列表包含 [1] 至 [73]，就生成全部 73 条
   • 不得使用范围（[1-50]）、占位符（"其他引用"）或截断
   • 工具：Edit（追加到文件）
   • 进度："已生成参考文献 ✓（N 条引用）"

8. 方法论附录

   • 生成：研究流程、核验方法（深度适当）
   • 工具：Edit（追加到文件）
   • 进度："已生成方法论 ✓"

阶段 8.3：自动续接决策点

生成章节后，检查字数：

如果总输出 ≤18,000 个单词： 正常完成

• 生成参考文献（包含所有引用）
• 生成方法论
• 核验报告完整性
• 保存副本到 /code/research_output/
• 完成！✓

如果总输出将超过 18,000 个单词： 自动续接协议

步骤 1：保存续接状态 创建文件：/code/research_output/continuation_state_[report_id].json

{
  "version": "2.1.1",
  "report_id": "[unique_id]",
  "file_path": "[absolute_path_to_report.md]",
  "mode": "[quick|standard|deep|ultradeep]",

  "progress": {
    "sections_completed": [list of section IDs done],
    "total_planned_sections": [total count],
    "word_count_so_far": [current word count],
    "continuation_count": [which continuation this is, starts at 1]
  },

  "citations": {
    "used": [1, 2, 3, ..., N],
    "next_number": [N+1],
    "bibliography_entries": [
      "[1] Full citation entry",
      "[2] Full citation entry",
      ...
    ]
  },

  "research_context": {
    "research_question": "[original question]",
    "key_themes": ["theme1", "theme2", "theme3"],
    "main_findings_summary": [
      "Finding 1: [100-word summary]",
      "Finding 2: [100-word summary]",
      ...
    ],
    "narrative_arc": "[Current position in story: beginning/middle/conclusion]"
  },

  "quality_metrics": {
    "avg_words_per_finding": [calculated average],
    "citation_density": [citations per 1000 words],
    "prose_vs_bullets_ratio": [e.g., "85% prose"],
    "writing_style": "technical-precise-data-driven"
  },

  "next_sections": [
    {"id": N, "type": "finding", "title": "Finding X", "target_words": 1500},
    {"id": N+1, "type": "synthesis", "title": "Synthesis", "target_words": 1000},
    ...
  ]
}

步骤 2：启动续接 Agent

使用通用 Agent 调用 Task 工具：

Task(
  subagent_type="general-purpose",
  description="Continue deep-research report generation",
  prompt="""
CONTINUATION TASK: You are continuing an existing deep-research report.

CRITICAL INSTRUCTIONS:
1. Read continuation state file: /code/research_output/continuation_state_[report_id].json
2. Read existing report to understand context: [file_path from state]
3. Read LAST 3 completed sections to understand flow and style
4. Load research context: themes, narrative arc, writing style from state
5. Continue citation numbering from state.citations.next_number
6. Maintain quality metrics from state (avg words, citation density, prose ratio)

CONTEXT PRESERVATION:
- Research question: [from state]
- Key themes established: [from state]
- Findings so far: [summaries from state]
- Narrative position: [from state]
- Writing style: [from state]

YOUR TASK:
Generate next batch of sections (stay under 18,000 words):
[List next_sections from state]

Use Write/Edit tools to append to existing file: [file_path]

QUALITY GATES (verify before each section):
- Words per section: Within ±20% of [avg_words_per_finding]
- Citation density: Match [citation_density] ±0.5 per 1K words
- Prose ratio: Maintain ≥80% prose (not bullets)
- Theme alignment: Section ties to key_themes
- Style consistency: Match [writing_style]

After generating sections:
- If more sections remain: Update state, spawn next continuation agent
- If final sections: Generate complete bibliography, verify report, cleanup state file

HANDOFF PROTOCOL (if spawning next agent):
1. Update continuation_state.json with new progress
2. Add new citations to state
3. Add summaries of new findings to state
4. Update quality metrics
5. Spawn next agent with same instructions
"""
)

步骤 3：报告续接状态 告知用户：

📊 Report Generation: Part 1 Complete (N sections, X words)
🔄 Auto-continuing via spawned agent...
   Next batch: [section list]
   Progress: [X%] complete

阶段 8.4：续接 Agent 质量协议

续接 Agent 启动时： 上下文加载（关键）：

1. 读取 continuation_state.json → 加载所有上下文
2. 读取现有报告文件 → 查看最后 3 个章节
3. 提取以下模式：
   • 句子结构复杂度
   • 使用的技术术语
   • 引用的位置模式
   • 段落过渡风格

生成前检查清单：

• 已加载研究上下文（主题、问题、叙事脉络）
• 已查看前文，确保行文连贯
• 已加载引用编号（从 N+1 开始）
• 已加载质量目标（字数、密度、风格）
• 已了解叙事脉络所处阶段（开头／中段／结尾）

逐节生成：

1. 生成章节内容
2. 质量检查：
   • 字数：在目标值 ±20% 范围内
   • 引用密度：与既定比例一致
   • 正文比例：≥80%
   • 主题关联：与 key_themes 相关
   • 风格匹配：与 quality_metrics.writing_style 保持一致
3. 如果任意一项检查未通过：重新生成该章节
4. 如果全部通过：写入文件并更新状态

交接决策：

• 计算：当前字数 + 剩余章节数 × 每节平均字数
• 如果总字数 < 18K：生成所有剩余章节并完成
• 如果总字数 > 18K：生成部分批次，更新状态，并启动下一个 Agent

最终 Agent 的职责：

• 生成最后的内容章节
• 使用 state.citations.bibliography_entries 中的所有引用生成完整参考文献
• 阅读组装完成的整篇报告
• 运行验证：python scripts/validate_report.py --report [path]
• 删除 continuation_state.json（清理）
• 向用户报告完成情况及指标

内置防疲劳机制： 每个 Agent 只生成适量内容（≤18K 字），以保持质量。 保留上下文，确保跨续接边界的内容连贯一致。

生成 HTML（McKinsey 风格）

1. 从 ./templates/mckinsey_report_template.html 读取 McKinsey 模板

2. 从研究发现中提取 3-4 个关键量化指标，用于仪表板

3. 使用 Python 脚本将 MD 转换为 HTML：

   cd ~/.claude/skills/deep-research
   python scripts/md_to_html.py [markdown_report_path]
   

   脚本会返回两部分：

   • Part A ({{CONTENT}})： 除参考文献外的所有章节，已正确转换为 HTML
   • Part B ({{BIBLIOGRAPHY}})： 仅参考文献章节，已格式化为 HTML

   关键： 脚本会自动处理所有转换：

   • 标题：## → <div class="section"><h2 class="section-title">，### → <h3 class="subsection-title">
   • 列表：Markdown 项目符号 → <ul><li>，并正确处理嵌套
   • 表格：Markdown 表格 → <table>，包含 thead/tbody
   • 段落：将文本包裹在 <p> 标签中
   • 粗体／斜体：text → <strong>，text → <em>
   • 引用：保留 [N]，以便在步骤 4 中转换为工具提示

4. 添加引用工具提示（归因渐变）： 对于 {{CONTENT}} 中的每个 [N] 引用（不包括参考文献），可选择添加交互式工具提示：

   <span class="citation">[N]
     <span class="citation-tooltip">
       <div class="tooltip-title">[Source Title]</div>
       <div class="tooltip-source">[Author/Publisher]</div>
       <div class="tooltip-claim">
         <div class="tooltip-claim-label">Supports Claim:</div>
         [Extract sentence with this citation]
       </div>
     </span>
   </span>
   

   注意：为节省时间，此步骤可选。使用基本的 [N] 引用即可。

5. 替换模板中的占位符：

   • {{TITLE}} - 报告标题（从 MD 中的第一个 ## 标题提取）
   • {{DATE}} - 生成日期（YYYY-MM-DD 格式）
   • {{SOURCE_COUNT}} - 唯一来源的数量
   • {{METRICS_DASHBOARD}} - 步骤 2 生成的指标 HTML
   • {{CONTENT}} - Part A 的 HTML（脚本输出）
   • {{BIBLIOGRAPHY}} - Part B 的 HTML（脚本输出）

6. 关键：不得包含表情符号 - 从最终 HTML 中移除所有表情符号

7. 保存到：[folder]/research_report_[YYYYMMDD]_[slug].html

8. 验证 HTML（必须）：

   python scripts/verify_html.py --html [html_path] --md [md_path]
   

   • 检查通过：继续步骤 9
   • 检查未通过：修复错误并重新运行验证

9. 在浏览器中打开：open [html_path]

生成 PDF

1. 使用 Task 工具和通用 Agent
2. 调用 generating-pdf 技能，并以 Markdown 作为输入
3. 保存到：[folder]/research_report_[YYYYMMDD]_[slug].pdf
4. 完成后会自动打开 PDF

---

输出规范

格式： 严格按照模板撰写全面的 Markdown 报告

必需章节（均须详尽）：

• 执行摘要（2–3 个简洁段落，50–250 个单词）
• 引言（2–3 个段落：问题、范围、方法、假设）
• 主要分析（4–8 项发现，每项 300–500 个单词，并附上引用 [1]、[2]、[3]）
• 综合与洞见（500–1000 个单词：模式、新颖洞见、影响）
• 局限性与注意事项（2–3 个段落：缺口、假设、不确定性）
• 建议（3–5 项即时行动、3–5 项后续步骤、3–5 项进一步研究）
• 参考文献（至关重要——请参阅以下规则）
• 方法附录（2–3 个段落：流程、来源、核验）

参考文献要求（零容忍——缺少完整参考文献，报告即不可用）：

• ✅ 必须列出报告正文中使用的每一条引用 [N]（如果报告中有 [1]–[50]，就必须列出全部 50 条）
• ✅ 格式：[N] 作者/机构（年份）。“标题”。出版物。URL（检索日期：日期）
• ✅ 每条独占一行，并包含所有元数据
• ❌ 不得使用占位内容：绝不能写“[8-75] 其他引用”、“……继续……”、“等等”或“[继续列出来源……]”
• ❌ 不得使用范围：必须逐条写出 [3]、[4]、[5]……，不得写成“[3-50]”
• ❌ 不得截断：如果引用了 30 个来源，就必须完整列出全部 30 条
• ⚠️ 如果参考文献包含占位内容或缺少引用，验证将失败
• ⚠️ 没有完整参考文献，报告就毫无价值——主张无法核验

严格禁止：

• 占位文本（TBD、TODO、[citation needed]）
• 未引用来源的重要主张
• 无效链接
• 缺少必需章节
• 以简短摘要代替详细分析
• 没有具体证据的含糊表述

写作标准（至关重要）：

• 叙述驱动： 使用流畅的文字和完整句子，循序渐进地帮助读者理解
• 精准： 审慎选择每个词语，每个词都必须有明确用意
• 精简： 删除赘述、不必要的形容词和花哨的语法
• 清晰： 使用精确的技术术语，避免歧义。将具体数字写入句子，而非项目符号
• 直截了当： 清楚陈述发现，不加修饰
• 信息密度： 提高信息密度，尊重读者的时间
• 项目符号规范： 仅在列举不同项目（产品、公司、步骤）时使用项目符号。默认使用段落
• 精准示例：
  • 不佳：“显著改善了结果” → 良好：“死亡率降低了 23%（p<0.01）”
  • 不佳：“多项研究表明” → 良好：“5 项 RCT（n=1,847）显示”
  • 不佳：“可能有益” → 良好：“生物标志物 X 增加了 15%”
  • 不佳：“• 市场：24 亿美元” → 良好：“2023 年，受消费者需求推动，市场规模达到 24 亿美元 [1]。”

质量门槛（由验证器强制执行）：

• 至少 2,000 个单词（标准模式）
• 平均可信度评分 >60/100
• 每项重要主张至少 3 个来源
• 明确区分事实与分析
• 包含所有章节且内容详尽

---

错误处理与停止规则

出现以下情况时立即停止：

• 同一错误导致验证失败 2 次 → 暂停、报告并询问用户
• 穷尽搜索后来源仍少于 5 个 → 报告限制并请求指示
• 用户中断或更改范围 → 确认新的方向

妥善降级处理：

• 来源为 5–10 个 → 在局限性中说明，并加强核验后继续
• 达到时间限制 → 整理部分结果并记录缺口
• 出现高优先级批评意见 → 立即处理

错误格式：

⚠️ Issue: [Description]
📊 Context: [What was attempted]
🔍 Tried: [Resolution attempts]
💡 Options:
   1. [Option 1]
   2. [Option 2]
   3. [Option 3]

---

质量标准（始终执行）

每份报告都必须：

• 至少包含 10 个来源（不足时须说明）
• 每项重要主张至少有 3 个来源
• 执行摘要少于 250 个单词
• 引用完整并包含 URL
• 评估可信度
• 包含局限性章节
• 记录方法
• 不含占位内容

优先级： 完整性高于速度。质量高于速度。

---

输入与假设

必需：

• 研究问题（字符串）

可选：

• 模式（quick/standard/deep/ultradeep）
• 时间限制
• 所需视角/来源
• 输出格式

假设：

• 用户需要经过核实且有引用支持的信息
• 该主题有 10-50 个可用来源
• 时间投入：5-45 分钟

---

适用场景 / 不适用场景

适用于：

• 综合分析（需要 10 个以上来源）
• 比较技术/方法/策略
• 前沿技术综述
• 多角度调查
• 技术决策
• 市场/趋势分析

不适用于：

• 简单查询（使用 WebSearch）
• 调试（使用标准工具）
• 只需 1-2 个搜索答案
• 需要快速回答的时效性问题

---

脚本（仅使用离线 Python 标准库）

位置： ./scripts/

• research_engine.py - 编排引擎
• validate_report.py - 质量验证（8 项检查）
• citation_manager.py - 引用跟踪
• source_evaluator.py - 可信度评分（0-100）

无需外部依赖。

---

渐进式参考资料（按需加载）

不要将以下内容内联，仅作参考：

• 完整方法论 - 8 个阶段的详细说明
• 报告模板 - 输出结构
• README - 使用文档
• 快速入门 - 快速参考
• 竞品分析 - 与 OpenAI/Gemini 的对比

上下文管理： 仅按需加载当前阶段所需的文件。不要预加载所有内容。

---

---

动态执行区域

用户查询处理： [执行期间将在此处插入用户研究问题]

检索到的信息： [此处将汇总搜索结果和来源]

生成的分析： [此处将生成发现、综合分析和报告内容]

注意： 此部分在技能定义中保持为空，仅在运行时填充内容。