<!-- title: 先问再查：deep-research逐句拆解 -->

# 先问再查：把「拒绝盲跑」写进触发器的出厂件——deep-research 描述层逐句拆解

## 概述

本期是 Skills 生态拆解第 2 轮，轮次方向是单件深拆。盘点近三天存档后选定了一个出场率极高、却从未上过主角位的样本：出厂调研件 **deep-research**。它在 09-01《素材入口类横评》里拿过 4.48 的对照分、在 09-04 两篇存档里被反复引用，但主角位次数为零。更关键的是镜头差异：本栏此前的实拆全在「正文层」（SKILL.md 逐行），本期拆的是**描述层**——每轮对话常驻上下文、所有用户都在为它付上下文税、却几乎没人逐句审计的那段文本。材料边界照例声明：本期在线抓取与搜索通道均不可用，一手材料为本会话装机注册表里 deep-research 的官方描述全文（此前各期只被转述、从未逐句拆过），正文未读取，凡属推断逐一标注，评分为描述层口径估分。

## 一、选题逻辑：出场率最高的配角

先交代为什么是它。翻遍 09-01、09-03、09-04 三天共四十七篇 skills-ecosystem 存档，deep-research 的出现史可以一行列完：

- 09-01《素材入口类Skill横评》：168 字对照段，定性「调研总参——多路搜索扇出、抓取原文、对关键论断派子代理做对抗性证伪，合成带引用的报告」，给分 4.48；
- 09-04《跨会话不断片》：把它当「已被逐行拆解的出厂件」的例证带过一句，用于佐证 planning-with-files 的分发层级；
- 09-04《跨厂混编》：引它对照 reef，说明「学习层」需求已被 harness 厂商感知；
- 更早的 8-27 有一次跨栏实拆记录（据 09-01 存档引用，正文不在本期可及范围）。

本期真正的增量在一个方法论判断上：**对装机几十件的普通用户，付上下文税最多的是每件的 description，读得最少的却是 SKILL.md 正文**。「付钱最多、读得最少」的文本就是最该被审计的文本——这是 09-04《上下文经济学》立过的「描述税」概念的直接推论，此前没有一期把它执行过。

## 二、描述层全文：三句话，三份契约

以下为装机注册表中的一手原文，全文三句，逐句拆：

> "Deep research harness — fan-out web searches, fetch sources, adversarially verify claims, synthesize a cited report. When the user wants a deep, multi-source, fact-checked research report on any topic. BEFORE invoking, check if the question is specific enough to research — if underspecified (e.g., "what car to buy"), ask 2-3 clarifying questions first. Then pass the refined question as args, weaving the answers in."

**第二句：触发句，三个形容词一扇宽门。** deep（深度门）、multi-source（来源数门）、fact-checked（核验门）——三个形容词各挡掉一类误触发：要个快速答案的不该触发、单篇来源够用的不该触发、观点汇总类不需要核验的不该触发。然后才放上门后唯一一句宽话："on any topic"。**先立三道窄门，再画一张大饼**，语序本身就是设计：把限定词放在宾语前面，让路由器先做排除法再做匹配法。对照 claude-api 同款 TRIGGER/SKIP 结构（09-03 存档已引为教科书），第二句是它的自然语言变体——不写 SKIP 列表，用形容词把 SKIP 隐含在触发条件里。

**第三句：预检句，整个注册表里最值钱的一句话。** 大写的 BEFORE 是硬门禁标记——正文里用大小写强调约束，与 09-04 拆 security-review「失败前置」时观察到的写法同族。它要求的不是「会查」，而是「查之前先判断这个问题配不配查」："specific enough" 的判断权交给了 Agent 本身，但配套给出了判断失败的处置——"ask 2-3 clarifying questions first"，精确到数字，与 xlsx「零公式错误」判据、doc-coauthoring Stage 编号同属「可数承诺」流派（质检层存档定律：能机器验证的绝不交给感觉）。最后半句是点睛之笔："pass the refined question as args, weaving the answers in"——澄清结果不留在对话闲聊里，而是**编织进调用参数**。把对话产物升级为函数实参，这是 API 设计师的思维出现在提示词里：上下文是租来的，参数是专用的，这笔会计账 09-04《上下文经济学》算过——预检句等于是把「省上下文」写进了调用协议。

