hl-research 拆解：一个“先问对问题“的调研工具，和它七版迭代里的取舍

这是上一篇《一个关于"不知道自己不知道什么"的问题》的续篇。上一篇讲的是这个调研工具为什么会存在：我在陌生领域选型时，常常连"有哪些维度要考虑"都不知道，传统调研工具默认我们已经了解真实的需求。

hl-research 几乎每一个机制，都不是我设计出来的，是被一次具体的失败逼出来的。所以接下来每个机制，我都会走同一条线：它最早是怎么做的 → 哪次真实运行出现什么问题 → 改了什么 → 当时还考虑过什么、为什么没选。 最后那一步往往不是"别的方案差"，而是"对我这个场景不合适"。

先给张地图

hl-research 是一个 Claude Code 的 Skill，用 /hl-research 触发。它把一次调研拆成两段：

flowchart TB Start["/hl-research 话题"] Start --> P0 P0 --> P1 subgraph SG0["Phase 0 --- 盲探与澄清"] P0["分类研究类型"] A["盲搜：摸清技术全景 + 搜反例"] B["分离硬约束 / 软假设"] C["把未知翻译成需求导向问题"] D["用户回答 → 确认调研计划"] P0 --> A --> B --> C --> D end subgraph SG1["Phase 1 --- 定向深研"] P1["按确认的计划并行深研"] E["每维度给默认推荐 + 来源质量标签"] F["对抗搜索：主动证伪每个推荐"] G["跨维度校验 + 写报告前自审"] H["按研究类型加载模板，输出报告"] P1 --> E --> F --> G --> H end

Phase 0 不做方案调研，它只负责一件事：帮我发现我不知道的维度，然后把这些维度翻译成我不需要懂这个领域也能回答的问题。Phase 1 才是真正的深研，这部分和市面上的调研工具差不多。

第一步：需求导向的提问，和那道确认门

最朴素的做法，是直接把技术选项摆给用户问："你想用 Mermaid 还是 HTML？"

这个问法有个致命的内在矛盾：用户来做调研，就是因为他不懂这个领域。如果一个问题需要领域知识才能回答，那这个问题本身就是错的。AI 不会提问，用户也答不上来，两边卡死。

所以 Phase 0 有一条硬规则：所有问题必须是需求导向的，不能是技术导向的。

错的问法：「应该用 Mermaid 还是 HTML？」
对的问法：「你希望图表最终在哪里看------浏览器？终端？还是提交到 Git 的文件？」

区别在于，第二个问题问的是结果和意图 ，不是技术。只有用户知道自己要什么，但他不该为了回答而先去学 Mermaid。后来我还给这一步加了个上限：Phase 0 最多问 3 个问题。多出来的未知，我要自己靠盲搜解决，不能一股脑甩给用户。Asking Clarifying Questions for Preference Elicitation With Large Language Models 发现，澄清问题一旦超过 4 个，回答质量会明显下降。

另一个零件是 Phase 0 结束后的那道确认门：进入深研之前，先把"我打算研究哪些维度"列出来，等用户点头再开跑。

我曾经怀疑这道门是不是纯属摩擦。第一次实战画图方案时，我看完计划只回了一个"go"，什么都没改。看起来确认门白设了。但我后来想明白，这个停顿必须有：它给了我读完计划、对照自己理解、决定要不要追问的机会。调研一旦跑偏，花掉的时间是回不来的。门之前改方向什么都不损失，过了门再改，前面全白干。

这里我没有选的一个方案是给确认门加个自动倒计时（几秒没响应就默认开跑）。听着省事，但它消灭的恰恰是这道门唯一的价值：让人有时间想。

第二步：把"约束"和"假设"拆开

这是整个工具里我最在意的一个机制，因为它直接对应上一篇里那个让我难堪的故事。

回顾一下：我当时想让 AI 理解意图后直接发 HTTP 请求，自以为方向是"用大模型的结构化输出拼接 HTTP 调用"。调研工具也老老实实顺着这个方向，给我产出了一份"怎么拼 HTTP"的方案。实现完我才发现，这个问题早被 Function Calling 和 MCP 解决了。我造了个轮子，一个很差的轮子。

最朴素的规则 ，是"把用户提供的一切都当成硬约束"。当时我觉得这样最稳妥，因为尊重用户的输入。但这条规则打崩在上面这个故事里：当用户的"约束"其实是一个伪装成需求的、错误的解决方案时，"全部当约束"就等于主动放弃了纠正错误前提的能力。工具只是在为一个错误的问题寻找完美答案。

