Matrix 精选
Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。
文章代表作者个人观点，少数派仅对标题和排版略作修改。
对于「个人微信公众号（以下简称公众号）的流程化发布」这个话题，其实在互联网上被很多人讨论过。说实话我自己也钻研了很长时间，至今仍不敢和人妄下定论「我已经不用担心公众号发布的事情」，但是目前的方案和以前相比，确实有了很大提升。话不多说，整理成一篇 Windows 下的公众号流程化写作与发布方案，以供后来参考。
此外，我还是保持以往写作的叙事风格，力求把事情说清道明。此外，加粗的部分也为「太长不看」而准备。
说在前面
广义上看，对于「码字→配图→成文→样式化→发布」这样一个写作过程，一千名作者眼中有一千种方法。但对于拥有公众号的作者来说，各种不同的方案所要解决的问题都直指一个共同的核心——公众号该如何流程化发布。
公众号的特殊性，导致它的发布条件众所周知地苛刻：
- 在 Markdown （以下简称 M↓）写作已经很常见的今天，公众号后台编辑器仍然是富文本编辑器
- 并且是巨难用的富文本编辑器
- 当下流行的第三方编辑平台同样既难看又难用，复制到公众号的格式还嵌套了各种各样的冗余样式
如此种种，不再详述。
而需要解决好这个问题，重点就应该放在「流程化」上。简言之，就是形成一套不囿于文章中具体的段落句读的、整体而宏观的、一步到位的公众号发布流程，最好同时也能让公众号以外平台的发布得到兼顾。
所以，本文就讨论一下，如何在 Windows 上一次性完成主要写作过程，并流程化发布于公众号。
先决定写作应用
对于 Windows 平台，我非常喜欢 Typora 这款应用。在刚接触 M↓ 写作的时候，我就一口气下载了很多个本地编辑器，最终敲定了 Typora。先简单说决定性因素：
- 界面简洁美观一款养眼的本地编辑器，对创作有极大的促进作用。
- 所见即所得很多 M↓ 编辑器存在的问题就是「写」和「看」很割裂，要么将渲染前后的样子以左右两栏的形式隔开，要么无法实时渲染、只对 M↓ 文本进行简单的颜色标记。而 Typora 默认在输入 M↓ 标记后就直接渲染成主题的样式，这样也保证了写作思路的清晰。
- 自动保存可以手动设置，无需按保存键就可以自动保存，这是沉浸式创作中很重要的一点。
Typora 对我来说如此趁手，以至于如果哪天公众号的条件苛刻到我必须放弃用 Typora 进行本地创作的话，我宁可放弃公众号。
然后决定图片
公众号编辑器难用，图片问题是大头。在自己的上一篇文章中，甚至用到了多达 21 张静态图片加上 5 张动图。如果图片问题无法解决，我便对发布公众号提不起一丝一毫的欲望。
本地图片
在使用本地编辑器进行写作的过程中，配图往往有以下几种方法：
- 照片型
- 从互联网上下载至本地，再导入编辑器
- 直接将互联网上的照片拷贝至剪贴板，再粘贴到编辑器
- 截图型
- 将截图拷贝至剪贴板，再粘贴到编辑器
- 将截图保存在本地，再导入编辑器
- 动图型
- 将录制完成的动图保存在本地，再导入编辑器
- 灵魂画师、设计师自己制作配图型
- 将图片导出到本地，再导入编辑器
其实一眼就可以看出，各种类型万变不离其宗：要么从本地导入，要么从剪贴板粘贴。从剪贴板粘贴的好处是方便，能省一步是一步，但是对于素材管理却是噩梦；从本地导入则更有条理，不过稍稍麻烦一些。
对于长期写作而言，良好的写作习惯非常重要。我在生活中是一个很注重条理性的人，这一点性格也被我带到了数字世界的文件管理上。我会将每篇文章的 M↓ 文稿都存放于以写作时间命名的目录下，并在此目录下建立一个 ./Img 文件夹，存放文章的所有配图，并且存放的时候就直接将图片命名，然后将自己的所有文章全部上传到 iCloud，以便多终端访问、修改。
随手将图片命名的好处在于，在插入图片到文章中后，将来渲染样式时给图片起标题就会非常方便。
所以我摒弃了剪贴板粘贴的方法，每次配图都先保存到 ./Img 文件夹，再拖入 Typora 中。另外，我在 Typora 中修改了插入图片的默认 M↓ 语法，以相对路径显示图片位置，而且我上传 iCloud 的也是整个目录，所以不会担心跨平台的问题。
在公众号后台中上传图片，目前我发现了三种方法：
- 直接在后台上传忍受差劲的编辑器和割裂的写作体验。
- 将最终写完的文章以 HTML 的形式拷贝到后台由于是拷贝整篇文章，所以出现不适配公众号编辑器的问题时需要再次修改，并且修改起来很困难（见后文详述）。
- 使用图床用图床链接而非本地链接来表示图片，再将纯文本形式的 M↓ 文稿发送至第三方排版平台，使用样式表进行排版、优化，并且直接发布。
显然，我采用了最后一种做法。此时，对于在互联网发布（特别是在公众号发布），图床的必要性就显现出来了。这就涉及到图床选择的问题。
图床选择
需要明确的是，公众号后台对于文章图片采取的策略是「一律上传到微信自己的 CDN」，有一说一，这一点还是很方便的。所以，选择图床的时候，我就记住一点：图床不重要，能让微信拉取到图片才重要。换句话说，只要微信从公众号编辑器拉取到图片，接下来的事情就不用我操心了，哪怕某一天图床跑路了，文章配图依然在，它甚至连水印都会帮我打好。
ShareX
由于本文的环境是 Windows 平台，我自然而然地想到了 Windows 下著名的上传与分享工具：ShareX。但是就实际使用的体验来看，并不是很好。原因如下：
- 在 ShareX 中内置支持的图床，有很多是优秀的国外服务，公众号后台统统无法拉取。
- 即便是自定义图床配置，ShareX 也需要面对一个同样的问题，那就是写作体验的割裂。我必须先在 Typora 中写文章，然后将图片通过 ShareX 自定义的快捷键上传到自定义的图床，再把自动返回的图床链接粘贴到 Typora 中去，最终形成纯文本 M↓ 文稿。
所以，如果 Typora 能够整合一个图床上传服务的话，一切就会好很多。
PicGo
巧得很，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 添加图壳作为上传的图床，就已经完成了。整个配图的过程梳理一下：
- 在 Typora 中写作
- 将需要插入的图片保存至本地，并做好文件管理、图片命名
- 将图片插入至 Typora
- 继续完成整个写作流程
- 将最终文稿复制一份
- 将复制的文稿继续用 Typora 打开，上传所有图片至图壳
- 得到一份图床版文稿
到此为止，写作的部分就已经结束了。
最后决定样式
样式，或者俗称排版，是一篇文章的点睛之笔，也是文章风格化最直接的体现。对于 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 也内置了越来越多的样式表，可以供一键调用。
其实这一步反而没什么好说的了，梳理一下：
- 直接用 Typora 打开图床版文稿
- 拷贝其内容然后粘贴到 mdnice 的网页
- 记得在「格式」里将链接转为脚注
- 然后点击右侧的「公众号」图标，拷贝到剪贴板
- 在公众号编辑器中粘贴
- 最后加上标题、作者、题图、简介，就可以发布了！
其他平台
之前讲过，我不仅发布于微信公众号这一个单一的平台，所以我也需要考虑目前这套流程的通用性。好在搞定了公众号之后，其他的平台就简单太多了。由于我已经留存了「原文稿」和「图床版文稿」两种格式的文章备份，所以对于支持自动上传图片至 CDN 的平台，我就用图床版文稿，不支持的平台我就用原文稿。
最终流程梳理与总结
事实上，在我的理解中，将「写作」与「发布」完全隔离，正是让创作流程化、模块化的重中之重，而「让创作流程化」又是高效写作的一个重要因素。所以我费劲巴力，为的就是形成一套「本地创作→云端备份→公众号发布」的流程。在我文章写完的那一刻，接下来要考虑的就是发布层面的事情，就该脱离文章内容本身了。如果追本溯源的话，M↓ 标记语言诞生的初衷也正出于此。
对于「写作」和「发布」的隔离，我的做法归根结底无非就是：
- 以「原文稿」和「图床版文稿」两种形式保存文章
- 在流程上将写文字与配图绑定、套用样式与发布绑定
- 恪守「一步到位」的原则
- 在尽可能不改动文章内容的前提下，采用妥协于平台的发布方法
而要妥协于平台，则不难看出，整个流程的难点就在于如何面对公众号匮乏的图片功能和羸弱的样式支持。
那么就考虑到图床的问题：用哪个应用来上传，是采用永久图床还是临时图床。如果用永久图床，就得寻找靠谱的东家，而且公众号后台可以拉取；如果是临时图床，那么就无所谓了。所以对比之下选择了 Typora 内建的 PicGo 图床聚合服务，并且根据 API 自定义添加了图壳的图床。
同时我也引申了一下文章管理的方法，比如在 M↓ 格式中如何引用图片的位置，以及如何在本地和云端存放自己的往期文章等等。
最后就到了样式化的环节，需要综合考虑公众号格式的支持、样式表的自定义、使用起来的便捷程度等诸多因素。在这个环节，我最终确定了 Markdown Nice 排版工具。
以上就是我目前的「微信公众号 Windows 平台流程化写作与发布」的整套方案。
后记
在写这篇文章时，《Markdown Nice-微信公众号排版神器》、《【两年的干货】新媒体写作工具指南》、《盘点国内免费好用的图床》等文章也给了我很大帮助。
这些以 Typora 为基点的一切，对于转移到 macOS 平台而言，理论上也是适用的。然而在 macOS 上，有 Ulysses 这样优秀的行业级写作和文章管理应用，不用实在可惜。所以，我还打算整理一套基于 Ulysses 的 「macOS 流程化写作与发布方案」。
今天也没什么干劲，这件事情就等到以后再去做吧！
