## 2.1 浏览器看了啥
浏览记录上传 + AI 日报方案
架构总览
Chrome Extension (content.js + background.js)
$\downarrow$ 实时追踪 tab 切换/关闭，计算停留时长
$\downarrow$ 攒到 buffer，每 5 分钟或 20 条批量上传
Supabase (browsing_records 表)
$\downarrow$ 每天 UTC+8 06:00 触发 Edge Function
Edge Function (generate-daily-summary)
$\downarrow$ 读取昨日记录 $\rightarrow$ 调 OpenRouter (Gemini Flash) 生成总结
$\downarrow$ 写入 daily_browsing_summaries 表
$\downarrow$ 调 Notion API 写入 Database
Notion Database (每天一条记录)
content.js 抓取页面正文 $\rightarrow$ background.js 缓存
$\downarrow$
durationTracker 结束计时时 $\rightarrow$ 关联正文内容 $\rightarrow$ 写入 buffer
$\downarrow$
buffer 满 10 条或每 5 分钟 $\rightarrow$ 上传到 Supabase（含完整内容）
每条记录现在包含 9 个维度：
| 字段 | 说明 |
| :------------------- | :------------------------ |
| url | 完整网址 |
| title | 页面标题 |
| domain | 域名 |
| visit_time | 访问时间 |
| duration_seconds | 停留时长 |
| content | 页面正文（最多 10000 字） |
| excerpt | 摘要（200 字） |
| language | zh / en |
| reading_time_minutes | 预估阅读时间 |
### 插件侧：记录机制
content.js:
页面加载 $\rightarrow$ 提取正文内容 $\rightarrow$ 发送 SAVE_PAGE_CONTENT
每 30 秒 $\rightarrow$ 检测鼠标/滚动/键盘是否活跃 $\rightarrow$ 发送 HEARTBEAT（含 scrollDepth）
background.js:
收到 HEARTBEAT $\rightarrow$ 更新 durationTracker 的活跃状态
收到 SAVE_PAGE_CONTENT $\rightarrow$ 缓存内容 + 存本地
durationTracker.js:
tab 切换/关闭/idle $\rightarrow$ 结算记录（含活跃时长、滚动深度、内容）
每 2 分钟检查 $\rightarrow$ 如果仍在活跃看同一页面 $\rightarrow$ 产生分段记录（不漏长会话）
supabaseUploader.js:
buffer 满 10 条 / 每 5 分钟 / 启动时 $\rightarrow$ 上传到 Supabase
## 过审的问题
$\blackcircle$ 坦率说，以目前的形态审核通过的难度较大。主要问题：
高风险点
1. 权限过广
- <all_urls> host permission + content script 在所有页面运行
- tabs + idle 组合 $\rightarrow$ 完整追踪用户行为
- Chrome 对这类「广泛权限」的插件审核非常严格
2. 数据收集量过大
- 提取每个页面的正文内容（10000 字）
- 滚动深度、交互事件数
- 全部发送到远程服务器（Supabase）
- 这触犯了 Chrome 的 User Data Privacy 政策
3. 缺少必要声明
- 没有 privacy_policy 字段
- 没有在安装/使用前征得用户明确同意
- 数据收集没有在扩展描述中充分披露
如果想过审，需要做的改动
| 改动 | 说明 |
| :----------------- | :----------------------------------------------------------- |
| 添加隐私政策页面 | 托管在网上，manifest 加 homepage_url |
| 首次使用弹窗授权 | 明确告知「本插件会收集您的浏览内容和时长」，用户点同意才开始 |
| 在商店描述中披露 | 列出所有收集的数据类型和用途 |
| 数据收集必须 opt-in | 登录 = 同意上传，未登录时只本地存储 |
| 减少不必要的收集 | engagement_events 等行为数据可能被视为过度收集 |
现实建议
如果这个插件只是你自己用，不需要上架 Web Store。直接以开发者模式加载（你现在就是这么用的）完全够了，也没有权限限制。
如果确实想上架（比如给别人用），建议把它改成「用户主动触发记录」模式而非「自动全量追踪」，或者剥离出内容提取功能，只保留 URL +
时长统计，这样过审概率高得多。
## 中文内容
3. 中文版的核心差异点：从“生词”到“上下文”
你之前的英语插件是：
单词 (Word) -> 翻译 (Translation)
中文版（针对母语者或高阶学习者）应该是：
术语/概念 (Term) -> 上下文/出处 (Context/Source)
为什么这是 High ROI？ 就像你说的，你想穷尽你的“单词量”。在中文语境下，这个“单词量”其实是你的知识图谱节点。
看到“熵增”，你知道是物理概念，但在管理学文章里，它代表“组织混乱度增加”。
记录这个词，并记录它是在哪篇文章里被标记的，比单纯记下“熵增=Entropy”更有价值。
总结建议
如果你要做中文版，建议不要复用 CEFR 分级逻辑（A1-C2 对母语者无意义）。
建议的新逻辑：
以“划词”为主，自动高亮为辅：中文边界难定，让用户手动划出“降本增效”比自动切分更准。
利用 Intl.Segmenter 辅助选中：当用户鼠标双击时，利用原生 API 智能扩展选中范围（选中“人工”自动扩展到“人工智能”）。
AI 分析侧重于“概念解释”：每日回顾时，AI 不是生成包含这个词的故事，而是生成这个概念的深度解析或反直觉的用法。
需要我为你写一个基于 Intl.Segmenter 的简单中文分词 Demo，看看它在浏览器里的实际效果吗？