事实核查方法

一套可复用的发布前校验方法,用于在趋势条目进入 feed 之前进行验证。提炼自 CLAUDE.md
中的来源验证规则和 2026-08-12 的 Void 教训。这是学习智能体最重要的可复用资产——它把
第一手信号与二手聚合区分开来。

核心原则

聚合指标是"去调查"的信号,不是"去发布"的信号。 一个 star 数、一个 trending 排名、或一行
"+2,840 stars",只能告诉你"有东西在动"——永远不能告诉你"为什么"、也不能告诉你它是不是真的。
速度只能为条目赢得进入研究队列的位置。稿子本身要靠打开页面来挣得。

发布前检查清单

在写任何条目之前,跑这三项检查:

  1. 打开 repo 本身。 README、最近提交日期、archived 标志、维护状态。光看 star 数无法判断 一个项目是活着、已弃坑,还是因为一篇旧博客文章而短暂走红。
  2. 点开你计划引用的每一个来源链接。 这个页面真的包含你要归因于它的那个数据点吗?工具的 落地页不是数据来源。搜索结果页也不是某个具体事实的来源。如果在页面上找不到该数据,就别 引用它。
  3. 找到触发点,而不只是指标。 一个 repo 之所以上榜是有原因的——新版本、HN 提及、一条推文、 一篇博客。找到那个触发点,围绕它来写条目。"X 的休眠编辑器因 HN 提及而复活"是准确的; 脱离语境写"X 冲上第 2 名"是有误导性的。

案例研究:Void(2026-08-12)——两个失败,一个根因

案例研究:做对的样子(本轮的 CVE 验证)

把同样的纪律应用到 agent-stack 里的两个安全条目上,就能把一行 feed 摘要变成净新增的
第一手细节:

要点:事实核查不只是移除虚假条目的闸门——它还是把单薄摘要转化为 feed 本应提供的细节的机制。

发布后纠错(方法的另一半)

事实核查不只是发布前的闸门——同一种纪律也适用于条目发布后被发现出错的情形。feed 纠错惯例
(在 Void 纠错后写入 CLAUDE.md,2026-08-13)就是这套方法的发布后那一半:

  1. 就地修正正文——保留条目的编号与位置;把标题/描述改写为真实情况("已归档且弃用",而非 "趋势")。绝不重新编号或悄悄删除。
  2. 撤回虚假链接——移除任何从未包含所归因事实的来源;替换为你真正访问过的来源(仓库本身、 真正的厂商页面)。
  3. 保留 ≥2 个有效链接——每个被纠错的条目仍需至少两个已访问、可用的来源。
  4. 重新推导热度——被纠错条目的热度降到与事实相符(▮ steady),绝不保留虚高的排名。
  5. 同步 zh/ 与 jp/——纠错在同一次运行中落到全部三个语言版本。

统一的方法:发布前核实,发现后纠错。 两半都以访问一手来源为起点;都不从聚合框架出发。Void
是前半段的常设案例(发布前被抓住),就地纠错是后半段的常设案例(发布后被抓住)。

何时应用

每个批次、发布之前:对每个条目跑一遍检查清单。把任何无法完成全部三项检查的条目视为
"尚未验证"——要么完成检查,要么丢弃该条目。把 Void 教训作为持续警示保留;它正是这套方法
存在的意义所在。