TL;DR
- 54 个主题分别维护 6 个语言版本；内容清单、字段和来源规则由测试统一约束。
- 资料区分官方、实机观察、创作者证据和社区报告，并保留核验日期与适用版本。
- 静态页面、交互工具、地图资源和发布通知需要分别验证；构建成功不等于生产可用或已经被索引。
本文复盘的是独立玩家资料站 WARDOGS Wiki 的实际建设过程。它不是游戏官方站点，也不是 T Salon 的社区产品；我们把它作为一个真实工程案例，讨论不断变化的事实如何被整理、翻译、验证和发布。
游戏 Wiki 看起来像一个内容项目：整理武器、载具、地图、系统要求和玩法，再让搜索引擎找到这些页面。但当资料来自持续更新的抢先体验游戏，真正困难的并不是“写出更多文章”，而是回答四个问题：这句话来自哪里、对应哪个版本、现在还能不能使用，以及其他语言是否同步表达了同一事实。
WARDOGS Wiki 当前为 54 个主题分别维护英语、俄语、德语、巴西葡萄牙语、日语和简体中文版本，共 324 份本地化指南。除此之外，站内还包含结构化物品目录、视频资料、新闻、互动地图以及武器比较、弹药匹配、预算与路线规划等工具。
页面数量增长以后，靠编辑者记住全部边界已经不可行。我们最终做的，是把编辑规范变成数据结构、构建规则和发布检查。
先确定什么可以写，而不是先追关键词
项目早期也从关键词清单出发。但关键词只能说明用户在找什么，不能证明答案是什么。
例如，玩家可能会搜索某件武器的伤害、某辆载具的价格或一次测试的开放时间。搜索需求是真实的，资料却可能尚未公开，也可能只出现在旧测试版本的视频中。如果为了覆盖关键词补出一个确定数字，页面虽然更“完整”，却会让未知信息变成错误信息。
因此，内容系统先定义了来源边界：
| 来源类型 | 可以支持什么 | 必须保留什么限制 |
|---|---|---|
| 官方页面与公告 | 发售、平台、版本和明确公布的功能 | 仍需记录发布日期与适用版本 |
| 当前游戏客户端 | 可重复观察的界面、物品和交互 | 说明观察版本，不能外推未来行为 |
| 创作者视频 | 操作路径、实机画面和特定版本表现 | 区分当前证据与历史证据 |
| 社区报告 | 故障线索和待复现问题 | 不能当作全局状态或官方结论 |
每条结构化资料还会标记可信度：已确认、已观察、多方印证或未验证。缺少证据的字段继续显示为未知，而不是用推测补齐。编辑规范也明确区分官方事实、实机画面、社区观察和未解决的问题。
这套做法带来的直接结果，是页面不一定显得“什么都有”，但读者知道哪些信息能用于当前决策，哪些只是一个历史版本的记录。
54 个主题乘以 6 种语言，靠清单而不是靠提醒
多语言网站最容易出现的情况，是英文页面已经更新，其他语言仍保留旧日期、旧数值甚至相反结论。
WARDOGS Wiki 没有把每种语言当成互不相关的文章集合。项目使用统一主题清单管理 slug、分类、顺序和关键词，并要求六个语言目录都包含相同主题。每篇 MDX 的标题、描述、更新时间、FAQ 与来源字段都要通过 schema 校验；来源必须使用 HTTPS，并来自允许的官方、创作者或社区站点。
这并不能保证翻译天然正确，但它先消除了几类可以自动发现的问题：
- 某个语言缺少整篇内容；
- slug 与主题清单不一致；
- 来源没有核验日期或落在禁止域名；
- 页面标题、摘要或必填字段不符合内容契约；
- MDX 混入系统不允许渲染的组件。
翻译仍需要人工判断。特别是“confirmed”“observed”“historical”和“unknown”这类状态词，如果被翻成程度更强的结论，字段结构一致也没有意义。因此，多语言同步的目标不是六份文字看起来一样，而是六个页面保留同一证据边界。
把当前事实与历史快照分开
抢先体验游戏会不断改变价格、解锁等级、物品表现和可用内容。旧视频可能仍然有研究价值，却不应该继续冒充当前数据。
物品目录因此不只保存名称和数值，还记录观察版本、核验日期、来源类别、可信度以及变更记录。当前官方更新可以覆盖决策字段，旧 Alpha 或 Beta 资料则保留为历史快照。页面会直接告诉读者：某个值是否适合用于当前赛季判断。
这种结构也适用于游戏之外的产品文档。API 版本、模型价格、浏览器兼容性和平台政策都在变化。如果系统只保存“最新答案”，就无法解释一个结论为什么改变；如果把所有旧信息混在正文里，读者又很难判断应该相信哪一段。
版本化内容的关键不是保留所有历史，而是让每条会变化的信息都有时间范围。
静态可索引页面与交互工具要分别设计
站内除了指南，还有武器比较、弹药匹配、配装预算、成长路线、系统检查和后勤规划等工具。它们需要支持分享链接，例如把两件武器或一条路线直接编码进 URL。
一次静态导出中，工具页面直接读取服务端 searchParams，导致 Next.js App Router 无法生成静态页面。单纯取消分享参数可以让构建通过，却会破坏用户已经复制的链接。
最终方案是让服务端先渲染确定的默认状态，页面加载后再由客户端读取查询参数并恢复选择。这样搜索引擎可以获得稳定 HTML，用户打开分享链接时仍能回到原来的比较或规划状态。测试也不只检查“构建命令成功”，而是实际打开导出的页面，确认 URL 状态恢复、站内资源没有 404。
这次问题提醒我们：可索引与可交互不是二选一，但两者通常需要不同的状态边界。
有时页面没有坏，只是资源还没到
互动地图曾出现过“打开以后像是什么都没有”的问题。逻辑检查和浏览器回归测试显示，三张底图能够切换，图片哈希也各不相同；真正的问题是每张底图约 1.9–2.1 MB，网络较慢时首屏会长时间保持空白感。
如果当时直接重写地图逻辑，反而可能引入新的错误。更合理的处理顺序是：
- 检查图片请求是否开始、返回状态和实际体积；
- 验证不同地图是否加载为不同资源；
- 检查切换地图后缩放和位置是否重置；
- 再决定需要压缩、预加载还是补充明确的加载反馈。
工程诊断需要区分“代码没有执行”“资源请求失败”和“资源成功但太慢”。用户看到的结果可能相似，修复方式完全不同。
发布完成，要以生产结果为准
站点同时维护 canonical、hreflang、sitemap、结构化数据和 IndexNow 通知。但这些配置存在，并不代表一次发布已经成功。
当前发布脚本会记录发布前 sitemap，部署后核对生产 revision、关键页面、canonical、重定向和 404 行为，再比较新旧 sitemap 并提交实际变化的 URL。IndexNow 返回接收成功，只能证明通知已被接受，不能证明页面已经被抓取、收录或获得排名。
同样的原则也适用于内容：文件写完、代码提交、部署平台显示成功、生产页面可访问、搜索后台重新抓取，是五个不同状态。只有实际读取生产页面，才能确认用户最终看到了什么。
这次项目真正留下的东西
WARDOGS Wiki 最有价值的部分，不是 324 份本地化指南或更多可索引 URL，而是一套可以继续拒绝错误信息的约束：
- 搜索需求不能替代事实来源；
- 翻译必须同步证据范围，而不只是同步文字；
- 会变化的数据需要版本和核验日期；
- 构建通过不能替代真实页面测试；
- 提交 sitemap 或 IndexNow 不能被描述成已经收录；
- 当证据不足时，“未知”就是正确答案。
这也是内容工程与批量生产页面的区别。前者让一条信息在来源、版本、语言和发布环节都可以被检查；后者只让页面数量增加。
完整项目可访问 WARDOGS Wiki，代码与内容契约保存在 GitHub 仓库。