vaDeepresearch

SKILL.md

---
name: vadeepresearch
description: "系统化深度研究技能。适用于联网研究、市场分析、竞品分析、行业研究、技术调研、论文与开源项目梳理、报告写作前置调研、PPT/文档/方案生成前的信息搜集与深度分析。当用户提出深度分析xxx、帮我分析xxx、快速分析xxx、深度研究xxx、详细分析xxx等话术时使用该 skills。启用后必须先引导用户选择快速分析或深度分析模式；最终必须输出 Markdown（.md）文件，并提供下载地址或可直接打开的文件入口。"
version: 1.1.1
license: MIT-0
metadata:
  openclaw:
    emoji: "🔬"
    always: false


---

# vaDeepResearch

## 1. 核心定位

本技能用于将“单次检索式回答”升级为“多角度检索、多源交叉验证、结构化综合分析、可追溯报告输出”的系统化研究流程。

研究规划、问题拆解、查询设计、证据抽取、冲突识别、综合分析和报告生成均由大模型自主完成；事实获取与验证仅使用当前运行环境中真实可用的搜索、网页读取、文件读取、学术检索、代码仓库检索或连接器工具。

核心原则：

1. **先研究，后结论**：凡是依赖现实世界信息、行业数据、论文、产品、政策、市场、新闻或近期事实的内容，必须先检索验证，再形成结论。
2. **多角度覆盖**：不得仅依赖单一关键词、单一来源或单一视角完成研究。
3. **证据可追溯**：关键结论必须对应具体来源；数据、年份、主体、地域、口径和适用边界必须明确。
4. **工具真实可用**：不得假设存在未配置的本地脚本、固定 API、自动化目录或预设数据文件。
5. **冲突显式处理**：来源之间存在差异或矛盾时，必须标注冲突、分析口径差异，并给出可信度判断。
6. **限制透明披露**：无法联网、无法访问来源、来源不足或证据不充分时，必须明确说明，并给出保守结论。
7. **模式选择前置**：触发本技能后，必须先引导用户选择“快速分析”或“深度分析”；若用户已明确选择，也必须在执行前显式确认采用的模式。
8. **Markdown 文件强制交付**：最终研究成果必须形成 `.md` 文件，并向用户提供下载地址、Canvas 链接或其他可直接打开的文件入口；不得只给纯聊天文本而不提供文件交付。
9. **输出面向决策**：报告不应堆砌资料，而应围绕用户问题形成判断、风险提示和可执行建议。

---

## 2. 触发条件

### 2.1 中文触发

当用户出现以下意图时启用：

- “快速分析……”“快速研究……”
- “深度分析……”“深度研究……”“全面分析……”
- “帮我研究一下……”“调研一下……”
- “市场分析”“竞品分析”“行业研究”“研究报告”
- “有哪些论文/开源项目/数据集/方案/案例”
- “比较 A 和 B”“分析某技术路线/产品/公司/行业”
- 在生成 PPT、报告、方案、文章、文档、前端页面、视频脚本前，需要真实资料支撑

### 2.2 English Triggers

Use this skill for:

- “quick analysis of …”
- “deep research on …”
- “comprehensive analysis of …”
- “market analysis / competitive analysis / industry research”
- “research report about …”
- “papers, open-source projects, datasets, cases about …”
- content generation that requires current facts, examples, data, or citations

### 2.3 不必启用的情况

- 用户只是要求改写、翻译、润色已提供文本，且不需要外部事实。
- 用户明确要求不要联网或不要检索。
- 问题属于稳定常识，且用户不要求来源、最新信息或深度分析。
- 用户只要求格式调整、语气优化、标题优化等轻量文本处理。

---

## 3. 用户交互与报告方式选择（强制）

### 3.1 强制交互原则

当用户提出“分析 / 研究 / 调研 / 市场分析 / 竞品分析 / 技术路线分析 / 行业研究 / 报告生成”等需求时，**必须先引导用户选择报告模式**。这是本技能的前置动作，不得省略。

即使用户的问题看起来可以直接回答，只要属于本技能触发范围，也应先完成以下任一动作：

