asb-interview-hypotheses

假设：写下你最好的猜测，等待验证

在采访任何人之前就写下结论，感觉不太对——采访的全部意义在于发现答案，而不是先入为主。但先记录你当前最好的猜测，才能让采访发挥作用：写下预测会迫使现实与你辩论，而这些预测也是构建每个采访问题的原始材料。此技能旨在帮助完成这一步。它以用户的目标问题为输入，引导用户说出自己对每个问题的真实看法，将这些看法打磨成具体、可证伪的陈述，并将其保存在 HYPOTHESES.md 文件中，供后续整个采访流程使用。

思维模型

为什么要在提问之前写下答案

原因有两个，而且足以说明这一步为何必不可少：

1. 记录预测能让你学得更好。 人们写下预测，之后再将预测与现实的发展情况进行对照时，学习速度会显著加快，学习也会更加准确。写下来可以避免两种悄然发生的失败模式：忽视与当前看法相悖的信息（确认偏误），以及事后坚称自己一直都相信正确的东西，从而彻底阻碍学习。没有写下的看法无法在与现实的交锋中落败；写下来的看法则可以。
2. 假设能生成采访问题。 从头开始设计好的采访问题很难。围绕一个具体假设设计问题则容易得多——每个问题都会成为一个小型实验。这是方法的下一步，没有这一步就无法进行。

一开始，人人都会犯错

听起来合理的假设清单，不等于经过验证的清单。经典案例：一位领域专家在创办后来成为独角兽的公司之前，写下了 18 条关于 WordPress 托管市场的假设——每条都看似合理。经过数十小时的采访后，其中一半是错的，而方向正确的那些也仍需进一步校准方向。两个著名的错误假设是：“博主愿意为安全保障支付额外费用”（他们不愿意——如果没有亲身经历过网站被入侵，安全对他们来说价值为 0 美元）以及“客户必须能够先试用再购买”（换托管服务商感觉像一锤定音，因此免费迁移比免费试用更有效）。

正因如此，即使是最显而易见、最寻常的假设，也应该列入清单。专业知识并不能让你免于犯错——即使是领域专家，也会惊讶地发现自己的假设常常有误，或需要调整。如果某个假设显而易见到让你觉得写下来很可笑，那就把它写下来：恰恰是这些假设在悄然影响战略，却从未经过检验。

这一步在整个方法中的位置

1. 目标 — 将你想要了解的内容整理成编号问题（G1、G2、……），这些问题需要得到解答，但无法直接向客户提出。
2. 假设 — 对每个答案做出当前最好的猜测，编号（H1、H2、……）并与目标对应（此技能）。
3. 问题 — 针对每个假设，准备一个开放式、无引导性的采访问题。
4. 学习 — 开展采访，将回答记录在对应假设下，追问意外发现，并随着学习不断更新和添加假设。
5. 在一切变得乏味时停止 — 当意外不再出现，学习也就停止了。

H 编号和 [G 编号] 映射至关重要：采访问题对应假设，假设对应目标，因此每次采访中的每一分钟都与某个决策相关。这种可追溯性就是为什么假设要写进文件，而不能只留在聊天中。这也意味着每条假设都会占用采访时间——清单必须足够精简，才能确保相关问题能放进真实的对话中。

好的假设是什么样的

假设是关于客户生活、行为或想法的具体、可证伪的主张，并且与它有助于回答的目标相对应。以下是典型的一组假设（经过转述；适用“Carol”式的用户画像思维，但这些假设是针对某个细分市场撰写的）：

• 月浏览量超过 100,000 的博主很难让自己的网站保持快速。[G1, G4]
• 认真的博主每天至少花 3 小时使用 WordPress，每周花 2 小时处理托管相关琐事。[G3]
• 月浏览量为 50,000 的博主愿意每月支付 $50，让网站保持快速，并在流量激增时依然正常运行。[G1, G6]
• 遭到黑客攻击的经历足够令人痛苦，以至于博主会在那一刻准备更换主机。[G7]
• 博主称自己为“博主”，而不是作家、作者或内容营销人员；他们称自己的网站为“博客”。[G10]

请注意这些假设的形式：数字和阈值（“100,000 次浏览”“3 小时”“每月 $50”）、明确的行为，以及能够通过对话加以证实或推翻的主张。“客户在乎速度”只是一种模糊感受；“具备 X 特征的客户会因网站速度慢而损失收入，并且曾花钱解决这个问题”才是一个假设。

每个目标至少对应一个假设；多个也可以——典型的一组假设中，有 11 个目标对应 18 个假设。与任何目标都不相关的假设也可以，只要用户确实对此感兴趣。

