花了一个下午重新梳理 myblog-need-intent 的设计，终于把六个 intent 的职责理清楚了。

以前的设计是每个 intent 各干各的，边界模糊。这次把它们分成了两类——配置类（post、idea、draft、open）只管设置状态，设完就用 user-error 终止；动作类（put、delete）才真正走到 yes/no 交互，执行上传或删除。这个切分很干净，配置类是"选择"，动作类是"执行"，互不纠缠。

但有个问题很有意思。配置类 intent 用 user-error 来终止函数流——这在 Elisp 里是标准做法，相当于"好了，活干完了，后面的代码别跑了"。但 Emacs 的 condition-case 会把 user-error 包裹成 progn 前缀显示给用户，看起来就像出错了一样。实际上什么都没错，函数已经正确完成了它的工作。这种"信号正确但呈现错误"的情况，在写 UI 交互的时候特别常见——底层逻辑是对的，但用户看到的东西产生了误解。

这让我想起老系统里那些日志。有时候运维看到一条 ERROR 日志就很紧张，但其实那条日志只是记录了一个正常的业务分支——比如"用户权限不足，拒绝访问"。从系统角度看是正常行为，从运维角度看像出了 bug。信息在不同层面流转的时候，含义会变。写代码的人知道自己在做什么，但用的人不知道。好的设计不仅是逻辑正确，还得让信息在每一个层面都表达得当。

说回 F6 的交互。按现在的设计，发一篇 idea 需要按三次 F6：第一次选 idea 切目录，第二次选 draft 翻草稿状态，第三次选 put 真正上传。每次只做一个原子操作，完了就停。这个节奏其实不错——每一步都明确，不会误操作。但 user-error 那个 progn: 前缀确实得想办法藏掉，不然每次都像踩了个地雷。

写到这儿突然觉得，这种"多次按键完成一个流程"的设计，有点像 Emacs 的很多内置命令——不是一键到底，而是一步步引导。可能这就是 Emacs 用户的审美：精确控制每一步，而不是把一切都交给一个黑盒按钮。

写碎碎念有个好处：不用考虑结构，不用画架构图，想到哪写到哪。今天就到这儿吧。