| name | deep-research-verifier |
| description | 深度研究与验证技能：当用户提出需要多源信息搜集、逻辑推理和事实验证的复杂问题时使用。
适用场景包括但不限于：投资研究、行业分析、技术对比、政策解读、商业决策支持等需要
"先想清楚怎么查，再去查，查完还要验证"的场景。
触发关键词/短语：为什么A而不是B、分析一下、帮我研究、设计一个SOP流程来回答、
深度分析、请验证、fact check、多角度分析、请先理解问题再回答、不要立即回答。
当用户明确要求"先设计研究流程再回答"或"验证你的结论"时，务必使用此技能。
当用户的问题涉及多个实体的比较（公司、技术、政策等）且答案不是简单事实时，也应触发。
|
Deep Research & Verification Skill
一个结构化的"研究-回答-验证"框架，用于回答需要多源信息支撑的复杂问题。
核心理念
大多数复杂问题的回答失败不是因为搜索不到信息，而是因为：
- 没想清楚需要什么信息就开始搜（研究设计缺失）
- 搜到了就直接用，没验证来源可靠性和逻辑自洽性（验证缺失）
- 把相关性当因果性，把单一来源当普遍事实（推理缺陷）
这个技能通过四个阶段来系统性地避免这些问题。
Phase 1: 问题解构与SOP设计
在做任何搜索之前，先停下来理解问题。
1.1 问题解构
将用户的问题拆解为：
- 核心问题：用一句话描述用户真正想知道什么
- 隐含假设：问题中暗含了什么前提？这些前提本身是否需要验证？
- 关键实体：涉及哪些公司/技术/概念？
- 时间维度：问的是当前状态、历史演变还是未来趋势？
1.2 设计研究维度
基于问题解构，列出需要搜集信息的维度。每个维度都应该回答一个子问题，子问题的组合能完整回答核心问题。
格式：
维度1: [子问题描述]
- 需要什么类型的信息（事实/数据/观点/对比）
- 可能的信息来源（公司公告/分析师报告/行业报告/新闻）
- 搜索关键词建议（2-3组）
维度2: ...
一般控制在 3-6 个维度。太少说明问题拆解不够，太多说明粒度过细需要合并。
1.3 输出SOP计划
将研究计划以清晰的步骤呈现给用户，说明：
- 计划搜集哪些方面的信息
- 为什么选择这些维度（与核心问题的关联）
- 预期的搜索顺序和逻辑（先搜什么、后搜什么、为什么）
如果用户说"不用展示SOP直接回答"，可以跳过展示，但内部仍应遵循这个思考过程。
Phase 2: 信息搜集与初步整合
2.1 按维度搜集
按照Phase 1设计的维度，逐一执行搜索。注意：
- 每个维度至少搜索2次，用不同关键词，避免单一搜索遗漏
- 优先原始来源：公司官方公告 > 监管文件(SEC Filing等) > 权威媒体 > 分析师 > 二手报道
- 记录来源层级：每条信息标注来自哪里，是一手还是二手
- 量化优先：能找到具体数字的不要只记结论性描述
2.2 初步整合
搜集完成后，按问题结构组织信息，形成初步回答框架。此时的回答是"草稿"，还需经过Phase 3验证。
格式参考：
论点1: [陈述]
支撑证据:
- 证据A (来源: xxx, 类型: 一手/二手)
- 证据B (来源: xxx, 类型: 一手/二手)
证据强度: 强/中/弱
论点2: ...
Phase 3: 验证与交叉检验（关键阶段）
这是与普通搜索回答最大的区别。对Phase 2的每个论点和关键证据进行系统性验证。
3.1 事实验证
对每条关键事实性声明进行检查：
- 数字验证：金额、日期、百分比等是否能在第二个独立来源中得到印证？
- 时效验证：信息是否过时？是否有更新版本？
- 来源交叉：同一事件是否有多个来源报道？报道内容是否一致？
- 原始来源追溯：二手信息是否正确引用了原始来源？
对于无法交叉验证的事实，明确标注"单一来源，未经交叉验证"。
3.2 逻辑验证
对每个推理链条进行检查：
- 因果 vs 相关：A和B同时发生，是否真的是因为A导致B？有没有其他解释？
- 充分性：证据是否足够支撑结论？有没有跳跃？
- 必要性：这个论点是否是回答核心问题必需的？
- 反面论证：是否存在反对观点？反对观点的证据有多强？
- 幸存者偏差：是否只看到了成功案例而忽略了失败案例？
3.3 补充搜索
基于验证阶段发现的漏洞，进行针对性补充搜索：
- 存疑的数字需要找第二来源确认
- 逻辑链条中的薄弱环节需要额外证据
- 反面观点需要搜索来评估其合理性
3.4 验证记录
为每个论点生成验证状态：
论点: [陈述]
验证状态: ✅ 已验证 / ⚠️ 部分验证 / ❌ 未通过验证 / ℹ️ 无法验证
验证详情:
- 事实层面: [验证结果]
- 逻辑层面: [验证结果]
- 如有修正: [原始 → 修正后]
Phase 4: 最终输出
4.1 正式回答
基于验证后的信息，组织最终回答。结构建议：
- 一句话核心结论（让读者先知道答案）
- 分层论述（按逻辑递进，而非按搜索顺序）
- 关键数据支撑（验证过的数字和事实）
- 局限性说明（哪些方面信息不足或存在争议）
4.2 证据追踪表（附在末尾）
这是透明度的关键。列出研究过程中：
采纳的证据：
| 论点 | 关键证据 | 来源 | 验证状态 | 采纳理由 |
|---|
| ... | ... | ... | ✅/⚠️ | ... |
放弃的证据/论点：
| 原始论点/证据 | 来源 | 放弃原因 |
|---|
| ... | ... | 与更可靠来源矛盾 / 逻辑不成立 / 时效过期 / ... |
未能验证的部分：
| 声明 | 原因 | 影响评估 |
|---|
| ... | 仅单一来源 / 缺乏数据 | 对结论影响大/小 |
实用指南
什么时候可以简化流程
- 如果问题比较简单（只需1-2次搜索就能回答），不需要走完整流程
- 如果用户明确说"快速回答就好"，可以简化但仍保持验证意识
- Phase 1的SOP设计可以在内部完成，不一定要展示给用户
什么时候必须走完整流程
- 用户明确要求设计SOP或验证
- 涉及投资决策相关的事实性问题
- 涉及多方对比且答案会影响用户判断的
- 用户对之前的回答质量不满意，要求更严谨
搜索策略提示
- 英文关键词通常能找到更多一手来源（SEC文件、公司公告）
- 中文关键词适合找分析解读和讨论
- 对于最新事件，按时间排序搜索
- 对于有争议的话题，主动搜索反面观点
常见验证陷阱
- 回声室效应：多个来源说同一件事，但都引用了同一个原始来源，本质上只是一个来源
- 标题党失真：文章标题的结论与正文细节不符
- 选择性引用：原文中有限定条件，但被引用时去掉了
- 过时信息：某个数字在6个月前是对的，但已经更新了
语言与风格
- 回答使用用户提问的语言
- 验证过程中的内部记录可以混合中英文
- 最终呈现时保持一致的语言风格
- 如果是中文回答，专业术语可以保留英文原文（如 neocloud、GPU-as-a-Service）
