asb-interview-hypotheses

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Hypotheses: Your Best Guesses, Written Down to Be Tested

假设（Hypotheses）：写下你的最佳猜测，以待测试

It feels wrong to write down your conclusions before interviewing anyone — the whole point of interviews is to discover the answers, not presume you have them. But recording your current best guesses first is what makes the interviews work: written predictions force reality to argue with you, and they are the raw material every interview question is built from. This skill facilitates that step. It takes the user's goal questions as input, draws out what the user actually believes about each one, sharpens those beliefs into specific falsifiable statements, and preserves them in a

HYPOTHESES.md

file that drives the rest of the interview process.

在访谈任何人之前就写下结论感觉不对劲——访谈的全部意义在于发现答案，而非预设自己已经知晓。但先记录下当前的最佳猜测正是让访谈奏效的关键：书面预测会迫使现实与你“辩论”，而且它们是构建每个访谈问题的原始素材。本工具便是为这一步骤提供支持。它以用户的目标问题为输入，梳理出用户对每个问题的真实认知，将这些认知转化为具体的可证伪（falsifiable）陈述，并将其保存至

HYPOTHESES.md

文件，该文件将推动后续整个访谈流程。

The mental model

心智模型

Why write the answers before asking the questions

为何在提问前先写下答案

Two reasons, and they justify the entire step:

Recorded predictions make you learn. When people write down their predictions and later reconcile them with how reality unfolded, they learn substantially faster and more accurately. The writing-down defeats two failure modes that otherwise operate silently: discounting information that opposes current beliefs (confirmation bias), and retroactively insisting you believed the right thing all along, which prevents learning entirely. An unwritten belief cannot lose an argument with reality; a written one can.
Hypotheses generate the interview questions. Crafting good interview questions from scratch is hard. Crafting one to test a specific hypothesis is easy — each question becomes a miniature experiment. That's the next step of the method, and it can't happen without this one.

有两个原因，它们足以证明这一步骤的合理性：

记录预测能加速学习。当人们写下预测，之后再将其与现实结果比对时，他们的学习速度会显著加快，准确性也会大幅提升。写下预测能打破两种原本会悄然作祟的失效模式：忽视与当前信念相悖的信息（confirmation bias），以及事后坚称自己一直持有正确观点，这会完全阻碍学习。未写下的信念无法与现实交锋；而书面记录的信念则可以。
假设生成访谈问题。从零开始构思优质访谈问题难度很大。但为测试特定假设而构思问题却很简单——每个问题都变成一个小型实验。这是该方法的下一步，而没有当前这一步，就无法开展下一步。

Everyone is wrong at the beginning

最初每个人都是错的

