HypoLoop
假设循环学习

我们不是允许失败,而是要求失败。
这是一个在团队项目中有意设计个人学习的学习框架。

目的学习,而非解决问题
引擎假设 → 提问 → 探究 → 评估
评估学习增量(Δ),而非产出物
For Whom

我们为这些人打造了它

🧭

教育者 · 运营者

你在运营基于团队项目的教育,却苦恼于“成果做出来了,个人到底学到了什么却说不清”;你希望课程靠结构自行运转,而不是依赖运营者的个人能力。

🛠️

团队负责人 · 组织

你想在副业项目、黑客松或新人入职中,打破成员“只做熟悉的事直到结束”的角色固化;你想明确团队成长与产出物之间的优先级。

📓

学习小组 · 个人学习者

你觉得课听完了却什么也没留下;你想用“学习之前先建立假设、再推翻它”的方式,无论独自学习还是在小组中,都提高学习的密度。

The Problem

团队在前进,
但个人在学习吗?

团队项目越是合理地运转,每个人就越会承担自己已经擅长的工作。产出物的质量在提升,个人的学习曲线却趋于平缓。学习被挤到一边,沦为解决问题时侥幸获得的副产品。

“解决有价值的问题,学习自然随之而来”
“学习只有被有意设计,才能得到保证”

HypoLoop 正是从更换这一前提出发。收回押在偶发学习上的赌注,让学习从一开始就成为一个被明确命名的目标。

为什么是“学习”,而不是“解决问题”
只解决问题的话 只解决当前实力够得着的问题 产出物在累积,实力却原地踏步 在更难的问题面前止步
边学习边解决的话 在学习中攻克小挑战 解决问题的能力本身在成长 最终抵达终极难题

这不是要放弃解决问题,而是要调换顺序。终极的真正问题,靠今天的实力是解不开的。只有学习才能让我们明天解决更难的问题,所以 HypoLoop 把学习置于产出物之上。小挑战不是绕路,而是通往终极问题的唯一阶梯。

Core Concepts

四大支柱

四个概念都用同一个例子来讲解 — 🍞 做面包。团队的目标是“开一家深受街坊喜爱的面包店”,而我是一名还不懂发酵的成员。

CONCEPT 01

假设引擎

在没有信息的状态下先建立假设,拆解成可验证的问题,在探究中推翻它,再评估增量。假设被推翻的瞬间是最大的学习点,验证的时刻就是考试。

假设 提问 探究 评估
🍞 用面包来讲

在学习之前先写下来 — “我理解面包是靠泡打粉膨胀的。去掉酵母烤一次就能见分晓。”结果烤出来是扁的。假设被推翻的这一刻,酵母发酵这个真正的原理被深深刻进脑海。如果一上来就先搜索,这条知识只会一扫而过。

CONCEPT 02

分形嵌套

团队滚动着面向世界问题的假设,个人则在其中嵌套自己的学习假设。“在解决这个团队问题的过程中,我要有意地学会 X。”层有两个,循环只有一个。

TEAM INDIVIDUAL × N
🍞 用面包来讲

团队滚动着“我们街区的人早上会想要刚出炉的健康面包”这个假设。我在其中嵌套了“在筹备这家面包店的过程中,我要学会发酵”这个学习假设。团队开面包店,我学发酵 — 层有两个,循环只有一个。

CONCEPT 03

挑战层级树

把终极的真正问题层层分解到可以挑战的大小。再小的挑战也与真正的问题以血统相连。决定它是玩具还是踏板的,不是大小,而是连接的可见性。

终极挑战 ← 个人选择的叶子节点
🍞 用面包来讲

开一家深受街坊喜爱的面包店 → 开发招牌健康面包 → 烤出酸面包 → 制作天然酵种(叶子节点)。就连在玻璃瓶里养一周酵种这样的小挑战,沿着树向上追溯,也与面包店这个真正的问题血统相连。所以它是踏板,不是玩具。

CONCEPT 04

学习增量(Δ)评估

成败的标准不是“问题解决了吗”,而是“相对于假设,发生了什么变化”。问题是真的,尝试也是真的,但被打分的是变化量。因此,产出物质量的下降可以被正式接受。

初始理解 当前理解 Δ = 学习
🍞 用面包来讲

今天烤的酸面包塌了,失败了。但在循环开始时,我并不知道发酵温度会改变什么;而现在我能解释“低温发酵造就风味,过度发酵让面团塌陷”。被打分的不是面包的形状,而是这段距离(Δ)。

Playbook

从设定问题到复盘,
八个步骤完成运转

这是一个靠结构而非某位运营者的能力来驱动的框架。复制每个步骤的模板,照着填写,第一个循环就开始了。

STEP 1
设定问题

