一文多发助手MVP实践

产品名称：一文多发助手 · MVP实践报告

一、文档信息

  • 版本：v0.1 MVP
  • 状态：已验证跑通（个人博客、微信公众号）
  • 撰写人：邹阳
  • 日期：2026-04-23

二、背景与痛点分析

用户场景：OneNote个人知识库维护习惯，写长文包含截图/手写笔记

核心痛点：

  • 图片迁移麻烦：OneNode复制粘贴时图片变成Base64或丢失，手动上传图床繁琐
  • 格式适配繁琐：博客要Front-matter，公众号要特殊排版，小红书要短文案
  • 发布流程割裂：多平台切换导致重复劳动，时间浪费在复制粘贴上

三、竞品分析

竞品：WechatSync（开源多平台同步助手）

💡 详细报告请跳转一文多发产品调研

差异化优势对比：

  • 输入源：竞品依赖自有MD编辑器；本方兼容OneNote导出的Word，维护知识库完整性
  • 智能处理：竞品无智能排版；本方含内容重排、100字摘要提炼、标签生成
  • 基础设施：竞品图片分散；本方统一阿里云OSS图床

四、MVP范围定义

版本目标：验证"OneNote"导入→AI增强→自动推送博客/公众号的核心闭环。

✅ In Scope (v0.1 已实现)：

  • 输入：OneNote 导出 Word 文档（纯图文）
  • 处理：图片提取并上传 OSS、格式转为 Markdown、AI 内容重排与摘要
  • 输出：
    • 自动化：GitHub 个人博客 Hexo 架构自动推送（含 Front-matter）
    • 半自动：生成微信公众号适配内容（借助本地 wenyan-cli 手动粘贴）

❌ Out of Scope (暂未实现/下一版本)：

  • 小红书、知乎、掘金 的自动草稿箱功能
  • 数学公式 OCR 精准转换
  • 飞书/语雀等云端文档直连

五、核心功能说明

流程总览图

最外层上下文视图

Agent系统内部图

Agent工作流总览图

文件解析

内容增强

图片上传

格式适配

多渠道发布

核心处理流程

1. 输入

  • 来源：OneNote导出的Word文件（.docx)
  • 承载平台：Coze Agent

2. 文件解析

  • 执行方式：调用工作流 document_parse_flow
  • 核心工具：TextIn（第三方文档解析 API）
  • 处理动作：提取文字、图片，生成初始markdown内容

⚠️ 已知问题：TextIn 的 OCR 会生成无意义图片（如装饰元素、公式碎片等）

3. 内容增强

  • 执行方式：调用工作流 content_enhancement_flow
  • 处理动作：
    • 文章重新排版
    • 生成约 100 字内容摘要
    • 自动生成封面图

4. 人工审核阶段

  • 目的：弥补 TextIn 解析的 OCR 缺陷
  • 审核内容：
    • 删除无意义图片
    • 修正错误文本
    • 确认文章结构与标题
  • 输出产物：经过校验的标准中转 Markdown 文件

5. 图片处理阶段

  • 执行方式：调用自定义插件 AliyunOSSUpload
  • 处理动作：
    • 将 Markdown 中的本地图片上传至阿里云 OSS 图床
    • 自动替换文中图片链接为外链 URL

6. 发布分发阶段

目标平台 执行方式 具体操作
个人博客 自动 调用 github_push_flow 工作流，生成含 Front-matter 的 Markdown 文件，自动推送至 GitHub（Hexo 架构）
微信公众号 半自动 复制适配后的 Markdown 内容，通过本地安装的 wenyan-cli 工具完成格式转换与发布

六、MVP产品方案与技术选型

技术选型与决策

看了模型架构后会更加详细的添加内容

编排平台：

  • Coze平台：Workflow+插件

文档解析：

  • Textin API，对比Coze内置LinkReaderPlugin插件会丢失超链接/图片，故自建代码节点调用

图床服务：

  • AliyunOSS（自定义Coze插件接入）

推理模型：

  • DeepSeek v3.2：后续插入详细模型分析

发布工具：

  • 博客走Github API工作流
  • 公众号走Wenyan-cli（放弃md2wechat，付费），放弃Wenyan-MCP版本，目前Coze不支持

关键问题与解决方案

1. 图片被模型误删

  • 现象：Kimi 128k在编排节点自行删除了图片连接
  • 解决：切换DeepSeek v3.2 + 强制约束Prompt（明确指出：禁止OCR，禁止删除任何![]…链接）

2. Coze代码节点沙箱限制

  • 现象：无法安装python-docx
  • 解决：改用HTTP节点调用第三方TextIn文旦解析API（需付费）

3. 本地CLI工具安装污染

  • 现象：where md2chat发现旧版本残留导致冲突
  • 解决：清理注册表/Path，切换至wenyan-cli方案

七、核心指标与验证结果

定性结果

  • ✅ 成功推送一篇产品经理基础课长文到Hexo博客（带自动生成的封面摘要）
  • ✅ 成功生成微信公众号版本，通过本地工具一键注入微信公众后台直接发布
  • ❌ 文章AI基础知识（含大量公式截图和手写内容），准确率低，被标记为下一迭代已知限制

八、后续迭代方向与发展规划

阶段二 (v0.2)：

  • 公式处理专项：引入 MathPix 节点专门处理 OneNote 公式截图 → LaTeX 转换
  • 平台扩展：补全掘金、知乎、小红书的格式适配逻辑（纯 Prompt 工作流即可覆盖）
  • 架构迁移调研：从 Coze → OpenClaw / Claude Code 迁移

💡 判断依据：Coze 对 Skills/MCP 支持有限，且在代码节点依赖上受限，Claude Code 对于文件操作和本地环境调用更灵活直接，适合"一文多发"这类强依赖文件 IO 的任务。

九、总结与反思

OneNote→Word→TextIn OCR链路增加文章解析这不稳定的一步，OCR易识别出图片中的无意义文字和装饰图标等，导致增加人工审核步骤，这个问题来源于内容输入源。

需要清楚知识型技术博主的知识存储方式是什么。

市场上知识型创作者的记录方式分层：

  • 本地markdown：Obsidian/typora/VS code+图床
  • 在线markdown：语雀/飞书/Notion
  • 富文本笔记：OneNote/印象 （使用是因为图片增删改查非常方便）
  • 纯在线写作：公众号后台/第三方编辑器

v2.0迭代：

输入源适配（不同格式走不同处理通道，避免OCR滥用）：

  • 保留word输入源
  • 增加pdf输入源
  • 增加markdown文件直接上传（覆盖Obsidian/Typora用户）
  • 增加飞书/语雀API读取（覆盖在线文档用户）

不支持在线编辑，主要功能是内容分发等