Skip to content

PRODUCT_EVALUATION_ZH.md

Latest commit

 

History

History
349 lines (222 loc) · 11.6 KB

PRODUCT_EVALUATION_ZH.md

File metadata and controls

349 lines (222 loc) · 11.6 KB
Raw

MoonPub 整体评估与阶段计划

这份文档回答三个问题：

  1. MoonPub 现在到底是什么，离“用户真能用起来”还差什么。
  2. 飞书秒记这条路线，应该留在当前项目里，还是拆成新项目。
  3. 接下来 4-8 周最值得做的目标和顺序是什么。

目标不是再写一份愿景，而是基于当前代码、当前文档和已经跑通的真实链路，收口成一个可执行计划。

如果你现在更需要的是“MoonPub 到底应该怎样被当成一个产品来理解”，先看 PRODUCT_WRAP_ZH.md。那份文档会先把 Core、输入工作流层和用户入口层拆开，再回来读这份评估会更顺。

一句话判断

MoonPub 现在最适合的定位，不是“一个已经完整产品化的 AI Agent”，而是：

一个本地优先的内容发布内核，微信发布是第一主线，飞书秒记是已经跑通的高价值输入源。

所以当前更合理的方向是：

  • 短期：不要把飞书路线拆成独立项目，先作为 MoonPub 内部的一级工作流继续做稳。
  • 中期：把 MoonPub 包装成“本地发布 Agent / 本地发布副驾驶”的产品形态。
  • 后期：当飞书输入源已经形成独立用户价值、独立发布节奏和独立分发渠道时，再考虑拆成单独项目或单独产品线。

当前项目真实状态

基于当前仓库代码和文档，MoonPub 已经具备这些真实能力：

  • 从 Markdown / Obsidian 生成微信兼容 HTML 和 draft JSON。
  • 推送到微信公众号草稿箱。
  • 用浏览器自动化补原创、赞赏、留言、创作来源、预览发送。
  • 导出到 Zola。
  • 支持封面、排版主题、Block 模板、AI 写作/润色。
  • 支持 capabilities --json，已经有了插件 / 本地 App / Agent 可调用的能力元数据。
  • 飞书秒记链路已经真实跑通： Feishu -> Inbox -> 草稿 -> 本地预览 -> 微信草稿 -> 微信后台预览发送

同时，当前项目也存在几个明显问题：

1. 用户理解成本仍然偏高

从代码角度看，能力已经不少；但从用户角度看，入口还是分散的：

  • CLI 命令很多
  • 文档很多
  • 默认路径、快速路径、本地预览、后台预览这些概念不够天然
  • 用户第一次上手时，不容易知道“我现在应该跑哪条路径”

2. 项目正在成长为“工作流平台”，但对外还像“命令集合”

从 src/plugin.rs、capabilities --json、draft-from-inbox、intake feishu 这些设计看，MoonPub 实际上已经在长成一个本地工作流内核。

但对外表达还是偏 CLI 工具：

  • 用户看到的是命令
  • 还不容易看到“推荐工作流”
  • 还没有非常清晰的“面向谁、先用哪条路、完成标准是什么”

3. 飞书路线已经有产品潜力，但还没到拆项目的时机

飞书秒记路线现在已经有三个强信号：

  • 输入天然高频：语音、会议、散步记录、临时想法都能进来
  • 内容天然需要整理：不是生文本直接发，而是要走“草稿确认”
  • 和 MoonPub 主线高度耦合：最终还是进入文章草稿、预览和发布

但它暂时还没有独立成项目的充分条件：

  • 主要输出目标还是公众号 / 博客文章
  • 目前最强价值仍然依赖 MoonPub 的渲染、排版、推送和预览能力
  • 还没有形成独立于发布链路之外的“飞书知识产品”

4. Obsidian 插件和未来 Agent 已经有基础，而且插件首页已经开始形成真正入口

仓库里已经有：

  • obsidian-plugin/
  • capabilities --json
  • 结构化 JSON 工作流输出

这说明“本地 App / Agent / 插件调用 MoonPub 内核”这条路是对的。