改了什么：Phase 0 现在会把用户的输入拆成两类。

硬约束：改不了的东西------已有系统、团队规模、预算、时间。
软假设：用户相信是真的、但调研可能推翻的东西------他选的方案、选的工具、设想的实现路径。

更关键的是，盲探阶段多了一个专门搜反例的动作：对用户陈述的每一个具体方案，主动去搜证明它是错的证据。如果搜到了，就在 Phase 0 输出里明确标成"被挑战的假设"，绝不和稀泥。

这条改动背后有个数据我印象很深。Allen AI 把"错误前提的请求"列为 AI 必须纠正的一类失效模式；而 Cancer-Myth: Evaluating Large Language Models on Patient Questions with False Presuppositions 发现，模型对错误前提的纠正率普遍不到 30%，剩下七成以上选择顺从。换句话说，"顺着用户问的去答"不是中立。它是一个已知的、大概率发生的失败。我不想让自己的工具落进那七成里。

第三步：四种研究类型，和按需加载的参考文件

最朴素的做法，是给所有调研套同一套输出结构。决策维度比较表。毕竟我最初的需求就是"帮我做技术选型"，比较表很自然。

它打崩在第一次拿来做探索型调研的时候。"帮我理解一下 X 这个领域"这种请求，用户手里根本还没有选项 ，你给他一张 A vs B 的比较表，是答非所问。后来翻 NNG 的信息检索行为研究才确认：获取事实、理解领域、对比选择，是三类认知任务，需要的输出结构根本不一样。

改了什么：Phase 0 开头先给研究分类，分四种。

类型	用户状态	真正需要的
探索型 Exploratory	有话题，没有先验知识	理解这个空间
方向型 Directional	有目标，没有路径	找到可行的路
比较型 Comparative	已有 ≥2 个选项	在其中做选择
验证型 Validatory	有具体方案	确认或推翻它

分型决定输出结构，四种类型各对应一个报告模板文件，用到哪个才加载哪个。

这个"按需加载"是从我另一个 Skill hl-diagram 那儿搬过来的同一套思路。那边的教训是：如果把五种图的语法一次性全塞进 context，无关内容反而会干扰模型，让它把不同图类型的语法搞混。调研这边同理，分类逻辑用一张紧凑的表内联在主文件里，四套完整模板拆成独立文件按需读，主文件就不会被撑肿，模板也能各自独立维护。

这里我没有选 的一个方案，是给每个领域（技术调研、市场调研、学术调研......）单独做一个 Skill。听起来更专业，但我盘了一下，这些领域的工作流是完全一样的，不同的只是内容和信息源。为不同内容拆出几个结构雷同的 Skill，是给自己凭空造维护负担。所以我让一个通用工作流去适配所有领域，差异交给"研究类型 + 信息源目录"这两个旋钮去调。

第四步：主动证伪，而不只是找支持证据

到这一步，工具已经能问对问题、做对分型了。但我后来意识到一个更隐蔽的毛病。

最朴素的深研做法 ，是为每个维度搜证据、挑一个推荐。问题在于，搜索这个动作天然倾向于找支持证据 。比如你想推荐 X，搜出来的也大多是 X 的好话。而跨维度校验那一步，只检查多个推荐之间会不会打架，没有任何一步去主动质疑单个推荐本身。

改了什么 ：Phase 1 现在多了一步对抗搜索。每个推荐出来之后，必须再跑一轮否定意图 的查询："X 的问题"、"为什么不用 X"、"X 的坑"。如果这一轮搜出了能动摇推荐的失效模式，就得在写报告前先改掉。这条是硬规则：没被质疑过的推荐，算不完整。

再往后还加了一道写报告前的自审检查点：在套用报告模板之前，先回答几个 yes/no。报告有没有正面回答 Phase 0 确认的核心问题？每个推荐都守住硬约束了吗？跨维度有没有互相矛盾？被标记为"挑战"的假设都处理了吗？凡是声称"主流""业界标准"的，有没有点名信息源？任何一条没过，就退回去重做。

这两步的灵感来源不太一样。对抗搜索学的是 Claude Code 自带 /deep-research 的三票反驳验证------每个结论要经得起被否定。自审检查点学的是 gpt-researcher 的独立的 reviewer / revisor 角色------写完不是终点，得有个角色专门挑刺。我没能力把它们的完整架构搬过来，但这两个哲学是可以在 Skill 这层用提示词落地的。

