admin/contentm_agent
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
contentm_agent/执行会话/目标-重写5份竞品分析文档并重新生成MCN短视-72111e/1b-竞品分析-汇总对比体.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 竞品分析 · 汇总对比体（内容工作台）

项目 slug：content-workbench　｜　原始目标：调研 5 个开源内容工作台项目并生成分析文档 本份是 1b 的汇总对比体，只做一件事：把 5 个竞品放在一起比 —— 共识是什么、差异在哪、哪里没人做好、我们要先解决什么。主线是五问：用途 → 场景 → 功能 → 作用 → 优势。 单个竞品的完整形态 / 给谁用 / 干什么用、用户把事办成的过程、它自己的能力与机制，在各家独立分析体里（证据附卷/ 5 份，写法判据见方法论 §11）。本份不重抄那部分，只保留横向对比需要的基线。 竞品池是 5 个开源项目，实际是 4 条独立产品线 ＋ 1 组同源双形态（见 §2）。 证据分三级：源码级（结论来自仓库文件树、源码或官方文件）· 官方文档级（只有官方自述与仓库元数据）· 界面级（有官方界面截图）。本次界面级只有 Easel 一家（4 张官方工作台截图）；文档级只有文到 AI 一家（无业务源码）。 原始证据在 取证/：api/ · api/fork/ · easel/ · opencreator/ · wendao/。取证时间见 §附 E。 改版说明（第二版，2026-10-07 22:3x）：第一版 21:41 写就，早于 4 份新版独立体，边界要重核（详见文末「这一版跟上一版的实质差别」）。本版按方法论 §0.4 收紧为纯横向：逐家的能力详述、机制详述交回独立体，只留横向铺开与选型结论。

0. 怎么读这份

五问落在哪：用途看 §3，场景看 §4，功能和作用都在 §5，优势看 §7。§8 的矩阵和 §10 的结论负责收口。

想知道「某一家具体长什么样、用户怎么用它」 —— 那不在本份，去读对应那家的独立分析体。本份只回答「摆在一起看，它们差在哪」。

文到 AI 的证据只到官方文档级，在本组不进源码级，凡引用处都已标注。它和另外 4 家的结论不同权。

许可、风险、取证冲突、缺口这四类工程与合规内容不进正文，统一放在 §附 A 到 §附 E。

1. 这次要回答什么

做一款自有内容工作台时，这 5 个项目各自把「用户的内容工作」做成了什么形态？哪些做法值得借鉴、哪些要避开、哪些还没被解决好？

竞品池见 §2。不展开的部分：用户量、下载量、营收、定价实测；行级代码 diff；各项目的真实运行验证（缺口见 §附 D）。

五问各自落在哪一节：

五问 关注点 落点
用途：是什么、给谁用、干什么用 What / Who §3
场景：用户在什么处境下用它 When / Why §4
功能：有哪些核心能力 What §5
作用：每项能力解决什么问题 What for §5
优势：相对谁、在哪些场景更强更弱 vs Whom §7

2. 选了哪些竞品

分三层：

  1. 直接竞品（做内容）：ZJU-REAL/Easel、krillinai/OpenCreator、wendaoai/wendao-content-workbench（文到 AI）。
  2. 间接与替代方案（发内容）：gitroomhq/postiz-app、lumizone/postsider。
  3. 点名参考实装：本次没有。原始目标只给了 5 个链接，所以全部按前两层收录。

为什么是这 5 个：用户要「把内容做出来」时，会在 Easel、OpenCreator、文到 AI 之间比，比的是全链路 / 媒体工厂 / 单平台桌面三条不同做法。用户要「把内容发出去、排期、接 Agent」时，两条路是成熟生态与 Agent 桥。

PostSider 是 postiz-app 的 fork —— 它的 ATTRIBUTION.md 里逐字写了这一点，两者同为 AGPL-3.0。所以这两个按一条产品线、两个形态处理；矩阵里分两列只为写清差异，同源关系回到 §附 C 第 3 条。

读的时候要带上一个前提：这 5 个不在同一赛道。 它们分属内容生产链的上游（做）和下游（发），这个分界后面每一节都要用到。

