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

30 KiB

Raw Permalink Blame History

1b 竞品分析（独立分析体）· 文到 AI

项目 slug：content-workbench　｜　竞品池层级：直接竞品（做内容）· 单平台纵深型本份是 独立分析体（方法论 §11 七节结构），不是汇总对比体。跨家横向对比在 ../research/1b-竞品分析.md。证据等级：文档级（官方 README、官网页面与脚本、官方更新清单）。仓库不含业务源码 —— 全仓 5 个 blob，GitHub 语言统计返回空对象。本组唯一不能做源码级的一家，结论不与另四家同权。 取证时间：2026-10-07　｜　改版：2026-10-07 第二版（重写，见文末「这一版跟上一版的实质差别」）

一、它是谁、属哪一层、为什么纳入

文到 AI 由 wendaoai（GitHub 组织，2026-09-17 注册，公开仓库只有 1 个）发布。它的 GitHub 仓不是代码仓，是文档仓 —— 全仓 5 个 blob：.gitignore、NOTICE.md、README.md、RELEASE_NOTES_0.0.113.md、一张首页截图。NOTICE.md 逐字写「source code is proprietary and is not distributed through this repository」。9 条提交全是 docs: 前缀，贡献者 1 人。

它属直接竞品（做内容），但只覆盖公众号一条线。用户只做公众号、又在意数据留在自己电脑上时，会拿它比。纳入的理由是**「单平台纵深」这条路能走多深**：同样是「内容工作台」，Easel 铺宽度（7 个平台），它铺深度（一个平台，但一条线走到底，同一份内容做出最多复用形态）。

一条要带着看的事实：这个仓的星标（3）、提交数（9）、贡献者数（1）都不能用来判断产品活跃度。 产品源码从来不在这个仓里，官方更新源显示产品侧 13 天内发了 11 个版本。拿 GitHub 数据读它，必然读错。

二、用途

形态：闭源商业桌面应用。README 自述「基于 Wails 构建，面向 Windows、macOS 和 Linux」。GitHub 上的仓只用来发产品介绍、版本公告和公开资料。
给谁用：公众号创作者、内容运营人员和小型内容团队。README 自陈「它不是只有一个输入框的 AI 写作工具，而是一套真正能把内容做完的桌面工作台」。
干什么用：在桌面端把公众号一条线做完 —— 选题、写稿、排版、配图、卡片、发布准备，再到数据复盘。数据默认留在本机，AI 服务和模型用户自己选。README 明写「不收会员费，不收订阅费，不按功能分级」。
证据等级：文档级。来源是 README、官网页面与脚本、官方更新清单，外加三处硬线索（仓库 topics 含 wails、.gitignore 排除 src/ server/ web/ data/ outputs/、官方 changelog）。技术栈（Wails ＋ Vue ＋本地 SQLite）是有据的推断，不是源码级结论。

三、场景

先说清这一节的边界：本份没有可核验的界面截图，也没有装机（本目标不做安装与运行）。所以下面的六行，凡是界面级的细节一律写「取不到」，官方文字能支持的另标出处。⛔ 不用功能名罗列冒充使用过程。

进入方式：官方自述级 —— 从官网「选择适合你电脑的版本」下载对应系统的安装包（4 个：macOS Apple 芯片 / macOS Intel 芯片 / Windows x64 / Windows ARM64），安装后打开桌面应用。取不到：安装过程与首次启动的实际界面（无可核验截图、未装机）。
操作路径：官方自述级 —— 官网把界面按六段编号：01 发现选题 → 02 开始创作 → 03 完成正文 → 04 生成图片 → 05 制作卡片 → 06 数据复盘；创作首页另有六个并列入口（写文章 / 参考改写 / 看图写作 / 图片生成 / 能力编排 / 任务管理）。取不到：段与段之间怎么跳、有没有向导、失败后返回哪里。
核心步骤：取不到：官网每段只给一句定位（例如 03 段写「在左侧继续和内容助手协作，在右侧阅读和编辑正文」），没有截图、没有源码、没有实机记录，无法核实实际点了几步、控件长什么样、异常怎么提示。
系统帮了什么：取不到：官方自述里能引的只有宣传语（「关键选项集中在输入区」「结果不是终点」「不是每次从零提示」），这类话不足以构成可核验的「系统帮了什么」。
最终产出：官方自述级 —— 文章、配图、多页卡片（小红书图文 / 知识卡片 / 手写卡片 / 封面）、发布准备状态；历史版本与内容资产存在本地项目库。取不到：产物的实际文件形态、落盘位置、能不能导出到别处。
哪一步最省力 / 最麻烦：取不到：官网只讲省力的一侧（「从工作台到公众号，少一次来回复制」「打开软件，第一件事就是开始创作」），没有讲麻烦在哪；也没有第三方实测可引。

