Phase 1 X 兴趣推荐 MVP

状态：Phase 1a 产品边界已确认 日期：2026-07-23

本文定义 Phase 1a 的 X 兴趣冷启动、候选获取、每日推荐、Web 反馈和敏感数据边界。它不是浏览器自动化或数据库的完整技术设计，也不等同于当前代码的交付状态；可运行的本地实现、启动方式和已知限制见本地书签工作台运行手册。

一、结论

Phase 1a 先做一个 本地优先的 X 兴趣推荐系统。

它以 data/phase-1a-input/ 中的 X Bookmarks 作为冷启动数据，从已登录浏览器读取候选内容，生成每日推荐，并通过 Web 页面收集反馈，逐步建立可查看、可修正的本地兴趣画像。

决策项	结论
冷启动数据	本地 X Bookmarks，目前为 996 条分类 Markdown。
X 接入方式	不使用 X API，直接操作已登录浏览器。
候选来源	关注账号时间线、已收藏作者、主题搜索，三路都使用。
每日候选	每路各获取 100 条，共 300 条。
每日推荐	去重、过滤和多样性控制后，目标生成 100 条。
交互入口	本地 Web 推荐页，不是联网搜索页。
Feedback	采用独立事件流。
兴趣画像	自动从书签和反馈生成；属于敏感数据，仅本地保存。
每日时间	Asia/Shanghai 20:00；浏览器链路稳定前不创建定时任务。

二、Phase 1a / Phase 1b 拆分

Phase 1a：X 兴趣冷启动与每日推荐

Phase 1a 做：

• 解析本地 X Bookmarks，保留原帖、作者、时间、URL、ID 和已有分类。
• 从书签自动生成兴趣主题、作者偏好、内容形式和语言偏好等初始信号。
• 通过已登录浏览器从三路来源读取候选内容。
• 过滤、去重、排序并生成每日推荐队列。
• 用本地 Web 页展示 100 条推荐、来源和推荐理由。
• 通过 Web 按钮记录用户反馈，并更新本地兴趣画像。
• 保存读取、推荐和反馈历史，支持解释、复盘和删除。

Phase 1a 不做：

• 不使用 X API。
• 不在浏览器中点赞、转发、关注、发消息或修改书签。
• 不接入 Notion、Obsidian、RSS、Newsletter、日程、图片库、理财或聊天记录。
• 不做跨来源统一 Search、Ask、计划建议或高影响自动执行。
• 不对图片、视频做 OCR、视觉理解或视频理解。
• 不默认把书签、兴趣画像、反馈或推荐历史发送给云端模型。

Phase 1b：内容中心扩展

Phase 1a 验证有效后，再考虑：

• 统一搜索本地文件、Obsidian 和 Notion 内容。
• 手动添加链接或文本。
• 接入浏览器收藏、RSS、Newsletter 等其他信息源。
• 增加 Inbox、主题、项目和跨来源视图。
• 引入摘要、标签和关联建议，作为可重算加工数据。
• 在引用准确的前提下探索 Ask。

三、冷启动与兴趣画像

1. X Bookmarks

data/phase-1a-input/ 中的 Markdown 是原始冷启动数据。它已经包含帖子正文、作者、发布时间、原帖链接和 X ID；已有本地分类只作为初始线索，不当作最终兴趣事实。

2. Interest Profile

兴趣画像是可重算加工数据，不覆盖书签原文。它至少包括：

• 主题及其当前权重。
• 作者及其当前权重。
• 内容形式偏好，例如工具、教程、观点、案例、研究或机会。
• 语言偏好。
• 当前兴趣与长期兴趣的时间权重。
• 反馈产生的正向、负向和去重信号。

画像应能回答“为什么推荐这条内容”，也应允许用户查看、修正或删除其结果。

四、每日候选与推荐规则

1. 三路候选池

来源	每日候选	作用
关注账号时间线	100 条	覆盖主动关注的人和其最新内容。
已收藏作者	100 条	放大书签已证明有价值的作者。
主题搜索	100 条	发现新作者、新项目和相邻主题。

主题搜索词由本地兴趣画像自动生成，不要求用户手工配置。

2. 内容准入

• 纳入原创帖和引用帖。
• 默认不纳入普通回复帖；来自已收藏作者或主题匹配很强的回复可例外。
• 中英文内容都可进入候选池。
• 带图片或视频的帖子可以推荐，但首版只使用文字、作者、时间和链接建模，媒体仍在原帖中查看。
• 广告、抽奖、纯转发、正文为空和已展示内容默认过滤。

3. 新鲜度与补足

候选内容先取最近 24 小时；某一路不足 100 条时，依次扩展到 72 小时和 7 天。7 天以上默认不自动补充。

补充的旧内容必须标记为“补充推荐”。已展示过、已标记“不感兴趣”或“重复或已知”的内容不再进入日常推荐。每日 100 条是目标，不为凑满数量降低质量门槛。