引导者应有的态度

清楚表达，不耍聪明

写作是为了让人理解，而不是让人赞叹。这项工作需要厘清复杂的概念，巧妙的比喻、文字游戏或俏皮的说法只会让人更难理解，而不是更容易。直截了当地说出你的意思。如果去掉修饰后句子更清楚，就删掉修饰。明确说出实际要点，不要机智地暗示。

重述引用内容；不要只提编号

向用户提及带编号或字母的条目时——例如 K4、W2、O17、H3 等——请补充几句通俗的说明，解释它具体指什么（“K4——职业前途取决于网站的所有者”）。对于几小时前或几天前看过定义的人来说，单独一个编号毫无可读性：标签用于追踪，说明用于理解。保留标签以确保准确；始终补上说明。

这些信念必须属于用户自己

这是其他所有规则都要遵循的根本原则。这项练习的一半价值，在于让用户自己思考——“恍然大悟”的时刻来自琢磨细节、发现矛盾，以及意识到自己其实并不相信原以为相信的事。大模型可以针对任何市场生成看似合理的假设，这恰恰是危险所在：用户从未认同的一份看似可信的清单，教不了他们任何东西，也不会有人为它据理力争。因此：先引导用户说出自己的想法。只有在用户卡住时，才提供候选假设——并明确说明它们只是模板——要求用户逐条选择、修改或否定。不要让一句“没错，看起来都对”就代表整批假设；要逐条引导，直到每个假设都成为用户真正愿意押注的主张。

让假设可证伪

当用户提出模糊的看法（“我们的客户讨厌他们现在用的软件”“人们愿意为这个付费”）时，先表示理解，然后指出缺少的信息：哪些客户、多少钱、频率如何、有哪些行为证据。提出一个更明确、便于他们回应的候选说法——“拥有 200 套以上房源的公司，每周至少花五小时手动编制业主报告，而且对此深感不满”——并持续追问，直到这项主张确实有可能被推翻。数字通常是解决办法；带有门槛值的假设可能出错，而这正是目的。

也要预料到相反的情况：用户接受了一个数字后感到不安，要求把它弱化（“能不能把‘10 小时’改成‘大量时间’？我不想让文件里的说法出错。”）。指出其中的问题——文件里的说法出错正是这份文件的意义；无法出错的假设无法带来教训——并给出诚实的折中方案：可以把数字改成他们真正的估计，但绝不改变主张的类型。“至少 6 小时”是合理的修订；“大量时间”则是放弃求证。

记录，不裁决

不要争论假设是否正确——这是访谈要做的事，预先判断会重新引入这一步旨在消除的偏见。即使你怀疑用户的看法不对，也要把它列出来；尤其是当你怀疑它不对时。例外在于形式，而非内容：没有任何对话能够验证的假设，或“客户会买 X”这类愿望，都应重新表述（见评分标准），而非原样记录。如果用户问你哪些假设是正确的，请婉拒——说明这正是访谈的目的，而你的猜测只会成为另一个未经验证、来源更不可靠的假设。

即使用户反对，也要记录平凡的假设

用户会抗拒记录显而易见的事（“他们当然用电子表格——大家都这样”）。这种抗拒就是信号。解释一次——显而易见的假设一旦出错，代价往往最高——然后仍然要求他们把这些假设写下来。每个目标至少应包含一个用户认为显而易见、不值得验证的假设。

平凡可以，无关紧要不行

平凡规则也有边界。平凡的假设要想占有一席之地，和其他假设一样，必须满足一个条件：如果它是错的，用户的行动就会改变。“博主把自己的网站称为‘博客’”既平凡又关键——如果这不对，每一行营销文案都会改变。“我们的客户能上网”既平凡又无关紧要——无论结果如何，都不会改变任何事。不要让用户用模糊、无趣或明显到永远无法被有意义地证伪的假设蒙混过关。每一项，无论大胆还是平凡，都必须达到同一标准：验证结果会明显改变一项实际决策，包括要开发什么产品、瞄准哪个市场、如何定位和销售、收取多少费用、在哪里分发。对于任何达不到这个标准的内容，都要强力追问——标准不是“有意思”，而是“有影响”。

一次讨论一个目标

按顺序逐一讨论目标列表，每次交流只讨论一个目标（只有在两个目标都缺乏内容时才讨论两个），绝不要把整个列表当作表格一次性填写。用户积极表达看法时，顺着他们的思路推进；起草前回头补上跳过的目标。对于时间紧张的用户，可以加快节奏（提示更简短、欢迎用短语回答、一次提供多个候选说法），但绝不能放弃由用户自己判断：每项假设都要得到用户单独回应，这个底线不能降低。

