在 Windows 平臺長進行流程化公眾號寫作

文章目錄[ 隱藏 ]

• Matrix 精選
• 本地圖片
• 圖床選擇
• 圖床配置
• 黏貼 HTML
• 瀏覽器擴展
• 適配公眾號的排版工具

摘要：換句話說，只要微信從公眾號編輯器拉取到圖片，接下來的事情就不用我操心了，哪怕某一天圖床跑路了，文章配圖依然在，它甚至連水印都會幫我打好。就目前看來，這個圖床的鏈接是長期保留的，不過我觀念比較傳統，依然是不習慣於以圖床鏈接的形式來長期保存文章的，所以圖殼對我而言依然是一個臨時圖床，我也就僅將其當作公眾號發布的跳板來使用。

Matrix 精選

Matrix 是少數派的寫作社區，我們主張分享真實的產品體驗，有實用價值的經驗與思考。我們會不定期挑選 Matrix 最優質的文章，展示來自用戶的最真實的體驗和觀點。

文章代表作者個人觀點，少數派僅對標題和排版略作修改。

對於「個人微信公眾號（以下簡稱公眾號）的流程化發布」這個話題，其實在互聯網上被很多人討論過。說實話我自己也鑽研了很長時間，至今仍不敢和人妄下定論「我已經不用擔心公眾號發布的事情」，但是目前的方案和以前相比，確實有了很大提升。話不多說，整理成一篇 Windows 下的公眾號流程化寫作與發布方案 ，以供後來參考。

此外，我還是保持以往寫作的敘事風格，力求把事情說清道明。此外，加粗的部分也為「太長不看」而準備。

說在前面

廣義上看，對於 「碼字→配圖→成文→樣式化→發布」 這樣一個寫作過程，一千名作者眼中有一千種方法。但對於擁有公眾號的作者來說，各種不同的方案所要解決的問題都直指一個共同的核心—— 公眾號該如何流程化發布 。

公眾號的特殊性，導致它的發布條件眾所周知地苛刻：

• 在 Markdown （以下簡稱 M↓）寫作已經很常見的今天，公眾號後臺編輯器仍然是富文檔編輯器
• 並且是巨難用的富文檔編輯器
• 當下流行的第三方編輯平臺同樣既難看又難用，復制到公眾號的格式還嵌套了各種各樣的冗餘樣式

如此種種，不再詳述。

而需要解決好這個問題，重點就應該放在 「流程化」 上。簡言之，就是形成一套 不囿於文章中具體的段落句讀的、整體而宏觀的、一步到位的公眾號發布流程 ，最好同時也能讓公眾號以外平臺的發布得到兼顧。

所以，本文就討論一下，如安在 Windows 上一次性完成主要寫作過程，並流程化發布於公眾號。

先決定寫作應用

對於 Windows 平臺，我非常喜歡 Typora 這款應用。在剛接觸 M↓ 寫作的時候，我就一口氣下載了很多個本地編輯器，最終敲定了 Typora。先簡單說決定性因素：

1. 界面簡潔美觀一款養眼的本地編輯器，對創作有極大的促進作用。
2. 所見即所得很多 M↓ 編輯器存在的問題就是「寫」和「看」很割裂，要麼將渲染前後的樣子以左右兩欄的形式隔開，要麼無法實時渲染、隻對 M↓ 文檔進行簡單的顏色標記。而 Typora 默認在輸入 M↓ 標記後就直接渲染成主題的樣式，這樣也保證了寫作思路的清晰。
3. 自動保存可以手動設置，無需按保存鍵就可以自動保存，這是沉浸式創作中很重要的一點。

Typora 對我來說如此趁手，以至於如果哪天公眾號的條件苛刻到我必須放棄用 Typora 進行本地創作的話，我寧可放棄公眾號。

然後決定圖片

公眾號編輯器難用，圖片問題是大頭。在自己的上一篇文章中，甚至用到了多達 21 張靜態圖片加上 5 張動圖。如果圖片問題無法解決，我便對發布公眾號提不起一絲一毫的欲望。

