admin/contentm_agent
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
de9fd3338f6cad241f20f357242c10c05c007564
contentm_agent/执行会话/目标-调研5个开源内容工作台项目并生成分析文档-5199a6/docs/pm/content-workbench/归档-说人话重写前-20261007/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

29 KiB
Raw Blame History

1b 竞品分析 · 内容工作台

项目 slug：content-workbench　｜　原始目标：调研 5 个开源内容工作台项目并生成分析文档 本份定位：这是 1b 竞品分析的主份，按 1b 方法论 10 节骨架横向展开（用途 → 场景 → 功能 → 作用 → 优势）。 竞品池：5 个开源项目 / 实际 4 条独立产品线 ＋ 1 组同源双形态（见 §2）。 证据分级：【源码级】＝ 结论来自仓库文件树 / 源码 / 官方文件；【文档级】＝ 仅官方自述与仓库元数据（本次只有文到 AI）。 原始证据：取证/api/（第 1 棒）· 取证/api/fork/（第 2 棒）· 取证/easel/（第 3 棒）· 取证/opencreator/（第 4 棒）· 取证/wendao/（第 5 棒）。取证时间逐条见 §附 E。 单项目明细（证据附卷）：../证据附卷/1b-竞品分析-{5项目清单与初步定位, Easel, OpenCreator, 文到AI, Postiz与PostSider同源双形态}.md（5 份，只作证据回查，不入 ①段产出白名单）。 改版说明：2026-10-07 按新版《竞品分析方法论（1b · 产品视角）》重排，并收口为 ①段白名单要求的唯一一份 1b-竞品分析.md；旧口径原件（按维度罗列工程面）已归档 ../归档-1b旧口径/。

0. 本份怎么读

  • 五问（用途 / 场景 / 功能 / 作用 / 优势）的落点：§3 / §4 / §5 / §5 / §7；§8 矩阵与 §10 结论是收口。
  • ⚠️ 文到 AI 是文档级证据（仓库无业务源码，全仓 5 个 blob）⇒ 其结论不与另 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 个链接）⇒ 全部按 1 / 2 两层收录。

为什么是这 5 个（用户的选择面）：

  • Easel / OpenCreator / 文到 AI —— 用户要「把内容做出来」时，会在这三个里比：全链路 vs 媒体工厂 vs 单平台桌面。
  • Postiz / PostSider —— 用户要「把内容发出去 / 排期 / 接 Agent」时的两条路：成熟生态 vs Agent 桥。
  • 🔴 同源关系（必记）：PostSider 自述是 postiz-app 的 fork（ATTRIBUTION.md 逐字，同为 AGPL-3.0）⇒ 二者按一条产品线、两个形态处理；矩阵里分两列只为写明差异，同源关系见 §附 C · 3。

读法警告：本组不是同一赛道的 5 个直接竞品，而是「内容生产链的上游（做）与下游（发）」各若干 —— 这个分界后面每一节都要带着看。

3. 竞品用途（是什么 / 给谁用 / 干什么用）