但当前还缺：

  • 更强的首次使用证据
  • 更一致的中英文入口口径
  • 更可视化的 walkthrough / 截图 / 录屏材料

这里的“统一入口对象”现在已经有了第一版落点：moonpub workspace --json。而且 Obsidian 插件已经开始真实复用这层协议，把它展开成 MoonPub 首页工作台，集中展示工作区类型、推荐入口、文章池阶段分布、能力元数据和推荐下一步，方便未来的本地 App 和 Agent 继续直接接力。

飞书路线：模块优先，不急着拆项目

当前建议

结论：先做成 MoonPub 内部的正式模块，不要立刻拆新项目。

理由很明确：

  1. 飞书路线的核心价值还依赖 MoonPub 主链路 飞书现在最有价值的不是“导入文本”，而是“导入后能直接变成可发布文章”。

  2. 输入源和发布内核最好先在一个仓库里迭代 现在 src/intake.rs、src/ai_workflow.rs、src/app.rs、src/push.rs 的组合，是一条完整闭环。现在拆仓库，会明显增加同步成本。

  3. 现在真正缺的是产品形态，不是代码仓库拆分 当前瓶颈不是“代码不够独立”，而是“用户不知道该怎么用”。

什么时候再考虑拆？

只有当下面 3 条里至少满足 2 条时，再考虑拆成独立项目更合理：

  • 飞书输入源开始支持不止公众号发布，比如知识整理、周报、会议纪要二次加工
  • 飞书链路开始有独立用户群，不只是 MoonPub 用户的一个输入源
  • 飞书链路需要独立的权限模型、发布节奏或前端产品入口

在此之前，更好的做法是：

  • 在当前仓库里把它做成 正式模块 / 正式工作流
  • 在文档和产品表达里把它升级成 一级入口

AI Agent 方向：可以做，但应该基于 MoonPub 内核包装

合理的产品表达

与其马上说“做一个新 Agent 产品”，更准确的说法是：

把 MoonPub 包装成一个本地内容发布 Agent。

它的职责不是替用户偷偷发文，而是：

  • 接收输入源：Obsidian、飞书秒记、未来照片/语音/摘录
  • 生成中间产物：Inbox、Draft、HTML、Cover
  • 给出下一步动作：编辑、预览、推送、后台确认
  • 保持人工确认边界

为什么这比“重新做一个 Agent 项目”更对

因为现在核心能力已经在仓库里了：

  • 结构化 JSON 输出
  • capabilities --json
  • publish/export target
  • 草稿后续动作语义

也就是说，MoonPub 已经具备成为 Agent runtime 的雏形。现在最优动作不是另起炉灶，而是：

  • 继续稳定 CLI 内核
  • 明确输入源与工作流边界
  • 把 workspace --json、status --json、check --json 这类协议层继续收口成统一入口
  • 在此基础上再长出插件 / App / Agent 外壳

如果接下来的重点是“插件 / App / Agent 到底应该先接哪几个命令、按什么层次接”，现在可以直接看 AGENT_PROTOCOL_ZH.md。

如果接下来的重点是“飞书、照片、语音这些输入源应该怎样统一建模，而不是继续各做各的 frontmatter”，现在可以直接看 INPUT_MODEL_ZH.md。

推荐的产品拆分

接下来建议把项目明确拆成三层来推进：

第一层：MoonPub Core

定位：本地发布内核

负责：

  • 渲染
  • 封面
  • 推送
  • 后台自动化
  • 导出
  • 文章状态管理
  • 能力发现与结构化输出

对应当前代码：

  • src/render.rs
  • src/push.rs
  • src/publish.rs
  • src/plugin.rs
  • src/ship.rs
  • src/bundle.rs

第二层：Input Workflows

定位：输入源工作流层

负责：

  • 飞书秒记
  • 照片整理
  • 未来语音笔记
  • 未来读书摘录

对应当前代码：

  • src/intake.rs
  • src/ai_workflow.rs

这里建议逐步把“飞书”从一个命令选项，升级成一个正式工作流模块。

第三层：User Surfaces

定位：用户入口层

负责：

  • CLI
  • Obsidian 插件
  • 未来本地 App
  • 未来 Agent 包装