把真正的问题立为终极挑战

团队宣布一个真心想解决的、真实存在于世界上的问题作为终极挑战。它应当并非不可能、但也绝不容易,并与成员的兴趣和关联性相连。这个问题的真实性,就是整棵树的真实性。

我们团队要解决 [世界上的真实问题 P]。
这是 [谁,在什么情境下] 实际面临的问题。
问题解决后,可以通过 [什么发生了改变] 来确认。
进行方式 — 照着做即可
全队60~90分钟便利贴 · 白板
  1. 收集(15分钟) — 每人把“最近 6 个月内亲身经历或亲眼目睹的不便”写在便利贴上,一张一条,至少 5 条。不必宏大。
  2. 归类(10分钟) — 全部贴到墙上,把相似的归成一组,并给每组起一个名字。
  3. 实存验证(10分钟) — 对每一组共同发问:“我们能不能指出至少一个真实经历这件事的人?”指不出来就剔除。
  4. 投票(5分钟) — 对剩下的候选每人投 2 票:“最有意思的” 1 票 + “以我们的规模能够承担的” 1 票。
  5. 宣告(15分钟) — 用得票最多的问题一起填写模板的三行,全员出声朗读并同意后即为确定。
填空提示问题
  • [世界上的真实问题 P] — 是否已经有人为忍受这个不便而花着时间或金钱?没有人为之惋惜的,不是问题,只是一个点子。
  • [谁,在什么情境下] — 不要用户画像,要具体到真实存在的人。“20 多岁的上班族” ✗ → “上班路上顾不上吃早餐的隔壁组小金” ✓
  • [什么发生了改变] — 写成问题解决后的第二天、能亲眼观察到的一个场景。
🍞 填写示例“我们团队要解决‘在街区里买不到刚出炉的健康面包’的问题。这是靠面包解决早餐的上班路上的邻居们每天面临的问题。问题解决后,可以通过早上 7 点店门口排起队来确认。”
STEP 2
分解树

层层拆解到可以挑战的大小

展开解决终极挑战所需的前提子挑战,不断分解,直到出现个人在一个循环内可以尝试的叶子节点。把树张贴在团队公共空间,让每个叶子到终极挑战的路径始终可见。

要解决 [上级挑战],
必须以 [子挑战 A / B / C] 为前提。

叶子判定 — 这个大小是否小到一个人
能在 1~2 周内尝试推翻假设?(否 → 再分解一次)
提示:一个叶子节点 = 能在 1~2 周内尝试推翻假设的大小
进行方式 — 照着做即可
全队60分钟大张纸 · Miro/FigJam
  1. 张贴根节点 — 把终极挑战写在最上方。
  2. 反复问分解问题 — 问“要实现它,必须先实现什么?”,把答案写成 2~4 个子挑战。从技术·用户·运营三个方向各问一遍,就很难有遗漏。
  3. 叶子判定 — 对每个节点发问:“这个大小是否小到一个人能在 1~2 周内尝试推翻假设?”如果不是,就在该节点上重复第 2 步。
  4. 张贴 — 把完成的树贴到团队公共空间(Notion·墙面)。从任何叶子到根的路径都要一目了然。
提示
  • 节点要写成行动,而不是名词 — “发酵知识” ✗ → “尝试制作天然酵种” ✓
  • 深度 3~4 层就足够了。叶子超过 15 个时,只保留本次循环会用到的分支,其余先折叠起来。
  • 树不是成品,而是地图草稿 — 每个循环都会更新。
🍞 填写示例开面包店 → 开发招牌健康面包 → 烤出酸面包 → 制作天然酵种(叶子)
STEP 3
选择叶子

每个人选自己“不会的”

不从白纸开始设立挑战。从树的叶子节点中挑选,规则只有一条 — 选择现在不会的。对新手来说,叶子是基础技能;对熟手来说,叶子是能放大专业能力的相邻领域(设计、领域知识、市场)。

我选择 [叶子 L]。
现在的我做不到这件事 — 依据:[一旦尝试就会发生的事]。
这个叶子通过 [叶子 → 中间 → 终极] 的路径
与团队挑战相连。
注意:一旦选了自己擅长的,使用这个框架的理由就消失了
进行方式 — 照着做即可
个人20分钟完成的树
  1. 扫描 — 浏览树上的叶子,各自标出“现在让我做就做不到的”。
  2. 选择 — 从标记中挑出一个在本次团队循环里真正会被用到的叶子。
  3. 写下依据 — 用一句话写下“做不到的依据”:现在去尝试,实际会发生什么。
  4. 朗读路径 — 向同伴出声讲述从叶子到终极挑战的路径。讲不顺,就先修补树。