竞品 是什么形态 给谁用 拿它干什么用
Easel 开源社媒内容工作台（本地自托管：Web :7860 ＋ CLI ＋ 单技能直跑） 要一条龙做社媒内容的个人/小团队 一个 Agent 贯穿「发现热点 → 策划选题 → 创作图文音视频 → 多平台发布 → 归因回写画像」
OpenCreator 创作者 AI 工作台（Web 单前端 ＋ Electron 壳；Codex 驱动） 要批量做媒体的创作者 把 Agent 对话与可视化创作工具装在同一个本地 Runtime 上，批量生产视频/图像/语音/口播
文到 AI 本地优先的公众号 AI 写作/排版/配图桌面工具（Wails，三平台） 只做公众号一条线、在意数据留本机的人 从选题、写稿、排版、配图到发布准备，全在桌面端本地完成
Postiz 社媒排期工具（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
① 我该做什么（发现热点/定选题） ✅ 9 个热点技能＋基础 6（共 15） ✅ 热点雷达 ＋ 营销日历 ⚠️ 有视频下载，无热点发现 ⚠️ RSS 自动发 ⚠️ —
② 选题怎么排成计划 ✅ 16 个策划技能 ✅ 选题库 / 系列规划 / 能力库编排 ⚠️ 脚本/模板 ⛔ ⛔
③ 把东西做出来 ✅ 114 个技能（含可运行脚本） ✅ 写作 / 排版 / 配图 / 卡片工坊 ✅✅ 108 模板 ＋ 10 项创作工具（视频翻译 14 源→101 目标语言等） ⚠️ AI Copilot/图/视频/切片（自带 Key） ⛔ 主动移除 AI 内容生成（只留 checker ＋ 改写）
④ 发出去 ✅ 7 平台（浏览器自动化喂入） ⚠️ 发布助手插件只填充不代发 ⛔ 不做发布 ✅✅ 30+ 平台（官方 OAuth） ✅✅ 30+ 平台
⑤ 发完怎么复盘 ✅ 11 个归因技能（回写账号画像） ⚠️ 公众号数据月度复盘 ⛔ ✅ 分析 ✅ 分析 / 客户报告

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

  • ①—② 是「做内容」三家的主场：它们把「该做什么」当成产品入口；两家排期产品不做选题，因为用户带着已成稿的内容来。
  • ③ 是分歧最大的一段：OpenCreator 把这段做成「媒体工厂」（批量、多语言、模板化）；Easel 做成「技能库」（技能＝可运行脚本，产物落盘）；PostSider 反过来主动移除 AI 生成 —— 它只服务「已经有稿子的人」。
  • ④ 是产品边界的分水岭：Easel 用浏览器自动化把「发」也纳入闭环（自陈有平台风控风险）；Postiz「不自动化、不抓取」；文到 AI 只填充不代发；OpenCreator 干脆不做。 ⇒ 用户价值差异：把④做进产品＝省一次搬运，但把不可逆动作交给了自动化；不做④＝少一段风险，但用户要手动搬一次。
  • ⑤ 只有 Easel 把「复盘」做成闭环：归因结果回写账号画像，下一轮 ①② 由此收敛 —— 这是本组唯一「用了越久越懂你」的设计。

判据自查：每一行都能说清「用户在什么处境下、要办成什么、为什么这时候会选它」。

5. 功能横向对比（能力 → 解决什么问题 → 起什么作用）

统一维度（按内容链路层建，可增不可缺）：能力面 / Agent 可调用面 / 媒体生成 / 内容治理。

5.1 能力面（按链路层）

维度 Easel 文到 AI OpenCreator Postiz PostSider
发现 / 热点 15 技能 热点雷达＋营销日历 ⚠️ 仅视频下载 ⚠️ RSS ⚠️ —
策划 / 选题 16 技能 选题库＋系列规划 ⚠️ 脚本/模板 ⛔ ⛔
创作 114 技能 写作/排版/配图/卡片工坊 108 模板＋10 工具 ⚠️ 自带 Key ⛔ 主动移除
发布 7 平台（自动化） 只填充不代发 ⛔ 30+（OAuth） 30+
归因 11 技能（回写画像） 月度复盘 ⛔ 分析 分析/客户报告

「是什么 → 解决什么问题 → 起什么作用」逐项（挑真正区分竞品的能力）：

  1. 技能即能力（Easel，114 个） —— 解决「功能清单写了但跑不起来」；作用是产物落盘、能力可被机器校验，不是文档里的名词。
  2. 创作模板体系（OpenCreator，108 条：image 79 / video 28 / cover 1） —— 解决「媒体批量化」；作用是把创作变成填模板，边际成本降到近零。
  3. 公开 API / SDK / MCP（PostSider，19 个工具＝13 读 ＋ 6 写） —— 解决「Agent 用不了排期工具」；作用是把发帖能力变成可编排的一等公民接口。
  4. 卡片工坊（文到 AI） —— 解决「一篇文章只能发一个平台」；作用是把内容资产从一篇扩成一组分发素材。
  5. 能力库（文到 AI） —— 解决「稳定步骤每次重做」；作用是把多步骤编排成一次完整交付。
  6. 画像六维 ＋ 长期记忆（Easel） —— 解决「每次生成都从零开始」；作用是输出随账号持续收敛。

5.2 Agent 可调用面

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

这条最值得记的产品决策：两家排期产品把 MCP/API/SDK 放进每一个付费档，没当成加价项。

5.3 内容治理（发布前）

  • Easel：两道闸 —— content_guard.py（敏感信息 fail-closed）＋ persona_gate.py（人设偏离 只提醒不阻断）⇒ 一道硬、一道软。
  • PostSider：read-first / draft-first —— Agent 可准备、排期、送审，发布仍是人的动作；急停恢复仅人可做。
  • 文到 AI：只填充不代发（把最后一步留给人）。
  • Postiz：托管侧走平台官方 OAuth，不抓取不自动化。