缺口汇总（都在上面）：① 六行里没有一行能拿到界面级证据；② 核心步骤、系统帮了什么、哪一步最省力·最麻烦这三行整行取不到，只剩官方自述的只言片语；③ 唯一稍微硬一点的是「进入方式」和「最终产出」，因为官网文字把下载路径和产物类别说清了。

备查（不作为第三节的答项）：官方文字能拼出一条链路顺序 —— 下载安装 → 打开桌面端 → 在选题中心定题 → 选一种创作入口写稿 → 左侧内容助手协作、右侧编辑正文（版本可对比、采用、继续改）→ 进图片工作台生成配图 → 卡片工坊把长文做成多形态素材 → 发布助手插件把标题与正文填进公众号后台、人工确认发布 → 登记已发布内容、采集公众号数据、按月复盘。这条链路的依据是官方流程说明与官方截图说明文字，不是界面截图，也不是实机观察，所以只作备查，不填进上面的固定行。

四、能力

本节只写官方自述的能力，逐项标明来源。每项答三件事：是什么、解决什么问题、对用户起什么作用。

八项核心能力（README「核心能力」表逐字）：灵感与选题、AI 写作与改稿、公众号编辑、图片生成、卡片工坊、营销创作、本地内容库、发布准备。
- 解决：内容创作被拆成七八个工具，一次生产要在它们之间来回搬。
- 作用：同一份内容从想法到能发出去，不用换工具。
三类创作入口（官网盘点）：写文章、参考改写、看图写作。
- 解决：每次创作都要从零想，好结构和好素材没法复用。
- 作用：起点可以是一句话、一篇参考稿，或一张图 —— 不用逼着自己先写出一段提示词。
卡片工坊的多形态产出（官网逐字）：小红书图文、知识卡片、手写卡片、封面。
- 解决：一篇文章只能发一个地方，素材没法二次利用。
- 作用：内容资产从「一篇」扩成「一组」，同一份东西能分发到更多位置。
能力库与创作方案（官网逐字）：官方能力加我的能力加提示词，可以把多个步骤编排成一套「创作方案」。
- 解决：一个稳定好用的步骤组合，下次还得手工重来一遍。
- 作用：把「一次好用」沉淀成「每次都能复用」。
图片工作台带完整上下文（官网逐字）：对话、参考图、素材、提示词和结果都留在同一条任务记录里，结果可以复制、保存提示词、下载或继续当下一轮参考图。
- 解决：上一张图怎么生成的，过两天就找不回来了。
- 作用：好结果能续下去，而不是每次从头试。
系列规划（官网逐字）：给长期栏目保留统一上下文。
- 解决：做专栏做到第三期，风格和设定已经飘了。
- 作用：长期栏目有一条不断线的上下文。
发布数据复盘（官网逐字）：登记已发布内容 → 采集公众号数据 → 按月份复盘并记录行动。
- 解决：下一步做什么还是靠感觉。
- 作用：选题从真实内容表现出发，而不是从印象出发。
发布助手浏览器插件（官网逐字）：把当前文章的标题、正文和封面交给浏览器，辅助填入微信公众号编辑器；支持 Chrome、Edge、Safari、Firefox。
- 解决：从桌面端到公众号后台，要手工复制一遍。
- 作用：省掉这次复制 —— 但只是填充，发布要自己确认（见第五节第 5 条）。

五、机制