对应当前代码 / 方向：

  • src/cli.rs
  • obsidian-plugin/
  • capabilities --json

未来 4-8 周的阶段目标

接下来的重点不应该是“再加很多能力”，而应该是：

先把用户能真正跑起来的主路径做窄、做清楚、做稳定。

Phase 1：收口成一个主推工作流

目标：让技术用户第一次看到项目时，知道该怎么走。

完成标准：

  • README 第一屏明确主推的 3 条路径：
    • 普通文章路径
    • 飞书秒记路径
    • 照片素材路径
  • 每条路径都只有 3-5 步
  • 文档里不再让用户自己猜“应该先用哪个命令”
  • 插件首页被明确承认是第一次体验的第一入口之一

建议优先事项：

  1. 明确“主推工作流”文档
  2. 把插件首页写成正式首页入口
  3. 把照片路线和飞书路线并列补齐

Phase 2：把飞书路线做成正式模块

目标：让飞书秒记不再像附加功能，而是核心入口之一。

完成标准：

  • 文档上成为一级入口
  • CLI / JSON 语义稳定
  • 后续动作统一为“编辑 / 预览 / 推送”
  • 能清楚区分默认保守模式和显式快速模式

建议优先事项：

  1. 保持 intake feishu 语义稳定
  2. 增加针对飞书链路的“推荐使用流程”文档
  3. 为后续照片/语音输入源预留统一输入模型

Phase 3：把 MoonPub 包装成 Agent-ready 内核

目标：让未来本地 App / Agent / 插件不用重写流程。

完成标准：

  • capabilities --json 持续稳定
  • 工作流命令的结构化输出稳定
  • 输入源与发布目标边界更清楚
  • 文档里明确“MoonPub Core / Input Workflows / User Surfaces”结构

建议优先事项：

  1. 为输入源增加统一抽象
  2. 梳理 CLI 和插件的边界
  3. 为本地 App / Agent 写一份集成说明

当前最值得马上做的 5 件事

按优先级排序，我建议是：

  1. 补真实首次体验证据 先把插件首页、飞书和照片三条路径的截图、录屏、walkthrough 做实。

  2. 把插件首页继续收成正式首页 现在已经形成雏形，接下来要继续压缩“第一次点哪里”的成本。

  3. 继续统一入口文档口径 尤其是英文 README、产品包装和执行计划，不要再落回旧阶段。

  4. 定义输入源抽象的方向 让飞书、照片、语音不再只是零散功能点。

  5. 继续写 Agent / 本地 App 集成文档 不急着做完整产品，但先把接口边界说清楚。

不建议现在做的事

以下动作现在看起来诱人，但不应该优先：

  • 立刻拆飞书成新仓库
  • 立刻承诺“完整 AI Agent 产品”
  • 继续横向加很多发布平台
  • 过早做云端托管或 SaaS 化

现在最需要的是：

把主线做清楚，让第一个真实用户能顺利用起来。

建议的近期里程碑

M1：用户看得懂

标志：

  • README 能让用户一眼知道自己属于哪条路径
  • 有一份正式“推荐工作流”文档
  • 飞书路线有稳定说法

M2：用户跑得通

标志：

  • 普通文章路径稳定
  • 飞书秒记路径稳定
  • 插件 / CLI 至少一条入口不让人迷路

M3：用户愿意持续用

标志：

  • 草稿交接顺滑
  • 修改、预览、推送边界明确
  • 能开始承接照片、语音、读书摘录等新输入源

最终结论

当前最优策略不是“继续分散优化”，也不是“马上拆新项目”，而是：

  1. 先把 MoonPub 明确成 本地发布内核
  2. 把飞书秒记明确成 当前最有价值的输入源工作流
  3. 把 CLI / 插件 / 未来 App 视为 不同入口层
  4. 先收口主推路径，再继续扩平台、扩输入源、扩产品外壳

如果只用一句执行建议来总结，就是：

现在先做“让用户会用”，再做“让能力更多”。

如果你现在更关心的不是“整体怎么判断”，而是“接下来具体按什么顺序推进、哪些里程碑算完成”，继续看 EXECUTION_PLAN_ZH.md。