6. 产品机制与交互方式（怎么解决 / 为什么这样设计）

  1. 「工作台」与「对话」是同一状态机的两个投影（OpenCreator）。 怎么解决：两侧动作都派发给同一个状态机，步骤/配置/进度/版本/结果回投到两个界面；改稿新建版本不覆盖，并带 sourceArtifactIds 溯源。 为什么这样设计：避免「界面状态」与「对话上下文」两套事实源打架 —— 用户价值是不会出现两个界面各说各话。
  2. 技能三层加载（Metadata 常驻 / Instructions 触发 / Resources 按需）＋ SKILL.md ≤200 行（Easel）。 怎么解决：技能再多，只有元数据常驻上下文。 为什么这样设计：直接回答「技能一多 prompt 就爆」；用户价值是能力可以持续变多而不拖垮响应。
  3. 发布前「分级闸门」（Easel）：不可逆的硬拦、可商量的软劝。 为什么这样设计：把「API key / 内部路径」与「AI 措辞 / 模型名」分开 —— 后者在 AI 科普里是正常内容。 用户价值：既挡住真事故，又不把正常内容误杀。
  4. 不重写 Agent 引擎，只透传 Codex（OpenCreator）。 为什么这样设计：把工期省在应用层。用户价值：跟上模型能力升级。 代价：上游一次破坏性变更就可能整体不可用（§附 B 风险）。
  5. 本地优先 ＋ 免密钥 provider 作一等公民（OpenCreator / 文到 AI / Easel 共同）。 怎么解决：codex-native（复用已登录订阅）、edge-tts（零密钥）与付费 provider 平级，图像 provider 默认值就是免密钥那条。 为什么这样设计：用户不必先配 Key 才能开始用。
  6. 画像目录即记忆作用域（Easel）。 怎么解决：全局 MEMORY.md 不承载账号知识，并行会话各读绑定画像。 为什么这样设计：从设计上消除并发写覆盖。

7. 优势与不足（能力表现 × 场景 × 对比对象 × 用户价值）

竞品 优势（相对谁 / 什么场景 / 什么结果） 不足（相对谁 / 什么场景 / 什么结果）
Easel 相对另 4 家，唯一覆盖「发现→归因」全闭环；在「要让内容越做越贴账号」的场景下，归因回写画像 ⇒ 输出持续收敛 相对 Postiz，发布环节用浏览器自动化，在「账号安全优先」的场景下 ⇒ 有风控/限流/封号风险（README 自陈）；安装门槛高（Node 版本窗口窄 ＋ FFmpeg/Chromium）
OpenCreator 相对另 4 家，媒体生成能力最强；在「批量做多语言视频」的场景下，108 模板 ＋ 10 工具 ⇒ 边际成本近零；工程化最重（2182 blob） 相对自建引擎者，上游强耦合：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. 可借鉴点与产品机会

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

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

  1. 技能/工具契约独立成包 ＋ protocolVersion 常量（OpenCreator）—— 三端同源最低成本一步。
  2. 状态机 ＋ 版本号 ＋ 幂等键三件套（OpenCreator）—— expectedRevision ＋ idempotencyKey ＋ CommandReceipt；并为「远端到底收没收」专设 unknown_remote_acceptance / abandoned_unknown 两态。
  3. 工具契约独立成断言目标（PostSider）—— tool-inventory.ts 把「Agent 能看到哪些工具」写死成独立清单 ⇒ 静默增删改名直接测试报红。
  4. 每个工具显式声明四个风险注解（PostSider）—— readOnlyHint / destructiveHint / idempotentHint / openWorldHint。
  5. 换牌 / 二开闸门（PostSider）—— .rebrand-allowlist ＋ rebrand-check.mjs（CI exit 1）。
  6. 迁移/回滚「演练先行 ＋ 不变量 SQL ＋ 幂等复验」（OpenCreator）—— 只建临时库、9 条验证、第二次 ensureBindings() 必须 repaired=0。
  7. 性能门禁写进 CI 且带硬阈值（OpenCreator）—— 请求数/DOM 峰值/Long Task/gzip 预算。
  8. 「技能文档 ↔ 脚本参数」机器校验（Easel）—— validate_skills.py 防文档漂移。
  9. 独立更新清单（文到 AI）—— stable.json：channel/publishedAt/supportedPlatforms/逐包 sha256/policy.{minimumSupportedVersion, allowSkip, remindAfterHours}。
  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）。
  9. 技能市场合规面：每条带七项风险声明 ＋ 给 Agent 的指令 ＋ 给人的步骤 ＋ 商业许可审查位（OpenCreator）。
  10. AGENTS.md 的分级验证铁律（OpenCreator）—— 同时治「动不动跑全量测试」与「用没跑的验证暗示无回归」。

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

  • 浏览器自动化发平台（Easel）—— 平台风控是真实风险。
  • README 与发行状态脱钩（文到 AI）—— 对外文档必须有「最后校准时间」。
  • 命名双轨：产品改名、内嵌件仍用旧名（OpenCreator）—— 二开前须先定跟新名还是旧名。
  • 上游强耦合的「薄壳」路线（OpenCreator）—— 省工期的对价是单点风险。
  • 素材授权未核实就用（OpenCreator 自述案例）—— 来源未复测的一律设 draft。

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

  1. 发现热点这一段普遍弱（追溯 §5.1 ①）：三家「有」但不深，两家不管 ⇒ 机会在把「找题」做成真正的入口。
  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 许可混用：主体 Apache-2.0 但内联 gzh-design=AGPL-3.0 ⚠️ 中 文件树 ＋ CHANGELOG
