发布说明与更新日志

发布说明是记录产品变更的、带有日期的第一方文档：发布了什么、影响谁、什么行为发生了变化、用户下一步必须做什么。更新日志是这些条目的按时间顺序集合。这种格式首先是留存工具，其次才是流量资产；客户用它来规划工作并避免意外。

首要规则是后果先于庆祝。版本发布可能让团队兴奋，但读者首先需要知道他们的工作流程、集成、数据、权限、价格或兼容性是否发生了变化。用平实的语言说明后果，然后再解释功能。在 SEO 文章类型 体系中，发布说明属于留存阶段的支持内容；其价值来自永不被悄然重写的永久记录。

它回答的问题

一份完整的发布说明条目回答了当前用户在看到产品变更或遇到不熟悉的行为后提出的问题：

• 什么发生了变化，变更发生在哪个发布日期或版本？
• 该变更是立即可用、逐步推出、处于测试阶段，还是受限于方案、区域、平台或账户类型？
• 谁受到影响，包括管理员、最终用户、开发者、合作伙伴或特定集成？
• 之前的行为是什么，现在有什么不同？
• 用户是否需要迁移、更新设置、重新授权访问、培训同事，还是无需采取任何操作？
• 该变更是破坏性的、已弃用的、可逆的、与安全相关的，还是可能改变已存储的数据？
• 更新后的说明、技术参考、已知限制和支持途径在哪里？
• 读者如何验证新行为在其账户中已生效？

不要让读者通过"改进"“更新"或"优化"等标签来推断影响。“导出已改进"是推广性表述但无法验证。“CSV 导出现在在新增的两列中包含已应用的国家和模型筛选条件；现有列和顺序保持不变"则定义了可观察的变更及其兼容边界。

何时使用此文章类型

当某个事件已发布或具有确定的可获取状态，并且产生了值得保留在产品历史中的用户可见差异时，使用发布说明。搜索意图 通常是导航型或信息型：读者搜索产品名称加上"发布说明”、版本号、已变更的功能、已弃用的功能或陌生的界面标签。不要将此格式用作承诺积压、通用公告推送或任务文档的替代品。

变更不需要新界面才算数。API 行为、保留策略、计算逻辑、身份验证、格式、限制、默认值、计费和可访问性都可能需要条目。没有可观察后果的内部重构则不需要。

最适合的业务类型

排名反映了维护与现有用户的带日期公开契约的必要性。

1. SaaS 。 最适合，因为持续交付的界面、API、权限、集成和方案限制可能在客户访问之间发生变化。条目应包括推出状态、受影响的方案、管理员影响和文档链接。
2. 市场平台 。 价值很高，因为一次发布可能影响买家、卖家、审核员、收款接收者或合作伙伴。需区分不同角色的影响，避免将特定参与者的变更呈现为普遍适用。
3. 电商 。 适用于账户、结账、订阅、退货、会员、配送和商家工具变更。需区分面向消费者的影响与面向运营方或集成方的影响，特别是在支付和订单状态方面。
4. 制造商与工业供应商 。 对于固件、控制软件、联网设备、技术门户和规格修订很重要。必须明确版本、型号兼容性、安全边界和回滚可用性。
5. 金融、金融科技与保险 。 有价值但审查严格，因为计算、资格、披露、身份验证和数据处理变更可能具有监管后果。需记录管辖区域、批准、生效日期和被取代的行为。
6. B2B 服务 。 当服务包含维护中的平台、方法论、数据集、客户门户或标准交付物时选择性地有用。普通的公司新闻属于别处，除非它改变了客户合同或工作流程。

搜索意图

发布说明的需求通常是低量高精度。查询包括产品名称加上"更新日志"“最新版本"“有什么变化"“新仪表盘”、API 版本、更新后引入的错误或弃用日期。搜索者不是在寻求宽泛的产品宣传。他们需要权威的时间戳和足够做出决策的细节。

有用的结果形式以产品 + 版本或日期 + 变更 + 影响开头。将这些事实放在标题、开头摘要、标题和元数据中，无需将每个小条目都推送到独立的可索引 URL。稳定的锚点让支持团队和 AI 答案可以引用一个条目；当发布包含大量迁移工作、特殊需求或多个相关变更时，独立页面是合理的。

发布说明是一个被低估的新鲜度信号，因为它们以实际发生的节奏暴露真实变更。但这并不能证明更改日期以显得活跃是合理的。条目日期、当前文档、产品行为和迁移指导必须保持一致。

页面结构

字数范围用于设置重点，而非配额。保持相同的字段顺序，使读者既能扫描小修复也能扫描破坏性版本。

