AI 说“完成了”，我应该怎样验收？
把验收写成用户能获得的结果，区分页面、接口和真实业务是否通过。
本页目录
直接回答
验收应围绕业务结果。构建成功只证明构建阶段未失败，页面能打开也不能证明模型、支付或保存有效。一个能发消息却只返回错误兜底的聊天页，核心任务仍未通过。先定义成功和失败时用户应看到什么，再选择必要的单元、集成或端到端检查。
实践建议：分别记录“缺少测试条件”和“测试失败”。前者需补环境或数据，后者需修实现或重新确认需求，两者都不能写成通过。
适用场景
- 准备交付或上线一个 AI 生成的功能。
- 自动测试全部通过，但用户仍然说不能用。
一步一步做
把需求改成可观察行为
写清前置状态、用户动作和预期结果。例如“提交后生成有效图片并能刷新查看”，而不是“按钮可点击”。把内容正确性和外观要求分开，避免只验界面。
覆盖关键异常和边界
至少考虑空输入、无权限、上游失败、重复提交与刷新。选择与功能风险相关的情况，不为简单文案改动堆测试；支付、删除、迁移等行为需要更严格证据。
选择能抓到错误的层次
纯计算适合单元检查；数据库或外部适配衔接适合集成；用户整条路径适合端到端。模拟上游可以稳定测试失败处理，但必须标明没验证真实服务。
修 Bug 先证明能复现
记录修复前现象，必要时加入一条会失败的回归检查。修复后验证原场景与相关调用方。测试应断言用户行为，避免照着当前内部代码写一套必过断言。
把结论和证据一起交付
分别列出通过、失败、未执行，注明环境、测试数据与真实服务范围。没有账号、设备或配置就写具体阻塞，不把未执行默认为通过。
写独立于实现的行为契约，再做红绿重构
先为缺陷写“给定状态→操作→输出与状态变化”，运行一次应失败的检查，确认它因为目标行为未满足而失败，而非缺依赖、语法错误或服务未启动。再做最小实现使其通过，必要时整理代码并重跑相关检查。测试与实现即使分给不同 Agent，也先共享正确业务契约；两人都误解需求时，独立上下文仍可能生成错误的绿色结果。
按边界写用例，而不是搜索源码长什么样
选择区间两侧、恰好边界、非法值、重复请求和无权限等相关场景。假设规则是满100减20、满200减50，应验99/100/199/200，并明确单位、叠加、退款和四舍五入；这是练习契约，不是促销建议。断言优惠金额与订单状态，不搜索源码里是否有某个 if。登录错误的细分应考虑账户枚举风险，不照搬任意状态码或次数阈值。
给每层检查写出它证明不了什么
单元检查计分或额度计算，不证明数据库提交；集成检查数据库与接口，不证明用户看到结果；端到端检查浏览器或真机路径，也不覆盖所有边界。Postman 是工具，真实 API 调用通常是接口或集成测试，不会自动变成单元测试。图片管道、未配置存储、已有类型错误和聊天 fallback 应分别报告：类型失败仍是失败，存储未配仍是未测，出现气泡不证明取得了模型回复。
验收自动检查本身会触发并阻止错误
检查真实修改事件是否触发、工作目录是否正确、测试是否为非持续监听模式、原始失败退出码是否保留。输出经 tail 等管道摘要后，不能以末尾命令成功掩盖上游失败。用可控失败证明门禁会报告失败，再恢复验证成功；手工运行返回0不证明自动触发链可用。Hook 未覆盖的写入、外部依赖和人工交互仍需另验；测试通过也不等于获得部署、真实计费或删除授权。
案例拆解
假设示例：聊天页面的假通过
界面打开、消息出现，只证明交互外壳运行。若回复是网络错误兜底、该触发的图片也没生成，核心功能仍失败。合格验收要看真实回复、触发条件、图片结果以及失败时是否误扣额度。
行动检查
可复制模板
功能验收清单模板
功能：
环境与数据：
前置状态：
操作步骤：
预期用户结果：
成功路径实际结果：
失败/无权限/重复操作结果：
保存与刷新后的结果：
真实服务验证范围：
未执行项及原因：
最终结论：通过 / 部分通过 / 失败。
行为契约与分层验收矩阵
需求/风险 | 前置状态 | 操作与输入 | 应有输出/状态 | 层次 | 真实依赖/替身 | 结果证据
正常：
阈值两侧与恰好边界：
空值/非法值/越权：
重复操作/重试/中断：
部分成功/上游不可用：
换设备/刷新/重启（如适用）：
每层不能证明的范围：
修复前失败原因：
修复后通过证据、版本与时间：
真实服务验收与门禁证据
构建/类型/单元/集成/E2E：分别列通过、失败、未执行。
服务调用：请求标识、测试环境、脱敏响应、预期字段：
结果可用：图片可打开/数据库可回读/权益可使用：
失败路径：提示、保留输入、恢复办法：
替身、fallback、跳过项：
自动门禁触发事件 → 日志 → 原始退出码 → 是否阻断：
受控失败验证/恢复后验证：
未测原因与下一步：
完成声明：只说上述证据支持的范围。
易错点
- 测试比例和覆盖率不是质量保证，不追求没有业务意义的数字。
- AI 自己编写并通过测试仍可能误解需求；关键验收由真实预期约束。
- 不能用“稍后补测试”掩盖当前交付缺口。