提示
  • 依据只有“没做过”是不够的 — 能写出“一上手就会卡在这个地方”,才是好叶子。
  • 在两个之间犹豫时,选更不会的那个
  • 如果你是专家 — 技术叶子看起来全都很容易,这本身就是信号。去设计·领域·市场的分支里选。
🍞 填写示例“我选择‘制作天然酵种’。依据:我以为面粉加水放着只会长霉 — 分不清发酵和腐败。路径:酵种 → 酸面包 → 招牌面包 → 面包店。”
STEP 4
撰写假设

在学习之前,用当下的理解写下假设

在搜索之前、听课之前,不借助任何信息,仅凭当前的理解填写假设模板。越别扭、错得越多越好。这个假设将成为认知钩子,勾住之后遇到的所有信息。

我现在对 [对象 X] 是 [这样理解/预期] 的。
试着做 [验证行动 Y],就能看出这个理解是否正确。
如果这个假设被推翻,我将学到 [将会学到的东西]。
进行方式 — 照着做即可
个人15分钟禁止搜索
  1. 隔断 — 定时 15 分钟。把搜索框、课程、AI 全部关掉。
  2. 撰写 — 只凭此刻脑子里的理解,填满模板的三行。
  3. 原样保留 — 就算别扭、感觉是错的,也不要修改。这份文档的目的不是正确答案,而是等着被推翻的靶子
  4. 确认大小 — 只需确认验证行动 Y 是能在 1~2 周内执行的大小。
填空提示问题
  • 想不出 [对象 X] 时 — 一开始做这个叶子,最先撞上的就是 X。
  • [验证行动 Y] 要是离开书桌的行动 — 阅读·观看 ✗,动手做·测量·亲身经历 ✓
  • 写不出 [将会学到的东西],说明假设还算不上一个预测 — 把 X 再收窄一些。
🍞 填写示例“我现在理解面包是靠泡打粉膨胀的。去掉酵母烤一次,就能看出这个理解是否正确。如果这个假设被推翻,我将学到让面团膨胀的真正原理。”
STEP 5
同伴验证

由同伴提出一个问题

提问的不是建立假设的本人,而是团队同伴 — “如果这个假设被推翻,你会学到什么?”答不上来,就修改假设重写。有了这个仪式,验证无需循环守护者也能运转,提问者自己也在训练元认知。循环守护者不是干预者,而是照看这套结构是否运转良好的基础设施管理者。

提问:“如果这个假设被推翻,你会学到什么?”
通过 — 回答指向一个具体的理解。
驳回 — 验证行动模糊 / 学不到任何东西
       / 是已经知道的东西。
被驳回后,修改假设并重写。
进行方式 — 照着做即可
两人一组每人10分钟
  1. 朗读 — 把假设出声读出来。
  2. 提问 — 同伴发问:“如果这个假设被推翻,你会学到什么?”
  3. 判定 — 30 秒内用一个具体的理解作答,即为通过。
  4. 驳回标准 — 验证行动模糊 / 学不到任何东西 / 是已经知道的东西。
  5. 再次挑战 — 被驳回就当场修改再问一遍。来回不超过 3 分钟。
提示
  • 提问的同伴禁止给建议 — 只提问。修改是本人的事。
  • 最好的驳回是:“那个你不是早就知道了吗。”
  • 如果有循环守护者,只看这个仪式是否在运转 — 不插手问答。
🍞 问答示例Q“被推翻的话你会学到什么?” — A“我会分清膨胀的原因是化学膨松剂,还是生物发酵。” → 通过
STEP 6
探究

在解决团队问题的同时推翻假设

不必另设学习时间,解决团队问题的过程本身就是假设的实验场。假设被推翻的瞬间要当场记录 — 预期与现实的落差越大,理解的更新也越大。

[探究日志 — 每当假设被推翻时]
预期:[原本预期的]
现实:[实际发生的]
从落差中学到的:[更新后的理解]
假设被推翻的瞬间是最大的学习点 — 不要事后补记,要当场记录
进行方式 — 照着做即可
个人整个循环期间探究日志
  1. 照常工作 — 不另设学习时间,团队工作照常推进。
  2. 当场记录 — 每当出现“咦,和预期不一样?”的瞬间,就当场花 5 分钟写下 3 行日志(预期/现实/学到的)。
  3. 每周分享 — 每周一次,在站会上各自分享一个被推翻的假设。这是炫耀的场合。
提示
  • 日志不必写得漂亮 — 留下来就行。照片、语音备忘也是日志。
  • 一周过去什么都没被推翻的话 — 把验证行动做得更狠,或者把假设定得更冒险。
🍞 日志示例预期:没有酵母就完全不会膨胀 / 现实:放了一天,稍微膨胀了一点 / 学到的:空气中也有野生酵母。
STEP 7
增量复盘