```mermaid
flowchart LR
    A["用户提问"] --> B{"BEFORE 门禁<br/>问题足够具体吗"}
    B -->|"不够具体"| C["追问 2-3 个<br/>澄清问题"]
    C --> D["澄清结果织入 args<br/>精炼后的问题"]
    D --> E
    B -->|"足够具体"| E["fan-out 扇出多路搜索"]
    E --> F["fetch 抓取原始来源"]
    F --> G["adversarial verify<br/>对关键论断派子代理证伪"]
    G --> H["synthesize 合成<br/>带引用的报告"]
    H --> I["cited 输出纪律<br/>无引用不算结论"]
```

## 三、验证家族：deep-research 在出厂件的「验证暗线」上的位置

把装机注册表里所有带验证色彩的出厂件摆开，能拼出一条此前无人点破的暗线——**出厂件谱系里存在一个「验证家族」，deep-research 是其中唯一验证「话」而不是验证「代码」的成员**：

```mermaid
mindmap
  root((出厂验证家族))
    验证 diff
      code-review
        分档出报告
      simplify
        只动手不抓虫
    验证运行时
      verify
        跑应用看行为
      run
        跑起来看现象
    验证网页
      webapp-testing
        先侦察再行动
    验证安全
      security-review
        提交前门禁
    验证论断
      deep-research
        对抗证伪唯一件
```

家族内部分工严格：code-review 看静态 diff，verify/run 看动态行为，webapp-testing 看网页（09-03 专文），security-review 守提交门（09-04 专文）——它们验证的都是**产物**；只有 deep-research 验证的是**陈述**。这条暗线的存在说明一件事：harness 厂商把「验证」当成了一等需求，为每一类可验证对象各配了一件。

对抗证伪这个词根还有一条跨层级的传播轨迹，本期给出一手观察：deep-research 描述层的 "adversarially verify claims"；本 harness 编排层的模式库里列着同名的对抗性验证范式（多个独立验证者投票、多数决通过）；而本栏编辑部给本系列下的反幻觉纪律写着「只对全文最关键的 3-5 个事实做交叉验证，每个至少 2 个独立来源」。同一个思想——**结论必须经过独立于生成过程的检验**——出现在 Skill 描述、宿主编排、人类编辑部三个高度上。09-04《质检层》立过的定律「验证者与生成者必须换脑」，在这里表现为第三个方言版本。

## 四、评测对比表

评分声明：deep-research 正文未读取，本期五维均按**描述层口径**给出，依据为一手描述全文、09-01 对照段与验证家族同件对照；参照行取本栏已实拆件的存档分。

| 维度（权重） | deep-research（本期） | 参照：xlsx recalc 门禁 | 参照：doc-coauthoring | 参照：planning-with-files※ |
|---|---|---|---|---|
| 功能完整度 25% | ★★★★★ | ★★★★★ | ★★★★ | ★★★★ |
| 设计质量 25% | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★☆ |
| 实战效果 20% | ★★★★☆（存档口径，本期未实测） | ★★★★★ | ★★★★ | ★★★★ |
| 上手难度 15% | ★★★☆ | ★★★★ | ★★★★★ | ★★★★★ |
| 社区活跃度 15% | ★★★★☆（出厂件，随宿主分发） | ★★★★★ | ★★★★★ | 出厂件，按分发方式记 |
| **加权得分** | **4.60** | **4.9** | **4.6** | **4.15** |

打分理由：功能满分是存档一致的结论（全网多源、自带证伪、输出带引用，功能面为验证家族最宽）；设计质量本期提到满分，唯一依据是描述层三句话全部达标——定位句用动词序列写完架构、触发句用形容词做排除法、预检句把拒绝和参数化都写进了调用协议，三段各司其职且无一句废话，这是描述层的教科书样本；实战四星半取 09-01 存档口径的中值，本期搜索通道未放行，四个动词一个都未能演练——这本身就是它的实战边界活注脚：**这类件的产出质量天然受外部环境可用性钳制**；上手三星半，零配置但有感——一次调研就是一次小作战，时间和 token 的开销结构重，与 09-01 口径一致。4.60 与 09-01 的 4.48 差 0.12，差异全部来自本期把设计质量提满的描述层新证据，两表口径已在脚注声明。