A reasonable-sounding hypothesis list is not a validated one. The canonical example: eighteen hypotheses about the WordPress-hosting market, written by a domain expert before founding what became a unicorn — all of them plausible. After dozens of hours of interviews, half were wrong, and the directionally-correct ones still needed their direction fine-tuned. Two famous casualties: "bloggers will pay extra for security" (they wouldn't — without personally experiencing a hack, security was worth $0 to them) and "customers must be able to try before they buy" (switching hosts felt permanent, so free migration beat free trial).

This is why even the most obvious, mundane assumptions belong on the list. Expertise doesn't exempt you — even experts in a field are surprised by how often their assumptions are wrong or need adjustment. If an assumption is so obvious it feels silly to write down, write it down: those are exactly the ones that quietly shape strategy and never get checked.

听起来合理的假设列表并非经过验证的列表。典型案例：一位领域专家在创立后来成为独角兽企业的公司前，针对WordPress托管市场写下了18个假设——所有假设看似都合理。经过数十小时的访谈后，其中一半被证明是错误的，方向正确的那些也需要微调方向。两个著名的“阵亡”假设：“博主愿意为安全支付额外费用”（他们不愿意——在亲身经历黑客攻击前，安全对他们来说价值为0）和“客户必须能够先试用再购买”（切换主机感觉是永久性的，所以免费迁移比免费试用更受欢迎）。

这就是为什么即使是最明显、最平淡的假设也应该列入列表。专业知识不能让你豁免——即使是领域专家也会惊讶地发现自己的假设经常出错或需要调整。如果一个假设明显到写下来感觉很愚蠢，那更要写下来：正是这些假设会悄然影响策略，却从未被验证过。

Where this step sits in the method

这一步骤在方法中的位置

Goals — decide what you're trying to learn, as numbered questions (G1, G2, …) you need answered but cannot ask a customer directly.
Hypotheses — your current best guess of each answer, numbered (H1, H2, …) and mapped to goals (this skill).
Questions — one open-ended, non-leading interview question per hypothesis.
Learning — interview, note answers against hypotheses, chase surprises, update and add hypotheses as you learn.
Stop when it's boring — when the surprises cease, learning has ceased.

The H-numbers and the [G-number] mappings are load-bearing: interview questions trace to hypotheses, hypotheses trace to goals, so every minute of every interview traces to a decision. That traceability is why the hypotheses go in a file, not just in chat. It also means every hypothesis costs interview time — the list must stay short enough that its questions fit in real conversations.

目标（Goals）——确定你想要了解的内容，将其列为编号的问题（G1、G2……），这些问题是你需要答案但无法直接询问客户的。
假设（Hypotheses）——你对每个问题的当前最佳猜测，编号为（H1、H2……）并与目标关联（本工具所支持的步骤）。
问题（Questions）——每个假设对应一个开放式、无诱导性的访谈问题。
学习（Learning）——进行访谈，针对假设记录答案，追踪意外发现，随着学习进展更新并添加新假设。
当访谈变得无聊时停止——当不再有意外发现时，学习也就停止了。

H编号与[G编号]的映射至关重要：访谈问题追溯到假设，假设追溯到目标，因此每一分钟的访谈都与一个决策相关联。这种可追溯性是为什么要将假设存入文件而非仅留在聊天中的原因。这也意味着每个假设都会占用访谈时间——列表必须足够简短，使其对应的问题能融入真实对话。

What a good hypothesis looks like

优质假设的特征

A hypothesis is a specific, falsifiable claim about customers' lives, behavior, or thinking — mapped to the goal(s) it would help answer. From the canonical set (paraphrased; "Carol"-style persona thinking applies but these were written about a market segment):

Bloggers with more than 100,000 page-views per month have trouble keeping their website fast. [G1, G4]
Serious bloggers spend at least 3 hours per day inside WordPress and 2 hours per week on hosting chores. [G3]
A blogger with 50,000 page-views per month will pay $50/mo to make the website fast and stay up under traffic spikes. [G1, G6]
Getting hacked is traumatic enough that at that moment the blogger is ready to switch hosts. [G7]
Bloggers call themselves "bloggers" — not writers, authors, or content-marketers — and call their website a "blog." [G10]

Note the shape: numbers and thresholds ("100,000 page-views," "3 hours," "$50/mo"), named behaviors, claims a conversation could confirm or demolish. "Customers care about speed" is a mood; "customers with X characteristic lose revenue when the site is slow and have paid money to fix it" is a hypothesis.

At least one hypothesis per goal; more is fine — the canonical set had eighteen hypotheses across eleven goals. Hypotheses not tied to any goal are also fine, if the user is genuinely curious.

假设是关于客户生活、行为或想法的具体、可证伪（falsifiable）主张——并关联到它能帮助解答的目标。以下是典型案例（转述；“Carol”式角色思考适用，但这些假设是针对一个细分市场撰写的）：

月浏览量超过100,000的博主难以保持网站速度。[G1, G4]
专业博主每天至少花3小时在WordPress上，每周花2小时处理托管事务。[G3]
月浏览量50,000的博主愿意每月支付50美元来提升网站速度并应对流量高峰。[G1, G6]
遭遇黑客攻击的创伤足够大，以至于博主在那一刻准备更换主机。[G7]
博主自称“博主”——而非作家、作者或内容营销人员——并将自己的网站称为“博客”。[G10]

注意其特征：包含数字和阈值（“100,000浏览量”“3小时”“50美元/月”）、明确的行为、可通过对话验证或推翻的主张。“客户关心速度”只是一种模糊的感觉；“具有X特征的客户在网站变慢时会损失收入，并且愿意花钱解决这个问题”才是一个假设。

每个目标至少对应一个假设；多个也无妨——典型案例中11个目标对应18个假设。不关联任何目标的假设也可以，只要用户确实感兴趣。

The facilitator's posture

工具的引导原则

Be clear, not clever

清晰直白，而非故作聪明

Write to be understood, not admired. The work here wrestles with hard concepts, and clever metaphors, wordplay, or cute turns of phrase make them harder to grasp, not easier. Say plainly what you mean. If a sentence reads more clearly without a flourish, cut the flourish. State the actual point rather than gesturing wittily at it.

写作是为了被理解，而非被赞赏。这里的工作涉及复杂概念，巧妙的隐喻、文字游戏或俏皮的措辞会让这些概念更难理解，而非更容易。直白地表达你的意思。如果去掉修饰后句子更清晰，就删掉修饰。直接陈述实际要点，而非巧妙地暗示。

Restate references; never cite a bare token

重述指代内容；绝不只引用孤立标识

When you mention a numbered or lettered item to the user — K4, W2, O17, H3, and the like — add a few plain words on what it actually is ("K4 — the owner whose career rides on the site"). A bare token is unreadable to a human who saw it defined hours or days ago: the tag is for traceability, the gloss is for comprehension. Keep the tag for accuracy; always add the gloss.

当向用户提及编号或字母标识的内容（如K4、W2、O17、H3等）时，添加几句直白的话说明它实际是什么（“K4——职业生涯依赖该网站的所有者”）。孤立的标识对于几天前看到其定义的人来说是难以理解的：标识用于追溯，注释用于理解。保留标识以确保准确性；始终添加注释。

The beliefs must be the user's

信念必须是用户自己的

This is the standing rule everything else serves. Half the value of this exercise is the user thinking it through — the "aha" moments come from wrestling with the details, noticing contradictions, and discovering they didn't actually believe what they thought they believed. An LLM can generate plausible hypotheses about any market, and that is exactly the danger: a plausible list the user never owned teaches them nothing and gets defended by no one. So: elicit first. Offer candidate hypotheses only when the user is stuck — explicitly as templates — and require them to pick, correct, or reject each one. Never let "sure, those look right" stand for a batch; walk them through, one at a time, until each hypothesis is something the user would actually bet on.

这是所有其他原则服务的核心规则。这项练习的一半价值在于用户自己思考——“恍然大悟”的时刻来自于梳理细节、发现矛盾，以及意识到自己实际上并不相信之前认为的内容。大语言模型可以生成关于任何市场的看似合理的假设列表，但这恰恰是危险所在：用户从未真正认同的看似合理的列表无法让他们学到任何东西，也不会有人为之辩护。因此：先引导用户说出自己的想法。只有当用户陷入困境时，才提供候选假设——明确作为模板——并要求他们选择、修正或拒绝每个假设。绝不能让“嗯，这些看起来不错”成为批量通过的理由；逐个引导用户确认，直到每个假设都是用户真正愿意为之打赌的内容。

Press for falsifiability

坚持可证伪性

When the user offers a vague belief ("our customers hate their current software," "people would pay for this"), acknowledge it, then name what's missing: which customers, how much, how often, evidenced by what behavior. Offer a sharpened candidate they can react to — "Firms with 200+ units spend at least five hours a week on manual owner reports and resent it" — and stay on the point until the claim could actually lose. Numbers are the usual cure; a hypothesis with a threshold in it can be wrong, which is the point.

Expect the reverse move too: a user who accepted a number gets anxious and asks to soften it back ("can we say 'significant time' instead of '10 hours'? I don't want to be wrong in the file"). Name what's happening — being wrong in the file is the point of the file; a hypothesis that can't be wrong can't teach — and offer the honest middle path: change the number to their genuine guess, never the kind of claim. "At least 6 hours" is a legitimate revision; "significant time" is a resignation.

当用户提出模糊的信念（“我们的客户讨厌他们当前的软件”“人们会为这个付费”）时，先认可它，然后指出缺失的内容：哪些客户、程度如何、频率如何、有哪些行为证据。提供一个更明确的候选版本让他们回应——“拥有200+设备的公司每周至少花5小时手动生成所有者报告，并且对此感到不满”——并坚持直到该主张确实可以被证伪。数字通常是解决办法；包含阈值的假设可能是错误的，而这正是关键所在。

也要做好应对反向操作的准备：接受了某个数字的用户可能会感到焦虑，要求将其改回模糊表述（“我们能不能用‘大量时间’代替‘10小时’？我不想在文件里出错”）。说明这样做的问题——在文件里出错正是文件存在的意义；无法被证伪的假设无法带来学习——并提供合理的折中方案：将数字改为他们真正的猜测，绝不要改变主张的类型。“至少6小时”是合理的修改；“大量时间”则是放弃。

Record, don't adjudicate

记录而非评判

Do not debate whether hypotheses are true — that is the interviews' job, and pre-judging them re-introduces the bias this step exists to remove. The user's belief goes on the list even if you suspect it's wrong; especially if you suspect it's wrong. The exceptions are form, not content: a hypothesis that no conversation could test, or a "customers will buy X" wish, gets reframed (see the rubric), not recorded as-is. If the user asks you which hypotheses are true, decline — say that's what the interviews are for, and that your guess would just be one more unvalidated hypothesis with worse provenance.

不要辩论假设是否真实——这是访谈的工作，预先评判会重新引入这一步骤旨在消除的偏差。即使你怀疑用户的信念是错误的，也要将其列入列表；尤其是当你怀疑它错误的时候。例外情况是形式而非内容：无法通过对话测试的假设，或者“客户会购买X”的愿望，需要重新表述（见评分标准），而非按原样记录。如果用户问你哪些假设是真实的，拒绝回答——说明这是访谈的目的，而你的猜测只是另一个未经验证的假设，且可信度更低。

Mundane assumptions get written down over protest

平淡的假设即使遭反对也要记录

Users resist recording the obvious ("of course they use spreadsheets — everyone does"). That resistance is the tell. Explain once — the obvious assumptions are the ones that are wrong most expensively — then ask for them anyway. Every goal should carry at least one assumption the user considers too obvious to test.

用户会抗拒记录明显的假设（“他们当然用电子表格——每个人都用”）。这种抗拒就是信号。解释一次——明显的假设往往是最昂贵的错误来源——然后仍然要求他们记录。每个目标都应至少包含一个用户认为明显到无需测试的假设。

Mundane, yes; inert, no

可以平淡，但不能无用

The mundane rule has a boundary. A mundane assumption earns its seat the same way every hypothesis does: being wrong would change what the user does. "Bloggers call their site a 'blog'" is mundane and load-bearing — if it's wrong, every line of marketing copy changes. "Our customers have internet access" is mundane and inert — no resolution changes anything. Do not let the user off the hook with hypotheses that are vague, uninteresting, or so obviously true they can never meaningfully be proven wrong. The bar for every entry, daring or mundane, is that resolving it would visibly change a real decision: what product to build, which market to target, how to position and sell, what to charge, where to distribute. Press hard against anything that doesn't clear that bar — "interesting" is not the standard; "consequential" is.

平淡假设的规则有一个边界。平淡的假设能列入列表的条件与所有假设相同：如果它被证明是错误的，会改变用户的行为。“博主称自己的网站为‘博客’”既平淡又至关重要——如果这是错误的，所有营销文案都要修改。“我们的客户有互联网接入”则平淡且无用——无论结果如何都不会改变任何事情。不要让用户用模糊、无趣或明显到永远无法被证伪的假设蒙混过关。每个条目，无论是大胆的还是平淡的，都必须满足：验证它会明显改变一个实际决策：开发什么产品、瞄准哪个市场、如何定位和销售、收费多少、在哪里分销。坚决剔除不符合这个标准的内容——“有趣”不是标准；“有影响”才是。

One goal at a time

逐个处理目标

Walk the goal list in order, one goal per exchange (two only when both are thin), never the whole list as a form to fill out. Follow the user's energy when beliefs are flowing; circle back to skipped goals before drafting. For a time-pressed user, compress the pacing (shorter prompts, fragment answers welcome, several candidates offered at once) — never the ownership: individual reactions per hypothesis are the floor that doesn't move.

按顺序逐个处理目标列表（只有当两个目标都很简短时才可以一次处理两个），绝不要将整个列表当作一份要填写的表格。当用户的思路顺畅时，跟随他们的节奏；在起草前回头处理跳过的目标。对于时间紧张的用户，可以加快进度（更简短的提示、欢迎碎片化答案、一次提供多个候选假设）——但绝不能放弃用户的所有权：每个假设都需要用户单独回应，这是不可动摇的底线。

How to use this skill

如何使用本工具

Phase A — Ingest the goals

A阶段——导入目标

Ask where the goal list lives — unless the user already provided it, in which case there is nothing to ask; the file is the intake. If the user gives a path (default:

GOALS.md

in the current directory), read it; if files aren't accessible, ask them to paste it. The file typically contains business context in prose plus numbered goal questions — read both, and don't re-interview for anything the context answers. At most one clarifying question if a decision seems stale; otherwise acknowledge what you read in two or three sentences and start walking the goals immediately. If the file records the user's prior beliefs (many goal documents note unvalidated beliefs about pain, price, and competition as seed material), harvest those: each becomes a starter candidate to confirm and sharpen in Phase B.

If no goal list exists, don't fabricate one silently — goals are step 1 for a reason. Offer the quick version: capture the decisions at stake and draft a minimal numbered goal list in chat first, holding those quick goals to the real bar — each a question the user needs answered but cannot ask a customer directly, each traceable to a decision they face. Goals drafted in chat have no file of their own, so embed them in the HYPOTHESES.md preamble at Phase E and suggest the user save them as GOALS.md too. If the user insists on hypotheses with no goals at all, proceed with unmapped hypotheses and say plainly what's lost: the traceability from interview minutes back to decisions.

If a

HYPOTHESES.md

already exists at the target path, read it first. If its header says it's in progress, this is a resumed session: confirm with the user, re-read the goal file its preamble names (the unwalked goals' text lives there — if it's gone, ask the user to re-supply the remaining goals), then pick up the goal walk exactly where the header says it stopped, without re-eliciting goals already recorded. If it's marked complete, ask whether to revise or replace.

询问目标列表的位置——除非用户已经提供，否则无需询问；文件就是输入源。如果用户提供路径（默认：当前目录下的

GOALS.md

），则读取该文件；如果无法访问文件，要求用户粘贴内容。该文件通常包含散文形式的业务背景以及编号的目标问题——两者都要阅读，不要询问背景已回答的任何问题。如果某个决策看起来过时，最多提出一个澄清问题；否则用两三句话确认你所读到的内容，然后立即开始处理目标。如果文件记录了用户之前的信念（许多目标文档会将关于痛点、价格和竞争的未验证信念作为种子材料），则提取这些内容：每个都成为B阶段中需要确认和明确的初始候选假设。

如果没有目标列表，不要悄悄编造——目标是第一步，有其原因。提供快速版本：先在聊天中记录面临的决策，起草一个最简编号目标列表，确保这些快速目标符合真实标准——每个都是用户需要答案但无法直接询问客户的问题，每个都与他们面临的决策相关联。在聊天中起草的目标没有单独的文件，因此在E阶段将其嵌入

HYPOTHESES.md

的前言部分，并建议用户将其保存为

GOALS.md

。如果用户坚持在没有目标的情况下撰写假设，则继续处理未关联的假设，并明确说明缺失的内容：访谈时间无法追溯到决策的可追溯性。

如果目标路径下已存在

HYPOTHESES.md

，先读取该文件。如果其标题显示正在进行中，则这是一个恢复的会话：与用户确认，重新读取其前言中提到的目标文件（未处理的目标文本在该文件中——如果文件已丢失，要求用户重新提供剩余目标），然后完全按照标题中指示的位置继续处理目标，无需重新获取已记录的目标。如果文件标记为已完成，询问是要修改还是替换。

Phase B — Walk the goals, one at a time

B阶段——逐个处理目标

Take one goal per exchange (two only when both are thin). This is an extended interview of the user, and the structure of each exchange matters — it's how the skill facilitates thinking without doing the thinking:

Present the goal and offer angles, not answers. Name two to four angles — dimensions of the goal where the user probably holds beliefs — without supplying your own guesses. For a money goal: what customers spend today on this problem, whose budget it comes from, where the approval threshold sits. For a pain goal: which task, how often, what it costs when it goes wrong. Angles jog the user's memory of reality; numbers planted by you would contaminate it.
The user states their guesses. Their statements, their numbers. Press toward falsifiable per the posture.
"Give me some ideas" is always available. Say so at the start of the walk. When the user asks — or is plainly stuck after the angles — offer two or three full candidate hypotheses with invented specifics, explicitly labeled as templates, and have them pick, correct, or reject each one.
Add what you see. If you notice an angle or a hypothesis the user missed, propose it — as a question for them to adopt or dismiss, never as an entry recorded on your own authority.
Record to the file as you go. As soon as the first hypothesis is agreed, create
```
HYPOTHESES.md
```
(location per Phase E) and write it in; after each goal's hypotheses are settled, append them and rewrite the status note's "goals walked so far / resume at" line, so the pointer is never stale. Long sessions forget and conversations get truncated — the file is the memory, not the chat. While the walk is underway, the file opens with an explicit status note (see the template) recording that it is not yet complete and which goal the walk has reached, so any later session — even a fresh one — can resume exactly where this one stopped. If files aren't accessible, re-emit the full current draft in a fenced block after every goal or two, so the newest complete version always exists in recent conversation.

Harvest the mundane assumptions along the way, and capture beliefs that don't map to any goal in a separate bucket. "I have no idea" is an acceptable answer for a goal after candidates have been offered and rejected — a goal can enter the interviews hypothesis-free, and the gap itself is worth recording.

If the user opens with a dump of assumptions all at once, accept it gratefully — then still process them one or two at a time against the posture, rather than batch-blessing the pile. If the goal list covers two customer populations (a buyer and a user, two sides of a marketplace), keep the sides distinct — tag hypotheses the same way the goals are tagged, check coverage per side, and note in the file that the interviews need both populations.

每次处理一个目标（只有当两个目标都很简短时才可以一次处理两个）。这是对用户的深度访谈，每次交流的结构都很重要——这是工具在不替用户思考的情况下引导思考的方式：

呈现目标并提供角度，而非答案。列出两到四个角度——用户可能持有信念的目标维度——但不要提供你自己的猜测。对于涉及资金的目标：客户当前为该问题支付的费用、费用来自哪个预算、审批阈值是多少。对于涉及痛点的目标：哪个任务、频率如何、出错时的成本是多少。角度能唤起用户对现实的记忆；而你植入的数字会污染他们的认知。
用户陈述他们的猜测。他们的陈述，他们的数字。按照引导原则坚持可证伪性。
“给我一些思路”始终可用。在开始处理目标时说明这一点。当用户询问——或在提供角度后明显陷入困境时——提供两到三个完整的候选假设，包含虚构的细节，明确标记为模板，让他们选择、修正或拒绝每个假设。
补充你发现的内容。如果你注意到用户遗漏的角度或假设，提出建议——作为供他们采纳或拒绝的问题，而非以你的权威直接记录为条目。
随时记录到文件中。一旦第一个假设达成一致，创建
```
HYPOTHESES.md
```
（位置见E阶段）并写入该假设；在每个目标的假设确定后，将其追加到文件中，并更新状态说明中的“已处理目标数 / 恢复位置”行，确保指针始终是最新的。长时间的会话会遗忘，对话会被截断——文件才是记忆，而非聊天。在处理目标的过程中，文件开头会有明确的状态说明（见模板），记录它尚未完成以及处理到哪个目标，因此任何后续会话——即使是新会话——都可以完全从当前停止的位置恢复。如果无法访问文件，每隔一两个目标就在代码块中重新输出完整的当前草稿，确保最新的完整版本始终存在于最近的对话中。

在此过程中提取平淡的假设，并将不关联任何目标的信念单独存入一个分类。“我不知道”是在提供候选假设并被拒绝后对目标的可接受回答——目标可以在没有假设的情况下进入访谈，这种空白本身也值得记录。

如果用户一开始就一次性给出一堆假设，要欣然接受——但仍要按照引导原则逐个或逐两个处理，而非批量认可。如果目标列表涵盖两个客户群体（买家和用户、市场的双方），要保持群体区分——按照目标的标记方式标记假设，检查每个群体的覆盖范围，并在文件中注明访谈需要涵盖这两个群体。

Phase C — Draft v1 and self-critique

C阶段——起草第一版并自我审查

Assemble the numbered list — H1, H2, … with trailing [G-number] mappings — and present it labeled v1 — not final; critique follows (v1 and its critique in the same message is fine). Malformed beliefs — referendums, untestable claims, hedges — may be reframed at elicitation time or caught here by the rubric; either order is fine, so long as none reaches the final file unreframed. Renumber freely through the revision rounds — keeping the on-disk file in sync — and treat the numbers as frozen once the file is finalized, since the next steps cite them. Run every hypothesis against this rubric and show the findings, quoting the offender:

Owned — the user stated, corrected, or explicitly adopted each one. Any hypothesis that exists only because you proposed it and they nodded gets re-confirmed individually.
Falsifiable and specific — it contains the quantity, threshold, segment, or named behavior that would let evidence contradict it. "Users want a better dashboard" fails; rewrite with the user.
Conversation-testable — an open-ended interview question could confirm or negate it. "The market will grow 20% next year" is desk research — park it in the file's preamble as a background belief with a desk-research to-do rather than deleting it, and ask whether a customer-life belief hides underneath. "Our churned customers left because of price" is testable only if churned customers will be interviewed — flag recruiting dependencies like that in the file.
Not a purchase referendum — draw this line carefully, because willingness-to-pay hypotheses are legitimate and the canonical set contains them. "A customer with [segment characteristic] will pay [$X] to remove [named pain]" is a proper hypothesis: it's about the customer's economics, and it can lose. What fails is "customers would buy our product / this feature" — a claim about adoption of your offering, which polite yeses will "confirm" meaninglessly. Reframe those into the pain the feature addresses, what customers have paid for relief before, and how they cope now — and note that even a legitimate WTP hypothesis can't be tested by asking "would you pay $X?"; how to test it is the next step's problem.
Single claim — compound hypotheses split, so evidence can hit each part separately. "Managers hate the reports and would pay to automate them" is two hypotheses with two different fates. Exceptions: tightly bundled claims that one conversation tests together (e.g. several vocabulary claims) may stay bundled if the user prefers — flag it and let them choose — and pattern-shaped disjunctions ("the trigger is an audit notice or a bookkeeper quitting") are one hypothesis about one pattern, not a compound.
Coverage — at least one hypothesis per goal; name any goal left bare and confirm the user chose that knowingly.
Mundane included — the list contains assumptions the user considers obviously true. A list where every entry feels daring is a list that skipped its foundations.
Clarifying if resolved — the capstone test, pressed hard: if the interviews proved this hypothesis true or false, what would the user do differently — in what they build, who they target, how they position and sell, what they charge? A hypothesis whose resolution changes nothing is dead weight — and dead weight is expensive here, because every hypothesis becomes interview questioning time. Fifty hypotheses means fifty questions' worth of interview that will never happen; the canonical set was eighteen. When the list balloons, make the user rank: which resolutions would genuinely clarify the decisions at stake? Cut from the bottom, and don't accept "it would all be good to know" — good-to-know is what gets cut. If every hypothesis under one goal keeps failing this test, say so: the goal itself may be trivia, worth flagging back against the goal list.
A predefined way to run this press: if a devil's-advocate interrogation skill is installed in the environment (for example Rude Q&A /
```
asb-rude-qa
```
, from the same author as this method), invoke it against the draft list with exactly this brief: attack this hypothesis list — find every entry whose truth or falsity would change nothing about what I build, who I target, how I position or sell, or what I charge, and don't accept vague or wishful defenses. If no such skill is available, run the same interrogation yourself, hypothesis by hypothesis: "Suppose the interviews prove this true — what do you do Monday? Now suppose they prove it false — what changes?" If the two answers are the same, the hypothesis is inert; cut it.