复盘的是变化量,不是产出物

循环结束时,每个人重新拿出起点的假设,测量当时的理解与现在理解之间的距离(增量Δ)。同时记录这次学习把团队挑战推进到了哪里 — 学习与解决在这里合而为一。

起点的我 [是这样理解] 的。
现在的我 [是这样理解] 的。
增量(Δ):[什么被更新了]
对解决的贡献:[这次学习把团队挑战
推进到了哪里]
被打分的不是产出物,而是增量 — 即使成果粗糙,只要增量够大就是成功
进行方式 — 照着做即可
全队60分钟STEP 4 的假设原文
  1. 朗读原文 — 每人把 STEP 4 的假设原封不动地再读一遍。
  2. 撰写增量 — 像向“循环开始时的自己”解释那样,填写增量模板。
  3. 发表 — 轮流进行,每人 3 分钟。不演示产出物,只讲理解的变化
  4. 团队层一句话 — 就本次循环把团队假设推进(或推翻)到了哪里达成共识。
提示
  • 抓不住增量时,重新翻开 STEP 6 的日志 — 每个被推翻的瞬间,都对应着一个增量。
  • 比起“不知道 → 知道”,“曾这样理解 → 现在那样理解”才是好的增量。
  • 复盘开始时,请出声读这句话 — “即使成果粗糙,只要增量够大就是成功。”
🍞 填写示例“起点的我理解膨胀靠的是膨松剂。现在的我知道,原理是酵母分解糖时释放的 CO₂,膨松剂只是那条捷径。Δ:化学 → 生物。贡献:招牌酸面包试制品 1 号。”
STEP 8
下一循环

用更新的理解建立下一个假设

复盘中更新的理解,就是下一循环的起点。下一个叶子要选更不会的,团队层也以同样的节奏运转 — 团队假设被推翻不是失败,而是转向的依据。循环永不停止。

下一个叶子:[比这次更不会的]
下一个假设:[用更新的理解重写]
团队层反馈:[如有被推翻的团队假设 → 转向方向]
从未被推翻的假设 = 定得太安全的信号。下一个叶子,选更不会的。
进行方式 — 照着做即可
团队 + 个人30分钟树 · 复盘记录
  1. 更新树 — 给完成的叶子做上标记,把探究中新发现的分支加进去。
  2. 下一个叶子 — 每人自选。规则不变:比这次更不会的。
  3. 转向共识 — 如有被推翻的团队假设,用一句话就转向方向达成共识。
  4. 重新开始 — 回到 STEP 4。循环永不停止。
提示
  • 可以再选同一领域的叶子 — 但假设必须更深一层。
  • 团队假设被推翻不是失败,而是收获。是复盘时值得鼓掌的事。
🍞 填写示例“下一个叶子:实验低温发酵如何改变风味。下一个假设:我理解发酵时间越长越好 — 烤 24·48·72 小时的面团来对比,就能见分晓。”
LOOP KEEPER · FACILITATOR

循环守护者不教 — 只提问

循环守护者(引导者)既不是传授知识的人,也不是检查挑战的人。他是照看结构是否运转良好的基础设施管理者,是在需要的时刻抛出一个问题的人 — 守护循环不停转动的人,因此得名。他不给答案 — 因为寻找答案的过程正是学习者的循环。下面这些问题不是守护者的专利。即使没有守护者,只要队友之间互相提问,框架就能运转。

选择叶子时
  • 那个,你现在不就已经会了吗?说你不会,依据是什么?
  • 能用自己的话说说,从那个叶子到终极挑战的路径吗?
建立假设时
  • 如果这个假设被推翻,你会学到什么?
  • 这真的是在搜索或学习之前写下的假设吗?
  • 那个验证行动,1~2 周内真的能做完吗?
探究过程中
  • 最近有没有哪个瞬间和预期不一样?记在哪里了?
  • 如果假设一个都还没被推翻 — 会不会是定得太安全了?
关闭循环时
  • 循环开始时的你,会怎么解释现在这个东西?
  • 这次学到的东西,把团队挑战推进到了哪里?
  • 用更新后的理解,你要建立的下一个假设是什么?
Templates

模板合集 —
复制即可开始

循环所需的全部句式模板,都汇集在这一页。格式本身就是过滤器 — 填不出空格,说明还没有准备好

TEMPLATE · 复制后即可使用
我现在对 [对象 X][这样理解/预期] 的。

试着做 [验证行动 Y],
就能看出这个理解是否正确。

如果这个假设被推翻,
我将学到 [将会学到的东西]

最后一行就是同伴验证问题的答案。提前写好这一行,就能立刻回答“被推翻的话你会学到什么?”;写不出来,说明假设还没有准备好。

