来源核验与对源复审：AI 内容的事实核查流程

AI 辅助写作把"写出文章"的成本降到接近零，把"写错文章"的风险放大到前所未有的程度：模型会流畅地补全你没给的细节，搜索摘要会悄悄丢掉限定词，而你自己的调研笔记里混着当天的推断。本文给出 GPTMap 编辑部在用的完整流程——三条规定管写作，五步复审管发布——并用一次真实的核验过程（2026-09-02 对 Anthropic 9-01 公告的逐句核对）做实例演示。这套流程的目标只有一个：让文中每句话都能被读者或审稿人指出原文出处。

1. 三条写作规定

规定一：关键事实必须可复现。 正文里的日期、价格、功能细节、公告引语，每一条都要能对应一次可复现的官方来源加载——不是搜索摘要，不是转述报道，甚至不是你自己当天的调研笔记。判据：发布前重抓一次来源，每个关键事实都能在原文里指出来；指不出来就删，或降级为明确标注的传闻。

规定二：不写超出原文的修饰。 来源核实过了，不等于围绕它写的每一句都站得住。三类高频翻车：

• 方向性比较——原文只说免费档是 3 个任务，你顺手写付费档"更多/更宽松"；
• 机制脑补——原文没说结果怎么送达，你写"推送/通知/发邮箱"；
• 细节膨胀——原文说"Gmail 新邮件"，你写成"指定发件人的 Gmail 新邮件"。

这三类读起来无害、像连接性文字，但都是原文没有的断言。判据与规定一同款：每一句描述、比较、解释都要能在原文里指出来。

规定三：参数与枚举值出自当次提取。 写 API 类内容时，正文里每个参数名、每个枚举/档位值，都要能在本次会话抓取的官方文档里指出——提取输出是白名单，不在白名单上的不写。API 演进快、记忆混版率高，这条是防"凭旧版记忆补新版细节"。

2. 一条衍生数字规则

凡是自己算出来的数字——篇数合计、剩余天数、百分比——用命令现场算，不要心算：

# 文章总数（例：本站当日 zh 文件数）
ls apps/web/content/posts/*.zh.md | wc -l

# 剩余天数（例：距某关停日）
python3 -c "from datetime import date; print((date(2026,9,24)-date(2026,9,1)).days)"

引用前口径检查清单：
[ ] 任务集/数据集版本与日期
[ ] 记分口径（partial/strict、无工具/带工具）
[ ] effort 档位与默认值
[ ] 安全防护是否开启、干预如何计分
[ ] 误差范围与试验次数
[ ] harness（评测框架）名称

同一族问题：自指统计必须带 as-of 日期。"本站现有 71 篇文章"这类句子不带日期就是定时炸弹——三个月后它必然变成错的。写成"截至 2026-09-01 有 71 篇"，或者干脆不写总数。

3. 对源复审五步法

发布前的最后一道工序，本质是一个循环而不是一遍检查：

1. 重抓全部来源。本篇用到的每个官方 URL 重新加载并存档；加载不到的，对应事实降级或删除。重抓的意义在于：官方页面会改，你写作当天到发布当天之间，来源可能已经不同。
2. 逐句对照。日期、价格、机制描述、引语，逐条在重抓的原文中指出位置。这一步没有捷径——"感觉看了一遍"抓不住"更宽松""推送通知"这类问题。
3. 跑三类句式扫描。比较级（更多/更快/更宽松/更高）、机制动词（推送/存储/失败/自动）、限定词（指定/默认/自动）。每个命中回原文核对。扫描只是辅助：命中清单是"待核对清单"，不是"错误清单"；把代码块剥出扫描范围，避免缩进误报淹没真问题。

三类风险句式的扫描模式（grep 可直接用）：

grep -nE '(更多|更快|更宽松|更高|更强|更便宜)' draft.md   # 比较级
grep -nE '(推送|存储|失败|自动|同步)' draft.md           # 机制动词
grep -nE '(指定|默认|自动)' draft.md                     # 限定词

4. 修复并重新 diff。用脚本逐文件修复、即写即存——修复脚本半路崩溃会让修复静默丢失；修完重新读 diff，确认修复没有引入新断言。
5. 复跑复审到零发现。修复本身可能引入新问题，所以整轮复审要重跑。连续一轮零发现才放行发布。

4. 实例演示：核验一份真实公告

2026-09-02，本站对 Anthropic 前一日发布的 Claude Fable 5.1 / Mythos 5.1 公告做了完整的对源复审。流程回放：

第一步，重抓 anthropic.com/claude-fable-and-mythos-5-1 与 newsroom 页，确认标题与字节量级一致、发布日期字段为 Sep 1, 2026。第二步，逐句对照草稿里的每条事实——"同一模型两档安全配置""$10/$50 per MTok""缓存读 $0.25/MTok、降 75%""典型负载约 -25%、高 agentic 最高约 -45%""EFS 分阶段、2026 年秋起""Mythos 当前仅限美国组织""effort 默认 Claude Code 为 High、Claude Cowork 与 Claude.ai 为 Medium"——每条都在重抓原文中指出原句。第三步，扫描出比较级命中"更少误报（-60%）"等表述，回原文核对为"cybersecurity false positives 减少 60%"，口径成立。第四步，修复草稿期残留的两处模糊表述（一处把官方"预计"口径写成了确定数，已加回限定词）。第五步，复跑一轮零发现，放行。

这个实例的关键点：全部七条价格与口径事实都指回了同一次可重抓的加载，而流程中真正抓出问题的不是"读一遍"，而是第三步的句式扫描和第四步的重新 diff。

5. 常见错误与排查

• 用"来源是官方的"替代"我看过原文"：官方域名也会被转述者加工；引用链条每多一跳，核验义务就多一轮。
• 核验只做一遍：修复引入新问题、来源当日更新、脚本静默失败——都会让"一遍过"变成漏网。循环到零发现才是放行条件。
• 扫描误报淹没真问题：把代码块、URL、代码注释从扫描范围剥掉；命中按风险排序核对。
• 笔记混当依据：调研笔记里标记清楚"原文说的"与"我推断的"两类内容，写稿时只用第一类。
• 修复不落盘：修复脚本要逐文件即写即存并验证写入成功，修完重新 diff。

6. 下一步

• 本流程在新闻稿上的实战记录：《OpenAI 生态第 42 周速报（2026-08-30 至 2026-08-31）：Assistants API 已关停 / Sol 降价确认 / 转写模型弃用》。
• 发布前完整清单（本流程是其上游环节）：《GPTMap 编辑手册：写一篇高质量 OpenAI 文章的 12 步清单》。
• 基准数字的口径核对（事实核查的近亲）：《怎么读模型发布里的基准对比图：effort 曲线、对数成本轴与安全干预》。
• 已发布文章的持续维护：《GPTMap 文章维护指南：半年重测、版本同步与下架》。