本节每条都标明是官方自述还是推断。每条接出「为什么这样设计 ⇒ 给用户什么结果」。

本地优先：数据存本地 SQLite，模型由用户自配（官网逐字「文到AI以桌面应用运行，使用本地 SQLite 保存内容与工作记录」；changelog 写「使用本地 SQLite 保存内容与工作记录」）。
- 为什么这么设计：内容素材和运营数据对创作者是资产，放云上就是把掌控权交出去。
- 给用户什么结果：项目、草稿、素材、任务记录、生成结果默认留本机；只有用户主动调 AI 时才把相关内容发给所选服务商。代价是换机器、多人协作要自己想办法（官网说「数据可以按自己的方式备份和迁移」）。
模型自由：不绑定单一厂商，按文字 / 图片 / 音频三类分别管模型（changelog v0.0.120 写「统一服务商目录」，支持搜索、全选、隐藏与默认模型；体验文字模型调整为阿里云百炼）。
- 为什么这么设计：模型迭代太快，绑一家等于把成本和质量都押上去。
- 给用户什么结果：可以按需换服务商、比价格、比效果。代价是配置这件事落在用户身上，模型费用也由用户和服务商结算。
更新清单与代码仓分离，清单自带完整性与升级策略（官方更新源 updates/stable.json 逐字段：channel: stable、version: 0.0.123、publishedAt、supportedPlatforms 四平台矩阵、逐包 sha256、policy.{minimumSupportedVersion, allowSkip: true, remindAfterHours: 24}）。
- 为什么这么设计：二进制流量不该压在代码仓上；而且更新这件事本身需要能强制、能跳过、能控制提醒节奏。
- 给用户什么结果：官网首屏能自动识别系统架构给出对应包（浏览器隐藏架构时有 fallbackArch 兜底）；每个包带 sha256 可校验；minimumSupportedVersion 能在必要时强制升级。这是这套产品里证据最硬的一块 —— 供给的是机器可复核的 JSON，不是文档自述。
修订不覆盖，版本可对比、可采用、可继续改（官网逐字；README 写「保留内容版本」）。
- 为什么这么设计：写作是一个来回改的过程，覆盖等于把退路删掉。
- 给用户什么结果：任何一版都能翻回去、能比对、能捡回来继续。注意这一条在本组里出现过两次（OpenCreator 也是「改稿新建版本不覆盖」）—— 两次独立观测到同一做法，说明它是这类产品的收敛点。
发布环节最保守：插件只填充，不代发（官网逐字「插件不会自动登录、保存草稿或点击发布；最终内容请在公众号后台检查并手动确认」）。
- 为什么这么设计：公众号发布是不可逆动作，账号风控的代价由用户承担。
- 给用户什么结果：三个做内容的项目里，它的账号风险最低。 代价是每篇都要人工点一次确认 —— 这个代价它选择自己承担而不转给用户。
内容闭环回到选题（README 的 mermaid 把「归档为内容资产」虚线回流到「选题与热点」，标注「下次继续复用」；官网把「采集公众号数据 → 月度复盘 → 记录行动」做成链路第 6 段）。
- 为什么这么设计：发布不是终点。没有回写，下一轮选题还是靠猜。
- 给用户什么结果：用得越久，选题判断的依据越实。

一处推断，单独说明：README 自述基于 Wails，仓库 topics 直接含 wails；changelog v0.0.122 写「恢复 Vue 作为唯一的 Web 与桌面前端」；官网写本地 SQLite；.gitignore 排除 src/ server/ web/ data/ outputs/，说明存在本地后端进程。⇒「Wails（Go）＋ Vue ＋本地 SQLite ＋用户自配模型」是有据的推断。具体语言版本、框架版本、依赖清单、模块划分、数据表结构一概查不到 —— 无 package.json、无 go.mod、无 Wails 版本号，语言统计返回空对象。

六、强在哪、弱在哪

每条四行。四条强、四条弱。

强 1

