每天 488 条 AI 新闻，我让一份 Markdown 替我选题
AI 圈每天有多少新内容？arXiv 的 cs.LG 一天挂八十多篇论文，我关注的七个 X 账号出三十多条推，中美科技媒体合起来上百篇。再加上 GitHub trending、几十个公众号、Reddit 的 r/LocalLLaMA——昨天一共 488 条进了我的订阅列表。
我一天读得完 15 条左右。剩下 473 条的结果是：错过 3 条该看的，被 10 条无关紧要的占了时间。
两个月前我不再靠毅力。我做了一把叫 AX 雷达的东西。每天 488 条进，约 15 条出。中间那 473 条，是一份 Markdown 写的编辑策略帮我筛掉的。
线上地址：news.ax0x.ai。源码：github.com/xingfanxia/newsroom。
AX 雷达主信息流：HKR 环 + 日历热力图 + 右侧主题聚类
聚合器不是答案，过滤器才是
热榜、AI Weekly、各种 Telegram 频道——我以前都用过。它们都在做同一件事：把别人的口味聚合成"大众口味"，再把大众口味推给我。
这套逻辑有个根本问题：AI 圈不存在"大众"。
我关心模型底层（架构、推理优化、数据策略）和 Agent 产品设计。聚合器推的是营销公告、融资新闻、创始人金句。一翻开"今日 AI 热榜"，要么是 OpenAI 又出了个消费者功能，要么是某家又融了一轮。真正有信号的那些——一篇 arXiv 小论文换了个想法、一条 X 推披露了内部做法——在热榜上根本排不上。
说白了，聚合器做的是去重加排序，真正缺的是过滤加评分。前者靠流量，后者靠一个明确的编辑判断。
做编辑判断这件事能不能外包给一个数据库热度加权？不能。热度加权筛出来的还是大众口味，而我要的是自己的口味。
488 条进、15 条出：管线长什么样
雷达有四个阶段，每个阶段独立运行、独立缓存：
- Fetcher：50 个信源，按 cadence 分桶拉取（每小时 / 每天 / 每周）。RSS、Atom、RSSHub（这个覆盖了公众号、36 氪、虎嗅、B 站）、arXiv 原生 API、X API v2，加上少量爬虫兜底。每条按
(源 ID, 外部 ID)哈希去重，原始 HTML 写进 raw_items 表。 - Normalizer：清 HTML、提作者、解析时间戳、规范 URL（去 UTM、跟重定向）。产物是干净的 items 记录。
- Enricher：LLM 并行调用，给每条打中英文摘要、三轴标签（能力 / 实体 / 话题）、3072 维 embedding。模型是 Azure OpenAI gpt-5.4 standard。
- Scorer：第二轮 LLM，读当前版本的编辑策略（下一节展开讲），给每条 0 到 100 打分，落进 featured / all / P1 / excluded 四个档。
系统页：43 个信源的运行状态、队列深度与错误日志
每一阶段写自己的表，并按 (item_id, version) 缓存。一条内容 enrich 过一次不重跑；策略改了只重跑打分，不重跑 enrich。省下来的钱是整个系统跑得动的前提。
过去三十天跑了 6.8 万次 LLM 调用，总花费低三位数美金。单人项目的量级，完全可接受。
成本结构也值得说一句：大头是 enrich（占一半左右），其次是 score（三分之一），剩下的 commentary、embed、newsletter 加起来不到两成。embed 看起来多，其实几乎不花钱——text-embedding-3-large 的价格跟文本生成差两个数量级。
用量页：今日花费、月度预算、按任务与按模型的成本构成
最关键的判断：编辑策略必须是人能读的
AI 新闻过滤器的传统做法是：把规则写进 Scorer 的 prompt 里。大多数开源项目都这么干。
这有三个问题：
- Prompt 是黑盒。改了不知道为什么改，A/B 没法做。
- Prompt 不 diff-able。你很难说清 v2 比 v1 严在哪、松在哪。
- Prompt 是一次性的。换了人、换了项目、换了模型，经验全归零。
雷达走了另一条路：编辑策略是一份叫 editorial.skill.md 的 Markdown 文件。600 多行。里面写清楚：
- 角色定义：读者是有行业认知的专业人士，不要喂"ChatGPT 是 OpenAI 做的 AI 工具"
- HKR 评分框架（下一节讲）
- 0 到 100 分的每个区间代表什么、举具体例子（95 到 100 是"每家都要写"，85 到 94 是"必须当天写"）
- 六条硬排除规则：技术门槛过高无上车点、云厂商促销、炒冷饭、科学叠 AI 但跟 Agent / 产品无关、纯营销、零论据观点稿
- 正信号加分（+3 到 +5）：Anthropic 实质更新、国产旗舰模型发布、跨源聚类、第一人称实验、带复现条件的论文
每次改动在数据库留一版（policy_versions 表），Worker 下次打分读当前版本。回滚 = 改一条 SQL。
为什么这个选择重要？它把编辑判断和打分执行分开了。编辑判断是人的活——我能直接看、直接改、和别人讨论。打分执行是模型的活——它读 Markdown、按规则打。两边都能独立迭代。
这种"判断作为人能读的文件"的做法，是这个项目唯一一个我事后觉得必须坚持的设计。所有别的部分都可以换——换数据库、换模型、换前端框架——但如果策略是 prompt 不是 Markdown，整个系统会在 3 个月后变得没人敢碰。
全部流里一条 X 帖子，带"精选理由 / 编辑点评 / 深度解读"三段式评注
HKR：把新闻当文章一样打分
传统的评分是单维度"重要性"。问题是"重要"太模糊——对谁重要？什么意义上重要？
我借了卡兹克写公众号长文的 HKR 框架（Hook / Knowledge / Resonance），迁到了新闻筛选上：
- H — Hook / 有趣：标题或切入点能不能让人想点？有没有悬念、反转、没见过的角度？营销话术不算 hook。
- K — Knowledge / 有料：读完能不能多一个数字、多一种机制、多一个值得验证的说法？
- R — Resonance / 有共鸣：戳不戳身份神经？读者会不会想转给同行？
规则：
- Featured（主推）：三个轴至少中两个
- P1（必读）：三个全中，且分数 ≥ 85
- All（全量可查）：至少中一个
- Excluded（排除）：一个都没中，或触发任一硬排除
这套分解带来的好处是判断路径可解释。打开一篇被选中的文章，右边标着 H ✓ K ✓ R ✗——我马上知道这是一条有 hook 有料但缺共鸣的研究向稿子。打开一篇被过滤的，标着 H ✗ K ✗ R ✗——我不用翻 prompt 猜为什么。
有料无 hook 的稿子不打算让它冲上首屏，但可以沉到"全部"列表里；有 hook 无料的稿子直接排除（那是标题党）；三个都有的稿子直接 P1 置顶。这种分档逻辑写进策略文件，一个礼拜就能调到很稳。
一期 Dwarkesh 播客条目的完整 HKR 拆解与深度解读
Agent 改的是策略，不是新闻
雷达的后台有个页叫"策略迭代"。工作流程是：
- 我每天刷主信息流，给感兴趣的点赞、没意思的点踩、特别好的收藏，可以附一句反馈。
- 攒够一批（比如一周 50 条），去"策略迭代"页点
开始生成新草稿。 - 一个 Claude Agent 起 session，工具只有三个：读当前策略、读一批反馈样本、写新草稿。
- 系统 prompt 限制它：读当前策略 + 读反馈 + 给出最小修改 + 单独列出「没动的地方，以及为什么不动」。后一项是为了防止 agent 过拟合最近的几条反馈，把通用规则改崩。
- UI 里看 diff：绿加红删，改了哪些阈值，加了哪些排除规则，确认 OK 就点"应用"。
- 新版本写进 policy_versions 表，下一轮 Scorer cron 自动用新策略。
这个设计有两个关键点。
Agent 是副主编，不是主编。它不决定策略，它读策略、看反馈、提修改建议。主编永远是我，最后的审核权必须在人这边。这条职责划分在 AI 辅助工作流里非常关键——一旦让 Agent 直接改上线策略，调试成本会爆炸。
策略有版本、有父子关系。policy_versions 表存 parent_version——v7 从 v6 派生，不是从零写。这意味着策略演进有祖谱，出问题能定位到是哪一代开始歪的。这跟 Git 的 commit 树一个道理，只是颗粒度从代码换成了策略文件。
还没解决的三件事
**低粉爆文这条线没通。**X 的 search/all 端点可以按粉丝阈值反查（作者粉丝 < 5 万 + 互动率 > 阈值），卡在 API 套餐的配额上。知乎、即刻、小红书的数据接口不稳定，爬虫兜底还在做。这个功能等通了会非常有用——AI 圈真正的早期信号常常来自三千粉的工程师，不是三十万粉的 V。
**跨源聚类的 UI 还没全接上。**后端在做 0.88 余弦距离 + 48 小时窗口的近重复合并。一条新闻被五家同时报，应该只显示一条、右边标"另有 N 个信源也报道了此事"。但前端的 cluster 徽标还没接，用户暂时看不到去重红利，首屏有时还是能看到同事件多源报道。
**评分校准漂移。**换过一次 Scorer 模型（早期是 Claude Haiku，现在 GPT-5.4 standard），0 到 100 的分布立刻错位了——同策略、同一批稿子，两个模型上的均值差 5 分。换模型必须重新校准整套分数带，这是大部分同类项目会踩的坑。
尾
雷达做了两个月。我读新闻的体验跟之前完全反过来——之前是大量扫、生怕漏掉；现在看 15 条精选，剩下时间能确信没漏掉。
但雷达真正教我的一件事不是过滤，是把编辑判断作为一种可版本化的制品来维护。
以前我凭直觉。"这条有意思"——好，转了。"这条没意思"——划掉。直觉无法 diff，也无法跟别人说清楚。现在我有一份 600 行的 Markdown，写清楚了我为什么点击、为什么划掉、哪些是硬规则、哪些是 bump。跟同行讨论口味，不再是举例子，而是发一个 commit diff。
这种"把直觉固化为文件"的做法，迟早会扩散到别的地方。产品经理的 taste、设计师的判断、编辑的嗅觉——都不是玄学，都是可以版本化的策略文件。雷达只是个新闻过滤器，但做新闻跟做产品没本质区别：判断总是应该能读、能改、能回滚。