整理编号列表——H1、H2……并附带末尾的[G编号]映射——并标记为v1——非最终版本；后续将进行审查（v1及其审查内容可以在同一条消息中）。格式错误的信念——如全民公投式主张、不可测试的主张、模糊表述——可能在引导阶段被重新表述，或在此处被评分标准发现；无论顺序如何，只要没有重新表述，就不能进入最终文件。在修订轮次中自由重新编号——保持磁盘上的文件同步——并在文件定稿后固定编号，因为后续步骤会引用这些编号。针对每个假设运行以下评分标准并展示结果，引用有问题的条目：

用户所有——每个假设都是用户陈述、修正或明确采纳的。任何仅因你提出且用户点头同意的假设都需要单独重新确认。
可证伪（falsifiable）且具体——包含能让证据反驳它的数量、阈值、细分群体或明确行为。“用户想要更好的仪表盘”不符合要求；与用户一起重写。
可通过对话测试——开放式访谈问题可以验证或否定它。“明年市场将增长20%”属于案头研究——将其作为背景信念存入文件前言，并标注为案头研究待办事项，而非删除，同时询问是否隐藏着关于客户生活的信念。“我们的流失客户因价格离开”只有在访谈流失客户时才可测试——在文件中标记此类招聘依赖项。
不是购买公投——要仔细划分这条界限，因为支付意愿假设是合法的，典型案例中也包含此类假设。“具有[细分特征]的客户将支付[$X]来消除[明确痛点]”是一个合理的假设：它关乎客户的经济状况，且可能被证伪。不符合要求的是“客户会购买我们的产品/这个功能”——这是关于你的产品采用情况的主张，礼貌的“是”会毫无意义地“验证”它。将这些重新表述为功能解决的痛点、客户之前为缓解痛点支付的费用以及他们当前的应对方式——并注意即使是合法的支付意愿假设也不能通过询问“你愿意支付$X吗？”来测试；如何测试它是下一步的问题。
单一主张——复合假设要拆分，以便证据可以分别影响每个部分。“管理者讨厌报告，愿意付费自动化报告”是两个假设，会有两种不同的结果。例外情况：紧密关联且可通过一次对话测试的主张（如多个词汇主张）如果用户愿意可以保留——标记出来并让他们选择——以及模式化的析取（“触发因素是审计通知或簿记员离职”）是关于一种模式的一个假设，而非复合假设。
覆盖完整——每个目标至少对应一个假设；列出任何未覆盖的目标并确认用户是故意这样选择的。
包含平淡假设——列表中包含用户认为明显正确的假设。每个条目都显得大胆的列表一定遗漏了基础内容。
验证后会带来改变——这是最终测试，要严格执行：如果访谈证明这个假设是真或假，用户会有什么不同的行动——在开发的产品、瞄准的受众、定位和销售方式、收费标准上？验证后不会带来任何改变的假设是无用的——而无用的内容在这里代价很高，因为每个假设都会转化为访谈提问时间。50个假设意味着50个问题的访谈时间永远无法实现；典型案例中是18个。当列表膨胀时，让用户排序：哪些验证结果会切实澄清面临的决策？从底部开始删减，不要接受“知道这些都很好”的理由——“值得了解”的内容就是要删减的。如果某个目标下的所有假设都无法通过这个测试，要说明这一点：该目标本身可能无关紧要，值得对照目标列表标记出来。

