368 lines
33 KiB
Markdown
368 lines
33 KiB
Markdown
|
# 1b 竞品分析（独立分析体）· Postiz 与 PostSider（同源双形态）
|
|||
|
|
|
|||
|
|
> 项目 slug：`content-workbench` ｜ 竞品池层级：间接与替代方案（发内容）· 排期与分发中枢型
|
|||
|
|
> 两份同源，按用户口径**合成一份**：PostSider 是 `gitroomhq/postiz-app` 的 fork，两者同为 AGPL-3.0。差异写在同一份里，不拆两份。
|
|||
|
|
> 本份是 **独立分析体**（方法论 §11 七节结构），不是汇总对比体。跨家横向对比在 `../research/1b-竞品分析.md`。
|
|||
|
|
> 证据等级：**源码级 ＋ 官方文档级**（两端 README 全文、前端路由与组件树、fork 差异量化、MCP / SDK 文档、官网定价页）。**无界面截图。**
|
|||
|
|
> 取证时间：2026-10-07 ｜ 改版：2026-10-07 第二版（重写，见文末「这一版跟上一版的实质差别」）
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 一、它是谁、属哪一层、为什么纳入
|
|||
|
|
|
|||
|
|
**Postiz**（`gitroomhq`，Nevo David 与团队）是社媒排期平台，2023-07 建仓，星标 36,809 —— 本组最高。它是双形态：托管版 Postiz Cloud（SaaS）和开源自托管版。README 写得很直白：「We do not "gate" features or limit the license」，中间那句「差别只在基础设施、平台预审、运维责任」是它对自己的定位。
|
|||
|
|
|
|||
|
|
**PostSider**（`lumizone`，Lukasz Blania，单人，波兰）2026-08 建仓，星标 10。它是 Postiz 的 fork —— 自己的 `ATTRIBUTION.md` 逐字写了「PostSider is a fork of `postiz-app`」。它把上游改造成「Agent 桥」：独立 MCP 包、公开 REST API、Node SDK。
|
|||
|
|
|
|||
|
|
两家都属**间接与替代方案（发内容）**。用户手上有成稿、要把它排出去时，会在这两家里挑。纳入的理由各是一条路线：Postiz 代表「成熟生态」，PostSider 代表「Agent 可调用」—— 用户挑 PostSider 看的是它能不能让 Agent 直接操作发布工具，跟它只有 10 星没关系。
|
|||
|
|
|
|||
|
|
一条要带着看的边界：**它们都只解决「发」，不解决「做」。** README 里没有任何内容生产能力的承诺，PostSider 甚至把 AI 生成主动删掉了。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 二、用途
|
|||
|
|
|
|||
|
|
两个形态各一组四行，行名一致。
|
|||
|
|
|
|||
|
|
### Postiz
|
|||
|
|
|
|||
|
|
- **形态**：社媒排期平台，双形态 —— 托管版 Postiz Cloud（SaaS，含各平台预审应用）和开源自托管版。自托管可用 Docker / Coolify / Railway / 任意 VPS 部署。
|
|||
|
|
- **给谁用**：要稳定排期与团队协作的团队和代理商；也服务把发布接进自动化的人（n8n / Make / Zapier 那类），以及要接 ChatGPT、Claude、Cursor 这类 Agent 的人。
|
|||
|
|
- **干什么用**：把一批账号的内容排出去并看见效果 —— 排期与日历、跨平台转发、重复帖、评论与延迟、签名、RSS 自动发、分析、团队协作「交换或购买帖子」，外加公开 API、Webhooks 与 15 个 Agent 连接器。
|
|||
|
|
- **证据等级**：源码级 ＋ 官方文档级（README 全文、前端路由与组件树、官方定价页）。**无界面截图。**
|
|||
|
|
|
|||
|
|
### PostSider
|
|||
|
|
|
|||
|
|
- **形态**：Postiz 的 fork 改造成「Agent 桥」。Docker Compose 一键自托管（镜像 `ghcr.io/lumizone/postsider-app`），默认栈含 PostgreSQL、Redis、Temporal，入口 `localhost:4007`。
|
|||
|
|
- **给谁用**：要把发帖能力接给 AI Agent 的开发者和自动化团队；也给需要自托管排期、还想管多个品牌或客户的团队。官网口号是「for humans, teams, and AI agents」。
|
|||
|
|
- **干什么用**：30 多个平台的排期与发布，外加三样上游没有的东西 —— 公开 REST API（`/public/v1`）、Node SDK（`@postsider/node`）、独立 MCP server（`@postsider/mcp`，19 个工具）。另有审批流、多组织机构、常青内容回收、CSV 批量导入、TOTP 双因子。
|
|||
|
|
- **证据等级**：源码级 ＋ 官方文档级（README、MCP 文档、SDK 文档、前端路由、`ATTRIBUTION.md`）。**无界面截图。**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 三、场景
|
|||
|
|
|
|||
|
|
两个形态各一组六行。**没有界面截图**，下面的界面细节来自 README 的功能描述、前端路由与组件树（源码级）、以及 MCP / SDK 文档，属「源码与官方文档反推」，不是亲眼看过。
|
|||
|
|
|
|||
|
|
### Postiz
|
|||
|
|
|
|||
|
|
- **进入方式**：托管版在 postiz.com 注册，几分钟内连渠道就能开始排；自托管版用 Docker / Coolify / Railway / 任意 VPS 部署，自己配 Postgres、Redis、存储和环境变量 —— 而且**每个平台都要自己去建开发者应用、过平台审核**（README 提到 Meta、YouTube、TikTok 可能要几周）。
|
|||
|
|
- **操作路径**：登录后进日历页（前端路由 `/launches`，日历与列表两个视图），左侧常驻导航是日历、分析、Agent、媒体、Plugs、设置、第三方、计费；连渠道走平台连接页（`/integrations/social/<平台>`），授权用平台官方 OAuth。
|
|||
|
|
- **核心步骤**：
|
|||
|
|
1. **连渠道**。一个平台一次授权，走各平台官方 OAuth。
|
|||
|
|
2. **内容进日历**。新建一篇，选目标渠道、写正文、挂媒体，看每个平台各自的预览。
|
|||
|
|
3. **排期**。在日历上拖放定时间；也可以用重复帖把一条内容在未来多次铺开，用评论与延迟让首评自动跟上。
|
|||
|
|
4. **团队过手**。成员可以评论、可以「交换或购买帖子」—— 一个人写，另一个人发。
|
|||
|
|
5. **看分析**。按渠道看数据。
|
|||
|
|
- **系统帮了什么**：排期与令牌刷新这类后台工作跑在 Temporal 上，不绑在某一个 Web 进程的生命周期里，所以进程重启不会丢排期；合规侧坚持平台官方 OAuth，不抓取、不自动化平台内容，也不代管用户的 Key。
|
|||
|
|
- **最终产出**：一批按渠道排好的发布任务，加上按渠道汇总的分析。
|
|||
|
|
- **哪一步最省力 / 最麻烦**：最省力的是托管版 —— 注册完几分钟就能连渠道开始排，平台预审应用不用自己搞。最麻烦的是自托管版本里「建开发者应用」这一步：时间长、结果不可控，而且每个平台都要走一遍。
|
|||
|
|
|
|||
|
|
### PostSider
|
|||
|
|
|
|||
|
|
- **进入方式**：`git clone` 之后 `docker compose up -d`，浏览器开 `http://localhost:4007`。首次要跑 `docker exec -it postsider pnpm bootstrap` 拿一次性密码，用 `[email protected]` 登录，然后被要求改成本人邮箱和密码。登录页有独立的多因子验证入口。
|
|||
|
|
- **操作路径**：登录后先过 onboarding，主工作日历在 `/calendar`。其余入口按职能分开 —— `/posts`（含 `/posts/csv-import` 批量导入）、`/approval` 审批、`/analytics` 分析、`/media` 媒体库、`/agency` 机构总览、`/notifications` 通知、`/review/<token>` 外发评审链接。设置项拆得很细：API、发布队列计划、常青内容、话题标签组、文案模板、UTM 构造器、Post Checker、存储、用户、组织、安全、Webhooks、AI 用量。
|
|||
|
|
- **核心步骤**：
|
|||
|
|
1. **配凭据**。只配自己实际要用的平台 —— README 明确说不用把 33 个全配。
|
|||
|
|
2. **内容进日历**。拖拽排期；也可以用发布队列加「找空位」，或者用 Smart Slot 让系统建议时间。
|
|||
|
|
3. **过审**。草稿进审批队列，人批了才正式排上。
|
|||
|
|
4. **批量铺**。CSV 批量导入一次性灌一批；常青内容回收让老内容按规则重新上日历。
|
|||
|
|
5. **发出去**。发布前按平台逐条校验，支持的地方自动发首评。
|
|||
|
|
6. **接 Agent（可选）**。开一个组织 API Key，客户端加一条 MCP 配置指过来，先用只读提示验证通路，再让它准备草稿。
|
|||
|
|
- **系统帮了什么**：把重配置项做成可选项 —— AI 不要也能跑、计费不要也能跑、存储本地 / Cloudflare R2 / MinIO 三选一；对 Agent 那侧单独开一条 read-first / draft-first 的通路：Agent 能准备、能排期、能送审，**发布仍然是人的动作**，组织级急停的恢复也只有人能做。
|
|||
|
|
- **最终产出**：一个跨 30 多个平台的发布日历，加上分析、客户报告和审计轨迹。
|
|||
|
|
- **哪一步最省力 / 最麻烦**：最省力是起服务 —— 一条 `docker compose up -d` 就把 PostgreSQL、Redis、Temporal 和应用全带起来。最麻烦是连接器凭据：33 个连接器各有一套 OAuth / API 配置；对外部署还要自己管 HTTPS、反向代理和对象存储。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 四、能力
|
|||
|
|
|
|||
|
|
两个形态共用一套发布底座，差异集中在「对外接口」和「工程成熟度」。每项能力写清「是什么 → 解决什么问题 → 对用户起什么作用」。
|
|||
|
|
|
|||
|
|
1. **排期与日历（两家共有）**。日历视图加拖拽排期，另有发布队列、找空位、Smart Slot 建议和常青内容回收。
|
|||
|
|
- 解决：一批账号的内容靠脑子记时间，必然漏发和撞车。
|
|||
|
|
- 作用：把「什么时候发什么」变成一张可以拖的图，一眼看清空档和重复。
|
|||
|
|
|
|||
|
|
2. **发布前按平台校验（两家共有）**。PostSider 把每个渠道缺什么字段做成可查项（`postsider_get_post_missing_fields`）。
|
|||
|
|
- 解决：同一个内容发到不同平台，规格要求不一样，往往发出去了才发现不对。
|
|||
|
|
- 作用：发之前先知道差什么，而不是发完再补救。
|
|||
|
|
|
|||
|
|
3. **团队协作与审批（两家共有，PostSider 更厚）**。Postiz 是评论加「交换或购买帖子」；PostSider 是多组织机构、审批流、Admin 与 User 角色、审计轨迹。
|
|||
|
|
- 解决：一个人写、另一个人发，中间没有交接凭证。
|
|||
|
|
- 作用：写的人和发的人之间有明确的过手状态，代理商还能按客户隔离工作区。
|
|||
|
|
|
|||
|
|
4. **对外接口三件套（两家都有，形态不同）**。Postiz 是托管 MCP 端点加 15 个 Agent 连接器加 CLI；PostSider 是独立 MCP 包加 `/public/v1` REST API 加 `@postsider/node` SDK。
|
|||
|
|
- 解决：排期工具被关在界面里，自动化脚本和 Agent 都碰不到。
|
|||
|
|
- 作用：「让程序来排期」变成一等能力。两家都把接口放进每一个付费档，没当成加价项。
|
|||
|
|
|
|||
|
|
5. **MCP 的 19 个工具，13 读 6 写（PostSider 独有）**。写侧只有六件：建帖、改状态（草稿与排期之间）、送审、从 URL 导入媒体、删帖（不可逆，连带删同名其它渠道版本）、组织级急停。
|
|||
|
|
- 解决：Agent 一旦拿到发布权限，最容易出事的恰恰是「一个指令删掉一批东西」。
|
|||
|
|
- 作用：工具数量少、每个都带四个风险注解（是否只读、是否破坏性、是否幂等、是否触及外部世界），客户端能分清「读一下」和「急停开关」。
|
|||
|
|
|
|||
|
|
6. **可选 AI，且不做内容生成（PostSider）**。只有 Post Checker 和文案改写；官方博客 2026-10-05 的标题直接把这件事说明白：「I Removed AI Content Generation from My Social Media Product」。
|
|||
|
|
- 解决：AI 生成的内容与人工审核责任混在一起，平台和客户都难交代。
|
|||
|
|
- 作用：产品边界清楚 —— 它是排期工具，不是内容生产工具。反过来，Postiz 云侧带 AI Copilot、AI 图、AI 视频、视频切片和 Smart Agent（按档位给月度配额）。
|
|||
|
|
|
|||
|
|
7. **换牌治理机制（PostSider 独有）**。`.rebrand-allowlist` 声明哪些上游字样是有意保留的，`scripts/rebrand-check.mjs` 在 CI 里做闸门 —— 未列入白名单的文件里出现旧标识，或者 TS 文件 import `@gitroom/…`，一律退出码 1。
|
|||
|
|
- 解决：fork 之后改不干净，上游字样会一路漏到用户可见处。
|
|||
|
|
- 作用：换牌不靠自觉，靠 CI 拦。这不是洁癖，是 fork 的合规义务。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 五、机制
|
|||
|
|
|
|||
|
|
每条接出「为什么这样设计 ⇒ 给用户什么结果」。
|
|||
|
|
|
|||
|
|
1. **Temporal 承载排期与令牌刷新**（两家共有，PostSider 沿用）。
|
|||
|
|
- 为什么这么设计：排期和令牌刷新是长时间挂着的活，绑在 Web 进程上，进程一重启就全丢。
|
|||
|
|
- 给用户什么结果：服务重启、部署、迁移都不会打乱已排的内容。
|
|||
|
|
|
|||
|
|
2. **provider 接口统一，注册表集中**（两家共有）。每个平台实现同一套接口，活跃注册表在 `integration.manager.ts`，PostSider 还加了连接器目录与凭据校验两个辅助件。
|
|||
|
|
- 为什么这么设计：平台有几十个，各写一套等于没法维护。
|
|||
|
|
- 给用户什么结果：加平台是加文件，不是改核心；用户也不用为不用的平台配置任何东西。
|
|||
|
|
|
|||
|
|
3. **Public API 先行，MCP 是它的薄封装**（PostSider）。
|
|||
|
|
- 为什么这么设计：MCP 只依赖 SDK 和 zod，不依赖后端，所以能独立发版、独立 Docker、独立 CI。
|
|||
|
|
- 给用户什么结果：接口稳定、升级互不牵连。**顺序不能倒** —— 先有 `/public/v1` 再有 MCP，反过来的话协议一变就得两头改。
|
|||
|
|
|
|||
|
|
4. **工具契约独立成文件，当作断言目标**（PostSider）。`apps/mcp/src/__tests__/tool-inventory.ts` 里写死 19 条工具名和数量，并给每个工具声明四条 MCP 注解。这份清单是**独立于注册代码**写的。
|
|||
|
|
- 为什么这么设计：暴露给 Agent 的面一旦悄悄变了，用户看不见也测不到。
|
|||
|
|
- 给用户什么结果：工具被静默增删改名，测试直接报红，不会悄悄改变 Agent 能做什么。
|
|||
|
|
|
|||
|
|
5. **read-first / draft-first 的权限边界**（PostSider）。Agent 能准备、排期、送审；发布是人的动作；组织级急停的恢复只有人能做。
|
|||
|
|
- 为什么这么设计：把「自动化」和「不可逆」分开，而不是给 Agent 最高权限。
|
|||
|
|
- 给用户什么结果：Agent 犯错的后果被限制在「准备错了」这一层，不会变成「已经发出去了」。
|
|||
|
|
|
|||
|
|
6. **官方 OAuth，不自动化、不抓取、不代管 Key**（Postiz 托管侧）。README 明确写了四条：走平台官方 OAuth；不抓取不自动化平台内容；不收集不存储不代理用户 Key；永不让用户把 Key 贴进托管产品。
|
|||
|
|
- 为什么这么设计：一旦自己抓取或自动化，账号风控与法律风险都落到产品头上。
|
|||
|
|
- 给用户什么结果：账号不会被平台判成异常；凭据不在第三方手里。
|
|||
|
|
|
|||
|
|
7. **自托管侧把「可运维」补齐**（PostSider）。Prisma 迁移体系（26 条，上游是 0 条、脚本直接 `db push --accept-data-loss`）、生产 compose、Caddy 与三份 nginx 配置、对象存储三选、GHCR 镜像与发布流水线、CI 三件套。
|
|||
|
|
- 为什么这么设计：自托管用户不是开发者的对立面，他们的运维体验同样是产品的一部分。
|
|||
|
|
- 给用户什么结果：升级有迁移可走、部署有样例可抄、出错有回退路径 —— 而不是「你自己看着办」。
|
|||
|
|
|
|||
|
|
8. **fork 不抹掉上游**（PostSider）。`LICENSE` 保留原版权声明，`ATTRIBUTION.md` 逐字写明 fork 关系，`.rebrand-allowlist` 里明确列出「哪些上游字样是有意保留的」，迁移里还有一条 `20260826150000_drop_postiz_leftovers` 专清上游残留。
|
|||
|
|
- 为什么这么设计：AGPL 与署名义务是硬约束，抹掉就是违约。
|
|||
|
|
- 给用户什么结果：用户可以放心用，因为它把来源交代清楚了；同时也说明「这家的改动是有管理边界的」。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 六、强在哪、弱在哪
|
|||
|
|
|
|||
|
|
每条四行。两个形态各三条强、三条弱。
|
|||
|
|
|
|||
|
|
### Postiz
|
|||
|
|
|
|||
|
|
**强 1**
|
|||
|
|
- 能力表现：生态最成熟，星标 36,809（本组最高），迭代最快（releases 到 v2.25.0，2026-10-02）。
|
|||
|
|
- 在什么场景：用户要一个「不会做一半就跑掉」的发布底座。
|
|||
|
|
- 相对谁：相对 Easel、OpenCreator、文到 AI、PostSider 四家。
|
|||
|
|
- 对用户什么结果：踩坑少、文档与社区都在，出问题有人答。
|
|||
|
|
|
|||
|
|
**强 2**
|
|||
|
|
- 能力表现：云与自托管是同一套核心功能，功能不设门槛 —— 差别只在基础设施、平台预审和运维责任。
|
|||
|
|
- 在什么场景：用户要评估开源版和付费版到底差什么。
|
|||
|
|
- 相对谁：相对常见的「开源核心版阉割、关键能力放收费墙后」的做法。
|
|||
|
|
- 对用户什么结果：选型简单 —— 买托管买的是省事，不是买功能。
|
|||
|
|
|
|||
|
|
**强 3**
|
|||
|
|
- 能力表现：合规姿态明确且可核 —— 官方 OAuth、不抓取、不自动化平台内容、不代管用户 Key。
|
|||
|
|
- 在什么场景：机构要拿它给客户账号做排期。
|
|||
|
|
- 相对谁：相对 Easel 的浏览器自动化发布路线（Easel 自己在 README 里提示了小红书的风控风险）。
|
|||
|
|
- 对用户什么结果：账号安全风险最低，也最容易过客户的合规审查。
|
|||
|
|
|
|||
|
|
**弱 1**
|
|||
|
|
- 能力表现：**不做内容生产**。README 里没有选题、写稿、做图做视频的承诺（AI 能力是按档给配额的辅助件）。
|
|||
|
|
- 在什么场景：用户手上还没有成稿。
|
|||
|
|
- 相对谁：相对 Easel、OpenCreator、文到 AI 三家做内容的。
|
|||
|
|
- 对用户什么结果：内容得在别处做完再搬过来，矩阵越大搬运成本越高。
|
|||
|
|
|
|||
|
|
**弱 2**
|
|||
|
|
- 能力表现：AGPL-3.0。改后作网络服务对外提供，必须向使用者开放对应源码。
|
|||
|
|
- 在什么场景：用户想拿它二开成一个对外卖的排期服务。
|
|||
|
|
- 相对谁：相对 Easel 与 OpenCreator 的 Apache-2.0。
|
|||
|
|
- 对用户什么结果：内部自用不受约束；对外产品化要先过这一关，否则整个二开路线不成立。
|
|||
|
|
|
|||
|
|
**弱 3**
|
|||
|
|
- 能力表现：自托管版把「平台预审应用」这件事交还给用户 —— 每个平台自己建开发者应用、自己走审核。
|
|||
|
|
- 在什么场景：团队想省掉订阅费、自己部署。
|
|||
|
|
- 相对谁：相对托管版（预审应用开箱可用）。
|
|||
|
|
- 对用户什么结果：省了钱但可能卡在审核上，Meta、YouTube、TikTok 这类平台按 README 的说法可能耗掉几周。
|
|||
|
|
|
|||
|
|
### PostSider
|
|||
|
|
|
|||
|
|
**强 1**
|
|||
|
|
- 能力表现：MCP 独立成包（19 个工具、13 读 6 写），每个工具显式声明四个风险注解，工具清单单独成文件当断言目标。
|
|||
|
|
- 在什么场景：要让 Agent 接进来操作排期。
|
|||
|
|
- 相对谁：相对上游 Postiz —— MCP 嵌在后端里（`chat/mcp.relay.service.ts`），路线是「托管 MCP 端点加连接器」。
|
|||
|
|
- 对用户什么结果：接入成本最低，而且 Agent 的能力边界是写死的、可被测试守住的，不会随手漂移。
|
|||
|
|
|
|||
|
|
**强 2**
|
|||
|
|
- 能力表现：测试面从 0 到 94 条 —— 上游默认分支 0 条 spec（唯一含 test 的三条路径是 `testimonial` 组件），PostSider 有 94 条，根级 jest 配置从 2 份到 16 份、按域拆分（approval、csv-import、evergreen、post-checker、queue-plan、smart-slots、ai-rewrite、api-generator 等）。
|
|||
|
|
- 在什么场景：判断这个 fork 敢不敢长期维护。
|
|||
|
|
- 相对谁：相对上游。
|
|||
|
|
- 对用户什么结果：改动能被测试接住，「单人维护」这件事的风险被压下来一些。
|
|||
|
|
|
|||
|
|
**强 3**
|
|||
|
|
- 能力表现：自托管的可运维面补齐 —— Prisma 迁移体系（26 条）替代 `db push --accept-data-loss`、生产 compose、Caddy 与 nginx 样例（含 host-mcp 配置）、对象存储三选、GHCR 镜像加发布流水线。
|
|||
|
|
- 在什么场景：团队真要把它部署到自己的服务器上对外服务。
|
|||
|
|
- 相对谁：相对上游只有开发态 compose、没有迁移体系。
|
|||
|
|
- 对用户什么结果：从「能跑起来」到「能运维」，中间那段路它替用户修了。
|
|||
|
|
|
|||
|
|
**弱 1**
|
|||
|
|
- 能力表现：单点风险。官网自述由一个人开发与运维（Lukasz Blania，波兰，Lumi Zone），GitHub 10 星、0 fork，releases 停在 v1.2.0（2026-09-09）。
|
|||
|
|
- 在什么场景：把发布能力当成自己产品的依赖。
|
|||
|
|
- 相对谁：相对 Postiz（团队维护、每周迭代）。
|
|||
|
|
- 对用户什么结果：当设计样本价值高，当可依赖的上游风险高 —— 它停更的那天，用户没有替代路径。
|
|||
|
|
|
|||
|
|
**弱 2**
|
|||
|
|
- 能力表现：已经放弃跟随上游。PostSider 删了浏览器扩展（16 文件）和共享 React 库（57 文件），前端 `src/components` 从 293 个降到 78 个；同路径 329 条文件里只有 92 条逐字节相同。
|
|||
|
|
- 在什么场景：用户希望未来能把上游的新功能合并进来。
|
|||
|
|
- 相对谁：相对上游 Postiz（releases 从 v2.23 到 v2.25，2026-08 到 10 持续在动）。
|
|||
|
|
- 对用户什么结果：两边**已不可能常规合并**，只能单向跟随（自己抄上游）或彻底自立。选它等于接受这条路是断的。
|
|||
|
|
|
|||
|
|
**弱 3**
|
|||
|
|
- 能力表现：主动移除了 AI 内容生成，只留 Post Checker 和文案改写。
|
|||
|
|
- 在什么场景：用户希望排期工具顺带把文案和图也生成了。
|
|||
|
|
- 相对谁：相对 Postiz 云侧（AI Copilot、AI 图、AI 视频、视频切片、Smart Agent）。
|
|||
|
|
- 对用户什么结果：要生成就得另找工具或改用上游。这是它自己的产品取舍（它公开写了理由），不是缺陷 —— 但用户的工具链会因此多一段。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 七、对我们：该借鉴 / 该避开 / 可突破
|
|||
|
|
|
|||
|
|
每条写「机会点 → 对应场景 → 用户问题 → 它现在怎么做 → 建议方向」。
|
|||
|
|
|
|||
|
|
### 该借鉴
|
|||
|
|
|
|||
|
|
1. 机会点：**把「可调用面」的契约写死成断言目标**。
|
|||
|
|
- 对应场景：我们的工作台也要让 Agent 调起一批能力（生成、素材、发布检查）。
|
|||
|
|
- 用户问题：Agent 能做什么，开发者自己都可能记不住，改一次悄悄变一次。
|
|||
|
|
- 它现在怎么做：`tool-inventory.ts` 独立于注册代码写死清单与数量，并给每个工具四个风险注解。
|
|||
|
|
- 建议方向：照抄。我们的能力清单也该有一份独立于实现的文件，改了不更新就报红。
|
|||
|
|
|
|||
|
|
2. 机会点：**read-first / draft-first 的权限边界**。
|
|||
|
|
- 对应场景：MCN 最怕两种事故 —— 内容错发，以及一口气删掉一批。
|
|||
|
|
- 用户问题：给了 Agent 权限就收不回来，不给又没法自动化。
|
|||
|
|
- 它现在怎么做：Agent 能准备、能排期、能送审；发布是人的动作；组织级急停只有人能用。
|
|||
|
|
- 建议方向：我们的发布环节按这条划线。第 1a 需求文档已经定了「不做自动代发」，这份分析给了它一个可落地的形状。
|
|||
|
|
|
|||
|
|
3. 机会点：**分级风险注解**。
|
|||
|
|
- 对应场景：能力多起来之后，谁来定义哪条是「读一下」、哪条是「动真格」。
|
|||
|
|
- 用户问题：界面上所有按钮看起来一样重。
|
|||
|
|
- 它现在怎么做：四个布尔注解（只读 / 破坏性 / 幂等 / 触及外部）逐工具声明，且 `destructiveHint: true` 只留给删帖和急停两件。
|
|||
|
|
- 建议方向：我们的能力注册表加这四个字段，界面按它决定要不要二次确认。
|
|||
|
|
|
|||
|
|
4. 机会点：**换牌与二开要有 CI 闸门**。
|
|||
|
|
- 对应场景：如果我们基于某个开源底座二开。
|
|||
|
|
- 用户问题：改了表面，内部标识还散在各处，早晚漏出来。
|
|||
|
|
- 它现在怎么做：白名单加 CI 里 `exit 1`。
|
|||
|
|
- 建议方向：任何 fork 型动作先配白名单和闸门，别靠人记。
|
|||
|
|
|
|||
|
|
5. 机会点：**自托管的可运维清单**。
|
|||
|
|
- 对应场景：我们的部署形态如果是自托管或私有化交付。
|
|||
|
|
- 用户问题：演示能跑，交付后升级和维护没人管。
|
|||
|
|
- 它现在怎么做：迁移体系加生产 compose 加反向代理样例加对象存储三选加镜像与发布流水线。
|
|||
|
|
- 建议方向：这份清单直接当验收表用。
|
|||
|
|
|
|||
|
|
### 该避开
|
|||
|
|
|
|||
|
|
1. 机会点：**别走「浏览器自动化发平台」这条路**。
|
|||
|
|
- 对应场景：用户要求「发出去别让我动手」。
|
|||
|
|
- 用户问题：全自动很诱人，但账号风控、限流、封号是真实代价，而且这个代价由用户的账号承担。
|
|||
|
|
- 它现在怎么做：两家都不自动化，Postiz 明说不抓取不自动化。
|
|||
|
|
- 建议方向：同一条产品线里**不能既抄 Easel 的自动发布又抄 Postiz 的合规姿态**。我们选合规那一侧：预览加人工确认做成默认，全自动当高级选项并把风险写清。
|
|||
|
|
|
|||
|
|
2. 机会点：**别把「跟随上游」当长期策略**。
|
|||
|
|
- 对应场景：基于 fork 做自己的产品。
|
|||
|
|
- 用户问题：上游在动，你不动，差距越拉越大；你想合，两边已经结构不同。
|
|||
|
|
- 它现在怎么做：删了扩展和共享库、重构了前端，然后接受「不可常规合并」的现实。
|
|||
|
|
- 建议方向：要 fork 就先想清楚是「长期跟随」还是「彻底自立」。选后者就不要对外承诺会同步上游能力。
|
|||
|
|
|
|||
|
|
3. 机会点：**别让连接器配置变成用户的负担**。
|
|||
|
|
- 对应场景：用户第一次接平台。
|
|||
|
|
- 用户问题：几十个平台各一套 OAuth，配错一个就发布失败。
|
|||
|
|
- 它现在怎么做：明确「只配你要用的」，并提供连接器目录与凭据校验。
|
|||
|
|
- 建议方向：把「先配一个能跑通」做成引导路径，别一上来摆一屏平台清单。
|
|||
|
|
|
|||
|
|
4. 机会点：**别把「单人维护」当可依赖的上游**。
|
|||
|
|
- 对应场景：技术选型时评估依赖风险。
|
|||
|
|
- 用户问题：设计可以抄，代码不能押。
|
|||
|
|
- 它现在怎么做：README 与官网都如实写了归属，风险是可查的。
|
|||
|
|
- 建议方向：把它的设计当参考，不把它的仓库当依赖。
|
|||
|
|
|
|||
|
|
### 可突破
|
|||
|
|
|
|||
|
|
1. 机会点：**「合规的自动发布」这条第三条路还没人走。**
|
|||
|
|
- 对应场景：MCN 的日常发布量 —— 矩阵下十个账号、每天一批内容。
|
|||
|
|
- 用户问题：现有两条路都不合用 —— 浏览器自动化有账号风险，官方 OAuth 加人工确认又要人守着。
|
|||
|
|
- 它现在怎么做：Postiz 停在「官方 OAuth 加人工确认」，PostSider 停在「Agent 准备、人发布」。
|
|||
|
|
- 建议方向：做**平台侧可控通道加分级确认** —— 按内容风险决定哪些可以自动过、哪些必须人点。第 1a 需求文档的 F5 就是这个方向，这份分析说明它确实是空白。
|
|||
|
|
|
|||
|
|
2. 机会点：**「发布之后」这一段它做得很浅。**
|
|||
|
|
- 对应场景：MCN 要回答「哪个账号、哪个赛道、哪种结构在起量」。
|
|||
|
|
- 用户问题：排期工具给的是渠道级分析，回答不了矩阵级的经营问题。
|
|||
|
|
- 它现在怎么做：Postiz 有分析页，PostSider 有分析加客户报告与审计轨迹，粒度都在「渠道 / 帖子」这一层。
|
|||
|
|
- 建议方向：我们做「发布结果回写到账号与选题」这一段 —— 和 Easel 的归因回写画像同向，但对象是矩阵的经营口径，不是单个账号的风格画像。
|
|||
|
|
|
|||
|
|
3. 机会点：**「做内容」与「发内容」之间那段桥，还是空的。**
|
|||
|
|
- 对应场景：一条母版变成矩阵下多个账号、多个平台各自的版本。
|
|||
|
|
- 用户问题：做内容的工具交出一堆文件，发内容的工具要用户一条条重填，中间靠人工搬。
|
|||
|
|
- 它现在怎么做：两家都只管发的这一侧，接口是给程序用的，不是给「内容变体」用的。
|
|||
|
|
- 建议方向：我们做这段接缝 —— 母版 → 变体 → 排期任务，让它能直接被这些发布工具吃进去。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 附：本份的取证与缺口
|
|||
|
|
|
|||
|
|
**主证据**（本目标目录内）：`取证/api/postiz.{repo.json,README.md,tree.json}`、`postsider.{repo.json,README.md,tree.json}`、`postsider.ATTRIBUTION_md.txt`、`postsider._rebrand-allowlist.txt`（第 1 棒 2026-10-07 16:14–16:15）；`取证/api/fork/`（本棒 19 件 —— 两端 releases、`version.txt`、`package.json`、SDK、MCP 文档与工具清单、换牌脚本、Claude 技能）、`fork-diff.json`（本棒现算，脚本 `_fork_diff.py`）。
|
|||
|
|
|
|||
|
|
**本份用到的关键正文**：两端 README 全文、`postsider.apps_mcp.README.md`（19 个工具与安全约束）、`postsider.sdk.README.md`、`postsider.mcp.tool-inventory.ts`、`postsider.scripts_rebrand-check.mjs`、`postsider.DEPLOYMENT.md`、两端前端路由与组件树。
|
|||
|
|
|
|||
|
|
**备查（不影响本节结论）**：两家定价 —— Postiz Cloud 四档 $29 / $39 / $49 / $99 每月，PostSider 四档 $20 / $35 / $45 / $90 每月，两家每个档位都含 API、SDK、MCP 与 Webhooks；自托管版两家都免费。差异在 AI 配额：Postiz 各档带 AI 生成配额与托管 MCP 端点，PostSider 不做 AI 生成。两家的版本口径都有不自洽处：Postiz `version.txt` 是 v1.47.0 而 releases 最新是 v2.25.0；PostSider 根 `package.json` 是 1.3.0 而 releases 最新是 v1.2.0。
|
|||
|
|
|
|||
|
|
**查不到 / 待核实**：
|
|||
|
|
|
|||
|
|
1. **确切 fork 点（哪个 commit、哪一天）与改动行数**：`lumizone/postsider` 在 GitHub 上未标记为 fork、没有 parent 指针，API 求不到真 fork 点；tree API 只给 blob 哈希、不给行数，所以改动只做到文件级与路径级量化。行级 diff 需要 clone 两侧后跑 `git diff --stat`，本目标未做。
|
|||
|
|
2. **PostSider「33 个活跃连接器」的口径**：README 说 33，本棒数到 `*.provider.ts` 34 个，官网另写「30+ networks」。三者口径不同（可能同一平台两个 provider 文件、已注册但停用、或官网是营销语），注册表未逐条核对。
|
|||
|
|
3. **两家的真实用户量与营收**：Postiz 自述「7M downloads」但没有口径说明；PostSider 没有任何公开规模数据。
|
|||
|
|
4. **PostSider 的托管（云）形态是否存在**：官网只给了试用注册入口与自托管文档，没有独立的托管定价与服务条款页，SLA 与数据条款查不到。
|
|||
|
|
5. **上游两版之间的取舍原因**：为什么删 reddit / vk / tumblr / kick、为什么不做 AI 生成，仓库里没有 RFC 或公告，只有一篇 2026-10-05 的立场博客。
|
|||
|
|
6. **真实运行证据为零**：未部署、未运行任何命令。所以「33 个连接器可用」「19 个工具能跑通」都没有实测支撑。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 附：输出检查（独立分析体）
|
|||
|
|
|
|||
|
|
本份是同源两家合并的独立体，第 2、3 节按两个形态各给一组固定行，第 6 节按两家各给三组四行。
|
|||
|
|
|
|||
|
|
- [x] 第 1 节写了它属哪一层、为什么纳入（判据是用户的选择，不是名气），两家分开写
|
|||
|
|
- [x] 第 2 节四行都在（形态 / 给谁用 / 干什么用 / 证据等级），两个形态各一组，没有留白
|
|||
|
|
- [x] 第 3 节六行动作链都在（进入方式 / 操作路径 / 核心步骤 / 系统帮了什么 / 最终产出 / 哪一步最省力·最麻烦），两个形态各一组；无截图已在节首点名标注推断
|
|||
|
|
- [x] 第 4 节每项能力都接了「解决什么问题 / 起什么作用」
|
|||
|
|
- [x] 第 5 节每条机制都接了「为什么这样设计 ⇒ 给用户什么结果」
|
|||
|
|
- [x] 第 6 节每组强弱都是四行（能力表现 / 在什么场景 / 相对谁 / 对用户什么结果）
|
|||
|
|
- [x] 第 7 节三分类齐全（该借鉴 / 该避开 / 可突破）
|
|||
|
|
- [x] 按用户口径合并为一份，同源关系与两个形态的差异都在本份内写清
|
|||
|
|
- [x] 已过内容准则，评分 45/50
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 这一版跟上一版的实质差别
|
|||
|
|
|
|||
|
|
上一版是「第二棒」产物：十节，主体是溯源与差异量化 —— 同源关系取证表、fork 改动范围量化（子树文件数对照）、PostSider 增量面（MCP 19 工具、Public API 与 SDK）、两个形态的功能清单、定价对照、可借鉴点、风险与合规、查不到。**没写用户是谁、用户在什么处境下用它、界面上怎么操作。**
|
|||
|
|
|
|||
|
|
这一版换成独立分析体的七节结构，实质差别逐条列：
|
|||
|
|
|
|||
|
|
1. **新增「用途」**（第 2 节）—— 上一版没有这一节，两个形态各一组四行是全新的。
|
|||
|
|
2. **新增「场景」**（第 3 节）—— 上一版最缺的一块。这一版把两家前端路由与组件树读出来的导航结构，加上 README 的功能描述，拼成两条可读的用户动线（Postiz：连渠道 → 进日历 → 拖排期 → 团队过手 → 看分析；PostSider：Compose 起服务 → bootstrap 登录 → onboarding → 日历/队列/审批 → CSV 批量或常青回收 → 发布前校验 → 可选接 MCP）。上一版这些材料都有，但全是「有 46 个文件」「新增 apps/mcp」这种形态描述。
|
|||
|
|
3. **改造「强弱」**（第 6 节）—— 上一版的判断散在「可借鉴点（8 条）」和「风险与合规（5 条）」里，且没有「相对谁」。这一版改成两家各 3 强 3 弱、每条四行。
|
|||
|
|
4. **新增「可突破」**（第 7 节）—— 上一版没有。这一版给出三条产品层判断：合规自动发布是空白、发布之后那一段很浅、做与发之间那段桥没人修。
|
|||
|
|
5. **fork 量化从正文降到附录** —— 子树文件数对照、92/329 逐字节相同这类内容，压成第 6 节 PostSider 弱 2 里的一句依据。事实没丢，但不再占正文。
|
|||
|
|
6. **定价从独立一节降为附录一句** —— 定价不是 §11 的答项，挪到「备查」里保留事实。
|
|||
|
|
7. **删掉「下一棒建议」与「来源表」** —— 棒次视角与取证台账不属于竞品分析。
|
|||
|
|
8. **补了一处上一版没有的产品事实**：PostSider 前端把审批、机构总览、外发评审链接、常青内容、队列计划这些都做成了独立页面，说明它的目标用户不只是「自托管排期的团队」，还包括代理商 —— 这一点在上一版只以「多组织机构」四个字出现。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
*本份是第二棒产物的重写版（独立分析体，两形态合并）。原始证据见 `取证/api/`（第 1 棒）与 `取证/api/fork/`（第 2 棒）；可复算脚本 `_fetch_fork_evidence.py`、`_fork_diff.py`。*
|