使用 新增、变更、修复、已弃用、已移除、安全 等稳定标签对变更进行分组，但绝不能让标签替代解释。“修复：导出"不是有用的记录。每个条目必须说明之前的症状或限制、新的可观察状态、影响范围以及任何必需的操作。

必需元素

位置也是风险控制的一部分：在功能庆祝之后才显示的迁移警告为时已晚。

前置元数据与结构化数据

遵循前置元数据规范 。本操作指南页面使用 entity = "post-type-release-notes"。已发布的更新日志应使用稳定的产品和流值，如 entity = "atlas-cloud-release-notes"；单个版本可使用 entity = "atlas-cloud-2026-08"。不要使用活动口号或可变的发布标题作为标识符。

对单个发布说明页面使用 schemaType = "Article"。如果网站将索引作为独立实体暴露，CollectionPage 可以描述该索引，同时每个重要条目保持为可见的带日期项目。仅当 FAQ 可见且受到实现支持时，才添加 FAQPage。不要仅仅因为迁移说明包含步骤就使用 HowTo，也不要因为页面仅修正了措辞就标记产品为新发布。

将发布日期与发布和修改日期分开存储。推荐的字段包括产品、流、版本、状态、releasedAt、平台、方案、区域、受影响角色、breakingChange、actionRequired、deprecationDate、负责人、规范 URL 和文档目标。对于分阶段推出，保留一个发布日期并在可见文案中说明时间窗口。

完整示例

以下虚构示例展示了某个重要版本。它将迁移后果放在功能摘要之前，并使用稳定的版本 URL。

+++
title = "Atlas Cloud 4.8 发布说明 — 2026 年 8 月 27 日"
seoTitle = "Atlas Cloud 4.8 发布说明：导出 API 迁移"
entity = "atlas-cloud-4-8"
keywords = [ "Atlas Cloud 4.8", "Atlas 发布说明", "导出 API v2", "Atlas 更新日志", "导出迁移", "Atlas 产品更新" ]
description = "Atlas Cloud 4.8 新增了保存的导出视图和 API v2，说明了 v1 弃用截止日期，并为管理员提供了经过测试的迁移和验证路径。"
type = "academy"
date = "2026-08-27 10:00:00"
schemaType = "Article"
product = "Atlas Cloud"
version = "4.8"
releaseStatus = "rolling-out"
releasedAt = "2026-08-27"
platforms = [ "web", "API" ]
affectedRoles = [ "工作区管理员", "集成负责人" ]
breakingChange = true
deprecationDate = "2026-10-15"
+++

# Atlas Cloud 4.8 发布说明

Atlas Cloud 4.8 于 2026 年 8 月 27 日开始推出。它新增了保存的导出视图和 Export API v2。工作区成员可以使用保存的视图而无需更改现有导出。使用 API v1 的集成负责人必须在 2026 年 10 月 15 日前完成迁移；此后，v1 导出请求将返回不支持的版本响应。

## 必需操作：迁移 Export API v1

**受影响对象：**向 `/api/v1/exports` 发送请求的集成。仪表盘导出和 API v2 客户端不受影响。

**变更内容：**v2 需要显式的 `format` 值，并在 `data.id` 中返回导出任务标识符。文件列不变，除非保存的视图选择了不同的字段集。

**截止日期：**在 2026 年 10 月 15 日前完成迁移和验证。现有 v1 请求在此之前继续可用。

1. 使用与当前 v1 请求相同的筛选条件，向 v2 端点发起测试请求。
2. 添加必需的 `format` 值，并从 `data.id` 读取任务标识符。
3. 对比新旧文件之间的行数、字段集、时区和已知记录。
4. 仅在对比通过后更新生产环境。保留之前的配置，直到首次计划的生产导出成功。

如果测试不匹配，将生产集成保留在 v1，并将脱敏后的请求 ID、时间戳、时区和字段不匹配信息发送给支持团队。请勿包含访问令牌。

## 新增：保存的导出视图

工作区管理员可以保存一个命名字段、筛选条件、排序方式和文件格式组合。具有导出权限的成员可以复用该视图；保存视图不会授予他们访问原本看不到的记录的权限。

要验证可用性，打开 **导出 → 视图** 并查找 **保存当前视图**。该控件可能在推出期间最多需要三天才会出现。在所有区域的标准版和企业版方案中均包含此功能。

## 修复：CSV 文件中的国家筛选标签

CSV 导出现在在筛选汇总列中使用可见的国家名称，而非内部的两字母值。此变更仅影响汇总标签；筛选记录和现有数据列不变。

## 已知限制

保存的视图尚不能在工作区之间传输。已删除的字段将在下次运行时从视图中移除，导出历史会记录该遗漏。