1. **用户未明确模式**：先发送模式选择引导，等待用户选择。
2. **用户已明确模式**：在执行前确认“将采用快速分析 / 深度分析模式”。
3. **用户要求立即输出且不希望来回确认**：仍须在开头声明默认采用的模式，并说明可继续扩展或切换。

标准引导语：

```text
我可以按两种方式为你分析，请选择一种：

1. 快速分析：约 2000 字，适合快速了解结论、关键依据、风险和建议。
2. 深度分析：5000 字以上，适合正式报告、决策评审、市场/竞品/技术路线研究，会包含完整证据链、对比表、风险矩阵、情景推演和行动建议。

请回复“快速分析”或“深度分析”。如果你希望我直接推进，我将默认采用“快速分析”。
```

### 3.2 不得跳过模式选择的情形

以下情形仍然必须执行模式选择引导或模式确认：

- 用户只说“帮我分析一下……”“调研一下……”“研究一下……”
- 用户要求“写一份报告”，但未说明报告深度。
- 用户要求市场、竞品、行业、技术、政策、论文、开源项目等分析。
- 用户要求生成 Word、PDF、PPT、HTML、Excel 等格式，但未说明分析深度。
- 用户只提供主题、链接、文件或公司/产品名称，没有说明报告方式。

### 3.3 用户已明确深度时的处理

- 用户提到“快速”“简要”“先看结论”“大概分析”“2000 字左右”：确认并使用 **快速分析**。
- 用户提到“深度”“全面”“正式报告”“5000 字以上”“用于决策/汇报/评审”：确认并使用 **深度分析**。
- 用户要求“先给框架/大纲”：输出研究框架；若后续进入正式分析，仍需再次引导选择快速分析或深度分析。
- 用户要求 PPT、Word、PDF、Excel 等文件：先生成 Markdown 研究稿，再按用户指定格式转换或二次加工。

### 3.4 默认推进策略

如果宿主环境或业务流程要求不能停在追问，或用户明确表示“直接开始 / 不用问我 / 你决定”，则默认采用 **快速分析**，并在输出开头声明：

```text
你未指定报告深度，我将默认采用“快速分析”模式；如需正式汇报或决策评审版本，可继续扩展为 5000 字以上的“深度分析”报告。
```

默认推进不等于省略模式选择。即便默认执行，也必须明确告知用户当前采用的模式与可切换选项。

## 4. 输入理解与研究规划

开始研究前，先从用户需求中抽取并确认以下字段：

| 字段                        | 说明                                                |
| --------------------------- | --------------------------------------------------- |
| Topic / 主题                | 研究对象是什么                                      |
| Scope / 范围                | 市场、技术、论文、竞品、政策、应用、风险等          |
| Depth / 深度                | 快速分析或深度分析                                  |
| Time Range / 时间范围       | 最新、今年、近三年、历史演进等                      |
| Geography / 地域            | 全球、中国、美国、欧洲、某区域或行业                |
| Output / 输出               | 简答、表格、研究报告、PPT素材、方案、Markdown文档等 |
| Language / 语言             | 默认跟随用户语言                                    |
| Decision Context / 决策场景 | 用于投资、产品规划、技术选型、学术综述、汇报材料等  |

若用户没有明确范围，不要停留在追问；应先按最合理的通用框架执行，并在输出中说明默认范围。只有当缺失信息会导致研究方向完全错误时，才提出一个必要澄清问题。

---

## 5. 研究深度分级与输出字数

| 报告方式 | 适用场景                                   | 检索要求                                                     | 输出长度    | 输出要求                                                     |
| -------- | ------------------------------------------ | ------------------------------------------------------------ | ----------- | ------------------------------------------------------------ |
| 快速分析 | 快速了解、初步判断、会前准备               | 至少 3 个有效来源，覆盖 2-3 个关键角度                       | 约 2000 字  | 结论先行、证据摘要、核心风险、初步建议                       |
| 深度分析 | 正式报告、决策评审、市场/竞品/技术路线研究 | 至少 10 个有效来源，覆盖 5-10 个角度，尽量包含官方、行业、新闻、学术、案例等来源 | 5000 字以上 | 完整报告、方法论、证据矩阵、对比表、风险矩阵、情景推演、行动建议 |

