sticky-markdown-note

这是什么#

一个常驻菜单栏（不占 Dock）的悬浮 Markdown 便签：全局快捷键 ⌥⌘N 随处速记，无边框透明圆角窗口，可置顶、可调透明度、五种配色。便签多了之后进管理器归类归档。

为什么不用现成的#

需求是**“需求砸过来时 3 秒记一条”**——这个”3 秒”就是全部理由。

现成的笔记应用（系统自带便签、各类知识库工具）都要经过”切到应用 → 找到位置 → 新建 → 开始打字”这几步。当你正在写代码、有人过来说一句”那个接口记得加个鉴权”，这几步足以让你要么打断心流、要么干脆不记。

所以设计目标只有一个：从任意应用里，一个快捷键直接出现一张能打字的便签。 其余功能都是围绕它长出来的。

三个设计决策#

① 存纯 .md 文件，元数据另放 sidecar。

便签内容直接存成 ~/Documents/StickyNotes/ 下的 .md 文件——人肉可读、可 grep、可用任何工具备份，不被这个应用锁定。而窗口位置、配色、置顶状态这类元数据存在单独的 index.json 里。

分开的理由是两者性质完全不同：内容需要长期可读、跨工具通用；元数据只对本应用有意义、格式随版本变。混在一起（比如给 md 加一堆 frontmatter）会让文件对外部工具变难读，而这恰好是选 Markdown 的初衷。

这个判断和我在 Agent 工程系列讲记忆分层时的结论同构：判据不是”怎么标”，是”怎么用”——用途不同的数据分开存，各选各最合适的形态。

② 预览态可直接勾选，按源码行号写穿回文件。

Markdown 渲染出的复选框通常是只读的，要勾选得先切到编辑模式改 - [ ] 为 - [x]。这里做成了预览里直接点：点击时按源码行号定位回原文件那一行改写。

多做这一步是因为待办清单的主要交互就是勾选——如果每次勾选都要”双击进编辑、找到那行、改一个字符、点回预览”，这个便签就退化成了只读展示板。

③ 从 Electron 重写为 Tauri。

初版是 Electron。重写的直接动机是体积与常驻开销——一个”常驻菜单栏、随时弹出”的小工具，本身就要求足够轻；Electron 每个窗口带一份浏览器运行时，对这个场景是数量级的浪费。

代价是要写 Rust 侧的原生集成（窗口管理、全局快捷键、菜单栏），以及为旧版用户做一次性的笔记导入。

我的判断与适用边界#

我把它限定为“快速捕获和短期提醒”，不把它扩展成完整知识库。双向链接、多人协作、复杂检索和跨设备同步都很有价值，但会改变启动速度、数据模型和交互重心，也会削弱一个快捷键立即记录的核心体验。

需要长期整理的内容应进入正式文档或知识库；便签只负责降低记录动作的阻力。这个边界也决定了为什么正文坚持使用普通 Markdown 文件：即使应用停止维护，内容仍能被其他工具继续处理。

其它细节#

• “勾选框 + 代码块”自动合并成一张卡片——为账号切换这类场景做的：勾选表示”当前在用”，不划线（划线语义是”已完成”，在这里不对）
• 格式工具条 + 快捷键（⌘⌥1/2/3 标题、⌘⇧8/7/9 列表），回车自动接续列表
• 支持一次性导入旧版笔记