本地圖片

在使用本地編輯器進行寫作的過程中，配圖往往有以下幾種方法：

• 照片型
• 從互聯網上下載至本地，再導入編輯器
• 直接將互聯網上的照片複製至剪貼板，再黏貼到編輯器
• 截圖型
• 將截圖複製至剪貼板，再黏貼到編輯器
• 將截圖保存在本地，再導入編輯器
• 動圖型
• 將錄制完成的動圖保存在本地，再導入編輯器
• 靈魂畫師、設計師自己制作配圖型
• 將圖片導出到本地，再導入編輯器

其實一眼就可以看出，各種類型萬變不離其宗： 要麼從本地導入，要麼從剪貼板黏貼。 從剪貼板黏貼的好處是方便，能省一步是一步，但是對於素材管理卻是噩夢；從本地導入則更有條理，不過稍稍麻煩一些。

對於長期寫作而言，良好的寫作習慣非常重要。我在生活中是一個很注重條理性的人，這一點性格也被我帶到了數字世界的檔案管理上。我會將每篇文章的 M↓ 文稿都存放於以寫作時間命名的目錄下，並在此目錄下建立一個 ./Img 文件夾，存放文章的所有配圖，並且存放的時候就直接將圖片命名，然後將自己的所有文章全部上傳到 iCloud，以便多終端拜訪、修改。

隨手將圖片命名的好處在於，在插入圖片到文章中後，將來渲染樣式時給圖片起標題就會非常方便。

所以我摒棄了剪貼板黏貼的方法，每次配圖都先保存到 ./Img 文件夾，再拖入 Typora 中。另外，我在 Typora 中修改了插入圖片的默認 M↓ 語法，以相對路徑顯示圖片位置，而且我上傳 iCloud 的也是整個目錄，所以不會擔心跨平臺的問題。

在公眾號後臺中上傳圖片，目前我發現了三種方法：

1. 直接在後臺上傳忍受差勁的編輯器和割裂的寫作體驗。
2. 將最終寫完的文章以 HTML 的形式複製到後臺由於是複製整篇文章，所以出現不適配公眾號編輯器的問題時需要再次修改，並且修改起來很困難（見後文詳述）。
3. 使用圖床用圖床鏈接而非本地鏈接來表示圖片，再將純文檔形式的 M↓ 文稿發送至第三方排版平臺，使用樣式表進行排版、優化，並且直接髮布。

顯然，我採用了最後一種做法。 此時，對於在互聯網發布（特別是在公眾號發布），圖床的必要性就顯現出來了。 這就涉及到圖床選擇的問題。

圖床選擇

需要明確的是，公眾號後臺對於文章圖片採取的策略是「一律上傳到微信自己的 CDN」，有一說一，這一點還是很方便的。所以，選擇圖床的時候，我就記住一點： 圖床不重要，能讓微信拉取到圖片才重要。 換句話說，只要微信從公眾號編輯器拉取到圖片，接下來的事情就不用我操心了，哪怕某一天圖床跑路了，文章配圖依然在，它甚至連水印都會幫我打好。

由於本文的環境是 Windows 平臺，我自然而然地想到了 Windows 下著名的上傳與分享工具：ShareX。但是就實際使用的體驗來看，並不是很好。原因如下：

• 在 ShareX 中內置支持的圖床，有很多是優秀的國外服務，公眾號後臺統統無法拉取。
• 即便是自定義圖床配置，ShareX 也需要面對一個同樣的問題，那就是寫作體驗的割裂。我必須先在 Typora 中寫文章，然後將圖片通過 ShareX 自定義的快捷鍵上傳到自定義的圖床，再把自動返回的圖床鏈接黏貼到 Typora 中去，最終形成純文檔 M↓ 文稿。

所以，如果 Typora 能夠整合一個圖床上傳服務的話，一切就會好很多。

巧得很，Typora 中確實整合了一個名為 PicGo 的圖床聚合應用，那我就沒有理由不選擇它了。

