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

28 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。 单项目明细（独立分析体）在 ../证据附卷/，共 5 份。它是 1b 的另一种既定体例（2026-10-07 用户定案：「竞品分析 有独立分析也有汇总分析 都应该要用上」），不是「只作证据回查」的附件；横向对比只在本份。 改版说明：2026-10-07 先按新版《竞品分析方法论（1b · 产品视角）》重排为汇总对比体（research/1b-竞品分析.md）；同日再按「说人话」内容准则（humanizer / humanizer-zh）过一遍文字。旧口径原件在 ../归档-1b旧口径/，本次改版前的版本在 ../归档-说人话重写前-20261007/。

0. 怎么读这份

五问落在哪：用途看 §3，场景看 §4，功能和作用都在 §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 个链接，所以全部按前两层收录。

为什么是这 5 个：用户要「把内容做出来」时，会在 Easel、OpenCreator、文到 AI 之间比，比的是全链路 / 媒体工厂 / 单平台桌面三条不同做法。用户要「把内容发出去、排期、接 Agent」时，两条路是成熟生态与 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 用浏览器自动化把「发」也纳入闭环，自己在 README 里承认有平台风控风险；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. 技能市场的合规面（OpenCreator）—— 每条带七项风险声明、给 Agent 的指令、给人的步骤、商业许可审查位。
  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 与 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 与 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 四条待核：CI 称 38 条技能自带测试，实际只测到 6 个测试文件；114 技能的 layer 源码级分布没做；SKILL-SPEC 的 test1.* 约定整树零文件；.env.example 里 xhs-maas / agnes provider 的来源未核实。技能可用率没有实测。

OpenCreator 八条待核：商业与规模证据全缺；技能市场「上架态」口径未核实；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旧口径/1b-竞品分析-跨项目汇总对比__旧口径-20261007.md

本份是 1b 竞品分析的汇总对比体（2026-10-07 按新方法论重排，同日过「说人话」内容准则）。独立分析体见 ../证据附卷/（5 份）；原始证据见 取证/；旧口径原件见 ../归档-1b旧口径/；本次改版前版本见 ../归档-说人话重写前-20261007/。

Reference in new issue View Git Blame Copy Permalink