我为什么要构建 Markdown 编辑器：VMark
太长不看版
一个非程序员在 2025 年 8 月开始了"氛围编程"，并在六周内构建了 VMark——一个 Markdown 编辑器。核心经验：git 是必须的（它是你的撤销按钮），TDD 让 AI 保持诚实（测试是对抗 bug 的边界），你是在进行氛围思考，而非氛围编程（AI 承担劳动，你做判断），以及 跨模型辩论胜过单模型信任。这段旅程证明了用户可以成为开发者——但前提是他们必须投资于几项基础技能。
起点
说实话，构建 VMark 对我来说首先是一段学习和体验的旅程。
我在 2025 年 8 月 17 日开始尝试那个新兴的编程趋势，人们称之为氛围编程（vibe coding）。"氛围编程"这个词最初由 Andrej Karpathy 在 2025 年 2 月 2 日发布于 X（前 Twitter）的帖子中造出并广泛传播。
Andrej Karpathy 是机器学习领域极具影响力的研究员和教育者。他曾在 OpenAI 和 Tesla 等公司担任重要职位，后来创立了专注于 AI 原生教育的 Eureka Labs。他的这条推文不仅提出了"氛围编程"的概念，还在技术社区中迅速传播，引发了大量后续讨论。
等我注意到并开始使用氛围编程工具时，距离这个概念诞生已经过去了将近半年。那时 Claude Code 还处于 1.0.82 版本。在我撰写这篇文档的 2026 年 2 月 9 日，它已经到达了 2.1.37 版本，中间经历了 112 次版本更新。
一开始，我只是用这些工具来增强我早就写好的一些自动化脚本——比如批量翻译电子书。我意识到自己不过是在放大原本就有的能力。
如果我原本就会做某件事，AI 就能帮我做得更好。如果我原本不会做某件事，AI 往往给了我一种能做到的错觉——通常伴随着一开始的"哇"的感觉——之后什么都没有。原本不会的，还是不会。那些精美的图片、抢眼的视频和长篇大论，在很多情况下，不过是新时代版本的"Hello World"。[1]
我对编程并非一无所知，但也绝对算不上真正的计算机工程师。充其量，我只是普通用户中的高级用户。我懂一些代码，甚至出版过一本关于 Python 编程的书。但这并不让我成为工程师。就像一个能搭草屋的人：知道的比不会的多，但和那些设计摩天大楼或桥梁的人根本不在一个量级。
然后，AI 改变了一切。
从脚本到软件
从最开始到现在，我几乎尝试了所有可用的 AI 编程 CLI：Claude Code、Codex CLI、Gemini CLI，甚至 Grok CLI 这样的非官方工具，以及 Aider 这样的开源替代品。然而，我用得最多的始终是 Claude Code。在 Codex CLI 引入 MCP Server 之后，我用 Claude Code 更多了，因为它可以在交互模式下直接调用 Codex CLI。有点讽刺的是，虽然 Claude Code 是最早提出 MCP 协议的，但它本身至今仍未提供 MCP Server（截至 2026-02-10）。
一开始，Claude Code 感觉就像一位突然搬进我家的专业 IT 专家——通常只有大公司才雇得起的那种。任何与计算机相关的事情都可以交给它处理。它会用我从未见过的命令行工具，或是以陌生方式使用的熟悉命令来解决问题。
只要获得足够的权限，几乎没有它做不到的事：系统维护、更新、网络配置、部署带有无数复杂配置和冲突的软件或服务。你绝对雇不到一个每月 200 美元就能做这些的人。
此后，我使用的机器数量开始增加。云实例从一两台增长到五六台；家里的机器从两三台增加到七八台。以前需要几天才能搭建好的问题——而且常常因为我知识有限而失败——突然消失了。Claude Code 处理了我所有的机器操作，修复问题之后，它甚至还会编写开机自启脚本，确保同样的问题再也不会发生。
然后我开始写一些以前从未能写出来的东西。
首先是一个叫 Insidebar-ai 的浏览器扩展，旨在减少浏览器中频繁的上下文切换和复制粘贴。然后是 Tepub，这看起来才真正像是正经软件：一个用于翻译 EPUB 书籍（单语或双语）甚至生成有声书的 Python 命令行工具。在此之前，我有的不过是笨拙的手写 Python 脚本。
我感觉自己就像一个时尚博主突然学会了裁缝技术——甚至拥有了一家纺织厂。无论我的品味原本多好，一旦不经意间更多地了解了相关和基础领域，我的许多看法自然而然——也不可避免地——改变了。
我决定花几年时间，把自己变成一个真正的计算机工程师。
我以前也做过类似的事。我在新东方教了很多年阅读课。教了几年之后，至少在阅读方面，我已经有效地把自己变成了一个英文母语阅读者（不是说话者）。我的口语很糟糕——但实际上也没什么用——就这样了。
我没有宏大的目标。我只是想锻炼大脑。这不是最有趣的游戏吗？
我决定每周完成一个相对小的项目，每个月完成一个相对大的项目。做了几十个项目之后，我猜自己会成为另一个人。
三个月后，我建立了十几个项目——有些失败了，有些被放弃了——但全都令人着迷。在这个过程中，AI 以惊人的速度变得越来越聪明。没有密集的实际使用，你永远不会真正感受到这一点；顶多是从别人那里听说。这种感受很重要，因为它直接塑造了我后来形成的一种 AI 哲学：对 AI 会持续变得更聪明的坚定信念。
2025 年 11 月，我基于 foliate.js 构建了一个 EPUB 阅读器，完全按照我喜欢的方式设计。我实现了在 Kindle 或 Apple Books（macOS/iOS）上无法获得的功能：分层高亮、高亮和笔记管理（不只是导出）、自定义词典、导出 Obsidian 卡片等。偶尔有 bug，但不影响我个人使用。
话虽如此，我还是太不好意思公开发布了。我学到的最大教训是：只为自己构建的东西是玩具；为很多人构建的东西是产品或服务。
为什么是 Markdown 编辑器
自然而然，我还在只考虑自己的需求。一旦"阅读"问题解决了，接下来我能为自己解决的就是"写作"。于是在 2025 年 12 月 27 日——圣诞节后从哈尔滨回到北京之后——我开始构建 VMark。这个名字简单地表示 Vibe-coded Markdown Editor（氛围编程的 Markdown 编辑器）。甚至连它的图标都是氛围编程的产物：Claude Code 通过 MCP 指示 Sketch 绘制它。
选择构建 Markdown 编辑器还有其他原因。
我觉得自己对一个 Markdown 编辑器应该是什么样子有相当清晰的想法。
我也有很多现有编辑器无法满足的未被满足的需求。
直觉上，它对我目前阶段来说是一个恰当大小的项目——一个我能实际完成的"中型"项目。
我也相信这样一个项目会让 AI 能更多地帮助我。毕竟，Markdown 编辑器并不新鲜；它的每一个细节都是 AI 比任何人都了解的东西。
然后我掉进了一个坑——一个非常深的坑。一个真正好的 Markdown 编辑器极难构建，远比我想象的复杂。
我表面上高兴了几天，然后花了一周时间反复挣扎、感到沮丧。最终，我问了 ChatGPT：
构建一个真正好的 Markdown 编辑器工作量有多大？
它回复的开头让我笑了——笑自己的无知。
可用的 Markdown 编辑器：1 人·1–2 周
好的 Markdown 编辑器：1–2 人·1–3 个月
重度写作者离不开的 Markdown 编辑器：
3–8 人·1–3 年（基本上是持续演进的项目）（很多细节略去。）
然后是最后一个问题：
你愿意维护它多久（以年计，不是月）？
这反而让我放下了顾虑。以年计的维护？对其他人来说可能是个问题，但对我来说不是。我不怕这个。我也有一个小小的洞见：Markdown 很可能是未来人机交互最基本的格式。随着时间推移，我只会用得更多。如果是这样，为什么不无限期地维护它呢？
顺带一提，在这个过程中，我发现 Typora——我多年来一直使用并购买了多个许可证的编辑器——实际上是一家上海公司开发的。
两周后，VMark 有了基本雏形。整整一个月后，在 2026 年 1 月 27 日，我将其标签从 alpha 改为 beta。
固执己见的编辑器
VMark 极度固执己见。事实上，我怀疑所有氛围编程的软件和服务都会如此。这是不可避免的，因为氛围编程本质上是一个没有会议的生产过程——只有我和一个从不反驳的执行者。
以下是我的几个个人偏好：
所有非内容信息必须远离主区域。甚至格式菜单也放在底部。
我有顽固的排版偏好。
中文字符之间必须有间距，但嵌入中文文本中的英文字母之间不能有间距。在 VMark 之前，没有编辑器能满足这个小众的、商业上毫无价值的需求。
行距必须随时可调。
表格只有标题行应该有背景色。我讨厌斑马纹。
表格和图片应该可以居中。
只有 H1 标题应该有下划线。
通常只在代码编辑器中才有的某些功能必须存在：
多光标模式
多行排序
自动标点配对
其他的可选但很好有：
Tab 右跳出
我喜欢所见即所得的 Markdown 编辑器，但我讨厌频繁切换视图（尽管有时是必要的）。所以我设计了一个源码预览功能（F5），让我可以在不切换整个视图的情况下查看和编辑当前块的源码。
导出 PDF 没那么重要。导出动态 HTML 才重要。
等等。
错误与突破
在开发过程中，我犯了无数错误，包括但不限于：
过早实现复杂功能，不必要地膨胀范围
在后来被删除的功能上花费时间
在路径之间犹豫，一次又一次地重新开始
沿着一条路走太久才意识到缺乏指导原则
总之，一个不成熟的工程师可能犯的每一个错误，我都犯了——而且是多次。结果就是从早到晚，我几乎不间断地盯着屏幕。痛苦，却又快乐。
当然，也有些事情我做对了。
比如，我在 VMark 核心功能还没稳固之前就添加了 MCP Server。这使得 AI 可以直接向编辑器发送内容。我可以直接在终端里让 Claude Code：
"提供用于测试这个功能的 Markdown 内容，全面覆盖边界情况。"
每次生成的测试内容都让我惊叹——并节省了大量时间和精力。
起初，我完全不知道 MCP 究竟是什么。直到我克隆了一个 MCP 服务器并将其修改成与 VMark 完全无关的东西——由此诞生了另一个项目 CCCMemory，我才深入理解了 MCP。氛围学习，名副其实。
在实际使用中，在 Markdown 编辑器中拥有 MCP 非常有用——尤其是在绘制 Mermaid 图表方面。没有人比 AI 更懂这些。正则表达式也一样。我现在习惯于让 AI 把它的输出——分析报告、审计报告——直接发送到 VMark 中。这比在终端或 VSCode 中阅读舒服多了。
到 2026 年 2 月 2 日——正好是氛围编程概念诞生一周年——我感觉 VMark 已经成为一个我可以真正舒适使用的工具。它仍然有很多 bug，但我已经开始每天用它写作，边用边修 bug。
我甚至添加了命令行面板和 AI 精灵（说实话，由于不同 AI 提供商的奇特行为，目前还不太好用）。但它明显走在一条不断为我改进的道路上——在这条路上，我已经无法再使用其他 Markdown 编辑器了。
Git 是必须的
六周之后，我感觉有些细节值得与其他像我这样的"非工程师"分享。
首先，虽然我不是真正的工程师，但幸运的是我理解基本的 git 操作。我使用 git 已经很多年了，尽管它看起来似乎只是工程师才用的工具。回想起来，我注册 GitHub 账号大约是 15 年前。
我很少使用高级 git 功能。例如，我不像 Claude Code 推荐的那样使用 git worktree。我用两台独立的机器代替。我只使用基本命令，全部通过自然语言指令交给 Claude Code 执行。
所有事情都在分支上进行。我随意折腾，然后说：
"总结到目前为止的经验教训，重置当前分支，让我们重新开始。"
没有 git，你根本无法做任何非平凡的项目。这对非程序员来说尤其重要：学习基本的 git 概念是必须的。只要看着 Claude Code 工作，你自然会学到更多。
其次，你必须理解 TDD 工作流。尽一切可能提高测试覆盖率。理解"测试作为边界"的概念。Bug 是不可避免的——就像粮仓里的米象。没有足够的测试覆盖率，你根本没有机会找到它们。
氛围思考，而非氛围编程
这里是核心哲学原则：你不是在氛围编程；你是在氛围思考。产品和服务始终是思考的结果，而非劳动不可避免的产物。
AI 已经接管了大部分"做"，但在什么、为什么和如何的根本性思考上，它只能辅助。危险在于它总是会跟随你的引领。如果你依赖它来思考，它会悄悄地把你困在自己的认知偏见中[2]——同时让你感觉比以往任何时候都更自由。正如歌词所唱：
"我们都只是囚徒，被自己的设备所困。"
我常对 AI 说的话是：
"把我当成你不太喜欢的对手。批判性地评估我的想法并直接挑战它们，但保持专业和非对抗性。"
结果始终高质量且出乎意料。
另一个技巧是让不同厂商的 AI 相互辩论。[3] 我为 Claude Code 安装了 Codex CLI 的 MCP 服务。我经常告诉 Claude Code：
"总结你刚才无法解决的问题，向 Codex 寻求帮助。"
或者我把 Claude Code 的计划发给 Codex CLI：
"这是 Claude Code 起草的计划。我想要你最专业、最直接、最毫不留情的反馈。"
然后我把 Codex 的回应反馈给 Claude Code。
当我发现 Claude Code 的 /audit 命令时（大约在十月初），我立即编写了 /codex-audit——一个通过 MCP 调用 Codex CLI 的克隆版本。用 AI 来施压和审计 AI，效果远胜过我自己来做。
这种方法本质上是递归的变体——与"如何有效使用谷歌"谷歌相同的原理。这就是为什么我不在复杂的提示词工程上花太多时间。如果你理解递归，更好的结果是必然的。
只用终端
还有一个性格因素。工程师必须真正享受 处理细节。否则工作会变得痛苦。每个细节都包含无数个子细节。
比如：弯引号与直引号；弯引号的显眼程度取决于拉丁字体而非中日韩字体（这是我在 VMark 之前从不知道的事情）；如果引号自动配对，那么右双引号也必须自动配对（这是我在写这篇文章时发现的细节）；与此同时，右弯单引号不应该自动配对。如果处理这些细节不让你快乐，产品开发不可避免地会变得无聊、令人沮丧，甚至令人愤怒。
最后，还有一个值得一提的极度固执己见的选择。因为我不是工程师，我出于必要选择了我认为更正确的路径：
我完全不用 IDE — 只用终端。
一开始，我用的是 macOS 默认终端。后来，我换成了 iTerm 以使用标签页和分割窗格。
为什么放弃 VSCode 这样的 IDE？最初是因为我无法理解复杂的代码——而且 Claude Code 经常导致 VSCode 崩溃。后来，我意识到我不需要理解它。AI 写的代码远比我——或者甚至是我负担得起的程序员（OpenAI 的科学家不是你能雇到的人）——能写出来的好得多。如果我不读代码，也就没必要读 diff 了。
最终，我停止了自己写文档（指导仍然是必要的）。整个 vmark.app 网站都是 AI 写的；我一个字都没动——除了关于氛围编程本身的反思。
这类似于我的投资方式：我能读财务报表，但我从不读——好公司用不着那些就显而易见。重要的是方向，不是细节。
这就是为什么 VMark 网站上有这样的致谢：
固执己见的另一个后果：即使 VMark 是开源的，社区贡献也不太可能。它纯粹是为我自己的工作流而构建的；许多功能对其他人来说价值很小。更重要的是，Markdown 编辑器并不是尖端技术。它不过是熟悉工具的无数实现之一。AI 几乎可以解决与之相关的任何问题。
Claude Code 甚至可以读取 GitHub Issue、修复 bug，并自动用报告者的语言回复。当我第一次看到它端到端地处理一个 Issue 时，我完全震惊了。
试金石
构建 VMark 还让我思考了 AI 对学习的更广泛影响。所有教育都应该以生产为导向[4]——未来属于创造者、思考者和决策者，而执行属于机器。对任何使用 AI 的人来说，最重要的试金石是：
自从你开始使用 AI，你是在 更多 地思考，还是 更少？
如果你思考得更多——而且思考得更深——那么 AI 正在以正确的方式帮助你。如果你思考得更少，那么 AI 正在产生副作用。[5]
此外，AI 从来都不是"少做工作"的工具。逻辑很简单：因为它能做更多的事情，你就能思考更多、钻研更深。结果是，你能做的——以及需要做的——事情只会 增加，而不会减少。[6]
写这篇文章的时候，我随手发现了几个小问题。结果，VMark 的版本号从 0.4.12 变成了 0.4.13。
既然我已经主要在命令行中生活，我不再感到需要大显示器或多个屏幕。13 英寸的笔记本电脑完全够用。甚至一个小阳台就能成为一个"足够好"的工作空间。
METR 进行的一项随机对照试验发现，经验丰富的开源开发者（平均在其分配项目上工作 5 年）在使用 AI 工具时实际上 慢了 19%，尽管他们预测会有 24% 的提速。该研究突显了感知与实际生产力收益之间的差距——AI 最有助于放大现有技能，而不是替代缺失的技能。参见：Rao, A., Brokman, J., Wentworth, A., et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR Technical Report. ↩︎
接受人类反馈训练的 LLM 系统性地赞同用户现有的信念，而不是提供真实的回应——研究人员称这种行为为奉承性（sycophancy）。在五个最先进的 AI 助手和四项文本生成任务中，模型始终调整回应以匹配用户意见，即使这些意见是错误的。当用户仅仅暗示了一个错误答案时，模型的准确率就会显著下降。这正是上文描述的"认知偏见陷阱"：AI 跟随你的引领，而不是挑战你。参见：Sharma, M., Tong, M., Korbak, T., et al. (2024). Towards Understanding Sycophancy in Language Models. ICLR 2024. ↩︎
这种技术与一种叫做多智能体辩论的研究方法相呼应，其中多个 LLM 实例在几轮中提出并挑战彼此的回应。即使所有模型最初都产生了错误答案，辩论过程也能显著提高事实性和推理准确性。使用来自不同厂商的模型（具有不同的训练数据和架构）会放大这种效果——它们的盲点很少重叠。参见：Du, Y., Li, S., Torralba, A., Tenenbaum, J.B., & Mordatch, I. (2024). Improving Factuality and Reasoning in Language Models through Multiagent Debate. ICML 2024. ↩︎
这与 Seymour Papert 的建构主义理论一致——即学习者在积极构建有意义的制品时，学习效果最佳，而不是被动地吸收信息。Papert 是皮亚杰的学生，他认为构建有形产品（软件、工具、创意作品）比传统教学更能激活更深层的认知过程。一个世纪前，John Dewey 也提出了类似的观点：教育应该是体验性的，与现实世界的问题解决相连，而不是死记硬背。参见：Papert, S. & Harel, I. (1991). Constructionism. Ablex Publishing; Dewey, J. (1938). Experience and Education. Kappa Delta Pi. ↩︎
2025 年一项对 666 名参与者的研究发现，频繁使用 AI 工具与批判性思维能力之间存在强负相关（r = −0.75），由认知卸载——将思考委托给外部工具的倾向——所介导。参与者越依赖 AI，他们调动自身分析能力的程度就越低。年轻参与者表现出更高的 AI 依赖性和更低的批判性思维得分。参见：Gerlich, M. (2025). AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking. Societies, 15(1), 6. ↩︎
这是杰文斯悖论的现代版本——1865 年的观察表明，更高效的蒸汽机并未减少煤炭消耗，反而增加了，因为更低的成本刺激了更大的需求。应用于 AI：随着编码和写作变得更便宜、更快，工作总量反而扩大，而不是收缩。近期数据支持这一点——2025 年对 AI 精通的软件工程师的需求同比增长近 60%，对 AI 工具熟练的开发者有 15-25% 的薪资溢价。效率收益创造了新的可能性，从而创造了新的工作。参见：Jevons, W.S. (1865). The Coal Question; The Productivity Paradox of AI, HackerRank Blog (2025). ↩︎