## 更新后的资源

- Export API v2 迁移指南
- Export API 参考
- 导出权限文档
- 导出故障排除

该示例指出了经过测试的兼容边界，区分了推出和发布日期，并为读者提供了验证访问权限的方法。

设计图库

在每个布局变体中保持相同的事实信息，使设计评审测试的是层次结构而非不同的编辑决策。

质量检查清单

发布说明只有在每条适用陈述都为真时才可发布：

• 标题和开篇指明产品、日期或版本、主要变更和受影响受众。
• 可用性精确：已发布、带时间窗口的推出、测试版、选择加入、方案限制、区域限制、已推迟或已撤回。
• 每条条目解释可观察的前后行为，而非依赖"改进"“增强"或"修复"等词语。
• 新增、变更、修复、已弃用、已移除和安全标签使用一致。
• 破坏性变更出现在推广性好处之前，并说明影响范围、截止日期、失败模式、替代方案、迁移、验证、回滚或支持途径。
• 日期区分发布、出版、实质修改、弃用和移除。
• 版本标识符、端点名称、菜单标签、方案、区域和平台范围已根据已发布状态进行验证。
• 读者能判断是否需要采取行动以及如何确认完成。
• 当前文档反映新行为，并在历史重要时链接回相关版本。
• 截图带有截取日期或版本，并为其显示的控制项或状态提供文字替代。
• 存档提供稳定 URL 或锚点、最新优先浏览以及访问旧条目的方式。
• 前置元数据 FAQ 答案与可见 FAQ 答案完全一致，分析功能区分浏览行为与迁移或产品操作。

常见错误

撰写宣传文案而非记录。“我们激动地改变您的工具体验"延迟了事实的呈现。以发布的行为、受众、可用性和操作为开头；将叙事性内容放在单独的发布公告中。

**埋没破坏性变更。**放在截图和好处之下的迁移截止日期会导致可避免的失败。将警告放在首位，并使其可独立理解。

**到处都将推出称为发布。**如果只有部分账户拥有访问权限，请说明是推出并给出预期时间窗口。当说明描述用户还看不到的控制项时，用户会失去信心。

**使用"错误修复和改进”。**这隐藏了受影响的行为，使用户无法认识到他们的问题已解决。除非安全披露需要克制，否则应说明症状、范围和新状态。

**为新鲜度而移动日期。**打字错误修正不会让旧版本变新。保留 releasedAt，单独记录实质性更正，仅当可见记录发生有意义变化时才使用 lastmod。

**重复当前的说明。**冗长的设置程序会在两个地方产生差异。在发布说明中总结变更步骤，让维护中的文档负责完整的当前工作流程。

内部链接

良好的内部链接 使更新日志成为产品知识的历史层。当过渡解释了行为变更时，从当前文档链接至发布说明。从发布说明链接至用户需要的具体文档、迁移、故障排除、策略或兼容性指导。

对每个实质性变更使用一个规范记录。发布博文、功能页面或支持答案可以引用它；任何一方都不应复制它。存档导航应连接相邻版本和索引页。对于弃用，将旧条目链接到其替代方案，并将迁移指导链接回通知。

如何衡量结果

衡量用户是否找到正确的记录、理解影响、完成所需操作以及减少需要澄清的问题。原始页面浏览量不是目标：一个小修复可能以很少的流量实现其目的。

使用提示词追踪 追踪产品加版本的问题、变更的功能名称、弃用日期和"最新更新"等措辞。使用来源与引用情报 检查 AI 答案是否引用规范条目并保留可用性、影响范围、截止日期和所需操作。AmICited Cockpit 可以将与发布相关的可见性和被引用的 URL 与自然着陆活动和选定的产品事件放在一起查看。

发布前，记录受影响的受众、推出窗口、支持量、迁移基线、目标查询和提示词，以及证明成功的指标。审查：

• 产品、版本、功能、弃用和更新日志查询的展示次数和访问量；
• 正确再现发布日期、状态、兼容性边界和操作的 AI 引用；
• 条目级锚点或页面浏览量，而非仅更新日志索引浏览量；
• 进入更新后的文档、迁移、故障排除或验证路径的点击量；
• 迁移启动、验证完成和遗留使用情况（在隐私安全的遥测条件下）；
• 因范围不明、推出访问缺失或未记录行为导致的支持联系；
• 更正、撤回、后续版本或截止日期变更后的过时答案。

遵循我们如何衡量结果 来区分发现、引用、互动、任务完成、留存和业务成果。在解读变动前标注发布、事件、活动和强制迁移。流量飙升可能表示混淆，而如果引用的答案遗漏了破坏性变更截止日期，则是有害的。

FAQ

常见问题