能力表现：单平台纵深最完整 —— 选题、写稿、改稿、排版、配图、卡片、发布准备、数据复盘压在一个桌面应用里，同一份内容做出最多复用形态。
在什么场景：团队只做公众号，或公众号是主战场。
相对谁：相对 Easel（铺 7 个平台，每段都不深）和 OpenCreator（只做媒体，不做发布）。
对用户什么结果：一个软件从今天写什么管到下个月复盘，不用在四五个工具之间倒内容。

强 2

能力表现：一稿多形态 —— 长文能变成小红书图文、知识卡片、手写卡片和封面。
在什么场景：一篇公众号长文写完之后，还想把它铺到别的分发位置。
相对谁：相对 Easel 的发布中心（一稿多端，改的是同一份内容的平台适配，不是多种形态的素材）。
对用户什么结果：一次生产换来一组分发素材，内容资产的复用次数翻倍。

强 3

能力表现：发布边界最保守 —— 插件只把标题、正文、封面填进公众号编辑器，明确不自动登录、不保存草稿、不点发布。
在什么场景：让工具碰到真实发布动作。
相对谁：相对 Easel 的浏览器自动化发布（README 自己提示小红书可能触发验证、限流、封号），也相对 Postiz 的官方 OAuth 路线。
对用户什么结果：三个做内容的项目里账号风险最低。用户只需要多按一次确认键，换掉了封号风险。

强 4

能力表现：升级与分发的基础设施是机器可复核的 —— 独立更新仓、四平台清单、逐包 sha256、minimumSupportedVersion / allowSkip / remindAfterHours 三个策略字段，官网按系统架构自动选包。
在什么场景：用户第一次下载、以及之后的版本升级。
相对谁：相对本组四家开源项目（都没有独立的更新清单与升级策略声明）。
对用户什么结果：拿到的包能校验，升级节奏可控，不会被无休止的弹窗追着走。

弱 1

能力表现：闭源。全仓 5 个 blob，NOTICE.md 明写「proprietary and is not distributed through this repository」，并声明「No license is granted to copy, modify, redistribute, reverse engineer, or create derivative works」。
在什么场景：用户想自审、想二次开发、或者想验证官方自述。
相对谁：相对 Easel 与 OpenCreator（Apache-2.0，可自由借用）以及 Postiz 与 PostSider（AGPL-3.0，源码可得）。
对用户什么结果：产品里的每一条能力宣称都无法自证。本份分析也只能到文档级 —— 这本身就是这条弱点的直接后果。

弱 2

能力表现：只做微信公众号一条线。README 全文与官网全文里，发布对象只有公众号，topics 也只有 wechat-editor 与 wechat-official-account。
在什么场景：一个矩阵同时运营公众号、视频号、小红书、抖音。
相对谁：相对 Easel（7 个平台）、Postiz 与 PostSider（30 多个平台）。
对用户什么结果：多平台运营要另配工具，产品内的复用止步于「素材」这一层，发布环节还是要人搬。

弱 3

能力表现：文档与发行状态脱钩。README（2026-09-17）写「当前尚未发布公开安装包」，而官方更新源已经是 v0.0.123（2026-09-23 发布），四个平台包都能下，官网首屏早有「下载所选版本」。
在什么场景：外部读者看完 README 判断产品成熟度。
相对谁：相对本组其它四家（README 与仓库状态基本同步）。
对用户什么结果：引 README 的「未发布」会被直接带偏。这不是小事 —— 对外文档没有「最后校准时间」，就会长期说假话。

弱 4

能力表现：生态极薄。GitHub 3 星、0 fork、贡献者 1 人、仓内 9 条 docs: 提交；Gitee 镜像存在但未核同步状态。
在什么场景：遇到问题要找答案、想找第三方扩展。
相对谁：相对 Postiz（36,809 星、Discord 社区、每周迭代）。
对用户什么结果：遇到问题只能找官方。产品本身迭代很快（13 天 11 个版本），但**「迭代快」和「生态厚」是两回事**，别混读。

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

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

该借鉴