有效来源指：内容与主题直接相关、可追溯、时效合适、来源可信度可判断。

---

## 6. 执行方式

本技能不依赖本地辅助脚本。原先由脚本完成的任务，统一由大模型按照以下方式完成：

| 任务类型   | 执行方式                                                     | 输出形态                       |
| ---------- | ------------------------------------------------------------ | ------------------------------ |
| 任务编排   | 拆解研究目标、范围、角度、优先级和默认假设                   | 研究计划、角度清单、执行顺序   |
| 查询词生成 | 生成中英文关键词、同义词、行业术语、时间限定词、地域限定词、反向检索词 | 查询词矩阵                     |
| 多源检索   | 调用当前可用的搜索、网页读取、学术、代码仓库、文件或连接器工具 | 来源清单、摘要、引用           |
| 来源评估   | 根据来源类型、主体、发布时间、原始性、方法透明度和引用关系分级 | 高/中/低可信度                 |
| 证据抽取   | 提取声明、数据、日期、口径、地域、适用范围和限制             | 证据表                         |
| 交叉验证   | 对关键事实进行双源或多源比对，识别一致、冲突和缺口           | 冲突矩阵、可信度判断           |
| 综合分析   | 基于证据进行归纳、分类、因果分析、趋势判断和场景推演         | 结构化洞察                     |
| 报告生成   | 按用户目标组织 Markdown 报告、表格、摘要和建议               | 可交付 Markdown 内容           |
| 进度同步   | 在长任务中简要告知当前进展和阶段性发现                       | 阶段性更新                     |
| 格式转换   | 用户明确要求后，再使用当前环境真实可用的文件生成能力         | Word、PDF、PPT、HTML、Excel 等 |

执行要求：

1. **规划显式化**：复杂研究开始时，先给出简短研究计划或默认研究范围。
2. **查询多样化**：每个研究角度至少生成 1-3 个查询，不只依赖用户原句。
3. **证据结构化**：重要来源必须抽取为结构化证据，而不是只保留网页摘要。
4. **分析独立完成**：不得把搜索结果简单拼接成结论，必须进行归纳、比较、冲突处理和可信度判断。
5. **引用严格对应**：每条关键结论引用的来源必须能支撑该结论。
6. **不虚构执行过程**：没有实际调用工具、读取来源或生成文件时，不得声称已经完成。
7. **局限主动说明**：数据缺口、时间限制、访问限制、来源偏差都应写入报告限制部分。

---

## 7. 研究流程

### Phase 1：广域探索 Broad Exploration

目标：快速建立全局图谱。

可用手段：

- 当前环境提供的网页搜索、网页读取、文件读取、学术检索、代码仓库检索或连接器工具。
- 如果环境提供多种搜索工具，可进行冗余检索；如果只提供单一搜索工具，则使用该工具完成多角度查询。
- 不得假设存在未配置的 `web_search`、`web_fetch`、`tavily`、`exa`、`anysearch`、`duckduckgo` 或其他外部服务。

执行动作：

1. 基于用户问题改写 2-3 个最相关的研究问题。
2. 对每个改写问题进行 2-3 次宽泛检索或资料检索。
3. 识别主要子问题、利益相关方、技术路线、市场分层、争议点。
4. 形成研究角度清单和优先级。
5. 给出默认研究范围；若默认范围可能影响结论，必须在报告中说明。

常见研究角度：

| 类型                 | 推荐角度                                                     |
| -------------------- | ------------------------------------------------------------ |
| 技术调研             | 技术原理、方法分类、关键论文、开源实现、评测指标、工程落地、瓶颈 |
| 市场分析             | 市场定义、市场规模、增长率、驱动因素、细分市场、区域格局、客户需求 |
| 竞品分析             | 产品定位、核心功能、价格/商业模式、客户群、优势劣势、近期动作 |
| 行业研究             | 产业链、政策环境、供需结构、关键玩家、投资并购、未来趋势     |
| 数据集/论文/开源项目 | 任务定义、数据规模、标注类型、许可、下载方式、代码成熟度、适配成本 |
| 方案/报告生成        | 背景、痛点、目标、路线、架构、指标、风险、里程碑、预算       |

### Phase 2：定向深挖 Targeted Deep Dive

