FlareMo 产品需求梳理（对标 flomo）

这份文档整理 FlareMo 后续的产品需求方向，以 flomo（浮墨笔记）为主要对标产品，结合 FlareMo 自身路线图（ROADMAP.md）和架构边界（docs/architecture-notes.md、docs/semantic-search.md）梳理。

它是需求池和决策输入，不是承诺：具体开发顺序、范围裁剪和验收口径在选定需求后另行细化。本文只记录稳定方向和边界，不写过程日志。

对标基准：flomo 的能力全景

flomo 的核心闭环是「持续记录 → 意义浮现」，产品能力可以分成五块：

1. 快速记录：无压输入、AI 语音转写、多渠道输入（微信服务号、App、网页、插件）、全平台同步。
2. 回顾体系（flomo 的灵魂）：
   • 被动回顾：小部件回顾、微信推送、Push 推送。
   • 主动回顾：回顾标签 + 时间范围集中回顾。
   • 探索式回顾（AI 加持）：相关笔记、随机漫步、认知地图、找一找（语义查询）。
3. AI 能力：flomo Agent（读过全部笔记的对话 AI）、AI 记忆档案、AI 洞察（多视角分析笔记）、MCP 连接（AI 工具直接读写笔记库）。
4. 标签体系：多级标签（#标签/子标签）、标签管理（重命名/删除/移动）、Emoji 标签、无标签筛选。
5. 其他：多维统计（热力图）、数据导入导出、API 输入、搜索（标签/历史/Spotlight）。

FlareMo 现状对照

flomo 能力	FlareMo 现状	差距
无压快速记录	已实现：composer、草稿恢复、离线队列	无语音转写、无微信/App 等外部输入渠道
卡片式时间线	已实现：memo-card + explorer（all/archived/trashed）	基本对齐
标签	已实现：多级标签树（层级折叠）、标签管理（重命名/移动/删除）、无标签筛选、层级前缀筛选、#父/子 层级提取	无 Emoji 标签
搜索	已实现：关键词 + 时间/状态语法	无语义搜索（"找一找"）
活动热力图	已实现	基本对齐
公开分享	已实现：share token + /share/{token}	基本对齐
引用/反向链接	部分：memo relations 已存在，前端可添加关系	无反向链接回顾面板、无关系图
多渠道输入	部分：Memos 兼容 API、MCP、Telegram bot 示例	Telegram bot 未升级为完整输入通道
AI 读写笔记 / 记忆	已实现：Agent Memory（/memory/mcp 六工具 + /memory 管理 UI），与 /mcp memo 工具子集并行	无 flomo Agent 式对话、无 AI 洞察；记忆召回仍为关键词（无语义 embedding）
数据导出	已实现：内联导出（≤32 MiB）+ 大型导出任务（分页 NDJSON + R2 清单 + 附件下载端点）	无浏览器端「导出集打包为单个归档」体验
每日回顾/随机漫步	已实现：/review/daily（那年今日分组）+ /review/walk（标签/引用游走 + 明信片总结）	无定时推送触达渠道
相关笔记/认知地图	未实现	认知地图依赖语义检索
AI 洞察/找一找	未实现（docs/semantic-search.md 只有设计）	完全缺失

需求池

按依赖关系和投入产出比分三批。每项标注：价值、成本、依赖、与 ROADMAP 的关系。

第一批：补齐 flomo 核心闭环

R1. 反向链接回顾（引用关系可视化）

• 内容：memo 详情页展示「被谁引用 / 引用了谁」的回顾面板；可选轻量关系图。
• 价值：高。复用已有 relations 数据，立刻有 flomo「笔记关系图」的味道，是知识管理的关键闭环。
• 成本：低。纯前端 + 复用现有 relations API，无新基础设施。
• 依赖：无。
• ROADMAP 关系：对应「引用关系、反向链接」产品主线；E2E 任务池里的「反向链接」测试项。

R2. 语义搜索（"找一找"）

• 内容：按 docs/semantic-search.md 实现。Vectorize 存派生 embedding 索引，D1 仍是事实源；命中后回 D1 校验 status/visibility/share/ACL；前端 explorer 加自然语言搜索入口。
• 价值：高。flomo「找一找」的对标核心，也是 R3 相关笔记的向量基础。
• 成本：中高。Vectorize 索引、embedding 模型绑定、memo 变更增量更新（可挂现有 outbox/SSE 事件流）、前端入口。
• 依赖：Cloudflare Vectorize + Workers AI（或外部 embedding 模型）。
• ROADMAP 关系：公开任务池「增加语义搜索」。

