一、先把边界划清：机器干三段，人干一段
「AI 文案自动发布」这句话里被省略的从来不是技术细节，而是责任划分。真实情况是一条四段链路：前三段可以完全交给机器，最后一段里有一件事只能由人做。
- 生成：把选题变成一篇结构化的内容——标题、关键词、正文、分类。可自动。
- 提交：把这篇内容交给分发服务，并明确指定「发到哪些账号」。可自动。
- 执行与重试：按账号池逐个走各平台自己的发布流程，失败按状态机退避重试。可自动。
- 账号侧处理：登录态失效、平台要求人工确认，只能人去平台后台点。这一段没有任何工具能替你完成。
云梭发布做的事，是把前三段接成一条队列，并在第四段第一时间把各平台的原话结果交回给你。本文只讲能查到的部分：字段名、参数、状态码、积分数字都来自官方接口与计费配置；各平台自家规则的地方一律标注「需补充实测数据」。
二、四段链路各自的输入、输出与依据
| 环节 | 输入 | 输出 | 可核实的口径 |
|---|---|---|---|
| AI 生成 | 选题方向、关键词 | 一条图文内容（类型 0 文章） | 生成扣费 round(tokens/1000×100) 积分 |
| 提交 | 内容 + account_ids | 服务端返回 content_pk | 逐账号池校验归属，非本人返回「账号pk有误」 |
| 执行 | 队列里 status=0 的行 | 每个「内容 × 账号池」一条结果 | 每 3 秒轮询；按 pool_id 分组，一轮一条 |
| 回查 | content_pk | 逐账号状态 + 平台原话 | status / remark / next_retry_time / failed_count |
三、第 0 步：账号从哪来，这是真实门槛
自动化之前得先有可用的登录态。云梭发布的做法是 Windows 电脑装 Chrome + 本地插件，由插件抓取各平台的登录态。这是真实门槛不是装饰：没有抓到的登录态，队列里的任务没有投递目标；把它藏起来，注册会在第一步流失，还产生客服成本。
- 可提交的范围：14 个已接入平台 + 自定义站点通道。平台侧包括抖音、快手、小红书、视频号、微信公众号、微博、知乎、头条号、百家号、企鹅号、网易号、搜狐号、一点资讯、大鱼号。
- 自定义站点通道不要拿来发推广内容：那是给客户自己站点用的。同一篇已经进过官网资讯，再从这条通道推一遍，等于自家站点收了两遍同一篇。
- 先抄一份账号台账：
/v1/pools/index返回pk / name / platform_name / login_status / publish_status / is_nurturing / last_used_time。提交要用的account_ids就是这里的一串 36 字符pk。
一个常见误解要点破：账号池列表显示登录态异常，不代表这篇发不出去；列表显示正常，也不保证这一轮一定成功。事实来源是提交之后按 content_pk 查到的逐账号状态，不是页面上那个标签。
四、第 1 段：AI 出来的不是一段文字，是字段齐全的对象
分发链路接收的不是纯文本，而是一个结构体。少任何一个必填字段，接口会直接拒收，而不是「先发出去再说」。
| 字段 | 口径 | 踩坑点 |
|---|---|---|
| title | 15～40 字符 | 写太短在开放接口侧会被拒 |
| short_title | 8～20 字符 | 缺这一项接口直接拒收 |
| long_title | 20～60 字符 | 照抄网上示例最容易漏 |
| keywords | 逗号分隔，总长 ≤255 | 会被拆成标签，堆词没有意义 |
| description | 摘要 | 列表页与站内搜索都读它 |
| categories | 至少 5 项一级分类 | 取值必须命中官方分类表（97 个），自己编会被拒 |
| html | 正文，剥离标签后非空 | 图片必须是公网可下载的 URL |
| cover | 封面，可省略 | 建议带上，多数平台列表页要图 |
三个标题不是形式：不同平台取的字段不一样，只写一个标题等于在站外渠道放弃展示位。
五、第 2 段：提交有两种入口
5.1 站内任务：按方向批量出稿
站内是「任务驱动」：配好方向、频率与绑定的账号池，生成先出词再出文，之后为每个绑定的账号池各建一条待发记录。适合「不想自己写，只定方向」的用法。
5.2 开放接口：对接自己的系统
已经有内容中台或 AI 流程的，走 POST /v1/distribution/push。鉴权三个请求头：nonce（8～32 字符随机串）、user-code（会员码）、signature（把接口密钥、随机串、会员码按官方文档规定的顺序拼起来做 SHA-512，取十六进制结果）——顺序固定、中间不加分隔符，接口只接受 POST。请求体除上表那些字段外，还要 type=0 和 account_ids。
服务端做三件硬校验：逐个检查 pk 的归属，不是本人账号直接报「账号pk有误」；会员余额不大于零时报「余额不足，请充值后重试」；成功返回 data.content_pk，后续所有回查都以它为唯一凭据。换句话说，越界这件事在接口层就被挡住了，不靠自觉。
六、第 3 段：执行是怎么被「取走」的
队列唯一的消费入口是一条每 3 秒执行一次的轮询。它取的是两类记录：一类是刚入队、还没被人碰过的「待发布」；另一类是失败后进入退避、并且已经到重试时间的那些。取的时候按账号池分组、按记录编号倒序、每轮限量。
有三点值得单独强调，因为它们直接决定你怎么排自己的活儿：
- 同一个账号池一轮只取一条：按账号池分组，不会出现同一个号被连续两条挤发。
- 没有排期字段。队列里唯一的时间列
next_retry_time是失败后的重试时刻，不是计划发送时刻。一条记录只要处于「待发布」，最多 3 秒后就被取走。所以「定时发布 / 按计划排期」不是当前能力：想要卡某个时间点发，只能你自己掐点提交，或者把生成时间安排在你需要它出现的那一刻之前。 - 三个前提缺一不可：内容确实存在、账号池存在且未被删除、会员余额大于零。任何一条不满足，任务不会报错给你，而是停在队列里或被判定为数据异常。
七、第 4 段：六种状态，只有三种能交给机器
| status | 含义 | 谁能推进下一步 | 你该做什么 |
|---|---|---|---|
| 0 | 待发布 | 机器 | 等，最多 3 秒后被取走 |
| 1 | 发布成功 | 机器 | 记进台账，按平台结算积分 |
| 2 | 失败可重试（指数退避） | 机器 | 看失败次数与下次重试时间，连续多次不动才人工介入 |
| 3 | 平台不支持，终结 | 不会自己恢复 | 改内容形态（比如把矢量图换成位图）或换平台 |
| 4 | 需要验证，退避 | 人 | 去平台后台处理，账号进养号态 |
| -1 | 数据异常 | 人 | 补内容或账号引用 |
回查用 POST /v1/distribution/status，请求体只要一个 content_pk，返回的是逐账号记录，附平台原话 remark。这一句必须说透：提交成功不等于发布成功。接口返回 content_pk 只代表进了队列，真正发没发出去要按这份逐账号状态判断。
八、成本账：一篇发满 14 个平台要多少积分
- 发布 850 积分 / 篇 / 平台；微信公众号与自定义站点通道五折，即 425。1 元 = 10000 积分。
- 一篇发满 14 个已接入平台 = 13 × 850 + 425 = 11475 积分 ≈ 1.15 元。同一条内容如果账号池里同一个平台挂了两个号，就要多算一份。
- 注册送的 10000 积分：够在单个平台连发 11 篇，够把整条流程验证一遍；不够一次全平台提交（11475 > 10000）。先用单平台跑通，再决定要不要铺。
- 生成环节按 token 另计：
round(tokens/1000 × 100)积分，与发布扣费是两笔账。
九、可直接抄的落地清单
- 跑一次
/v1/pools/index，把每个账号的pk、平台、登录态抄成一张表，标出本轮哪些参与投放。 - 排除自定义站点通道——同一篇已经进过官网资讯，不要再从这条通道推第二遍。
- 备稿：三标题齐全、
keywords3～6 个真实搜索词、categories至少 5 项且取官方一级分类、正文里的图片全部是公网 URL。 - 先只提交 1 个账号，用
/v1/distribution/status看它落到哪个状态；确认status=1之后再扩量。 - 扩量时把同一篇提交到 3～5 个平台，观察两件事：内容形态被不被接受（对应
status=3）、账号会不会被要求验证（对应status=4）。 - 把
status=2的记录按failed_count排序，连续多次仍不成功的单独拉出来读remark，别让它一直默默退避。 status=4与登录失效的账号单独列成待办——这一档只能人去平台后台处理，处理完才回到队列。- 固定每周一次复盘：各平台成功数、失败原因分布、单篇成本，据此改下周的选题与投放范围。每天的角色只是「值班」，方向是周复盘改的。
各平台每天能接多少条同题材内容，规则在各平台手里，这边没有实测数据，需补充实测数据之后再定「同一账号一天发几篇」。稳妥起点是一天一篇，观察两周状态与平台原话，再放量。
十、这套流程不承诺的三件事
- 不承诺内容一定被平台接受：能不能发、能以什么形态发，判定权在各平台。工具只负责把每个平台的原话交回来，让你自己看见。
- 不承诺流量结果：分发解决的是「发没发出去」。互动与转化数据需要实测，本文不编。
- 不替你做账号决策：号要不要停、要不要退某个平台、内容要不要改方向——这些判断只能人做，也正是人在闭环里唯一该占的位置。
十一、闭环是这样转起来的
四段链路接完之后，分工很清楚：写稿与配图交给 AI，提交、执行、重试与状态回查交给云梭发布，人只在两个位置出现——周一定方向，以及处理平台侧的登录与验证。节奏于是变成「定方向 → 机器每天出稿并提交 → 每小时回看一次状态 → 周复盘改两条规矩」，从生成到发布、检查、复盘，再回到下周方向。
闭环的价值不是少点几下按钮，而是把耗在重复劳动上的精力省下来，转去做决策、定方向，把生产力提上去。机器负责重复，人负责判断。这，才叫无人化运营。