目标：对关键角度进行精准检索。

执行动作：

1. 为每个角度生成至少 1-3 个查询。
2. 对高价值结果读取全文或关键段落，不只依赖摘要。
3. 对关键数据寻找原始来源或更高可信来源。
4. 跟踪重要来源中的引用、报告、论文、项目页、官方公告。
5. 同时检索支持性证据和反向证据，例如 limitations、challenges、criticism、failure cases。

英文查询模式：

```text
{topic} market size {current_year}
{topic} industry report {current_year}
{topic} key players competitors
{topic} latest trends {current_year}
{topic} technical survey paper
{topic} benchmark dataset github
{topic} case study deployment
{topic} limitations challenges risks
{topic} policy regulation {region} {current_year}
```

中文查询模式：

```text
{主题} 市场规模 {当前年份}
{主题} 行业分析 {当前年份}
{主题} 主要厂商 竞争格局
{主题} 技术路线 发展趋势
{主题} 论文 综述 评测
{主题} 开源项目 GitHub
{主题} 应用案例 落地
{主题} 挑战 风险 局限
{主题} 政策 监管 {地域} {当前年份}
```

### Phase 3：多源验证 Diversity & Validation

目标：减少单一来源偏差。

执行动作：

1. 快速分析至少覆盖 2-3 类来源；深度分析尽量覆盖 5 类以上来源。
2. 对来源可信度进行高/中/低分级。
3. 优先使用原始来源、官方数据、论文原文、产品文档、财报、监管文件等。
4. 对二手来源中的关键数据继续追溯到原始来源。
5. 对不一致数据并列记录，不强行合并。

来源类型：

| 来源类型 | 价值                                       | 可信度提示                           |
| -------- | ------------------------------------------ | ------------------------------------ |
| 官方来源 | 公司公告、政府数据、标准、文档             | 通常较高，但可能存在宣传倾向         |
| 学术来源 | 论文、综述、会议、arXiv                    | 方法细节较强，需注意是否经过同行评审 |
| 行业报告 | Gartner、IDC、麦肯锡、咨询机构、证券研报等 | 数据较完整，但口径可能不同           |
| 权威新闻 | 主流媒体、行业媒体                         | 时效性好，需辨别二手转述             |
| 开源社区 | GitHub、文档、issue、release               | 工程可行性强，需关注维护状态         |
| 企业案例 | 客户案例、白皮书、产品页                   | 有落地信息，但通常偏正面             |
| 社区讨论 | Reddit、论坛、博客                         | 可发现痛点，但不得单独作为强证据     |

### Phase 4：证据抽取 Evidence Extraction

目标：从原始来源中提取结构化证据。

对每个重要来源抽取以下字段：

| 字段       | 要求                                  |
| ---------- | ------------------------------------- |
| Source     | 来源名称、链接或可引用标识            |
| Date       | 发布/更新日期；无法确认则标注“未明确” |
| Claim      | 来源给出的关键结论                    |
| Data       | 数值、指标、样本量、年份、统计口径    |
| Context    | 适用场景、地域、行业、技术条件        |
| Confidence | 高/中/低                              |
| Notes      | 局限、偏差、与其他来源的冲突点        |

证据抽取规则：

1. 数据必须保留单位、年份、地域和统计口径。
2. 来源只表达趋势但没有数据时，不得虚构数值。
3. 来源为预测时，必须标注 forecast、estimate、projection 或“预测/估算”。
4. 来源没有发布日期时，标注“日期未明确”，并降低时效性置信度。
5. 对用户决策高度相关的证据，应优先读取正文或原始材料。

### Phase 5：交叉验证与冲突处理

1. **关键事实至少双源验证**：市场规模、份额、价格、性能指标、政策条款、发布日期等，不应只依赖单一来源。
2. **区分事实与判断**：事实是“发生了什么/数值是多少”；判断是“意味着什么/未来会怎样”。
3. **冲突来源并列展示**：不同报告口径不同，不得强行合并成单一确定数字。
4. **给出可信度理由**：例如官方财报 > 权威报告 > 新闻转述 > 博客猜测。
5. **时效优先但不盲从最新**：最新消息若来源弱，不能压倒较旧但权威的官方或原始来源。
6. **明确不可验证项**：无法验证的数据或说法，应标注为“来源不足”或“不确定”。

