更新日志：记录变更内容与时间

更新日志是一份关于页面实质性变更的日期记录：变更了什么、为什么变更，以及答案、建议或证据是否发生偏移。

更新日志

2026年8月27日 — 定价与建议已更新
将已停用的 Starter 方案替换为当前的 Essentials 方案，更新了对比表格，并更改了对需要审计导出功能的团队的建议。已根据供应商的方案文档重新核实了来源。

2026年5月12日 — 证据已刷新；结论不变
替换了两条已过时的功能引用，并验证了其余方案限制。推荐选项未发生变化。

每个日期都对应一个可审查的事件。仅写"2026年8月27日已更新"无法解释变更内容；日志揭示了工作的范围及其影响。

为什么这个元素很重要

读者并非对所有变更一视同仁。纠正拼写错误的标题与推翻一项建议、替换一个数据集或修复一条不安全的说明绝不等同。单一的更新日期将这些不同的事件压缩为同一个信号。在用于花钱、执行程序、解读研究或理解政策的页面上，读者需要知道自己所依赖的部分是否发生了变化。

更新日志保存了历史，无需读者自行比较缓存副本。它回答了四个问题：页面是否得到了维护？变更是否影响了我？错误是否被公开纠正？结论是否仍然成立？清晰的答案创造了责任感，并防止了那种仅更新日期而无实质工作的虚假新鲜度。

报告影响，而非活动。“更新了链接"只描述了行动。“已替换撤回的2024年市场总量来源；数值和结论未变"则告诉读者哪些内容仍然可信。如果结论发生了偏移，请如实说明。

机器可提取性意味着软件可以将每个事件分解为日期、类型、摘要、详情、受影响部分和证据引用。稳定的字段让审计能够找到更正，让智能体能够解释变更后的推荐，让迁移能够保留历史。不一致的文字会让软件难以判断事件的起止位置。

因此，该元素的类型化目的优先于视觉上相似的时间线或项目符号列表。请遵循元素编写规则 ：当内容记录的是当前页面的修订时，将其编码为更新日志。渲染器可以使用列表、卡片或可展开的存档，但规范的事件字段必须在每种呈现方式中都得以保留。

何时使用

当读者可能需要对比当前版本和早期版本的页面时，应使用更新日志。触发场景包括：建议变更、事实更正、方法修订、数据集替换、计算方式改变、新版本发布、资格条件变更、定价模型更新、操作说明修改或选项存档。

当权威性随时间积累时，该元素最为有价值。研究可能需要更正分母；文档可能需要支持新界面；法规解读可能需要区分修订案与编辑性澄清。无声的重写会毁掉回访读者所需的历史。

在范围审核后发现无变更的情况下，可谨慎使用复核条目。将其标注为"已审核”，说明检查了哪些内容，并声明结论未变。这适用于波动数据、价格、产品能力或规则；但不得将其用作凭空制造活动的借口。

接近但不适用的情况需要不同的处理方式：

• 发布日期或修改日期： 使用新鲜度标记 来展示规范的页面日期。标记和日志可以协同工作，但两者不可相互替代。
• 产品发布历史或项目时间线： 这些描述的是主题本身的变化。更新日志记录的是对当前页面的编辑变更。
• 版本控制输出： 提交信息包含实现杂项、内部标识符和安全敏感细节。它们不是面向读者的编辑记录。
• 来源列表： 来源区块 证明声明的出处。更新日志则说明这些来源或声明在何时、因何而改变。
• 次要维护： 除非变更改变了含义或可访问性，否则不要记录拼写、标点、格式、图片压缩、分析、追踪参数或模板迁移。

没有实质性修订的页面只需提供发布日期，不需要空白面板或虚构历史。

放置位置

将完整日志放在答案、证据、结论和来源之后，但在相关内容、新闻通讯订阅或结尾行动号召之前。读者首先需要了解当前页面，然后才是其历史。在研究、统计和政策页面上，日志通常位于来源或方法论之后。

如果最新变更影响到页面的阅读方式，请在主导日期旁添加"查看变更内容"的链接并跳转至完整日志。请勿在此处重复条目内容。涉及安全、资金、资格或结论的更正，还需在受影响的声明旁添加说明。

当作者署名与日志各自保持独立时，日志可与作者署名共享同一维护区域。但日志不得放置在购买按钮、限时优惠、倒计时、评分、推荐语或促销徽章旁边；那样会将历史转化为紧迫感或隐含背书。不要将其合并到来源区块中：来源变更的原因是编辑史，而非引用信息。

保留一份规范的日志。侧边栏可以链接到它，但不得复制。超过五条条目后，显示最新的三到五条，并通过"查看更早更新"展开其余内容。将完整历史保留在页面上或稳定的受治理存档中。

