最底层
Copy-paste 做的事：从 context A 提取信息，注入 context B。
操作系统给这件事准备的工具，是一个单槽位、易失性的中转缓冲区。只留最后一条。新的进来，旧的就没了。它甚至不是队列，是一个永远只有一个元素的寄存器。
这套设计匹配一种使用方式：1:1，且阅后即焚。复制一个，粘贴一个，继续工作。大多数时候，这就够了。
根本矛盾
信息复用并不是严格顺序的。你经常需要：
- 从 A 取多条，再到 B 逐条贴（多槽位）
- 昨天复制的东西今天还要用（持久化）
- 同一段文字反复贴（常驻片段）
这三个需求共享同一个交互原语（copy / paste），也共享同一个 UI 需求（快速找到）。所以它们会挤进同一个产品。Paste 成立，是因为它覆盖了这些例外，同时保住了零摄入成本。
本质抽象
Hamu 的本质不是 clipboard manager，也不只是 snippets manager。
它是以剪贴板为零成本摄入口的个人信息缓存。
Copy 这个动作本身是一个隐式信号：「这段信息值得提取」。系统剪贴板把信号用完就扔。Hamu 把信号留下来——把 transfer buffer 变成 capture trigger。
摄入成本必须继续是零。一旦要求你主动输入、建目录、写标题，它就变成了一个更差的笔记应用。笔记和 Hamu 的分界线在这里：笔记要你组织；Hamu 是被动捕获。
1:1 仍然是主流
把寄存器加成无限且持久，并不是要改掉 1:1。
大多数人还是：复制一个，粘贴一个。Hamu 的价值不在于改变这个节奏，而在于那些低频、高痛的例外：
- 回溯 — 刚复制的被下一条盖掉了。
- 批量中转 — 两个文档之间搬很多小块。
- 历史召回 — 周二那条链接、上周那段地址。
- 常驻 — 每天都要贴的固定文字。
更准确的描述：把一个只服务于「这一次 paste」的寄存器，变成一条保留所有 copy 的时间线，让任意历史时刻的 copy 都能被未来任意次 paste 消费。从 1:1 到 1:N。从瞬时到可持久。
Board 做成横向时间线，是在暗示：你的剪贴板有时间维度。
transient 和 resident
被复制的信息分两类。
Transient 中转一次就完，应该待在 History，用完可以忘，也可以被上限清掉。
Resident 会反复用。升级方式是 Move 进 Collection，不是 Pin，也不是再复制一份。一条 Item 只在一个位置。
Resident 再往上，就是笔记和知识库。Hamu 停在这条线之前。越过它，摄入成本不再为零，产品会输给任何一本正经的笔记软件。
为什么规则在模型前面
分类不是为了「看起来智能」。是为了检索时少翻。
最便宜、最确定的信号先决定：图片就是 image，文件就是 file，微信 / QQ / 飞书复制进来就是 chat，整段 URL 就是 link。模型只处理剩下的 code / article / other。这样链接和聊天不会被模型误分。
超越中间层
Paste 优化的是 copy 和 paste 之间的缓存。它没有质疑这两个动作本身。
要越过它，得打破隐含假设：
- 摄入 — 为什么必须等用户按 Cmd+C？「看到有用的东西」可以被检测。Hamu 现在用 ⌘⇧2 让用户自己划，而不是后台窥屏。噪音过滤是这一层的真正难点。
- 输出 — 为什么必须打开面板去翻？当前应用 × 实体类型，一层浅规则就能推。从 pull 变成 push。
- 粒度 — 为什么按整块存？电话、日期、地址、金额可以从 blob 里拆出来。检索变成找那个号码，而不是找那段话。
- 最远的一层 — 消灭 copy-paste：人不再做数据管道，源和目的地直接连上。
Hamu 现在停在最短路径：copy 摄入 + Board 召回 + 手动 paste。结构化拆解、上下文推荐、被动窥屏，都是后面的增强，不是第一天要铺满的表面。