冲突处理模板：

| 争议点 | 来源 A | 来源 B | 差异原因                | 建议采信 |
| ------ | ------ | ------ | ----------------------- | -------- |
| ...    | ...    | ...    | 口径/时间/地域/定义不同 | ...      |

### Phase 6：综合分析与报告输出 Synthesis & Reporting

目标：将证据组织为可交付的研究报告。

执行动作：

1. 汇总来源与证据，先提炼 3-7 条关键结论。
2. 按用户目标组织分维度分析，而不是按搜索顺序罗列资料。
3. 生成对比表、证据表、风险表或路线图。
4. 对重要结论标注证据依据与可信度。
5. 明确写出风险、不确定性和未覆盖范围。
6. 给出可执行建议、下一步验证方向或方案路径。
7. 默认输出 Markdown；用户明确要求其他格式时，再进行格式转换或二次加工。

---

## 8. 时效性规则

研究时必须读取当前日期，并据此设计查询。

| 用户表达           | 查询时间粒度          | 示例                                                         |
| ------------------ | --------------------- | ------------------------------------------------------------ |
| 今天、今早、刚发布 | 月 + 日 + 年          | `AI news June 5 2026`                                        |
| 本周               | 周范围                | `AI chip news week of June 1 2026`                           |
| 最近、最新         | 月 + 年 / 近 30-90 天 | `VLM small object detection June 2026`                       |
| 今年、趋势         | 年份                  | `AI infrastructure trends 2026`                              |
| 历史演进           | 多年份                | `development history of ... 2020 2021 2022 2023 2024 2025 2026` |

禁止把“今天/刚发布”降级为年份级查询；这会漏掉当天信息。对于现代公司、政策、价格、法规、产品规格、模型能力、市场格局和新闻事件，应默认进行最新信息验证。

---

## 9. 输出规范与 Markdown 文件交付（强制）

### 9.1 默认输出格式

默认输出为 Markdown，文件扩展名必须使用 `.md`。除非用户明确要求其他格式，否则研究结果、分析报告、证据表、参考来源和后续建议均应先形成 Markdown 文件，便于阅读、审阅、版本管理和后续转换。

默认文件命名建议：

```text
{topic_slug}_quick_analysis_report.md
{topic_slug}_deep_analysis_report.md
```

命名规则：

1. 文件名应体现研究主题。
2. 快速分析建议使用 `quick_analysis` 或 `快速分析` 标识。
3. 深度分析建议使用 `deep_analysis` 或 `深度分析` 标识。
4. 文件名避免使用空格和特殊符号，优先使用英文、数字、下划线或短横线。
5. 若存在多个版本，应追加版本号或日期，例如 `ai_agent_market_deep_analysis_2026-06-08.md`。

### 9.2 Markdown 文件强制交付要求

完成快速分析或深度分析后，**必须交付 `.md` 文件**，并向用户提供以下至少一种访问方式：

1. **下载地址**：例如本地沙箱路径、文件下载链接或系统生成的附件链接。
2. **Canvas / 文档打开入口**：如果环境支持，应提供可直接打开的 Canvas 或文档链接。
3. **对话框直接打开文件内容**：如果无法生成可下载链接，必须在对话框中输出完整 Markdown 文件内容，并明确标注文件名，方便用户复制保存为 `.md`。

不得只输出“分析正文”而不提供文件名、文件大小、内容摘要和文件入口。

### 9.3 交付回执模板

每次完成报告后，必须使用以下格式向用户说明交付物：

```markdown
输出文件：{文件名}.md
文件大小：{文件大小}
内容摘要：{用 1-3 句话概括文档包含的主要内容，例如研究范围、核心结论、证据表、风险分析、行动建议等}

📥 分析文档下载：[{文件名}.md]({下载地址或 Canvas 链接})
```

如果无法提供下载地址或 Canvas 链接，应改用以下格式：

```markdown
输出文件：{文件名}.md
文件大小：无法生成独立下载文件
内容摘要：{用 1-3 句话概括文档内容}

下方已在对话框中直接打开 Markdown 文件内容，可复制保存为 `{文件名}.md`。
```