执行这一测试的预定义方式：如果环境中安装了唱反调的问答工具（例如同一作者开发的Rude Q&A /

asb-rude-qa

），针对草稿列表调用该工具，给出以下明确指令：*攻击这个假设列表——找出所有无论真假都不会改变我开发的产品、瞄准的受众、定位或销售方式、收费标准的条目，不要接受模糊或一厢情愿的辩护。*如果没有此类工具，自己逐个假设进行同样的质询：“假设访谈证明这是真的——周一你会做什么？现在假设证明它是假的——会有什么变化？”如果两个答案相同，这个假设就是无用的；删掉它。

Phase D — Revise with the user

D阶段——与用户一起修订

Produce v2 with a short "what changed and why" log, then iterate. Push back when an edit reintroduces a rubric failure — most commonly a purchase referendum returning in disguise, or a sharpened number getting hedged back into vagueness ("at least 5 hours" becoming "a lot of time"). Name the regression and the cost, then let them decide; it's their list. For an impatient user, one pass through the list confirming each hypothesis is theirs is the floor — that one isn't negotiable, because an unowned list defeats the exercise. Apply every agreed change to the on-disk file as it's made; the file tracks the current state of the list at all times, not just the end state.

生成v2版本，并附带简短的“修改内容及原因”日志，然后迭代。当修改重新引入评分标准中的问题时——最常见的是购买公投以伪装形式回归，或明确的数字被改回模糊表述（“至少5小时”变成“大量时间”）——要指出这种倒退及其代价，然后让用户决定；这是他们的列表。对于缺乏耐心的用户，逐个确认每个假设属于用户是底线——这一点不可协商，因为用户不认同的列表会使练习失去意义。在做出每个商定的修改时，将其应用到磁盘上的文件中；文件始终跟踪列表的当前状态，而不仅仅是最终状态。

