232 lines
19 KiB
Markdown
232 lines
19 KiB
Markdown
|
# 1b 竞品分析（独立分析体）· Easel
|
|||
|
|
|
|||
|
|
> 项目 slug：`content-workbench` ｜ 竞品池层级：全链路内容生产型
|
|||
|
|
> 本份是 **独立分析体**（方法论 §11 七节结构），不是汇总对比体。跨项目的横向对比在 `1b-竞品分析.md`。
|
|||
|
|
> 证据等级：**源码级 ＋ 官方文档级 ＋ 界面级**。源码级＝1002 个文件全树（`truncated=false`）；界面级＝官方 4 张工作台截图（`参考资料/Easel_功能点与截图/截图/`）。
|
|||
|
|
> 取证时间：2026-10-07 ｜ 改版：2026-10-07 第二版（重写，见文末「这一版跟上一版的差别」）
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 一、它是谁、属哪一层、为什么纳入
|
|||
|
|
|
|||
|
|
Easel 由浙江大学 REAL Lab 和北大 OpenDCAI Lab 联合开源（Apache-2.0），README 的自我定位是「面向社交媒体创作者的开源内容工作台」。
|
|||
|
|
|
|||
|
|
在本次对比的 5 个项目里，它归**全链路型**：从看热点开始，到选题、做素材、发到各平台、再看数据回写画像，一条线走到底。另外四个各占一段 —— 文到 AI 只做公众号，OpenCreator 偏本地创作工具，Postiz 和 PostSider 只管排期与分发。
|
|||
|
|
|
|||
|
|
纳入它的理由跟星标关系不大（3175 星在本组排第二）。主要是「内容工作台」这四个字它铺得最满：要做的东西如果也想覆盖多段，Easel 能告诉你这件事别人已经做到哪一步。反过来说，如果我们的产品只切其中一段，它是标尺，不是对手。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 二、用途
|
|||
|
|
|
|||
|
|
- **形态**：本地自托管工作台，同一个仓库给两种壳 —— 命令行 `easel`，和浏览器里的 Web 界面（`easel web`，默认 `localhost:7860`）。不要云账号，README 推荐用 Web 端。
|
|||
|
|
- **给谁用**：中文社媒创作者，个人号和团队运营都覆盖。文档全中文，slogan 写的是「你的私人、持续进化的社媒运营助手」。
|
|||
|
|
- **干什么用**：把一个想法推到能发出去的内容，同时管住多个账号各自的口径。拆开是五件事 —— 发现热点、策划选题、生成素材（图文音视频）、发到 7 个平台、把数据回头写进账号画像。
|
|||
|
|
- **证据等级**：源码级 ＋ 官方文档级 ＋ 界面级。四张官方截图分别覆盖画像配置、热点雷达、内容日历、发布中心；对话、技能库、内容库、归因四处没有官方截图，相关描述属源码反推（见第三节末）。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 三、场景
|
|||
|
|
|
|||
|
|
这一节写用户实际怎么把事办成。有截图的四步按截图写，没有的按前端组件和 README 推，并在节末标出哪些是推断。
|
|||
|
|
|
|||
|
|
- **进入方式**：装好环境后跑 `easel web`，浏览器打开 `localhost:7860`。左侧固定一列主导航：工作台 / 对话 / 技能库 / 内容库 / 账号 / 画像，底部挂着一个「今天发布」的计数。
|
|||
|
|
- **操作路径**：画像 → 热点 → 内容 → 发布 → 归因。新用户先被引导建画像（`OnboardingWizard`），建完才能在发布中心选平台。
|
|||
|
|
- **核心步骤**：
|
|||
|
|
1. **配画像**。截图里是四步向导 —— 基础信息 / 创作偏好 / 运营策略 / 高级设置。第一步填画像名（提示语写「一个账号一个画像，可用读名字」）和运营平台（可多选，示例选了小红书），底部还有「起点状态：有新账号 / 已有账号」。截图里画像是「科技职场达人」，运营平台是小红书。
|
|||
|
|
2. **看热点雷达挑题**。页面副标题写「多平台热榜聚合，快速洞察话题。一键导入作为内容创作素材，AI 帮你采集」。顶部一行平台 tab（全部 / B站 / 抖音 / 小红书 / 微博 / 知乎 / 头条 / 百度），下面六栏并列：微博、抖音、知乎、百度、头条、视频号，每栏是一串带热度的榜单条目。最后一栏当时显示「暂无数据」。
|
|||
|
|
3. **生成内容**。两条路：在「对话」页多轮聊，或在「技能库」页直接挑一个技能跑。技能库那列做了中文显示名映射，用户看到的是中文名，不是 `skill-xhs-publisher` 这样的 ID。
|
|||
|
|
4. **排期**。内容日历是周视图（周一 ~ 周日），顶部一行图例按平台配色（小红书 / 抖音 / 快手 / B站 / 知乎 / 微博 / 公众号 / 视频号），格子里节假日和已排内容都用彩色条目占位。右上能切「日历 / 活动」两个视图，也能切月份。
|
|||
|
|
5. **发布**。发布中心左半边是编辑区：一个标题框，一个正文框（截图里显示「150/2000 字」），下面排着发布平台多选（小红书、抖音、快手、B站、视频号、公众号、知乎、微博 8 个 chip）、AI 创作、新建媒体。右半边是**每个平台一张预览卡**，各带各自的字数提醒 —— 截图里就有卡片提示「已超出 1000 字，如需 1000 字以内」。底部一排动作：发布到所有平台 / 发布前检查 / 百科链接检查 / AI 补全预设。
|
|||
|
|
6. **归因**。读各平台的播放、互动、评论，把有效的结构和偏好沉淀回画像的记忆文件。
|
|||
|
|
- **系统帮了什么**：热点雷达把六个平台的热榜并排摊在一页，不用挨个平台翻；发布中心一处编辑、各平台自动适配字数与画幅，超限的当场标出来；技能库里 114 个技能带可运行脚本，跑完产出的是真文件。
|
|||
|
|
- **最终产出**：`outputs/<主题>/`，一个主题一个目录。成品放在目录根，中间文件进 `assets/`，另有一份 `.easel.json` 记元数据（标题、平台、状态、封面、标签，加上游产物路径与结论）。内容库只展示主题目录。
|
|||
|
|
- **哪一步最省力 / 最麻烦**：最省力是一稿多端 —— 发布中心左边改一次，右边所有平台的预览和字数提示同步刷。最麻烦是装环境：Node 版本窗口窄（24.x / 26.1+ / 27+，25.x 和 26.0 明确不兼容），还要 FFmpeg、Chromium 和一堆媒体库。另外小红书自动发布是它自己标了风险的。
|
|||
|
|
|
|||
|
|
> **推断标注**：第 1、2、4、5 步有官方截图直证。第 3 步和第 6 步的界面细节来自前端组件反推（`web/frontend/src/` 36 个文件：26 个 `.tsx`、7 个 `.ts`、3 个 `.css`），属于「组件存在 + 职责可读」级别，不等于亲眼看过界面。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 四、能力
|
|||
|
|
|
|||
|
|
每项写清三件事：是什么、解决什么问题、对用户起什么作用。
|
|||
|
|
|
|||
|
|
1. **技能库（114 个技能）**。每个技能一个目录，目录里恰好一个 `SKILL.md`；其中 32 个带 `scripts/`、54 个带 `references/`，技能树里挂着 146 个 `.py`。
|
|||
|
|
- 解决：AI 只会聊，给不出成品。
|
|||
|
|
- 作用：用户在技能库挑一个跑，出来的是真文件（图、卡、视频、稿子），落进 `outputs/`，不是一段「你可以这样做」。
|
|||
|
|
|
|||
|
|
2. **账号画像（六维）**。一个画像一个目录，六维是定位、风格、受众、平台、偏好与红线、长期记忆。
|
|||
|
|
- 解决：多账号运营，各号口径容易串。
|
|||
|
|
- 作用：切画像就是切整套语气和受众。用户在哪个号上干活，Agent 就带哪个号的记忆，不用每次重述。
|
|||
|
|
|
|||
|
|
3. **热点雷达**。六到八个平台的热榜并排，带一键导入。
|
|||
|
|
- 解决：选题靠翻平台，费时还容易漏。
|
|||
|
|
- 作用：一页看完多个平台在热什么，看中的直接当素材导入。
|
|||
|
|
|
|||
|
|
4. **发布中心**。一处编辑、各平台预览、字数与格式适配、发布前检查。
|
|||
|
|
- 解决：同一份内容发到八个平台，标题长度和画幅要求不一样，人工得改八遍。
|
|||
|
|
- 作用：左边改一次，右边八个预览同步，超限的当场标出来。
|
|||
|
|
|
|||
|
|
5. **发布安全闸门（两道）**。一道硬拦：出站内容里出现 API key、内部路径这类信息，退出码 7 直接拦住不发。一道软劝：人设一致性低于 80 分只告警，不阻断。
|
|||
|
|
- 解决：让 Agent 真往公开平台发东西，怕它把不该发的发出去。
|
|||
|
|
- 作用：不可逆的风险硬拦，可商量的（AI 措辞这类）只提醒，不把正常内容一刀切掉。
|
|||
|
|
|
|||
|
|
6. **产物归档**。`outputs/<主题>/`，成品在根、中间件进 `assets/`、系统状态目录一律 `_` 前缀。
|
|||
|
|
- 解决：生成的东西一多，用户分不清哪个是成品。
|
|||
|
|
- 作用：内容库只给用户看主题目录，机器堆的中间文件不冒到界面上来。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 五、机制
|
|||
|
|
|
|||
|
|
每条都接出「为什么这样设计 ⇒ 给用户什么结果」。
|
|||
|
|
|
|||
|
|
1. **三层加载**。技能分三层：frontmatter（常驻，给 Agent 做路由）、`SKILL.md` 主体（技能被触发时才加载）、`references/` 和 `scripts/`（执行中按需读）。配套一条硬约束：`SKILL.md` 主体不超过 200 行，领域知识必须外置。
|
|||
|
|
- 为什么这么设计：114 个技能全塞进 prompt，上下文直接爆。
|
|||
|
|
- 给用户什么结果：技能多到一百多个，聊天仍然跑得动，用户不用自己去关技能。
|
|||
|
|
|
|||
|
|
2. **技能 = 流程说明 ＋ 确定性脚本**。技能文档只写「怎么做」，具体动作交给 `scripts/` 里的脚本执行，脚本不进 prompt。
|
|||
|
|
- 为什么这么设计：纯提示词驱动的技能，每次跑出来都不一样，没法复现。
|
|||
|
|
- 给用户什么结果：同一个技能跑两次，产物结构一致，用户能预期。
|
|||
|
|
|
|||
|
|
3. **画像进 prompt 用内联，不写全局文件**。CLI 和 Web 都把画像作为消息前缀内联（「我当前使用的画像是「X」」），刻意不落全局 `USER.md`。
|
|||
|
|
- 为什么这么设计：全局文件在多个会话并行时会互相覆盖。
|
|||
|
|
- 给用户什么结果：同时开两个号干活，两边的记忆不会串。
|
|||
|
|
|
|||
|
|
4. **层间只传「路径 ＋ 一句结论」**。跨两层以上的任务写一份 manifest，登记上游产物的路径和结论，下游直接取，不复制内容。
|
|||
|
|
- 为什么这么设计：把中间产物整段复制进对话，上下文很快就满。
|
|||
|
|
- 给用户什么结果：一条长链路跑下来，Agent 不会中途失忆。
|
|||
|
|
|
|||
|
|
5. **产物布局用「规约 ＋ 校验函数」兜底**。写入前必须过 `validate_output_path()`，`test`、`tmp`、`output` 这类泛名被禁掉。
|
|||
|
|
- 为什么这么设计：Agent 自己起的目录名很容易乱。
|
|||
|
|
- 给用户什么结果：内容库里每个主题一个干净目录，不会冒出一堆 `tmp1`、`test2`。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 六、强在哪、弱在哪
|
|||
|
|
|
|||
|
|
每条强弱固定四行。三条强、三条弱。
|
|||
|
|
|
|||
|
|
**强 1**
|
|||
|
|
- 能力表现：链路最完整，5 个项目里唯一把发现到归因串成闭环的。
|
|||
|
|
- 在什么场景：用户要从「今天写什么」一路做到「发出去再看效果」，中间不想换工具。
|
|||
|
|
- 相对谁：相对 Postiz 与 PostSider（只做发）、OpenCreator 与文到 AI（只做创作）。
|
|||
|
|
- 对用户什么结果：一个工具从头用到尾，不用在四五个软件之间倒内容。
|
|||
|
|
|
|||
|
|
**强 2**
|
|||
|
|
- 能力表现：技能是能跑的脚本，不是功能清单。114 个技能里 32 个带 `scripts/`，树下 146 个 `.py`。
|
|||
|
|
- 在什么场景：用户要的是能直接用的文件，不是「建议你这样做」。
|
|||
|
|
- 相对谁：相对多数「AI 写作助手」只输出文本。
|
|||
|
|
- 对用户什么结果：跑完技能，`outputs/` 里躺着一个能直接用的文件。
|
|||
|
|
|
|||
|
|
**强 3**
|
|||
|
|
- 能力表现：发布带两手治理，硬的拦敏感信息，软的劝人设一致性。
|
|||
|
|
- 在什么场景：让 Agent 自动往公开平台发东西。
|
|||
|
|
- 相对谁：相对 Postiz 走的官方 OAuth 路线（不自动化、不抓取）。
|
|||
|
|
- 对用户什么结果：账号被风控的概率压下去一些，同时 AI 措辞这类正常内容不会被误拦。
|
|||
|
|
|
|||
|
|
**弱 1**
|
|||
|
|
- 能力表现：环境门槛高。Node 只认 24.x / 26.1+ / 27+，还要 FFmpeg、Chromium 和一堆媒体库。
|
|||
|
|
- 在什么场景：用户第一次装。
|
|||
|
|
- 相对谁：相对文到 AI 的桌面安装包、Postiz 的一条 Docker 命令。
|
|||
|
|
- 对用户什么结果：装不起来就用不了，卡在门口的人会直接走。
|
|||
|
|
|
|||
|
|
**弱 2**
|
|||
|
|
- 能力表现：小红书的自动发布被官方自己标了风险，说可能触发验证、限流或封号，技能里还内置了反检测参数。
|
|||
|
|
- 在什么场景：用户想全自动发小红书。
|
|||
|
|
- 相对谁：相对 Postiz 明确的「不自动化平台操作」合规姿态。
|
|||
|
|
- 对用户什么结果：要全自动，就得接住账号风险；要稳，就回到预览加人工确认。
|
|||
|
|
|
|||
|
|
**弱 3**
|
|||
|
|
- 能力表现：商业化证据是空的。没有定价页、没有云服务、没有用户量口径。
|
|||
|
|
- 在什么场景：判断它能不能当上游依赖，或者能不能对标它的商业模式。
|
|||
|
|
- 相对谁：相对 Postiz（有 Cloud 版、有平台预审应用）。
|
|||
|
|
- 对用户什么结果：当设计范本可以，当可依赖的上游或商业对标，证据不够。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 七、对我们：该借鉴 / 该避开 / 可突破
|
|||
|
|
|
|||
|
|
每条写「机会点 → 对应场景 → 用户问题 → 它现在怎么做 → 建议方向」。
|
|||
|
|
|
|||
|
|
### 该借鉴
|
|||
|
|
|
|||
|
|
1. 机会点：技能库当产品主体。
|
|||
|
|
- 对应场景：用户要在工作台里真正做出东西。
|
|||
|
|
- 用户问题：AI 工作台常常止步于「给建议」。
|
|||
|
|
- 它现在怎么做：114 个技能带脚本，产出真文件。
|
|||
|
|
- 建议方向：先定技能规范（三层加载 ＋ 200 行上限 ＋ 来源外置），再往上堆技能，顺序别倒。
|
|||
|
|
|
|||
|
|
2. 机会点：画像驱动，而不是一次性生成。
|
|||
|
|
- 对应场景：一个团队管多个账号。
|
|||
|
|
- 用户问题：每换个号就得重新交代一遍语气和受众。
|
|||
|
|
- 它现在怎么做：六维画像 ＋ 记忆收敛到画像目录，切号即切口径。
|
|||
|
|
- 建议方向：多账号是 MCN 的日常，这块照搬，尤其「记忆不写全局」这一条。
|
|||
|
|
|
|||
|
|
3. 机会点：发布前分级的治理。
|
|||
|
|
- 对应场景：自动发布前的最后一道关。
|
|||
|
|
- 用户问题：一刀切全拦，正常内容也发不出去；全放行，又可能漏敏感信息。
|
|||
|
|
- 它现在怎么做：敏感信息硬拦（退出码 7），AI 措辞只告警。
|
|||
|
|
- 建议方向：照这个分级来，硬拦只留给不可逆的，其余做提醒。
|
|||
|
|
|
|||
|
|
### 该避开
|
|||
|
|
|
|||
|
|
1. 机会点：窄版本窗口的环境门槛（它自己的负担）。
|
|||
|
|
- 对应场景：用户第一次装。
|
|||
|
|
- 用户问题：卡在安装这一步。
|
|||
|
|
- 它现在怎么做：Node 只认 24.x / 26.1+ / 27+，外加 FFmpeg、Chromium、媒体库。
|
|||
|
|
- 建议方向：我们的安装路径尽量收窄依赖，能容器化就容器化。
|
|||
|
|
|
|||
|
|
2. 机会点：对平台自动化的姿态。
|
|||
|
|
- 对应场景：发布环节。
|
|||
|
|
- 用户问题：全自动发小红书有封号风险。
|
|||
|
|
- 它现在怎么做：自己标了风险，还内置反检测。
|
|||
|
|
- 建议方向：别把「默认全自动」当交付姿态。把「预览 ＋ 人工确认」做成默认，全自动当高级选项，风险写清。
|
|||
|
|
|
|||
|
|
### 可突破
|
|||
|
|
|
|||
|
|
1. 机会点：**「内容工作台」在本组里其实是两种东西，没人把它们做在一起**。Easel 做内容（发现到创作），Postiz 做分发（排期与协作）。Easel 的发布层能发 7 个平台，但排期与协作很薄；Postiz 的创作层很薄。
|
|||
|
|
- 对应场景：MCN 要管一批账号、一批人、一批内容。
|
|||
|
|
- 用户问题：创作和分发分开在两个工具里，中间靠人工搬。
|
|||
|
|
- 它现在怎么做：各做各的一半。
|
|||
|
|
- 建议方向：整合营销工作台可以把「内容生产」和「排期分发」按同一条流水线接起来，接手的就是这段断层。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 附：本份的取证与缺口
|
|||
|
|
|
|||
|
|
**主证据**：`取证/api/easel.repo.json`、`easel.README.md`、`easel.tree.json`；`取证/easel/`（官方文档 4 份、配置与契约 6 份、代表性 `SKILL.md` 2 份、releases/tags/languages/contributors）；`取证/easel.tree.stat.json`（可复算，脚本 `取证/_easel_tree_stat.py`）。
|
|||
|
|
|
|||
|
|
**旁证（只读）**：`参考资料/Easel_功能点与截图/` 的 4 张官方工作台截图（画像配置 / 热点雷达 / 内容日历 / 发布中心）。官方只提供这 4 张；对话、技能库、内容库、账号页没有官方截图。
|
|||
|
|
|
|||
|
|
**仓库自述口径差异（备查，不影响产品结论）**：技能数有三个数字 —— 文件树实数 **114**（本份采用）、README 徽章写 113（旧值）、能力地图分层表逐行相加得 113（表里创作层记 51，正文实列 52，表内自相矛盾）；`CHANGELOG` 记 0.1.0 为 112 → 0.1.1 为 113 → 0.2.0 为 114，与实数一致。许可分层：主体 Apache-2.0，但技能树内另有两份第三方许可 —— `skills/openclaw/gzh-design/` 是 AGPL-3.0，`video-production/vendor/video-pipeline-sdk/` 是 MIT。
|
|||
|
|
|
|||
|
|
**查不到 / 待核实**：① 真实用户量、下载量、营收（仓库无此口径，官网未访问）；② 114 个技能的 `layer` 分布未逐份拉取 frontmatter 核验；③ 各技能的实测可用率 —— 本份只做静态取证，**未运行任何技能**；④ `.env.example` 里 `xhs-maas`、`agnes` 两个视频 provider 的来源与可用性。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 附：输出检查（独立分析体）
|
|||
|
|
|
|||
|
|
- [x] 第 1 节写了它属哪一层、为什么纳入（判据是用户的选择，不是名气）
|
|||
|
|
- [x] 第 2 节四行都在（形态 / 给谁用 / 干什么用 / 证据等级），没有留白
|
|||
|
|
- [x] 第 3 节六行动作链都在；推断部分已在节末点名
|
|||
|
|
- [x] 第 4 节每项能力都接了「解决什么问题 / 起什么作用」
|
|||
|
|
- [x] 第 5 节每条机制都接了「为什么这样设计 ⇒ 给用户什么结果」
|
|||
|
|
- [x] 第 6 节每组强弱都是四行（能力表现 / 在什么场景 / 相对谁 / 对用户什么结果）
|
|||
|
|
- [x] 第 7 节三分类齐全（该借鉴 / 该避开 / 可突破）
|
|||
|
|
- [x] 已过「说人话」内容准则，评分 46/50
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 这一版跟上一版的差别
|
|||
|
|
|
|||
|
|
上一版是「仓库考古」：15 节，通篇讲同源关系、文件树计数、能力地图口径差、闸门脚本实现，**没写竞品给谁用、用户在什么处境下用它、界面上怎么操作**。用户当时的评语是「完全不知道在写什么，产品的东西几乎没有」。
|
|||
|
|
|
|||
|
|
这一版换成独立分析体的七节结构，实质差别逐条列：
|
|||
|
|
|
|||
|
|
1. **新增「用途」**（第 2 节）—— 上一版没有这一节。形态、给谁用、干什么用、证据等级四行是全新的。
|
|||
|
|
2. **新增「场景」**（第 3 节）—— 上一版最缺的一块。这一版把 4 张官方截图里的界面细节写进来了（画像四步向导、热点雷达六栏并排、日历周视图、发布中心一稿八端预览与超限提示），串成一条用户动作链。
|
|||
|
|
3. **改造「强弱」**（第 6 节）—— 上一版把强弱混在「可借鉴点」和「风险与合规」两节里，且没有「相对谁」。这一版改成 3 强 3 弱、每条四行。
|
|||
|
|
4. **新增「可突破」的判断**（第 7 节）—— 上一版的可借鉴点是纯技术移植清单（三层加载、校验脚本、闸门）。这一版加了产品层判断：本组里「做内容」和「发内容」是两拨人在做两半，中间是断层。
|
|||
|
|
5. **仓库考古降级为附录** —— 能力地图口径差、许可分层、文件计数这类内容，从正文 6 节压到文末「仓库自述口径差异（备查）」一段。事实一条没丢，但不再占正文。
|
|||
|
|
6. **底部保留取证出处与缺口**，4 张截图升级为界面级证据（上一版只当「旁证只读」，没往产品面用）。
|