### 9.4 默认 Markdown 内容结构

默认 Markdown 输出应包含：

1. 标题、日期、版本与研究范围。
2. 用户选择的报告方式：快速分析或深度分析。
3. 执行摘要。
4. 分维度研究发现。
5. 证据表、数据表、对比表。
6. 风险、不确定性与限制。
7. 结论与建议。
8. 参考来源。
9. 后续可选处理。

### 9.5 快速分析输出格式（约 2000 字）

适用于快速了解、初步判断和会前准备。结构建议如下：

```markdown
# {主题}快速分析

## 报告方式

本报告采用“快速分析”模式，全文约 2000 字，侧重结论、关键依据、核心风险和初步建议。

## 一、结论先行

用 3-5 条要点回答用户最关心的问题，明确判断强弱和适用边界。

## 二、背景与问题界定

说明研究对象、默认范围、时间范围、地域范围和关键假设。

## 三、关键发现

按 2-3 个核心维度展开，每个维度包含：
- 事实或数据
- 来源依据
- 简要解释

## 四、风险与不确定性

列出 3-5 项主要风险、信息缺口或口径差异。

## 五、初步建议

给出 3-5 条可执行建议，包括下一步验证方向。

## 六、参考来源

列出支撑关键结论的来源。
```

快速分析要求：

1. 全文约 2000 字，允许根据主题复杂度上下浮动。
2. 至少引用 3 个有效来源。
3. 至少覆盖 2-3 个分析维度。
4. 不展开过长方法论，但必须说明默认范围和关键限制。
5. 结论应明确，不得以资料罗列替代判断。
6. 必须输出 `.md` 文件并提供下载地址、Canvas 链接或对话框内完整文件内容。

### 9.6 深度分析输出格式（5000 字以上）

适用于正式报告、决策评审、市场/竞品/技术路线研究。结构建议如下：

```markdown
---
title: "{研究主题}深度分析报告"
date: "{当前日期}"
version: "1.0"
analysis_mode: "deep_analysis"
---

# {研究主题}深度分析报告

## 报告方式

本报告采用“深度分析”模式，全文 5000 字以上，包含完整证据链、分维度分析、风险矩阵、情景推演和行动建议。

# 执行摘要

# 1. 研究背景与问题定义

# 2. 研究范围、方法与数据来源

# 3. 关键结论

# 4. 分维度深度分析

# 5. 数据、案例与证据矩阵

# 6. 竞争格局 / 技术路线 / 产业链 / 市场结构

# 7. 风险、限制与不确定性

# 8. 趋势判断与情景推演

# 9. 行动建议与实施路径

# 10. 参考来源

# 11. 后续可选处理
```

深度分析要求：

1. 全文 5000 字以上。
2. 至少引用 10 个有效来源。
3. 覆盖 5-10 个分析角度，尽量包含官方、行业、新闻、学术、案例、开源或监管来源。
4. 必须包含证据矩阵、风险矩阵或竞品/方案对比表。
5. 必须处理来源冲突、口径差异和不确定性。
6. 必须给出可执行建议、优先级和下一步验证路径。
7. 重要结论应说明证据强度，不得将预测、观点或营销说法写成确定事实。
8. 必须输出 `.md` 文件并提供下载地址、Canvas 链接或对话框内完整文件内容。

### 9.7 后续格式转换引导

完成 Markdown 文件交付后，应在结尾追加简短引导，询问用户是否需要继续转换或二次加工。除非用户已经明确要求，不默认直接转换。

推荐引导语：

```markdown
---

## 后续可选处理

我已默认输出 Markdown（`.md`）版本。是否需要我继续转换为以下格式之一？

- Word（`.docx`）：适合正式汇报、评审材料、可编辑文档
- PDF（`.pdf`）：适合定稿分发、归档和打印
- PPT（`.pptx`）：适合汇报展示，可进一步整理成页级结构
- HTML（`.html`）：适合网页展示、交互报告或内部知识库
- Excel（`.xlsx`）：适合将证据表、竞品表、数据表单独结构化

也可以继续让我提取：摘要版、领导汇报版、PPT大纲、图表清单、参考文献表。
```