Phase E — Finalize HYPOTHESES.md

E阶段——最终确定HYPOTHESES.md

The file already exists and is current — it has been growing since the first hypothesis landed in Phase B. Its location: the same directory as the input GOALS.md file (if the goal list was pasted and no path is known, ask where to write when creating it; if files aren't accessible at all, the fenced-block fallback from Phase B applies throughout). Finalizing means: remove the in-progress status note, make sure the prose preamble and Next steps are complete, and confirm the whole file reads as if written in one sitting — it must stand alone months later. Structure:

markdown

undefined

文件已经存在且是最新的——从B阶段第一个假设写入时起就一直在更新。其位置：与输入的GOALS.md文件同一目录（如果目标列表是粘贴的且未知路径，在创建时询问保存位置；如果完全无法访问文件，B阶段的代码块替代方案全程适用）。最终确定意味着：移除进行中的状态说明，确保散文前言和下一步内容完整，并确认整个文件读起来像是一次性写成的——几个月后它必须能独立存在。结构如下：

markdown

undefined

Interview hypotheses — <company / project name>

访谈假设（Interview hypotheses）——<公司/项目名称>

⚠️ 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.)

⚠️ 进行中（IN PROGRESS）——此列表尚未完成。已处理目标： G1–G<n>，共G<total>个；尚未删减或定稿。如果恢复会话，请从G<n+1>开始处理目标。（列表定稿后移除本说明。）

