Postiz CLI 与 MCP:一套先审核、后发布的社交媒体排程流程

2026 年 9 月独立实测笔记: 我使用 Postiz 托管版排程并监测 LazyingArt 的帖子。本流程用 Postiz CLI 2.0.15 实测;官方源码此后已有更新,因此请根据实际安装版本重新核对每条命令。本文没有赞助,也没有推广链接;排程成功不等于真正公开发布,更不等于产生收入。

真正有用的自动化边界不是“让 Agent 到处发帖”,而是:

让软件准备、排程和观察;由人确认准确的目的地、文案、媒体和不可逆操作。

这个区别很重要:每个平台的字段和规则不同;排程器返回成功后,仍可能没有可核验的公开帖子;互动也不等于线索或成交。

1. 先判断 Postiz 是否适合

当你管理多个渠道、需要可审核的日历、需要平台专属设置,或想通过 CLI、API、MCP 建立受控流程时,Postiz 比较合适。如果你只是偶尔在一个平台发帖,它可能没有必要。把备份、升级、数据库、存储、OAuth 应用、平台密钥、监控和事故处理计算在内后,自托管也不一定更便宜。

需求实际选择
希望减少基础设施维护,使用持续维护的排程器Postiz 托管版
需要完整基础设施控制,并愿意维护整套系统官方开源 Postiz 部署
只在一个平台偶尔发一条直接使用该平台
自动回复或未经请求的互动不要使用本流程

官方仓库是开源的,但目前的 Docker Compose 不止一个容器。它包括 Postiz、PostgreSQL、Redis,以及带独立 PostgreSQL、Elasticsearch、管理工具和 UI 的 Temporal stack。请阅读当前部署文件,不要复制旧文章中的局部 compose 片段。

2. 安装和认证时不要泄露凭据

该 package 要求 Node.js 18 或更高版本。从 npm 安装 CLI,并确认自己实际运行的版本:

npm install -g postiz
postiz --version
postiz auth:login
postiz auth:status

OAuth 设备流程会把凭据保存在 ~/.postiz/credentials.json。不要把这个文件、API key、OAuth token、集成 ID、组织标识符或原始命令输出放入 Git、截图、Issue 或 Agent 对话记录。当前 CLI 的 auth:status 会显示 token 前缀和组织标识符;即使是缩略输出,也应当视为私密信息。

如果 OAuth 凭据与 POSTIZ_API_KEY 同时存在,CLI 优先使用 OAuth。测试时应使用不含任何生产 integration 的独立 Postiz 账户或 organization。单独的 shell 或浏览器 profile 并不是权限边界。

3. 读取每个平台的实时约定

不要根据旧示例硬编码平台 schema。先列出已连接的集成,在私密环境中选择目标,然后读取它当前的设置:

postiz integrations:list

INTEGRATION_ID="replace-with-the-reviewed-private-id"
postiz integrations:settings "$INTEGRATION_ID"

设置响应会说明字符限制、必填字段、平台专属选项和动态工具。例如,Reddit 目的地可能要求 subreddit、标题、帖子类型,以及通过平台工具选出的 flair。在 CLI 2.0.15 实测中,有些无关设置会被忽略,而不是被拒绝。这是观察到的行为,不是 API 保证;应始终遵循实时 schema 与 rules。

把集成 ID 放在忽略提交的本地配置或短期 shell 变量里。公开 campaign 文件只应包含 xinstagram 之类的稳定标签,而不是账户标识符。

4. 先建草稿,再进入排程

即使只生成草稿,posts:create 也是会改变状态的命令。运行前先核对目的地、ISO 8601 时间、时区、文案和设置:

postiz posts:create 
  -c "Platform-specific copy reviewed by a person" 
  -s "YYYY-MM-DDTHH:MM:SSZ" 
  -t draft 
  -i "$INTEGRATION_ID"

随后在可见的 Postiz 日历中检查已保存草稿,以及界面实际提供的 preview。只有这些内容无误后,才把它移入队列:

POST_ID="replace-with-the-reviewed-private-post-id"

# Starts the publishing workflow at the draft's stored date.
postiz posts:status "$POST_ID" --status schedule

# Before provider publication, withdraw it and terminate the running workflow.
postiz posts:status "$POST_ID" --status draft

如果平台已经发布,撤回 workflow 并不等于回滚公开帖子。不要因为 CLI 接受多个 integration ID,就向所有渠道发送完全相同的文字:X、Instagram、Reddit、LinkedIn 和视频平台不仅技术限制不同,读者预期也不同。

第一次测试请使用可撤销、没有外部链接的草稿。不要拿付费 campaign、客户私密文档,或误发后会造成伤害的消息做测试。

5. 先上传媒体,再附加到帖子

媒体字段需要 Postiz 上传流程返回的 URL,不应传入任意本地文件名或第三方网址。先上传、检查响应,再只使用返回的 path:

UPLOAD_JSON="$(postiz upload ./reviewed-cover.png)"
MEDIA_URL="$(printf '%s' "$UPLOAD_JSON" | jq -er '.path | strings | select(length > 0)')"

