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 现状对照

需求池

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

第一批：补齐 flomo 核心闭环（✅ 全部已实现，2026-09-13 收官）

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

• 内容：memo 详情页展示「被谁引用 / 引用了谁」的回顾面板；可选轻量关系图。
• 价值：高。复用已有 relations 数据，立刻有 flomo「笔记关系图」的味道，是知识管理的关键闭环。
• 成本：低。纯前端 + 复用现有 relations API，无新基础设施。
• 依赖：无。
• ROADMAP 关系：对应「引用关系、反向链接」产品主线；E2E 任务池里的「反向链接」测试项。
• 状态：✅ 已实现（2026-09-13）。详情页关联 tab 既有「引用了谁 / 被谁引用」面板（条目带记录时间与类型徽章、点击跳转、可管理增删），新增本篇视角轻量双列关系图（CSS 连接线、移动端隐藏）；内容级出处高亮与力导向全景图后置。

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 模型）。
• 状态：✅ 已实现。Workers AI embedding + Vectorize 派生索引（memo 向量共享 namespace）、/api/app/search/semantic 与前端「语义搜索」入口；命中回 D1 memoReadScope 复查，provider/索引缺失时自动降级 FTS5。详见 docs/semantic-search.md。

R3. AI 回顾三件套

• 内容：
  1. 每日回顾：定时挑选旧 memo 推送（cron 已有 17 3 * * * 可复用/新增）+ 前端回顾页。
  2. 随机漫步：沿 memo 关系随机游走，输出一条「明信片」式回顾路线。
  3. 相关笔记：当前 memo 的语义相近历史笔记。先做基于标签/关系的轻量版，R2 落地后升级为向量版。
• 价值：高。flomo 的灵魂功能，把「记录」变成「回顾」。
• 成本：中。每日回顾/随机漫步是纯 D1 + 前端；相关笔记轻量版零新依赖，向量版依赖 R2。
• 状态：✅ 已实现（触达渠道 2026-08-12 f34a5e3；勘误于 2026-09-13）。每日回顾页、随机漫步、相关笔记均上线；触达渠道为站内通知——cron（17 3 * * *）按 UTC 日期为「那年今日」有历史的用户幂等写入 daily_review 通知（daily-review:<date> 撞唯一索引，重放 no-op），铃铛渲染日历图标、点击归档并直达 /review/daily。已知边界：通知按 UTC 帧判定「今日」，远时区边缘时刻可能差一天；Web Push 后置。
• 依赖：R1（关系数据）。
• ROADMAP 关系：公开任务池「回顾触达渠道」。

第二批：输入与体验（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，可作为后续小迭代）。

R10. 日历视图（日历 = 未来之事 + 过往笔记的容器）

• 核心概念：只有一个可调度实体——带日期的任务。日历不新增日程实体、不引入"日程 vs 任务"的用户概念：日历格子里的条目就是一桩事，带不带完成状态是条目自身的属性。任务（tasks 模块）由此升格为日程的唯一事实源：Projects 页退化为按项目组织的视图之一，日历页按日期组织同一份数据，看板/优先级/dueAt 保留并成为日程主力。
• 内容：
  1. /calendar 专属日历页（主入口）：导航一级入口。整月视图：过去格子淡色铺已写笔记（点进去筛当天时间线），未来格子亮着排任务；顶部「今天」摘要（到期任务 + 笔记内未勾选的 Markdown 任务清单，复用已解析的 has_incomplete_tasks）；支持月导航、快速建日程（= 新建带日期任务）、改期（改 dueAt）。移动端独占一屏，交互模型对齐系统日历。
  2. 探索页只读小月历（辅）：与热力图并排，职责限于"回看过去/扫一眼近两周"，点日期跳时间线筛选，其余交互引至专属页；避免与专属页功能重复。
  3. 月历组件复用：一个组件两种形态（大 = 可交互版，小 = 只读联动版），聚合 API 共用。