3. 用途基线（一行一家）

这一节只给「摆在一起比」需要的最小基线。各家完整的用途四行（形态 / 给谁用 / 干什么用 / 证据等级）在独立体 §2，本份不重抄。

竞品 形态 给谁用 用它干什么
Easel 开源社媒内容工作台，本地自托管（Web :7860 ＋ CLI） 要一条龙做社媒内容的个人或小团队 一个 Agent 贯穿「发现热点 → 策划选题 → 创作图文音视频 → 多平台发布 → 归因回写画像」
OpenCreator 创作者 AI 工作台，Web 单前端 ＋ Electron 壳，Codex 驱动 要批量做媒体的创作者 把 Agent 对话与可视化创作工具装在同一个本地 Runtime 上，批量生产视频、图像、语音、口播
文到 AI 本地优先的公众号写作 / 排版 / 配图桌面工具（Wails，三平台） 只做公众号一条线、在意数据留本机的人 从选题、写稿、排版、配图到发布准备，全在桌面端本地完成
Postiz 社媒排期工具（Cloud SaaS ＋ 开源自托管双形态） 要稳定排期与协作的团队 30+ 平台排期、分析、团队协作，并接受 n8n / Make / Zapier 式自动化接入
PostSider Postiz 的 fork，改造成「Agent 桥」（Docker Compose，入口 :4007） 要把发帖能力接给 AI Agent 的开发者 30+ 平台排期，加公开 REST API、Node SDK、MCP server（19 个工具）

「内容工作台」这个词在本组里指两种东西：做内容的（Easel、OpenCreator、文到 AI）和发内容的（Postiz、PostSider）。

4. 使用场景横向对比

横切方式：按内容生产链上的五个用户处境铺开，看用户在这个处境下要办成什么、各竞品怎么让他办成。不按竞品逐个写。

用户处境 Easel 文到 AI（文档级） OpenCreator Postiz PostSider
① 我该做什么（发现热点、定选题） 有，热点雷达聚合 6 到 8 个平台 有，热点雷达加营销日历 弱，有视频下载，没有热点发现 弱，RSS 自动发 弱，无
② 选题怎么排成计划 有，策划技能成组 有，选题库、系列规划、能力库编排 弱，脚本和模板 无 无
③ 把东西做出来 有，技能库带可运行脚本 有，写作、排版、配图、卡片工坊 有，十项创作工具加 108 条模板（视频翻译覆盖 14 源语言到 101 目标语言） 弱，AI Copilot 与图、视频、切片，要自带 Key 无，主动移除了 AI 内容生成
④ 发出去 有，7 平台，靠浏览器自动化喂入 弱，发布助手插件只填充不代发 无，不做发布 有，30+ 平台，走官方 OAuth 有，30+ 平台
⑤ 发完怎么复盘 有，归因结果回写账号画像 弱，公众号数据月度复盘 无 有，按渠道分析 有，分析和客户报告

⚠️ 文到 AI 那一列的证据只到官方文档级。它的「场景」在独立体 §3 里已写明六行动作链里三行整行取不到，本表的格子只是官方自述能支撑到的粒度，别当界面级事实读。

各自处境下「为什么这么做」（When / Why 这一层）：

① 到 ② 是做内容三家的主场。它们把「该做什么」当成产品入口。两家排期产品不做选题，因为用户是带着已成稿的内容来的。

③ 是分歧最大的一段。OpenCreator 把这段做成媒体工厂，批量、多语言、模板化；Easel 做成技能库，技能就是可运行脚本，产物落盘；PostSider 反过来主动移除了 AI 生成，它只服务已经有稿子的人。

④ 是产品边界的分水岭。Easel 用浏览器自动化把「发」也纳入闭环，自己在 README 里承认有平台风控风险；Postiz 不自动化也不抓取；文到 AI 只填充不代发；OpenCreator 干脆不做。这背后是两种用户价值：把 ④ 做进产品省下一次搬运，代价是把不可逆的动作交给了自动化；不做 ④ 少一段风险，但用户要手动搬一次。

⑤ 只有 Easel 做成了闭环。归因结果回写账号画像，下一轮的 ①② 由此收敛。这是本组唯一一处「用得越久越懂你」的设计。

