VMark 解读：李笑来的 AI 原生 Markdown 编辑器，为什么它只收 issue 不收 PR

资讯

一位自称"顶多算普通用户里的 Power User"的写作者，用 AI 从零做了一个 Markdown 编辑器。它现在有 770 个 star、5,000 多次提交，而且就在今天（2026 年 9 月 22 日）刚发布了 0.9.82 版。这个项目叫 VMark，发起人是李笑来（@xiaolai），代码几乎全部由 AI 写成——他自己在项目里署的名不是"创始人"也不是"核心开发者"，只有一行字：Producer（制作人）。

VMark 当然是个编辑器，但更有意思的是它背后的那套东西：一个人怎么用 AI 维护一个中型项目、为什么它只收 issue 却明确拒绝外部 PR、以及"让一个 AI 写代码、再让另一个 AI 来挑刺"这套流程到底怎么跑。工具层面的东西（尤其是中文排版）也很实在，下面一并讲清楚。

一、VMark 是什么

先给结论：它是一款免费、开源（ISC 协议）、本地优先的 Markdown 编辑器，官方给自己的定义是 "An AI friendly markdown editor"（对 AI 友好的 Markdown 编辑器），官网的口号则是 "The Plain-Text Workspace Where Humans and AI Collaborate"——人和 AI 协作的纯文本工作空间。

  • 官网：vmark.app；代码仓库：github.com/xiaolai/vmark
  • 主平台：macOS（原生支持 Apple Silicon 与 Intel）。Windows 与 Linux 属于"尽力而为"级别，但今天的 0.9.82 发行包里其实 .exe、.msi、.rpm、.deb、AppImage 都齐了
  • 技术栈：Tauri v2（Rust）+ React 19 + TypeScript + Tiptap + CodeMirror 6
  • 隐私：不联网、不需要账号、不做数据收集，文档全部留在本机

绕不开的一点是它的作者。李笑来（@xiaolai）此前是前新东方英语老师、作家、投资人，在加密货币领域有过争议很大的公开经历。他在这件事上的身份则简单得多：一个懂一点 Python、出版过程序书，但自称"不是工程师"的用户——关于这个身份定位，他自己的说法是"这就好像一个能盖草房的人，虽然比不会盖草房的人多懂些技术，但和那些能设计大厦或者桥梁的人，完全不是同一个物种"。

二、它最核心的差异：MCP 原生，你和 AI 改的是同一份文件

市面上大多数"AI 编辑器"的思路是加一个侧边栏聊天框：你在左边写，AI 在右边答，你还得自己把内容复制来粘贴去。VMark 走的是另一条路——内置 MCP（Model Context Protocol）服务器，让 AI 直接读写你正在编辑的那个文件本身，中间没有任何格式转换。

接法很简单：Settings → Integrations → Install，每个助手一次点击。目前官方列出的支持列表包括 Claude Desktop、Claude Code、Codex CLI、Antigravity CLI、Grok CLI 和 opencode。

李笑来自己描述实际用法时说，他常让 AI 把分析报告、审核报告这类输出直接发进 VMark 里看，"比在 Terminal（或者 VSCode）里阅读舒服太多了"；画 Mermaid 图表时更顺手，因为"没有谁比 AI 更熟悉这种东西"。他在开发早期就给 VMark 加了 MCP 服务，理由是——这样可以随时要求 AI 生成覆盖各种边界情况的测试文本塞进来。

三、Markdown 之外：多格式，而且"认识"文件的结构

它不只是个 Markdown 编辑器，能打开的东西包括 Markdown、JSON / JSONL、YAML、TOML、Mermaid、SVG、HTML（沙箱内渲染）以及纯文本；各种代码文件（.ts、.py、.rs、.go、.css 等）会以语法高亮的形式打开，也可以就地编辑或丢给外部编辑器。

比较聪明的一点是按文件类型给"对的视图"：

  • 打开 .github/workflows/ci.yml，它画的是工作流流程图，而不是一堆 YAML 文本
  • 打开 Cargo.toml、package.json、pyproject.toml，它给的是依赖关系树
  • 普通的 JSON / YAML / TOML 则渲染成可展开折叠的树

编辑体验上还有几个点：三种 Markdown 模式可以在写作中切换（WYSIWYG 所见即所得、F5 的 Source Peek 只查看当前段落源码、F6 的纯源码模式）；多光标支持 Mod + D 选中下一个相同项、Alt + Click 手动加光标；括号和引号会自动配对，按 Tab 能直接跳出；官方说有 165 个快捷键，全部可自定义。界面内置 10 种语言（含简繁中文、日文、韩文等），首次启动会按系统语言自动匹配；macOS 上有 6 套主题。

四、对中文用户最实在的一块：中文排版

