AI内容分发自动化助手评测
AI内容分发自动化助手评测
一、手工基线评测
1.1 评测范围
本轮手工基线共覆盖 8 篇文章，输入方式分布如下：
- 本地 Obsidian：4 篇
- 飞书链接：2 篇
- 带外链 Markdown：2 篇
所有样本均以"博客可访问 + 公众号草稿箱生成"为最终成功标准，耗时都是在最终成功标准上进行统计。
1.2 基线汇总
1.2.1 单篇结果
| 文章 | 输入方式 | 图片数 | 公式 | 总耗时 | 详细步骤耗时 |
|---|---|---|---|---|---|
| 一文多发助手2.0技术文档 | Obsidian | 6 | 否 | 52m | 准备信息 4m；处理图片 4m；编辑 front-matter 10m；找封面图 2m；粘贴到编辑器并补图链 17m；GitHub 推送 3m；复制到公众号 8m；微信排版/发布 4m |
| ReAct论文研读 | Obsidian | 0 | 是 | 16m | 准备信息 3m；找封面图 1m；编辑 front-matter 3m；粘贴到编辑器 4m；GitHub 推送 3m；微信发布 2m |
| Prompt工程 | Obsidian | 0 | 否 | 21m | 准备信息 2m；文章整理排版 8m；处理图片 0m；找封面图 2m；编辑 front-matter 2m；粘贴到编辑器 2m；GitHub 推送 3m；微信发布 2m |
| RAG工程与实践 | Obsidian | 0 | 否 | 25m | 准备信息 1m；文章整理排版 11m；处理图片 2m；找封面图 2m；编辑 front-matter 4m；粘贴到编辑器 1m；GitHub 推送 2m；微信发布 2m |
| Dify调研 | 飞书链接 | 0 | 否 | 25m | 准备信息 4m；找封面图 2m；编辑 front-matter 4m；粘贴到编辑器并重排 7m；GitHub 推送 3m；微信发布 5m |
| openclaw安装及简单了解 | 飞书链接 | 0 | 否 | 23m | 准备信息 2m；找封面图 2m；编辑 front-matter 4m；粘贴到编辑器并重建表格 9m；GitHub 推送 3m；微信发布 3m |
| 手写数字识别 | 带外链Markdown | 3 | 是 | 19m | 准备信息 3m；处理图片 3m；找封面图 1m；编辑 front-matter 5m；粘贴到编辑器并替换 1 张图片 2m；GitHub 推送 2m；微信发布 3m |
| AI基础知识 | 带外链Markdown | 7 | 是 | 22m | 准备信息 3m；处理图片 2m；找封面图 1m；编辑 front-matter 2m；放入博客项目并替换图链/排版 10m；GitHub 推送 2m；微信发布 2m |
1.2.2 按输入方式汇总
| 输入方式 | 样本数 | 成功率 | 总时长 | 平均时长 |
|---|---|---|---|---|
| Obsidian | 4 | 100% | 114m | 28.5m |
| 飞书链接 | 2 | 100% | 48m | 24m |
| 带外链 Markdown | 2 | 100% | 41m | 20.5m |
| 总计 | 8 | 100% | 203m | 25.375m |
1.2.3 不同来源的文章操作步骤
| 来源类型 | 主要手工操作步骤 | 典型额外成本 |
|---|---|---|
| 本地 Obsidian | 准备测试信息 → 如有需要先整理笔记内容 → 找封面图 → 编辑 front-matter → 粘贴正文到博客项目 → 处理图片/公式/排版 → GitHub 推送部署 → 发布到微信草稿箱 → 人工复核 | 笔记态内容整理、公式兼容、图片替换 |
| 飞书链接 | 准备测试信息 → 打开飞书并复制正文 → 找封面图 → 编辑 front-matter → 粘贴到博客项目 → 重新排版/重建表格 → GitHub 推送部署 → 发布到微信草稿箱 → 人工复核 | 复制后排版重整、表格重建成本高 |
| 带外链 Markdown | 准备测试信息 → 检查外链图片和外链资源 → 找封面图 → 编辑 front-matter → 将 Markdown 放入博客项目 → 替换外链图片/修正公式 → GitHub 推送部署 → 发布到微信草稿箱 → 人工复核 | 图片链接替换、公式修正 |
1.3 关键结论
- 带外链 Markdown 最接近低摩擦发布，原文排版基本完成，发布阶段主要是补 front-matter、替换图片、执行发布
- 飞书链路的主要成本在复制后重排和表格重建，不在发布命令本身
- Obsidian 作为主输入源，遇到图片、公式、笔记态内容时，人工成本上升明显
1.4 内容复杂度和耗时关系
- 图片多：会增加图片上传、替换、检查成本
- 公式多：会增加博客侧公式渲染检查和返工概率
- 表格存在：飞书链路下手工重建成本明显升高
- 原文是"笔记态"而不是"成文态"：会显著增加整理和排版时间
二、AI内容分发自动化助手评测
2.1 评测范围
与手工基线评测文章一致。博客结果以仓库推送成功且内容可检查为准，微信结果以进入公众号草稿箱且可人工复核为准。
2.2 自动化结果汇总
2.2.1 单篇结果
| 文章ID | 文章名称 | 输入方式 | dify工作流耗时 | 总耗时（预估wenyan-mcp的耗时每篇在40s） | 与手工基线耗时差 |
|---|---|---|---|---|---|
| A01 | 一文多发助手2.0技术文档 | Obsidian | 2.431min | 3.098min | 48.902min |
| A02 | ReAct论文研读 | Obsidian | 1.347min | 2.014min | 13.986min |
| A03 | RAG工程与实践 | Obsidian | 2.155min | 2.822min | 22.178min |
| A04 | Dify调研 | 飞书链接 | 0.917min | 1.584min | 23.416min |
| A05 | openclaw安装及简单了解 | 飞书链接 | 0.545min | 1.212min | 21.788min |
| A06 | 手写数字识别 | 带外链Markdown | 0.886min | 1.553min | 17.447min |
| A07 | AI基础知识 | 带外链Markdown | 2.173min | 2.840min | 19.160min |
| A08 | Prompt工程 | Obsidian | 0.489min | 1.156min | 19.844min |
2.2.2 遇到的问题汇总
| 典型问题 | 出现场景/文章 | 精简描述 | 影响 |
|---|---|---|---|
| 微信 IP 白名单限制 | A01 | wenyan-mcp 发布公众号草稿时报 invalid ip … not in whitelist | Dify 已完成内容处理和 GitHub 发布，但公众号失败，需要加白名单后重跑 |
| 文本入参字符上限 | A01 | md_content 文本类型超过 Dify 10000 字符限制 | 长文无法直接走文本入参，需要改文件入参或截断 |
| 文件/文本入参类型错误 | A06、A07 | 带外链 Markdown 应传文件，但实际按文本传入 | Dify API 400，流程直接失败 |
| 文件变量选择器配置错误 | A06 | 文档提取节点未正确绑定上传文件变量 | Dify 工作流失败，需要修正节点输入 |
| 本地 CLI / wenyan 缓存问题 | A03 | 首次发布时本地缓存写入失败 | 需要重试，拉长总耗时 |
| GitHub 与公众号发布耦合 | A01 | 同一次工作流里 GitHub 成功但公众号失败 | 建议拆分发布结果，便于单独补偿重试 |
| 复杂内容仍需人工复核 | A05、A07 | 表格、公式、外链图片等自动处理后仍可能有质量风险 | 自动化省时明显，但最终草稿仍要 spot check |
2.3 关键结论
自动化省掉的不是"发命令"本身，而是下面这些重复劳动：
- front-matter 编写
- 正文图片上传与链接替换
- 博客项目粘贴与推送
- 公众号草稿写入
- 多平台串联切换
💡 这个项目的核心价值已经从"能不能发"升级成了"能不能稳定减少发布前后的重复劳动"
2.4 核心问题
当前自动化还没有彻底解决 4 类问题：
- 环境依赖：如公众号白名单 IP、代理、网络问题
- 流程脆弱点：Dify/CLI 入参类型一旦配错会整链失败
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 茯茶养生人的博客！
