Matrix 精選

Matrix 是少數(shù)派的寫作社區(qū)，我們主張分享真實的產(chǎn)品體驗，有實用價值的經(jīng)驗與思考。我們會不定期挑選 Matrix 最優(yōu)質(zhì)的文章，展示來自用戶的最真實的體驗和觀點。

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

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

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

說在前面

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

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

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

如此種種，不再詳述。

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

所以，本文就討論一下，如何在 Windows 上一次性完成主要寫作過程，并流程化發(fā)布于公眾號。

先決定寫作應用

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

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

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

然后決定圖片

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

本地圖片

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

• 照片型
• 從互聯(lián)網(wǎng)上下載至本地，再導入編輯器
• 直接將互聯(lián)網(wǎng)上的照片拷貝至剪貼板，再粘貼到編輯器
• 截圖型
• 將截圖拷貝至剪貼板，再粘貼到編輯器
• 將截圖保存在本地，再導入編輯器
• 動圖型
• 將錄制完成的動圖保存在本地，再導入編輯器
• 靈魂畫師、設計師自己制作配圖型
• 將圖片導出到本地，再導入編輯器

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

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

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

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

在公眾號后臺中上傳圖片，目前我發(fā)現(xiàn)了三種方法：

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

顯然，我采用了最后一種做法。此時，對于在互聯(lián)網(wǎng)發(fā)布（特別是在公眾號發(fā)布），圖床的必要性就顯現(xiàn)出來了。這就涉及到圖床選擇的問題。

圖床選擇

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

ShareX

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

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

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

PicGo

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

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

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

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

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

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

@編程如畫 在 圖殼的開發(fā)日記 里寫道：

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

圖床配置

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

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

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

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

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

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

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

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

到此為止，寫作的部分就已經(jīng)結(jié)束了。

最后決定樣式

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

• 將 M↓ 格式的文章渲染為 HTML 格式，拷貝并粘貼在公眾號編輯器
• 直接將 M↓ 純文本粘貼在公眾號編輯器，然后使用瀏覽器擴展來轉(zhuǎn)換樣式
• 使用專門針對公眾號排版的網(wǎng)站，在網(wǎng)頁上一鍵轉(zhuǎn)換樣式

粘貼 HTML

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

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

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

瀏覽器擴展

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

可惜事實并非如此：

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

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

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

適配公眾號的排版工具

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

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

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

我已經(jīng)把 WeChat-Format 的源碼放在 GitHub 上了，想要什么自己去改吧，F(xiàn)ree as in Freedom。

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

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

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

直到這一步，我與「流程化發(fā)布公眾號」的斗爭才進入了終局：采用 mdnice 的網(wǎng)頁來排版，然后直接在公眾號編輯器里粘貼。由于是發(fā)布個人公眾號，所以可以有充分的空間來自定義自己喜愛的樣式表；另一方面，mdnice 也內(nèi)置了越來越多的樣式表，可以供一鍵調(diào)用。

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

1. 直接用 Typora 打開圖床版文稿
2. 拷貝其內(nèi)容然后粘貼到 mdnice 的網(wǎng)頁
3. 記得在「格式」里將鏈接轉(zhuǎn)為腳注
4. 然后點擊右側(cè)的「公眾號」圖標，拷貝到剪貼板
5. 在公眾號編輯器中粘貼
6. 最后加上標題、作者、題圖、簡介，就可以發(fā)布了！

其他平臺

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

最終流程梳理與總結(jié)

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

對于「寫作」和「發(fā)布」的隔離，我的做法歸根結(jié)底無非就是：

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

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

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

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

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

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

后記

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

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

今天也沒什么干勁，這件事情就等到以后再去做吧！

> 下載少數(shù)派 客戶端 、關(guān)注 少數(shù)派公眾號 ，了解更精彩的數(shù)字生活 ??