用途：为即将进入 QA 的功能变更编写可执行的验收标准与人工验证计划，让评审者无需询问作者即可对运行中的应用判定通过或失败。自动化测试负责正确性，QA 负责功能级行为。
适用时机：功能变更进入 QA 需要书面验证计划；评审涉及用户可见行为的 PR；事故复盘需要回归检查；发布候选需要切版前冒烟验证。不适用：仅改单元测试的重构、内部命名调整；针对 API 契约的测试应使用契约测试而非功能 QA。
标准格式：每条标准为单一、可独立验证的陈述——Given <起始状态>，when <动作>，then <可观察结果>。避免一条标准合并多个 when 或 then，应拆分。
计划必须覆盖：黄金路径（最常见成功流程端到端）；空与最小状态（零项、一项、缺失可选输入）；边界输入（最大长度字符串、最大数值、unicode、适用的 RTL 文本）；错误状态（网络失败、权限拒绝、校验失败、冲突 409、未找到 404）；并发与顺序（两用户同时操作、与后台任务竞争、变更中刷新）；性能包络（变更需处理的最大现实输入，不出现 UI 卡死或超时）；向后兼容（既有数据、URL、持久化用户偏好继续可用）；遥测与审计（应发出的事件、日志或活动记录）。某节确实不适用时写“N/A: ”，不得静默省略。
证据：每条标准在验证通过时需附证据——UI 行为用截图或短片段，API 行为用复制的控制台/网络输出，遥测用日志片段或活动行，性能标准用计时测量。无证据的“看起来没问题”不算通过。
隔离与跟进：失败标准阻断验收，除非负责人明确豁免并附可跟踪的后续问题；“已知问题”而无链接跟进不算豁免。验证中途新增标准需重新开始整轮验证，部分覆盖会掩盖回归。
交回作者：验证计划分三节返回——Pass（通过标准及一行证据摘要）、Fail（失败标准及精确复现步骤）、Blocked（无法运行的标准及原因）。作者负责将失败转为修复或已接受的延期。
反模式：把验收写成测试计划（如“为 X 写 Cypress 测试”）；依赖实现细节（选择器、查询计划）的标准；无优先级的长清单（应区分必须通过与可选）；只说“通过”而无证据的验证报告。