机会点：「能力库」把稳定步骤沉淀成可复用方案。
- 对应场景：MCN 的创作有固定套路（选题拆解 → 文案 → 标题 → 封面 → 发布检查）。
- 用户问题：套路每次靠人脑重走一遍，新人上手更慢。
- 它现在怎么做：官方能力加我的能力加提示词，可以编排成一套「创作方案」。
- 建议方向：我们的流水线不该只是一串步骤，要能存成方案。第 1a 需求文档里 S3「不用记 skill 名字，点就行」正是这件事。
机会点：一稿多形态的「卡片工坊」。
- 对应场景：一条母版要变成矩阵下多个平台各自的版本。
- 用户问题：同一份内容在不同平台的表达形态不一样，人工改十遍。
- 它现在怎么做：长文自动转成小红书图文、知识卡片、手写卡片、封面四类。
- 建议方向：这是「母版 → 变体」最直接的一个样本。我们的变体生成要按平台形态出，不只是按字数裁剪。
机会点：修订不覆盖，版本可对比、可采用。
- 对应场景：多人在同一条内容上迭代。
- 用户问题：改错了回不去；两个版本孰优无从比较。
- 它现在怎么做：保留内容版本，官网写「版本可以对比、采用和继续修改」。
- 建议方向：照做。这条在本组被两次独立观测到（OpenCreator 也是新建版本不覆盖），说明它是这类产品的收敛点，不是某一家的偏好。
机会点：发布助手只填充不代发。
- 对应场景：用户要求「发出去别让我动手」。
- 用户问题：全自动很诱人，但风险落在用户账号上。
- 它现在怎么做：插件明确不自动登录、不存草稿、不点发布，把最后一步留给人。
- 建议方向：我们的默认姿态按这条走 —— 预览加人工确认是默认，全自动是高级选项、风险写清。与 §七的「该避开」第 1 条是同一条纪律。
机会点：独立更新清单＋平台矩阵＋ sha256 ＋升级策略。
- 对应场景：我们如果做桌面端或本地分发。
- 用户问题：自造一套「检查更新」接口，很快变成一个说不清的私有协议。
- 它现在怎么做：一份静态 JSON 带着版本、四平台矩阵、逐包哈希和三个升级策略字段，官网只负责读清单加选包。
- 建议方向：这套结构直接可搬，而且天然支持灰度与强制升级。
机会点：内容闭环回到选题。
- 对应场景：内容负责人每天要回答「今天哪个账号发什么」。
- 用户问题：发布完就断线，下一轮选题靠感觉。
- 它现在怎么做：登记已发布内容 → 采集数据 → 月度复盘 → 记录行动。
- 建议方向：这一步对我们不是可选项。矩阵经营最缺的就是「发布结果能反哺选题」。低成本高价值，优先做。

该避开

机会点：别让「免费」变成说不清的承诺。
- 对应场景：产品对外口径。
- 用户问题：官方 changelog 里出现过「商用绿色版」字样，但官网与 README 都没有对应的售卖页或授权说明 —— 免费边界说不清，用户会怀疑。
- 它现在怎么做：README 与官网都写免费（不收会员费、订阅费、不按功能分级），但对「商用绿色版」不置一词。
- 建议方向：我们的收费口径一次说清，别留这种需要用户自己去 changelog 里考古的悬案。
机会点：别让对外文档和实际状态脱钩。
- 对应场景：任何文档与发行分离的发布方式。
- 用户问题：README 停在「尚未发布」，实际已经发到 0.0.123，外部读者被带偏。
- 它现在怎么做：文档仓手工维护，更新源独立。
- 建议方向：对外文档必须有「最后校准时间」，或者直接读可机器刷新的版本清单。这条对我们尤其相关 —— 我们的文档更新也是手工的。
机会点：别把「闭源」当默认（对我们要做的这类工作台而言）。
- 对应场景：MCN 要按客户要求定制、要私有化交付。
- 用户问题：闭源产品改不动，客户提的定制需求只能等官方。
- 它现在怎么做：闭源，且明确禁止反向工程与衍生作品。
- 建议方向：我们如果面向机构客户，代码可得性本身就是一项采购条件。这条决定架构自由度，要提前想。
机会点：别用 GitHub 数据判断一个产品的活跃度。
- 对应场景：竞品调研、技术选型。
- 用户问题：3 星、9 条文档提交，看起来像个停摆项目，实际产品 13 天发了 11 个版本。
- 它现在怎么做：把代码仓和发布渠道彻底分开。
- 建议方向：调研前先问一句「这个仓到底是代码仓还是文档仓」。本目标一开始按「5 个开源项目」排期，实际只有 4 个能做源码级 —— 这就是没先问这一句的代价。