5. 功能横向对比

维度按内容链路层建，可增不可缺：能力面、Agent 可调用面、内容治理。每项能力「解决什么问题 / 起什么作用」的完整写法在独立体 §4，本节只做横向。

5.1 能力面（按链路层）

维度 Easel 文到 AI OpenCreator Postiz PostSider
发现 / 热点 强，多平台热榜聚合 中，热点雷达 弱，仅视频下载 弱，RSS 弱，无
策划 / 选题 强，技能成组 中，选题库加系列规划 弱，脚本与模板 无 无
创作 强，技能库带脚本 中，写作 / 排版 / 配图 / 卡片工坊 最强，十项工具加 108 模板 中，自带 Key 无，主动移除
发布 中，7 平台自动化 弱，只填充不代发 无 最强，30+ OAuth 最强，30+
归因 强，回写画像 中，月度复盘 无 中，分析 中，分析 / 客户报告

横向看下来，能拉开差距的只有两段：创作（OpenCreator 最重）和发布（Postiz 与 PostSider 最全）。其余各段都有至少一家做得出，差异在深度不在有无。

5.2 Agent 可调用面

竞品 形态 解决什么问题
Easel OpenClaw Agent ＋ MCP 让技能能被 Agent 调起
OpenCreator MCP runtime 透传 Codex 不自造 Agent 循环，省一半工期
Postiz MCP 嵌在后端 ＋ CLI ＋ 15 个 agent 连接器 让现成 Agent 接进来
PostSider 独立 MCP 包，19 工具（13 读 6 写） 把「可调用面」做成独立产品件
文到 AI 无 —

这一行的横向结论：Agent 可调用面已经不是差异点。 5 家里 4 家都有，两家排期产品还把 MCP / API / SDK 放进了每一个付费档，没当成加价项。它已经从卖点变成基础能力。

5.3 内容治理（发布前）

横向铺开四家的姿态：

  • Easel：两道闸。content_guard.py 管敏感信息（API key、内部路径），fail-closed，退出码 7；persona_gate.py 管人设偏离，低于 80 分只告警。一道硬，一道软。
  • PostSider：read-first / draft-first。Agent 可以准备、排期、送审，发布仍然是人的动作；急停恢复也只有人能做。
  • 文到 AI：只填充不代发，把最后一步留给人。
  • Postiz：托管侧走平台官方 OAuth，不抓取、不自动化。
  • OpenCreator：不做发布，所以这一段没有对应设计。

横向看下来分两派：「硬拦 ＋ 软劝」「只填充不代发」是产品内的闸门；「不自动化平台」是产品外的合规姿态。两条不冲突，但见 §9.2 第 1 条 —— 同一条产品线里不能两头都抄。

6. 机制横向对比

§5 比的是「有什么」，本节比「同一个问题各家怎么解」。各家的完整机制清单在独立体 §5，本节只挑横向有分歧的几组。

1. 记忆与上下文的作用域。

  • Easel：按账号画像分（六维画像，画像目录即记忆作用域，不写全局文件）。
  • OpenCreator：按通用三级分（global / project / thread）；文档说明它不会自动保存，只给「存为长期记忆」的建议。
  • 文到 AI：单机本地 SQLite，没有账号维度。
  • Postiz / PostSider：没有内容记忆这一层。

⇒ 这一组的分歧是「作用域的粒度」。做内容的三家里，只有 Easel 把粒度收到了账号；OpenCreator 收到项目；文到 AI 干脆不做多账号。

2. 改稿与版本。

  • OpenCreator：修订产生新版本、不覆盖，带 sourceArtifactIds 溯源和 stale 标记。
  • 文到 AI：版本可对比、可采用、可继续改。
  • Easel：产物落 outputs/<主题>/，系统状态目录带 _ 前缀。

⇒ 修订不覆盖是本组的共识，两家独立出现同一条（OpenCreator、文到 AI）。Easel 走的是另一条路（按主题归档，不强调版本链）。

