微信公眾號 Markdown 排版工具 · 6 套主題一鍵生成可貼上 HTML

解決什麼

公眾號運營者長期面臨排版痛點:手動在編輯器裡調格式耗時費力,用第三方工具(135編輯器/秀米)又要來回切換平臺,粘貼後樣式經常丟失。技術內容創作者習慣用 Markdown 寫作,但公眾號編輯器不直接支援,需要人工轉換並重新排版。該專案提供一套自動化流程:寫完 Markdown 後,通過 AI Agent(Claude Code/Codex/Cursor)呼叫預設主題和元件庫,生成樣式全內聯、符合微信平臺規範的 HTML,一鍵複製貼上即可釋出,全程無需手動調格式。

為何火

1455 stars 的熱度源於三個核心優勢:平臺適配徹底(所有樣式內聯、文字用 <span leaf=""> 包裹,規避公眾號會過濾的 <style>/class/grid 等寫法)、主題質量高(6 套主題由兩位公眾號實踐者聯合打磨,覆蓋教程/測評/深度分析等常見題材)、AI Agent 友好(輸入輸出全是純文本,任何 Agent 都能呼叫,不依賴特定模型)。專案在 2026-07-01 建立後一週內即釋出正式版,說明作者對需求把握精準且執行力強。

核心功能

• 6 套精選主題:摸魚綠(預設,適合教程測評)、紅白(深度分析)、石墨極簡(設計科技)、留白禪意(隨筆)、摸魚票據(工具對比)、橄欖手記(內刊復盤),每套包含完整元件庫(設計變數+數十個元件+視覺層級表)
• 主題生成器:通過一句話描述或參考圖,讓 AI 生成全新主題並儲存本地複用
• 智慧排版:自動章節編號(末章用 ∞ 或 ///)、每段標記 1-3 個關鍵詞下劃線、從正文提煉引言卡與目錄、作者簽名去重合並
• 內容相容:支援程式碼塊(深/淺色可選)、圖片、GIF(帶動圖角標)、行內程式碼、引用、列表、產品徽章
• 雙關卡校驗:component_lint.py 檢查元件庫源頭,validate_gzh_html.py 檢查最終產物,確保 0 ERROR 才交付
• 一鍵複製:生成帶複製按鈕的預覽頁,點選後富文本進剪貼簿,直接粘進公眾號編輯器

安裝

方式一(推薦):

npx skills add https://github.com/isjiamu/gzh-design-skill

方式二:對任意 AI Agent 說"請幫我安裝 https://github.com/isjiamu/gzh-design-skill 這個 skill",它會自動 clone 到對應目錄

方式三:手動克隆

git clone https://github.com/isjiamu/gzh-design-skill.git ~/.claude/skills/gzh-design

裝好後直接對 Agent 說:"用摸魚綠把這篇文章排成公眾號 HTML:article.md",它會自動選主題、讀元件庫、解析 Markdown、裝配 HTML、跑校驗、輸出預覽頁。

適合誰

• 公眾號運營者:需要高頻發文且對排版有要求,用本工具可節省 80% 排版時間
• 技術博主/教程作者:習慣用 Markdown 寫作,需要把技術文件轉成公眾號格式(支援程式碼塊高亮、自動編號)
• 內容團隊:多人協作時用 Markdown 統一格式,最後批次轉換,保證視覺風格一致
• AI Agent 使用者:已在用 Claude Code/Cursor/Codex,可無縫整合該 Skill 擴充套件能力

不適合:純圖片海報製作、PPT 生成、普通網頁開發、非公眾號平臺排版。專案明確宣告"只排版不寫作",需先有 Markdown 內容才能使用。

社群評價

暫無足量社群公開討論,以下為基於專案本身的中立評估:

專案在一週內獲得 1455 stars 和 161 forks,說明需求真實且解決方案有效。README 文件詳盡(含完整使用流程、主題速查表、常見場景對照),作者提供企業微信交流群二維碼,顯示出較強的社群運營意願。技術上採用"約束優於自由"的設計哲學,通過預設主題和指令碼校驗保證輸出質量,而非依賴模型自由發揮,這在實際應用中更可靠。專案由兩位公眾號實踐者聯合共建,主題設計和質量標準來自真實運營經驗,實用性較強。

選型對比

vs 135編輯器/秀米(商業工具):

• 135/秀米優勢:視覺化編輯、模板更多、有客服支援
• 本專案優勢:完全免費、Markdown 原生支援、AI Agent 自動化、樣式不依賴第三方平臺、可自定義主題生成器

vs Markdown Nice(同類開源):

• Markdown Nice 是線上編輯器,需手動操作;本專案是 AI Agent Skill,可程式設計呼叫
• Markdown Nice 主題更豐富但不可程式設計生成;本專案內建主題生成器
• 本專案雙關卡校驗更嚴格,專門針對公眾號平臺限制做兜底

取捨建議:偶爾發文且不懂技術選 135/秀米;高頻發文且用 Markdown 寫作選本專案;需要視覺化調整細節選 Markdown Nice。

已知坑

1. 單人維護風險:貢獻者數為 1,若作者停更可能影響後續支援(但專案已釋出正式版且功能完整)
2. 依賴 AI Agent:必須配合 Claude Code/Cursor 等工具使用,不能獨立執行,普通使用者有學習成本
3. 主題定製門檻:雖有主題生成器,但理解元件庫結構需要一定技術背景,非技術使用者難以深度定製
4. 平臺規則變化:公眾號若調整 HTML 過濾規則,需及時更新校驗指令碼(README 提到"確定性檢查"但仍需人工維護規則庫)
5. 圖片處理侷限:README 未說明圖片上傳邏輯,可能需手動上傳到公眾號素材庫後再引用 URL
6. AGPL-3.0 傳染性:若基於本專案開發商業服務,衍生程式碼也必須開源,需注意許可證約束

中文使用者注意:專案託管在 GitHub 但無需梯子,直接 clone 即可;作者提供企業微信群,國內使用者交流方便;全形標點自動規範化,符合中文排版習慣。