Vibe Coding
这些不是演示项目。它们每天在我自己的工作流里跑：改 Keynote、盯自动测试、调编辑器里的输出样式。写它们的过程本身就是一次 Vibe Coding——把「我想要一个能干某件事的命令」讲清楚，让 AI 把代码写出来，再用同一套测试验收。
Keynote CLI · Rust 3.0 · 57 条命令
用命令行读写和编辑 Apple Keynote 的 .key 文件。
改一页标题、换一次版式、批量导出大纲——这些以前只能靠手工点 Keynote。kn 把 57 条命令做成一个 Rust 二进制：大部分操作直接处理 IWA / zip 容器，只有文档模型强制要求时才调用 Keynote 本体。
测试浮层 · DSH 插件 · npm 0.1.1
把自动测试的进展画在被测界面之上。
AI 跑一次 GUI 测试要好几分钟，等的人却不知道跑到第几步、这一步期待什么、现在能不能动鼠标键盘。这块浮层就回答这些：置顶、鼠标穿透、不抢焦点，还会自动挑屏幕上最空的角。
输出呈现设置 · DSH 插件 · npm
把「输出怎么显示」收进一个配置页，改完立刻生效。
过程节点展不展开、代码块多大、模型用什么语言回答——这些琐碎但天天要调的设置，现在集中在一个页面上，不用重启、不用改配置文件。
Markdown 阅读器 · macOS 应用 · SwiftPM
纯本地的 macOS Markdown 阅读器，打开即渲染，不联网。
写完 Markdown 总要「看一遍排版再改」——Markable 就是给这件事做的：原生 TextKit 渲染、只读、不写回源文件；外部改动 2 秒内自动刷新并保持阅读位置，导出 PDF 时直接走本机 md2pdf，拿交付级版式。
怎么做的
这四个工具的做法是一样的：先把约束讲清楚，让 AI 写，再用测试验收，然后每天用、每天改。
不说「做个好用的工具」，而是写清输入输出、失败怎么办、哪些操作绝不能碰源文件。约束越具体，AI 写出来的东西越接近能用的工具。
每个命令都要能被验证：读一个 .key 写出新文件、再读回来比对；浮层要用像素观测工具量，不靠截图猜。测试不过就不算完成。
工具的价值在「天天顺手」。用一周会暴露真实问题，再让 AI 改——这比自己从头写省下的不是打字时间，是想清楚问题的时间。
Vibe Coding