3. Agent 与人的分工。

  • Easel：发布前分级闸门，硬的拦、软的劝。
  • PostSider：read-first / draft-first，Agent 到「送审」为止，发布归人。
  • 文到 AI：插件只填公众号编辑器，不登录、不存草稿、不点发布。
  • Postiz：不自动化、不抓取。

⇒ 四家的落点不同，方向一致：把不可逆的那一步留给人。 这条在本组是共识，不是某一家的偏好。

4. 能力怎么加载 / Agent 引擎从哪来。

  • Easel：自建技能运行时，三层加载（元数据常驻 / 指令触发 / 资源按需），SKILL.md 不超过 200 行。
  • OpenCreator：不重写 Agent 引擎，全透传给 Codex，只做生命周期、事件归一化、持久化、调度与 UI。
  • 文到 AI：能力库，把多步骤编排成一套「创作方案」。

⇒ 这是唯一的真分歧：自建运行时（Easel）对上透传上游（OpenCreator）。两种都能跑，代价不同，见 §7 与 §9.2 第 1 条。

7. 优势与不足

每条都写清「相对谁 / 什么场景 / 什么结果」。逐家的完整强弱清单（每条四行）在独立体 §6，本表只留横向判断。

竞品 优势 不足
Easel 相对另 4 家，唯一覆盖「发现到归因」全闭环；在「要让内容越做越贴账号」的场景下，归因回写画像，输出持续收敛 相对 Postiz，发布环节用浏览器自动化；在「账号安全优先」的场景下，有风控、限流、封号风险（README 自陈）。安装门槛也高（Node 版本窗口窄，还要 FFmpeg 和 Chromium）
OpenCreator 相对另 4 家，媒体生成能力最强；在「批量做多语言视频」的场景下，十项工具加 108 模板，边际成本近零。工程治理也最重 相对自建引擎者，上游强耦合 —— Codex 一次破坏性变更就可能整体不可用。另外它不做发布，用户得另找出口
文到 AI（文档级） 相对另 4 家，单平台纵深最完整；在「只做公众号、要在意数据留本机」的场景下，端到端本地完成。产品侧 13 天发了 11 版 相对开源同行，闭源（全仓 5 blob），用户无法自审、无法二开；GitHub 侧只发文档（3★），社区支持弱
Postiz 相对另 4 家，生态最成熟、星标最高、迭代最快；在「要稳定排期与协作」的场景下，30+ 平台走官方 OAuth，合规且省维护 相对 Easel，不做内容生产。相对自用者，AGPL-3.0 意味着一旦作对外网络服务就得开放源码
PostSider 相对 Postiz，把 Agent 桥做成了独立件（19 工具 MCP 加 API 加 SDK）；在「要把发帖接给 Agent」的场景下，接入成本最低 相对 Postiz，单人开发、10★、发布停在 v1.2.0，且已放弃跟随上游。作设计样本有价值，作可依赖上游风险高

8. 竞品能力矩阵

能力 / 场景             Easel    文到AI    OpenCreator   Postiz    PostSider    机会
① 发现热点              强       中       弱            弱        弱           ← 全组普遍弱
② 选题与计划            强       强       中            —         —            ← 生产侧已有解
③ 内容生产              强       中       最强          中        主动放弃      ← 差异化主战场
④ 多平台发布            中(自动化) 弱(半)   无            最强      最强         ← 合规路线二选一
⑤ 归因回写              强       中       无            中        中           ← 只有 Easel 成闭环
⑥ Agent 可调用面        中       无       中            强        最强         ← 已成基础能力
⑦ 发布安全闸门          强(分级)  中       无            强        强           ← 已成基础能力
⑧ 本地优先/免密钥        强       强       强            弱        弱           ← 做内容侧共识

这张矩阵能看出五件事：

已经是基础能力、不再构成差异的：⑥ Agent 可调用面、⑦ 发布安全闸门、⑧ 本地优先与免密钥。

能拉开差距的：③ 内容生产（OpenCreator 最强）、④ 多平台发布（Postiz 和 PostSider 最强）。

某家独有的：只有 Easel 做出了 ⑤ 归因回写闭环；只有 PostSider 把 MCP 做成了独立产品件。

普遍做得不好的：① 发现热点 —— 做内容的三家里两家只是「有」，发内容的两家几乎不管。

