观察到的现象
记录很容易，重新进入上下文很难
普通笔记工具把内容按时间保存；当用户隔了几周回来，需要自己重新记起“它和什么有关”。
Flagship Case · 01HCI · AI Product
AI Linked Notes
Grove 语林
记录新内容，也找回被遗忘的笔记
这个 Case Study 记录了问题定义、PRD、交互原型和真实 AI Demo，目标是降低旧笔记的找回成本。
线上可交互 · 真实 AI 检索与判断 · Apple 导入在 Web 中透明模拟
Product evidence
面试官可以直接打开的交付物
竞品分析和 PRD 可免登录查看；交互原型从这里直接打开 Figma，可能需要登录。
- 角色
- Product / UX / Vibe Coding
- 阶段
- Discovery → Live AI Demo
- 平台
- iOS concept · Web demo
- 时间
- 2026 · Flagship case
01 · Problem framing
笔记能保存下来，上下文却会随时间丢失。
主流笔记产品擅长保存、搜索和分类，但“这条笔记为什么和那条有关”仍然依赖用户记忆。 对不熟悉双向链接或知识图谱的普通用户，记录前还要设计结构，会增加额外工作。
用户写下新内容时，需要及时看见那条可能有用的旧笔记。
产品假设
关系建议应该出现在内容形成之后
系统在用户完成一段记录后给出少量、可解释的旧笔记候选，让用户少做一次事后整理。
设计约束
AI 不能替用户决定关系
关联会改变未来检索路径，因此候选必须允许确认、忽略、撤销和手动管理。
02 · Competitive analysis
组织能力越强，用户承担的维护工作也越多。
Opportunity
产品机会是提供低门槛、可解释、可修正的关系建议。
flomo 提供低门槛记录基线，Obsidian 提供持久链接机制。目标产品保留记录的低门槛，同时降低维护关系的成本。
03 · Product strategy
四条原则决定 AI 什么时候出现、能做什么。
记录优先
持续输入时不展开候选；停顿后只露出轻提示，保存后再进入关系确认。
解释比置信度重要
候选理由直接说明“共同提到问卷与访谈”，不显示抽象的 87% 相似度。
关系始终可控
确认、忽略、撤销、添加与移除都在用户手里，并保持双向同步。
提供多种找回入口
搜索、最近、相关笔记和主题共同承担旧内容的找回入口。
04 · Product requirements
PRD 将 P0 范围落实到可验收流程。
P0 · 核心闭环
首次使用与快捷指令导入、记录、AI 关系建议、搜索、主题浏览、关系管理、失败降级。
Non-goals
不以默认知识图谱、复杂数据库或全自动整理作为首版主体验。
验收原则
每条建议可解释、每个关系动作可逆、AI 失败不阻断记录。
05 · A pivotal constraint
Apple 备忘录缺少通用读取接口，导入改用快捷指令。
最初设想是用户授权后直接批量读取备忘录。但 Apple 没有向第三方提供通用的备忘录读取 API；逐条分享又会让迁移成本高到足以劝退用户。
放弃伪授权
不用一个看起来顺滑、实际上无法落地的系统授权页掩盖技术限制。
采用快捷指令批量导入
用户主动选择文件夹并运行导出；产品解释发生了什么，并明确不修改原笔记。
保留“直接开始”
有旧笔记的用户可以更快看到关联效果；新用户也能跳过导入直接记录。
O1 · 从 Apple 备忘录导入 / 直接开始
06 · Interaction design
关系候选在停顿后提示，保存后集中处理。
A3 · 用户主动点击后，才展开关联候选
候选一直展开会抢走输入焦点。输入过程中只在停顿后显示轻提示；用户主动点击或保存后再处理关系。
A1
持续输入
不展示关联卡片，保持写作注意力。
A2
短暂停顿
只出现一条“发现 1 条关联笔记”的轻提示。
A3
主动点击
用户想提前判断时，再展开理由、旧笔记与操作。
A4
保存之后
新笔记保存后，再集中确认、忽略或撤销关系。
07 · Retrieval paths
搜索解决“我知道要找什么”，主题解决“我只记得大概”。
关系需要服务于下一次找回。原型把关系呈现为相关笔记和相关主题，没有使用节点图作为主导航。
08 · Vibe coding & real AI
真实 AI 检索和关系判断已接入 Demo。
Live architecture
Worker 负责安全与校验；BGE-M3 + Vectorize 召回旧笔记，本地规则重排，DeepSeek 最后判断关系并生成理由。
01Embedding
BGE-M3
中文与多语言语义向量
02Retrieval
Vectorize
Top K 相似笔记召回
03Re-ranking
Local scorer
关键词、实体、时间与降级
04Judgement
DeepSeek
关系类型、理由与结构化输出
Model decision record
BGE-M3 负责召回，DeepSeek 只做关系判断。
选择时比较中文语义、JSON 稳定性、延迟和部署复杂度。
@cf/baai/bge-m3
Embedding · 语义召回
为什么选：适合中文和中英混合短文本，1024 维向量可直接接入 Workers AI 与 Vectorize。
未选方案：聊天模型生成向量容易造成索引波动；外部 Embedding 服务还会增加一次网络请求。
deepseek-v4-flash
LLM · 关系判断
为什么选：任务是短上下文中文分类。关闭思考、temperature 0.1，可较快返回稳定 JSON。
未选方案：更大的推理模型无法修复召回阶段的错误候选，还会增加等待时间和调用成本。
输出格式可校验
模型输出经过 JSON Output 与 Zod 校验，前端只渲染稳定的数据结构。
失败仍可继续记录
AI 超时或不可用时自动退回本地评分，不用错误弹窗阻断用户。
09 · Evaluation & prompt iteration
评测重点是控制误推荐，同时守住召回率。
Evaluation principle
错误推荐比少推荐更伤信任。主指标因此同时检查找回、误推荐和空结果，不要求每条笔记都有关系。
V1 · Baseline
只说“保守判断”，仍会放行主题相似和近重复内容。
V2 · Production
加入正向条件、硬拒绝规则和零结果约束，默认只保留一个主要候选。
Same model · Same dataset · Prompt only
只改 system prompt，重新跑同一份开发集
DeepSeek、Embedding、阈值、温度和输出结构均保持不变。
| 指标 | V1 | V2 | 结果解读 |
|---|---|---|---|
| 推荐准确率 Precision@2 | 88.0% | 100% | 只保留高相关候选 |
| 推荐召回率 Recall@2 | 100% | 100% | 收紧规则没有漏掉应推荐笔记 |
| 空结果正确率 | 94.4% | 100% | 无可靠关系时能够停止 |
| 误推荐率 | 5.6% | 0% | 开发集中的错误关联被消除 |
Locked test · 20 cases
V2 确定后只运行一次：推荐对象、空结果与 JSON 结构全部通过，误推荐率 0%，P95 约 3.4 秒。
10 · Product telemetry
用行为数据检查旧笔记有没有被再次利用。
离线评测检查推荐质量；Cloudflare D1 记录从候选展示到旧笔记复用的行为漏斗。
01
选择开始方式
onboarding_path_selected
02
尝试保存
note_save_attempted
03
看到候选
relation_candidate_shown
04
处理关系
relation_action
05
打开旧笔记
old_note_opened
06
真实复用
old_note_reused
Product correction
补齐保存尝试、AI 评估和旧笔记打开等分母事件；“打开”和“成功复制正文”分开记录。
Privacy boundary
ID 在 Worker 中哈希；正文、搜索词、IP 和 User-Agent 不入库。目前只能证明指标可计算，还没有足够真实用户样本。
11 · Retrospective
复盘
复盘同时检查项目执行和产品方案。执行问题集中在 Apple 导入和视觉验收；产品落地后还会面对冷启动、关系过期、同步和隐私问题。
哪里做得好
范围
真实产品和作品集 Demo 分开说明
PRD 保留完整产品范围；Demo 明确标注 Apple 导入为受 Web 权限限制的模拟流程。
实现
召回、判断和校验分别处理
BGE-M3 召回、规则重排、DeepSeek 判断、Zod 校验。任一 AI 环节失败都不影响保存笔记。
评测
Prompt、数据集和测试结果都有版本
开发集用于修改 Prompt，锁定测试只做最终验收；D1 埋点不保存笔记正文。
哪里做得不好
产品调研
Apple 导入约束发现得太晚
PRD 和 Figma 先按直接读取备忘录设计，确认系统权限后又改成快捷指令导入。
设计验收
视觉标准确定得太晚
液态玻璃、手机边框和 Case Study 密度缺少统一基准，几轮修改都依赖目测。
产品目前的缺陷
下面四项在真实落地后仍然存在，需要继续验证和处理。
01
冷启动依赖笔记数量
笔记太少或内容过短时，系统没有足够候选。用户第一次使用可能只看到一个普通笔记工具。
处理方向
达到最小语料量后再启用推荐，并用示例笔记帮助用户提前理解关联价值。
02
关系会随着内容变化而过期
笔记被修改、拆分或删除后，已有关系可能失效。当前 Demo 还不会自动重算或提示过期。
处理方向
记录关系的生成时间和依据；正文发生明显变化后重新评估，并保留撤销入口。
03
Apple 导入解决不了持续同步
快捷指令适合首次批量导入，后续新增、修改和删除仍需要用户再次运行。
处理方向
先验证增量导入和重复检测；无法稳定同步时，明确把它定义为迁移工具。
04
云端处理会提高隐私门槛
语义向量和关系判断需要处理笔记内容。对私人笔记来说，用户可能因此拒绝使用 AI 功能。
处理方向
补充清晰授权和数据保留说明，评估端侧 Embedding，并允许关闭云端关系判断。
为什么做不好
01
缺少立项前的技术预检
流程设计开始前没有逐项确认系统权限、数据格式和失败路径。
02
视觉验收停留在主观判断
代表页面、设计 token、同视口截图和通过标准没有一起确定。
针对哪些问题，后续怎么处理
下面四项会作为后续 AI 产品项目的检查顺序。
01
平台约束
立项第一周验证 Shortcuts 权限、导出格式和失败路径，再确认导入流程。
02
视觉验收
先选代表页面，固定设计 token 和截图视口；每轮保存修改前后对照。
03
AI 任务拆分
分别定义召回、规则、模型判断和人工确认的职责，并准备超时与降级方案。
04
上线观测
离线评测检查推荐质量，D1 埋点检查用户是否沿关联打开并复用旧笔记。
下一轮验证
测试快捷指令导入、关系提示的中断感，以及用户是否会沿关联打开并复用旧笔记。
Continue exploring