交接前如何审查 Confluence 需求文档的版本变更
比较 Confluence 同一页面的两个已发布版本，检查权限、数值与验收条件的变化，并在交给开发和测试前留下清晰的评审记录。
在需求交给开发和测试之前，先把当前文档与团队上次确认的版本进行比较，再把权限、数值和验收条件的变化逐项记入交接记录。只重读最新页面，很容易看见新要求，却漏掉已经删除的要求。版本对比能帮助定位这些变化；是否接受变化、需要调整哪些实现和测试，仍要由团队确认。
例如，一份报表导出需求只改了几个地方：编辑者也能导出，下载链接从一天延长到三天，最大行数翻倍，开放范围却缩小到试点工作区。如果开发和测试沿用旧理解，即使大家都看过最新页面，也可能交付出不同的结果。
本文使用 Confluence 开发环境中的虚构页面 Report Export — Handoff Requirements，比较同一页面的两个已发布版本。配图展示真实的文本与表格对比结果，并保留英文界面。本文由 Page Compare 的开发者 BlueGrove Labs 编写；该应用在 Marketplace 的名称为 Compare Any Two Pages – Visual Diff for Confluence。
1. 选择团队上次确认的版本
比较的起点应当是上次讨论、估算或编写测试计划时使用的版本。它可能比当前页面早好几个版本，并不一定是紧邻的上一版。
本例以 v1 作为交接基准，v2 作为待评审版本。这里比较的是两个已发布的 Confluence 页面版本，不涉及编辑器里尚未发布的草稿。
开始前，在评审记录里写清楚三件事：页面名称、基准版本、待评审版本。即使评审过程中又有人更新页面，大家也知道本次讨论针对哪一组内容。
2. 选择适合的比较方式
Confluence 自带的 版本历史（Version history） 可以比较同一页面的不同版本。对于一次简单的文档检查，这可能已经足够。打开页面的版本历史，选择相关版本并查看差异即可；具体控件以当前站点界面为准。参见 Atlassian 的页面编辑与版本历史说明。
本文使用 Page Compare，是为了在统一视图与并排视图之间切换，并用固定版本的比较链接保留讨论上下文。如果原生比较已经满足团队需要，同样可以在那里使用下面的审查方法。
3. 用统一视图检查措辞和删除内容
已安装应用时，可以从当前页面开始：
- 打开需求页面右上角的 更多操作（•••），在 Apps 分组中选择 Compare this page；部分界面会直接显示该入口。
- 保留两侧预选的当前页面，将 Before 改为 Version 1。
- 本例的 After 保持 Latest version · v2。点击 Compare 后，核对结果表头实际显示的是 v1 → v2。后续页面更新时，以表头中的数字版本为准。
- 选择 Unified，阅读同一上下文中的新增和删除内容。
查看清晰原图（在新标签页打开） 第一项验收标准原本是：
Workspace admins can export a report.
v2 在管理员之后增加了 and editors。这会扩大可使用导出功能的角色范围，需要确认权限规则和测试是否一并更新。
第二项将下载链接有效期从 24 小时改为 72 小时。负责过期逻辑和边界测试的人，需要明确采用哪个值。
第三项更容易被忽略：“每次导出后发送确认邮件”整条要求消失了。 只阅读 v2，看不到它曾经存在。差异能指出删除，但无法说明作者的意图：这是有意取消，还是编辑时遗漏？交接前应向需求负责人确认。
4. 用并排视图核对数值与范围
切换到 Side by side，把 Before 与 After 的完整表格放在一起看。
查看清晰原图（在新标签页打开） 表格中有两项业务变化：最大导出行数从 5,000 增加到 10,000，适用范围从 All workspaces 收窄为 Pilot workspaces only。文件格式仍是 CSV，本次修订没有提出新增格式。
适用范围需要和前面的角色变化一起读：能导出的角色增加了，能使用功能的工作区却减少了。 如果只改权限判断，漏掉试点范围，或者只安排容量测试，漏掉非试点工作区的访问测试，都可能误解这次需求。
工具栏统计的是差异标记，一次替换可能包含旧值删除和新值添加两个标记。业务变化应当单独记入下方的评审记录。
5. 记录交接前需要确认的决定
本例有五项业务变化，可以用一张小表把它们转成待确认事项：
| 业务变化 | 交接前需要回答的问题 | 应留下的记录 |
|---|---|---|
| 管理员 → 管理员及编辑者 | 编辑者的导出权限是否与管理员一致？ | 确认权限规则及对应测试。 |
| 链接有效期 24 → 72 小时 | 实现和过期边界测试是否都采用新时长？ | 记录需要同步调整的开发与测试工作。 |
| 删除导出确认邮件 | 是否有意取消这项要求？ | 记录需求负责人的明确答复。 |
| 最大行数 5,000 → 10,000 | 新上限以及超出上限时的行为是否明确？ | 记录边界、超限行为和验证事项。 |
| 全部工作区 → 仅试点工作区 | 如何识别试点工作区？由谁维护？ | 写明筛选规则和负责人。 |
这张表里的问题还没有被解决。将答案记录在页面评论或团队现有评审记录中，附上页面名称、双方版本号、评审人、日期和未决事项。如果讨论后又发布了新版本，应检查新的版本对比，再完成交接。
Page Compare 只读展示比较内容，不会替团队修改需求、作出审批决定或回写页面。业务结论应当留在团队实际使用的协作流程中。
6. 分享本次讨论的版本组合
确认结果表头的 Before、After 版本后，使用工具栏中的 Share comparison 复制比较链接，并附到交接记录中。链接包含本次实际比较的数字版本和阅读模式；即使最初选择的是 Latest，分享链接也不会随之后的页面更新自动前进。接收者仍需有权访问相关内容，链接本身不授予权限。具体操作见比较结果与分享说明。
固定版本链接有助于重现讨论上下文，但它不是永久归档，也不等于审批记录。团队仍需单独保存决定，并在需要时完成既有审批流程。
交接是否准备好，取决于变化后的预期是否明确、待处理问题是否有负责人。把关键措辞、旧值和新值放在一起，能让这场讨论更具体。
如需复现本文的比较操作，可查看 Page Compare 使用文档。