还没被解决好的需求：④ 的合规自动化。现在只有「浏览器自动化（有风险）」和「OAuth 或只填充（要人工）」两条路，没有第三条。

取值口径：本矩阵只保留能区分竞品的行。⑦⑧ 作为「共识能力」行列保留，用途是提示「不必在这里找差异」。

9. 可借鉴点与产品机会

三类分开写。每条第 4 段「它现在怎么做」的完整版在独立体 §7，本节做的是三类汇总，并追回 §4 / §5 / §7。

9.1 该借鉴（竞品已验证有效，且与自有目标一致）

可以直接搬的工程做法（成本低、边界清晰）：

  1. 技能 / 工具契约独立成包 ＋ 版本常量（OpenCreator）—— 三端同源最低成本的一步。
  2. 状态机 ＋ 版本号 ＋ 幂等键三件套（OpenCreator）—— 为「远端到底收没收」专设 unknown_remote_acceptance / abandoned_unknown 两态。
  3. 工具契约独立成断言目标（PostSider）—— 把「Agent 能看到哪些工具」写死成独立清单，静默增删改名会直接测试报红。
  4. 每个工具显式声明四个风险注解（PostSider）—— readOnlyHint / destructiveHint / idempotentHint / openWorldHint。
  5. 换牌与二开闸门（PostSider）—— .rebrand-allowlist ＋ rebrand-check.mjs（CI exit 1）。
  6. 迁移回滚按「演练先行 ＋ 不变量 SQL ＋ 幂等复验」做（OpenCreator）—— 只建临时库，第二次修复必须 repaired=0。
  7. 性能门禁写进 CI 并带硬阈值（OpenCreator）—— 请求数、DOM 峰值、Long Task、gzip 预算。
  8. 「技能文档与脚本参数」机器校验（Easel）—— 防文档漂移。
  9. 独立更新清单（文到 AI）—— stable.json：channel / publishedAt / supportedPlatforms / 逐包 sha256 / 升级策略三字段。
  10. 可用版本回退的运行组件管理（OpenCreator）—— 定期检查更新但永不自动安装，失败时保留当前可用版本。

高价值的产品设计：

  1. 技能三层加载，SKILL.md 控制在 200 行内（Easel）。
  2. 发布前分级闸门：一道硬、一道软（Easel）。
  3. 出站内容安全要分级而不是全禁（Easel）。
  4. 「工作台」与「对话」共用同一状态机，修订产生新版本而非覆盖（OpenCreator）。
  5. read-first / draft-first 的产品边界（PostSider）。
  6. 画像六维，记忆作用域收敛到画像目录（Easel）。
  7. 付费操作的前置协议（Easel）—— 先给范围、计划、费用预估再请求。
  8. 本地与免密钥 provider 作一等公民（OpenCreator、文到 AI、Easel 共同）。
  9. 技能市场的合规面（OpenCreator）—— 每条带七项风险声明、给 Agent 的指令、给人的步骤、商业许可审查位。
  10. AGENTS.md 的分级验证铁律（OpenCreator）—— 同时治「动不动跑全量测试」和「用没跑的验证暗示无回归」。

9.2 该避开（竞品存在明显问题，不照搬）

  1. 同一条产品线里不能既自动发、又宣称合规。 Easel 走浏览器自动化（README 自陈风控风险），Postiz 走官方 OAuth、不抓取不自动化。两条是互斥的设计红线，选一条走到底。（追回 §4 ④、§5.3）
  2. 不把「薄壳透传」当默认路线（OpenCreator）—— 省工期的对价是上游一次破坏性变更就可能整体不可用。
  3. 不让对外文档与发行状态脱钩（文到 AI）—— README 停在「尚未发布」，实际已发 10 个版本。对外文档必须有「最后校准时间」。
  4. 不留命名双轨（OpenCreator）—— 产品改名了，内嵌 CLI、脚本、技能前缀还用旧名。
  5. 不用未核实授权的素材（OpenCreator 自述案例）—— 来源没复测的一律先设 draft。

