复合案例：页面代码已改，为什么仍不能说 QA 通过

复合案例说明：本文由多个常见运营情境抽象重组而成，不对应任何真实品牌、站点、账号或单一项目；名称、过程与数据均为虚拟示意，不可用于反推来源。

直接判断：代码改完与页面修好之间隔着构建、预览、数据、设备、关键路径和发布状态；在没有对应回读前，最准确的状态只能是“本地已验证”。

某虚拟配饰站希望调整产品卡片信息层级，并修复移动端按钮错位。AI 完成局部代码修改，针对性测试与构建都通过。项目记录却没有立刻写“已修复”，因为生产主题并未改变，真实商品数据和移动端交互也尚未验证。

先做判断

团队把完成拆成五层：代码已修改；本地检查通过；未发布草稿预览已生成；人工 QA 通过；生产发布并回读。每一层都需要自己的证据，不能用构建成功替代视觉与行为，也不能用预览替代线上状态。

诊断与决策框架

第一步定义页面契约。要证明的不是“更好看”，而是特定断点下不溢出、真实长标题不破版、变体与价格正确、按钮可点击、键盘焦点可见、关键跳转与加购路径工作。

第二步用真实形态数据测试，但不暴露真实客户或项目。选择长短标题、缺图、多价格、售罄、多变体等边界样本，必要时在隔离环境中脱敏。只用整齐的 mock 数据，会漏掉最常见的生产问题。

第三步区分自动与人工 QA。自动检查负责构建、链接、关键元素和可访问性基础；视觉比较负责断点和布局；人工负责语义、交互感受、触屏操作和业务承诺。三者互补，不能互相冒充。

第四步设置发布闸门。责任人查看同一份预览与 diff，确认影响范围和回退方案后才允许发布。若预览后来重新生成，旧批准失效。

第五步线上回读。发布后重新打开生产页面，检查版本、关键路径与代表性样本。缓存、市场设置或第三方脚本可能让线上结果与草稿不同，因此发布成功提示仍不是最终证明。

常见误判

• 构建通过就宣布视觉与交互 QA 通过。
• 只截桌面首页，不测移动端、产品页、变体和加购路径。
• 用 mock 数据验证后直接发布，忽略真实内容边界。
• 把草稿预览链接当成生产已更新的证据。

验证清单

• 状态明确区分本地、草稿预览、人工 QA、发布和线上回读。
• 测试覆盖关键断点、真实形态边界数据与核心交互路径。
• 自动、视觉和人工 QA 各有明确责任。
• 发布批准绑定同一版本的 diff 与预览。
• 有回退方案，且发布后重新读取生产页面。
• 报告不包含真实站点、账号、截图或可反推业务数据。

适用边界

这个案例适合主题、落地页和组件级改动。小型纯文案修正可以缩短测试矩阵，但仍需确认目标环境；结账、支付、隐私与第三方嵌入等高风险区域需要平台专用检查和更严格批准。

用 人工闸门位置诊断 设计发布批准，再按 安全独立站 AI 工作流剧本 完成从本地到线上回读的完整链路。