4. 生成每日推荐

候选池共 300 条。系统需要：

• 按原帖 ID、URL 和近似内容去重。
• 过滤低质量、无正文和不满足准入规则的内容。
• 结合兴趣画像、作者、主题、内容形式和新鲜度排序。
• 控制单一作者、主题和来源的占比，保留探索内容。
• 输出目标为 100 条的稳定推荐队列，并保留每条内容的来源和推荐理由。

五、本地 Web 推荐页

首个页面是每日推荐页，不预设 Dashboard。

每条内容至少展示：

• 正文、作者、发布时间和原帖链接。
• 来源：时间线、已收藏作者或主题搜索。
• 推荐原因。
• 是否为补充推荐。
• 反馈按钮。

未操作的内容只表示尚未反馈，不计为负反馈，也不要求用户每天标完 100 条。

当前冷启动工作台

在每日候选采集和推荐尚未启用前，Web 首屏是 书签校准，用于浏览本地导入的 X Bookmarks 并收集第一批反馈；它不能伪装为当日新推荐。

• 书签校准：宽屏采用 Sidebar + Workspace + ContextPanel 三栏。用户选中一条书签后，右栏展示该条内容、推荐依据、关联信号和原帖入口；左右侧栏固定在 viewport 内，中间列表滚动时分类筛选条吸顶。
• 兴趣画像：使用 Sidebar + Workspace 两栏，工作区占用原右栏空间；不展示“当前上下文”。
• 运行历史：使用 Sidebar + Workspace 两栏，工作区占用原右栏空间；不展示“当前上下文”。
• 移动端：仅在书签校准页提供“打开上下文面板”入口，并以 Sheet 展示选中内容；兴趣画像和运行历史不显示该入口。

该布局规则只描述当前 Phase 1a 的本地校准闭环。未来的每日推荐、搜索或对象详情页可按是否存在明确选中对象决定是否启用 ContextPanel。

六、Feedback Event

Feedback 独立于原帖和兴趣画像保存。首版标签为：值得关注、想深挖、稍后看、不感兴趣、重复或已知。它们的候选过滤、类别排序增量、90 天衰减和回顾要求，以Feedback 排序规则契约为唯一来源。

每条反馈应带有内容 ID、推荐批次、操作时间和画像版本，确保系统能解释“这次推荐为何变化”。

七、浏览器、调度与隐私边界

1. 浏览器读取

• 使用用户已登录的浏览器会话，不保存密码、Cookie、Token 或浏览器凭证。
• 只读地浏览时间线、作者主页、搜索结果和帖子详情。
• 浏览器登录失效、出现验证码或页面结构变化时，记录失败并停止本次读取，不高频重试。

2. 每日调度

• 目标时间为 Asia/Shanghai 20:00，对应 cron 表达式 0 20 * * *。
• 创建定时任务前必须验证调度宿主机时区和浏览器接入方式。
• 在手动运行已稳定、候选池与 Web 反馈闭环可用前，不创建或启用定时任务。

3. 敏感数据

兴趣画像、反馈、推荐历史和浏览行为共同构成敏感个人数据。Phase 1a 的处理原则：

• 本地保存，可查看、可修正、可删除。
• 默认不进入云端模型。
• 不写入浏览器状态，不向外部服务同步。
• 不把兴趣画像视为对用户人格、健康、财务能力或身份的确定性判断。

八、Phase 1a 成功标准

• 能完整读取并回查本地 X Bookmarks。
• 能自动生成可查看、可修正的初始兴趣画像。
• 能从三路来源各读取候选，并生成可解释的每日推荐队列。
• 每条推荐都可以回到原帖，且显示来源和推荐理由。
• Web 页面能记录 5 类反馈，并在后续推荐中体现变化。
• 运行过程中不改变浏览器中的任何 X 状态，不泄露兴趣画像。

九、当前决策

• 以本地 X Bookmarks 作为兴趣冷启动数据。
• 不使用 X API，直接操作已登录浏览器。
• 每天从关注账号时间线、已收藏作者和主题搜索各获取 100 条候选。
• 每日推荐目标为 100 条，按 24 小时、72 小时、7 天的窗口分层补足。
• 初始兴趣模型自动生成，后续由 Web 反馈校正。
• 每日推荐通过本地 Web 页面操作和打标。
• Feedback 标签为：值得关注、想深挖、稍后看、不感兴趣、重复或已知。
• 兴趣画像属于敏感数据，默认本地保存且不进入云端模型。
• 每日生成时间为 Asia/Shanghai 20:00；浏览器链路稳定前不创建定时任务。

十、下一步

技术方案应围绕以下问题展开：

• 已登录浏览器的只读接入方式。
• X Bookmarks 的解析和本地存储。
• 兴趣画像和 Feedback Event 的本地数据模型。
• 三路候选读取、去重、过滤和排序。
• 本地 Web 推荐页和反馈交互。
• 定时任务启用前的时区、失败处理和审计策略。