CYCLE SHEET — 一页纸走完一个循环
ALL-IN-ONE

循环表

粘贴到 Notion 或文档中,一个循环期间只填这一页。它是下方 8 个步骤模板的浓缩版。

[循环表 — 姓名: · 周期: ~ ]

叶子:[从树上选出的、现在不会的]
做不到的依据:[一旦尝试就会发生的事]
血统:[叶子 → 中间 → 终极挑战]

假设:我现在对 [对象 X] 是 [这样理解/预期] 的。
验证行动:[1~2 周内可以尝试的 Y]
被推翻后会学到:[一个具体的理解]
同伴验证:通过 / 驳回 — [同伴姓名 · 日期]

探究日志(每次被推翻时):
- 预期: → 现实: → 学到的:
- 预期: → 现实: → 学到的:

增量(Δ):[起点的理解] → [现在的理解]
对解决的贡献:[把团队挑战推进到了哪里]
下一个叶子:[比这次更不会的]
STEP TEMPLATES — 全部八个步骤
STEP 1 · 设定问题

终极挑战宣言

在启动会上由全队一起填写,出声朗读后确定。

我们团队要解决 [世界上的真实问题 P]。
这是 [谁,在什么情境下] 实际面临的问题。
问题解决后,可以通过 [什么发生了改变] 来确认。
STEP 2 · 分解树

分解 + 叶子判定

对每个节点提出叶子判定问题,答案是否就再分解一次。

要解决 [上级挑战],
必须以 [子挑战 A / B / C] 为前提。

叶子判定 — 这个大小是否小到一个人
能在 1~2 周内尝试推翻假设?(否 → 再分解一次)
STEP 3 · 选择叶子

挑选“不会的”

规则只有一条 — 现在不会的。写出依据才算完成。

我选择 [叶子 L]。
现在的我做不到这件事 — 依据:[一旦尝试就会发生的事]。
这个叶子通过 [叶子 → 中间 → 终极] 的路径
与团队挑战相连。
STEP 4 · 撰写假设

假设句式

搜索之前,15 分钟,只凭当下的理解。错得越多越好。

我现在对 [对象 X] 是 [这样理解/预期] 的。
试着做 [验证行动 Y],就能看出这个理解是否正确。
如果这个假设被推翻,我将学到 [将会学到的东西]。
STEP 5 · 同伴验证

验证问答判定表

提问者只提问 — 禁止建议。来回不超过 3 分钟。

提问:“如果这个假设被推翻,你会学到什么?”
通过 — 回答指向一个具体的理解。
驳回 — 验证行动模糊 / 学不到任何东西
       / 是已经知道的东西。
被驳回后,修改假设并重写。
STEP 6 · 探究

探究日志

在假设被推翻的当场,5 分钟内写完。不必写得漂亮。

[探究日志 — 每当假设被推翻时]
预期:[原本预期的]
现实:[实际发生的]
从落差中学到的:[更新后的理解]
STEP 7 · 增量复盘

增量复盘

复盘变化量而非产出物。把起点假设的原文放在旁边来写。

起点的我 [是这样理解] 的。
现在的我 [是这样理解] 的。
增量(Δ):[什么被更新了]
对解决的贡献:[这次学习把团队挑战
推进到了哪里]
STEP 8 · 下一循环

下一循环计划

下一个叶子选更不会的;被推翻的团队假设化为转向方向。

下一个叶子:[比这次更不会的]
下一个假设:[用更新的理解重写]
团队层反馈:[如有被推翻的团队假设 → 转向方向]
MEETING — 会议运营
WEEKLY · 团队·学习小组通用

每周例会议程

学习小组把循环压缩为一周,用这份议程运转。60~90 分钟。

[每周例会议程 — 60~90分钟]

1. 增量分享(每人3分钟)
   原样朗读上次的假设原文,
   只谈与当前理解的距离。禁止炫耀成果物。
2. 炫耀被推翻的瞬间
   每人一个与预期不符的瞬间。
   如果没人被推翻 → 全员叶子升级。
3. 撰写下一个假设(15分钟,当场)
   在搜索之前写。
4. 同伴验证(两人一组)
   “如果这个假设被推翻,你会学到什么?”
   直到通过。只许提问,不许给答案。
Samples

完整走完八个步骤的
五个循环

五个进行示例来自不同的团队规模、熟练度和领域。第一个案例是按天记录、完整走过八个步骤的详细演练 — 想看框架实际如何运转,请从它读起。(这些是以运营场景为基础重构的示例。)