R3. AI 回顾三件套

• 内容：
  1. 每日回顾：定时挑选旧 memo 推送（cron 已有 17 3 * * * 可复用/新增）+ 前端回顾页。
  2. 随机漫步：沿 memo 关系随机游走，输出一条「明信片」式回顾路线。
  3. 相关笔记：当前 memo 的语义相近历史笔记。先做基于标签/关系的轻量版，R2 落地后升级为向量版。
• 价值：高。flomo 的灵魂功能，把「记录」变成「回顾」。
• 成本：中。每日回顾/随机漫步是纯 D1 + 前端；相关笔记轻量版零新依赖，向量版依赖 R2。
• 状态（2026-08）：每日回顾前端页（/review/daily，那年今日）与随机漫步（/review/walk，含明信片总结）已上线；剩余为定时推送触达和相关笔记面板。
• 依赖：R1（关系数据）、R2（向量版相关笔记）。
• ROADMAP 关系：公开任务池「增加 AI 回顾」。

第二批：输入与体验（flomo 的"低摩擦"护城河）

R4. 多渠道输入

• 内容：
  1. Telegram bot 升级：现有 apps/telegram-bot 示例升级为完整输入通道（发消息即记 memo）。
  2. PWA + 快捷唤起：桌面 PWA 唤起即写、iOS 分享扩展。
  3. 语音转写：Workers AI speech-to-text（成本较高，可后置）。
• 价值：中高。降低记录摩擦，是 flomo「像发消息一样记录」的核心体验。
• 成本：中。Telegram bot 已有基础；PWA 是前端工作；语音转写依赖 Workers AI 质量。
• 依赖：无硬依赖。
• ROADMAP 关系：产品主线「快速记录」。

R5. 标签体验补齐

• 内容：多级标签树（层级折叠）、标签管理（重命名/移动/删除）、无标签筛选、Emoji 标签。
• 价值：中。flomo 标签体系是「让结构生长」的关键，也是 Memos 兼容面「层级 tag」未完成项。
• 成本：中。前端 + 少量 domain/API 扩展。
• 依赖：无。
• ROADMAP 关系：Memos 兼容矩阵「层级 tag」未完成项。
• 状态：✅ 已实现（v0.6.0）。多级标签树、层级前缀筛选、重命名/移动（含子树）、删除、无标签筛选、#父/子 层级提取均已落地。Emoji 标签未做（提取正则暂不包含 Emoji，可作为后续小迭代）。

第三批：工程与可靠性（自托管长期价值）

R6. 大型导入导出异步化

• 内容：超过内联上限（32 MiB）时走 R2 对象包 + 校验清单 + 异步任务状态查询，替代直接 413。
• 价值：中。数据安全与可迁移性，自托管用户的核心诉求。
• 成本：中高。R2 对象包、任务状态表、前端进度展示。
• 依赖：无。
• ROADMAP 关系：公开任务池「为超过内联上限的大型导入导出增加异步对象包和校验清单」。
• 状态：✅ 已实现（v0.6.0）。data_tasks 任务表 + 大型导出任务（分页读 D1、NDJSON 分块写 R2、自包含 manifest 清单、附件经认证端点流式下载）+ 导入任务（请求内执行并记录结果）+ cron 兜底过期/清理。内联导出阈值改为按完整 JSON 估算。前端导出/导入走任务流并轮询。限制：导入仍受请求体大小约束（约 100 MiB），超大型导入建议用 scripts/backup-drill.mjs 管理员灾备流程。

R7. 附件生命周期观测

• 内容：清理计数、缺失 R2 对象报告、可控重试。
• 价值：中。运维可观测性，避免附件静默丢失。
• 成本：中。
• 依赖：无。
• ROADMAP 关系：公开任务池「增加附件生命周期观测面」。

R8. 浏览器 E2E 扩展