9.3 可突破（需求真实存在，竞品解决得不够好）

  1. 发现热点这一段普遍弱（追溯 §5.1 ①、§8 ①）。三家「有」但不深，两家不管。机会在把「找题」做成真正的入口。
  2. 合规的自动发布是空白（追溯 §8 ④）。现有两条路是「有风险的自动化」和「要人工的半自动」，第三条路（平台侧可控通道加分级确认）还没人做好。
  3. 做内容与发内容之间那段桥，还是空的（追溯 §2、§4 ④）。用户要在两处搬一次。机会在只做中间那段可复用的桥，而不是再造一个全链路。

10. 结论（产品层）

  1. 用户最核心的需求是让「该做什么 → 做出来 → 发出去 → 知道效果」这条链跑通，并且越跑越顺，而不是买到某一项最强的功能。
  2. 竞品共同解决了什么：③ 内容生产（有模板或技能就够用）、④ 多平台发布（30+ 平台已是基础）、⑥ Agent 可调用面（已成基础能力，不再是卖点）。
  3. 竞品共同存在什么问题：① 发现热点普遍弱；④ 的合规自动化没人做好；⑤ 归因闭环只有一家做成。
  4. 已经是基础能力的：Agent 可调用面、发布安全闸门、本地优先与免密钥。
  5. 还能形成差异的：内容生产的批量化与本地化（OpenCreator 路线）；归因回写形成复利（Easel 路线）。
  6. 本产品应优先解决什么 —— 先立规范再堆能力。① 技能和工具先有规范且机器可校验；② 再立契约层，可版本化、可断言；③ 发布这类不可逆动作一律设分级闸门；④ 工程治理直接内化（分级验证铁律、把 unknown 当一等结论、迁移演练加幂等复验）。
  7. 一句话：本组没有对手，只有零件。Easel 给「技能即能力加治理闸门」的骨架，OpenCreator 给「契约化加治理铁律加迁移演练」的工程底座，Postiz 和 PostSider 给「分发中枢加 Agent 桥」的接口范式，文到 AI 给「单平台纵深加发布边界」的产品取舍。最划算的路径是：以 Easel 的技能体系为主干，以 OpenCreator 的契约与治理为工程底座，以 PostSider 的 read-first / draft-first 定发布边界，许可上只搬 Apache-2.0 那一侧的代码。

附 A. 许可与合规速查

要复用代码，只在 Apache-2.0（Easel、OpenCreator）里取。取 Easel 时先确认内联的 gzh-design（AGPL-3.0）是否在交付路径上。

只借鉴设计、不搬代码，这 5 项都能看。

要把 AGPL 项目（Postiz、PostSider）改后作网络服务对外，须开放对应源码；内部自用不受约束。

要复用官方文案、截图或品牌素材，只有文到 AI 明确禁止（proprietary，NOTICE.md）；其余以各自 LICENSE 为准。

附 B. 风险总表

项目 风险 级别 依据
Easel 平台风控：自动化发布到小红书存在验证、限流、封号风险 高 README 加 skill-xhs-publisher 风险段逐字（独立体 Easel §六 弱 2）
Easel 许可混用：主体 Apache-2.0 但内联 gzh-design 是 AGPL-3.0 中 独立体 Easel 附录「仓库自述口径差异」
Easel 依赖重、安装门槛高（Node 版本窗口窄） 中 独立体 Easel §六 弱 1
文到 AI 无 LICENSE：文案、截图、品牌素材均不可复制 高 NOTICE.md 逐字（独立体 文到 AI 附录「许可提醒」）
文到 AI 「免费」边界未核实（changelog 出现「商用绿色版」） 中 独立体 文到 AI 附录「查不到 / 待核实」第 3 条
文到 AI 闭源加静默更新（allowSkip: true） 中 独立体 文到 AI §五 机制 3
OpenCreator 上游强耦合：Codex 一次破坏性变更就可能整体不可用 高 独立体 OpenCreator §六 弱 1
OpenCreator 素材与商标再分发许可未在仓内单独声明 中 独立体 OpenCreator §六 弱 4
Postiz / PostSider AGPL-3.0 网络服务义务加上游署名义务 高（若对外） ATTRIBUTION.md 逐字（独立体 Postiz 与 PostSider §五 机制 8）
PostSider 单点风险：单人、10★、发布停在 v1.2.0 高 独立体 Postiz 与 PostSider §六 弱 1
全组 平台合规路线二选一，不可混：Easel 走浏览器自动化，Postiz 走官方 OAuth，文到 AI 只填充不代发 高（设计红线） 独立体 Easel §六 弱 2、Postiz 与 PostSider §七 该避开 1

