0 Fork 0

Files

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

19 KiB

Raw Permalink Blame History

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），属于「组件存在 + 职责可读」级别，不等于亲眼看过界面。

四、能力

每项写清三件事：是什么、解决什么问题、对用户起什么作用。

技能库（114 个技能）。每个技能一个目录，目录里恰好一个 SKILL.md；其中 32 个带 scripts/、54 个带 references/，技能树里挂着 146 个 .py。
- 解决：AI 只会聊，给不出成品。
- 作用：用户在技能库挑一个跑，出来的是真文件（图、卡、视频、稿子），落进 outputs/，不是一段「你可以这样做」。
账号画像（六维）。一个画像一个目录，六维是定位、风格、受众、平台、偏好与红线、长期记忆。
- 解决：多账号运营，各号口径容易串。
- 作用：切画像就是切整套语气和受众。用户在哪个号上干活，Agent 就带哪个号的记忆，不用每次重述。
热点雷达。六到八个平台的热榜并排，带一键导入。
- 解决：选题靠翻平台，费时还容易漏。
- 作用：一页看完多个平台在热什么，看中的直接当素材导入。
发布中心。一处编辑、各平台预览、字数与格式适配、发布前检查。
- 解决：同一份内容发到八个平台，标题长度和画幅要求不一样，人工得改八遍。
- 作用：左边改一次，右边八个预览同步，超限的当场标出来。
发布安全闸门（两道）。一道硬拦：出站内容里出现 API key、内部路径这类信息，退出码 7 直接拦住不发。一道软劝：人设一致性低于 80 分只告警，不阻断。
- 解决：让 Agent 真往公开平台发东西，怕它把不该发的发出去。
- 作用：不可逆的风险硬拦，可商量的（AI 措辞这类）只提醒，不把正常内容一刀切掉。
产物归档。outputs/<主题>/，成品在根、中间件进 assets/、系统状态目录一律 _ 前缀。
- 解决：生成的东西一多，用户分不清哪个是成品。
- 作用：内容库只给用户看主题目录，机器堆的中间文件不冒到界面上来。

五、机制

每条都接出「为什么这样设计 ⇒ 给用户什么结果」。

三层加载。技能分三层：frontmatter（常驻，给 Agent 做路由）、SKILL.md 主体（技能被触发时才加载）、references/ 和 scripts/（执行中按需读）。配套一条硬约束：SKILL.md 主体不超过 200 行，领域知识必须外置。
- 为什么这么设计：114 个技能全塞进 prompt，上下文直接爆。
- 给用户什么结果：技能多到一百多个，聊天仍然跑得动，用户不用自己去关技能。
技能 = 流程说明＋确定性脚本。技能文档只写「怎么做」，具体动作交给 scripts/ 里的脚本执行，脚本不进 prompt。
- 为什么这么设计：纯提示词驱动的技能，每次跑出来都不一样，没法复现。
- 给用户什么结果：同一个技能跑两次，产物结构一致，用户能预期。
画像进 prompt 用内联，不写全局文件。CLI 和 Web 都把画像作为消息前缀内联（「我当前使用的画像是「X」」），刻意不落全局 USER.md。
- 为什么这么设计：全局文件在多个会话并行时会互相覆盖。
- 给用户什么结果：同时开两个号干活，两边的记忆不会串。
层间只传「路径＋一句结论」。跨两层以上的任务写一份 manifest，登记上游产物的路径和结论，下游直接取，不复制内容。
- 为什么这么设计：把中间产物整段复制进对话，上下文很快就满。
- 给用户什么结果：一条长链路跑下来，Agent 不会中途失忆。
产物布局用「规约＋校验函数」兜底。写入前必须过 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 版、有平台预审应用）。
对用户什么结果：当设计范本可以，当可依赖的上游或商业对标，证据不够。

七、对我们：该借鉴 / 该避开 / 可突破

每条写「机会点 → 对应场景 → 用户问题 → 它现在怎么做 → 建议方向」。

该借鉴

