“已完成”不等于“已验证”

AI 工程里，"代码完成、测试通过、可发布、已部署、生产可用、持续健康"是六个不同的结论。每个结论都需要绑定目标版本、环境、身份权限、样本、验证方法和未覆盖边界。低层检查、单次成功或健康接口，不能替代真实业务、生产观察和恢复能力证据。

六个结论，不能互相替代

结论	可以说明	不能自动说明
代码完成	实现已落到指定工作树或提交	已构建、已测试、已发布
测试通过	指定版本在列出的检查、环境和样本下满足断言	未列出的真实链路、角色和长期质量
可发布	发布前检查、产物标识、风险与回滚准备已满足	已部署或生产流量正常
已部署	指定产物和配置已进入目标环境	入口已切流、用户流程可用
生产可用	生产入口、关键依赖和本批用户流程在指定时间点通过	所有用户、所有能力、未来持续健康
持续健康	约定窗口内错误、延迟、费用、资源和用户结果在范围内	永久不退化、无需再次验证

证据支持的是具体声明，不是笼统的"完成"。类型检查通过只能支持可分析性，Mock 通过只能支持模拟条件下的前端行为，生产健康只能支持服务存活。

证据必须绑定对象和范围

一次验证要能成立，至少回答九个问题：

1. 验证对象：测的是源码、提交、镜像、模型、Prompt、配置、迁移，还是生产实例？
2. 声明：这次要证明的是正确性、兼容性、性能、费用、部署，还是恢复能力？
3. 环境：本地、Mock、测试环境、canary、蓝绿槽位，还是生产？
4. 身份与权限：用的哪个角色？管理员的成功不能当成普通用户的可用。
5. 输入与样本：样本量、正反例、外部依赖是什么？
6. 方法与预期：执行了什么检查，期望看到什么？
7. 实际结果：数量、状态、失败、降级分别是什么？
8. 时间与来源：何时执行，证据在哪？
9. 未覆盖边界：哪些真实链路、角色、时段没有验证？

代码提交、模型版本、Prompt、配置、数据版本变化后，旧证据只保留历史价值。

验证层级：由弱到强，但不互相覆盖

1. 静态与结构检查（lint、类型、Schema、秘密扫描）
2. 确定性局部测试（单元测试、计费公式、路由、权限判断）
3. 隔离组合验证（Mock、干净安装、服务间组合）
4. 真实依赖与业务 E2E（真实 Provider、真实数据、真实用户流程）
5. 候选环境验证（canary / 蓝绿 inactive slot）
6. 发布后核验（切流后的真实请求、费用、日志）
7. 跨时间观察（多日样本、分位数、失败率、质量漂移）
8. 恢复验证（回滚、备份恢复、幂等重试）

层级高不自动覆盖低层断言。一次真实生产请求的保真度很高，但覆盖和持续性可能很低；大量 Mock 测试覆盖很高，但真实依赖保真度低。两类证据互补，不互相替代。

低风险文案不需要机械走完八层；支付、权限、持久化、模型计费、外部写入、生产迁移，不能只凭静态或 Mock 证据收口。

AI 评测的特殊处理

AI 输出是非确定的，不能拿"字符串完全一致"做回归，也不能凭"看起来不错"通过：

• 能固定的先固定：输入、Prompt 模板、模型版本、参数、工具、数据窗口。
• 评测维度明确写出来：结构合法、事实可核验、引用与日期、拒答/降级、延迟、费用、人工实质改写。
• 正例、反例、失败、降级样本同时保留。只存最佳输出会隐藏真实分布。
• 单次链路成功、多样本质量、长期稳定性，分开表述。
• 有阈值记录分子、分母、原样本结果。整改后通过，不能把原始失败改写成通过。

失败也是证据：一个真实案例

资讯简报的质量门禁实践中，自动评测 10 个样本只过了 3 个（3/10 = 30%）。整改、复验、人工确认之后通过。但 3/10 这个数字在报告里原样保留，没有删掉。

理由：失败和未验证项界定的是当前能力边界。整改后通过，记录方式是"原失败 + 根因 + 变更 + 复验"，形成可审计的"整改后通过"，而不是覆盖历史。删掉失败记录，等于删掉了边界本身。

AI 的参与边界

AI 可以整理测试清单、生成候选用例、执行已授权检查、汇总结果、指出缺口。但不能：

• 把未执行、失败、超时、无权访问的检查写成通过；
• 用低层证据推导高层业务或生产结论；
• 自行确定评分、阈值、有效期、审批人；
• 因自动测试通过而批准生产切流或外部状态变更；
• 删除失败证据，或把"整改后通过"改写为"原样本通过"。

小结

"完成"是形容词，"验证"是动词。前者描述状态，后者要求证据。

以后听到"做完了"，问五个问题就够了：在哪个环境、用什么身份、拿什么样本、什么时候、证明了什么。答不上来，不算数。