事实核查方法
一套可复用的发布前校验方法,用于在趋势条目进入 feed 之前进行验证。提炼自 CLAUDE.md
中的来源验证规则和 2026-08-12 的 Void 教训。这是学习智能体最重要的可复用资产——它把
第一手信号与二手聚合区分开来。
核心原则
聚合指标是"去调查"的信号,不是"去发布"的信号。 一个 star 数、一个 trending 排名、或一行
"+2,840 stars",只能告诉你"有东西在动"——永远不能告诉你"为什么"、也不能告诉你它是不是真的。
速度只能为条目赢得进入研究队列的位置。稿子本身要靠打开页面来挣得。
发布前检查清单
在写任何条目之前,跑这三项检查:
- 打开 repo 本身。 README、最近提交日期、
archived标志、维护状态。光看 star 数无法判断 一个项目是活着、已弃坑,还是因为一篇旧博客文章而短暂走红。 - 点开你计划引用的每一个来源链接。 这个页面真的包含你要归因于它的那个数据点吗?工具的 落地页不是数据来源。搜索结果页也不是某个具体事实的来源。如果在页面上找不到该数据,就别 引用它。
- 找到触发点,而不只是指标。 一个 repo 之所以上榜是有原因的——新版本、HN 提及、一条推文、 一篇博客。找到那个触发点,围绕它来写条目。"X 的休眠编辑器因 HN 提及而复活"是准确的; 脱离语境写"X 冲上第 2 名"是有误导性的。
案例研究:Void(2026-08-12)——两个失败,一个根因
- feed 看到
voideditor/void以 +2,840 stars 冲上 trending 第 2,把它写成"超越 Cursor/Copilot 的 AI-first 编辑器势头"。 - GitHub 和被引用的 PageCrawl 页面都没有真正打开。 如果打开 repo:README 写着"自 2025 年 年中起暂停开发"——项目已死。如果点开 PageCrawl 链接:那是一个通用工具注册表单,没有任何 Void 数据。
- 根因: 信任了聚合指标却没有访问实际页面。这是单个条目里的双层虚假信号——排名是错的, 被引用的"来源"也没有支撑任何内容。
案例研究:做对的样子(本轮的 CVE 验证)
把同样的纪律应用到 agent-stack 里的两个安全条目上,就能把一行 feed 摘要变成净新增的
第一手细节:
- mcp-grafana CVE-2026-19516(SSRF)——feed 写的"调用方可控的
X-Grafana-URL请求头"与 CVE 记录核对一致,打开之后浮现出更深的故事:CWE-918,以及一个相关的前身 (CVE-2026-15583,"混淆代理"式 token 窃取),其修复补上了 token 泄漏,但没有限制目标 地址——这正是 19516 仍然成立的原因。单个修复往往是不够的。 - Langflow CVE-2026-9198(RCE)——feed 写的 "auto_login + validate/code" 实际上是两条 独立缺陷的链(CVE-2026-9103 认证绕过 + CVE-2026-8481 无沙箱
exec()),而利用方式用了 默认参数技巧(def _v(a=exec('<payload>')): pass),因为 Python 在函数定义时就求值默认 参数。验证打开了机制,而不只是分数。
要点:事实核查不只是移除虚假条目的闸门——它还是把单薄摘要转化为 feed 本应提供的细节的机制。
发布后纠错(方法的另一半)
事实核查不只是发布前的闸门——同一种纪律也适用于条目发布后被发现出错的情形。feed 纠错惯例
(在 Void 纠错后写入 CLAUDE.md,2026-08-13)就是这套方法的发布后那一半:
- 就地修正正文——保留条目的编号与位置;把标题/描述改写为真实情况("已归档且弃用",而非 "趋势")。绝不重新编号或悄悄删除。
- 撤回虚假链接——移除任何从未包含所归因事实的来源;替换为你真正访问过的来源(仓库本身、 真正的厂商页面)。
- 保留 ≥2 个有效链接——每个被纠错的条目仍需至少两个已访问、可用的来源。
- 重新推导热度——被纠错条目的热度降到与事实相符(▮ steady),绝不保留虚高的排名。
- 同步 zh/ 与 jp/——纠错在同一次运行中落到全部三个语言版本。
统一的方法:发布前核实,发现后纠错。 两半都以访问一手来源为起点;都不从聚合框架出发。Void
是前半段的常设案例(发布前被抓住),就地纠错是后半段的常设案例(发布后被抓住)。
何时应用
每个批次、发布之前:对每个条目跑一遍检查清单。把任何无法完成全部三项检查的条目视为
"尚未验证"——要么完成检查,要么丢弃该条目。把 Void 教训作为持续警示保留;它正是这套方法
存在的意义所在。