一文多发助手2.0产品设计

一、项目概述

1.1 产品定位与价值主张

产品定位

面向个人知识型创作者的内容分发自动化工具，支持从飞书链接、带外链的Markdown文档、本地Obsidian文档三种来源输入，自动完成内容解析、图片上传、AI增强（排版、摘要、标签、封面图生成）、格式适配（Front-matter/公众号排版），并自动推送至个人博客（Github + Hexo）及微信公众号草稿箱（通过wenyan-mcp）。

核心价值

覆盖不同来源的内容分发，针对个人博客和微信公众号进行排版，解决重复粘贴，提高效率。利用AI增强生成对应的标题、摘要、标签、分类和封面图，图片统一管理，使得创作者专注于内容创作，直接一键分发。

1.2 目标用户与核心痛点

目标用户

多平台发布需求的个人技术博主
知识型长文创作者

核心痛点

图片链接管理混乱
不同平台内容格式有差异
重复格式调整和手动上传操作耗费时间
写作兼顾排版很烦，需要后续多次整理
文章需要进行概要总结、封面图选取、标签和类别整理

二、版本演进

2.1 上个版本回顾

技术方案

1.0版本基于Coze平台搭建Agent，核心流程如下：

OneNote写作
    ↓
导出Word文档
    ↓
TextIn API解析（OCR + 文档结构提取）
    ↓
DeepSeek v3.2 内容增强
    ↓
图片上传至阿里云OSS
    ↓
Hexo博客自动发布 / 微信公众号半自动发布（wenyan-cli）

已支持平台

平台	发布方式	自动化程度
Hexo个人博客	GitHub Pages	全自动
微信公众号	wenyan-cli	半自动（需手动确认）

2.2 上个版本局限性总结

平台限制

MCP协议不支持，从wenyan-mcp绕道到wenyan-cli
代码节点运行在受限的沙箱环境中，只内置requests_async和numpy，无法使用python-docx等库（已经可以下载第三方库，该限制不存在）

输入源问题

仅支持Word文档输入，写作工具绑定OneNote
OneNote导出Word后，TextIn解析存在不准确：
- 表格/图标无法完整OCR，输出为格式
- 解析后会将图片中无意义的装饰图logo、水印、箭头等留下
- 需要在Agent中增加审查步骤删除注释内容和废图，增加了不稳定性

功能限制

Coze工作流的节点能力有上限，难以支持复杂的处理逻辑，需要添加很多代码节点
github只支持新增文章发布，不能修改文章发布（需要在code节点中增加sha值）
微信公众号发布需要将markdown导出到本地，在命令行中输入命令发布到草稿箱，需要手动介入

核心矛盾分析

输入源的确定与图片的存储是主要矛盾点：

OneNote作为个人习惯使用的知识库记录平台，可以多端查看和记录，支持手写功能和富文本编写，图片记录时多采用截图粘贴的方式
写作方便了，但导出传播带来负担
Markdown作为个人博客发布时的内容记录，图片需要以外链的形式存放，从而实现轻量、简便的优点

决策结论

针对不同写作用户制定属于他们的输入源和后续流程。

2.3 新版本设计目标

在1.0基础上重点解决三个问题：

输入源扩展：不再绑定单一写作工具，支持飞书、Obsidian、带外链的Markdown文件
功能增强：增加个人博客修改文章的能力，数学公式的获取和显示问题
平台能力升级：从Coze迁移至Dify，获得更强的工作流编排能力，将工作流导出使用，集成MCP到Node CLI项目中使用

版本对比

版本	时间	平台	核心能力
1.0	MVP阶段	Coze Agent + Workflow	文档解析 → 内容增强 → 博客发布（自动）、公众号发布（半自动）
2.0	当前版本	Dify Workflow + Node.js CLI	多输入源 → 图片自动处理 → 公众号发布（自动化程度更高）

三、2.0版本产品设计

3.1 支持的输入方式

基于市场上知识型创作者的记录方式调研：

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

2.0版本支持的三种输入方式

输入方式	适用场景	使用要求
飞书文档链接	在飞书中写作的用户	仅支持纯文本和表格，不支持图片和mermaid流程图
带外链的Markdown文件	图片已托管在外部的文章	适合word/PDF通过TextIn WebUI转换后的文件
本地Obsidian文档	使用Obsidian写作、图片存储在本地的用户	图片需保存在与文档同级的assets文件夹

各输入方式详细说明

1. 飞书文档链接

使用飞书文档插件get_document_content获取到Markdown内容。

⚠️ 局限性

飞书本质是企业写作工具，文档系统是为多人协作编辑设计的，不是为个人知识管理+AI集成+内容发布设计的

飞书的图片存在自己的CDN，且API是为企业开发者设计，个人使用较重

如果使用"获取飞书文档所有块"工具，还需要对块数据进行解析，很麻烦

2. 带外链的Markdown文件

针对导出的Word或PDF文件转换成的Markdown文件，通过TextIn的WebUI解析，删除工作流中人工审查这个不确定性较强的步骤。浏览器上解析完成可直接在其自带的编辑器中修改。

⚠️ 局限性：需要浏览器中操作，下载文件然后在终端页面发布。

3. 本地Obsidian文档

Obsidian中搭建自己的知识库，编写markdown格式文档。

💡 使用要求

图片保存在与文档同级别的assets文件夹中，设置如下图

使用Paste Image Rename插件对图片重命名，避免空格等，浏览器会将URL中空格解析成%20

3.2 核心流程设计

3.3 用户使用流程

1、项目终端输入

PS D:\Dify\cope> node src/cli.js --way 本地Obsidian文档 --md-file "D:/wiki/articles/一文多发助手2.0产品设计/一文多发助手2.0产品设计.md"