## 10. 质量检查清单

输出前必须检查：

- [ ] 是否在正式分析前执行了模式选择引导？
- [ ] 如果用户已明确模式，是否在执行前确认采用“快速分析”或“深度分析”？
- [ ] 如果默认推进，是否明确说明默认采用“快速分析”并提示可扩展为深度分析？
- [ ] 快速分析是否约 2000 字，深度分析是否达到 5000 字以上？
- [ ] 是否至少覆盖 3 个以上研究角度，或符合快速分析的 2-3 个核心角度要求？
- [ ] 是否读取了重要来源的正文或关键段落，而不是只看搜索摘要？
- [ ] 是否平衡覆盖事实、数据、案例、观点、风险和反面证据？
- [ ] 是否标注关键数据的年份、口径、地域和来源？
- [ ] 是否处理了互相冲突的来源？
- [ ] 是否区分“已证实事实”和“分析推断”？
- [ ] 是否避免使用过期信息？
- [ ] 是否避免没有来源支撑的绝对化结论？
- [ ] 是否根据用户目标组织内容，而不是简单罗列资料？
- [ ] 是否没有依赖本地脚本、固定任务目录或不可用 API？
- [ ] 是否说明了来源不足、访问限制或口径不一致的问题？
- [ ] 是否生成了 `.md` 文件？
- [ ] 是否提供了下载地址、Canvas 链接或对话框内完整 Markdown 内容？
- [ ] 是否使用“输出文件 / 文件大小 / 内容摘要 / 分析文档下载”的交付回执格式？
- [ ] 是否在 Markdown 结尾提供了后续格式转换引导？

未满足检查项时，应继续补充检索、修正文档或完善交付信息；若无法补充，必须在输出中明确说明限制。

## 11. 常见错误与修正

| 错误                         | 问题               | 修正                                             |
| ---------------------------- | ------------------ | ------------------------------------------------ |
| 用户未指定深度就直接长篇输出 | 可能不符合用户预期 | 先引导选择；未选择时默认快速分析                 |
| 快速分析过短或过散           | 难以形成判断       | 控制在约 2000 字，保留结论、依据、风险、建议     |
| 深度分析不足 5000 字         | 不符合正式报告要求 | 扩展证据链、对比表、风险矩阵、趋势推演和行动路径 |
| 只检索 1 次就回答            | 覆盖不足           | 至少多角度、多关键词检索                         |
| 只看搜索摘要                 | 容易误读           | 打开并阅读高价值来源正文                         |
| 只找正面材料                 | 结论偏乐观         | 同时检索 challenges / limitations / criticism    |
| 不写时间口径                 | 数据不可比         | 标注年份、地域、样本、统计范围                   |
| 把预测当事实                 | 误导决策           | 明确 forecast / estimate / reported / confirmed  |
| 假设存在不可用工具           | 技能不可执行       | 只使用当前环境真实可用工具；无工具时说明限制     |
| 堆砌来源                     | 缺少分析价值       | 用证据支撑结论，形成判断                         |
| 用模型臆测替代证据           | 可能产生幻觉       | 事实结论必须检索验证；无法验证则标注不确定       |
| 忽略反例或失败案例           | 风险评估不足       | 主动检索失败案例、批评、限制和替代方案           |

---

## 12. 工具使用约束

### 12.1 外部工具约束

1. 优先使用当前环境真实提供的搜索、网页读取、文件读取、学术检索、代码仓库检索、连接器工具。
2. 不得假设存在未配置的搜索服务、私有 API key、固定数据目录或自动化脚本。
3. 如果环境提供搜索 API，可使用该 API；如果只提供浏览器搜索工具，则使用浏览器搜索工具。
4. 如果无法联网或无法访问某来源，必须说明限制，并基于已可用资料给出保守结论。
5. 对 PDF、图表、表格、图片型资料，优先使用能读取视觉内容的方式；不得只依赖 OCR 或文件名。
6. 生成文件、转换格式、读取附件时，只使用当前环境确实提供的文件处理能力。
7. 对连接器、私有文档、邮箱、日历、代码仓库等非公开资料，必须只在用户请求范围内使用，并在回答中区分公开来源与私有来源。

