把"多平台自动发布"拆成五个可核查的节点——账号查询、素材上传、字段校验、发布预览、正式发布——比找一个"一键发布按钮"更接近真实可用的方案。本文以蚁小二 yxer CLI 为例，说明每个节点要做什么、要确认什么、哪些地方必须回到官方文档核对。

说明：涉及具体子命令、参数名、返回字段、错误码的内容，公开资料尚未完整覆盖。本文中标注为"以当前 CLI 帮助与官方文档为准"的部分，请不要凭经验脑补后直接上生产。

1、先界定任务：什么算"多平台自动发布"

在动手之前先回答三个问题：

多账号：是同一平台下的多个账号，还是跨平台的多个账号？

多平台：目标平台有几个，各自支持哪些内容类型？

多内容类型：视频、图文（笔记）、长文（文章）是三类不同结构的内容，发布字段并不通用。

如果只是偶尔发一条、发一个平台，手动发布完全够用。真正值得 CLI 化的场景是：需要批量或重复发布、需要定时排期、希望由脚本或 AI Agent 调用同一套流程、并且事后需要能追溯每一步做了什么。

yxer 的思路是把多账号、多平台、多内容类型的发布封装成一条可审计的 CLI 流程，让 Claude Code、Codex、Cursor、Trae、WorkBuddy 这类 Agent 可以调用蚁小二已有的账号管理、发布、数据能力，而不需要为每个平台单独写接口对接。

边界要说清楚：官方口径是蚁小二支持近 40 个平台的全栈管理，但"支持近 40 个平台"不等于"每个平台都支持全部内容类型"。具体某个平台是否可发、支持视频还是长文、账号类型是否覆盖，请以官网、客户端内的平台列表和 CLI 当前帮助为准，不要把它理解成"全平台通用"。

把发布拆成五个节点，每个节点都有明确的输入和输出：

账号查询 → 素材上传 → 字段校验 → 发布预览 → 正式发布

任何一步没有拿到可引用的输出，就不应该进入下一步。

2、设置阶段：准备账号、凭证与素材

2.1 账号接入

账号授权在蚁小二客户端或后台完成。客户端本身内置了浏览器环境，账号授权通过内置浏览器执行，不需要把平台账号密码交给第三方系统。单账号、单平台多账号、多平台账号都可以在这里接入。

团队场景下，还可以把不同账号分配给不同成员运维，按角色划分操作范围。这是后续做权限最小化的基础——不要让一个 Agent 或一个 API Key 拥有全部账号的发布权限。

2.2 CLI 环境与凭证

官方给出的安装与初始化命令如下（可直接复制给 Agent 执行）：

npm install -g @yixiaoermail/cli
yxer --version
yxer config init --api-key <你的 API Key>
yxer skill sync
yxer doctor

要点：

安装过程中如果没有 API Key，可以先完成安装，只要 yxer --version 能输出版本号即可。

API Key 的获取路径：登录蚁小二后台 →【主页】→【蚁小二 CLI】，在此创建 API Key。

同页面还会给出一个 clientId（蚁小二客户端 ID）。它的作用是区分发布模式：带上 clientId，Agent 可以调用本机蚁小二客户端实现本地发送；不带则走云发布模式。

yxer doctor 用于自检环境，建议每次换机器或升级后都跑一次。

2.3 素材与目标清单

开始前准备好三样东西：

素材目录：统一命名规则（建议按"平台_内容类型_日期_序号"），避免 Agent 引错文件。

目标平台清单：明确每个平台要发什么类型的内容。

字段清单：标题、正文、话题、封面、位置、可见范围等，哪些是必填、哪些平台特有。

素材的格式、大小、时长、数量限制由各平台规则决定。CLI 的校验会以当前规则为准，但不要把某一次成功的参数当成永久有效的参数——平台规则会变。

3、节点一：账号查询——先确认"发给谁"

这一步解决的是最常见也最贵的错误：发错账号。

一次合格的账号查询结果，应当至少包含：

实践建议：

先按平台或分组筛选，再取账号 ID，不要一次性列出全部账号后靠人眼挑。

把查询结果落盘保存（比如 accounts.json），后续步骤从文件读取账号 ID，而不是每次重新查询——这样出问题时能回放。

官方资料中提到的典型用法包括"批量检测所有账号状态，筛选出已完成发布、登录失效的账号"，这一步应当作为发布前的固定前置动作。

硬性条件：授权过期、账号被限制或状态异常时，不要继续发布。哪怕后面的命令能跑通，结果也是失败或被平台拦截。

具体的账号查询子命令与输出结构，请以 yxer --help 和官方文档为准。

4、节点二：素材上传——把文件变成可引用素材

