如何依据官方来源维护产品更新日志

构建更新日志的核心在于一个简单的框架：变更前 → 变更后 → 证据。这有助于将产品的实际变更与公告、复述或个人解读区分开来。

只有当能够记录变更前后的状态、指明受影响的用户群体，并附上官方来源时，才创建条目。如果缺少其中任何要素，应将条目标记为“需进一步核实”，而不是凭猜测填补空白。

按责任归属锁定信息来源

为每个产品整理一份官方页面和渠道的简要地图。不同类型的变更通常在不同的地方得到确认。

• 版本发布和功能——更新专区、发布日志、文档、官方博客或团队频道。
• 价格和限额——定价页面；如果支付细节至关重要，还包括相关条款。
• 使用规则和数据处理的——服务条款、隐私政策、特定功能的单独规则。
• 故障和可用性——状态页面、关于事件的官方声明以及后续的澄清说明。

官方渠道可能会迅速发布新闻，但未必包含所有限制条件。如果帖子称“新功能已上线”，而文档明确了地区、套餐或启用方式，那么包含具体条件的文档才是主要证据。帖子可以作为附加链接保存。

按照“变更前 → 变更后 → 证据”的框架记录

日志中的每一条记录描述一项变更。添加以下字段以便日后核查：

请使用如下记录模板：

• 发现日期： [DD.MM.YYYY]
• 核查日期： [DD.MM.YYYY]
• 生效日期： [DD.MM.YYYY 或 “未注明”]
• 变更前： [来自官方来源的原状态]
• 变更后： [来自官方来源的新状态]
• 受影响用户： [套餐 / 地区 / 账户类型 / “未注明”]
• 条件和限制： [条件、限额、例外情况 / “未注明”]
• 变更状态： [已公告 / 推行中 / 已生效 / 已取消]
• 行动项： [需要检查或修改的内容]
• 证据： “[原文片段]”；[页面截图：日期，网址]
• 原始来源： [官方来源 URL]
• 记录状态： [已确认 / 需进一步核实 / 已被澄清取代]

变更状态回答的是变更本身处于哪个阶段的问题。记录状态则表明你是否有足够的理由信任当前的描述。例如，变更可能是“已公告”，但如果官方来源直接描述了未来条件，记录可以是“已确认”。或者，变更可能是“已生效”，但如果不清楚涉及哪些用户，记录则是“需进一步核实”。

区分事实与推论

一条有价值的记录包含三个层面：

1. 已确认的事实——原文中直接陈述的内容。
2. 工作推论——这对你意味着什么。
3. 待解问题——来源未解释的内容。

假设官方文本提到了一项新设置。事实：“添加了设置”。推论：“需要检查它是否改变了当前的工作流程”。问题：“当前使用的套餐是否提供此功能？”将这些部分分开记录，以免假设看起来像已确认的变更。

独立评论、注释或复述可以提示关注方向。但它们不能证实价格、条件、可用性或事件原因。将这些材料保存在记录的备注中，而在“原始来源”字段中保留官方来源。

在获得澄清后更新记录

公告可能不完整，条件也可能发生变化。不要默默修改过去的表述。创建一条新的关联记录：在其中添加新的核查日期和指向澄清内容的链接。将旧记录的状态保留为“已被澄清取代”。如果变更被取消，在新记录中将变更状态设为“已取消”，并保存取消的证据。

这样，日志中既保留了初始版本，也显示了其不再适用的原因。日志回答了两个问题：目前已知什么，以及这一信息基于何种来源。