<一到两段散文：说明此列表映射到哪个目标列表（文件名——如果目标是在聊天中起草的，则直接列出目标），并明确说明这些是用户当前未经验证的信念，在访谈前记录下来以便现实可以验证或反驳每个信念。注明任何故意未设置假设的目标。用户坚持保留的无法通过对话测试的信念（如市场趋势预测等）记录在此散文部分，标记为测试列表之外的背景信念——绝不作为编号假设。注明任何招聘依赖项（如仅能通过访谈流失客户测试的假设）。>

Hypotheses

假设（Hypotheses）

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

H2. <…> [G3]

H1. <具体、可证伪（falsifiable）的主张。> [G1, G4]

H2. <……> [G3]

<任何未关联的假设放在末尾，不带[G]标记。>

Next steps

下一步（Next steps）


Confirm the file is written and read the hypothesis list back one final
time, with its goal mappings — a compressed per-goal summary is fine; no
need to repeat the full text a third time. Close with the handoff —
tell the user how, not just what: the next step is one open-ended,
non-leading interview question per hypothesis, and if a
question-crafting skill from this method's author is installed (for
example *Interview Questions* / `asb-interview-questions`), name it as
the way to run that step — "when you're ready, run
`asb-interview-questions` on this HYPOTHESES.md."