附 C. 取证一致性复核（冲突读数，以原始件为准）

  1. Easel 技能数 113 与 114 冲突，以 114 为准。easel.tree.stat.json 里 skills_openclaw_dir_count = 114、skillmd_count = 114，用 取证/api/easel.tree.json 复算一致。113 是 README 旧徽章和能力地图的口径。
  2. Postiz 文件树「截断前」的措辞有误，实际未截断。_summary.json 里 tree_total_blobs = 1018、tree_truncated = false。真正被截断的是 OpenCreator 的树，已用 11 份分片补全。
  3. PostSider 连接器 33 与 34 冲突。34 是仓库里 *.provider.ts 的文件数（源码级），33 是 README 口径，30+ 是官网营销语，三者口径不同，引用时要标明。「活跃注册数」仍未逐条核对。
  4. OpenCreator 模板 108（79 / 28 / 1）：tree.stat.json 的 template_entries_by_category 三档全为 0，该派生字段失真，须以原始分片 tree_template.json 为准，复算吻合。
  5. Postiz 版本口径不一：version.txt 是 v1.47.0，releases 最新是 v2.25.0（2026-10-02），两处口径不一，原因查不到。

附 D. 已知取证缺口（照抄《目标执行状态.md》，不补编）

全组共性：五家的真实用户量、下载量、营收基本查不到（Postiz 自述「7M downloads」但没有口径）。真实运行证据为零 —— 全程只做静态取证，未安装、未编译、未运行任何命令。

Postiz 与 PostSider：fork 点（GitHub 未标记 fork、无 parent 指针）与改动行数（tree API 只给 blob sha，行级 diff 需要 clone 两侧）都未取到。PostSider「33 个活跃连接器」的口径未逐条核对；是否有托管云服务查不到。

Easel：CI 称 38 条技能自带测试，实际只测到 6 个测试文件；114 技能的 layer 源码级分布没做；SKILL-SPEC 的 test1.* 约定整树零文件；.env.example 里 xhs-maas / agnes provider 的来源未核实。技能可用率没有实测。

OpenCreator：商业与规模证据全缺；技能市场「上架态」口径未核实；docs/plans/ 10 份计划的落地率未核；火柴人、头像、音频的再分发许可未核；runtime/（183 个 blob，其中 .go 163 个）只做了结构级取证；语言构成是按文件数口径（与官方字节口径不可混）。

文到 AI：源码级面全部查不到；「商用绿色版」是什么查不到；updates/versions/ 只到 0.0.115 而 stable.json 已到 0.0.123，原因查不到。

附 E. 来源与取证时间

五个对象仓库：

  1. https://github.com/ZJU-REAL/Easel（main）
  2. https://github.com/wendaoai/wendao-content-workbench（main；主页 https://www.asfop.top/）
  3. https://github.com/krillinai/OpenCreator（master）
  4. https://github.com/gitroomhq/postiz-app（main；官网 https://postiz.com）
  5. https://github.com/lumizone/postsider（main；官网 https://postsider.com）