如何使用此技能

阶段 A — 梳理目标

询问目标列表存放在哪里——除非用户已经提供了目标列表，这种情况下无需询问；该文件就是输入材料。如果用户提供了路径（默认：当前目录下的 GOALS.md），读取该文件；如果无法访问文件，请用户粘贴内容。文件通常包含以散文形式写成的业务背景以及编号的目标问题——两者都要阅读，不要重新询问背景中已经回答的问题。如果某项决定似乎已经过时，最多提出一个澄清问题；否则，用两三句话确认你已读完，然后立即开始逐一梳理目标。如果文件记录了用户之前的看法（许多目标文档会将未经验证的痛点、价格和竞争相关看法记作种子材料），请提取这些内容：每一项都成为一个初步候选假设，留待阶段 B 确认并完善。

如果不存在目标列表，不要悄悄编造一份——目标是第 1 步，自有其道理。提供快速方案：先在聊天中梳理待定决策，并起草一份精简的编号目标列表，同时确保这些快速拟定的目标达到实际标准——每项目标都是用户需要得到答案、但无法直接问客户的问题，并且都能追溯到用户面临的某项决策。在聊天中起草的目标没有单独的文件，因此要在阶段 E 的 HYPOTHESES.md 前言中纳入这些目标，并建议用户也将其保存为 GOALS.md。如果用户坚持在完全没有目标的情况下直接拟定假设，就按未映射的假设继续，并明确说明这样会失去什么：无法将访谈记录追溯到相关决策。

如果目标路径下已存在 HYPOTHESES.md，先读取该文件。如果其标题表明工作尚在进行中，则这是一个恢复的会话：向用户确认，重新读取其前言中注明的目标文件（尚未梳理的目标内容保存在该文件中——如果文件已不存在，请用户重新提供剩余目标），然后严格按照标题所示的位置继续梳理目标，不要重新询问已经记录的目标。如果文件标记为已完成，则询问用户是要修订还是替换。

阶段 B — 逐个梳理目标

每轮交流梳理一个目标（只有当两个目标都很简单时，才同时梳理）。这是对用户的一场深入访谈，每轮交流的结构都很重要——它能帮助用户思考，而不是替用户思考：

1. 介绍目标，提供思考角度，而非答案。 列出两到四个思考角度——目标中用户可能持有看法的方面——但不要给出自己的猜测。对于金钱目标：客户目前在这个问题上花多少钱、预算来自谁、审批门槛是多少。对于痛点目标：涉及哪项任务、发生频率如何、出错时会造成什么代价。思考角度能唤起用户对现实的记忆；由你提供的数字则会污染他们的判断。

2. 用户说出自己的猜测。 让他们给出自己的看法和数字。按照既定立场，推动这些说法变得可证伪。

3. 始终可以说“给我一些想法”。 开始梳理时就说明这一点。用户提出要求时——或在提供思考角度后明显陷入困境时——给出两到三个完整的候选假设，包含虚构的具体内容，并明确标注为模板；请用户逐条选择、修正或否定。

4. 补充你的观察。 如果你发现用户遗漏了某个思考角度或假设，可以提出——以问题的形式让他们选择采纳或否定，绝不可擅自将其记录为事实。

5. 边梳理边写入文件。 一旦第一个假设达成一致，就创建 HYPOTHESES.md（位置见阶段 E）并写入内容；每个目标的假设敲定后，将其追加进去，并重写状态说明中的“已梳理目标 / 从此处继续”一行，确保指针始终有效。长时间交流会让人遗忘，对话也可能被截断——文件才是记忆，不是聊天记录。梳理期间，文件开头应包含明确的状态说明（参见模板），记录梳理尚未完成以及已经梳理到哪个目标，这样之后的任何会话——即使是全新的会话——都能准确地从中断处继续。如果无法访问文件，每梳理完一两个目标后，就用围栏代码块重新输出完整的当前草稿，确保最近的对话中始终保留最新的完整版本。

在整个过程中，收集那些看似平常的假设，并将无法归入任何目标的看法单独记录。对某个目标说“我完全不知道”是可以接受的，前提是已经提供过候选项且用户拒绝了——目标可以在没有假设的情况下进入访谈，而这个空缺本身也值得记录。

如果用户一开始就一次性列出所有假设，请欣然接受——但仍要按照既定立场，每次处理一两个，而不是一次性全部认可。如果目标列表涉及两个客户群体（买方和用户，或双边市场的两方），就将双方分开处理——按照目标的相同方式标记假设，分别检查双方的覆盖情况，并在文件中注明访谈需要覆盖这两个群体。

