2026 年 9 月独立实测笔记: 我使用 Postiz 托管版排程并监测 LazyingArt 的帖子。本流程用 Postiz CLI
2.0.15实测;官方源码此后已有更新,因此请根据实际安装版本重新核对每条命令。本文没有赞助,也没有推广链接;排程成功不等于真正公开发布,更不等于产生收入。
真正有用的自动化边界不是“让 Agent 到处发帖”,而是:
让软件准备、排程和观察;由人确认准确的目的地、文案、媒体和不可逆操作。
这个区别很重要:每个平台的字段和规则不同;排程器返回成功后,仍可能没有可核验的公开帖子;互动也不等于线索或成交。
Table of Contents
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 文件只应包含 x、instagram 之类的稳定标签,而不是账户标识符。
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. 可重复的“先审核”清单
- 验证认证状态,但不要分享输出。
- 列出 integrations,并私下选择准确目的地。
- 读取该 integration 的实时设置与工具。
- 编写平台专属文案并核对链接。
- 每个媒体文件都先上传和检查,再附加。
- 用明确的 UTC 时间创建草稿。
- 检查已保存草稿,以及界面实际提供的 preview。
- 只排程或发布一次。
- 核对准确公开帖子后,才记录发布成功。
- 把回复当作审核提醒,把分析当作信号;只有实际收到的钱才算收入。
这套流程比盲目交叉发布慢,但对小型品牌已经足够快,也更容易审计。
商业与推广边界
本文目前只使用普通、无追踪链接,不会产生 Postiz 推广佣金。你可以直接访问普通 Postiz 官网或开源仓库,不经过推广追踪。
如果以后加入追踪链接,它必须位于一篇可以独立解决问题的指南之后,旁边有清晰披露,并保留同样醒目的普通入口;在申请、准确项目条款、归因、撤销、收款路线和已签发 URL 经过私下核验前,链接必须保持禁用。自动生成的社区回复中不应出现推广链接。