机会点：技能库当产品主体。
- 对应场景：用户要在工作台里真正做出东西。
- 用户问题：AI 工作台常常止步于「给建议」。
- 它现在怎么做：114 个技能带脚本，产出真文件。
- 建议方向：先定技能规范（三层加载＋ 200 行上限＋来源外置），再往上堆技能，顺序别倒。
机会点：画像驱动，而不是一次性生成。
- 对应场景：一个团队管多个账号。
- 用户问题：每换个号就得重新交代一遍语气和受众。
- 它现在怎么做：六维画像＋记忆收敛到画像目录，切号即切口径。
- 建议方向：多账号是 MCN 的日常，这块照搬，尤其「记忆不写全局」这一条。
机会点：发布前分级的治理。
- 对应场景：自动发布前的最后一道关。
- 用户问题：一刀切全拦，正常内容也发不出去；全放行，又可能漏敏感信息。
- 它现在怎么做：敏感信息硬拦（退出码 7），AI 措辞只告警。
- 建议方向：照这个分级来，硬拦只留给不可逆的，其余做提醒。

该避开

机会点：窄版本窗口的环境门槛（它自己的负担）。
- 对应场景：用户第一次装。
- 用户问题：卡在安装这一步。
- 它现在怎么做：Node 只认 24.x / 26.1+ / 27+，外加 FFmpeg、Chromium、媒体库。
- 建议方向：我们的安装路径尽量收窄依赖，能容器化就容器化。
机会点：对平台自动化的姿态。
- 对应场景：发布环节。
- 用户问题：全自动发小红书有封号风险。
- 它现在怎么做：自己标了风险，还内置反检测。
- 建议方向：别把「默认全自动」当交付姿态。把「预览＋人工确认」做成默认，全自动当高级选项，风险写清。

可突破

机会点：「内容工作台」在本组里其实是两种东西，没人把它们做在一起。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 的来源与可用性。

附：输出检查（独立分析体）

第 1 节写了它属哪一层、为什么纳入（判据是用户的选择，不是名气）
第 2 节四行都在（形态 / 给谁用 / 干什么用 / 证据等级），没有留白
第 3 节六行动作链都在；推断部分已在节末点名
第 4 节每项能力都接了「解决什么问题 / 起什么作用」
第 5 节每条机制都接了「为什么这样设计 ⇒ 给用户什么结果」
第 6 节每组强弱都是四行（能力表现 / 在什么场景 / 相对谁 / 对用户什么结果）
第 7 节三分类齐全（该借鉴 / 该避开 / 可突破）
已过「说人话」内容准则，评分 46/50

这一版跟上一版的差别

上一版是「仓库考古」：15 节，通篇讲同源关系、文件树计数、能力地图口径差、闸门脚本实现，没写竞品给谁用、用户在什么处境下用它、界面上怎么操作。用户当时的评语是「完全不知道在写什么，产品的东西几乎没有」。

这一版换成独立分析体的七节结构，实质差别逐条列：

新增「用途」（第 2 节）—— 上一版没有这一节。形态、给谁用、干什么用、证据等级四行是全新的。
新增「场景」（第 3 节）—— 上一版最缺的一块。这一版把 4 张官方截图里的界面细节写进来了（画像四步向导、热点雷达六栏并排、日历周视图、发布中心一稿八端预览与超限提示），串成一条用户动作链。
改造「强弱」（第 6 节）—— 上一版把强弱混在「可借鉴点」和「风险与合规」两节里，且没有「相对谁」。这一版改成 3 强 3 弱、每条四行。
新增「可突破」的判断（第 7 节）—— 上一版的可借鉴点是纯技术移植清单（三层加载、校验脚本、闸门）。这一版加了产品层判断：本组里「做内容」和「发内容」是两拨人在做两半，中间是断层。
仓库考古降级为附录 —— 能力地图口径差、许可分层、文件计数这类内容，从正文 6 节压到文末「仓库自述口径差异（备查）」一段。事实一条没丢，但不再占正文。
底部保留取证出处与缺口，4 张截图升级为界面级证据（上一版只当「旁证只读」，没往产品面用）。

19 KiB Raw Permalink Blame History Unescape Escape