怎么判断 Gemini API 结论还能不能用

Gemini API 的结论会过期：2.5 Pro 自 12 月 1 日起自动路由到 3.8 Flash 并按新费率计费，官方变更日志 10 天里更新 6 次。（核验 2026-11-05，F30、F60）

一、Gemini API 的结论会过期：问题不是记住多少条事实

假设你三个月前写过一条笔记：Batch 批量接口能降一半成本，并发上限一百。今天要拿它做容量规划，你敢直接用吗？

大多数人会翻回官方页确认一遍。问题是，你真正需要确认的不是「这条还在不在」，而是「它是哪天看到的、从哪个页面看到的、中间官方改过没有」。这三件事如果没记，翻页也补不回来——你只会看到一个今天的样子，无法判断三个月前的判断错在哪。

官方变更日志给了紧迫感：最近一条是 2026-11-05，往前到 10-26 的 10 天里共有 6 次更新，其中 11-02 那条要求在 12 月 1 日前修改模型字符串（F60）。也就是说，「一年复核一次」这种节奏，写完就已经过期。这条结论本身就是复核时抓出来的——上一版写的是「最近两条是 11-04 与 11-02，十天里五次」，重抓原文才看到顶部还有一条 11-05。

所以本教程不给「结论清单」，给一套可执行的机制：每条事实有编号、有具体值、有来源页、有核验日期、有状态。这一节讲的就是这套机制怎么用，以及怎么让它自动拦住你自己。

二、一条 Gemini API 说法能不能溯源：最小可运行示例

机制的核心只有一句话：任何具体值，必须能在原文里逐字找到。 找不到就不是事实，是记忆。

下面这段代码是一个极简版溯源检查，用三条笔记去比对一段模拟的官方原文。

## EXPECT: 可溯源 2/3 | 不可溯源：Batch 并发上限 20
OFFICIAL = ("Batch API offers 50% cost reduction. "
            "Requests are capped at 100 concurrent, input file up to 2GB.")
CLAIMS = [
    ("Batch 降价 50%", "50"),
    ("Batch 并发上限 100", "100"),
    ("Batch 并发上限 20", "20"),
]
def missing(tokens, corpus):
    return [t for t in tokens if t not in corpus]

untraced = []
for text, token in CLAIMS:
    if missing([token], OFFICIAL):
        untraced.append(text)
out = f"可溯源 {len(CLAIMS) - len(untraced)}/{len(CLAIMS)} | 不可溯源：{'、'.join(untraced)}"
assert untraced == ["Batch 并发上限 20"]
print(out)

这段代码故意写得很笨——就是字符串包含判断。它的价值不在算法，而在把「凭印象写的数字」变成一条会当场报错的记录。第三条笔记写的是 20，原文写的是 100，一秒就能看出来。

三、解释与边界：五字段、四档复核、一个禁令

五字段怎么填。 事实基线表的每一行有五个必要字段，编号只作主键，不参与判断。

四档复核怎么分。 不同事实的变质速度不同，一刀切必然要么太松要么太累。

价格那一档排得最近，是因为官方已经预告了 12 月 1 日的模型自动路由与价格切换（F30、F33），F38 则提醒折扣与模型可用性都可能变。区域与合规放半年，是因为那份清单的变化频率明显更低。

一个禁令：待核项不得当结论。 状态为「待核」的条目，正文只允许写「请到官方页复核」，不允许拿它推导任何结论。目前基线里有三条待核：一处官方两页数字互相矛盾，一处 API 版本路径写法不一致，一处网页版许可声明没抓到。这三处的共同点是——官方自己没写统一，我就不替它选一个。

边界在哪。 这套机制只能保证「我写的值在原文里存在」，不能保证「原文本身是对的」，也不能保证「我引用的上下文没被曲解」。所以复核时要连上下文一起看，而不是只比对数字。这一点在见 10.1 拆账单时会再遇到：数字对得上，含义可能完全不同。

四、预期输出与异常分支：三类异常

真跑输出：

可溯源 2/3 | 不可溯源：Batch 并发上限 20

整套门禁跑起来是这样的（2026-11-06 实测，条目数会随新增事实变化）：

事实基线门禁 | 表: 官方事实基线表.md | 基准日: 2026-11-06
  F 条目 62 | 已确认 59 | 待核 3 | 复核计划 4 档
  数字溯源：校验 53 个，未命中 0 个
结果: PASS（0 FAIL）

三类异常，处理方式完全不同。第一类，数字未命中。 说明这个值在原文里找不到，要么换回原值，要么补一条新事实并标来源。我自己在这套机制里就犯过一次：原文只写整数美元，我在基线里多写了两位小数，看起来更精确，实际是自造精度，门禁当场把它抓出来，改回原样才通过。第二类，来源页无本地快照。 这类不是「页面不存在」，而是「本地没存证」——重抓一次，不要下「官方删了这个页面」的结论。第三类，条目到期。 到期不等于错误，只表示「该重新看一眼了」；复核后如果值没变，更新核验日期即可，不新增编号。

还有一个反常但必要的规则：复核后发现值变了，不覆盖旧行，而是新编一个号。 因为旧结论可能已经被别的章节引用，覆盖会让那些引用悄悄变成错的。新增编号、标注替代关系，才是可追溯的做法。

五、判据卡：什么信号说明该复核了

六、来源与核验：官方页与 F 编号

• https://aistudio.google.com/docs/changelog.md（核验 2026-11-05，F60）
• https://aistudio.google.com/docs/pricing.md（核验 2026-11-05，F38）
• https://aistudio.google.com/docs/terms.md（核验 2026-11-05，F59，待核）

本节提到的「三条待核」属于官方文档自身未统一的部分，正文不对其下断言，只标注「请到官方页复核」。复核周期与分档以本教程事实基线表的复核计划为准，那份表随每次重抓更新。

七、动手试：三个可验收练习

1. 把 CLAIMS 第三条的「20」改成「2」，重跑。预期输出是 可溯源 3/3 | 不可溯源：——「2」在 2GB 里作为子串存在，被误判成可溯源。接着把 missing 里的 t not in corpus 换成按词边界匹配 not re.search(rf"(?<![A-Za-z0-9]){re.escape(t)}(?![A-Za-z0-9])", corpus)，重跑，预期输出回到 可溯源 2/3 | 不可溯源：Batch 并发上限 2。验收标准：说清「子串匹配会漏报，词边界更严，但两者都不理解语义」。
2. 给 OFFICIAL 补一句「Priority tier is billed separately」，再加一条声称「Priority 与 Batch 同价」的笔记，重跑。预期输出里可溯源数不变；验收标准是你说清「为什么这条检查抓不住语义错误」。
3. 从本教程任取一条带 F 编号的结论，去官方页找对应原文，逐字比对。验收标准：写下「F 编号、原文片段、是否逐字一致」三列；只要有一列写不出来，这条结论就不能进你的项目文档。