执行驱动交付（六）：TR4 双面闸——为什么验收要双向？
执行驱动交付（EDD）：AI 项目交付方法论 · 6/8
📖 摘要：TR4 验收是双面闸——对内是 EDD 闭环收口：边界卡上所有「推测待验证」项在这里终验（验证不过不许进固化层），经验回灌下一个项目；对外是交付的重量：凭证 + 尾款 + 作品集。本文讲 TR3 与 TR4 的本质区别、裁判权归属（运动员兼裁判的解法）、六属性评估与验收三态。
📌 本文要解决的核心痛点
- 自测报告写「全部通过」，客户说「你自己测的自己信？」——运动员兼裁判，谁信？
- 验收时发现问题，当场改应用——「改完再测」和「测完再改」混在一起，质量到底是谁的？
- 边界卡上标了一堆「推测待验证」，验收时一个都没验证，直接固化进 skill？
- 本文讲 TR4 双面闸：对内终验推测项（错误放大坑最后一道闸），对外交出证据包——裁判是硬标准，不是人。
场景
交付一个 AI 应用，开发阶段自测（TR3）全绿。出验收报告：功能✓ 性能✓ 安全✓——全部通过。
客户问：「这些是你自己测的吧？你测的当然通过。」
这句话问出了 AI 交付最尴尬的信任问题：交付方是运动员，又是裁判。传统软件有第三方测试、有验收标准，AI 应用交付没有——自测报告天然不被信任。更糟的是，如果交付方在验收时还边测边改：「这个 bug 我马上修一下再测」——测完再改、改完再测混在一起，最后报告上的「通过」到底是测出来的，还是改出来的？质量是谁的，永远说不清。
TR4 不是「再测一遍」，是把验收拆成两个方向：对内怎么收口，对外怎么交账。
结论
TR4 是双面闸：对内 = EDD 闭环收口（推测项终验 + 经验回灌起点）；对外 = 交付的重量（凭证 + 尾款 + 作品集）。
TR3 和 TR4 的本质区别，一张表：
| 维度 | TR3 自验证 | TR4 验收 |
|---|---|---|
| 立场 | 作者视角：实现符不符合约束 | 裁判视角：成品值不值得上线 |
| 目的 | 收敛——修到符合约束 | 判定——三态（通过/有条件通过/不通过） |
| 问题处理 | 迭代式：修→重跑→再修 | 判定式：记录→分级→报告 |
| 评估范围 | 功能正确性为主（对不对） | 六属性整体（行不行） |
| 对象状态 | 开发中的应用（还在迭代） | 冻结后的成品（准备交付） |
| 产出 | 自验证结论（内部资产） | 验收报告（对外凭证） |
TR3 是修到对，TR4 是判给客户。 TR4 之前，应用冻结——不再迭代，只评估。
推导链：运动员兼裁判，怎么解决？
交付侧做 TR4 确实是「运动员兼裁判」，但裁判可以是硬标准而不是人——硬标准不会失真。三个裁判，对应三个场景：
对内收口：裁判 = 硬标准——TR0 可断言成功标准 + 客户拍板边界卡 + 终态画面 + 基线化用例集。用项目开始时的标准判项目结束时的成果，相当于「按合同判履约」——标准客观可复现，不因人而异
对外交付：裁判 = 客户（签字权）——TR4 报告是「证据包」不是「判决书」，客户拿着做验收决策；「有条件通过 / 缺陷分级」让客户看到全貌，而不是一个粉饰过的「通过」
独立验收：裁判 = 第三方（只报告不修改）——客户不信任自测报告时，第三方验收是独立业务线
商业闭环在这里：客户不信任「运动员兼裁判」的自测报告，正是独立验收服务的需求来源。
实践动作：TR4 的输入、动作、输出
TR4 动作链：
① 六属性评估：功能/性能/安全/可靠性/压力/异常全量覆盖
（异常含错误路径：乱码/超长文本/提示注入攻击/恶意诱导）
② 边界推测项终验：边界卡上所有「推测待验证」项做最终验证
——验证不过不许进固化层（错误放大坑最后一道闸）
③ 验收三态判定：通过 / 有条件通过 / 不通过（判定权在人）
④ 缺陷分级：P0 阻断（必须修）/ P1 严重（必须修）/
P2 一般（记录+修复计划）/ P3 轻微（记录不阻塞）
——「严重缺陷=0 才通过」中的严重 = P0+P1
⑤ 对照终态画面查整体拼装：防「每块都对、整体拼错」
（成功标准防不了方向错——画面是 TR4 前唯一可对照
整体方向的东西）
⑥ 出具报告（客户语言，不堆内部术语）→ 客户签字
⑦ 经验固化触发：新约束/新边界走证据门槛进 skill/黄金集双面闸的结构，一张图看全：
对内闸拦住「推测当事实」进固化层（错误放大坑的最后一道闸），对外闸产出可交付的凭证——两个方向，一套证据。
对内评估维度（资产单必做）：六属性映射 AI 应用语义——性能→首 token 延迟/单轮 token 消耗/总成本；安全→提示注入/越权调用；异常→对抗样本/乱码/超长文本/恶意诱导；外加任务成功率（终态谓词验证，不靠模型自评）、循环率、熔断触发率。对外报告保留客户语言，不直接用熔断触发率这类术语。
正例实证：推测项终验，拦下一条错误规则
一个检索类项目，边界卡标了三条「推测待验证」：阈值 0.3 更好、top_k 8 命中更高、rerank 能降噪声。TR4 逐条终验：
阈值 0.3 vs 0.5：实测 0.5 更稳（推测被否，拦下）
top_k 4→8：带图段命中率显著提升，成本上升可接受（推测验证通过，固化）
rerank：降噪明显（验证通过，固化）
终验结果是错误放大坑的最终账目：两条进固化层（有实测背书），一条被拦（避免了 N 个项目带病运行）。推测项不终验，等于把「可能错」直接写进 skill——TR4 是对内收口的最后一环，不是对外交付的走过场。
反例实证：验收时改应用，质量说不清
一个交付项目（早期踩坑），验收阶段客户报了一个边界场景 bug。我们的第一反应：当场修，修完再测，报告写「全部通过」。
结果客户问：「你测的时候是修之前的版本还是修之后的？」——答不上来。修之前的用例结果不算数，修之后的没测全。「通过」这个结论的版本归属都说不清，报告的可信度直接归零。
修复：验收基线化 + 冻结应用。验收时发现问题，记录、分级、归因——但不当场改：基线跑完，统一归因（应用缺陷/用例缺陷/环境问题三分），再按流程修，修完重跑基线。独立验收（只报告不修改）也是这个逻辑的延伸——交付侧能改（先修→重跑→给意见→等指令），独立验收只报告。
边界与版本
档位差异：一档极简验收单（边界项核对 + 成功标准核对 + 关键负向用例，半天）；三档全量六属性 + 完整报告 + 终验报告
TR4 输入：TR3 用例集 + 执行记录（继承，不重测功能）、边界卡（推测项终验）、被测应用（冻结后成品）、客户验收环境 + 真实数据——沙盒测不出的问题在真实环境暴露
判定权在人：三态判定和客户签字是人的职责，AI 跑测试出初稿，人做判定——判断活全甩给 AI，TR4 会面对「AI 觉得全对、客户一看全错」的应用
缺陷分级 P0-P3 为对内判定口径；对外报告用客户能懂的严重/一般/提示三级
收尾
TR4 双面闸的本质：对内，它把「可能错」变成「已验证」——推测项终验是错误放大坑的收口；对外，它把「我觉得行」变成「证据包」——硬标准 + 客户签字，运动员兼裁判的问题被结构化解掉。
验收不是流程的终点，是两件事的分界线：经验回灌开始，交付凭证交出。
下一篇（完结篇）：资产复利与边界——为什么每一单都要让下一单更便宜？
💬 讨论区：你的验收是「测完再改」还是「基线化后统一修」？客户问「你自己测的自己信？」的时候，你是怎么回答的？评论区聊聊。
本文基于真实项目交付经验撰写（2026-08，1 个真实交付项目与内部实战实验）。文中数据均来自实测记录，方法论部分以「已验证 / 推断待验证」标注边界。
