在 Windows 平台上进行流程化公众号写作

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

然后，在 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 的网页来排版，然后直接在公众号编辑器里粘贴。 由于是发布个人公众号，所以可以有充分的空间来自定义自己喜爱的样式表；另一方面，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: