先把选项摆上画布，再问 AI

当一个决定真有两三个选项时，把整团乱麻贴进 Claude Code 或 Codex，是最贵的一种想。你拿到一段流畅回答，里面混着你的约束和模型的默认值，事后还得自己把取舍再拼一遍。在 BaseHalf 画布上，便宜的那一步可以先做：把问题、约束和每个选项摆到眼睛能对照的位置。等板上已经看得出什么重要了，再问 Agent。

一个具体的取舍

假设你要给一个小型桌面工具加离线草稿。三种存储形态反复出现：

1. 用户已有文件夹里，一篇草稿一个 Markdown 文件。
2. 本机 SQLite，一张 drafts 表。
3. 单个 JSON 文档，每次保存整文件重写。

没有哪一种荒唐。每一种会在不同约束上翻车。任务不是「问 AI 哪个最好」，而是对照同一份清单并排看选项，再让 Agent 只压测其中一块。

把问题摊成卡片

用 BaseHalf 打开项目文件夹。建短笔记当卡片，别写长文：

• problem.md：一段话：离线草稿要扛得住崩溃，并且不用专用查看器也能打开。
• constraints.md：真正绑住你的几条：必须离线可用、优先用户用任意编辑器就能打开的文件、v1 不想碰迁移、同步故事保持无聊。
• 每个选项一张：option-markdown-files.md、option-sqlite.md、option-json-blob.md。各自写清想法、你已信的好处、你已怕的失败方式。
• open-questions.md：还没答的问题（半写完就崩怎么办、备份长什么样、同事在 git 里 diff 到什么）。

像白板一样拖开。问题放上面。约束在左列。选项横排中间。问题卡放在它威胁到的选项下面。这套摆法是给你看的。卡片位置和尺寸写在 .bh/ 下，通常不进 git，所以边想边挪不会变成合并冲突。

布局不是可持久的图

这块板上其实在做两件不同的事。

视觉组织是卡片坐在哪。它帮你分组、对照、发现缺口。是给眼睛的座位。一般留在本机 .bh/。

Upstream 连接是你画出的线，表示一张卡片的上下文流入另一张。BaseHalf 把它们写成文件里的纯文本列表（Markdown frontmatter，或其他文件类型在 .bh/ 下的 mirror）。Git 看得到。下一次 Claude Code 或 Codex 会话也看得到。这才是该留下来的上下文。

不要把每一次空间分组都当成语义链接。三个选项横排，并不等于它们互为 upstream。只有上下文真该流动时才连线，比如把 constraints.md 连进每个选项笔记，把 open-questions.md 连进你马上要测的那个选项。一条线表示 A 喂给 B。它不是思维导图标签，不是自动知识图谱，也不能代替卡片里的正文。

先用空间比较，再收窄提问

选项横排、左边同一列约束时，缺口会很快露出来。Markdown 文件在可检查性和 git diff 上赢；你还欠自己一个半写崩溃的答案。SQLite 在事务式落盘上更稳；你还欠「用户能不能不用我们的 App 打开草稿」。JSON 整包看起来简单，直到双写和半写保存出现在问题卡上。

选你要帮忙的那一块。也许只是：「在这些约束下，如果选 Markdown 文件、进程写到一半挂了，最先坏的是什么？」选中该选项卡，加上 constraints.md 和相关问题。选中内容进入 Agent Area，Claude Code 或 Codex 看到的是你挑中的相关内容，不是整块板，也不是下周你会忘了贴的那段 prompt。

有了回答之后写什么

留下让下个月更省事的部分：决定、理由、以及你否掉的选项。写成短笔记，用 upstream 把约束和胜出的选项连进去。被否掉的头脑风暴卡可以留着，也可以删。别把每一个空间簇都升级成永久连接。

边界

这是在花一次模型调用之前，用文件夹想清楚的办法。它不会替你发明选项，不会用假指标打分，也不会把画布变成自动决策树。约束写错了，板子再整齐也只会整齐地选错。画布让取舍可见；拍板仍然是你的。

先把问题摊开。空间布局给自己看。只有该留下的上下文才写进 upstream。再选中 Agent 该看到的部分，然后才问。