结构

1. 元素标题： 使用"更新日志”、“修订历史"或一个在页面设计外仍保持清晰的可批准标签。
2. 事件日期： 显示绝对日历日期，并同时以 ISO 8601 机器时间戳形式暴露同一数值。
3. 事件类型： 区分已更新、已更正、已审核、方法已更改和已归档，不依赖于颜色。
4. 摘要： 用一行简洁的文字说明变更的对象和结果。
5. 详情： 当旧状态、新状态及原因有助于读者理解页面时，予以说明。
6. 受影响部分： 可选择链接到稳定的标题或图表，使用不会被重新利用的片段标识符。
7. 影响： 说明答案、结论、建议、资格条件或说明是否发生了变化。
8. 证据引用： 可选择指向已在页面来源区块中定义的来源标识符。
9. 存档控件： 展示更早条目的同时，不将其从文档或无障碍树中删除。

条目必须在无样式的情况下仍然可理解。图标、线条和颜色不得单独承载类型或影响信息。

设计示例

不同变体反映了信息密度和编辑风险的不同。

紧凑型最新变更行

对于单一简单修订，使用一行紧凑格式。包含日期、类型、摘要和影响。当说明超过两句话时，使用标准列表。

标准修订列表

对于二到五条条目，使用最新优先的列表，字段顺序保持一致。

更正主导变体

对于重大错误，标注为"更正”，显示错误状态和更正状态，说明影响，并链接到受影响部分。在不使用警示性语言的前提下加以强调。

方法或版本变更

当数据集、公式、产品版本、管辖区域或方法发生变化时，显示旧版本和新版本。说明早期结果何时不再具有可比性。

可展开存档

超过五条条目后，用条目数量和日期范围标注存档。保留标题和列表结构，不要让 JavaScript 成为访问记录的唯一途径。

窄视口

在移动端将日期、类型、摘要和详情纵向堆叠。切勿裁剪日期或隐藏影响文本。

参数

父级字段控制集合；重复的子项字段描述每个事件。

条目是重复的项目，而非单个 HTML 字段。父级的首个标题映射为 title；每个项目的首个标题映射为 summary，其余正文映射为 detail。日期、类型、影响、引用和版本保留为属性。

impact 为必填项，以便读者无需自行推断答案是否发生偏移。仅在内容无结论时使用 not-applicable。无编辑的审核使用 type=reviewed 和 impact=unchanged。

语法与代码示例

所有表示形式均保留相同的字段。来源标识符指向规范的来源区块。

可移植 Markdown 指令

:::update-log{order=newest-first visibleItems=3}
## Update log

::item{date="2026-08-27" type=updated impact=changed affectedSection="plans" evidenceRef="vendor-plans"}
### Pricing and recommendation updated

Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.
::

:::

Hugo 短代码约定

{{< update-log title="Update log" order="newest-first" visibleItems="3" >}}
  {{< update-log-item date="2026-08-27" type="updated" impact="changed" affectedSection="plans" evidenceRef="vendor-plans" >}}
  ## Pricing and recommendation updated
  Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.
  {{< /update-log-item >}}
{{< /update-log >}}

这是一个适配约定，而非已有的短代码。每个参数均有命名。

WordPress 块

<!-- wp:amicited/update-log {"title":"Update log","order":"newest-first","visibleItems":3} -->
<!-- wp:amicited/update-log-item {"date":"2026-08-27","type":"updated","impact":"changed","affectedSection":"plans","evidenceRef":["vendor-plans"]} -->
<h3>Pricing and recommendation updated</h3>
<p>Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.</p>
<!-- /wp:amicited/update-log-item -->
<!-- /wp:amicited/update-log -->

WordPress 应为日期、类型、影响、部分和证据提供结构化控件。

示例

良好的更新条目

2026年7月18日 — 计算方法已更正
将"渠道表现"表格中的转化率分母从所有会话更正为符合条件的商品会话。自然搜索的值从3.1%变为2.4%；渠道排名和文章结论未变。底层会话计数不受影响。

之所以有效，是因为它指出了错误、旧定义和新定义、受影响部分、数值影响以及结论状态。读者可以判断早期工作是否需要复核。

糟糕的更新条目

2026年夏季 — 全面刷新！
我们审核了此页面并做了若干改进，以便您可以相信所有内容都是最新的。

这种写法无效，因为日期模糊，“全面"夸大了范围，“若干改进"隐瞒了事实，“相信"则要求读者给予未经证实的信任。如果工作仅为表面性，请删除该条目。如果是实质性工作，请逐一声明所有影响决策的变更。

Schema 标记与无障碍

更新日志没有独立的 Schema.org 类型。它作为内容保留在包含它的 Article、TechArticle 或 Report 之中。最新的实质性事件可以支持 dateModified；无变更的审核不得支持。切勿替换 datePublished。

