doocs/md：把 Markdown 变成微信圖文，但圖床設定才是真正考驗
✍ WeChat Markdown Editor | 一款高度简洁的微信 Markdown 编辑器：支持 Markdown 语法、自定义主题样式、内容管理、多图床、AI 助手等特性
秒懂
- 它是什麼？
- doocs/md 是一款把 Markdown 即時渲染成微信圖文的開源編輯器，強調簡潔與自訂主題。它解決了公眾號排版痛點，但多圖床與 AI 整合的設定複雜度，值得你先想清楚。
- 適合誰用？
- doocs/md 適合內容創作者、技術寫作者，以及需要快速產出乾淨微信圖文的人，尤其是那些已經熟悉 Markdown 且不想在排版上花太多時間的使用者。不適合需要複雜排版控制、或無法接受把圖片上傳到第三方服務的人。
- 可以商用嗎？
- 可以。WTFPL 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
編輯器要解決的，是公眾號排版地獄
寫微信公眾號的人都知道，把一篇 Markdown 貼進公眾號後台，格式會全部跑掉。doocs/md 的定位很清楚，它把 Markdown 文件即時渲染成微信圖文的樣式，讓作者專注在寫作而不是調整行距和字級。這個專案針對的是內容創作者，尤其是那些已經習慣用 Markdown 寫技術文章或筆記的人。對他們來說，與其記住公眾號那套繁瑣的排版規則，不如用一個能直接輸出乾淨版面的工具。專案描述裡也明說，現有的開源微信 Markdown 編輯器普遍樣式繁雜，需要反覆調整，而 doocs/md 想提供更簡潔的替代方案。這不是一個通用的文件編輯器，它只服務一個狹窄但真實的需求：把 Markdown 變成能直接貼進公眾號的 HTML。
即時渲染、主題與擴充語法，機制藏在細節裡
doocs/md 的核心機制是即時渲染。你輸入 Markdown，右側或同頁面就同步顯示成微信圖文的樣式。根據 README，它支援標準 Markdown、數學公式（KaTeX）、Mermaid 圖表、PlantUML 和 GFM 警告塊。這代表你不只寫文字，還能嵌入流程圖或序列圖。程式碼區塊有多種高亮主題，也能自訂主題色與 CSS。比較特別的是 Ruby 注音擴充，格式是 `[文字]{注音}` 或 `[文字]^(注音)`，這對需要標註日文讀音或中文拼音的人很有用。底層技術是 Vue 3、Vite 和 Tailwind CSS，這從 topics 可以看出。整個編輯器是單頁應用，資料存在瀏覽器的本地草稿，並支援自動保存。雲端同步則需要登入帳戶，這點在功能清單中特別註明。換句話說，即時渲染不是魔法，而是透過前端框架把 Markdown 轉換成符合微信規範的 HTML 結構，再套上主題樣式。
部署與執行，線上版和自架的選擇
最簡單的使用方式是直接開 https://md.doocs.org，README 建議用 Chrome。如果你想自己跑，專案是 Node.js 應用，要求 node 版本大於等於 22。從釋出紀錄看，v2.1.0 是 2025 年 10 月釋出，代表仍在維護。專案也有 Docker image，在 Docker Hub 上標為 latest。若要從原始碼建置，你可能需要先 `npm install` 再 `npm run dev` 或類似指令，但 README 沒有明確列出建置步驟，這點需要自己看 repository 的 package.json。另外，專案提供 npm 套件 `@doocs/md-cli`，這暗示有命令列工具可以批次轉換 Markdown 到微信格式。如果你不想依賴線上服務，自架 Docker 版本是可行的，但要注意線上版的雲端同步功能需要登入，自架時是否連動到 doocs 的伺服器，這在 README 中沒有詳細說明。
圖床是功能亮點，也是設定陷阱
doocs/md 支援的圖床多達十三種，從 GitHub、阿里雲、騰訊雲到 MinIO、S3、Cloudflare R2，甚至 Telegram。這個數量很驚人，但也暗示一個問題：每種圖床都需要不同的設定參數。以 GitHub 為例，你得設定 `Repo` 和 `Token`，而 token 的取得方式要另外看 GitHub 文件。阿里雲需要 `AccessKey ID`、`AccessKey Secret`、`Bucket`、`Region`。MinIO 則要 `Endpoint`、`Port`、`UseSSL` 等。每個服務都有對應的教學連結，但這代表使用者得先理解雲端物件儲存的概念。預設圖床不需要任何設定，這是最低門檻的選項，但預設圖床的圖片會存在哪裡？README 只寫「預設」並無說明，這是一個值得注意的盲點。如果你只是偶爾寫一篇文章，用預設圖床最省事，但若你經營公眾號且需要長期穩定的圖片網址，自己設定 GitHub 或 S3 圖床才是正解。
AI 助手與內容管理，是加分還是干擾
功能清單提到整合主流 AI 模型，包括 DeepSeek、OpenAI、通義千問、騰訊混元、火山方舟和 302.AI。這代表編輯器內建 AI 輔助寫作，可能是生成段落或改寫文字。但 README 沒有詳細說明 AI 助手的實際操作方式，例如是對話框還是自動補全。這點讓人心存疑問：一個號稱高度簡潔的編輯器，加入 AI 功能後是否還能保持簡潔？內容管理則包括本地草稿和自動保存，這對長篇文章很有用，避免瀏覽器當機時遺失內容。雲端同步需要登入帳戶，但 README 只給了一個雲同步說明的連結，沒有解釋同步的範圍是編輯器偏好還是包含草稿內容。如果你在多台裝置間工作，這個差異會影響你的使用流程。整體來說，AI 助手是行銷亮點，但實際效益要看你是否信任第三方 AI 服務處理你的文章內容。
真正的限制：依賴微信生態與圖床服務
doocs/md 最大的限制在於它只服務微信公眾號。如果你需要同時發布到其他平台，例如知乎或自己的部落格，這個編輯器輸出的格式可能無法直接複用。其次，所有圖片上傳都依賴外部服務，無論是預設圖床還是你設定的雲端儲存。一旦某個圖床服務停止或政策改變，你文章中的圖片網址可能失效。這在 README 中沒有提及任何備份或遷移機制。另外，程式碼區塊的主題和 CSS 自訂雖然靈活，但如果你不熟悉 CSS，調整樣式可能會花掉不少時間，這與專案宣稱的「專注寫作」有所矛盾。最後，AI 整合需要你提供 API 金鑰或使用第三方代理服務（如 302.AI），這會增加隱私與成本考量。對於只是想要快速排版的人來說，doocs/md 可能過於複雜；對於技術能力強的人來說，這些功能又可能不夠深入。
替代工具與差異：從 markdown-nice 到自建流程
市場上已經有類似的開源工具，例如 markdown-nice（mdnice），它同樣提供 Markdown 轉微信圖文的功能。主要的差異在於 doocs/md 的圖床整合更廣，且內建 AI 助手。mdnice 的設計更偏向純排版，沒有那麼多外部服務的依賴。如果你只需要簡單的轉換，mdnice 可能更輕量。另一方面，如果你已經有固定的圖片上傳流程，例如使用 PicGo 搭配 GitHub，那 doocs/md 的內建圖床反而可能跟你的既有工具重疊。另一種替代方案是自行用 Pandoc 或 Hexo 的插件來產生 HTML，再手動貼進公眾號，但這需要更多技術背景。doocs/md 的優勢在於它把渲染、上傳和儲存在一個介面完成，缺點是這些功能被綁在一起，你無法只選用其中一部分。
維護與授權：WTFPL 的雙面性
doocs/md 採用 WTFPL 授權，這是最寬鬆的授權之一，代表你可以自由使用、修改和散布，甚至不需要保留版權聲明。但反面來說，這也意味著專案不提供任何擔保，若有 bug 或安全問題，你無法要求作者負責。從釋出頻率看，v2.1.0 在 2025 年 10 月發布，v2.0.4 在同年 6 月，專案仍算活躍。但最後一次 push 是 2026 年 9 月（根據資料），這可能是未來的日期，也可能是資料錯誤，無法確認。如果你要自架，升級成本取決於你如何部署。用 Docker 的話，更新只要拉新 image；但如果你修改了原始碼，每次升級都可能需要合併衝突。雲端同步功能依賴 doocs 的伺服器，若你自架且未連動，可能無法使用該功能。整體來說，WTFPL 讓你可以放心採用，但你也得自己承擔長期維護的責任。
編輯結論
doocs/md 適合內容創作者、技術寫作者，以及需要快速產出乾淨微信圖文的人，尤其是那些已經熟悉 Markdown 且不想在排版上花太多時間的使用者。不適合需要複雜排版控制、或無法接受把圖片上傳到第三方服務的人。採用前，你應該先確認你的圖床策略：如果只用預設圖床上傳，那風險最低；若要使用 GitHub 或雲端物件儲存，務必先閱讀 docs 目錄下的各圖床教學，並測試 token 與權限設定。另外，登入帳戶才能同步偏好，若你只想離線使用，則需自行部署或接受偏好不跨裝置。最後，因為授權是 WTFPL，你可以自由修改，但也就沒有來自社群的任何擔保，出問題時得靠自己。
社群筆記