棒次 产物 / 证据 取证时间（CST） 落点
第 1 棒 5 项目元数据、README、文件树 2026-10-07 16:13–16:17 取证/api/*.{repo.json,README.md,tree.json} 加 _summary.json
第 2 棒 Postiz / PostSider 同源双形态，fork 差异 2026-10-07 16:40–17:05 取证/api/fork/（19 件）加 fork-diff.json
第 3 棒 Easel 深度分析 2026-10-07 17:06–17:19 取证/easel/（17 件）加 easel.tree.stat.json
第 4 棒 OpenCreator 深度分析 2026-10-07 17:37–17:56 取证/opencreator/（76 件）加 opencreator.tree.stat.json
第 5 棒 文到 AI 分析（文档级） 2026-10-07 18:07–18:10 取证/wendao/（20 件）
第 6 棒 跨项目汇总对比（本份第一版前身） 2026-10-07 18:31–18:5x 归档-1b旧口径/1b-竞品分析-跨项目汇总对比__旧口径-20261007.md
第 7 棒 5 份独立分析体重写（产品视角七节） 2026-10-07 21:40–22:01 证据附卷/（5 份）
第 8 棒 汇总对比体按新边界重排（本份） 2026-10-07 22:3x 本文件

这一版跟上一版的实质差别

上一版（21:41 写）已经按新方法论重排过一次，也过了「说人话」。但它写在新版独立体之前 —— 4 份独立身体是 21:58 到 22:01 才落盘的。于是它对边界、对证据等级的分类都停在旧认识上。

这一版的实质差别，逐条列：

  1. 证据等级从两级改成三级。 上一版写「证据分两级：源码级 / 文档级，本次只有文到 AI 落在文档级」。新版独立体里 Easel 是「源码级 ＋ 官方文档级 ＋ 界面级」（4 张官方截图），是本组唯一有界面级证据的一家。这一级是重写独立体时才补上的，上一版没有。

  2. §3 用途从「逐家细述」改成「一行一家的基线」。 上一版 §3 用一张三列表把五家的形态、给谁用、干什么用逐格写满，和独立体 §2 的用途四行重复。这一版只留对比基线，明写「完整四行在独立体 §2」，不再重抄。

  3. §5.1 后半的六项能力详述删掉了。 上一版在能力矩阵后面又挑了六项能力（技能即能力 / 创作模板体系 / 公开 API / 卡片工坊 / 能力库 / 画像记忆）逐条展开，那是逐家产品面，归独立体 §4。这一版只留矩阵加横向解读。

  4. §6 从「逐家机制罗列」改成「同一机制横向对比」。 上一版 §6 六条里，四条是单家机制（OpenCreator 两投影状态机、Easel 三层加载与分级闸门、OpenCreator 透传 Codex、Easel 画像记忆），按 §0.4 归独立体。这一版换成四组横向：记忆作用域、改稿与版本、Agent 与人的分工、能力加载与引擎来源 —— 每组比的是「同一个问题各家怎么解」。

  5. §7 表加了指引，§9 明标「细节在独立体 §7」。 优势不足表与三类汇总保留（它们是汇总体该写的），但都加了一行「完整清单在独立体 §6 / §7」，避免读者以为本份就是全量。

  6. 清掉悬空的节号引用。 上一版 附B 依据列写「第 2 棒 §八·4、第 3 棒 §十三·1」，上一版 附D 写「照抄《目标执行状态.md》§八」—— 这些指向的是旧棒次文档的编号，新版独立体早改成七节结构。这一版全部换成指向新版独立体的节号。

  7. §4 场景矩阵给文到 AI 那一列加了证据警示。 上一版直接填格；新版独立体已明确文到 AI 的场景「六行里三行整行取不到」。这一版在表下加了警示行，说明那一列只到官方自述粒度。

  8. §4 处境的格子从「技能计数」改成「能力强弱」。 上一版写「有，9 个热点技能加基础 6，共 15」「有，114 个技能」这类计数 —— 计数是独立体的事。这一版只留强弱与做法。

  9. 附 E 补了第 7、8 两棒。 上一版只到第 6 棒；这一版把「第 7 棒 独立体重写」「第 8 棒 汇总重排」补上，时间对得上。

没变的部分（事实一条没丢）：竞品池分层与纳入理由、§8 能力矩阵的八行与五个判断、§9 的三类条目、§10 的七条结论、§附 A 到 §附 D 的许可、风险、冲突读数与缺口。

本份是 1b 竞品分析的汇总对比体（第二版，2026-10-07 22:3x 按方法论 §0.4 收紧为纯横向）。独立分析体见 证据附卷/（5 份）；原始证据见 取证/；旧口径原件见 ../归档-1b旧口径/；本次改版前版本见 ../归档-说人话重写前-20261007/。本版落在目标目录 72111e 内，⛔ 未覆盖 research/1b-竞品分析.md。

Reference in new issue View Git Blame Copy Permalink