微信公众号自动化流水线（脱敏版）：每日自动写稿与发表的设计取舍

每天一篇公众号文章，靠的不是意志力，而是一条跑得动的流水线。本文记录一条“每日自动写稿 + 发表”的公众号流水线设计与取舍，内容已脱敏，只讲公开通用的做法，不涉及任何具体服务器、账号与密钥信息。

先说结论：流水线只做三件事

一条能长期跑的公众号流水线，职责要收敛：

1. 定时触发：每天固定时间启动一次，失败可重试，但不追补过期任务。
2. 生成草稿：按固定选题库与模板产出初稿，写进草稿箱，不直接发表。
3. 人工确认后发表：人看一眼再点发表，发表动作永远不交给无人值守的定时器。

把“生成”和“发表”拆开，是整条流水线最重要的取舍：生成可以自动化，发表必须留一个人工关口。

流水线的四个环节

1. 选题：先有库，再谈自动化

没有选题库的自动化，产出的第一天就开始重复。我的做法是维护一个选题清单，每条选题只记三样东西：主题、面向的读者、这篇文章要讲清的一个取舍。每天从清单里按顺序取一条，取过的标记为已用，避免同一主题短期内重复出现。

选题的来源是日常工作中真实遇到的问题，例如一次排障、一次配置踩坑、一次方案选型。只记录问题本身，不记录任何环境细节。

2. 写稿：模板先行，模型只负责初稿

写稿环节用固定模板约束结构，例如：问题背景、做了什么取舍、为什么这样选、如果重来会怎么改。模板的好处是文章结构稳定，坏处是容易写得像填空题，需要在人工复核时把模板味改掉。

生成初稿的工具可以是任何合规的大模型服务，关键点不在工具，而在输入：给模型的是脱敏后的问题描述和结构要求，而不是任何真实配置、日志原文或账号信息。模型产出的是初稿，不是终稿。

3. 脱敏与复核：流水线里最花时间的一步

发表前的复核清单是固定的，逐项过：

• 有没有出现服务器地址、端口、内网地址、账号名、密码或密钥；
• 有没有出现本机路径、部署脚本原文、未公开的域名；
• 有没有编造的数字，例如阅读量、用户量、性能对比数据，凡是没有来源的数字一律删掉；
• 正文里的网址是否都写成了代码格式的纯文本，而不是可点击的超链接。

这一步不能省，也不能交给模型自己检查自己。脱敏的标准是：文章发出去之后，读者只能学到做法，拿不到任何可以用来定位我方环境的信息。

4. 发表：人工点一下，但流程要顺

公众号的发表入口在公众平台的草稿箱与发表管理页。我的流程是：草稿在流水线里生成后，先同步到公众平台的草稿箱；每天固定时间人工打开草稿箱，通读一遍，改掉别扭的句子，确认无误再点发表。

这样做发表时间可能不完全固定，但换来的是可控：任何一篇有问题的文章，都可以在发表前被拦下来。

几个具体的取舍

取舍一：定时触发，还是手动触发

定时触发省心，但节假日、选题断档时也会照常跑，产出低质量文章。我的取舍是定时触发加人工确认：定时器只负责“提醒我今天该写了”，不负责“今天必须发一篇”。选题库空了，宁可停更一天，也不用凑字数顶上。

取舍二：全自动发表，还是半自动

全自动发表看起来最省事，但一旦上游出问题，错文章会在无人注意时发出去。半自动多花几分钟，却把风险关在发表之前。对个人公众号来说，这几分钟是最值得花的成本。

取舍三：内容存在哪里

草稿、选题库、复核清单都用纯文本文件保存，放在版本控制里。好处是改动有记录、可以回滚；坏处是多人协作时需要约定格式。对只有一两个维护者的流水线来说，纯文本够用了，不必为此引入数据库。

失败时怎么办

流水线一定会失败，设计时就要把失败当成常态：

• 生成失败：不重试写稿，直接记一条失败日志，第二天人工补写。
• 同步草稿失败：本地草稿还在，人工复制过去发表，不阻塞当天的发表。
• 发表后发现错误：第一时间在公众号后台修改或删除，并在下一篇文章里说明更正，不悄悄改掉当作没发生。

每种失败都对应一个人工兜底动作，而不是让流水线自己想办法“聪明”地恢复。

一个最小可用的版本

如果从零开始，我会先搭最小版本，再慢慢加东西：

1. 一个选题清单文件，按顺序取题。
2. 一个写稿模板，固定文章结构。
3. 一个复核清单，发表前逐项打勾。
4. 一个每天固定时间的提醒，提醒我去复核和发表。

跑顺一个月之后，再考虑要不要加自动生成、自动同步这些环节。顺序反了，流水线越搭越重，最后没人愿意维护。

写在最后

公众号自动化的目标不是“每天自动发一篇”，而是“每天都能稳定地产出一篇可以发的东西”。把生成和发表拆开、把脱敏和复核放进流程、接受停更比凑数好，这三条做到了，流水线就能长期跑下去。