测试 Software 3.0——行业的答案与信任基座的答案
截至 2026 年年中，针对"prompt 即程序"（prompt-as-program）类系统存在两种测试文化，二者各自解决问题的一半。
evals 主流阵营（DeepEval、Promptfoo、LangSmith、Braintrust——LLM 应用世界趋同之后的实践）：为用例构建一个golden set（黄金集）；用混合评分小组打分——约 60% 是确定性检查（精确匹配/正则/schema/延迟），约 30% 是 LLM-as-judge（G-Eval、DAG 指标、成对比较），约 10% 是人工——绝不单靠 LLM 评判（评分器自身的随机性会叠加在系统的随机性之上）；先定基线，再设门槛（先给当前系统打分，卡的是相对基线的 REGRESSION（回归），而不是绝对阈值）；每次 prompt/agent 变更都在 CI 里跑一遍 evals，评测不过 = 阻止合并，理由是"未经测试的 prompt 会悄悄漂移"。针对 agent 的额外做法：基于轨迹的评测（工具调用是否正确、整条轨迹上的任务完成度），而不只是给最终输出打分。
utter-manual 技术栈（由失败长出来的，不是设计出来的）：T0 机械检查（lint、媒体测量、重新推导命令）→ T1 在 ARTIFACT BYTES（工件字节）上做的、每条规则都附引用证据的全新上下文对抗式审计 → T2 相对于当前赢家的基准评测 → T3 owner 一票否决，否决理由被转化为永久规则 → T4 arena 指标，作为唯一真正的证伪手段。此外还有主流所缺的信任管道：内容寻址的发布关卡（被审计的字节就是发布出去的字节）、前提重新推导（审计者不得依赖对方提供的"已知"事实来验证——防止洗白）、以及棘轮机制（任何一名审计者更深一层的发现，都会被提升进入规则文本，供之后所有审计者阅读）。
双方各自缺什么。 主流止步于"输出 vs 预期"这一层：没有任何机制防止前提被洗白，没有任何机制把被评测的工件和实际发布的工件绑定在一起，而且质量门槛是绝对的，不是相对于当前赢家的。反过来，um 的技术栈既没有 golden set，也没有回归 harness：每一次审计都是针对单个工件的；当某条规则或某个 skill 变更时，没有任何东西会重新跑一遍已经积累的旧用例，于是一次规则修改可能悄悄弄坏原本能通过的东西——这正是主流的 CI evals 本该防住的那种漂移。综合方案一旦说出来就很明显：保留信任基座，采纳回归纪律——被审计过的台账本身就是一个正在不断积累的 golden set（每一个通过的工件加上它的判定，就是一条打好标签的用例）；每当机器本身发生变化（skill 修改、规则收紧），就应该触发对一个抽样出的 golden 切片的重新审计，卡的是回归。成本很低，因为这些用例本来就已经作为已提交的台账条目存在了。
八项实践（子笔记——各自独立成篇）
按一次变更的生命周期排序：
- golden-set ——本身就是测试套件的那份数据集（生产日志 + 构造出来的边界用例 + 事故化石化）
- scorer-panel ——60/30/10 的确定性/判官/人工混合；G-Eval、DAG、成对比较；判官校准
- nondeterminism-statistics ——n 次运行的 pass@k、先看显著性再报警、把方差本身当作一个指标
- trace-evals ——评判整条轨迹（工具选择是否正确、步骤效率、端到端完成度）；τ-bench/SWE-bench
- regression-ci ——每个改动 prompt 的 PR 都跑一遍用例集；卡的是回归，绝不是绝对门槛
- online-evals ——影子/金丝雀发布、线上抽样评判并配合漂移报警、隐式信号
- runtime-guardrails ——内嵌进每一次生产执行里的确定性检查
- automated-red-teaming ——针对信任边界本身生成的攻击题库
同类笔记：git-as-agent-trust-substrate（为什么"绑定"胜过"信任"）· audit-as-membrane · tdd-net-popper-mechanized · awareness 专栏 practice 节点里的那套实践层测试栈。
来源：2026-07-18 的行业现状调查（DeepEval / Promptfoo / Braintrust / Confident-AI 的指南），与 utter-manual 自家长出来的验证技术栈对照而成。