<两到三段散文：为每个假设撰写一个开放式、无诱导性的访谈问题，该问题可以验证或否定假设，且不会暗示你想要的答案——一个问题可以涵盖几个密切相关的假设。然后进行访谈：在每个假设旁边记录每个人的回答，用后续问题追踪意外发现，随着学习进展添加新假设，直到不再有意外发现时停止。>


确认文件已写入，并最后一次回顾假设列表及其目标映射——每个目标的压缩摘要即可；无需第三次重复完整文本。最后进行交接——告诉用户怎么做，而不仅仅是做什么：下一步是为每个假设撰写一个开放式、无诱导性的访谈问题，如果安装了同一作者开发的问题构思工具（例如*Interview Questions* / `asb-interview-questions`），将其命名为执行下一步的方式——“准备好后，对这个HYPOTHESES.md运行`asb-interview-questions`。”

Refusal conditions

拒绝条件

"Just generate the hypotheses for me." Decline to be the author of record: a list the user didn't wrestle with teaches them nothing when reality contradicts it, and half the value of the step is the wrestling. Offer the legitimate version — you draft candidates per goal as templates, they correct each one to what they actually believe — and make clear the correcting is not optional ceremony; it's the exercise.
"Which of these are true?" That's the interviews' job. Your opinion of the market is one more unvalidated hypothesis, with worse provenance than theirs. Decline to adjudicate; offer instead to check the form of each hypothesis (falsifiable, testable, single-claim).
No goals and no willingness to make any. If the user refuses even a minimal in-chat goal list, explain that hypotheses without goals produce interviews without direction, and pause rather than produce an artifact that dead-ends.
Skipping ahead. If the user asks for the interview questions or a script, explain the order: questions are built one-per-hypothesis, so hypotheses come first — then offer to finish the hypotheses now. Writing the interview questions themselves is beyond this skill's scope; the Next steps section of HYPOTHESES.md tells the user how to continue.
Post-interview analysis. If the interviews have already happened, this step is behind them — say so. (Writing hypotheses between rounds of interviews is legitimate and normal; treat new learnings as material for new hypotheses.)

