把 9 次点击变成 0 次：一位开发者如何把 Excalidraw 变成博客配图流水线
从“画图很爽”到“导图很烦”，技术写作者的老问题又被翻出来了
如果你写过技术博客，大概率体验过一种很拧巴的时刻：文字已经快写顺了，图却还在拖后腿。一个箭头的位置、一段标签的长度、一个框的边界，改动看似很小，却足以让整篇文章的表达逻辑跟着变。图和文从来不是各管各的，尤其在技术写作里，图往往不是装饰品，而是论证的一部分。
开发者 Martin Lysk 最近分享了自己的解法。他平时常用 Excalidraw 梳理技术问题、给同事解释架构，后来又把它用到博客配图里。问题也随之暴露：每次修改一张图，都要手动导出一遍；如果博客还要兼容浅色和深色模式，那就得再来一遍。选中 frame、点击导出、输入文件名、切换主题、再导一次，最后还很可能发现有个标签刚好越界，于是从头再来。整套动作大约 45 秒，不算长，但足够让人烦。
这件事乍看很小，像是典型的“程序员嫌麻烦所以造轮子”。但我反而觉得，它非常典型地戳中了今天独立开发者和技术写作者的一块共同痛点：创作的真正阻力，很多时候不是不会写，也不是不会画，而是工具链中那些反复、机械、打断思路的细枝末节。人一旦被这种微小摩擦打断几次，表达欲就会明显下降。
他没换工具，而是把工具改了
Lysk 一开始的思路很符合工程师本能：既然手动导出麻烦，那就把这件事丢给自动化。他先做了一个 GitHub Action，检查最近提交里变更过的 .excalidraw 文件，解析其中的 frame，然后自动导出深色和浅色两套 SVG，再提交回仓库。借助开源工具 excalirender，这条流水线很快跑起来了。
这套方案并不难理解，也很“DevOps”：有变更，触发构建，生成产物，回写仓库。对于很多工程团队来说，这已经是很自然的做法了。可它的问题也马上出现。其一，渲染库本身有 bug；其二，流程依赖 x86 Docker 镜像，而他用的是 ARM 架构的 Mac，本地根本跑不顺。结果就是，明明想解决“导图麻烦”，却变成了“必须先 push 到 GitHub，等 CI 跑完，再 pull 回来才能看效果”。
这就很讽刺了。自动化本应缩短反馈链路，结果却把一个本地创作问题，绕到了远端流水线上。对写作者来说，最重要的不是“最终可以生成图片”，而是“改完马上能看到图片”。创作工具和构建工具最大的区别，就在反馈速度。前者必须贴手，后者可以晚一点。把两者混在一起，常常会让体验变形。
于是他换了一个更聪明的方向：不是在 Excalidraw 外面补一层自动化，而是直接把自动导出能力塞进 Excalidraw 的 VSCode 扩展里。
一个 frame 命名规则，换来本地实时预览
新的工作流很简单，甚至有点优雅。用户只需要把想导出的内容框进一个 frame 里，再把 frame 命名为 export_图片名。扩展监听 .excalidraw 文件变化后，就会自动识别这些 frame，并在同目录下生成两份 SVG：${image_name}.light.exp.svg 和 ${image_name}.dark.exp.svg。
这意味着什么？意味着技术作者终于可以像写代码那样写图文：一边调整图，一边在本地预览文章；一边修改文章表述，一边即时确认对应配图是否还成立。导出的图片就在项目目录旁边，编辑器还能自动补全引用，Markdown 预览里也能立刻看见效果。这个体验上的提升，远比“省了 45 秒”更重要，因为它真正减少的是上下文切换。
我很喜欢这个思路的一点在于，它没有试图发明一个全新的内容平台，也没有把 Excalidraw 改造成“下一代博客系统”。它做的只是把创作过程里最讨厌的一段缝补平。很多好工具的价值就在这儿：不是惊天动地，而是把人从重复劳动里偷偷救出来。
放到更大的背景里看，这其实也是近两年开发者工具演进的一个缩影。过去我们更关注编译速度、部署效率、云原生流水线；现在越来越多人开始认真打磨“个人创作工作流”——文档、笔记、示意图、知识库、博客、演讲稿，这些过去被视为“非生产代码”的环节，如今也被纳入自动化和工程化的改造范围。写作本身，正在变成一种可编排的开发流程。
为什么这件小事，在今天尤其有意义
Excalidraw 这几年之所以受欢迎，不只是因为它“手绘风”好看，更因为它恰好踩中了技术表达的舒适区。对工程师来说，它比传统设计软件轻，负担小；比截图和 PPT 灵活；又不像 Figma 那样天然带着设计协作的门槛。很多人用它并不是为了做精致图，而是为了快速解释一个系统、一个协议、一次故障路径。
而当越来越多工程师开始写博客、做公开分享、经营个人知识输出时，图文协同就变得更关键了。你会发现，真正阻碍大家持续输出的，常常不是缺少观点，而是这些看似不值一提的小摩擦：图片命名乱、暗色适配麻烦、局部修改后懒得重新导出、预览环境和发布环境不一致。久而久之，人就会对“再改一版”产生心理抗拒。
Lysk 的这个改动，刚好提供了一个很有代表性的思路：不要把创作环节当成发布前的附属工序，而要把它当成第一现场来优化。尤其在 VSCode 成为事实上的“超级编辑器”之后，越来越多写作者其实已经在同一个环境里处理代码、文档、图示和静态站点。如果 Excalidraw、Markdown、预览器和导出工具能形成更紧密的闭环，那技术写作的体验会被整体抬高一个台阶。
当然，它也提出了一个挺现实的问题：这种功能应该留在个人 fork 里，还是应该进入官方扩展？Lysk 自己的态度很克制。他提到自己不太想直接提 PR，因为不想背负维护责任，更倾向于提 issue 把问题和思路说清楚。这其实很能代表开源世界里一个常见又微妙的处境——很多好点子并不是缺实现，而是缺长期维护者。功能做出来不难，难的是谁来接住它。
工具越来越聪明，但“作者感”不能被自动化吞掉
我认为这件事最值得玩味的地方，不在于自动导出本身，而在于它提醒我们：好的创作工具，应该努力隐身。它最好像空气一样，平时感觉不到，一旦缺席你就浑身难受。自动导出、双主题生成、本地实时预览，这些能力之所以有价值，不是因为它们炫，而是因为它们让作者能更专注于表达本身。
不过，自动化也有边界。比如，当图示的生成越来越顺滑，人会不会反而过度依赖图，而忽略文字的严谨？又或者，当一切都可以被流水线化之后，博客是否会进一步朝“工程产物”而不是“个人表达”倾斜？这不是 Excalidraw 一家的问题，而是今天所有创作工具都要面对的张力：如何在提高效率的同时，不把内容做成冷冰冰的流水件。
从行业角度看，这种围绕个人工作流的“小而美”创新，未来很可能会越来越多。Notion 有自己的数据库化表达方式，Obsidian 靠插件生态把笔记变成操作系统，Figma 与 FigJam 试图统一设计与白板，Excalidraw 则站在“轻量解释工具”的位置上持续生长。它们竞争的已经不只是功能，而是谁更懂创作者在哪一秒最容易被打断。
所以，这篇分享真正有趣的地方，不是“某位开发者周末用 Claude 写了个扩展”，而是它再次证明了一件事：当 AI 降低了写插件、改工作流的门槛后，越来越多过去忍一忍就过去的痛点，会被直接消灭。我们或许正在进入一个“每个人都能给自己的创作流程打补丁”的时代。那会让内容生产更高效，也会让工具生态变得前所未有地碎片化、个性化。
这到底是好事还是麻烦？我倾向于认为，短期内它肯定是好事。因为真正稀缺的从来不是工具统一，而是表达冲动别被琐事磨没了。至于后续会不会出现维护分裂、插件兼容、工作流绑架，那是下一阶段才会集中爆发的问题。
眼下来看，把 9 次点击变成 0 次，已经足够让很多技术作者心情变好了。别小看这点心情，它往往就是下一篇文章能不能写出来的分水岭。