这是很多中文写作者真正会为它买单的地方。VMark 内置了 20 多条 CJK 排版规则，一个快捷键就能完成中英文之间加空格、全角标点转换、直角引号「」的替换这类操作——写技术文档的人通常都被中英文混排的间距折磨过。

而它的偏好多半来自作者本人的"洁癖"，他自己列过几条：汉字之间必须有字间距，但混排的英文单词内部不能有字间距；表格只允许首行有背景色（他明确说讨厌斑马纹）；行间距必须可以随时调；只有 H1 有下划线。这些需求单独看"毫无商业价值"，但他认为这恰恰是 Vibe Coding 的必然结果——后面会讲到为什么。

五、上手：五步

  1. 安装（macOS）：brew install xiaolai/tap/vmark；也可以去 GitHub 的 Releases 页下载 .dmg（Apple Silicon 与 Intel 分开打包）。Windows / Linux 用户同样在 Releases 页找对应格式。
  2. 启动：拖进"应用程序"文件夹，打开即可。不需要注册账号，也不需要联网。
  3. 接 AI：进 Settings → Integrations，选中你在用的助手，点 Install，一次点击完成 MCP 配置。
  4. 开始写：默认是所见即所得；按 F5 查看并修改当前段落的 Markdown 源码，按 F6 切到纯源码模式。
  5. 需要时再开高级功能：焦点模式、打字机模式、文档历史、表格与图片居中，都在设置里，默认不打扰你。

六、真正值得读的部分：这个项目是怎么被造出来的

如果只把 VMark 当成一个编辑器，你大概只会觉得"做得还不错"。它真正被技术圈反复讨论的，是它的生产方式。

1）整个项目是 vibe-coded，而且只收 issue，不收 PR

仓库 README 里写得很直白："VMark is vibe-coded — written entirely by AI under human supervision."（VMark 是 vibe-coded 的，整个代码库由 AI 在一位维护者监督下写成。）

于是它做了一个在开源圈很少见的决定：欢迎 issue，但不接受外部 Pull Request。官方文档给出的理由很扎实："one human can't meaningfully review another human's AI-generated code"——一个人没法真正有效地评审另一个人 AI 生成的代码。因为当贡献者的 AI 写代码、维护者的 AI 审代码时，链条里的两个人类反而是最不理解这份代码的人。

他们列了一张表来说明这件事：人写人审，评审者能推理意图；AI 写、原作者审，还部分有上下文；AI 写、另一个人审，就"几乎没有上下文也没有 AI 会话上下文"。而 PR 场景正好落在最后一档。文档还引用了 CodeRabbit 对 50 万+ 个 PR 的分析：AI 生成的 PR 问题数是人工 PR 的 1.7 倍，其中逻辑与正确性错误多出 75%——而这类错误恰恰是"扫一眼看着挺合理、必须逐步走查才能发现"的那种。

所以它的接口变成了：你提一个描述清楚的 issue，AI 带着项目完整上下文（约定、测试、架构）去修。官方把这套流程写成了固定管线：抓取 issue → 分类（bug / feature / 提问）→ 建分支 → TDD 修复（RED → GREEN → REFACTOR）→ 跨模型审计循环（最多 3 轮）→ 跑全量闸门 pnpm check:all → 建 PR。对，最终仍然会开 PR，只不过作者和维护者是同一个人加他的 AI。

2）跨模型校验：Claude 写代码，Codex 来挑刺

这套流程里最有信息量的一环是用两个模型互相对抗：Claude（Anthropic）负责写实现，Codex（OpenAI）独立审计。官方文档给的原话是"You write, I audit"，核心逻辑是——同一个模型写和审，它的盲区会在两遍里都活下来；换成不同厂、不同训练数据、不同架构的模型，盲区就不重合了。

具体实现上，他们用了一个叫 cc-suite@xiaolai 的 Claude Code 插件，把 Codex 挂成 MCP server。有个细节值得注意：Codex 跑在沙箱只读环境里，只能读代码不能改文件，所有修改仍然由 Claude 执行。

官方给出的经验数字是：每次审计，第二个模型通常能多找出 2 到 5 个第一个模型漏掉的问题——包括逻辑错误、边界情况（null、空值、Unicode、并发）、重构后的死代码、以及被"合理化"掉的约定违规。成本呢？每次审计几秒钟的 API 时间。

顺带说，这套"让 AI 挑 AI 的刺"不是拍脑袋。文档里列了四篇研究：多智能体辩论能提升事实性与推理准确率（ICML 2024）、角色扮演提示在 12 个推理基准上稳定优于零样本（NAACL 2024）、前沿模型能察觉自己正在被评估（2025），以及——最后一个很有意思——当评审者是 AI 而不是人类时，模型那种"顺着用户说"的谄媚压力会被移除（ICLR 2024）。这解释了为什么"换个模型来审"比"自己再审一遍"有效。

3）一个人的提示词：把 AI 当成不喜欢你的对手