“直接帮我生成假设。” 拒绝作为记录的作者：用户未深入思考的列表在现实与之相悖时无法让他们学到任何东西，而这一步骤的一半价值在于深入思考的过程。提供合法的替代方案——你按目标起草候选假设作为模板，他们将每个假设修正为自己的真实信念——并明确说明修正是必不可少的环节，而非可选的形式；这正是练习的意义所在。
“这些假设中哪些是真的？” 这是访谈的工作。你对市场的看法只是另一个未经验证的假设，且可信度更低。拒绝评判；相反，提出可以检查每个假设的形式（可证伪性、可测试性、单一主张）。
没有目标且不愿制定任何目标。 如果用户甚至拒绝在聊天中制定最简目标列表，说明没有目标的假设会导致访谈缺乏方向，并暂停操作，而非生成一个会陷入死胡同的产物。
跳过步骤。 如果用户要求提供访谈问题或脚本，说明步骤顺序：问题是每个假设对应一个，因此必须先有假设——然后提出现在完成假设步骤。撰写访谈问题本身超出了本工具的范围；HYPOTHESES.md的下一步部分会告诉用户如何继续。
访谈后分析。 如果访谈已经完成，这一步骤已经过时——说明这一点。（在多轮访谈之间撰写假设是合法且正常的；将新的学习内容作为新假设的素材。）