把你存过的东西，变成替你认出下一个该看的东西

四个痛点你全中了，而排第一的那个决定了整个方案的方向：不是找不到，是根本不会回去找。

你选的周报主体是「新项目对照我的兴趣」。把它和上面那条痛点拼起来，整套系统真正的产物只有一个：每周那份周报。

一期就是这整张图。关键是右边那条回边——没有它，系统永远停在第一版画像上，推荐不会越用越准。

每条都有原话出处。没写在这里的，就是还没定的（见第 10 节），不要当成已定的需求往下做。

动笔前逐条查了官方文档。其中两条如果不提前发现，做到一半会返工。

X 书签

GET /2/users/{id}/bookmarks · max_results 100 · pagination_token · OAuth 2.0 PKCE

X 可取字段

id / text / created_at / author_id / entities / public_metrics / lang / conversation_id

X 计费

owned reads $0.001 · Post:Read $0.005 · User:Read $0.010

GitHub

/search/repositories 按 created+stars · 认证后 20 次/分钟

周报是这套系统唯一的产物。它的规格就是这个项目的规格——下面每一条都要能直接实现出来。

一份周报由四块组成，顺序固定：

每条推荐包含这些字段，缺一不可：

这一节是整套系统的成败所在。让 LLM 打分，它会给什么都打七分，最后推给你一堆泛泛相关的东西，你看两周就不看了。

三道闸，全过才够格，顺序固定：

判定时喂给模型的是收藏原文，不是画像。

过了硬闸之后才打分，而且必须给分数锚点。没有锚点的打分一定会挤在 70-80 之间。

还要有负面清单，明确写进判定规则：

每条收藏进库后要产出三样东西：标签、一句话摘要、推测的收藏理由。标签体系是重点——它直接决定画像准不准。

标签用「先自由生成、再收敛成词表」。

画像是推荐的唯一判据，但它是 AI 归纳的、必然有偏差，所以必须能看见、能改。

反馈怎么改画像（这是那条回边的具体规则）：

界面长什么样在可点原型里；这里写的是每个界面背后的判断规则，两份对着看。

失败必须分两类：要你动手的，和等系统重试的——这决定你现在该不该起身。

你选了"跑在本机、用本地订阅"，那么整套东西的形态就定了：一个定时触发的脚本 + 一个 SQLite 文件，没有常驻服务、没有数据库服务器、没有容器。

为什么不做常驻服务：

数据存在一个 SQLite 文件里，九张表：

为什么是 SQLite 不是 Postgres：单用户、几百到几千条数据、要跟着 Mac 走。一个文件，拷走就是备份，出问题用任何工具都能打开看。上 Postgres 意味着多一个要照顾的服务，换不来任何东西。

每天那一次的完整流程：下面这张是照着能实现的那版——每步的输入输出、失败往哪走、结果写进哪张表都标了。

七个阶段对应的要点：

一条链路走通：X 书签 → 打标签 → 提炼画像 → 每天扫新项目 → 够格的进周报 → 飞书。

一期做完你就知道这东西对你有没有用。没用就停，成本是几天加不到一美元。

一期几乎零成本，唯一会让它变贵的是待澄清第 1 条。

回填历史书签

约 400 条 × $0.001 = 不到 $1，一次性

日常增量

每天几条，一年不到 $2

打标签 / 摘要 / 打分

$0，走你的 claude / codex 订阅

GitHub

$0，公开接口免费

部署

$0，跑在你自己的 Mac 上

「关注的人在聊什么」

每天 200 条 ≈ $30/月 —— 是上面全部加起来的几十倍，待定

把做不了的划掉，比把能做的说满更有用。下面这些不是「以后补」，是这一期里界面上根本不会出现的东西。

这五条我没有替你假设答案。第 1 条最该先定，它决定这个项目是「几乎免费」还是「每月一顿饭钱」。

这三件我做不了，得在开工前备好，否则长任务会卡在权限上。