事情的起点很小：我在写一个技术文档，想插一张流程图，打算用 Mermaid 语法来画。
Mermaid 语法本身不复杂，但有一个很让人抓狂的地方——你写完代码，不知道渲染出来长什么样，得提交到 GitHub 或者粘贴到某个预览工具里才能确认。
这个「写 → 切换工具 → 看效果 → 切回来改 → 再切回去」的循环，我重复了大概十几次，把一张流程图弄了将近一个小时。
我去找有没有更好的工具
搜了一圈，发现现有的在线 Mermaid 编辑器大概分两类：
功能强大但太重：集成了项目管理、团队协作、历史版本，打开一个流程图编辑要先登录账号、选工作区、新建项目……我只想画一张图，用不到这些。
轻量但功能残缺：只能预览，不能导出 PNG，或者导出的图分辨率很差，放到文档里模糊。
我真正想要的东西很简单：
- 打开就能用，不登录
- 写 Mermaid 代码，实时看到渲染结果
- 看完之后能导出一张清晰的图
就这三件事，没有一个工具做到我满意。
我发现这个需求比我想的普遍
当时我在几个技术交流群里随口问了一下，「你们画流程图用什么？」
回答五花八门：有人用 draw.io、有人用 ProcessOn、有人用 Figma、有人直接用 PPT 的流程图功能。
用 Mermaid 的人不多，但他们遇到的困境和我一样——Mermaid 用在文档里很方便，但缺一个顺手的编辑器。
更有意思的是，一些不用 Mermaid 的人告诉我为什么：「听说 Mermaid 挺好用的，但不知道怎么验证自己写的对不对，就没学。」
这让我意识到，一个好用的在线编辑器，可能是很多人入门 Mermaid 的门槛。
我想清楚了这个工具要解决什么问题
不是「提供 Mermaid 预览功能」——这太宽泛了。
真正要解决的问题是：让写文档的人能快速验证自己写的 Mermaid 代码是否正确，然后顺手导出用。
用户坐下来的心态是：我有一个图要画，想快点搞定，不想折腾工具本身。
所以设计的原则就是：工具本身越透明越好，用户的注意力应该全部在「图」上，而不是在「工具怎么用」上。
具体来说：
- 左边写代码，右边实时渲染，不需要点「预览」按钮
- 支持所有 Mermaid 图表类型：流程图、时序图、ER 图、甘特图……
- 导出 SVG 和 PNG 两种格式，PNG 可以直接贴进文档或 PPT
- 不登录，不注册，打开即用
做完之后我发现用的人比预期多样
本来以为用户主要是写技术文档的开发者。
但后来从反馈里发现，用这个工具的人分布比我想的广得多：
- 写 README 的开发者：GitHub README 支持 Mermaid，但没有本地预览，需要反复 push 才能看效果，有了在线编辑器就能先验证
- 做技术分享的人：准备演讲或者写博客，需要快速出一张架构图或者流程图
- 产品经理：需要和研发对齐流程，但不懂代码——Mermaid 语法比想象中容易学，有了实时预览之后上手快多了
- 学生：写毕业论文或者课程报告，需要画 UML 图，不想装 Visio
这些人有一个共同点：他们都需要「图」，但不需要「专业图表软件」。
我从这个工具里学到一件事
做工具之前，我定义需求的方式是「这个工具提供 X 功能」。
做完之后，我意识到更准确的定义方式是：「这个工具帮助一类人，在某个具体场景下，以最小的阻力完成某件事。」
Mermaid 在线编辑器不是「一个支持 Mermaid 渲染的 Web 应用」，而是「让写文档的人能在 5 分钟内画完一张流程图并导出」。
这两种定义方式，会导致完全不同的设计决策。前者关注功能清单，后者关注用户的完成状态。
用「用户最终想达到什么状态」来定义工具，比用「工具提供什么功能」来定义，做出来的东西通常更顺手。