本地文件不能直接出现在发布命令里。需要先上传，拿到一个稳定的引用标识（素材 ID 或 URL），后续字段里引用的是这个标识。

yxer CLI 对外提供的发布路径之一就是"素材到平台素材库"——素材先进入平台的素材库，再被内容引用。这样做的好处是：素材上传失败可以在正式发布前就被发现，而不是等到发布时报错。

这个节点要确认四件事：

格式/大小/尺寸校验：不通过就不进入下一步。

返回的引用标识：素材 ID 或 URL，记录到本地。

存储时效：素材在平台素材库中保留多久，是否会被清理。

平台侧限制：同一素材在不同平台的可用性不同（尺寸比例、时长上限）。

失败重试要有上限和间隔。同一个文件连续失败三次，基本可以判断是格式或权限问题，继续重试没有意义，应该转人工检查。

上传成功与失败的返回结构示意（字段名以实际返回为准）：

// 成功（结构示意）
{ "material_id": "...", "url": "...", "status": "ok" }

// 失败（结构示意）
{ "status": "failed", "reason": "format_not_supported", "file": "a.mp4" }

5、节点三：字段校验——在发布前拦住错误

这是整套流程里价值最高的一步。AI 会写内容，但真正容易出错的是字段：话题漏写、标题超长、封面缺失、定时时间格式不对、可见范围选错。

yxer CLI 在正式发布前增加了校验机制：Agent 执行任务时，会自动检查平台字段和素材结构，把问题发现在发布前而不是发布后。官方提到的三条路径中，第二条就是"文章发布前平台填写结构校验"。

校验要区分两类字段：

通用字段（大多数平台都有）：标题、正文、素材引用、账号、定时时间。

平台特有字段（因平台而异，需要单独处理）：话题/标签、地理位置、@ 提及、商品挂载、可见范围、封面、合集/专栏等。

原则是：通用字段用一套模板管理，平台特有字段单独建映射表，不要混在一起。

校验通过才进入预览。校验失败应当返回可定位到具体字段的错误信息，例如：

// 错误结构示意，字段名以实际返回为准
{ "field": "title", "code": "max_length_exceeded", "message": "标题超出平台限制" }

重要条件：平台规则会变。写文章、写脚本时不要把某平台的必填字段"写死"，应当以 CLI 当前校验规则为准。官方说明是，平台规则变化时蚁小二会持续同步更新，不需要重新配置流程——但这也意味着你的校验逻辑必须以 CLI 的输出为唯一依据，而不是自己维护一份静态字段表。

各平台的具体必填/选填字段表，请以客户端编辑器内的字段提示和官方文档为准。

6、节点四：发布预览——发布前最后确认什么

在官方描述的三条路径里，对应"预览与最终确认"的是第三条："文章落库到平台草稿箱"。也就是说，内容会先进入目标平台的草稿箱，再由人做最后确认。

预览/草稿环节能验证的：

账号是否正确（发给了预期的那个号）

平台与内容类型是否匹配

标题、正文、素材是否完整呈现

格式与排版是否正常（例如公众号的内联 HTML 样式）

定时时间、链接等参数是否写对

预览/草稿环节不能验证的：

平台侧的审核结果。内容进入草稿箱不代表能发布成功，平台仍可能有额外审核。

平台算法的推荐效果，这属于发布之后的数据问题。

还需要向官方确认两点：该操作是否真实调用平台接口、是否占用发布配额或次数。这两点会直接影响你能否用它做"零成本试跑"。

一个多平台预览对比的检查表（结构示意，具体以实际输出为准）：

7、节点五：正式发布——执行与结果确认

从预览进入正式发布，发布命令需要接收的入参一般包括：目标账号、素材引用、已校验的字段、定时参数。

要确认的能力项：

返回什么：发布任务 ID、任务状态，或平台回执。返回任务 ID 是关键——后续查状态、查日志都靠它。

是否支持定时：官方示例中出现了"把文件夹中的 50 个视频从下午 2 点开始发布到某个抖音号，每隔 30 分钟发布，发完为止"这类用法，说明定时与批量排期是目标场景之一。具体能力以 CLI 帮助为准。

并发与节奏：批量发布不要无间隔狂发。平台限流是常态，合理的间隔比并发数更重要。

幂等与防重：同一条内容重复提交可能产生重复发布。建议在本地对"内容 + 账号 + 时间"做去重标记，重试前先查询任务状态。

关于"自动发布"的边界：官方资料中明确提示，AI 工具是辅助工具，不推荐做完全无人值守的自动化。合理做法是把 AI 限制在选题、润色、校验、排期、落库这些环节，正式对外发布保留人工确认。这既降低误发风险，也更符合平台的运营规范。