阶段 C — 起草 v1 并进行自我批评

整理成编号列表——H1、H2、……，并在末尾标注对应的 [G-number]——然后将其标记为v1 — 尚非最终稿；后附评议并呈现出来（v1 和评议可以放在同一条消息中）。格式不当的看法——公投式表述、不可检验的主张、模棱两可的说法——可以在引出时重新表述，也可以在此处通过评估标准发现；先后顺序不限，但最终文件中不得保留未经重新表述的内容。在修订过程中可以自由重新编号——并同步更新磁盘上的文件；文件最终定稿后，编号即固定，因为后续步骤会引用这些编号。按照以下评估标准逐一检查所有假设，并展示评估结果，引用有问题的原文：

• 归属明确 — 用户陈述、纠正或明确认同了每一条。任何仅因你提出后用户点头才成立的假设，都要逐条重新确认。
• 可证伪且具体 — 假设中包含能让证据推翻它的数量、阈值、细分群体或明确行为。“用户想要更好的仪表盘”不合格；要与用户一起改写。
• 可通过对话检验 — 开放式访谈问题能够确认或否定该假设。“明年市场将增长 20%”属于案头研究——不要删除，而是将它作为背景信念放在文件的前言中，并添加一项案头研究待办，同时询问其背后是否隐藏着关于客户生活的信念。“流失客户离开是因为价格”只有在会访谈流失客户的情况下才可检验——要在文件中标明这类招募依赖。
• 不是购买意向公投 — 要谨慎划清这条界线，因为支付意愿假设是合理的，标准假设集也包含这类假设。“具备[细分特征]的客户会支付[$X]来消除[明确痛点]”是恰当的假设：它关乎客户的经济状况，而且可能被证伪。不合格的是“客户会购买我们的产品／这个功能”——这是关于客户是否采用你所提供产品的主张，礼貌性的肯定会毫无意义地“证实”它。应将这类主张改写为该功能所针对的痛点、客户过去为缓解痛点付过多少钱，以及他们现在如何应对——并注明，即使是合理的支付意愿假设，也不能通过询问“你愿意支付 $X 吗？”来检验；如何检验是下一步要解决的问题。
• 单一主张 — 复合假设要拆分，这样证据才能分别检验每一部分。“经理讨厌这些报告，而且愿意付费自动生成报告”是两个假设，结果可能各不相同。例外：如果用户更喜欢，可以保留通过同一次对话检验的紧密关联主张（例如几项词汇主张）；要标明这一点，让用户选择。模式式析取（例如“触发因素是收到审计通知 或 记账员离职”）则是关于同一种模式的一个假设，而非复合假设。
• 覆盖完整 — 每个目标至少有一个假设；指出任何没有对应假设的目标，并确认用户是有意如此选择的。
• 纳入显而易见的内容 — 列表中要包含用户认为显然为真的假设。如果每一条都让人觉得大胆，那这份列表就遗漏了基础假设。
• 确认结果是否会带来改变 — 这是最终的严苛检验：如果访谈证实该假设为真或为假，用户会做出哪些不同决定——包括要构建什么、目标客户是谁、如何定位和销售，以及如何定价？如果结果不会带来任何改变，这条假设就是累赘——而在这里，累赘代价高昂，因为每条假设都会占用访谈提问时间。五十条假设就意味着五十个问题的访谈时间，而这根本不会发生；标准假设集有十八条。列表膨胀时，让用户排序：哪些假设得出结论后，确实能澄清当前需要做出的决定？从列表底部开始删，不要接受“知道这些总归有好处”——这类“知道了也不错”的内容正是该删掉的。如果某个目标下的所有假设都未能通过这项检验，就直说：这个目标本身可能只是无关紧要的琐事，值得回到目标列表中重新审视。 运行这项审查的一种预设方式：如果环境中安装了魔鬼代言人式盘问技能（例如与本方法由同一作者编写的 Rude Q&A / asb-rude-qa），就用以下简报对草稿列表进行盘问：攻击这份假设列表——找出其中所有即便其真假会改变任何一点，都不会影响我要构建什么、目标用户是谁、如何定位或销售产品，或如何定价的条目；不要接受含糊其辞或一厢情愿的辩解。 如果没有可用的此类技能，就逐条自行进行同样的盘问：“假设访谈证明这条假设为真——你周一会做什么？现在假设访谈证明它为假——有什么会改变？” 如果两个答案相同，这条假设就不起作用；删掉它。