postiz posts:create 
  -c "Reviewed caption" 
  -m "$MEDIA_URL" 
  -s "YYYY-MM-DDTHH:MM:SSZ" 
  -t draft 
  -i "$INTEGRATION_ID"

排程前,请核对本地文件的尺寸、类型、视频或音频时长、使用权,以及是否包含私密元数据。对于 TikTok、YouTube、Instagram 等重媒体平台,应在每次使用前立即读取 integration settings;发布方式和必需披露可能改变最终结果。

6. 把排程器状态与公开证据分开

队列项目不是公开帖子。平台 ID 不一定对应可用的公开 URL。点击不是线索,待结算佣金也不是收入。

用有限日期范围查看排程状态:

postiz posts:list 
  --startDate "YYYY-MM-DDT00:00:00Z" 
  --endDate "YYYY-MM-DDT23:59:59Z"

对于声称已经发布的项目,应在可见浏览器中打开准确 release URL,核对账户、内容、媒体、时间和目的地。如果帖子分析返回 {"missing": true},不要自动连接第一个搜索结果:

postiz posts:missing "$POST_ID"

# Only after visually identifying the exact provider item:
postiz posts:connect "$POST_ID" --release-id "$REVIEWED_RELEASE_ID"
postiz analytics:post "$POST_ID" -d 30

发布结果不明确时应检查,而不是重试;重试可能制造重复帖子。Postiz post、integration 与 release ID 只能保存在私密且有访问控制的记录中。使用 content hash 或 idempotency 记录检测重复,不要把这些 ID 暴露在公开 log。我的 monitor 只产生审核提醒,不自动回复或重新提交。

7. 把 MCP 凭据视为可写,并增加审核门槛

Postiz 也提供官方 MCP endpoint。目前文档列出 11 个工具:它可以列出 integrations 与 posts、读取 schema、调用平台辅助工具、修改尚未发布帖子的设置、创建草稿或排程/立即发布帖子,并生成媒体;目前不能读取或回复评论。

优先使用能向 https://api.postiz.com/mcp 发送 Authorization: Bearer ... header 的客户端。官方也记录了把 API key 放入 URL 的方式,但 URL 更容易出现在浏览器历史、proxy log、截图和诊断信息中。请把 secret 放进客户端的私密凭据机制;一旦暴露就立即轮换。

MCP 凭据具有写权限,而 prompt 只是行为指引,不是访问控制。应使用客户端的 tool approval,或使用不含生产 integrations 的测试 organization。给 Agent 的指令应当明确:

Before any write call, return the intended account name, UTC time, HTML
content, attachment URLs, provider settings, and unresolved fields.

After explicit approval, call schedulePostTool once with type=draft only.
Do not use type=schedule or type=now, generate media, shorten links, or
modify an existing post.

与 CLI -c 的普通文本不同,MCP 帖子内容必须是 HTML:每行用 <p> 包裹,并且只使用当前 tool reference 允许的 tag。MCP 只是让 Postiz 操作更容易调用;它不会取消平台规则、同意要求或公开发布核验。

8. 托管版与自托管如何选择

如果最稀缺的是运维注意力,选择 Postiz 托管版。如果确实需要基础设施控制,并且能够维护完整依赖、存储、TLS/reverse proxy、备份、升级、OAuth 凭据和平台 callback,再选择自托管。

自托管应从当前官方 Docker Compose 仓库和迁移说明开始。不要假设 latest 可以复现,应固定经过审核的 release;替换所有示例 secret;保持数据库和上传存储为私有;并测试 reverse proxy 是否支持 MCP streaming。即使自托管,仍然依赖外部平台的 API 和政策。

9. 可重复的“先审核”清单

  1. 验证认证状态,但不要分享输出。
  2. 列出 integrations,并私下选择准确目的地。
  3. 读取该 integration 的实时设置与工具。
  4. 编写平台专属文案并核对链接。
  5. 每个媒体文件都先上传和检查,再附加。
  6. 用明确的 UTC 时间创建草稿。
  7. 检查已保存草稿,以及界面实际提供的 preview。
  8. 只排程或发布一次。
  9. 核对准确公开帖子后,才记录发布成功。
  10. 把回复当作审核提醒,把分析当作信号;只有实际收到的钱才算收入。

这套流程比盲目交叉发布慢,但对小型品牌已经足够快,也更容易审计。

商业与推广边界

本文目前只使用普通、无追踪链接,不会产生 Postiz 推广佣金。你可以直接访问普通 Postiz 官网开源仓库,不经过推广追踪。

如果以后加入追踪链接,它必须位于一篇可以独立解决问题的指南之后,旁边有清晰披露,并保留同样醒目的普通入口;在申请、准确项目条款、归因、撤销、收款路线和已签发 URL 经过私下核验前,链接必须保持禁用。自动生成的社区回复中不应出现推广链接。

主要资料来源

Leave a Reply