同樣，我將主流的幾家圖床服務都嘗試了一下：

• imgur全球公認最優秀的圖床服務，但是由於特殊原因，公眾號後臺無法拉取。
• GitHub雖然人稱 GitHub 什麼都能做，但是如果做圖床，公眾號依然無法拉取。
• SM.MS一名活躍於 V2EX 的開發者開發的圖床服務，同樣也是國內目前數一數二的圖床服務，同樣也是公眾號無法拉取。
• 七牛、騰訊等國內雲存儲註冊需要身份證實名認證，對於發布公眾號而言有些大材小用了。

所以，看似選擇很多，有這麼多非臨時的圖床服務，但是仔細一考量，其實路全都被堵死了。我在這一步一籌莫展了很久，後來才想通。還是那句話： 圖床不重要，能讓微信拉取到圖片才重要。 所以，我只需要提供臨時鏈接的圖床就可以了。於是我想到了 Markdown Nice 排版工具（以下簡稱 mdnice） 【後文詳述 2】 的開發者 @Phoebe 先前自建的臨時圖床： mdnice 圖床 。

但是，既然是臨時圖床，就會面臨一個新的問題：在 Typora 中將圖片上傳之後，本地圖片的鏈接就會直接被替換成圖床的鏈接。這對於臨時圖床來說是致命的，因為有可能以後再打開這篇文稿，所鏈接的圖片就被全部清空了。於是我採取了這樣一種方法：在我的寫作流程裡， 我會保留一份「用本地鏈接格式配圖的 M↓ 文稿」（以下簡稱「原文稿」），然後將其復制一份，單獨用於上傳臨時圖床，得到一份「以圖床外鏈格式配圖的 M↓ 文稿」（以下簡稱「圖床版文稿」 。

其實，當我去查找 mdnice 圖床的時候，發現已經找不到了。不知從何時開始， @Phoebe 轉而採用了開發者 @編程如畫 在2019 年年末寫的一個名為「 圖殼（imgkr） 」的圖床。就目前看來，這個圖床的鏈接是長期保留的，不過我觀念比較傳統，依然是不習慣於以圖床鏈接的形式來長期保存文章的，所以圖殼對我而言依然是一個臨時圖床，我也就僅將其當作公眾號發布的跳板來使用。

@編程如畫在 圖殼的開發日記 裡寫道：

這段時間一直在做一些開源項目和小工具，囿於國內沒有好用的圖床，為了解決圖片存儲問題，與@小匠合作做出了自己的圖床，並開放出去，希望得到大家的支持。

圖床配置

圖床找到了，接下來就是如何配置的問題，這些都不難。

首先需要下載 PicGo 應用，並且在 Typora 的偏好設置中啟用。

然後，在 PicGo 中添加 web-uploader 插件 。

提示：安裝插件需要 npm 支持，可以先在 Windows 上安裝 Node.js 。這是 手動安裝 web-uploader 的地址 ，也可以在 PicGo 中自動安裝。添加完成後，插件面板便會顯示。

參考 這篇文章 在 PicGo 中自定義 Web 圖床。

這一步對於我這樣不懂代碼的「麻瓜」來說，屬實走了不少彎路，不過好在最後還是琢磨出來了。

到目前為止，Typora 添加圖殼作為上傳的圖床，就已經完成了。整個配圖的過程梳理一下：

1. 在 Typora 中寫作
2. 將需要插入的圖片保存至本地，並做好檔案管理、圖片命名
3. 將圖片插入至 Typora
4. 繼續完成整個寫作流程
5. 將最終文稿復制一份
6. 將復制的文稿繼續用 Typora 打開，上傳所有圖片至圖殼
7. 得到一份圖床版文稿

到此為止，寫作的部分就已經結束了。

最後決定樣式

樣式，或者俗稱排版，是一篇文章的點睛之筆，也是文章風格化最直接的體現。對於 M↓ 格式的文章而言，樣式化主要依托於 .css 樣式表。而如果需要在富文檔格式的公眾號編輯器中套用自己常用的樣式表，則需要曲線救國一番，方法包括以下幾種：

