执行驱动交付六TR4 双面闸——为什么验收要双向执行驱动交付EDDAI 项目交付方法论 · 6/8基于 1 个真实交付项目与内部实战实验实测2026-08 摘要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 才通过」中的严重 P0P1 ⑤ 对照终态画面查整体拼装防「每块都对、整体拼错」 成功标准防不了方向错——画面是 TR4 前唯一可对照 整体方向的东西 ⑥ 出具报告客户语言不堆内部术语→ 客户签字 ⑦ 经验固化触发新约束/新边界走证据门槛进 skill/黄金集双面闸的结构一张图看全对内闸推测项终验否是边界卡「推测待验证」清单逐项最终验证验证通过不许进固化层退回执行循环对外闸验收凭证六属性评估 缺陷分级P0-P3验收报告判定权在人客户语言客户签字 经验固化对内闸拦住「推测当事实」进固化层错误放大坑的最后一道闸对外闸产出可交付的凭证——两个方向一套证据。对内评估维度资产单必做六属性映射 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 跑测试出初稿人做判定——判断活全甩给 AITR4 会面对「AI 觉得全对、客户一看全错」的应用缺陷分级 P0-P3 为对内判定口径对外报告用客户能懂的严重/一般/提示三级收尾TR4 双面闸的本质对内它把「可能错」变成「已验证」——推测项终验是错误放大坑的收口对外它把「我觉得行」变成「证据包」——硬标准 客户签字运动员兼裁判的问题被结构化解掉。验收不是流程的终点是两件事的分界线经验回灌开始交付凭证交出。下一篇执行驱动交付七资产复利——为什么每一单都要让下一单更便宜 更多实战记录见我的博客鱼日先生讨论区你的验收是「测完再改」还是「基线化后统一修」客户问「你自己测的自己信」的时候你是怎么回答的评论区聊聊。如果觉得有收获欢迎点赞 收藏 关注这是激励我更新这个系列的最大动力。本文基于真实项目交付经验撰写2026-081 个真实交付项目与内部实战实验。文中数据均来自实测记录方法论部分以「已验证 / 推断待验证」标注边界。 执行驱动交付（六）：TR4 双面闸——为什么验收要双向？
执行驱动交付六TR4 双面闸——为什么验收要双向执行驱动交付EDDAI 项目交付方法论 · 6/8基于 1 个真实交付项目与内部实战实验实测2026-08 摘要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 才通过」中的严重 P0P1 ⑤ 对照终态画面查整体拼装防「每块都对、整体拼错」 成功标准防不了方向错——画面是 TR4 前唯一可对照 整体方向的东西 ⑥ 出具报告客户语言不堆内部术语→ 客户签字 ⑦ 经验固化触发新约束/新边界走证据门槛进 skill/黄金集双面闸的结构一张图看全对内闸推测项终验否是边界卡「推测待验证」清单逐项最终验证验证通过不许进固化层退回执行循环对外闸验收凭证六属性评估 缺陷分级P0-P3验收报告判定权在人客户语言客户签字 经验固化对内闸拦住「推测当事实」进固化层错误放大坑的最后一道闸对外闸产出可交付的凭证——两个方向一套证据。对内评估维度资产单必做六属性映射 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 跑测试出初稿人做判定——判断活全甩给 AITR4 会面对「AI 觉得全对、客户一看全错」的应用缺陷分级 P0-P3 为对内判定口径对外报告用客户能懂的严重/一般/提示三级收尾TR4 双面闸的本质对内它把「可能错」变成「已验证」——推测项终验是错误放大坑的收口对外它把「我觉得行」变成「证据包」——硬标准 客户签字运动员兼裁判的问题被结构化解掉。验收不是流程的终点是两件事的分界线经验回灌开始交付凭证交出。下一篇执行驱动交付七资产复利——为什么每一单都要让下一单更便宜 更多实战记录见我的博客鱼日先生讨论区你的验收是「测完再改」还是「基线化后统一修」客户问「你自己测的自己信」的时候你是怎么回答的评论区聊聊。如果觉得有收获欢迎点赞 收藏 关注这是激励我更新这个系列的最大动力。本文基于真实项目交付经验撰写2026-081 个真实交付项目与内部实战实验。文中数据均来自实测记录方法论部分以「已验证 / 推断待验证」标注边界。