多作者知识库的设定一致性：world-state 模式

一个知识库长到几十篇文章，最大的敌人不是写不出新内容，而是旧文章与新事实打架：选型指南推荐着一个已下线的模型，对比文里的价格和定价页对不上，两篇教程用了同一个 API 的两个版本的参数。多作者会放大这个问题，AI 协作则把它推到极致——每个写作会话都没有共享记忆。GPTMap 用一个叫 world-state 的模式解决这个问题：一份带核对日期的共享设定快照、一套固定的变更传播流程、以及把机器能验证的一致性全部下沉到构建期。本文以本站 78 篇文章的实际运作为例（2026-09-03 核对），拆解这个模式的完整实现。

1. 问题定义：一致性失败的三个层次

• 表层：两篇文章给出不同的数字（价格、日期、版本号）。读者未必记得哪篇对，但一定记得"这个站前后矛盾"。
• 中层：新文章引用旧事实。行业每有事件（改价、下线、新发布），存量文章里所有引用该事实的位置都成了潜在错误点——而且是搜索引擎和 AI 摘要引擎最愿意抓的那种错误。
• 深层：AI 协作会话各写各的。没有共享上下文的两个会话，即使都"忠于官方源"，也会因为各自查证的时间点不同而产出不一致。

三层问题的共同根因：事实没有单一的、带日期的、人人（和每个 AI 会话）必读的存放点。

2. 快照：只记共享事实，必须带核对日期

GPTMap 的 world-state 是一个 Markdown 文件，结构上有四类内容：

1. 核心设定：现役模型家族、每档的定价（含促销价与承诺期限）、上下文与输出上限、协议版本；
2. 状态清单：已下线产品（写文章时别再推荐）、产品侧退役与 API 侧下线的区分、竞品现役速览；
3. 传播规则：改这个世界线的固定流程（下文第 3 节）；
4. 命令化清单：会过时的统计不写数字，写生成命令。

# world-state 快照条目格式（示意）
| 事实 | 当前值 | 核对日期 | 来源 |
| Sol 定价 | $4 / $20 per MTok（促销） | 2026-09-01 | 官方 changelog |

两条格式纪律贯穿全文件：

• 每条事实都能回答"何时核对"：文件头部有"最后核对"总日期，关键变更（如降价、弃用）条目内注日期。这与《来源核验与对源复审：AI 内容的事实核查流程》的"状态断言带核验日期"是同一条纪律在快照层的体现。
• 经验值显式标注：拿不到一手来源的数字（如某些产品内配额）在快照里就标注 (经验值)，各文章引用时继承标注。

3. 变更传播：三步流程与一个判据

事实变更（行业事件或快照纠错）触发固定三步：

1. 改快照——先改事实的存放点，再动任何文章；顺序反了必然漏。
2. grep 受影响旧文——用变更项的具体字面（价格数字、产品名、参数名）搜全库，逐篇同步。判据是推荐语境而非提及：新闻稿和弃用清单里出现旧名字是对的（它们在报道事件），选型表、迁移建议、回退方案里出现才是残留。且按事实类别扫整表，不按行扫——同一张表的姊妹行往往共享同一批事实。

# 事实变更后：找出引用了变更项的所有旧文（例：改价格就搜数字与产品名）
grep -rln '$4 / $20' apps/web/content/posts/
grep -rln 'gpt-5.6-sol' apps/web/content/posts/

3. 同步 living changelog——本站有一篇持续更新的模型更新日志文章，是所有事件的时间线视图；快照改了它不改，时间线就成了假账。

4. 工程护栏：把一致性下沉到构建期

人工 review 兜不住规模化的一致性，机器能验证的就不该留给人工：

• 双向一致性断言：站点导航按大区组织频道，构建期断言"大区必须恰好覆盖全部频道"——只加频道不加大区会直接构建失败。这是故意的：防止结构性遗漏静默通过，等读者撞上死链。
• frontmatter 枚举校验：category、contentType 等字段用枚举限定，写错的文章会被校验拦下（甚至被读取器静默丢弃——所以校验必须在写入路径上）。
• 内链与标题的脚本核验：内链 slug 必须存在、链接文本必须与目标文件标题逐字一致（zh 与 en 各自核对），全部脚本化。

这条的推广原则：凡是机器能验证的一致性，构建期报错优先于人工把关；同时验证脚本自身的输出要交叉验证，避免脚本缺陷伪装成"内容干净"。

5. AI 协作：入口文件就是世界观

AI 写作会话没有跨会话记忆，所以它对世界的全部认知来自三份入口材料：

1. 仓库入口说明：项目定位、硬性约束（纯静态、不直接 push 主分支）、可用命令；
2. world-state 快照：当前事实全集（本文主角）；
3. 流程 skill 文档：把"怎么写一篇、怎么核验、怎么复审"固化成可触发的步骤文档。

这套配置的实际效果可以量化：本站 2026-08-29 至 09-03 连续六天、由不同会话产出的内容批次，跨文章的事实（价格、日期、竞品数据）每批都经逐轮对源复审，复审发现的问题均在发布前修复——一致性不靠会话记得住，靠快照查得到。竞品速览机制是一个具体例子：竞品发布的当日事实进快照，后续对比类文章引用时以快照为唯一入口，不再各自去记。

6. 常见错误与排查

• 快照变成文章索引：把"每篇文章讲了什么"塞进快照——它必然过时，而且没有读者需要它。快照只记共享事实。
• 改文章不先改快照：顺序反了，本次改动的事实来源就散落在文章里，下次无从同步。
• grep 到提及就改：把新闻报道里对旧事件的正当提及也"纠正"了，反而制造错误。
• 手维护会过时的清单：篇数、日期、数量级统计写死在快照或文章里。带 as-of 日期，或改命令化。
• 快照与官方源冲突时迁就快照：以官方为准，改快照，再走传播流程——快照是索引不是权威，权威永远是官方源。

7. 下一步

• 发布前完整清单（world-state 是其上游环节）：《GPTMap 编辑手册：写一篇高质量 OpenAI 文章的 12 步清单》。
• 快照事实的核验流程：《来源核验与对源复审：AI 内容的事实核查流程》。
• 快照变更的落地实例（竞品速览首次启用）：《OpenAI 生态 9-02 速报：Anthropic 发布 Claude Fable 5.1 / Mythos 5.1，基准表含 GPT-5.6 Sol》。
• 已发布文章的维护与退役：《GPTMap 文章维护指南：半年重测、版本同步与下架》。