deep-research skill 解析¶

deep-research 是一套面向事实型与分析型研究任务的带来源支撑研究框架。它的核心设计思想是：研究任务首先要把问题范围、证据要求、检索预算、校验强度和交付结构定义清楚，再进入检索、提炼与结论生成。 因此它把范围分类、歧义消解、证据要求、研究模式、幻觉风险意识、预算控制、内容提取和执行真实性串成一条严格串行流程。

1. 定义¶

deep-research 用于技术调研、方案比较、事实核验、趋势分析、代码库研究和混合型研究任务。它输出的不只是“研究结论”，还包括：

• 问题归一化后的研究范围
• 证据链要求与置信度约束
• 实际执行的方法、检索与提取过程
• 共识与争议的拆分
• 来源质量说明与研究缺口

从设计上看，它更接近“带门禁的研究执行框架”，而不是一个自由发挥的网页搜索提示词。

2. 背景与问题¶

这个 skill 要解决的核心问题，是研究任务在没有明确约束时，很容易同时出现“结论来得太快、证据层级太弱、引用不可核查、结构不稳定”四类问题。

在没有框架约束时，常见失真通常集中在 8 类：

deep-research 的设计逻辑，就是把“研究行为”从临场发挥，收束成一套可验证、可审计、可复用的流程。

3. 与常见替代方案的对比¶

先看它与几种常见做法的区别：

它的价值不在于替代模型的分析能力，而在于给研究过程加上边界、证据纪律和交付纪律。

4. 核心设计逻辑¶

4.1 先做 范围分类 和 歧义消解¶

deep-research 把 范围分类 Gate 和 歧义消解 Gate 放在最前面，要求先确认研究类别、研究目标、比较维度和深度要求，再开始任何检索。

这样设计的原因很直接：很多研究失败，不是因为资料查得不够多，而是因为一开始研究对象就没有定义清楚。比如：

• “research microservices” 这种请求过宽，必须先收束成具体问题
• 趋势分析如果不限定时间范围，很容易混入过期资料
• 技术比较如果不先说明要比性能、成本、生态还是运维复杂度，最后结论会失焦

把这两道 Gate 前置，本质上是在先回答“要研究什么”，而不是一上来就搜索。

4.2 证据链要求必须先于检索¶

第三道强制门禁是证据要求。它要求在开始检索之前，先定义不同类型结论最低需要什么证据链。

这层设计非常关键，因为“研究结论”本身不是同一种东西：

• 单一事实主张，适合用官方或一手来源核验
• 最佳实践建议，需要官方依据加实践者经验
• 技术对比，需要多份独立 benchmark 或评测
• 趋势判断，需要跨时间的多源数据
• 快速变化或存在争议的话题，需要多层来源并显式处理冲突

如果不先规定证据门槛，模型很容易在“刚找到一点像答案的东西”时提前收尾。deep-research 要做的是先定义“什么叫够了”，再决定何时形成结论。

4.3 研究模式 和 预算控制 必须成对出现¶

deep-research 不只划分 Quick / Standard / Deep 三种模式，还为每一种模式设置了 retrieval 和 content extraction 的上限。

这是一个很成熟的设计，因为研究任务存在两个常见偏差：

• 查得太少，证据不足却结论完整
• 查得太多，检索轮次膨胀但新增信息很有限

模式解决“要查多深”，预算解决“最多查到哪里停”。两者合在一起，才能让研究既不过浅，也不过度失控。

这种设计还带来一个重要好处：用户能预期交付成本。对于 quick check，用户要的是快速核验；对于 deep dive，用户才愿意为更高的证据完整度付出更多检索成本。

4.4 幻觉风险意识 会被提升为独立门禁¶

deep-research 把幻觉风险意识单独设为强制门禁，并配有专门的 hallucination-and-verification.md 参考资料。

这说明它对研究任务的理解非常清楚：研究输出最危险的部分，不是“观点不够深”，而是看起来很像真的，但实际上无法验证。在研究场景里，这类问题尤其常见：

• 编造 URL、论文标题或作者名
• 把过期信息当成当前事实
• 用绝对化表达包装不确定结论
• 把相近产品、版本或概念混为一谈
• 只选支持自己结论的证据，忽略反例