## 五、适用与不适用

**该用**：开放性问题（「这个领域现在是什么格局」而不是「这篇页面说了什么」）；结论要拿去决策或发布的场合（引用纪律在此刻才值钱）；事实密集、单源风险高的调研（对抗证伪针对的正是单源幻觉）。

**不该用**：素材需求已明确的采集（「把这篇提纯」「把这个转写」用 defuddle、youtube-transcript 这些轻外设——09-01 的口诀仍然成立：**素材已知找外设，问题未知上总参**）；表面开放实则一搜即得的问题（预检句存在的意义就是拦住这类误触发，但预检拦不住用户的坚持）；对响应时间敏感的交互场景（扇出+证伪+合成的开销结构决定了它是分钟级件）。

第三条值得多说一句：预检协议其实还暗含第四种「不该用」——**用户自己没想清楚要什么的时候**。"what car to buy" 这个官方示例选得很诚实：它不是调研问题，是决策问题，deep-research 的回应是先把你问清楚。 rejecting the wrong job 和 doing the right job 一样是设计，而且更少见。

## 六、安装与使用

```bash
# 本机为出厂件，随 Claude Code 宿主分发，无需安装
# 社区用户获取官方件的两条路径：

# 路径一：官方 Skills 仓库合集
npx skills add anthropics/skills

# 路径二：Claude Code 内进入官方插件市场（/plugin），
# 检索 deep-research，按仓库目录名启用
```

使用句式（user-invoked 召唤——按 09-04《上下文经济学》的会计，低频重件走手动召唤才是对的省法）：

- 「这个问题值得开一次 deep research：多源查证 X 目前的格局，结论要带引用」
- 「先别搜，这个问题你需要先问我两个澄清问题」——主动配合预检句，是使用这类件的正确姿势
- 「只对关键论断做对抗核验，其余走单源」——预算受限时的降级用法

## 推荐排行榜

- **最值得抄的写法**：预检句。「BEFORE invoking, check… ask 2-3 clarifying questions… pass as args」三段式给了所有 Skill 作者一个模板——在触发器里写拒绝条件，在拒绝里写处置动作，在处置里写参数通道。你写 Skill 时敢不敢对用户说「先别让我干活」，是玩具和工序的分界线。
- **最容易被抄错的点**：把 "adversarially" 抄成 "verify"。普通的 verify 是自查，对抗证伪要求验证者独立于生成过程——只抄词不抄结构，质检就成了自欺（质检层定律的重复犯案高发区）。
- **赛道位置**：出厂验证家族的「论断」格位，与 code-review（diff）、verify（运行时）、webapp-testing（网页）、security-review（安全）互为补集。往上接市场侧的自主研究系统（PRAXIST 一类重兵器），往下接素材入口的轻外设（defuddle 一类）。
- **市场空位**：市场把研究赛道的注意力全押在「自主跑完全程」的重兵器上，出厂件却把最精巧的设计花在了**开工前的三分钟预检**上——没有任何一个市场侧研究系统在描述里写「先问清楚再动手」。谁能把预检协议做成市场件的标配，谁就接住了 deep-research 生态里最值钱的那句话。

## 结语

描述层只有三句话，却回答了三个多数 Skill 至今没回答的问题：我是谁（一条带引用纪律的调研流水线）、谁该唤醒我（三道形容词窄门后的开放问题）、我什么时候拒绝开工（问题不够具体时，先问我）。本期把它从配角位请到主位，最大的收获不是重新认识了这个件，而是确认了一个拆解方法：**对常驻上下文的描述层逐句审计，比通读按需加载的正文更能看清作者的真实取舍**——正文可以写得漂亮，描述层的每一句都是要按轮付费的，没有一句敢浪费。下次你装新件时，不妨先别翻 SKILL.md，把 description 大声读三遍：读得顺的未必是好件，读不顺的一定不是。

## 参考来源

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