• 明确不做：独立日程/事件表、团队日历（无创建主体，砍掉；团队维度由热力图/回顾页代表）、提醒推送（等站内通知/Web Push 就绪，不做"无触达的提醒"）、重复规则、iCal 同步、自然语言日期解析、memo eventAt 字段。
• 价值：中高。任务功能此前只入口于 Projects 页，日历补上"按时间看"这个维度后，任务/日程管理闭环才算成型。
• 成本：低。纯前端 + 聚合 API 为主，零新表零 migration，权限矩阵与 Memos 兼容 API 零改动（tasks 为 owner 私有，天然个人日历）。
• 依赖：无（tasks 模块已在线）。
• ROADMAP 关系：产品主线「安静时间线」的延伸。

R11. 音频文稿阅读（录音文件 + 转写长文同篇）

• 内容：让一条 memo 能同时承载一个音频文件和它对应的转写长文，并把它作为整体阅读形态呈现：
  1. 同篇承载：音频作为附件、转写作为正文（markdown），二者归属同一条 memo；设团队可见（protected）即进入团队知识库，成员在时间线/搜索中可读，也可通过公开分享页对外分享。不涉及系统内录制，也不涉及系统内转写——音频和文稿都由用户从外部带进来。
  2. 吸顶播放器：正文滚动时播放器常驻可见，支持倍速、拖动进度、播放进度记忆，可边听边读。
  3. 文稿排版：把转写当文章读——正文图片约束、标题层级与锚点、可折叠目录，阅读栏宽统一。
  4. 时间戳联动：转写中带时间戳时，点击时间戳可跳到音频对应位置；无时间戳时退化为纯吸顶播放，不做额外要求。
• 明确不做：浏览器内录音、系统内语音转写（仍是 R4 的独立后置项）、独立「录音文稿」页面或路由、新数据表。
• 价值：中高。团队知识库最常见的形态之一就是「一场分享/会议/访谈的录音 + 文字稿」，同篇承载 + 听读联动能让这类内容真正可用；也是「个人知识管理」主线里附件与长文能力的自然延伸。
• 成本：中。纯前端展示层重构（播放器、文稿排版、目录、时间戳联动），复用现有 memo/附件/分享/权限模型，零新表零 migration；不新增依赖。
• 依赖：无。音频附件与公开分享已在线。
• ROADMAP 关系：产品主线「个人知识管理」（附件、公开分享）的延伸，与 R4 语音能力解耦。
• 状态：✅ 已实现（2026-09-12）。同篇承载 + 吸顶播放器（倍速/拖动/进度记忆/跟随滚动）+ 文稿排版（标题锚点/可折叠目录/图片约束）+ 时间戳跳转 + 时间线长文折叠 + 正文内嵌图片（/file/ 相对路径跨上下文成立，分享页注入 share_token，画廊去重共存，死链降级占位），详情页与公开分享页同享；纯前端展示层改动，零新表零 migration。编辑器插图入口（粘贴/拖拽 → 上传 → 光标处插引用，发送时绑定，弃稿孤儿走既有 7 天 GC）已落地；最后后置项：分享页 SEO。

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

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。

后续（按投入产出比）

• 语义召回：已实现——memory 向量经 embedding outbox 索引到 VECTORIZE_MEMORIES 的 per-user namespace，召回优先语义、provider/索引缺失时自动降级 FTS5，与 memo 的「找一找」共用同一套基础设施。
• 自动固化：P0 依赖 Agent 主动调用 remember / checkpoint；后续在会话/工作完成后自动调 LLM 提炼关键决策与教训。
• agent 身份与可观测：source_agent 目前是来源字符串；后续可做 agent 注册与召回命中率/质量度量。

建议的开发顺序

按「投入产出比 + 不阻塞」推荐。已实现：R2（语义搜索）、R3 全部（含触达渠道）、R5（标签补齐）、R6（大型导入导出）、R11（音频文稿阅读）、R1（反向链接回顾）。剩余推荐顺序：

认知地图 / AI 洞察（R2/R3 数据已铺好）→ R4（ASR 转写闭环 + bot 完整通道）→ R7（附件观测）→ R8-R9（E2E 与生态）

理由：

• 认知地图与 AI 洞察站在语义搜索、相关笔记、关系与记忆之上，是「AI native」定位的正面兑现点。
• R4 的 ASR 让「丢音频进库 → 自动出文稿 → 进入已建好的阅读管线」闭环，bot 完整输入通道属体验增强。
• R7-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. 相关笔记已按轻量版（标签+关系）上线；是否升级为语义排序（向量基础已就绪）。