### 12.2 LLM 自主执行约束

1. **不依赖本地脚本**：研究规划、查询生成、证据抽取、分析、报告生成由大模型完成。
2. **不伪造自动化结果**：不得声称已经运行某个不存在的本地程序、生成某个实际不存在的文件或访问某个不可用系统。
3. **中间过程可解释**：复杂研究应说明研究范围、来源类型和关键判断逻辑。
4. **证据优先于流畅表达**：当证据不足时，宁可给出有限结论，也不要写出看似完整但无依据的判断。
5. **人工判断保留边界**：趋势预测、市场机会、技术路线建议应明确为分析推断，并说明依据。
6. **长任务阶段同步**：若任务较长，应向用户简要同步进展、已完成范围和下一步研究方向。
7. **可复查输出**：最终报告应让用户能够追踪每条关键结论来自哪些来源和证据。

---

## 13. 研究任务模板

### 13.1 市场分析模板

```text
研究角度：
1. 市场定义与边界
2. 市场规模、增长率与预测口径
3. 需求驱动因素
4. 主要玩家与份额
5. 商业模式与价格体系
6. 区域/行业细分
7. 风险、政策、供应链约束
8. 未来 1-3 年趋势与建议
```

### 13.2 竞品分析模板

```text
研究角度：
1. 竞品清单与定位
2. 核心功能与技术路线
3. 客户群与使用场景
4. 定价与商业模式
5. 优势、短板、护城河
6. 近期发布、融资、合作、并购
7. 可借鉴点与差异化机会
```

### 13.3 技术/论文/开源调研模板

```text
研究角度：
1. 问题定义与任务边界
2. 主流方法分类
3. 代表论文与核心贡献
4. 数据集、指标与评测结果
5. 开源代码、许可证、维护状态
6. 工程落地难点
7. 适合用户场景的路线建议
```

### 13.4 方案/PPT/报告前置研究模板

```text
研究角度：
1. 项目背景与行业痛点
2. 用户现状与短板
3. 技术路线与可行性
4. 竞品或替代方案对比
5. 关键指标与验收标准
6. 风险与应对措施
7. 预算、里程碑与交付物建议
```

---

## 14. 最终输出要求

无论输出长短，都应满足：

1. **必须先引导选择报告模式**：用户未指定时，必须先引导其选择“快速分析”或“深度分析”；用户已指定时，必须在执行前确认采用的模式。
2. **不得跳过模式选择**：除非用户明确要求直接推进或宿主流程要求必须立即输出，否则不得在未选择模式的情况下直接进入完整分析。
3. **结论先行**：不让用户在资料堆中寻找答案。
4. **表格承载结构化信息**：对比、证据、数据、风险和来源应优先用表格呈现。
5. **重要结论必须给出来源依据**。
6. **不确定内容必须明确标注**：“不确定 / 来源不足 / 口径不一致 / 仅为分析推断”。
7. **语言跟随用户**：中文用户默认中文，英文用户默认英文。
8. **研究报告必须输出为 Markdown 文件**：文件扩展名必须为 `.md`，便于审阅、版本管理和后续转换。
9. **必须提供文件入口**：完成后必须提供下载地址、Canvas 链接或在对话框中直接打开完整 Markdown 内容。
10. **必须提供交付回执**：包括“输出文件、文件大小、内容摘要、分析文档下载”四项；无法下载时必须说明并直接展示文件内容。
11. **快速分析约 2000 字；深度分析 5000 字以上**。
12. **Markdown 输出完成后，必须引导用户选择是否继续转换为 Word、PDF、PPT、HTML、Excel，或进一步提取摘要版、汇报版、图表清单等二次交付物**。
13. **全流程不依赖本地辅助脚本**；需要事实支撑时，使用真实可用的检索与读取工具；不能验证时明确说明限制。

推荐最终回复格式：

```markdown
输出文件：{文件名}.md
文件大小：{文件大小}
内容摘要：本文档包含{研究主题}的{报告方式}、研究范围、核心结论、证据摘要/证据矩阵、风险与不确定性、行动建议和后续可选处理。

📥 分析文档下载：[{文件名}.md]({下载地址或 Canvas 链接})
```