• 將 M↓ 格式的文章渲染為 HTML 格式，複製並黏貼在公眾號編輯器
• 直接將 M↓ 純文檔黏貼在公眾號編輯器，然後使用瀏覽器擴展來轉換樣式
• 使用專門針對公眾號排版的網站，在網頁上一鍵轉換樣式

黏貼 HTML

首先來看第一種。Typora 本身即支持導出 HTML，導出後直接黏貼在公眾號編輯器中，所以第一種方法是最方便的。但是這樣子的弊端也很明顯，就是會導致各種各樣的格式問題，包括但不限於：

• 縮進消失
• 二級列表消失
• 代碼塊消失
• 公式不受支持
• 外部鏈接被刪除

以及一些其他問題。如果再去逐項排查修改，不僅查找困難、過程枯燥、步驟繁瑣、毫無意義， 而且也會極大地降低寫作效率，有違流程化寫作「一步到位」的理念。 所以，黏貼 HTML 的方案被我排除。

瀏覽器擴展

很多人都知道，對於 M↓ 純文檔的排版，有一個非常好用的瀏覽器擴展： Markdown Here ，我也經常使用它。Markdown Here 支持自定義樣式表，而且在瀏覽器中任何可以輸入文檔的地方，都可以使用它來一鍵排版。所以，理論上講，Markdown Here 的適用場景非常廣闊。

可惜事實並非如此：

• 對發布公眾號而言，依然會出現上述的幾大格式問題。
• 我也不僅僅是發布公眾號這個單一的平臺。

對於其他平臺， 這種「一鍵排版」的擴展程序並不能夠識別本地圖片鏈接，也無法從本地上傳。 所以圖片必須是圖床鏈接的形式，而且是相對穩定的圖床，如 imgur、SM.MS 等等。而我前文已經提到，我僅僅是把圖殼作為「臨時圖床」來使用的。

圖殼是一款在 2019 年 12 月才誕生的、由個人開發者開發的免費圖床，我對它的歷史、口碑、用戶協議、隱私政策、甚至安全性全都無從知曉。如果此時我只是為了使用瀏覽器擴展來排版，就將相同的內容再上傳一遍到其他圖床，將會非常影響效率。

適配公眾號的排版工具

所以只剩下第三種方案——尋找已經適配了公眾號的第三方排版工具。

目前的公眾號排版工具其實並不少，如我先前接觸的 「可能吧」公眾號一鍵轉換器 、後來了解到的 Wechat Format 排版工具 ，以及最終使用的 mdnice 排版工具 ，和最近剛了解到的 Md2All 排版工具 等等，具體也可以參考 互聯網上的這篇推薦 。其中：

• 「可能吧」排版工具不支持自定義樣式表。
• Md2All 支持自定義樣式表，並且解決了上述一系列格式問題，不過由於剛接觸，也就沒有很深入地去了解。
• Wechat Format 也解決了格式問題，不過網頁版依然不支持自定義樣式表，想修改的話需要下載源碼。 Wechat Format 的作者表示 ：

我已經把 WeChat-Format 的源碼放在 GitHub 上了，想要什麼自己去改吧，Free as in Freedom。

所以，我最終選擇的是 @Phoebe 開發的 mdnice。其實 mdnice 所採用的圖床也正是由 @編程如畫 開發的圖殼，二者背後的故事可以在 @編程如畫 的這篇 《我體驗開源世界的這幾年》 推文中了解到，或者參考 Markdown Nice 文檔 。

印象中，大約半年以前在使用的時候，mdnice 的網頁和現在的並不相同。不知何時，mdnice 將頁面網址更新為 https://mdnice.com/ ，並且推出了相應的瀏覽器擴展程序，可以在公眾號的編輯器頁面上顯示更多元素，也可以直接選擇或自定義 CSS、直接渲染。