把这层做成独立门禁，而不是几条零散提醒，意味着 skill 把“反幻觉”视为研究正确性的基础设施。

4.5 强制要求先提取正文内容 vs 只看搜索摘要¶

内容提取 Gate 是 deep-research 最关键的设计之一。它明确规定：必须先读取真实来源内容，不能只依据搜索摘要、标题或二手转述形成关键结论。

这层设计解决的是研究流程里最常见、也最隐蔽的错误：

• 搜索摘要只保留结论，不保留上下文
• 页面标题容易带营销语气，不能代表正文证据强度
• 二手文章会丢失 benchmark 方法学、版本范围或实验条件

因此，skill 要求先通过 fetch-content 提取页面正文，再进行 synthesis。它甚至明确规定：关键来源提取失败时，应该把问题记入 gaps，而不是假装证据已经成立。

这让 deep-research 和“会搜索”的普通工作流形成了本质区别。它要求的不是“看到来源”，而是“真的读过来源”。

4.6 执行真实性 要单独强调¶

执行真实性门禁 要求研究报告必须如实说明：

• 检索是否真的执行了
• 内容是否真的提取了
• 实际提取、引用了多少来源
• 哪些结论来自正文，哪些只是 snippet 线索

这层设计的重要性在于，研究任务特别容易出现“表面上像是做过了”的假象。没有执行完整性约束，模型很容易写出一份看起来很完整的报告，但里面混杂了假定、想象和未执行步骤。

执行真实性 的作用，就是把“研究报告”从纯文本产物，变成一个带执行证据的交付物。

4.7 Honest Degradation 比“硬凑完整答案”更重要¶

deep-research 支持 Full / Partial / Blocked 三种降级结果，并且要求显式说明 gap、原因和下一步建议。

这个设计非常有工程价值，因为研究任务经常会遇到这些情况：

• 关键资料被 paywall 挡住
• 某些领域内容没有被公开搜索引擎很好索引
• 时间窗口太新，资料还不充分
• 预算已经到顶，但证据链仍未满足

如果没有降级设计，模型通常会走向两个坏方向：

• 明明证据不足，却把语气写得非常确定
• 一旦遇到障碍就停止，没有可继续推进的结果

deep-research 选择了第三条路：在证据不足时，诚实地报告当前能确认到什么、还缺什么、下一步该如何补证据。

4.8 拆分共识、争议、来源质量与缺口的输出合同¶

当前 skill 在 Standard 和 Deep 模式下要求 9 个部分；Quick 模式可以省略第 5、6 部分。在完整报告结构里，最有设计价值的几块是：

• Consensus vs Debate
• Source Quality Notes
• Gaps & Limitations

这些部分的意义，不只是让报告看起来更完整，而是让读者在很短时间内回答四个关键问题：

• 哪些结论已经比较稳
• 哪些地方来源之间仍有分歧
• 当前证据到底强不强
• 哪些空白会影响决策

这也是 deep-research 和普通“资料汇总”之间的关键区别。前者在交付一个研究判断框架，后者往往只是在堆材料。

4.9 同时覆盖 web research、codebase research 和 hybrid research¶

deep-research 在 范围分类 阶段就把任务划分为 comparative、trend、claim verification、technical deep-dive、codebase research 和 hybrid research。

这说明它从一开始就没有把研究理解成“只上网搜资料”。在工程实践里，很多真正有价值的研究任务都是混合型的：

• 先从代码库里找出现状
• 再用外部资料校验最佳实践或替代方案
• 最后把内部约束和外部证据拼起来形成建议

把 codebase research 和 hybrid research 纳入同一框架，能让 skill 直接覆盖更接近真实研发决策的场景，而不只适合做公开信息收集。

4.10 references 采用“基础必载 + 细则按需”的加载方式¶

当前版本的 deep-research 已经不是一个单文件 skill。它把输出合同作为固定前置加载内容，把高风险校验协议和 programmer-specific research patterns 作为按需加载的 references。

这种设计比“把所有规则都塞进 SKILL.md”更合理，原因有三点：

• 低频但高重要性的规则，可以在需要时展开，不污染默认上下文
• 不同研究任务关注点不同，没必要每次都加载全部细则
• 引用协议、反幻觉协议、编程研究模式本来就适合独立维护