Easel 依赖重、安装门槛高（Node 版本窗口窄） ⚠️ 中 README
文到 AI 无 LICENSE：文案/截图/品牌素材均不可复制 🔴 高 NOTICE.md 逐字
文到 AI 「免费」边界未核实（changelog 出现「商用绿色版」） ⚠️ 中 wen_gitcode_releases.rendered.md
文到 AI 闭源 ＋ 静默更新（allowSkip: true） ⚠️ 中 stable.json
OpenCreator 上游强耦合：CLI 一次破坏性变更即可能整体不可用 🔴 高 设计文档多处承认版本敏感
OpenCreator 素材/商标再分发许可未在仓内单独声明 ⚠️ 中 只一份 Apache-2.0 LICENSE
Postiz / PostSider AGPL-3.0 网络服务义务 ＋ 上游署名义务 🔴 高（若对外） ATTRIBUTION.md 逐字
PostSider 单点风险：单人、10★、发布停 v1.2.0 🔴 高 官网自述 ＋ 元数据
全组 平台合规路线二选一，不可混：Easel＝浏览器自动化；Postiz＝官方 OAuth；文到 AI＝只填充不代发 🔴 高（设计红线） 第 2 棒 §八·4、第 3 棒 §十三·1

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

  1. Easel 技能数 113 vs 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 的树（第 4 棒已用 12 份分片补全）。
  3. PostSider 连接器 33 vs 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 ↔ PostSider 的 fork 点（GitHub 未标记 fork、无 parent 指针）与改动行数（tree API 只给 blob sha，行级 diff 需 clone 两侧）。
  • PostSider「33 个活跃连接器」口径未逐条核对；是否有托管（云）服务查不到。
  • 各项目用户量 / 下载量 / 营收：Postiz 自述 7M downloads（无口径），其余查不到（Easel / OpenCreator 主页未访问）。
  • Easel 4 条待核：CI 称 38 条技能自带测试 vs 实测 6 个测试文件；114 技能 layer 源码级分布未做；SKILL-SPEC 的 test1.* 约定整树零文件；.env.example 的 xhs-maas/agnes provider 来源未核实。技能可用率无实测。
  • OpenCreator 8 条待核：商业与规模证据全缺；技能市场「上架态」口径未核实；docs/plans/ 10 份计划落地率未核；火柴人/头像/音频再分发许可未核；真实运行证据为零；runtime/krillinai（Go 183 文件）只做结构级取证；语言构成是按文件数口径（与官方字节口径不可混）；docs/development/ 等正文未逐份读。
  • 文到 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-竞品分析-跨项目汇总对比__旧口径-20261007.md

本份为 1b 竞品分析（2026-10-07 按新方法论重排并收口为白名单唯一一份）。单项目明细见 ../证据附卷/；原始证据见 取证/；旧口径原件见 ../归档-1b旧口径/。

Reference in new issue View Git Blame Copy Permalink