四账号矩阵自动化：先别急写发布脚本

起因：我要把四个号跑起来

手上两个微信公众号、两个小红书，想做成矩阵。第一反应很自然：写个自动发布工具，一键四投。

动手前我先去查了两个平台的开放能力，结果把方案整个推翻了。

（上一篇 牙科公众号内容流水线 里查过公众号，这次补上小红书，两个平台凑齐了。）

两条政策事实

小红书：官方开放平台 open.xiaohongshu.com 确实存在，OAuth2.0 也正规，但它面向商家和服务商——要先过资质审核（第三方开发者，或商家自研绑定店铺）。文档里能看到的接口是笔记详情、评论列表、订单商品这类读取接口，没有对外的「发布笔记」接口。

有篇开发者文章写得很直白：「对普通个人而言，开放平台更多是商家自研或服务商做集成用，个人账号直接调用的场景有限。」

微信公众号：官方文档「发布能力」页原文——

注：2025 年 7 月起，个人主体账号、企业主体未认证账号及不支持认证的账号将被回收以上接口的调用权限。

也就是说个人主体连花钱认证都拿不回 freepublish。

结论：两个平台都不给个人开发布接口。 想自动发，只剩浏览器自动化一条路。

但两个平台都有原生定时

这才是关键——

「到点自动发出去」这件事，平台早就解决了。 我要做的只是提前把草稿传上去、点一下定时。

为省这 5 分钟去写浏览器自动化脚本，要长期背三样东西：登录态过期、验证码拦截、平台一改版脚本就废。这笔账不划算。

所以我把「一键四投」的方案删了。

那瓶颈在哪

既然发布不是瓶颈，四个号的真正问题就浮出来了：内容量。

• 四个号各自原创 → 内容需求翻四倍。我现在公众号 1.2 篇/周，摊到四个号就是每个号 0.3 篇/周，全部饿死
• 一条母稿 → 改写成多个平台版本 → 内容成本不变，覆盖面成倍增加

所以矩阵的经济性来源不是「发布自动化」，是**「一次生产、多平台改写」**。

确认下来的结构也帮了忙：四个号不是一源四发，是两套内容线，每套一个公众号加一个小红书。这个结构比同平台多号安全得多——平台之间不查重，而小红书明确打击同平台多号发相似内容。

自动化该建的六层

选题        AI 每周出 6-8 条候选
  ↓
母稿        只写事实与结论，不带平台腔
  ↓
改写        一条母稿 → 公众号版 + 小红书版
  ↓
素材包      每平台独立目录 + 发布前校验
  ↓
投递        上传草稿 + 平台原生定时（唯一要动手的一层）
  ↓
数据回填    公众号看分享率，小红书看收藏率与互动率

六层里五层 AI 能接管，只有「投递」要人点几下。AI 价值最大的是第三层改写。

小红书这层跟公众号差得远

规格不搞清楚，做出来也是废稿：

小红书是双列信息流，用户先看封面再看标题。封面做成横版会被裁掉，点击率直接砍半，而且发出去改不了封面。

素材契约：把规格变成能跑的检查

跟公众号那套一样，每篇一个目录，发之前跑校验脚本。

我拿公众号那张封面故意测了一下：

[封面] cover.png 1536×1024，比例 1.50
[错误] 封面是横版或正方形，小红书信息流要求竖版 3:4

精准拦下。 这正是「公众号封面直接搬去小红书」最容易犯的错。

脚本零第三方依赖——自己解析 PNG/JPEG 文件头取尺寸，不用装 Pillow。除了封面比例，还查标题字数、正文字数、标签数量、配图编号连续性，外加一串高风险词告警（最好 / 第一 / 根治 / 百分百 / 治愈……）。

实测时报了个「第一」，查下来是「第一次用牙龈可能出血」——误报。但这个方向我认：医疗健康内容的极限词是硬红线，误报花 3 秒确认，漏报可能直接限流。

跨平台改写实测

拿已经终审通过的一篇公众号稿改成了小红书版，534 字：

• 开头从「第一句给结论」改成「先说痛点」（「用了半年牙线觉得没用？」）
• 正文拆成 6 段，加 emoji 和序号
• 结尾从「转给家里那个总说牙线没用的人」改成「先收藏，下次买的时候对照着挑」+ 评论区提问

同一份事实和结论，换一套表达方式，就是另一篇内容。这比新写一篇快得多，而且不是洗稿。

这次决定不做的事

• 不做一键四投的浏览器脚本。 定时已被平台解决，脚本省的那点时间抵不过维护成本
• 不用设备指纹 / 分布式 IP 那套「矩阵系统」。 市面上卖这个的，本质是帮你对抗平台风控。那是灰产，而且一旦被判定营销号，四个号一起废
• 不在同平台多号之间搬内容。 两个小红书号必须定位真的不同

下一步

先把第一套（牙科）的小红书跑满 10 篇，看收藏率和互动率，再决定要不要给第二套复制同一套流水线。

另外有个细节值得记：小红书看的不是阅读量，是收藏率和互动率。这两项才有长尾价值——一篇攻略被收藏，半年后还有人翻出来看。