这是一种典型的生产级 skill 设计：基础流程和输出合同常驻，重型细则按需加载。

4.11 把研究流程做成脚本化子命令 vs 只写自然语言步骤¶

deep-research 不只是文档规则，还显式绑定了 retrieve、fetch-content、search-codebase、validate、report 这些子命令。

这层设计的价值在于，它把“研究方法”从抽象建议落到可执行步骤：

• 检索与提取可以复现
• 验证步骤可以独立运行
• 报告生成有明确输入输出
• 后续可以更容易做自动化测试和回归验证

这也是它比普通提示词更强的一点：不仅规定“应该怎么想”，还规定“应该怎么执行”。

5. 这个设计解决了哪些具体问题¶

结合当前 SKILL.md 和配套 references，可以把它解决的问题归纳为：

6. 主要亮点¶

6.1 把“研究”变成了带门禁的执行流程¶

很多 research workflow 的问题，在于只有“查资料”这一步。deep-research 的亮点，是把前置判断、证据门槛、提取要求、验证协议和交付格式全部显式化。

6.2 对反幻觉的处理非常系统¶

它没有停留在“注意别幻觉”这种口号层面，而是把 hallucination type、verification priority、source tier、query pattern 和 insufficient evidence protocol 组织成了一套完整机制。

6.3 对“证据是否真的读过”要求很严格¶

强制 content extraction 是这个 skill 最重要的质量控制点之一。它直接抬高了研究结论的可靠性下限。

6.4 结构化交付非常适合沉淀为长期资产¶

在 Standard 和 Deep 模式下，Research Question、Method、Executive Summary、Key Findings、Detailed Analysis、Consensus vs Debate、Source Quality Notes、Sources、Gaps & Limitations 这套结构天然适合复盘、复用和更新；Quick 模式则允许为速度省略其中的部分展开区段。

6.5 很适合做混合型研发研究¶

很多技能只擅长 web search 或 code search 其中之一。deep-research 的优势在于两边都覆盖，并且把它们纳入同一套证据和交付框架。

6.6 当前版本比评估快照更强调执行完整性¶

现有评估报告最强地证明了它在结构纪律上的价值，例如模板一致性、编号引用和来源可信度标注。与此同时，当前 SKILL.md 已经扩展为 8 个 强制门禁、9-section 输出契约 和多份 references。也就是说，评估报告验证了它的核心方向，而当前 skill 在此基础上进一步强化了执行门禁和反幻觉约束。

7. 什么时候适合用，什么时候不该硬用¶

8. 结论¶

deep-research 的真正亮点，在于它把研究任务里最容易失真的部分系统化了：先明确问题边界，再定义证据门槛，随后约束检索深度与预算，强制读取正文内容，用反幻觉协议校验高风险结论，最后用固定合同交付共识、争议、来源质量和研究缺口。

从设计上看，这个 skill 体现了一个非常清晰的原则：研究质量首先取决于证据纪律和交付纪律，其次才是表达能力。 这也是它特别适合做工程决策、技术比较和事实核验类任务的原因。

9. 文档维护¶

当以下内容发生变化时，这份文档应该同步更新：

• skills/deep-research/SKILL.md 中的 强制门禁、研究模式、预算、安全规则 或 输出契约 发生变化。
• skills/deep-research/references/output-contract-template.md、hallucination-and-verification.md、research-patterns.md 中的关键协议发生变化。
• skills/deep-research/scripts/deep_research.py 的子命令、执行方式或输出字段发生变化。
• evaluate/deep-research-skill-eval-report.zh-CN.md 中支撑本文判断的关键结论发生变化。
• skill 的结构再次演进，导致评估快照与当前实现差异继续扩大。

建议按季度复查一次；如果 deep-research 的 gate、reference 或脚本结构有明显重构，则应立即复查。

10. 相关阅读¶

• skills/deep-research/SKILL.md
• skills/deep-research/references/output-contract-template.md
• skills/deep-research/references/hallucination-and-verification.md
• skills/deep-research/references/research-patterns.md
• skills/deep-research/scripts/deep_research.py
• evaluate/deep-research-skill-eval-report.zh-CN.md