先把问题和方案分开放，再做选择
把实际出问题的事情放在 BaseHalf 画布的一边，把已经有人提出的方案放在另一边。只有属于这条指定问题的问题卡才连上去，再把那一切片选给 Claude Code 或 Codex。
一句抱怨砸进频道，几乎同时跟来三个方案。人很容易把这一堆贴进 Claude Code 或 Codex，问该做哪一个。模型会很流畅地把一个尚未落地的方案，当成对问题本身的描述。更便宜的功夫在更前面，而且是视觉上的：先把实际发生的事放在板子的一边，把已经有人提出的方案放在另一边，然后再请任何人做选择。
这和把一团雾摊开、直到能给问题起名字，不是同一步；也和把选项对着清单并排放好、把原话和一次跳跃分开、或把事实、假设和未决问题分开不同。这里的抱怨已经带着答案一起出现了。风险在于：一个方案已经被归档成了问题本身。
「分享太难了」
假设一款本地优先的桌面笔记应用，正在频道里收到这样的抱怨。旁边，人们已经收集到实际发生过的事：
- 有人把一个 Markdown 文件发给一位不用这款应用的同事。对方要的是一份 PDF，或一个链接。
- 一次站会上，不在那台会议电视上安装桌面应用，笔记就显示不出来。试了五分钟，会议就往下走了。
- 两位同事周末各自改了一份同一则笔记的副本，周一用了一上午手工合并。谁也没有被锁在外面，他们只是不知道对方手里还有一份。
这些是问题。它们还没说该做什么。旁边，频道里已经有方案了：
- 加一个能在浏览器里打开的公开分享链接，这样没有安装应用的人也能读到笔记。
- 加一个「发送副本」按钮，用邮件把 PDF 发出去。
- 加实时多人编辑，让两个人同时改同一则笔记。
分享链接的故事很整齐，对那位同事和那间会议室，它很可能就是该先做的修复。可它对周末那次合并毫无帮助。多人编辑的故事也很整齐，它瞄准的是另一种失败。如果你把那句抱怨和三个方案贴进同一个 prompt，你会得到一份流畅的建议，把两个问题和三个方案混成同一个决策。
两堆，不要一份简报
用 BaseHalf 打开项目文件夹。每个文件都会变成一张卡片。写短笔记，一张只放一个想法：
context.md：抱怨刚到时的原样，此外什么都不写：不是一份诊断，也不是一份计划。- 问题：
problem-coworker-no-app.md、problem-meeting-projector.md、problem-two-editors.md。只放人们碰上的事。这些卡片上不要写「所以我们应该做分享链接」。 - 已提出的方案：
sol-share-link.md、sol-email-copy.md、sol-realtime-multiplayer.md。每一张都明确写明：这是一个提出来的修复，不是对问题的重述。 ask.md：你终于愿意拿去问 Agent 的那个问题，比如：「那位不用应用的同事，和会议电视上看不到笔记，看起来是同一个问题：没有这款应用的人看不见笔记。周末那次合并是另一个问题。板上这些方案里，哪些其实在处理前一个，哪些该等这个问题被起了名字再谈？」
像白板上的纸条那样拖开。情境放上面。问题堆在左边，已提出的方案堆在右边。要问的那句话放底部，坐在可能真正属于它的那些问题卡下面。每堆顶上放一张短标签，能帮眼睛把两种句子分开。这套摆法是给你看的。卡片位置和尺寸写在 .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:。如果这次要问的不是周末那次合并，也不是多人编辑那个方案，就先别连它们。坐在左边那一堆，只是一种直觉：这张卡是问题。一条线才是在说：上下文会流过去。
选那一切片，不要整块板
你不是在问「分享该怎么修」。你是在问：你到底先在解决哪一种分享失败，以及这些方案里哪些其实在处理那一个。
选中那张问题卡，再加上属于它的那两张问题卡。如果这一轮想让模型先把问题说清楚、再去排方案，就先别选周末那次合并和那三个方案。拖一个方框，或按住 Shift 再点，就能组成这个集合；板子上其余的卡片可以仍看得见，而不被倒进 prompt。选中的内容，才是 Claude Code 或 Codex 这一问在 Agent Area 里能看见的。BaseHalf 本身不是 Agent。
然后问。不要问「我们该交付哪个方案」。请模型判断那两种失败是不是同一个问题，以及板上哪些方案真正跟它有关。
回答之后留下什么
留下那条指定的问题、真正该被放在一起的那些问题卡，以及一则短笔记：哪些方案在这个框架下还站得住。如果它们还该一起走，就保留或调整上游列表。一个瞄准了另一种失败的方案，可以留在板子上、待在自己那一堆里，留给下一问。不要只因为左边那些失败曾经坐在一起，就把整堆都升级成永久的连接。
限度
把两堆分开，并不能让问题清单变得完整，也不能保证你挑对了该考虑的方案。如果那位同事其实已经有一种能用的导出，真正的痛其实是周末那次合并，你就会拿一个整齐但错误的框架去做压力测试，模型也会流畅地回答它。画布让这种混在一起的情况变得看得见。到底哪一种失败摊在桌上，还是得你来决定。
先把问题和方案分开放，再做选择。只有该跟着那条指定问题走的切片，才写成上游。选中那一切片，然后再问 Agent。