A. 商业模型直接杀死它。BYOK + local-first + 无后端 = 收不到订阅费、没有数据飞轮、没法做团队版。Readwise 不会做，因为它要 ARR；Notion 不会做，因为它要把人拉进 Notion 生态。这种产品形态只可能存在于“开发者写给自己用”的语境，不可能撑起公司。
B. 商业玩家必须做最大公约数。Readwise/Cubox/Recall 必须服务 Twitter/Kindle/PDF/Podcast 全场景，做不了“为深度长文阅读者写的偏激工具”。任何大厂做 AI 笔记，被迫往“整页无差别总结”走（Recall 就是范本），因为那才是普通用户能 get 到的价值。
C. 真实用户群 < 1%。会“主动选段 + 写自己想法 + 事后回看”的人本身就是 builder/researcher，而这群人多半已经在 Obsidian/Logseq 里有自己的流程，自己会写脚本——他们不付费，也不接受别人定义的工作流。
D. 最痛的一刀——“捕获摩擦”很可能是个伪痛点。复制 → ⌘Tab → 粘到 Obsidian，3 秒。这个流程对受过训练的深度读者根本不构成“打断阅读流”的程度。“摩擦高”是产品 narrative，不是用户的实际抱怨。InstantNotes 真上手用一周，会发现“按⌥⇧C”和“复制粘贴”在心智负担上几乎没区别——甚至前者更怪，因为要记快捷键。
E. 真痛点在另一端，不在捕获端。用户真正抱怨的从来不是“难记下来”，而是：
- 6 个月后想不起来“那段关于 KV cache 的高亮在哪篇文章里”
- 读新东西时不知道“两年前我对同一主题的判断是什么”
- 几百条 capture 之间的关系塌缩成时间线，没法横向连接
捕获是已解决问题。Retrieval 和 connection 才是市面真空白。
所以 README 那句“AI 前置到阅读现场”很可能就是你自己说的——为 AI-native 而 AI-native。把 AI 套到一个本来已经被复制粘贴解决的问题上。
Granola 选择把产品核心放在“会议”而不是“阅读”，本质上不是因为会议更有趣，而是因为会议更符合早期 AI 产品的商业闭环：痛点更刚、频率更高、付费意愿更强、数据更适合 AI、输出更明确，也更容易进入企业工作流。
阅读时漏掉一点，通常可以回去重读；但会议不一样。
会议里会产生很多高价值信息，比如：
- 决策
- action items
- 客户需求
- 价格异议
- 候选人评价
- 投资判断
- 谁答应了什么
- 下一步谁负责
这些信息一旦没记下来，会后很难完整追溯，也容易影响交付。
所以阅读笔记更像是“提升效率”，会议笔记更像是“防止出错”。这也是 Granola 先切会议场景的核心原因：会议的 ROI 更直接。
Granola 的典型用户是 founders、VC、sales、recruiters、managers 这类人。
这些人每天都在开会，而且每场会都可能直接影响业务结果：
- VC 要记 founder quality、traction、risks；
- sales 要记客户痛点、预算、采购时间线；
- recruiter 要记候选人的强弱项；
- founder / manager 要记团队决策和 follow-up。
这些用户愿意为“少漏事、少整理、少掉链子”付费。
相比之下，阅读场景虽然人群更大，但付费意愿更分散。很多人会说“我想读得更好”，但不一定每天愿意为阅读笔记付钱。
会议天然有开始和结束：
- 日历提醒
- Zoom / Google Meet / Teams 链接
- 明确参会人
- 明确会议主题
- 明确会后待办
所以产品可以自然嵌入用户工作流：开会前打开，会议中随手记几个关键词，结束后 AI 自动补全。
但阅读场景更分散：
- 可能是网页、PDF、书、论文、邮件、微信文章；
- 可能在手机、电脑、Kindle、Notion 里读；
- 没有统一入口，也没有明确结束点；
- 用户还要主动保存、划线、整理、复习。
这导致阅读产品更难养成稳定习惯。
会议会自动产生完整上下文。
Granola 可以拿到：
- 音频
- 转录
- 用户手写笔记
- 会议标题
- 日历信息
- 参会人
- 时间线
- action items
所以 AI 很容易做“补全”。
Granola 的核心不是让 AI 从零总结，而是：用户先判断什么重要，AI 再根据转录把细节补齐。
比如用户只写一句 “pricing concerns”，会议结束后，AI 可以从转录中找出所有和价格相关的讨论，并补成完整笔记。
这比纯 AI 总结更强，因为它不是替代用户判断，而是增强用户记忆。
阅读场景就复杂很多。网页结构、PDF OCR、版权、划线、引用、跨设备同步、知识库整理，都会增加产品复杂度。
会议结束后，用户通常很清楚自己要什么：
- meeting summary
- decisions
- next steps
- action items
- follow-up email
- CRM update
- candidate feedback
- investor memo
所以 Granola 很容易设计模板。
但阅读后的需求很发散：
- 摘要
- 卡片笔记
- 金句
- 反驳观点
- 投资观点
- 论文综述
- 写作素材
- 知识库沉淀
- 原文摘录
这会让产品定义变得更难。阅读不是没有价值，而是输出形态太开放，早期更难聚焦。
会议笔记天然会被分享。
开完会之后，用户经常会把纪要发给：
- 同事
- 客户
- 上级
- 没参会的人
- CRM / Slack / Notion / Jira / Linear
所以会议笔记本身有传播属性。一个人用了 Granola，别人看到纪要，也可能被带动使用。
更重要的是，会议数据可以变成公司资产。公司可以问：
- 最近客户都在抱怨什么？
- sales calls 里最常见的 objection 是什么？
- 产品会议里哪些 feature 被反复提到？
- 项目推进卡在哪里？
- 招聘面试中候选人质量如何？
这就让 Granola 不只是个人笔记工具，而是有机会变成公司 memory / business insight 系统。
阅读笔记则更偏个人知识管理，企业预算更难打进去。
会议笔记市场里，很多工具是让 bot 加入会议，比如 Otter、Fireflies、Fathom 等。
但 bot 加会有一个问题：在客户会议、融资会议、招聘面试里，它可能会让人感觉被监控，破坏会议氛围。
Granola 的差异化在于：不派 bot 进会议，而是像一个增强版私人笔记本。
用户自己写一点，AI 在背后转录并补全。这种体验更自然，也更符合高敏感会议场景。
而阅读笔记市场已经有 Notion、Obsidian、Readwise、Roam、各类浏览器插件，竞争更拥挤，用户迁移成本也更高。
Granola 选择会议，是因为会议同时满足了几个关键条件：
高频、高痛点、高付费意愿、触发器清晰、AI 增强价值明显、数据输入统一、输出模板明确、容易分享、容易进入企业工作流。
而阅读虽然空间大，但问题是：
输入太碎、输出太散、习惯难养、付费意愿不够集中、商业化更慢。
不要只问：“阅读场景有没有需求？”
更应该问：
用户在哪个瞬间最怕漏掉重点？
Granola 找到的是会议里的关键决策和 action items。
如果你做阅读产品，也不要泛泛地做“AI 帮你总结文章”。更好的切入点是一个更痛、更具体的瞬间：
用户读长文、论文、研报时，突然产生 aha moment，但这个想法很快会忘。产品要帮他低摩擦捕捉这个瞬间，保留原文上下文，并区分 AI 总结和用户自己的想法。
也就是说，你的重点不是“总结阅读材料”，而是：
捕捉用户自己的判断力。
语言 / Language：中文 | English
此为 MVP 版本，未来将扩展到系统级选中可入会话、视频时间点标记、图片 OCR 等支持。
InstantNotes 是一个阅读现场的 AI 笔记浏览器扩展：在网页中选中文字，按快捷键捕获到当前阅读 Session；读完后基于这些人工筛选过的内容生成结构化 Markdown 笔记，并复制或导出到你的知识库。
默认 AI 接入为 OpenRouter。捕获内容和设置本地优先保存，项目不自建后端。
阅读网页、文档、技术博客、论文或长文章时，真正有价值的片段和瞬间洞察很容易丢失。不是因为它们不重要，而是因为捕捉、整理、加工并入库的摩擦太高。
传统流程通常是：先高亮或复制内容，再切换到笔记工具，再组织上下文，再事后调用 AI 总结。这会打断阅读现场，也让很多原本值得保留的想法在切换工具之前就消失。
InstantNotes 的目标是降低从“看到有价值内容”到“形成可回顾笔记”的摩擦，让捕捉阅读中的 Aha moment 变成一种轻量、近乎无意识的动作。
主要用户是正在网页中阅读、研究、查资料、看教程、读产品文档或浏览长文章的人。用户不想离开当前页面，也不想为了记录一个想法而打断阅读节奏去打开 Obsidian、Notion、Logseq 或 ChatGPT。
用户愿意做的最小动作是：选中一段文字，然后按一个快捷键。这个动作只表达一件事：这段内容值得被保留、进入当前阅读会话，并在之后交给 AI 处理。
InstantNotes 的核心理念是：把 AI 前置到阅读现场。
它不是“读完之后再整理”，而是“阅读时筛选上下文，读完即得入库笔记”。AI 不应该无差别总结整篇网页，而应该基于用户主动捕获的上下文工作。
一个仍然让人感觉像魔法的最小版本应该做到：
- 网页选区捕获：选中文字后按
⌥⇧C/Alt+Shift+C，内容进入当前 Session。 - 我的想法：按
⌥⇧D/Alt+Shift+D，在当前页面快速记录自己的判断、疑问或 Aha moment。 - 悬浮反馈：页面中有轻量浮球和悬浮窗，显示当前 Session 已捕获数量。
- 打开/收起悬浮窗：按
⌥⇧L/Alt+Shift+L，直接打开或收起悬浮窗。 - 可控预览：长捕获默认截断，单条可展开/收起，也可一键全部展开/收起。
- Session 自动归属：按页面 URL 与时间窗口自动把捕获内容聚合到同一会话。
- OpenRouter 生成：填写 OpenRouter API Key 后读取模型列表，选择模型生成笔记。
- 多种输出：支持精简、正常、详细三档结构化概括，以及不调用 AI 的原文导出。
- Markdown 交付：生成结果可复制，也可导出为
.md文件，便于进入 Obsidian、Logseq 或其他知识库。 - Local-first：捕获记录保存在 IndexedDB，API Key 保存在
chrome.storage.local。
- 界面过于简略，信息层级、交互反馈和视觉完成度仍偏 MVP。
- 概括质量由于自主调用 API，模型不一致会导致质量和结构不一致。
- 目前只支持 OpenRouter，尚未接入更多 Provider 或本地模型。
- 实时 Aha moment 联想，以及「我的想法」与原文内容的结合方式还未做深度优化。
你是我的阅读笔记助手。请只基于下面捕获的 {n} 条网页原文和「我的想法」，生成一份精简的结构化概括。
要求：
- 不要引入未提供的信息
- 不要逐条机械复述
- 保留重要原文含义，也保留我的想法、判断和问题
- 用一句话说明核心内容
- 再列出 3-5 个关键点，只保留最重要的信息
- 输出 Markdown 正文，frontmatter 由工具拼接，不要重复输出
— 用户捕获内容开始 —
{captures}
— 用户捕获内容结束 —你是我的阅读笔记助手。请只基于下面捕获的 {n} 条网页原文和「我的想法」，生成一份正常长度的结构化概括。
要求：
- 不要引入未提供的信息
- 不要逐条机械复述
- 保留重要原文含义，也保留我的想法、判断和问题
- 按主题归纳内容，用清晰的小标题和要点组织
- 如果有「我的想法」，把它自然融合到相关主题里
- 输出 Markdown 正文，frontmatter 由工具拼接，不要重复输出
— 用户捕获内容开始 —
{captures}
— 用户捕获内容结束 —你是我的阅读笔记助手。请只基于下面捕获的 {n} 条网页原文和「我的想法」，生成一份较详细的结构化概括。
要求：
- 不要引入未提供的信息
- 不要逐条机械复述
- 保留重要原文含义，也保留我的想法、判断和问题
- 按主题展开，说明关键信息之间的关系
- 保留值得回看的重要细节，但不要为了变长而重复
- 整理出我的想法、疑问和可以继续追问的方向
- 输出 Markdown 正文，frontmatter 由工具拼接，不要重复输出
— 用户捕获内容开始 —
{captures}
— 用户捕获内容结束 —- KR1：捕捉动作足够简单，选中文字后按一个快捷键即可完成捕获。
- KR2：捕捉过程不打断阅读流，不跳转页面、不打开新窗口、不强迫用户立刻整理。
- KR3：用户能在页面内看到轻量反馈，知道内容已经进入当前 Session。
- KR1：AI 必须基于用户主动捕捉的内容生成笔记，而不是对整篇网页做无差别总结。
- KR2：AI 输出必须清晰、可回顾、可继续加工，并默认使用 Markdown 格式。
- KR3：系统支持至少三种终态生成方式：精简、正常、详细。
- KR4：从触发生成到 Markdown 可复制或导出的延迟足够短，让生成像阅读流程的自然收尾。
- KR1：捕获与生成记录默认存储在浏览器本地 IndexedDB。
- KR2：API Key 存储在
chrome.storage.local，项目不自建后端，不接触用户数据。 - KR3：扩展权限保持克制，只申请实现阅读捕捉、AI 生成与 Markdown 导出所需的权限。
- KR4：未来可扩展到系统级选中入会话、视频时间点标记、图片 OCR、多 Provider 与跨浏览器支持。
npm install
npm run build然后打开 chrome://extensions/，开启「开发者模式」，选择「加载已解压的扩展程序」，加载项目的 dist/ 目录。
首次使用时打开扩展设置页，填写 OpenRouter API Key，点击「读取 OpenRouter 模型」，选择一个模型后保存。
| 快捷键 | 作用 |
|---|---|
⌥⇧C / Alt+Shift+C |
捕获网页选区 |
⌥⇧D / Alt+Shift+D |
记录我的想法 |
⌥⇧L / Alt+Shift+L |
打开 / 收起悬浮窗 |
⌥⇧S / Alt+Shift+S |
打开生成与导出面板 |
快捷键可在 chrome://extensions/shortcuts 自定义。
- 捕获内容默认保存在浏览器本地 IndexedDB。
- API Key 保存在
chrome.storage.local。 - 项目不自建后端，不接触用户数据。
- AI 请求从扩展直接发往用户配置的 OpenRouter。