# Why I Built a Markdown Editor: VMark
**作者**: xiaolai
**日期**: 2026-02-10T13:41:14.000Z
**来源**: [https\://x.com/xiaolai/status/2021217901936771324](https://x.com/xiaolai/status/2021217901936771324)
---
In truth, building VMark has primarily been a learning and experiential journey for myself.
I began experimenting with the emerging programming trend known as *vibe coding* on August 17, 2025. The term *vibe coding* itself was first coined and circulated on February 2, 2025, originating from a post by Andrej Karpathy.
Andrej Karpathy is a highly influential researcher and educator in the field of machine learning. He has held important positions at companies such as OpenAI and Tesla, and later founded Eureka Labs, focusing on AI-native education. His tweet not only introduced the concept of “vibe coding,” but also spread rapidly through the tech community, sparking extensive follow-up discussions
By the time I noticed and started using vibe coding tools, nearly half a year had already passed. At that time, Claude Code was still at version [1.0.82] As I write this document on February 9, 2026, it has reached version [2.1.37], having gone through 112 version updates in between.
At the very beginning, I only used these tools to enhance some automation scripts I had written long ago — for example, batch-translating ebooks. What I realized was that I was merely amplifying abilities I already had.
If I already knew how to do something, AI helped me do it better. If I didn’t know how to do something, AI often gave me the illusion that I could — usually with an initial “wow” moment — followed by nothing. What I originally couldn’t do, I still couldn’t do. Those beautiful images, eye-catching videos, and long-form articles were, in many cases, just another form of “Hello World” for a new era.
I am not completely ignorant of programming, but I am certainly not a real computer engineer. At best, I am a power user among ordinary users. I know some code, and I have even published a book about Python programming. But that does not make me an engineer. It’s like someone who can build a thatched hut: they know more than someone who can’t, but they are not even remotely in the same category as those who design skyscrapers or bridges.
And then, AI changed everything.
From the beginning until now, I have tried almost every AI coding CLI available: Claude Code, Codex CLI, Gemini CLI, even unofficial tools like Grok CLI, as well as open-source alternatives such as Aider. Yet the one I have used the most is always Claude Code. After Codex CLI introduced an MCP Server, I used Claude Code even more, because it could call Codex CLI directly in Interactive Mode. Ironically, although Claude Code was the first to propose the MCP protocol, it still does not provide an MCP Server itself (as of 2026-02-10).
At first, Claude Code felt like a professional IT specialist who had suddenly moved into my home — someone you would normally only find in large companies. Anything computer-related could be handed over to it. It would solve problems using command-line tools I had never seen before, or familiar commands used in unfamiliar ways.
As long as it was given sufficient permissions, there was almost nothing it couldn’t do: system maintenance, updates, networking, deploying software or services with countless tricky configurations and conflicts. You could never hire a person like this for USD 200 a month.
After that, the number of machines I used began to increase. Cloud instances grew from one or two to five or six; machines at home increased from two or three to seven or eight. Problems that used to take days to set up — and often failed due to my limited knowledge — suddenly disappeared. Claude Code handled all machine operations for me, and after fixing issues, it even wrote auto-start scripts to ensure the same problems would never occur again.
Then I started writing things I had never been able to write before.
First came a browser extension called **Insidebar-ai**, designed to reduce constant context switching and copy-pasting in the browser. Then came **Tepub**, which actually looked like real software: a Python command-line tool for translating EPUB books (monolingual or bilingual) and even generating audiobooks. Before that, all I had were clumsy, handwritten Python scripts.
I felt like a fashion blogger who had suddenly acquired tailoring skills — or even owned a textile factory. Regardless of how good my taste once was, once I inadvertently learned more about related and foundational fields, many of my views naturally — and unavoidably — changed.
I decided to spend several years turning myself into a real computer engineer
I had done something similar before. I taught reading classes at New Oriental for many years. After teaching for several years, at least in reading, I had effectively turned myself into an English native reader (not speaker). My speaking was terrible — but there was no real use for it anyway — so that was that.
I wasn’t aiming for anything grand. I just wanted to exercise my brain. It’s the most interesting game, isn’t it?
I decided to complete one relatively small project every week, and one relatively larger project every month. After dozens of projects, I guessed I would become a different person.
Three months later, I had built more than a dozen projects — some failed, some were abandoned — but all were fascinating. During this process, AI became visibly smarter at an astonishing pace. Without dense, hands-on usage, you would never really feel this; at most, you’d hear about it secondhand. This feeling matters, because it directly shaped an AI philosophy I’ll discuss later: **a firm belief that AI will keep getting smarter**.
In November 2025, I built an EPUB reader based on foliate.js, designed exactly the way I liked it. I implemented features I couldn’t get on Kindle or Apple Books (macOS/iOS): layered highlights, highlight and note management (not just export), custom dictionaries, exporting Obsidian cards, and more. There were occasional bugs, but they didn’t affect my personal use.
That said, I was too embarrassed to release it publicly. The biggest lesson I learned was this: something built only for yourself is a *toy*; something built for many people is a *product* or a *service*.
Naturally, I was still only thinking about my own needs. Once “reading” was solved, the next thing I could solve for myself was “writing.” So on December 27, 2025 — after returning to Beijing from Harbin after Christmas — I started building **VMark**. The name simply means *Vibe-coded Markdown Editor*. Even its icon was vibe-coded: Claude Code instructed Sketch via MCP to draw it.
Choosing to build a Markdown editor had other reasons as well.
- I felt I had a fairly clear idea of what a Markdown editor *should* be like.
- I also had many unmet needs that existing editors failed to satisfy.
- Intuitively, it felt like a project of just the right size for me at this stage — a “medium-sized” project I could realistically handle.
- I also believed such a project would allow AI to help me more. After all, a Markdown editor is nothing new; every detail of it is something AI understands better than almost anyone.
And then I fell into a hole — a very deep one. A truly good Markdown editor is extremely difficult to build, far more complex than I had imagined.
I was superficially happy for a few days, then spent a week repeatedly struggling and feeling dejected. Eventually, I asked ChatGPT:
> How big is the workload for building a really good Markdown editor?
The opening of its reply made me laugh — at my own ignorance.
- A usable Markdown editor: **1 person · 1–2 weeks**
- A good Markdown editor: **1–2 people · 1–3 months**
- A Markdown editor heavy writers can’t live without:
- 👉 **3–8 people · 1–3 years** (and essentially a continuously evolving project)
- (Many details omitted.)
- Then came the final question:
- *How long are you willing to maintain it (in years, not months)?*
That actually reassured me. Maintenance measured in *years*? That might be a problem for others, but not for me. I’m not afraid of that. I also had a small insight: Markdown is likely the most fundamental format for future human–computer interaction. I’ll only use it more over time. If so, why not maintain it indefinitely?
As a side note, during this process I discovered that Typora — an editor I had used and paid for multiple licenses for over many years — is actually developed by a company based in Shanghai.
Two weeks later, VMark had a basic shape. One full month later, on January 27, 2026, I changed its label from *alpha* to *beta*.
VMark is **highly opinionated**. In fact, I suspect all vibe-coded software and services will be. This is unavoidable, because vibe coding is inherently a production process without meetings — just me and an executor who never argues back.
Here are a few of my personal preferences:
- All non-content information must stay out of the main area. Even the formatting menu is placed at the bottom.
- I have stubborn typographic preferences.
- Chinese characters must have spacing between them, but English letters embedded in Chinese text must not. Before VMark, no editor satisfied this niche, commercially worthless requirement.
- Line spacing must be adjustable at any time.
- Tables must only have background color on the header row. I hate zebra stripes.
- Tables and images should be centerable.
- Only H1 headings should have underlines.
- Some features typically found only in code editors must exist:
- Multi-cursor mode
- Multi-line sorting
- Automatic punctuation pairing
- Others are optional, but nice to have:
- Tab Right Escap
- I like WYSIWYG Markdown editors, but I hate constantly switching views (even though it’s sometimes necessary). So I designed a *Source Peek* feature (F5), allowing me to view and edit the source of the current block without switching the entire view.
- Exporting PDF isn’t that important. Exporting dynamic HTML is.
- And so on.
During development, I made countless mistakes, including but not limited to:
- Implementing complex features too early, unnecessarily inflating scope
- Spending time on features that were later removed
- Hesitating between paths, restarting again and again
- Following a path for too long before realizing I lacked guiding principles
In short, I experienced every mistake an immature engineer can make — many times over. One result was that from morning until night, I stared at a screen almost nonstop. Painful, yet joyful.
Of course, there were things I did right.
For example, I added an MCP Server to VMark before its core features were even solid. This allowed AI to send content directly into the editor. I could simply ask Claude Code in the terminal:
> “Provide Markdown content for testing this feature, with comprehensive coverage of edge cases.”
Every time, the generated test content amazed me — and saved enormous time and energy.
At first, I had no idea what MCP really was. I only came to understand it deeply after cloning an MCP server and modifying it into something entirely unrelated to VMark — leading to another project called **CCCMemory**. Vibe learning, indeed.
In real usage, having MCP in a Markdown editor is incredibly useful — especially for drawing Mermaid diagrams. No one understands those better than AI. The same goes for regular expressions. I now routinely ask AI to send its output — analysis reports, audit reports — directly into VMark. It’s far more comfortable than reading them in a terminal or VSCode.
By February 2, 2026 — exactly one year after the birth of the vibe coding concept — I felt VMark had become a tool I could genuinely use comfortably. It still had many bugs, but I had already started writing with it daily, fixing bugs along the way.
I even added a command-line panel and AI Genies (honestly, not very usable yet, due to quirks of different AI providers). Still, it was clearly on a path where it kept getting better for me — and where I could no longer use other Markdown editors.
Six weeks in, I felt there were some details worth sharing with other “non-engineers” like myself.
First, although I’m not a real engineer, thankfully I understand basic **git** operations. I’ve used git for many years, even though it seems like a tool only engineers use. Looking back, I think I registered my GitHub account about 15 years ago.
I rarely use advanced git features. For example, I don’t use git worktree as recommended by Claude Code. Instead, I use two separate machines. I only use basic commands, all issued via natural language instructions to Claude Code.
Everything happens on branches. I mess around freely, then say:
> “Summarize the lessons learned so far, reset the current branch, and let’s start over.”
Without git, you simply can’t do any non-trivial project. This is especially important for non-programmers: *learning basic git concepts is mandatory*. You’ll naturally learn more just by watching Claude Code work.
Second, you must understand the **TDD** workflow. Do everything possible to improve test coverage. Understand the concept of *tests as boundaries*. Bugs are inevitable — like rice weevils in a granary. Without sufficient test coverage, you have no chance of finding them.
More importantly, here is a core philosophical principle: **you are not vibe coding; you are vibe thinking**. Products and services are always the result of *thinking*, not the inevitable outcome of *labor*.
AI has taken over much of the “*doing*,” but it can only assist in the fundamental thinking of *what*, *why*, and *how*. The danger is that it will always follow your lead. If you rely on it for thinking, it will quietly trap you inside your own cognitive biases — while making you feel freer than ever. As the lyric goes:
> “We are all just prisoners here, of our own device.”
What I often say to AI is:
> “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.”
The results are consistently high-quality and unexpected.
Another technique is to let AIs from different vendors debate each other. I installed Codex CLI’s MCP service for Claude Code. I often tell Claude Code:
> “Summarize the problems you couldn’t solve just now and ask Codex for help.”
Or I send Claude Code’s plan to Codex CLI:
> “This is the plan drafted by Claude Code. I want your most professional, blunt, and unsparing feedback.”
Then I feed Codex’s response back to Claude Code.
When I discovered Claude Code’s`/audit` command (around early October), I immediately wrote`/codex-audit` — a clone that uses MCP to call Codex CLI. Using AI to pressure and audit AI works far better than doing it myself.
This approach is essentially a variant of *recursion* — the same principle behind asking Google “how to use Google effectively.” That’s why I don’t spend much time on complex prompt engineering. If you understand recursion, better results are inevitable.
There’s also a personality factor. Engineers must genuinely enjoy **dealing with details**. Otherwise, the work becomes miserable. Every detail contains countless sub-details.
For example: curly quotes vs straight quotes; how noticeable curly quotes are depends on the Latin fonts rather than CJK fonts (something I never knew before VMark); if quotes auto-pair, right double quotes must auto-pair too (a detail I noticed while writing this very article); meanwhile, right curly single quotes should *not* auto-pair. If handling these details doesn’t make you happy, product development will inevitably become boring, frustrating, and even infuriating.
Finally, there’s one more highly opinionated choice worth mentioning. Because I’m not an engineer, I chose what I believe is the more correct path out of necessity:
**I use no IDE at all** — **only the terminal.**
At first, I used the default macOS Terminal. Later, I switched to iTerm for tabs and split panes.
Why abandon IDEs like VSCode? Initially, because I couldn’t understand complex code — and Claude Code often caused VSCode to crash. Later, I realized I didn’t need to understand it. AI-written code is vastly better than what I — or even programmers I could afford to hire (OpenAI’s scientists aren’t people you can hire) — could write. If I don’t read the code, there’s no need to read diffs either.
Eventually, I stopped writing documentation myself (guidance is still necessary). The entire [https\://vmark.app](https://vmark.app) website was written by AI; I didn’t touch a single character — except for reflections on vibe coding itself.
This is similar to how I invest in secondary markets. I have an accounting background, so I *can* read financial statements — but I *never* do. My philosophy sounds absurd: good companies are obvious without financials. The key isn’t financial statements; it’s whether you can hold for the long term (at least ten years). That has nothing to do with financial statements.
That’s why the VMark website includes this credit:
> I am just a *Producer*.
Another consequence of being highly opinionated: even if VMark is open-sourced, community contributions are unlikely. It’s built purely for my own workflow; many features have little value for others. More importantly, a Markdown editor is not cutting-edge technology. It’s one of countless implementations of a familiar tool. AI can solve virtually any problem related to it.
Claude Code can even read GitHub issues, fix bugs, and automatically reply in the reporter’s language. The first time I saw it handle an issue end-to-end, I was completely stunned.
Throughout the process of building VMark, I often found myself thinking about my children’s future education. AI’s greatest impact on ordinary people will be in education.
First, age 15 is likely a real watershed. Any effective education must be completed before then. Everything afterward is self-education and self-cultivation. Before that, building reading endurance is crucial.
Second, school education has long been proven ineffective. If you don’t treat school primarily as a place for socialization and psychological development — and instead treat it as the main source of education — children are almost guaranteed to become obsolete in the future world
Most importantly, all education should be production-oriented (a view I repeatedly emphasize in *Good Family Education* and *The Truth About Wealth*). The future belongs to producers — especially creators, thinkers, and decision-makers. Execution belongs to machines.
As for children using AI, I have one solid piece of advice worth sharing with parents and kids alike:
> Don’t be easily dazzled by AI.
Making yourself — or others — say “wow” doesn’t matter. What matters is whether you’ve used AI to create something you could *never* have created before. The more complex, real, and useful it is, the better.
A simple litmus test:
> After you start using AI, are you thinking more, or less?
If you’re thinking more — and thinking deeper — then AI is helping you in the right way. If you’re thinking less, then AI is producing side effects.
Also, AI is never a tool for “doing less work.” The logic is simple: because it can do more things, you can think more and go deeper. As a result, the things you *can* do — and *need* to do — will only **increase**, not decrease.
While writing this article, I casually discovered several small issues. As a result, VMark’s version number went from **0.4.12** to **0.4.13**.
And since I’ve started living primarily in the command line, I no longer feel any need for a large monitor or multiple screens. A 13-inch laptop is completely sufficient. Even a small balcony can become an “enough” workspace.
## 相关链接
- [xiaolai](https://x.com/xiaolai)
- [@xiaolai](https://x.com/xiaolai)
- [18K](https://x.com/xiaolai/status/2021217901936771324/analytics)
- [Andrej Karpathy](https://x.com/karpathy/status/1886192184808149383)
- [1.0.82](https://github.com/anthropics/claude-code/commit/b1751f2)
- [2.1.37](https://github.com/anthropics/claude-code/commit/85f28079913b67a498ce16f32fd88aeb72a01939)
- [https\://vmark.app](https://vmark.app/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [9:41 PM · Feb 10, 2026](https://x.com/xiaolai/status/2021217901936771324)
- [18.7K Views](https://x.com/xiaolai/status/2021217901936771324/analytics)
- [View quotes](https://x.com/xiaolai/status/2021217901936771324/quotes)
---
*导出时间: 2026/4/14 14:32:12*
---
## 中文翻译
# 我为什么开发了一个 Markdown 编辑器：VMark
**作者**：xiaolai
**日期**：2026-02-10T13:41:14.000Z
**来源**：[https\://x.com/xiaolai/status/2021217901936771324](https://x.com/xiaolai/status/2021217901936771324)
---
说实话，开发 VMark 对我自己来说首先是一段学习和体验之旅。
我从 2025 年 8 月 17 日开始尝试一种新兴的编程趋势，即所谓的 *vibe coding*（氛围编程）。而 *vibe coding* 这个词本身最早是在 2025 年 2 月 2 日被提出并传播开来的，源自 Andrej Karpathy 的一条帖子。
Andrej Karpathy 是机器学习领域极具影响力的研究者和教育者。他曾在 OpenAI 和特斯拉等公司担任重要职位，后来创立了 Eureka Labs，专注于 AI 原生教育。他的那条推文不仅引入了“vibe coding”这一概念，还在技术圈迅速传播，引发了大量的后续讨论。
等我注意到并开始使用 vibe coding 工具时，已经过去了将近半年。当时 Claude Code 还处于 [1.0.82] 版本。而在我于 2026 年 2 月 9 日撰写本文时，它已经达到了 [2.1.37] 版本，其间经历了 112 次版本更新。
最初，我只是用这些工具来增强我多年前写的一些自动化脚本——比如批量翻译电子书。我意识到，我只不过是在放大自己已有的能力。
如果我本来就会做某件事，AI 能帮我做得更好。如果我本来不会做某件事，AI 常常给我一种“我也可以做到”的幻觉——通常一开始会有“哇”的一声惊叹——然后就什么都没有了。我原本做不到的事情，依然做不到。那些精美的图片、吸睛的视频、长篇大论的文章，在很多时候不过是新时代另一种形式的“Hello World”罢了。
我对编程并非一无所知，但我也肯定算不上真正的计算机工程师。充其量，我只是普通用户中的高级用户。我会一些代码，甚至还出版过一本关于 Python 编程的书。但这并不意味着我就是工程师。这就好比一个会搭茅草屋的人：他比不会搭的人懂得多，但与那些设计摩天大楼或桥梁的人相比，完全不在同一个层次上。
然后，AI 改变了一切。
从最初到现在，我几乎试用了市面上所有的 AI 编程命令行工具：Claude Code、Codex CLI、Gemini CLI，甚至包括 Grok CLI 这样的非官方工具，以及 Aider 这样的开源替代品。但我用得最多的始终是 Claude Code。在 Codex CLI 推出 MCP Server 之后，我用 Claude Code 用得更多了，因为它可以在交互模式下直接调用 Codex CLI。有点讽刺的是，尽管 MCP 协议最早是由 Claude Code 提出的，但它自己至今（截至 2026-02-10）仍未提供 MCP Server。
起初，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，但并不影响我个人使用。
话虽如此，我还是不好意思将它公开发布。我学到的最大一课是：只为自己做的东西是一个*玩具*；为许多人做的东西才是一个*产品*或一项*服务*。
自然，我仍然只是在考虑自己的需求。“阅读”解决之后，下一个我能为自己解决的就是“写作”。于是，在2025年12月27日——也就是圣诞节后从哈尔滨回到北京之后——我开始构建 **VMark**。这个名字的意思就是 *Vibe-coded Markdown Editor*（氛围编码的 Markdown 编辑器）。连它的图标都是氛围编码的：通过 MCP 让 Claude Code 指挥 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 右缩进 Esc 退出
- 我喜欢所见即所得的 Markdown 编辑器，但我讨厌不断切换视图（尽管有时确实必要）。于是我设计了一个 *Source Peek*（源码速览）功能（F5），让我无需切换整个视图就能查看和编辑当前区块的源码。
- 导出 PDF 不那么重要。导出动态 HTML 才重要。
- 等等。
在开发过程中，我犯了无数的错误，包括但不限于：
- 过早实现复杂功能，不必要地膨胀了范围
- 把时间花在后来又被删掉的功能上
- 在多条路径之间犹豫，一次次推倒重来
- 在某条路径上走了太久，才意识到自己缺乏指导原则
简而言之，一个不成熟的工程师可能犯的每一个错误我都经历过——而且不止一次。其结果之一是，从早到晚，我几乎不间断地盯着屏幕。痛苦，却又快乐。
当然，也有我做对了的事情。
例如，在 VMark 的核心功能尚未稳固之前，我就为它添加了一个 MCP Server。这让 AI 可以直接把内容发送进编辑器。我只需在终端里对 Claude Code 说：
> “为测试这个功能提供 Markdown 内容，要全面覆盖各种边界情况。”
每一次，生成的测试内容都让我惊叹——并为我节省了大量的时间和精力。
起初，我完全不知道 MCP 到底是什么。直到我克隆了一个 MCP server 并把它改造成了与 VMark 毫无关系的东西——由此又催生了另一个名为 **CCCMemory** 的项目——我才真正深入理解了它。名副其实的氛围学习（vibe learning）。
在实际使用中，Markdown 编辑器里拥有 MCP 功能 incredibly 有用——尤其是绘制 Mermaid 图表时。在这方面没有人比 AI 更懂。正则表达式也是一样。如今我经常让 AI 把它的输出——分析报告、审计报告——直接发送到 VMark 中。这比在终端或 VSCode 里阅读舒服多了。
到2026年2月2日——也就是 vibe coding 概念诞生整整一年之际——我感觉 VMark 已经成为一款我能真正舒适使用的工具。它仍然有很多 bug，但我已经开始每天用它写作，并在过程中顺手修复 bug。
我甚至加了命令行面板和 AI 精灵（说实话，目前还不太好用，因为各家 AI 服务商各有怪癖）。不过，它显然正走在一条对我而言不断变好的路上——而且我已经离不开它，没法再用其他 Markdown 编辑器了。
六个星期后，我觉得有些细节值得分享给其他像我一样的“非工程师”。
首先，虽然我不是真正的工程师，但幸好我懂基本的 **git** 操作。我用了 git 多年，尽管它看起来像是只有工程师才会用的工具。回想起来，我大概在15年前就注册了 GitHub 账号。
我很少用 git 的高级功能。比如，我没有按 Claude Code 建议的那样使用 git worktree，而是用两台独立的机器。我只用基本命令，全部通过自然语言指令下达给 Claude Code。
所有操作都在分支上进行。我随意折腾，然后说：
> “总结一下目前学到的经验，重置当前分支，我们重新开始。”
没有 git，你根本做不了任何不简单的项目。这对非程序员尤其重要：*学习基本的 git 概念是必须的*。看着 Claude Code 工作，你自然就会学到更多。
其次，你必须理解 **TDD** 工作流。想尽一切办法提高测试覆盖率。理解*测试即边界*这个概念。Bug 是不可避免的——就像粮仓里的米虫。没有足够的测试覆盖率，你就没有机会发现它们。
更重要的是，这里有一条核心的哲学原则：**你并不是在 vibe coding；你是在 vibe thinking**。产品和服务始终是*思考*的结果，而不是*劳动*的必然产物。
AI 已经接管了大量的“*做*”，但在*做什么*、*为什么做*和*怎么做*这些根本性思考上，它只能起辅助作用。危险在于，它总是会顺着你说。如果你依赖它来思考，它会悄悄把你困在自己的认知偏见里——同时让你感觉自己比以往任何时候都更自由。正如那句歌词所唱：
> “我们其实都是自己建造的牢笼中的囚徒。”
我经常对 AI 说的一句话是：
> “把我当作一个你并不特别喜欢的对手。批判性地评估我的想法并直接挑战它们，但保持专业、不带敌意。”
结果始终是高质量的，而且常常出人意料。
另一个技巧是让不同厂商的 AI 互相辩论。我为 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 了。
最终，我连文档都不亲自写了（指导仍然是必要的）。整个 [https\://vmark.app](https://vmark.app) 网站都是 AI 写的；我一个字符都没碰——除了关于 vibe coding 本身的感悟。
这和我在二级市场投资的方式很相似。我有会计背景，所以我*能*读财务报表——但我*从来不读*。我的理念听起来很荒谬：好公司不用看财报也能一眼看出。关键不在于财务报表，而在于你能否长期持有（至少十年）。这与财务报表毫无关系。
所以 VMark 网站上有这样一句致谢：
> 我只是一个 *Producer*。
固执己见的另一个后果是：即使 VMark 开源，也不太可能有社区贡献。它纯粹是为我自己的工作流程打造的；很多功能对别人没什么价值。更重要的是，Markdown 编辑器并不是什么前沿技术，它只是一个熟悉工具的无数实现之一。AI 几乎可以解决与之相关的任何问题。
Claude Code 甚至能读取 GitHub issue、修复 bug，并自动用报告者的语言回复。我第一次看到它端到端地处理一个 issue 时，完全惊呆了。
在构建 VMark 的整个过程中，我常常会想到自己孩子的未来教育。AI 对普通人最大的影响，将体现在教育上。
首先，15 岁很可能是一道真正的分水岭。任何有效的教育都必须在此之前完成。此后的一切，都是自我教育和自我修养。在那之前，培养阅读耐力至关重要。
其次，学校教育的低效早已被证明。如果你不把学校主要当作社交和心理发展的场所——反而把它当作教育的主要来源——那么孩子在未来的世界里几乎注定会被淘汰。
最重要的是，所有教育都应该以生产为导向（这是我在《好的家庭教育》和《财富的真相》中反复强调的观点）。未来属于生产者——尤其是创造者、思考者和决策者。执行属于机器。
至于孩子使用 AI，我有一条切实可行的建议，值得与家长和孩子分享：
> 不要轻易被 AI 迷惑。
让自己——或别人——说一声“哇”并不重要。重要的是，你是否用 AI 创造出了你以前*根本不可能*创造出来的东西。它越复杂、越真实、越有用，就越好。
一个简单的试金石：
> 开始使用 AI 之后，你想得更多了，还是更少了？
如果你想得更多——而且想得更深——那么 AI 正在以正确的方式帮助你。如果你想得更少了，那么 AI 正在产生副作用。
另外，AI 绝不是“少干活”的工具。道理很简单：正因为它能做更多的事情，你才能想得更多、想得更深。结果，你能做的——以及需要做的——事情只会**增加**，而不会减少。
写这篇文章的过程中，我顺手发现了几个小问题。于是，VMark 的版本号从 **0.4.12** 升到了 **0.4.13**。
而且，自从我开始主要在命令行中生活之后，我不再觉得需要大显示器或多屏幕了。一台 13 英寸的笔记本电脑完全够用。甚至连一个小阳台都可以成为一个“足够”的工作空间。
## 相关链接
- [xiaolai](https://x.com/xiaolai)
- [@xiaolai](https://x.com/xiaolai)
- [18K](https://x.com/xiaolai/status/2021217901936771324/analytics)
- [Andrej Karpathy](https://x.com/karpathy/status/1886192184808149383)
- [1.0.82](https://github.com/anthropics/claude-code/commit/b1751f2)
- [2.1.37](https://github.com/anthropics/claude-code/commit/85f28079913b67a498ce16f32fd88aeb72a01939)
- [https\://vmark.app](https://vmark.app/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [9:41 PM · Feb 10, 2026](https://x.com/xiaolai/status/2021217901936771324)
- [18.7K Views](https://x.com/xiaolai/status/2021217901936771324/analytics)
- [View quotes](https://x.com/xiaolai/status/2021217901936771324/quotes)
---
*导出时间: 2026/4/14 14:32:12*
