流程页面模板

发布前QA关卡之所以存在，是因为错误在页面被索引、链接、引用、翻译或在其他回答中被复用后，代价会变得更高。这个关卡不是最终的校对环节。它是一个节点，由一位可问责的负责人验证页面仍与其简报匹配、其证据可核查、各组件满足其合同要求、并且发布结果可以被衡量和维护。本参考文档演示了锁定流程/检查清单模板中的所有十个模块。

阶段： 发布前的最终审核。时间盒： 标准详情页45–90分钟，当专家必须验证法律、医疗、财务、安全或技术声明时适当延长。负责人： 一位未撰写最终草稿且有权限阻止发布的编辑或内容主管。

为什么这个阶段放在这里

制作流程将工作分配至研究、简报、写作、设计、主题审核和实现等环节。每个交接都可能保住了局部质量，却削弱了页面的整体性。作者可能遵循了简报，但使用了过时的证据。设计师可能创建了精美的表格，但其列已不再比较同一维度。实现者可能引入了损坏的链接或格式错误的JSON。发布前关卡将这些输出重新整合，并测试实际的发布候选版本。

它放在内容、组件、证据和专家审核之后，因为QA无法验证尚未完成的工作。它放在发布之前，因为那是修正标题、来源、路由、schema字段、截图或转化路径的最后低成本节点。将QA提前会产生虚假信心；将其推迟到发布之后，则会把可预防的缺陷变成公开事故。

该阶段依赖于已批准的简报，并产生记录在案的发布决策。如果两者缺少任何一项，检查清单就变得主观：审阅人会争论品味偏好，因为目标读者、页面职责、证据标准和完成条件从未被确定。

输入与输出

输入和输出使该阶段可审计。输入是审阅人评估候选版本所需的材料。输出是他人无需重复整个审核即可使用的证据。

QA输入与输出

输入不仅仅因为文件存在就被接受。简报必须描述此页面，证据登记表必须覆盖实际存在的声明，专家批准必须引用正在发布的候选版本。

检查清单

顺序可以降低返工。先检查页面目的，再润色句子；先验证证据，再处理样式；先审查结构，再检查链接；先确认实现，再做最终发布决策。序列早期出现的失败可能使页面返回到制作阶段——如果页面的意图和比较框架本身就是错的，那么精修替代文本没有任何价值。

1. 1
   1. 匹配简报

   内容：将候选版本与已批准的目标读者、意图、页面类型、必需模块和结果进行对比。原因：一个制作精美但解决错误问题的页面不应发布。方法：将每项需求追溯到一个可见章节或已批准的例外情况。工具：简报和渲染后的候选版本。完成条件：每个必需模块都有对应位置，开头回答了所指定的需求。
2. 2
   2. 验证声明与范围

   内容：检查事实声明、日期、单位、版本、方案、市场和限制条件。原因：未经支持或过于宽泛的声明会损害信任，并且可能在脱离上下文的情况下被提取使用。方法：将正文与证据登记表和原始来源进行比对。工具：证据登记表和来源页面。完成条件：每个实质性声明都得到支持、限定，或被移除。
3. 3
   3. 测试信息结构

   内容：检查标题层级、直接回答、表格、步骤、提示框和CTA位置。原因：每个元素都有其语义职责，顺序传达了依赖关系。方法：先单独阅读标题，然后扫描组件（不看周围正文）。工具：渲染后的页面。完成条件：页面在两次浏览中均可理解。
4. 4
   4. 验证链接与媒体

   内容：打开内部链接、外部证据、应用深度链接和每个被引用的资源。原因：一个看似合理的路径仍可能已失效、被重定向、设为私密或不相关。方法：将锚点与前部数据记录对比，并检查每个最终目的地。工具：浏览器和仓库路径。完成条件：目的地存在且匹配意图，图片具有准确的替代文本和尺寸。
5. 5
   5. 检查元数据与结构化内容

   内容：验证标题、描述、关键词、日期、关联字段、链接记录和FAQ一致性。原因：元数据驱动着发现、模板、关系以及机器可读的表示形式。方法：将前部数据与渲染后的页面和内容合同进行对比。工具：源文件和预览。完成条件：字段有效，描述具有点击吸引力，可见的FAQ文本与前部数据完全匹配。
6. 6
   6. 审查转化与衡量

   内容：测试下一步操作并记录预期的衡量链条。原因：可见性并不自动等同于有价值的成果。方法：提交或检查CTA，建立基准线，选择观察窗口，并命名决策规则。工具：页面、分析工具和AmICited报告。完成条件：操作正常运作，监控负责人能够解释什么变化会触发响应。
7. 7
   7. 记录发布决策

   内容：标记发布、暂缓发布或已批准的例外情况。原因：未记录的口头决策无法支持问责或事后诊断。方法：将失败项、负责人、证据和截止日期附加到QA记录中。工具：交付追踪器。完成条件：发布者收到一条明确的指令和监控交接信息。