可突破

机会点：它把「单平台」这条路走到了头，但止步于一个平台。
- 对应场景：MCN 的矩阵要同时管公众号、视频号、小红书、抖音。
- 用户问题：单平台纵向做得再好，矩阵运营者还是要在几个工具间搬。
- 它现在怎么做：只做公众号，把一条线做深。
- 建议方向：这不是要我们做第二个文到 AI。可突破的是把它的「深」抽出来复用 —— 卡片工坊那套「一稿多形态」、能力库那套「方案可复用」，做成跨平台的，而不是绑在公众号一条线上。
机会点：它的数据回写只到「月度复盘」这一层。
- 对应场景：内容负责人要按账号、按赛道看矩阵表现。
- 用户问题：月度人工复盘跟不上矩阵的节奏，也回答不了「哪个账号该加量、哪个该换方向」。
- 它现在怎么做：登记已发布内容 → 采集公众号数据 → 按月复盘 → 记录行动，人工参与很重。
- 建议方向：我们做自动化的回写与异常值提示（对标第 1a 需求文档 S1 的「异常值」诉求），让选题判断变成日常可见的，而不是月底才做一次。

附：本份的取证与缺口

主证据（本目标目录内）：取证/api/wendao.{repo.json,README.md,tree.json}（第 1 棒 16:14）；取证/wendao/（第 5 棒 20 件 —— NOTICE.md、RELEASE_NOTES_0.0.113.md、.gitignore、releases/tags/languages/contributors/branches/commits/forks、组织信息、官网首页与隐私政策的原始 HTML、官网脚本、sitemap、GitCode 稳定版清单与单版本清单、更新仓文件树与 releases 渲染页、取证脚本与日志）。

通道口径：仓内正文一律走 contents API（返回 base64），4/4 成功；gitcode.com 网页是 SPA、原始 HTML 是空壳，其内容分两类 —— api.gitcode.com 的 JSON 机器可复核，releases 页 changelog 是渲染抽取（已在正文逐处标注）。

查不到 / 待核实：

源码级面全部查不到：技术栈具体版本（Wails、Go、Vue、Node）、依赖清单、模块划分、数据表结构、AI 调用实现、公众号数据的采集方式（插件抓取？官方接口？人工导入？）。无源码、无构建清单、语言统计返回空对象。
用户量、下载量、营收：GitHub 侧 3 星 0 fork；GitCode 更新仓页显示「项目总下载次数 787」，但那是该仓的 Clone、Pull、zip 与 Release 下载之和，不是产品安装量。产品级数据查不到。
「商用绿色版」是什么：官方 changelog（v0.0.120 修复项）出现该词，但官网与 README 都没有对应的售卖页或授权说明。查不到。
版本清单与发行不同步的原因：updates/versions/ 只到 0.0.115（16 份），而 stable.json 已到 0.0.123。是「只对部分版本留档」还是「目录已停更」，查不到。
Gitee 镜像状态未核：README 给出 gitee.com/wendaoai/wendao-content-workbench，本目标未访问，是否同步、是否含额外内容都不知道。
更新清单的其它信道未核：只读到 channel: "stable"；是否存在 beta、insider 等清单文件，updates/ 下只有 stable.json 与 versions/，未再探测。
真实运行证据为零：未下载安装包、未安装、未运行。所以「六段链路可用」「智能排版能出公众号内联样式」「卡片工坊可用」都没有实测支撑，只有官方陈述与 changelog。
合规面未核：官网 FAQ 称「AI 生成内容需人工审核」，隐私政策自陈「不构成完整法律意见」，这些合规性未经第三方核验（本份只做转述）。