不要将条目编码为 CreativeWork、Event、HowToStep 或 ItemList；这些类型暗示了日志所不具备的含义。使用可预测的 HTML：标注的区块、列表项、标题、<time datetime="2026-08-27">2026年8月27日</time> 以及稳定的片段标识符。

每个事件使用一个列表项；CSS 可在不改变顺序的情况下绘制时间线。声明条目按最新优先排列。以文本而非仅靠颜色或图标显示类型，并使用描述性链接。

存档需要使用一个带有条目数量或范围标注的原生展开控件。所有条目必须可通过键盘和屏幕阅读器访问。不要使用 ARIA live 区域。保留标题顺序和本地化日期。

在受影响的声明处放置更正说明，并在日志中记录。前者保护当前读者，后者保存历史记录。

编写规则

以变更的对象和精确的动词开头：“资格规则已澄清”、“数据集已替换"或"公式已更正”。摘要控制在4–14个词，详情控制在25–90个词。用一句话说明变更和原因，另一句话说明影响。使用本地化的绝对日期和最新优先的显示顺序。

先解释原因，再说明结果。“供应商已停用 Starter，因此我们将其替换为 Essentials 并重新评估了建议"记录了因果关系；“我们改进了对比"则只是表达观点。使用中性过去时态。

每个实质性条目应回答以下问题：

• 哪些具体的事实、说明、方法、来源、范围或结论发生了变化？
• 变更为何必要？
• 在页面上的哪个位置发生？
• 主要答案、建议或结论是否发生变化？
• 读者是否需要根据早期版本重新执行某个决策或操作？

每个编辑事件创建一个条目，而非每次按键。将一次审核中的相关变更归为一组；将无关的工作、不同影响或不同日期分开。显示三到五条，保留实质性历史。

切勿包含机密说明、安全细节、漏洞、个人数据、责任归属、原始提交哈希值、未说明的工单、营销内容、紧迫性提示或参考文献。切勿承诺"100%最新”、删除更正、无声重写条目或将表面性工作重新标注日期。

如果某条条目需要更正，保留其日期并添加一条更正事件。隐私、安全或法律义务可能证明删减是合理的，请在适当级别说明记录已被修改及原因。

使用此元素的文章类型

postTypes 的 frontmatter 数组是此表格的数据来源。“必需"意味着实质性修订历史是该格式信任契约的一部分；“条件性"意味着日志在发生符合条件的变更后出现。

新页面无需空日志。在发生符合条件的变更后，保留此元素。

QA 检查清单

• 每条可见条目代表一个实质性编辑事件，而非表面性或自动化变更。
• 事件日期精确、有效、非未来，并与已批准的编辑记录一致。
• 摘要指出变更的对象，并控制在4–14个词以内。
• 详情先说明变更内容和原因，再描述好处。
• 条目明确说明答案、结论、建议、资格条件或说明是否发生变化。
• 重大更正也出现在受影响的声明旁边。
• 片段标识符和证据引用指向同一规范页面上的稳定目标。
• 日志位于主要内容与来源之后，但在促销类结尾模块之前。
• 日志未在视觉上与 CTA、优惠、评分、推荐语或来源区块合并。
• 日期使用语义化的 <time> 值；事件类型和影响不依赖于颜色或图标。
• 存档控件可通过键盘操作，标签清晰，并将其完整内容暴露给辅助技术。
• 仅审核的条目不更改 dateModified；实质性最新事件与规范的更新日期一致。
• 不包含机密说明、个人数据、安全细节、原始实现历史和营销语言。
• 页面的文章类型和读者风险证明了该元素的合理性。

常见问题

是否每项内容编辑都应记录在更新日志中？

不。只记录改变事实、说明、证据、范围、解释、建议或读者决策的变更。省略拼写、间距、追踪、模板及其他非实质性编辑。

更新日志与最后更新日期有何不同？

最后更新日期仅说明发生了实质性变更。更新日志则陈述变更内容、变更原因，以及答案或结论是否发生偏移，从而使维护声明可被审查。

最新更新应排在前面还是最旧的排在前面？

对于维护中的页面，应优先显示最新条目，因为读者通常需要了解当前变更。在机器输出中保留时间顺序，当可见列表被缩短时，提供清晰标注的存档。

更新日志能否替代更正声明？

不能。重大错误既需要在受影响的声明处进行显著更正，也需要在日志中永久记录。日志保存历史，不得将更正隐藏在页面底部。

无变更的审核是否应记录在日志中？

仅当审核状态对读者重要，且条目标注为"已审核"而非"已更新"时才记录。说明检查的范围，以及未发现需要实质性变更，且不要更改 dateModified。