美中不足的是，這個擴展程序會導致原本的頁面元素也被樣式表所改變。鑒於擴展程序至今仍在開發中，所以我就暫時先不用了。

直到這一步，我與「流程化發布公眾號」的鬥爭才進入了終局： 採用 mdnice 的網頁來排版，然後直接在公眾號編輯器裡黏貼。 由於是發布個人公眾號，所以可以有充分的空間來自定義自己喜愛的樣式表；另一方面，mdnice 也內置了越來越多的樣式表，可以供一鍵調用。

其實這一步反而沒什麼好說的了，梳理一下：

1. 直接用 Typora 打開圖床版文稿
2. 複製其內容然後黏貼到 mdnice 的網頁
3. 記得在「格式」裡將鏈接轉為腳註
4. 然後點擊右側的「公眾號」圖標，複製到剪貼板
5. 在公眾號編輯器中黏貼
6. 最後加上標題、作者、題圖、簡介，就可以發布了！

其他平臺

之前講過，我不僅發布於微信公眾號這一個單一的平臺，所以我也需要考慮目前這套流程的通用性。好在搞定了公眾號之後，其他的平臺就簡單太多了。由於我已經留存了「原文稿」和「圖床版文稿」兩種格式的文章備份，所以對於支持自動上傳圖片至 CDN 的平臺，我就用圖床版文稿，不支持的平臺我就用原文稿。

最終流程梳理與總結

事實上，在我的理解中，將「寫作」與「發布」完全隔離，正是 讓創作流程化、模塊化 的重中之重，而「讓創作流程化」又是高效寫作的一個重要因素。所以我費勁巴力，為的就是形成一套 「本地創作→雲端備份→公眾號發布」 的流程。在我文章寫完的那一刻，接下來要考慮的就是發布層面的事情，就該脫離文章內容本身了。如果追本溯源的話，M↓ 標記語言誕生的初衷也正出於此。

對於「寫作」和「發布」的隔離，我的做法歸根結底無非就是：

• 以「原文稿」和「圖床版文稿」兩種形式保存文章
• 在流程上將寫文字與配圖綁定、套用樣式與發布綁定
• 恪守「一步到位」的原則
• 在盡可能不改動文章內容的前提下，採用妥協於平臺的發布方法

而要妥協於平臺，則不難看出，整個流程的難點就在於 如何面對公眾號匱乏的圖片功能和羸弱的樣式支持。

那麼就考慮到圖床的問題：用哪個應用來上傳，是採用永久圖床還是臨時圖床。如果用永久圖床，就得尋找靠譜的東家，而且公眾號後臺可以拉取；如果是臨時圖床，那麼就無所謂了。所以對比之下 選擇了 Typora 內建的 PicGo 圖床聚合服務，並且根據 API 自定義添加了圖殼的圖床 。

同時我也引申了一下文章管理的方法，比如在 M↓ 格式中如何引用圖片的位置，以及如安在本地和雲端存放自己的往期文章等等。

最後就到了樣式化的環節，需要綜合考慮公眾號格式的支持、樣式表的自定義、使用起來的便捷程度等諸多因素。在這個環節，我最終 確定了 Markdown Nice 排版工具 。

以上就是我目前的「微信公眾號 Windows 平臺流程化寫作與發布」的整套方案。

在寫這篇文章時， 《Markdown Nice-微信公眾號排版神器》 、 《【兩年的乾貨】新媒體寫作工具指南》 、 《盤點國內免費好用的圖床》 等文章也給了我很大幫助。

這些以 Typora 為基點的一切，對於轉移到 macOS 平臺而言，理論上也是適用的。然而在 macOS 上，有 Ulysses 這樣優秀的行業級寫作和文章管理應用，不用實在可惜。所以，我還打算整理一套基於 Ulysses 的 「macOS 流程化寫作與發布方案」。

今天也沒什麼幹勁，這件事情就等到以後再去做吧！

> 下載少數派客戶端、關註少數派公眾號，了解更精彩的數字生活 :leaves:

>在 Windows 平台上進行流程化公眾號寫作