為什麼我要打造 Markdown 編輯器：VMark
TL;DR
一位非程式設計師在 2025 年 8 月開始 Vibe Coding，在六週內打造了 VMark — 一款 Markdown 編輯器。核心心得：git 是必備的（它是你的復原鍵）、TDD 讓 AI 保持誠實（測試是對抗 Bug 的邊界）、你是在 Vibe Thinking，不是 Vibe Coding（AI 負責執行，你負責判斷），以及 跨模型辯論勝過單一模型信任。這段歷程證明了使用者可以成為開發者 — 但前提是他們必須投入在幾項基礎技能上。
起源
說實在的，打造 VMark 對我來說，主要是一段學習與體驗的旅程。
我在 2025 年 8 月 17 日開始嘗試一種新興的程式設計趨勢，稱為 Vibe Coding。「Vibe Coding」這個詞本身最早是在 2025 年 2 月 2 日由 Andrej Karpathy 在 X（前身為 Twitter）上發文時提出並廣泛流傳的。
Andrej Karpathy 是機器學習領域極具影響力的研究者和教育者。他曾在 OpenAI 和 Tesla 等公司擔任重要職位，後來創辦了 Eureka Labs，專注於 AI 原生教育。他的這條推文不僅引入了「vibe coding」的概念，也迅速在技術社群傳播，引發了廣泛的後續討論。
當我注意到並開始使用 Vibe Coding 工具時，距離它的誕生已近半年。那時，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（Vibe Coding 的 Markdown 編輯器）。就連它的圖示也是 Vibe Coding 出來的：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 是 高度主觀的。事實上，我懷疑所有 Vibe Coding 的軟體和服務都會如此。這是不可避免的，因為 Vibe Coding 本質上是一個沒有會議的生產過程 — 只有我和一個從不反駁的執行者。
以下是我的一些個人偏好：
所有非內容資訊都必須保持在主區域之外。就連格式選單也放在底部。
我有頑固的排版偏好。
中文字之間必須有間距，但嵌入中文中的英文字母則不能有。在 VMark 之前，沒有任何編輯器能滿足這個小眾的、商業上毫無價值的需求。
行距必須隨時可調。
表格只有標題行才能有背景色。我討厭斑馬條紋。
表格和圖片應該可以置中。
只有 H1 標題應該有底線。
一些通常只在程式碼編輯器中才有的功能必須存在：
多游標模式
多行排序
標點符號自動配對
其他是可選的，但很好用：
Tab 鍵右跳脫
我喜歡所見即所得的 Markdown 編輯器，但我討厭不斷切換視圖（儘管有時是必要的）。所以我設計了來源預覽功能（F5），讓我可以在不切換整個視圖的情況下，查看和編輯當前區塊的原始碼。
匯出 PDF 不那麼重要。匯出動態 HTML 才重要。
等等。
錯誤與突破
開發過程中，我犯了無數錯誤，包括但不限於：
過早實作複雜功能，不必要地膨脹了範疇
花時間在後來被移除的功能上
在路徑之間猶豫，一再重新開始
沿著一條路走太久，才意識到缺乏指導原則
總之，我犯了一個不成熟的工程師能犯的每一個錯誤 — 而且犯了很多次。結果是，從早到晚，我幾乎不間斷地盯著螢幕。痛苦，卻也快樂。
當然，也有做對的事情。
例如，在 VMark 的核心功能還未穩固之前，我就為它加入了 MCP Server。這讓 AI 可以直接將內容傳送到編輯器中。我可以簡單地在終端機中告訴 Claude Code：
「提供用於測試此功能的 Markdown 內容，全面覆蓋邊界情況。」
每次，生成的測試內容都讓我驚嘆不已 — 並節省了大量的時間和精力。
起初，我根本不知道 MCP 究竟是什麼。我是在複製了一個 MCP Server 並將其修改成與 VMark 完全無關的東西之後，才深入理解了它 — 這衍生了另一個名為 CCCMemory 的專案。這就是 Vibe Learning。
在實際使用中，Markdown 編輯器裡有 MCP 是極其有用的 — 尤其是在繪製 Mermaid 圖表時。沒有人比 AI 更懂這些。正規表示式也一樣。我現在常常請 AI 將它的輸出 — 分析報告、稽核報告 — 直接傳送到 VMark。這比在終端機或 VSCode 中閱讀要舒服得多。
到 2026 年 2 月 2 日 — 正好是 Vibe Coding 概念誕生一周年 — 我感覺 VMark 已成為我可以真正舒適使用的工具。它仍然有很多 Bug，但我已經開始每天用它寫作，邊用邊修 Bug。
我甚至加入了命令列面板和 AI 精靈（說實話，因為不同 AI 供應商的怪癖，目前還不太好用）。儘管如此，它顯然走在一條不斷為我改善的道路上 — 我已經無法再使用其他 Markdown 編輯器了。
Git 是必備的
六週後，我覺得有些細節值得與其他像我一樣的「非工程師」分享。
首先，雖然我不是真正的工程師，但幸好我懂基本的 git 操作。我用 git 已經好多年了，儘管它看起來是一個只有工程師才用的工具。回頭想想，我大概在 15 年前就註冊了 GitHub 帳號。
我很少使用高級的 git 功能。例如，我不像 Claude Code 推薦的那樣使用 git worktree。我用兩台獨立的機器代替。我只使用基本指令，全部透過自然語言指示給 Claude Code 執行。
所有事情都在分支上進行。我自由地折騰，然後說：
「總結目前學到的教訓，重置當前分支，讓我們重新開始。」
沒有 git，你根本無法進行任何非平凡的專案。這對非程式設計師尤其重要：學習基本的 git 概念是必備的。光是看 Claude Code 工作，你就會自然地學到更多。
其次，你必須了解 TDD 工作流程。盡一切可能提高測試覆蓋率。理解「測試作為邊界」的概念。Bug 是不可避免的 — 就像糧倉裡的米蟲。沒有足夠的測試覆蓋率，你根本沒有機會找到它們。
Vibe Thinking，不是 Vibe Coding
這是核心哲學原則：你不是在 Vibe Coding；你是在 Vibe Thinking。產品和服務永遠是思考的結果，而不是勞動的必然產物。
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，效果遠比我自己來好得多。
這種方法本質上是遞迴的變體 — 與「如何有效使用 Google」這個問題背後的原理相同。這就是為什麼我不花太多時間在複雜的提示工程上。如果你理解遞迴，更好的結果是必然的。
只用終端機
還有一個性格因素。工程師必須真正享受 處理細節。否則，工作就會變得很痛苦。每個細節都包含無數的子細節。
例如：彎引號 vs 直引號；彎引號是否明顯取決於拉丁字型而非 CJK 字型（這是我在 VMark 之前從未了解的事）；如果引號自動配對，右雙引號也必須自動配對（這是我在撰寫本文時注意到的細節）；但右彎單引號則不應自動配對。如果處理這些細節不讓你開心，產品開發就不可避免地會變得枯燥、令人沮喪，甚至憤怒。
最後，還有一個值得一提的高度主觀選擇。因為我不是工程師，我出於必要選擇了我認為更正確的路徑：
我完全不用 IDE — 只用終端機。
起初，我用的是 macOS 預設的終端機。後來，我換成了 iTerm，以獲得分頁和分割視窗功能。
為什麼放棄 VSCode 等 IDE？最初是因為我看不懂複雜的程式碼 — 而且 Claude Code 常常導致 VSCode 崩潰。後來，我意識到我根本不需要看懂它。AI 寫的程式碼比我 — 或者甚至是我請得起的程式設計師（OpenAI 的科學家可不是你能雇用的人）— 能寫的要好得多。如果我不讀程式碼，也就不需要讀差異了。
最終，我停止自己撰寫文件（指引仍然是必要的）。整個 vmark.app 網站都是由 AI 撰寫的；我沒有觸碰一個字 — 除了關於 Vibe Coding 本身的反思。
這和我的投資方式很像：我可以讀財務報表，但我從不讀 — 好公司不需要靠報表就能看清楚。重要的是方向，不是細節。
這就是為什麼 VMark 網站上有這樣的致謝：
高度主觀的另一個後果：即使 VMark 是開源的，社群貢獻也不太可能發生。它純粹是為我自己的工作流程打造的；許多功能對其他人幾乎沒有價值。更重要的是，Markdown 編輯器並非尖端技術。它是一個熟悉工具的無數實現之一。AI 幾乎可以解決與它相關的任何問題。
Claude Code 甚至可以讀取 GitHub Issues、修復 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 系統性地迎合使用者現有的信念，而不是提供真實的回應 — 研究人員將這種行為稱為諂媚性。在五個最先進的 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 是 Piaget 的學生，他認為打造有形的產品（軟體、工具、創意作品）能激發比傳統教學更深層的認知過程。John Dewey 在一個世紀前也提出了類似的論點：教育應該是體驗式的，與解決現實問題相連，而不是死記硬背。參見：Papert, S. & Harel, I. (1991). Constructionism. Ablex Publishing; Dewey, J. (1938). Experience and Education. Kappa Delta Pi. ↩︎
一項針對 666 名參與者的 2025 年研究發現，頻繁使用 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). ↩︎