许可提醒：仓内无 LICENSE，NOTICE.md 声明「proprietary…All rights reserved」，并写明「No license is granted to copy, modify, redistribute, reverse engineer, or create derivative works from the product, its documentation, screenshots, or brand assets」。所以它的 README 文案、官网文案、界面截图、品牌素材都不可复制进我们的产物；本份只做事实性引用，未转载任何素材文件。

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

第 1 节写了它属哪一层、为什么纳入（判据是用户的选择，不是名气）
第 2 节四行都在（形态 / 给谁用 / 干什么用 / 证据等级），没有留白
第 3 节六行动作链都在（进入方式 / 操作路径 / 核心步骤 / 系统帮了什么 / 最终产出 / 哪一步最省力·最麻烦）；取不到的写了「取不到：<原因>」，没有留白、也没有拿功能名罗列顶替
第 4 节每项能力都接了「解决什么问题 / 起什么作用」，且逐项标明是官方自述
第 5 节每条机制都接了「为什么这样设计 ⇒ 给用户什么结果」，推断处已单独说明
第 6 节每组强弱都是四行（能力表现 / 在什么场景 / 相对谁 / 对用户什么结果）
第 7 节三分类齐全（该借鉴 / 该避开 / 可突破）
证据等级已声明为文档级，并写明「不与另四家同权」
已过内容准则，评分 45/50

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

上一版是「第五棒」产物：十一节，主体是取证过程与公开面盘点 —— 六条结论（闭源实证、三层公开面、单平台定位、可核验工程做法、技术栈线索、README 与发行脱钩）、仓库元数据表、产品定位、功能清单（README 八项加官网十项加 changelog 暴露的版本迭代面）、技术架构线索逐条标证据类型、发布与分发机制、可借鉴点、风险与合规、查不到、来源表。没写用户是谁、用户在什么处境下用它、界面上怎么操作。

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

新增「用途」（第 2 节）—— 上一版没有这一节。「给谁用」在上一版只以「公众号创作者、内容运营人员和小型内容团队」一句夹在定位段里出现，这一版单独立行。
新增「场景」（第 3 节）—— 上一版最缺的一块，而且这一版没有硬凑：六行里三行整行取不到（核心步骤、系统帮了什么、哪一步最省力·最麻烦），另外三行只给官方自述并写明缺什么。上一版把官网的六段链路当成「功能清单」放在 §4.3，那不是使用过程。
把技术栈从「推断」改成「有据的推断＋缺什么」—— 上一版有一张逐条标证据类型的表；这一版在第五节把它压成一段并写死边界（具体版本、依赖清单、模块划分、数据表结构一概查不到）。
改造「强弱」（第 6 节）—— 上一版把这部分拆成「可借鉴点（8 条，工程做法为主）」和「风险与合规（5 条）」，且没有「相对谁」。这一版改成 4 强 4 弱、每条四行。其中「文档与发行状态脱钩」从「风险第 1 条」升级成一条独立的弱项，因为它对用户的直接影响最大。
新增「可突破」（第 7 节）—— 上一版没有。这一版给出两条产品层判断：它的「深」可以抽出来跨平台复用；它的数据回写只到月度人工复盘这一层。
公开面盘点降级为附录 —— 仓库元数据表（5 个 blob 逐条、语言统计空对象、9 条 docs: 提交、1 个贡献者）、changelog 逐版摘要、stable.json 逐字段这些内容，压进第四节第 8 条、第五节第 3 条与附录。事实一条没丢。
删掉「下一棒建议」与「来源表」 —— 棒次视角与取证台账不属于竞品分析。上一版那张 19 行来源表压成附录两句通道口径。
加了一句上一版没有的判断：这个仓的星标、提交数、贡献者数不能用来判断产品活跃度 —— 它是文档仓不是代码仓。上一版虽然写了这句话（第 1 条结论），但把它放在结论里说；这一版提到第一节当作读这份文档的前提。

本份是第五棒产物的重写版（独立分析体）。原始证据见 取证/api/（第 1 棒，只读复用）与 取证/wendao/（第 5 棒 20 件）；取证脚本 _fetch_wendao.py。

30 KiB Raw Permalink Blame History Unescape Escape