每个条目都包含内容、原因、方法、工具和完成条件，整合在一条记录中。团队可以将这些字段移入追踪器，但不应将条目简化为一个模糊的复选框，例如"SEO已检查"。没有证据的二元标签会在每个页面上引发不同的解读。

AmICited中的工具

最终审核应将页面与发布后将使用的报告相连接。使用AmICited的可见性报告来定义相关的提示组、记录当前的回答和引用来源，并将品牌提及与来源引用区分开。当页面包含有时效性的产品、价格或流程事实并需要审核触发条件时，使用内容新鲜度报告。

打开 https://app.amicited.com/reports/cockpit 记录与页面目标主题相关的基准视图。当维护决策依赖于更新历史时，打开 https://app.amicited.com/audit/freshness。深度链接应作为可执行工具（而非装饰性产品引用）纳入检查清单记录中。

当这些资源存在时，将第一张以大截图形式渲染，第二张使用 workflow-section 渲染，并附上关于该报告如何改变交接流程的简洁说明。在此之前，必需的截图注释可以防止损坏的图片引用。

决策规则

阈值将发现转化为可预测的行动。“需要改进"是不够的；审阅人需要知道哪些失败会阻止发布、哪些可以在同一时间盒内修正、以及哪些例外情况需要批准。

发布决策规则

因此，“不合格"的含义不仅仅是分数不完美。它意味着页面可能误导读者、无法维护、破坏了关键路由、违反了内容合同、或缺少做出预期决策所需的证据。严重失败始终阻止发布。截止日期不会降低严重程度。

交付物模板

QA记录应足够简洁以便完成，又足够具体以便审计。每个发布候选版本使用一条记录：

页面：[规范URL或仓库路径]
发布候选版本：[版本或时间戳]
简报负责人：[姓名]
QA负责人：[姓名]
审核开始/完成：[时间戳]

决策：发布 | 暂缓发布 | 已批准的例外情况

检查项：
- [通过/未通过/不适用] 简报匹配 — 证据：
- [通过/未通过/不适用] 声明与范围 — 证据：
- [通过/未通过/不适用] 结构与元素合同 — 证据：
- [通过/未通过/不适用] 链接、媒体和应用操作 — 证据：
- [通过/未通过/不适用] 元数据、关联和FAQ一致性 — 证据：
- [通过/未通过/不适用] 转化与衡量 — 证据：

例外情况：
- 范围：
- 原因：
- 批准人：
- 修正负责人和截止日期：

衡量交接：
- 预期结果：
- 基准线：
- 观察窗口：
- 决策规则：
- 监控负责人：

不要在证据字段中粘贴"看起来不错”。指向另一位审阅人可以核查的来源、渲染后的章节、已测试的目标地址、截图或已记录的值。

常见问题

其他失败包括：在验证意图之前进行校对；仅检查来源是否存在而不检查来源支持什么；接受不在磁盘上的截图路径；仅测试桌面行为；将重定向链接视为自动正确；让可见的FAQ答案与前部数据偏离；以及在发布后记录衡量数据（此时已无干净的基准线）。

检查清单膨胀是另一种失败。成百上千个权重相同的检查项让审阅人走马观花。将关键决策保持突出，将专家流程移至链接的子检查清单中，并用理由标记不适用项，而不是删除该字段。

下一阶段

下一阶段是发布和初始验证。QA负责人将已批准的候选版本、决策记录、发布窗口、规范目标地址、重定向要求（如有）以及已知的可逆例外情况移交给发布者。发布者确认部署的页面与已批准的候选版本一致，并返回在线URL和部署时间。

之后，监控负责人记录在线基准线，并开始QA阶段定义的观察窗口。使用SEO结果 框架来区分可见性、选择、互动和业务成果。如果部署更改了内容、元数据、路由或组件，则受影响的QA检查项重新开放；批准不会自动转移至一个实质上不同的页面。

• 发布者收到一个候选版本 — 路径或版本与审核批准的文件一致
• 发布条件可见 — 重定向、时间安排、例外情况和回滚负责人随交接信息一起传递
• 在线验证已分配 — 指定人员在部署后确认规范URL、内容、元数据、媒体、链接和CTA
• 监控从基准线开始 — 负责人在解读变动之前，已记录预期结果、观察窗口和决策规则

SEO流程 将发布视为交接，而非工作的终点。只有当发布证据、衡量决策和审核负责人保持关联时，页面才变得可维护。

常见问题

常见问题

学院布局会在末尾附上转化面板。检查清单本身以发布和监控交接结束，因为流程页面应该让操作者进入一个可问责的下一步状态，而不是仅仅看到一份已完成清单。