SAMPLE 01 · 详细演练🍞 街角面包店副业项目 4 人 · 全员非科班新手 · 2 周循环
STEP 1
设定问题
DAY 1 · 90分钟
四个人聚在一起,每人把“最近六个月里遇到的不便”写成 5 张便利贴,共 20 张贴上墙。归类之后得到早餐 · 通勤 · 社区商圈三簇。对每一簇抛出实存验证问题 — “我们能指出一个真实经历这个问题的人吗?”对“街区里没有面包店”,全员都指向了自己和隔壁组的同事;而“通勤很无聊”没有一个人能指出为此惋惜的人,落选。用每人 2 票的投票(兴趣 1 票 + 力所能及 1 票)敲定之后,大家一起填好宣言,全员出声朗读。我们团队要解决“在街区里买不到刚出炉的健康面包”的问题。这是靠面包解决早餐的上班路上的邻居们每天面临的问题。问题解决后,可以通过早上 7 点店门口排起队来确认。
STEP 2
分解树
DAY 1 · 60分钟
从技术、用户、运营三个方向追问“要开成面包店,得先做成什么?”,得到三个分支。对“烤出酸面包”抛出叶子判定问题 — “这个大小是否小到一个人能在 1~2 周内尝试推翻假设?” — 答案是。再分解一次,得到三个叶子,并把完成的树发布到 Notion。开面包店 ├─ 开发招牌健康面包(技术) │ └─ 烤出酸面包 ← 叶子判定:否,再分解 │ ├─ 制作天然酵种 ← 叶子 │ ├─ 掌握揉面与整形 ← 叶子 │ └─ 掌控烘烤温度 ← 叶子 ├─ 争取早晨的顾客(用户)→ 作为团队假设 └─ 找到小规模起步的方法(运营)
STEP 3
选择叶子
DAY 2 · 20分钟
扫一遍叶子,给“现在让我做我做不来的”做标记。“揉面与整形”感觉照着 YouTube 就能跟做,于是排除 — 依据只有“只是没做过”的叶子是弱叶子。酵种不一样。我选择“制作天然酵种”。 依据:我以为面粉加水放一周只会长霉 — 我分不清发酵和腐败。 血统:酵种 → 酸面包 → 招牌面包 → 面包店。把这条路径出声讲给同伴听时毫无卡顿,树无需修补即告通过。
STEP 4
撰写假设
DAY 2 · 15分钟
计时器 15 分钟,搜索框、YouTube、AI 全部关掉。最难的是忍住“搜一下 3 分钟就有答案”的冲动。只凭此刻脑中的理解填满了三行。我现在理解面包是靠泡打粉膨胀的。 去掉酵母烤一次,这个理解对不对就能见分晓。 如果这个假设被推翻,我将学到让面团膨胀的真正原理。
STEP 5
同伴验证
DAY 2 · 10分钟
其实最初的假设并不是这个。第一次提交的假设是“我不懂发酵。做一次酵种就会懂了”,面对同伴的提问只答得出“会…懂发酵吧?”,于是被驳回(会学到什么太模糊)。当场重新追问“我到底真正误解了什么?”,改写成泡打粉假设,再次挑战。Q“如果这个假设被推翻,你会学到什么?” 第 1 次:“会懂发酵” → 驳回(模糊) 第 2 次:“能分清膨胀是因为化学膨松剂 还是因为生物发酵” → 通过
STEP 6
探究
DAY 3~11
不安排单独的学习时间 — 面包店的筹备(团队作业)本身就是实验场。在玻璃瓶里养起酵种,并让一份去掉酵母的面团作为对照组一起运转。每当假设被推翻的瞬间,当场写下 3 行日志:DAY 3 — 预期:面粉+水只会坏掉 现实:第 3 天冒起气泡,散发酸香 学到的:不是腐坏,发酵正在“发生” DAY 5 — 预期:去掉酵母就完全不会膨胀 现实:放了一天,竟然“稍微”膨胀了 ← 假设被推翻的瞬间 学到的:空气中住着野生酵母。 发酵不是加进去的,而是自己发生的 DAY 9 — 预期:酵种放得越多,膨胀得越好 现实:过度发酵,面团塌了 学到的:发酵不是用量的函数,而是时间·温度的函数同一时期,团队层也在验证自己的假设 — 带着“街坊们早上想要现烤的健康面包”,在周末早晨的咖啡店门口访谈了 12 位邻居。比起“现烤”,大家对“健康食材”反响更大。层有两个,循环只转一个。
STEP 7
增量复盘
DAY 12 · 60分钟
每人把 DAY 2 的假设原文一字不改地朗读出来,再像讲给“当时的自己”听那样填写增量。试制的酸面包 1 号是塌的 — 但被打分的不是面包的形状,而是这段距离。开始的我理解为膨胀是泡打粉的化学反应。 现在的我知道原理是酵母分解糖时释放的 CO₂, 膨松剂只是那条捷径。额外的收获是, 发酵是时间·温度的函数,这一点我也用身体记住了。 增量(Δ):化学 → 生物,以及用量 → 时间·温度 对解决问题的贡献:招牌酸面包试制品 1 号 — 虽然塌了,但通过了团队试吃。
Δ 增量:“膨胀 = 膨松剂的化学反应” → “膨胀 = 酵母分解糖时释放的 CO₂,膨松剂只是那条捷径。” 团队贡献:招牌酸面包试制品 1 号。被打分的不是产出物的质量(塌掉的面包),而是增量 — 成功。
STEP 8
下一循环
DAY 12 · 30分钟
更新了树 — 给酵种叶子标上完成,并新增探究中发现的“低温发酵”分支。下一个叶子,选更不懂的。下一个叶子:实验低温发酵如何改变风味 下一个假设:我理解为发酵时间越长越好 — 分别烤 24·48·72 小时来对比,就能见分晓 团队层反映:根据访谈结果,把讯息从“现烤”为中心 转向“健康食材”为中心
SAMPLE 02🦯 室内导航教育项目团队 5 人 · iOS 专业学生
终极挑战
我们团队要解决“视障人士在室内迷路”的问题。这是在导盲犬和盲道都到不了的建筑物内部每天上演的问题。问题解决后,可以通过在初次到访的建筑里独自抵达目的地来确认。
树 → 叶子
室内寻路 → 不依赖眼睛传达信息(非视觉界面) → 闭着眼睛用一整天 VoiceOver 手势体系
选择依据
“学了三年 iOS 开发,却一次都没有打开过 VoiceOver。”
假设
我现在理解视障人士是把屏幕从上到下按顺序听读着使用的。闭眼用一天就能见分晓。如果这个假设被推翻,我将学到非视觉探索的真实策略。
同伴验证
Q“被推翻的话你会学到什么?” — A“是线性朗读,还是存在别的探索策略。” → 通过
被推翻的瞬间
预期:按顺序边听边用 / 现实:半天就放弃了 — 太慢了,根本没有人那样用。人们靠转子(Rotor)和标题跳转,“跳跃着结构”来探索 / 学到的:非视觉使用的核心不是朗读,而是结构。
Δ 增量:“线性朗读模型” → “结构跳转模型。好的无障碍 = 精心设计的标题层级。” 团队贡献:把引导 UX 从“按顺序读”转向为“地标 + 方向”的方式。
下一个循环
把路线引导翻译成触觉节奏 — 能否不靠声音传达方向。
SAMPLE 03📦 市场库存应用训练营团队 6 人 · 只做过前端的学员
终极挑战
我们团队要解决“传统市场的商贩离开账本就无法掌握库存”的问题。这是商贩们每天打烊后要花一小时手工盘点的问题。问题解决后,可以通过收尾盘点在 10 分钟内完成来确认。
树 → 叶子
库存应用 → 库存数据安全地累积 → 搭建一个记录变动的 API 服务器
选择依据
“服务器一直只是 fetch 别人做好的。我解释不了端口是什么。”
假设
我现在理解服务器存储只要每次收到请求就写进文件就足够了。同时发 100 个请求试试就能见分晓。如果这个假设被推翻,我将学到并发中什么会出问题。
同伴验证
Q“被推翻的话你会学到什么?” — A“文件写入在并发请求下会变成什么样。” → 通过
被推翻的瞬间
预期:请求一多顶多变慢 / 现实:并发 100 条之后,库存数和实际对不上了 — 连报错都没有,悄无声息地错了(race condition) / 学到的:存储不是“写入”,而是“相互竞争的写入”。
Δ 增量:“存储 = 写进文件” → “存储 = 相互竞争的写入。事务和锁为什么存在,我用身体记住了。” 团队贡献:引入 SQLite 事务,与 1 位市场商贩开始 beta 测试。
下一个循环
地下店铺时断时续的网络 — 走向离线优先同步。
SAMPLE 04🔎 内部 Wiki 搜索机器人1 人(独自使用 HypoLoop)· 后端 3 年经验
终极挑战
我要解决“新人在 Slack 上反复问同样的问题”的问题。答案明明在公司 Wiki 里,却找不到。问题解决后,可以通过一半的入职问题由机器人解决来确认。独自使用时:团队层 = 我想做出的真正成果。
树 → 叶子
搜索机器人 → 把问题和文档按语义连接起来 → 把文档转成向量,试做相似度检索
选择依据
“我连用比喻都解释不了‘嵌入(embedding)’。”
假设
我现在理解嵌入检索是关键词检索的全面升级版。把同样 20 个问题投给两种方式做对比,就能见分晓。如果这个假设被推翻,我将学到两种方式各自在什么时候占优。
同伴验证
没有同伴,于是先把假设公开在博客上 — 由未来的自己和读者担任验证者。(独自使用时的替代仪式)
被推翻的瞬间
预期:嵌入在所有场景全面占优 / 现实:在专有名词和错别字问题上,关键词检索大获全胜 / 学到的:嵌入擅长“相近的意思”,不擅长“精确的那个词”。
Δ 增量:“全面升级版” → “互为补充 — 所以混合检索才会存在。” 成果:关键词+向量混合检索原型。
下一个循环
用数字衡量检索质量 — 制作一套 50 题的评估集。
SAMPLE 05🎛 部署仪表盘公司内部黑客松 3 人 · 10 年经验后端开发者
终极挑战
我们团队要解决“每次出故障都要互相打听现在部署了什么”的问题。这是部署现状只存在于开发者脑子里的问题。问题解决后,可以通过非开发岗位也能在 30 秒内自行确认现状来验证。
树 → 叶子
仪表盘 → 做出一眼就能读懂的界面 → 不靠设计师,亲自做信息架构
选择依据
“十年来 UI 都是拿到稿子只管实现。从没判断过界面上该去掉什么。” — 专家的叶子 = 能放大专业能力的相邻领域
假设
我现在理解好的仪表盘就是把信息一样不落地展示出来。做一个测试 — 只给 3 位同事看 30 秒再询问现状 — 就能见分晓。如果这个假设被推翻,我将学到信息架构中该舍弃什么。
同伴验证
Q“被推翻的话你会学到什么?” — A“信息量与掌握速度之间的关系。” → 通过
被推翻的瞬间
预期:指标越多越容易掌握 / 现实:塞满全部 12 个指标的第一版界面,3 个人全都答不上“现在有故障吗?” / 学到的:问题不在信息量,而在层级。
Δ 增量:“好界面 = 一样不落” → “好界面 = 一个界面回答一个问题。” 团队贡献:通过 30 秒测试的 v2 拿下黑客松第二名。
下一个循环
面向色觉障碍用户的状态色无障碍 — 带着“红/绿就足够了”这个下一个假设出发。
用 HypoLoop 跑过一个循环了吗?把你的假设原文和增量复盘发送到 leeo [at] kakao.com — 优秀案例将在本页展示。
FAQ

