admin/contentm_agent
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
contentm_agent/执行会话/目标-调研5个开源内容工作台项目并生成分析文档-5199a6/docs/pm/content-workbench/证据附卷/1b-竞品分析-Postiz与PostSider同源双形态.md
T
WorkBuddy df56c2c137 初始化提交：contentm_agent 工作区全量快照 
内容分四块：
1、产品规划产出 —— MCN 短视频整合营销工作台的①段五份（1a 需求／1b 竞品／1c 画像／1d 策略／1e 场景）、②段两份（2a 功能／2b 布局）、③段界面（DESIGN.md 契约与令牌表 ＋ mcn-workbench.html 原型 ＋ 实测/会诊/审查三份 ＋ 23 张闸门截图）。
2、开源竞品调研 —— 5 个内容工作台项目的取证原始件与 1b 系列分析文档。
3、参考资料 —— 竞品视频抽帧 1145 张 ＋ 2 个源视频 ＋ 功能点截图。
4、机制侧 —— 协作脚本与状态台账、工作区记忆日志、抽帧/OCR 脚本。

.gitignore 只排运行时日志、脚本备份副本与一次性探针输出，其余按原样入库。
2026-10-08 08:13:02 +08:00

33 KiB
Raw Permalink Blame History

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 节按两家各给三组四行。

  • 第 1 节写了它属哪一层、为什么纳入（判据是用户的选择，不是名气），两家分开写
  • 第 2 节四行都在（形态 / 给谁用 / 干什么用 / 证据等级），两个形态各一组，没有留白
  • 第 3 节六行动作链都在（进入方式 / 操作路径 / 核心步骤 / 系统帮了什么 / 最终产出 / 哪一步最省力·最麻烦），两个形态各一组；无截图已在节首点名标注推断
  • 第 4 节每项能力都接了「解决什么问题 / 起什么作用」
  • 第 5 节每条机制都接了「为什么这样设计 ⇒ 给用户什么结果」
  • 第 6 节每组强弱都是四行（能力表现 / 在什么场景 / 相对谁 / 对用户什么结果）
  • 第 7 节三分类齐全（该借鉴 / 该避开 / 可突破）
  • 按用户口径合并为一份，同源关系与两个形态的差异都在本份内写清
  • 已过内容准则，评分 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。

Reference in new issue View Git Blame Copy Permalink