自动关联目录：自动化验证：静态契约测试不能代替真实运行证据

核心判断：检查 Target.cs、Build.cs、脚本参数和 Manifest 能快速阻止配置回归，但它只能证明“声明看起来正确”；启动、跨进程通信、资产加载和 DS 行为仍需要绑定实际产物的运行证据。

一、业务冲突

一次共享改动可能同时影响编辑器、客户端、DS、轻量运行时、桌面壳和资产工具。全量 UE 构建与 E2E 很慢，只跑单元测试又会漏掉插件加载、链接裁剪、Cook 数据和打包脚本问题。测试策略必须在反馈速度和证据强度之间分层。

二、实际实现

工程已有丰富层次：纯函数测试覆盖状态机、摘要、进度和错误分类；真实 Windows 文件句柄与批处理脚本测试平台语义；契约测试检查 Target、插件、部署目录和失败码传播；服务测试驱动冻结计划、重试与恢复；浏览器 E2E 验证管线 UI；运行报告还绑定包清单摘要、制品集合、运行 ID、引擎日志和运行时 JSON，拒绝构建前或其他运行留下的证据。

三、值得保留

快速测试没有假装自己是 E2E，而是逐步提高证明强度。尤其是把 Runtime Evidence 与实际包字节及本次 RunId 绑定，解决了“拿旧日志证明新构建成功”的常见假阳性。脚本失败码也被测试为向上传播，而非吞掉后仍打印成功。

四、结构性缺陷

部分裁剪测试仍依赖源码正则、字符串存在或手工规则，它们不能证明预处理后的代码和最终链接结果。测试数量多但若没有 Change Impact 映射，开发者仍可能只运行熟悉子集。大量 Fixture 也可能与真实 UE 行为逐渐分叉。

五、目标设计

struct VerificationEvidence {
    ChangeSetId change;
    TargetId target;
    ArtifactSetId artifacts;
    EvidenceKind kind; // Contract, Build, Launch, Scenario, Load, Visual
    RunId run;
    Result result;
};

GateResult Accept(ChangeImpact impact, EvidenceSet evidence) {
    return RequiredMatrix(impact).AllSatisfiedBy(evidence)
        && evidence.AllBindCurrentArtifacts();
}

协议改动要求三端 golden vector；模块裁剪要求 UBT Receipt、链接清单和启动；UI 改动要求结构断言与视觉基线；DS 逻辑要求真实 Client/Server 场景。静态扫描只作为早期 Gate，不作为最终证明。

六、取舍与验证

证据矩阵会增加 CI 时间，应按影响选择目标，并把慢测试放到合并 Gate。定期故意破坏插件、Schema、包字节、运行 ID 和 DS 协议，确认对应 Gate 必定失败；一个从未证明能抓住错误的测试套件，只是在积累文件。