先把已知、假设和未知分开放，再提问
把事实、未经检验的假设和尚未回答的问题在 BaseHalf 画布上分成三堆。只有该留下的才连上这次决策，再把那一切片选给 Claude Code 或 Codex。
一个决策砸进频道，里面混着硬事实、大家已经当真理在用的说法，还有谁都还没回答的问题。人很容易把这一堆贴进 Claude Code 或 Codex，问到底该怎么做。模型会很流畅地把一句猜测和日历上已经订死的安排当成同一种东西。更便宜的功夫在更前面，而且是视觉上的：先把你真正知道的放一堆，把你只是在假定的放一堆，把你还得去查的放一堆，然后再请任何人做选择。
这和把一团雾摊开、直到能给问题起名字，不是同一步；也和把选项并排放好、或把原话和一次跳跃分开不同。这里的问题已经摊在桌上。风险在于：一个假设已经被归档成了事实，一个还空着的缺口已经被跳过去了。
这个季度要不要做公开 API
假设一款本地优先的桌面笔记应用，正在决定要不要在本季度结束前交出一个公开 API。桌上已经有这些：
- 上个月有两位企业客户负责人书面提出要 API 权限。一位想把笔记拉进自己的仪表盘，另一位想从内部表单创建笔记。
- 今天官方唯一的导出方式，是对一个文件夹做手动 CSV 导出。没有成文的 HTTP API，也没有官方 SDK。
- 一场为期四周的性能冲刺下周一就开始，是上次规划会上定下来的。
这些是已知。它们还没说你应该做 API，也没说你做得到。旁边，团队已经把另一些事当成真的：
- 这两位负责人代表一种更普遍的需求：还会有更多客户要同样的东西。可是谁也没去问名单上的其他人，也没数过有多少人已经在用脚本对付 CSV 导出。
- 一层很薄的 API（列出文件夹、读取一条笔记、创建一条笔记）在冲刺之后两周就能做完，含文档和鉴权。这个数字还没有对着现有代码估过。
- 现有的支持人手扛得住 v1 的工单、密钥重置，以及「为什么我的 token 是 401」。谁也没把上一季度的工单量，放到「再加一个 API」的情境里看过。
还有一些问题是空着的：
- 前 90 天里，到底会有多少客户真的去调这个 v1 API？
- 两位负责人是不是都需要一个通用的公开 API，还是一个更窄的导出或写入钩子就够了？
- 如果现在开工，这场性能冲刺是推迟一个月、丢掉一周，还是把团队拆开？
「冲刺之后两周」的故事很整齐。它也可能正是那个一旦不成立、就该在有人动手写路由之前把决策缩小的假设。
三堆，不要一份简报
用 BaseHalf 打开项目文件夹。每个文件都会变成一张卡片。写短笔记，一张只放一个想法：
context.md：桌上的这个决策，此外什么都不写：不是一个 yes，也不是一份计划。- 已知：
know-two-leads.md、know-csv-only.md、know-perf-sprint.md。只放你能指得出来的事实。这些卡片上不要写「所以我们应该做 API」。 - 假设：
assume-leads-are-pattern.md、assume-two-weeks.md、assume-support-ok.md。每一张都明确写明：这是一件你还没检查、却已经当成真的事。 - 仍需要：
need-90-day-demand.md、need-smallest-surface.md、need-sprint-cost.md。只放问题，不放答案。 ask.md：你终于愿意拿去问 Agent 的那个问题，比如：「这些假设里，哪一条如果是错的，会让这个季度的公开 API 被砍掉或缩小？在动到这场性能冲刺之前，用什么最便宜的办法检验风险最高的两条？」
像白板上的纸条那样拖开。情境放上面。已知堆在左边，假设堆在中间，还没回答的问题堆在右边。要问的那句话放底部，坐在可能真的会改变它的事实和假设下面。每堆顶上放一张短标签，能帮眼睛把三种句子分开。这套摆法是给你看的。卡片位置和尺寸写在 .bh/ 下，通过 BaseHalf 自己的忽略文件不进 git（它不会去改你的 .gitignore），所以你可以继续挪这三堆，而不把一个座位表变成合并冲突。
眼睛现在能看见粘贴进 prompt 时会被盖住的东西：三则假设坐在三条事实和三个未决问题中间，而这些卡片里只有一部分跟眼前这个决策有关。
一堆不是一条连接，选中也不是
一旦板子看起来像一张图，有三种动作很容易被混在一起。
| 动作 | 它是什么 | 它是用来做什么的 |
|---|---|---|
| 空间上的一堆 | 卡片放在哪里、有多大，通常写在 .bh/ 下 | 让眼睛把事实、假设和未决问题放在不同的地方 |
| 上游连接 | 文件里的一份纯文本列表：Markdown 笔记是 frontmatter 里的 upstream:，其他文件是 .bh/mirror/<path>/upstream.yaml | 应该留下来、并流入那条指定问题的证据或假设 |
| 选中 | 你为这一问高亮的卡片，用单击、Shift-单击，或拖出一个方框 | 此刻 Claude Code 或 Codex 在 Agent Area 里应当看见的东西 |
坐在一起是一种看的方式。它不是语义关系，也不等于左边每一张都证明了中间每一张。BaseHalf 不会替你分辨已知和假设。是你把它们挪开，直到三种句子不再占同一块地方。
只有当 A 应当继续喂给 B 的时候，才画一条线。ask.md 一经写下，就把「两位负责人」那张、「性能冲刺」那张，以及你想拿来做压力测试的那两条假设连进去，如果这些上下文下周还该跟着这个问题走。Markdown 笔记把这份列表写在文件开头的 frontmatter 里，字段是 upstream:。如果这次要问的不是支持人手够不够、也不是「最小表面」那个问题，就先别连它们。坐在中间那一堆，只是一种直觉：这张卡是假设。一条线才是在说：上下文会流过去。
选那一切片，不要整块板
你不是在问「我们该不该做公开 API」。你是在问：哪些假设一旦不成立，就会让这个季度的这项工作被砍掉或缩小；以及在冲刺被挪走之前，怎样用最便宜的办法检验风险最高的那些。
选中那张问题卡，再加上属于它的那些假设卡。如果「两位负责人」是这些假设所依靠的事实，就把它也加进去；如果这一轮还不想让模型去评支持人手和那些未决问题，就先别选它们。拖一个方框，或按住 Shift 再点，就能组成这个集合；板子上其余的卡片可以仍看得见，而不被倒进 prompt。选中的内容，才是 Claude Code 或 Codex 这一问在 Agent Area 里能看见的。BaseHalf 本身不是 Agent。
然后问。不要问「写一份 API 计划」。请模型指出：这些假设里，哪一条一旦倒掉就会真的改变决策；以及要检查它们，怎样才算够。
回答之后留下什么
留下那条指定的问题、被证明真正要紧的那些假设，以及一则短笔记：每一条是站住了、被降级了，还是仍待检查。如果它们还该一起走，就保留或调整上游列表。一条被推翻的假设，可以改写成已知里的一条更正，或留在原处当作提醒。不要只因为左边那些事实曾经坐在一起，就把整堆都升级成永久的连接。
限度
把三堆分开，并不能让已知变得完整，也不能保证你挑对了该检验的假设。如果那两位负责人其实已经被答应过「会做」，或者那场冲刺根本没有笔记里写得那么锁死，你就会拿一个整齐但错误的框架去做压力测试，模型也会流畅地回答它。画布让那个还没做的检查变得看得见。检查本身，还是得你去做。
先把已知、假设和未知分开放，再提问。只有该跟着那条指定问题走的切片，才写成上游。选中那一切片，然后再问 Agent。