李笑来在手记里也讲过他自己的土办法：让 Claude 写一个方案发给 Codex，附一句"这是 Claude 写的，你给我最专业、最不留情的反馈"，再把批评丢回给 Claude 让它改。他的评价是"用 AI 卷／督促 AI，效果比我自己督促它们好太多了"。

他还写了一条自己常用的提示词，每次都有意外收获：

"Treat me as a rival you don't particularly like. Evaluate my ideas critically and challenge them directly."

七、作者自己的几个判断

他在开发手记《我为什么制作了一个 Markdown 编辑器 VMark?》里把过程和教训都摊开了。时间线大致是：2025 年 8 月 17 日开始尝试 vibe coding；同年 11 月做了个 epub 阅读器；2025 年 12 月 27 日从哈尔滨过完圣诞节回北京，动手写 VMark（名字就是 "Vibe coded Markdown Editor" 的意思，连图标都是 AI 通过 MCP 指挥 SketchApp 画的）；2026 年 1 月 27 日把 alpha 换成 beta；2026 年 2 月 9 日开始写那篇手记。

其中有几句话流传很广，也确实是这个项目的方法论底色：

  • "你不是在 Vibe Coding，你其实是在 Vibe Thinking。" 他认为 AI 接管的是"做"的过程，但 What / Why / How 这些最基础的思考它只能起辅助作用；更麻烦的是"它只会顺着你的话说下去"，所以一旦在思考上依赖它，就会被悄悄困在自己的思维定势里。
  • "做出来之后只是给自己用的东西叫'玩具'，做出来之后能给很多人用的才叫'产品'。" 这是他在上一个项目（那个 epub 阅读器）上撞到的墙——自己用得很爽，却"不好意思放出去给别人用"，因为 bug 还在，只是他知道怎么绕过。
  • 必须学一点 git，必须搞懂 TDD。 原话是"没有 git，根本干不了任何稍微大一点的项目"，以及"想尽一切办法提高 Test Coverage，了解 Test as Boundary 的概念"。
  • "AI 从来都不是'少干活'的工具。" 他的判断是：AI 能做很多事的结果，是人可以想得更深，于是自己能做、要做的事只会变多，不可能变少。

他还引了一个他自己问 ChatGPT 得来的工程量参照，这条对想做类似项目的人很有用：能用的 Markdown 编辑器约需 1 人 1–2 周；好用的约 1–2 人 1–3 个月；而"让重度写作者离不开的"，大约要 3–8 人做 1–3 年，且是持续演进型工程。

如果你想看关于 vibe coding 更宏观的行业讨论（Karpathy 造词的原始边界、METR 与安全数据、Simon Willison 的 Vibe Engineering 等等），站内这篇《Vibe Coding 时代，软件工程为什么更重要了》正好可以对照着读——VMark 基本就是那个话题的一个正面样本。另外，李笑来署名的英语学习项目 everyone-can-use-english 站内也有独立教程。

八、几个上手前该知道的边界

  • 它不是成熟商业软件。版本号还在 0.9.x，作者自己说"还有大量的 bug"，定位也是"自己用着顺手"再逐步向外。它在快速迭代（今天的提交还在往上走），但别期待企业级支持。
  • 平台权重不均。macOS 是主平台；Windows / Linux 虽有安装包，官方明确写了是 best-effort，遇到问题优先修的不会是这两个平台。
  • 它是"编辑器"，不是"知识库"。本地优先、不联网、无账号，也就意味着没有云同步、没有多端协同、没有笔记图谱。追求"第二大脑"那套的，应该去看 Obsidian 这类工具。
  • 高度固执己见（Highly Opinionated）。作者本人认为"以后所有 Vibe Coded 软件都是高度固执己见的"，因为整个过程就是"只有我自己和一个绝不争辩的执行者"。它的排版偏好是卖点，也是脾气——你觉得表格该有斑马纹，它不会给你。
  • 不收 PR 这件事要有心理预期。你提交的代码合并建议不会被采纳，但你提的 issue 会被 AI 认真处理。

九、一句话总结

VMark 的价值有两层：工具层，它是少见的把"AI 直接读写同一份文件"做成默认工作流、并且对中文排版较真的免费编辑器；方法层，它公开示范了一个人 + 多个 AI 怎么维护一个中型项目——从 issue 即规格、TDD 即边界，到用另一个模型当"不留情的对手"。如果你关心的不是"AI 能不能写代码"，而是"AI 写了代码之后，人还剩什么活要干"，那么它的官方文档可能比软件本身更值得花时间。

参考来源

说明：本文为介绍与解读类文章，未做工具实测。产品能力、版本号、star 数、开发流程等内容均引自官方站点、官方仓库的 README 与文档，以及作者本人的开发手记；文中引用的第三方研究数据出自官方文档所列来源。具体功能与数据请以官方页面为准。

腾讯云精选福利

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

腾讯云精选福利