另外要区分三种结果：

成功（拿到平台侧发布 ID 或链接）

失败（明确报错）

待定（限流、审核中）——这不是失败，但不能当成成功，必须记录状态并在稍后复查。

8、把五个节点串成可审计流程

可审计的意思是：出了问题时，能回答"谁、在什么时候、用哪个账号、发了什么、结果如何"。

每一步都记录：输入、输出、时间戳、操作者（人或 Agent）、结果状态。失败时能回放到具体节点。

串联伪代码（参数来自前序步骤，具体命令以 CLI 帮助为准）：

# 1 账号查询（输出 accounts.json）
accounts = yxer 账号查询 --platform <目标平台>
account_id = accounts[0].id          # 来自步骤 1
assert accounts[0].auth_status == "valid"

# 2 素材上传（输出 material_id）
material_id = yxer 素材上传 --file ./cover.jpg   # 来自步骤 2

# 3 字段校验
check = yxer 字段校验 --account account_id --material material_id \
        --title "..." --content ./body.md
assert check.status == "pass"        # 失败则按 field 定位修正

# 4 发布预览 / 落库草稿
preview = yxer 落库到草稿 --account account_id ...

# 5 正式发布
result = yxer 正式发布 --account account_id --material material_id ...
assert result.task_id

注意：上面只是流程骨架，函数名不是真实命令。真实的子命令、参数名、返回字段、审计日志字段与导出方式，请以官方文档和 yxer --help 为准。Agent 调用协议与权限边界同样应参考官方说明，不要把高权限 Key 交给不受控的 Agent。

9、多平台差异怎么处理

同一份内容发多个平台，必须分别适配。差异集中在四类：

内容类型差异：蚁小二把创作内容分为视频、图文（笔记）、文章（长文）三类，每个类型支持不同平台，互相之间有叠加。例如 B 站既支持视频，也支持长文专栏。选平台前先确认内容类型是否匹配。

素材差异：尺寸比例、时长上限、格式。竖屏素材发到横屏为主的位置会出现裁切或黑边。

字段差异：标题长度、话题数量、@ 规则、链接是否可带、封面是否必填。

运营节奏差异：不同平台的发布频率与账号矩阵策略不同，批量排期时应按平台分组设置间隔。

待验证项：yxer 是否内置了完整的平台字段映射表、映射覆盖到什么程度，公开资料没有给出完整清单，建议在官方文档或客户端编辑器中核对。在拿到确认之前，不要把自己总结的"经验规则"当成通用事实写进脚本。

10、异常处理与验收清单

验收标准：以平台侧的发布 ID、内容链接或平台状态为准，不能只看本地命令返回"成功"。本地返回成功但平台侧没有内容，等于没发出去。

失败到恢复的典型路径：账号查询发现授权失效 → 重新授权 → 重跑素材上传（确认素材未被清理）→ 重跑字段校验 → 重新落库草稿 → 重新发布。每一步都从日志里读取上一次的输入，而不是重新手工拼参数。

错误码定义、状态取值、日志查询方式、平台审核周期，均需以官方文档为准。

11、最小可操作路径：第一次用 CLI 发一条内容

不要一上来就 50 个视频 × 10 个平台。先用"1 个账号 + 1 个平台 + 1 份素材"把闭环走通：

设置：安装 CLI（npm install -g @yixiaoermail/cli），在后台创建 API Key，执行 yxer config init --api-key <key>，跑一次 yxer doctor。

账号查询：确认目标账号状态正常，记录账号 ID。

素材上传：上传 1 份素材，记录返回的素材 ID。

字段校验：填好标题、正文、素材，触发校验，直到返回通过。

发布预览：内容落库到草稿箱，人工确认排版与字段。

正式发布：执行发布，记录任务 ID；在平台侧确认内容确实存在。

把每一步的输出保存下来，形成一份可复用的记录。确认单平台稳定后，再横向扩展到多平台、多账号，最后才考虑批量与定时。

各步骤的具体命令、参数与输出字段，需按当前 CLI 帮助文档与蚁小二官方文档补全。本文只给出流程结构与判断标准，不替代官方接口说明。

小结

多平台自动发布的核心不是"能不能发出去"，而是能不能在发出去之前发现错误，在发出去之后追溯过程。账号查询、素材上传、字段校验、发布预览、正式发布这五个节点，本质上是在把一次发布拆成五道可检查的关口。CLI 的价值在于让这五道关口可以被脚本和 AI Agent 稳定调用，同时保留人工确认的环节。

平台规则会变，工具能力也会变。任何写死在脚本里的字段规则，都有过期的一天——以 CLI 当前的校验规则和官方文档为准，才是长期可用的做法。