第五步：标"来源质量"，而不是"置信度"

最后一个零件是个很小的措辞决定，但我想专门拎出来讲，因为它体现了一种我越来越认同的克制。

我想给每个推荐标个可信度，让我自己读报告时心里有数。最直接的叫法是"置信度"，这也是我最初想用的词。

但我特意没用 它。Understanding the Effects of Miscalibrated AI Confidence on User Trust, Reliance, and Decision Efficacy 发现，只有约 26% 的用户能正确识别出 AI 的过度自信；更麻烦的是，一个数字化的"置信度"会被读成准确率的保证。模型说"置信度 90%"，用户就当成"九成是对的"。可这九成只是模型对自己的感觉，不是证据的强度。这俩是两回事，而把它们混为一谈，正是 2025 年那批生产级 agent 反复栽跟头的地方。

所以改成了"来源质量" ，标 [High] / [Medium] / [Low]，依据是信息源之间的一致程度，不是模型的自我感觉：

[High] = 至少两个独立权威源一致（官方文档、同行评审论文）
[Medium] = 单个权威源，或两个以上社区平台的共识
[Low] = 只有实践者经验，或对抗搜索时亮过红灯

一个词的差别，但它把可信度从"模型有多自信"重新锚回到"证据有多硬"。

几个架构级的取舍

上面那些是机制层面的取舍，就地融在每个零件里。还有几个否决是架构级 的。它们不绑在某个零件上，而是关于整个工具的形态。我把它们集中放这儿，因为这几个最能说明一件事：很多"没选"不是因为那个方案差，而是因为它对我的约束不合适。

context: fork。 Claude Code 有个 fork 机制可以隔离上下文，看着很适合调研。但它有个硬伤：不能在执行中途停下来问用户。而我整个 Phase 0 的命门就是"中途暂停、等用户回答"。形态不兼容，直接出局。

整体迁移到 Claude 的 Dynamic Workflow。 我专门做过一次可行性评估，结论是全量迁移和 Phase 0 架构同样不兼容，因为 Workflow 没法在执行中途暂停等输入。但评估也不是白做：它里头的对抗验证理念（就是零件四那个三票反驳），是唯一一个当下就能借、也确实借过来了的东西。至于 Phase 1 和 Workflow 的混合路线，我没否死，是搁置。

多 agent 并行深研。 维度一多，并行派子 agent 是很自然的优化。但我现在卡在 Skill 的 allowed-tools 上，它只给了 WebSearch / WebFetch / Read / Write，没有 Bash，也没有 Agent。工具集不支持，再好的设计也落不了地。这条等工具放开了再回来看。

整体换成社区里那套 Deep-Research-skills （1.2k star）。它架构更成熟，五个模块化命令加并行 agent 搜索。但它是为专家用户 设计的，默认你能看懂一份技术大纲并据此调整。这恰恰是我一开始要解决的问题的反面：我做 hl-research，就是因为我不是那个领域的专家，需要工具帮我把技术问题翻译成需求问题。换过去等于把我自己最需要的那一层给丢了。

说实话，这几个否决里，有的我到现在也不能 100% 确定是对的。多 agent 那条、Workflow 混合那条，都标着"等条件成熟再看"。对于陌生领域里的新需求，我也经常拿不准自己的判断是不是完全正确。我能做的，只是把"在我当前的约束下，这样取舍更合适"这件事记清楚，留给下一次迭代去推翻或确认。

被失败逼出来的，往往比设计出来的更耐用

回头看这七版，最强的一个感受是：理论上完美的设计，第一次运行就会暴露问题；而那些问题，正是让设计变好的原材料。 约束/假设分离是被一个轮子逼出来的，四分型是被一次答非所问逼出来的，对抗搜索是被"只会找好话"逼出来的，没有哪一条是我坐在那儿凭空想周全的。

还有一个我挺喜欢的闭环：/hl-diagram 这个工具，本身就是 hl-research 第一次实战调研出来的；调研完，我又用它给整套工具画了张全景图。一个工具被调研工具找到、实现，再反过来用来验证调研工具的质量。

这也是为什么 research-workflow.md 那份决策账本对我这么重要。它把每个决策背后的理由、每次执行的 trace 都留了下来。下次改 hl-research 的人，能看到的不只是"现在是什么样"，而是"为什么是这样、当时还排除过什么"。能被推翻的决策，才是能进化的决策。

工具代码开源在 hl-skills，有兴趣的读者可以去玩下。