• 内容：Markdown 渲染、历史恢复、反向链接、分享撤销、附件预览的 E2E 覆盖。
• 价值：中。质量保障，随 R1/R5 等前端改动同步补。
• 成本：低中。
• 依赖：随对应功能落地。
• ROADMAP 关系：公开任务池「扩大浏览器 E2E」。

R9. 扩大 Memos 第三方客户端兼容矩阵

• 内容：逐客户端 smoke + 配置示例写入 docs/memos-ecosystem.md。
• 价值：中。生态复用是 FlareMo 的差异化定位。
• 成本：中（需要真实客户端验证）。
• 依赖：无。
• ROADMAP 关系：公开任务池「扩大真实 Memos 客户端兼容矩阵」。

Agent Memory（对标 flomo「AI 记忆档案」）

flomo 的「AI 记忆档案」对应 FlareMo 的 Agent Memory：让 AI 通过统一 MCP 端点读写跨 session、跨 Agent 共享的长期记忆，用户随时可查看、确认、纠正。定位是 Human Knowledge (Memo) + Agent Memory，记忆归用户所有，Agent 只是读者和贡献者。

现状（P0 已完成）

• 四张 D1 表（memory_items / memory_revisions / memory_relations / memory_resource_links）+ memory_fts FTS5 检索索引；D1 是唯一事实源。
• /memory/mcp 无状态 Streamable HTTP MCP，六个工具：memory_bootstrap / memory_recall / memory_remember / memory_checkpoint / memory_link / memory_forget。
• /api/app/memory 管理 API + /memory Web 管理界面（Core / Projects / Recent / Review / Archive）。
• 权限层级 locked > confirmed > observed > inferred：Agent 永不覆盖用户确认/锁定的记忆，冲突进 Review；写入门禁含指纹去重与凭据安全检测。
• Memo ↔ Memory 双向连接（derived_from / promoted_to），导出导入纳入（bundle v3）。
• 接入说明见 docs/agent-memory.md。

后续（按投入产出比）

• 语义召回：P0 是 FTS5 关键词召回；接 Vectorize embedding 后升级为自然语言召回，schema 已预留 embedding_* 字段，与 memo 的「找一找」共用同一套基础设施。
• 自动固化：P0 依赖 Agent 主动调用 remember / checkpoint；后续在会话/工作完成后自动调 LLM 提炼关键决策与教训。
• agent 身份与可观测：source_agent 目前是来源字符串；后续可做 agent 注册与召回命中率/质量度量。

建议的开发顺序

按「投入产出比 + 不阻塞」推荐：

R1（反向链接回顾）→ R2（语义搜索）→ R3（AI 回顾）→ R4（多渠道输入）→ R5（标签补齐）→ R6-R9（工程与生态）

理由：

• R1 纯前端复用现有 relations，成本最低、立刻有 flomo 味。
• R2 有完整设计文档，是「找一找」的对标核心，且解锁 R3 的相关笔记向量版。
• R3 的 AI 洞察依赖语义搜索/embedding，放 R2 之后最顺。
• R4/R5 是体验增强，不阻塞核心闭环。
• R6-R9 是工程与生态，可穿插进行。

边界与不做

• 不复制 flomo 的客户端矩阵（iOS/Android/鸿蒙原生 App 不在 FlareMo 范围；Web/PWA 是主形态）。
• 不做 flomo Agent 式「读过全部笔记的对话 AI」的完整形态；AI 能力只做派生能力（洞察、回顾、检索），不替代 D1 事实源。
• 不引入邮件推送（项目明确无 email provider）；回顾触达渠道优先站内通知/Web Push。
• 不把 Vectorize、Workers AI 当主数据库（沿用 docs/semantic-search.md 边界）。
• 不因为对标 flomo 而破坏 Memos 兼容面；新增能力优先复用 /api/v1/* 和 domain services。

待决策问题

1. AI 回顾/洞察的模型放哪：Cloudflare Workers AI（国内可达性一般）还是外部模型（如 DeepSeek/OpenAI，走应用层令牌）？影响是否新增 API key 配置。
2. 每日回顾的触达渠道：站内通知（已有 notification 表，成本最低）/ Web Push（需新基础设施）/ 其他。
3. 语音输入是否进近期规划（Workers AI speech-to-text 质量与国内体验待评估）。
4. 相关笔记先做轻量版（标签+关系，零新依赖）还是直接等语义搜索做向量版。