常见问题

产出物质量下降,真的没关系吗?
不只是没关系,这本身就是设计的一部分。因为在 HypoLoop 中被打分的不是产出物,而是学习增量(Δ)。不过,问题本身必须是真的,尝试也必须是真的 — 真实性由层级树来守护。只要每个小挑战都与终极的真正问题血统相连,粗糙的成果就是踏板,而不是玩具。
熟练的专家在这个框架里能学到什么?
规则相同 — 选择自己不会的。只不过专家的“不会的”不是基础技能,而是能放大自身专业能力的相邻领域。对一位十年经验的开发者来说,为做出更好成果所需的设计感觉或市场领域知识,就是他的叶子节点。为了把擅长的事做得更好而习得周边知识,这就是专家的挑战。
没有循环守护者或引导者也能运转吗?
这正是目标。树的分解负责关联性和难度,假设模板负责可验证性,同伴验证仪式负责质量。如果有循环守护者,其角色也不是干预,而是照看这套结构是否运转良好的基础设施管理。学习小组或小团队完全可以在没有守护者的情况下,仅靠同伴验证起步。
团队成果与个人学习冲突了怎么办?
个人学习优先。这不是例外条款,而是框架的身份认同 — HypoLoop 不是解决问题的框架,而是学习的框架,而学习最终必须发生在个人身上。正因为这条原则,承担陌生的部分不是给团队添麻烦,而是正确的使用方式
一个人也能用吗?
可以。把团队层设为“我想做出的真正成果”,把它分解成层级树,再在每个叶子上运转假设循环即可。同伴验证可以由学习伙伴、社区,或留给未来自己的记录来替代。核心 — 在学习之前先写假设 — 在独自一人时同样有效。
能与现有的挑战式方法论一起使用吗?
HypoLoop 不是某种方法论的改良版,而是独立框架;但它继承了挑战带来的动机能量,因此可以用在挑战式课程之上叠加个人学习层的方式结合。不妨从把现有的团队挑战设为终极挑战,再加入树的分解和个人假设循环开始。

这里没有回答的问题,请发送至 leeo [at] kakao.com — 好问题会被加入这个列表。

在下一个项目中,
建立你的第一个假设

你需要的,只是一个真正的问题、一张树,和一个做好了被推翻准备的假设。

想试用或有疑问?— leeo [at] kakao.com