我为什么制作了一个 Markdown 编辑器 VMark？
笑来约 14 分钟其实，制作 VMark 的过程，是我自己的一个学习和体验的过程。
我从 2025 年 8 月 17 日开始尝试 vibe coding 这个新兴的编程潮流。vibe coding 这个词汇是在 2025 年 2 月 2 日首次被创造并传播的，最早来自于 Andrej Karpathy 在 X（x.com）的一个帖子。
Andrej Karpathy 是一位在机器学习领域颇具影响力的研究者与科普教育者，他曾在 OpenAI 和 Tesla 等知名公司担任重要职位，并创办了 Eureka Labs 专注于 AI 原生教育项目。Karpathy 的这条推文不仅提出了 “vibe coding” 的概念，而且迅速在技术圈内广泛传播，引发了深入的后续讨论。
等我注意到并开始使用 Vibe Coding 工具的时候，已经是半年之后了。当时 Claude Code 的版本还是 1.0.82，而我开始写这个文档的时间是 2026 年 2 月 9 日，版本号是 2.1.37，期间已经有 112 次版本升级……
最早的时候，我只是用它帮我强化一些很久以前写过的自动化脚本，比如，批量翻译电子书什么的…… 我发现自己只是用它放大自己原本已有的能力而已。
原来会做什么，那么 AI 帮助我做得更好；原来不会做什么，那么 AI 会给我一个假象，好像我也能做似的，但，常常是让我 “哇哦” 一下之后，然后就没有了 —— 原来不会做的，实际上依然不会做。那些漂亮的图片，令人眼前一亮的视频，甚至洋洋洒洒的文章，其实只不过是新时代里的另外一种表现形式的 “Hello World”。
我也不是完全不懂编程。但，我肯定不是什么真正的计算机工程师。我顶多算是普通用户里的 Power User —— 我懂一点代码，甚至出版过一本关于 Python 编程的书籍。但，这并不等于我是工程师。这就好像一个能盖草房的人，虽然比不会盖草房的人多懂些技术，但和那些能设计大厦或者桥梁的人，完全不是同一个物种一样。
然而，AI 改变了这一切。
从一开始到现在，虽然各种 AI Coding Cli 我都尝试过，Claude-Code, Codex-Cli, Gemini-Cli，甚至，非官方的 Grok-Cli，以及各种开源替代，比如 Aider 等等。然而，其中用的最多的，总是 Claude-Code…… Codex-Cli 提供了 MCP Server 之后，我用 Claude-Code 更多了，因为可以让它在 Interactive Mode 里直接调用 Codex-Cli……奇怪的是，首先提出 MCP 协议的 Claude-Code 却没有提供 MCP Server 功能（截至：2026/02/10）。
最初的时候，Claude-Code 对我来说，更像是个家里突然多出来的一个以前只有大公司里才有的专业 IT Guy，家里关于计算机的任何事情都可以交给它 —— 它会用我之前完全没见过的命令行指令，或者我之前见过的命令但没见过的使用方式，解决一切问题。
只要给它足够的权限，它几乎没有不能做的事情，维护更新，联网设置，部署各种有着无数特殊设置难以解决冲突的软件或者服务…… 这种 “人” 可绝对不是 200 美金一个月就可以雇来的啊！
有了它之后，我使用的机器数量开始增加，云端的机器从一两个增加到五六个，家里的机器从两三台变成七八台…… 以前要花好几天设置并且还常常因为自己的知识能力有限而出现的各种问题，突然之间消失了，它可以帮我做一切机器运维，并且，解决完问题之后，还可以制作自动启动的脚本，确保将来不出现同样的问题……
然后，我开始尝试写一些以前写不出来的东西。首先是个浏览器插件：Insidebar-ai，用来减少我在浏览器里那些反复切换和拷贝粘贴。然后是个看起来像真正的软件一样的 Tepub，是一个 Python 命令行程序 —— 帮我翻译 epub 书籍（单语版/双语版），或者为 epub 书籍制作有声版 Audiobook。在此之前，我只能用手写的笨拙的 Python Script。
我感觉自己就好像是个穿搭博主突然之间有了裁缝的本事，甚至在这个工业时代里，连纺织厂都是自己的一样。无论之前觉得自己的品味如何，在不经意之间了解了更多其他相关领域或者底层领域之后自然而然且又不得已改变了很多观念一样。
我决定花几年时间把自己变成真正的计算机工程师。
类似的事儿我以前做过。我曾在新东方教过多年的阅读课，讲了几年之后，起码在阅读方面，我把自己变成了 English Native —— 口语非常差，可怎么办呢？也没地方用得着…… 于是就那样了。
其实也不图什么，只是练练脑子 —— 这是最有趣的游戏，不是吗？
我决定每周做一个相对小一点项目，每个月做一个相对大一点的项目…… 如此这般几十个项目做过之后，我猜我应该变成另外一个人了吧？
三个月后，我做了大大小小十几个项目，也有失败的，也有搁置的，但都有趣极了 —— 在这个过程中，AI 在以肉眼可见的速度变得更聪明…… 如果不是直接高密度使用的话，真的不太有这种具体的感受，顶多是 “道听途说” 而已。然而，这很重要，因为这种感受直接决定了一个我一会儿会深入讲解的 AI 使用哲学：“笃信 AI 会越来越聪明”。
2025 年 11 月，我写了一个基于 foliate.js 的 epub 阅读器，把它设计成了我自己喜欢的样子，实现了很多 Kindle 和 Books（macOS/iOS）上我无法使用的功能。比如，叠加高亮，高亮/笔记整理（不只是导出），定制辞典，导出 Obsidian 卡片等等…… 时不时有这样那样的 bug，但不影响我自己正常使用。
—— 但实在不好意思放出去给别人用。说实话，这个过程中学会的最大教训是：做出来之后只是给自己用的东西叫 “玩具”，做出来之后能给很多人用的才叫 “产品” 或者 “服务”。
当然，我还是只能想到自己的需求。“读” 解决了之后，我能为自己解决的就是 “写” 了…… 于是，2025 年 12 月 27 日，我从哈尔滨过完圣诞节回北京，就开始动手写 VMark —— 其实只不过是 Vibe coded Markdown Editor 的意思…… 甚至连它的图标，都是 Vibe Coded，Claude-Code 通过 MCP 指挥 SketchApp 画的。
选择写一个 Markdown 编辑器也有一些别的理由。
我觉得自己对一个 Markdown 编辑器 “应该是什么样的” 相对清楚。
我的确有很多 “需求” 未被现有的编辑器满足。
并且，直觉上来看，对我来说，它应该是个不大不小，正好是这个时期的我能应付的那种 “中型” 项目……
另外，我也觉得这样的项目会让 AI 更能帮助我 —— 毕竟，一个 Markdown 编辑器，不是什么新鲜东西，它的每个细节，AI 想了解的话，肯定比谁都更清楚……
然后…… 发现自己掉进了坑里 —— 不小心掉进了一个很大很深的坑。一个真正好用的 Markdown 编辑器，其实是很难做的 —— 至少，比想象的复杂很多很多倍。
先是肤浅地开心了几天，然后是反复折腾垂头丧气了一周…… 然后我跑去问 ChatGPT：
写一个很好的 markdown 编辑器，是多大的工程量？
它的回答一开头就给我看乐了 —— 因为自己曾经的无知。
能用的 Markdown 编辑器：1 人 · 1–2 周
好用的 Markdown 编辑器：1–2 人 · 1–3 个月
让重度写作者离不开的 Markdown 编辑器：
👉 3–8 人 · 1–3 年（而且基本是持续演进型工程） （这里省略很多很多字……）
你愿意维护多久（年，而不是月）？
>
看到最后，倒是舒心了 —— 维护时间按 “年” 计算？这事儿对别人来说可能是问题，对我来说完全不是，我真不怕这个。另外，我还有个小洞见：Markdown 其实就是未来人机交互的最基本格式…… 所以，我自己只能越用越多，一直用…… 既然如此，一直维护又如何呢？
顺带说，这个过程中我才发现我用了好多年并且买了好几个 Licenses 的 Typora 竟然是个 base 在上海的一家中国公司的产品。
半个月后，VMark 有了基本的雏形；整整一个月后，2026 年 1 月 27 日，我把 alpha 字样换成了 beta……
VMark 是一个高度固执己见（Highly Opinionated ）的东西 —— 事实上，我猜，以后所有 Vibe Coded Software/Services 都是高度固执己见的…… 这其实是没办法的事儿，因为一切 Vibe Coding 的过程自然而然地都是 “不需要与人开会” 的 “生产过程”。 —— 只有我自己和另外一个绝不争辩的执行者。
随便罗列几个我自己的偏好：
一切非内容信息，必须不能在上面…… 所以，甚至连格式菜单都被我放到编辑器底部了。
我有些固执的排版偏好
汉字之间必须有字间距，但同时，于汉字混排的英文词汇的字母之间不能有字间距。在有 VMark 之前，没有编辑器会满足我的这个特殊且又毫无商业价值的需求……
行间距必须可以随时调节。
表格必须是只有首行（Header）有背景色 —— 我讨厌斑马样式。
表格/图片可以居中显示
Heading 只有 H1 有下划线
有些 Coding Editor 才有的功能必须有：
多光标模式
多行排序
标点符号自动配对
它们不见得有的但也必须有： Tab Right Escape
我喜欢 WYSIWYG 的 Markdown 编辑器，但与此同时也讨厌两边切换（虽然这也是必须）…… 所以，我设计了个额外的无需切换整个 view 的 Source Peek（F5）的功能 —— 随时查看并修改当前 block 的 source。
导出 PDF 其实不重要，重要的是导出一个动态 html。
……
在这个开发过程中，我犯了无数的错误，包括不限于：
过早实现某个复杂的功能乃至于工程量无必要地叠加
花时间实现了后来不得不删掉的功能
在路径之间踌躇、反复，最终推倒重来
在某个路径上走了很久才发现自己未制定必要的原则和哲学
……
反正，把不成熟工程师所能犯的错误全都实打实地经历了绝对不止一遍…… 导致的结果之一就是每天早上起来开始到晚上睡觉之前，基本上都是在盯着屏幕 —— 痛并快乐着。
当然，也有做得对做得好的事情，比如，在核心功能做的还不够好的时候就给 VMark 添加了 MCP Server 功能。这样就可以让 AI 直接向编辑器发送内容。于是，我总是可以要求 Claude-Code 直接在命令行里：“Provide Markdown content for testing this feature, with comprehensive coverage of edge cases.” 而它每次发送的测试文本，总是让我大开眼界 —— 当然，更多的好处是，有了 MCP Server，省了好多时间精力。
至于 MCP 到底是什么，之前我当然完全不懂。我是通过克隆一个 MCP 服务器而后把它改造成我需要的另外一个与 VMark 全无关系的功能的过程中才深入理解的 —— 于是有了另外一个项目 CCCMemory…… Vibe Learning 啊！
不仅在开发过程中有用，在实际使用场景里，一个 Markdown 编辑器有 MCP 服务对我来说真的太有用了。比如，尤其在画各种 Mermaid Graphs 的时候，简直就是神器 —— 因为没有谁比 AI 更熟悉这种东西了（另外，AI 写正则表达式也是总能做到令人叹为观止），不是吗？我现在总是让 AI 将其输出结果（分析报告/审核报告之类的东西）直接发送到 VMark，总之比在 Terminal（或者 VSCode）里阅读舒服太多了。
到了 2026 年 2 月 2 日（恰好是 Vibe Coding 这个概念诞生的一周年）的时候，我开始觉得 VMark 是我自己能用着比较顺手的工具了 —— 虽然它还有大量的 bugs…… 但，我已经开始每天用它写东西（的同时顺手抓虫子）了。
我甚至开始为它增加了命令行面板，也增加了 AI Genies 的功能（说实话不太好用 —— 因为现在的 AI Providers 都有自己的古怪配置或者说特性）…… 总之，它已经在 “我自己觉得越来越好用” 然后也 “从此开始没办法用别的 Markdown 编辑器” 的路上了。
从开始算起，整整六周之后，我觉得也有点细节值得与像我一样的 “非工程师” 分享。
首先，虽然我不是什么真正的工程师，可幸亏我懂一些基础的 git 操作 —— 这个看起来只有软件工程师才用的东西，我已经用了很多年。现在回头想，我好像注册 github 账户已经有 15 年左右了。
我很少用 git 的高级功能。比如，Claude-Code 推荐的 git worktree 方式我就不用 —— 我的办法是直接用两台机器而不是同一台机器上的两个 worktrees。我只用最基本的功能，并且还全部都是使用自然语言指挥 Claude-Code 操作 git。
无论什么，都在分枝上操作。先胡乱折腾一段时间，然后告诉 Claude-Code “整理一下过往教训，重置当前的分支，让我们重新来过……”
没有 git，根本干不了任何稍微大一点的项目。这一点很重要，尤其是非程序员想要做项目的话，必须学一点 git 基础 —— 当然，了解基础概念就足够开始的了，在观看 Claude-Code 干活的过程中，总是可以了解更多……
其次是，必须了解 TDD 工作流。想尽一切办法提高 Claude-Code（或者其它的任何 Vibe Coding 工具）的 Test Coverage。了解 Test as Boundrary 的概念。任何软件都必然有 bugs —— bugs 就好像是大米虫一样，只要是粮仓，就必然有它们长出来，没完没了…… 如果没有足够的 Test Coverage 就失去了找到它们的任何机会。
更为重要的另外一个哲学原则：你不是在 Vibe Coding，你其实是在 Vibe Thinking。任何产品或者服务都只能是思考的产物，而不是劳动的必然结果。
AI 只是接管了我们 “DO” 的过程和辛劳，但，它实际上在 What/Why/How 这种看似最为基础的思考过程中只能起辅助作用。最要命的是，它只会顺着你的话说下去，于是，只要你在思考上依赖它，它就会反过来不声不响地把你困在你自己的思维定势之中且能让你越来越不自知，然后我们就会像歌词里所说的那样：“We are all just prisoners here, of our own device” 的同时，却认为自己更自由了……
我经常对 AI 说的是，“Treat me as a rival you don’t particularly like. Evaluate my ideas critically and challenge them directly, but keep it professional and non-hostile.” 总是有高质量且意外的收获。
另外一个技巧是，让两个不同厂商的 AI 相互讨论甚至争论。我给 Claude-Code 安装了 Codex Cli 的 MCP 服务。于是，经常可以对 Claude-Code 说：“Summarize the problems you couldn’t solve just now and ask Codex for help.”。我也经常把 Claude-Code 的计划在另外一个 Terminal 窗口里发给 Codex Cli：“This is the plan drafted by Claude Code. I want you to review it and give me your most professional, blunt, and unsparing feedback.”，然后把 Codex Cli 的输出拷贝粘贴给 Claude-Code，让它根据建议改善。
当我找到一个可以适用 Claude-Code 的 /audit 命令之后（大概是 10 月初），我马上写了另外一个 /codex-audit，其实是就是它的克隆版，只不过是要求用 MCP 去访问 Codex Cli 做同样的事情。用 AI 卷/督促 AI，效果比我自己督促它们实在是好太多了。
这种方法其实是 “递归” 的一种变体，和当年我去问 Google “如何有效地使用 Google” 其实是同一个原理。这也是我不太研究复杂的提示词工程的原因，只要会用递归，必然有更好的结果。
还有一件事，其实是性格问题。做工程的人，必须打心眼里由衷喜欢处理细节。否则的话，做事就不开心。要面对无数的细节，而每个细节之中，其实也有无数的细节。
比如，弯引号和直引号不同；弯引号的明显程度其实是 Latin 字体决定的（不做 VMark 我可真不知道这事儿）；如果实现了引号自动配对，那么，右双引号也得被处理成自动配对（这是我在写当前这个文档时才发现的细节）；与此同时，右弯单引号，是不应该自动配对的…… 这些琐细的事情，你要处理的时候觉得很开心，否则，做产品做服务，就必然会变成无聊、沮丧、挫败、无奈、甚至令人气愤的过程。
最后，还有一个格外值得提及的事情 —— 但也是“高度固执己见”的事情。因为我自己并非工程师，所以，基于不得不的出发点，选择了我认为更正确的一条路：
不用任何 IDE —— 只用 Terminal…… 最初我只是用 macOS 自带的 Terminal，后来选择了有标签有分屏面板的 iTerm。
为什么直接放弃了 VSCode 这类 IDE 呢？最初只是因为 “看不懂复杂代码”（再加上 Claude-Code 经常让 VSCode 闪退），再后来发现也没必要看懂…… 因为无论如何 AI 写的都肯定比 1）自己 2）自己能花钱雇来的人类程序员/工程师好太多了（OpenAI 的科学家们，肯定不是我们能花钱雇来的人类啊）…… 代码都不看，diff 就更不用看了，不是吗？
后来我甚至连文档都不自己动手写了（指导是必须的）—— 整个 https\://vmark.app 都是 AI 写的，我一个字符都没碰过。（关于 Vibe-Coding 的过程和经验总结分享除外。）
这有点像我自己在二级市场上投资。我是会计专业出身，真的不是读不懂，但，实际上我从来不读上市公司财报。我的哲学听起来不像话：好公司大家都知道，不用看财报也知道。关键根本不在于财报，关键只在于你是否能做到长期持有（至少十年以上）—— 这事儿跟财报半点关系都没有。
所以，在 vmark.app 的网站上，有这么个 Credit 提示：
我只是一个 Producer（制作人）。
另外，还有个 “高度固执己见” 自动带来的后果：VMark 就算开源了，也不能指望 “社群贡献”。首先，这完全是为了让自己顺手才写的东西，很多功能对别人来说并无太大价值。最为关键的是，Markdown 编辑器不是什么科技前沿的东西，是个无数人实现过无数次的编辑器中的一个简单分子，所以，AI 可以帮助我们解决关于它的任何问题。
Claude-Code 甚至可以直接阅读 Github 上的 Issues，而后跑回来找问题，修复，最后，竟然还可以自动根据提出问题的用户所使用的语言回复…… 第一次让它处理 issue 的时候，看到结果，真是把我惊到了 —— 目瞪口呆了好一会儿。
在整个 VMark 的制作过程中，思考最多的其实是自己家孩子的未来教育方向。AI 对普通人影响最大的，其实是教育领域。
首先，15 岁可能真的是个明显的分水岭 —— 任何有效的教育，在此之前就已经彻底结束了…… 随后全都是自我教育和自我修行。在此之前，阅读耐力的培养无比重要（当然，重要的事情总是很多）。
其次，学校里的教育不仅早就被证明为无效，并且，如果不把学校当作孩子的有效社交场所和心理健康养成场所的话，如果把学校当作教育的主要来源的话，那么，孩子基本上一定沦为未来世界里的无用之人。
最重要的是，一切的教育都最好要以生产为导向（我在《好的家庭教育》和《财富的真相》里反复提及这个观点）—— 未来是生产者的世界，尤其是制作人的世界，思考者的世界，决策者的世界…… 虽然，历来如此，但，有另外一个重要不同：至于执行么，那是机器人的世界。
而关于小朋友使用 AI，我有个很扎实的建议 —— 也值得家长与孩子分享：
不要轻易被 AI 迷惑。
让自己或者别人 WOW 一下一点都不重要。重要的是，用 AI 做出了什么自己之前完全不可能做出来的东西？那东西越复杂越好，越真实越好，越有用越好。
有一个简单的判断标准：
用了 AI 之后，你的思考是变多了，还是变少了？
如果变得更多更深入了，那就是 AI 起了好作用。如果是更少了，那就是 AI 起了副作用。
另外，AI 从来都不是 “少干活” 的工具。道理很简单，它能做很多事的重要结果是，你可以想得更多更深入，然后，你自己能做的事情，要做的事情，只能变多，不可能变少。
在写这篇文章的过程中，顺手发现了好几个小问题，随后，VMark 的版本号从 0.4.12 变成了 0.4.13……
还有，自从主要生活在命令行里之后，再也没有什么大屏幕/多屏幕的需求了…… 一个 13# 的笔记本电脑对我来说都彻底足够了…… 哪怕是一个小阳台都可以成为 “足够的工作空间”。