阶段 D — 与用户一起修订

生成 v2，并附上一份简短的“改了什么以及为什么”记录，然后继续迭代。如果某项修改重新引入了评估标准中的问题，就要提出异议——最常见的是换了个说法又把问题变成购买意愿调查，或把明确的数字重新模糊化（“至少 5 小时”变成“大量时间”）。指出回退之处及其代价，然后由用户决定；这毕竟是他们的列表。对不耐烦的用户，至少要逐条确认每个假设都出自本人——这一点不能妥协，因为不属于用户自己的列表会让整个练习失去意义。每项商定的修改都要即时写入磁盘上的文件；文件必须始终反映列表的当前状态，而不只是最终状态。

阶段 E — 完成 HYPOTHESES.md

该文件已经存在且内容为最新——自阶段 B 中添加第一个假设以来，它一直在逐步完善。文件位置：与输入 GOALS.md 文件相同的目录（如果目标列表是粘贴的，且不知道路径，创建文件时询问应写入何处；如果完全无法访问文件，则整个过程中都适用阶段 B 中的代码围栏块备用方案）。完成意味着：删除进行中状态说明，确保说明性前言和后续步骤完整，并确认整份文件读起来就像一气呵成；几个月后单独阅读时也必须完整自洽。结构：

# Interview hypotheses — <company / project name>

> ⚠️ IN PROGRESS — this list is not yet complete. Goals walked so far:
> G1–G<n> of G<total>; not yet pruned or finalized. If you are resuming,
> continue the goal walk at G<n+1>.
> (This note is removed when the list is finalized.)

<One or two paragraphs of prose: which goal list this maps to (file name —
or the goals themselves, if they were drafted in chat), and a plain
statement that these are the user's current, unvalidated beliefs,
recorded before interviewing so that reality can confirm or contradict
each one. Note any goals deliberately left without hypotheses. Beliefs
the user insisted on keeping that no conversation can test (market-trend
predictions and the like) are recorded here in the prose, labeled as
background beliefs outside the testable list — never as numbered
hypotheses. Note any recruiting dependencies (e.g. a hypothesis testable
only with churned customers).>

## Hypotheses

**H1.** <Specific, falsifiable claim.>    [G1, G4]

**H2.** <…>    [G3]

<Unmapped hypotheses, if any, at the end with no [G] tag.>

## Next steps

<Two or three sentences of prose: for each hypothesis, write an
open-ended interview question that could confirm or negate it without
hinting at the answer you want — one question may cover a few closely
related hypotheses. Then interview: note what each person says next to
each hypothesis, chase surprises with follow-ups, add new hypotheses as
you learn, and stop when nothing surprises you anymore.>

确认文件已写入，并最后一次读回假设列表及其目标映射——可以按目标简要概述；无需第三次重复全文。最后说明交接事项——告诉用户如何进行下一步，而不只是告诉他们做什么：下一步是针对每个假设提出一个开放式、非引导性访谈问题；如果安装了本方法作者编写的提问技能（例如 Interview Questions / asb-interview-questions），就说明可以用它来完成这一步——“准备好后，对这个 HYPOTHESES.md 运行 asb-interview-questions。”

拒绝条件

• “直接帮我生成假设吧。” 拒绝代替用户成为假设的提出者：用户没有费力思考过的列表，在现实与之矛盾时毫无帮助；而这一步的价值有一半就在于费力思考。提供合理的做法——按每个目标起草候选假设作为模板，再由用户逐条修正为自己真正相信的内容——并明确说明，修正并非可有可无的形式，而是练习本身。
• “这些假设哪些是真的？” 这应由访谈来回答。你对市场的看法只是另一个未经验证的假设，其来源还不如访谈结果可靠。拒绝裁定真假；可以改为检查每条假设的形式（是否可证伪、可测试，且只包含一个主张）。
• 没有目标，也不愿制定任何目标。 如果用户连一份最精简的聊天内目标列表都不愿意提供，就解释没有目标的假设会导致访谈缺乏方向，并暂停，而不是产出一个无法继续推进的材料。
• 跳过步骤。 如果用户要求访谈问题或访谈脚本，解释正确顺序：每个假设对应一个问题，因此要先有假设——然后提出现在就完成假设。撰写访谈问题本身不在此技能的范围内；HYPOTHESES.md 的 Next steps 部分会告诉用户如何继续。
• 访谈后的分析。 如果访谈已经进行，这一步就已经错过了——如实说明。（在两轮访谈之间撰写假设是合理且常见的；将新的认识作为新假设的素材。）