我是如何用一套 Python 脚本，把技术文章「稳定」分发到知识星球 + 公众号的

如果你也在同时运营 知识星球 / 公众号 / 技术博客，
那你大概率踩过这些坑。

目录（TOC）

• • 真实问题：不是不会写，而是发到崩溃
• • 为什么我没有用现成平台，而是自己写脚本
• • 这套多平台发布脚本，解决了哪些「工程级问题」
• • 核心设计思路拆解
• • 1. 内容不是一次性提交，而是可控拆分
• • 2. 每个平台都有「发布节流器」
• • 3. 微信 45004，是被「字符数」坑死的
• • 4. 失败≠报错，而是可恢复状态
• • 一个人维护多内容渠道，真正可行的方式
• • 我在知识星球里，会把哪些东西继续写完
• • 适合谁加入，不适合谁
• • 面试题：你真的理解「内容发布系统」了吗？

真实问题：不是不会写，而是发到崩溃

很多人以为「内容创作」的瓶颈在写作能力。

但当你真正开始同时运营多个平台，你会发现真正消耗人的，是这些事情：

• • Markdown 在公众号里 格式全乱
• • 超长技术文，一发就 45004
• • 知识星球 API 偶发失败，不知道该不该重试
• • 今天已经发过了？我记不住
• • 明明是同一篇内容，却要 手动改三份

写文章是脑力活，
发文章，是体力 + 工程活。

为什么我没有用现成平台，而是自己写脚本

我一开始也试过：

• • 各种「多平台分发工具」
• • 公众号编辑器 + 复制粘贴
• • Notion → 微信插件

最后全部放弃，原因很简单：

它们都不是为「技术长文 + 稳定输出」设计的。

而我需要的是：

• • Markdown 是唯一源
• • 可控的 HTML 转换
• • 明确知道：哪里会超限，怎么兜底
• • 失败后可以安全重跑

于是我干了一件很工程师的事：

把“内容发布”当成一个系统来写。

这套多平台发布脚本，解决了哪些「工程级问题」

这不是一个「调接口」的脚本，而是一个发布系统的最小实现。

它解决的是这些非常现实的问题：

• • ✅ 同一篇 Markdown
  → 知识星球文章 + 动态绑定
  → 公众号草稿箱
• • ✅ 每日发布上限控制（防封、防手滑）
• • ✅ 定时发布
• • ✅ 超长内容 自动拆分，而且：
• • 不拆代码块
• • 不拆 Markdown 结构
• • ✅ 微信 45004 的根因级规避
• • ✅ 封面素材 永久缓存
• • ✅ 所有失败都有 重试 + 降级路径

核心设计思路拆解

下面说的不是「怎么写代码」，而是为什么要这么设计。

1. 内容不是一次性提交，而是可控拆分

公众号的限制不是「字数」，而是：

HTML 字符数 < 20000

这是一个非常坑的点。

所以我做了三层设计：

1. 1. 先渲染 minimal HTML
2. 2. 按 HTML 字符数评估
3. 3. 优先在 Markdown 结构边界拆分
• • 段落
• • 标题
• • fenced code block

拆分不是字符串切割，而是结构保护。

这是绝大多数工具做不到的。

2. 每个平台都有「发布节流器」

我不相信「我今天记得我发了几篇」。

所以脚本里有一个独立的：

• • DailyStatsManager
• • 按 平台 + 日期
• • 自动在指定时间（比如 09:00）重置

这本质上是一个 轻量级发布配额系统。

3. 微信 45004，是被「字符数」坑死的

很多人以为是内容太长，其实是：

• • JSON 默认 ensure_ascii=True
• • 中文被转成 \uXXXX
• • 字符数直接爆炸

所以我在所有微信请求里：

json.dumps(payload, ensure_ascii=False).encode("utf-8")

这是实战踩坑换来的经验。

4. 失败≠报错，而是可恢复状态

一个工程化脚本，最怕的是：

跑到一半失败，不知道现在算「发没发成功」。

所以我做了：

• • 发布日志
• • 已发布记录
• • 幂等式判断
• • 可安全重跑

这是“脚本”和“系统”的分水岭。

一个人维护多内容渠道，真正可行的方式

我现在的工作流是：

写 Markdown
   ↓
跑脚本
   ↓
知识星球（文章 + 动态）
   ↓
公众号（草稿箱）

我不再关心：

• • 哪个平台限制多少
• • 哪一步会失败
• • 是否会重复发布

我只关心内容本身。

我在知识星球里，会把哪些东西继续写完

这篇文章，只是一个「入口」。

在知识星球里，我会系统性拆解：

• • 这套脚本的 完整工程结构
• • 如何扩展到：
• • 掘金 / CSDN
• • 企业微信
• • 内部知识库
• • 内容系统的：
• • 发布流水线
• • 失败补偿
• • 可观测性设计
• • 一个人，如何把技术内容变成长期资产

不是碎教程，而是完整系统思路。

适合谁加入，不适合谁

适合：

• • 已经在写技术文章
• • 不想再手动发平台
• • 对工程设计有追求
• • 想把内容当「产品」做的人
• • 想学习Python的人

不适合：

• • 想要 3 天速成
• • 只关心流量套路
• • 不想看代码、不想理解设计

如果你也在做 技术内容长期输出，
并且已经意识到：

写作不是最大成本，
混乱和重复劳动才是。

那这个知识星球，大概率适合你。