没有标准答案时，验收标准就是标准答案
上一讲结束，我们留了个尾巴：Agent 拆好了、跑起来了——可它干得对不对？生成的需求文档、代码，没有标准答案，怎么验收？验收不了，该怎么迭代？
这一讲是模块四的起点，也是前面很多伏笔收拢的地方。第 2 讲讲过防幻觉靠流程，第 5 讲讲循环翻车姿势，第 6 讲讲看调用轨迹找翻车——它们其实是同一件事的零件。今天把它们组装成一台机器：评估体系。
问题一：没有标准答案，怎么验收？
传统软件的验收很简单：预期输出是确定的，对就是对，错就是错。可 Agent 的产出是开放的——一份需求文档，哪有什么”标准答案”？没有标准答案，怎么判断它写得对不对？
答案是换个参照物：不和标准答案对，和验收标准对。没有标准答案时，验收标准就是标准答案。
那验收标准怎么写？这里有个反直觉的技巧：别问”好的长什么样”，先写”坏的长什么样”。问”什么是好需求文档”，写出来的一定是四平八稳的空话——”结构完整、逻辑清晰”，这种标准没法打分。问”烂的需求文档干过什么蠢事”，答案立刻就出来了：
失败句一：它写的验收条件是「系统要快」，没法验证
失败句二：它漏掉了异常流程，只写了主流程
失败句三：字段定义和架构规范里的命名不一致三个失败句子写出来，验收标准几乎自动长出来：每条失败句反过来就是一条可检查的标准——”验收条件必须可验证””必须包含异常流程””字段命名必须与架构规范一致”。
最后定指标。评估产出有三种指标，按产出形态选：
任务成功率 端到端主指标：N 个任务过了几个（判结果不判措辞）
精确匹配 答案唯一时用：数值、日期、分类
评估标准（rubric）打分 开放输出：按标准逐条打分主指标用任务成功率——它能容纳”对的路不止一条”；评估标准做诊断工具，看失败的到底烂在哪条标准上。
问题二：谁来评？
标准有了，下一个问题是：每条标准谁来判？三个裁判，按顺序上场：
第一棒：确定性检查（能自动判的，全自动化）
格式对不对：文档五个部分齐不齐、代码能不能跑
规则对不对：命名字符不符合规范、字段在不在表结构里
——写脚本判，零成本，秒出结果
第二棒：LLM 评审（判断"好不好"的软标准）
逻辑通不通、方案合不合理
——让模型评模型，但标准要独立于生成过程
第三棒：人工抽检（保底校准）
自动评大部分，人抽查一小部分对答案
——确认"机器评的"和"人评的"没跑偏顺序千万别反：能确定判的，就别用模型评。道理很硬——裁判不可信，下游所有数字都没意义。一个自己都不准的评分器，会让咱们对着错误的通过率做决策。
LLM 评审（LLM-as-judge）还有个专门的坑要防：它最常见的失败模式不是”评错”，而是“自信地同意”——倾向于给好评。这是最难从仪表盘上发现的翻车，所以第三棒人工抽检必须留着：定期拿机器的评分和人的判断对一对，跑偏了就校准。
像不像代码评审？lint 先扫一遍（确定性），再让程序员看逻辑（软判断），最后 leader 抽查（保底）。机器干机器的，人干人的，谁也别替谁。（沈剑当过技术委员会主席，评审这件事——机器干机器的，人干人的，顺序乱了必出问题，深有体会。）
问题三：评完，怎么迭代？
评估不是终点，是引擎。完整的迭代循环长这样：
跑 N 个任务 → 算通过率 → 捞失败 case →
归因到设计缺陷 → 改设计 → 再跑一轮关键是”归因”这一步——失败 case 往哪儿归？前面几讲的翻车清单现在全部派上用场：
规划错 目标理解偏了 → 改任务书/提示词
行动错 工具用错、参数给错 → 改工具描述、改工具设计
观察错 结果误读带着错跑 → 加观察环节的校验
知识错 不遵守团队规范 → 改 skill 正文和资源通过率还有个更大的用处：驱动架构决策。OpenAI 官方建议里有一句话，和咱们第 8 讲完美咬合：要不要上多 Agent，应该由评估数据说了算。第 8 讲咱们说”信号驱动”，第 9 讲补全下半句：信号够不够，用通过率来验证。拆之前单 Agent 通过率多少？拆之后多少？数字说话。
最后，测试集是活的：生产环境里每发现一种新的翻车姿势，就把它写成一个失败句、加进测试集。测试集朝着真实的风险面生长，评估体系才不过时。
沈剑评审十几年，最深的体会：失败 case 是最值钱的资产——成功的系统都差不多，失败的各有各的教训。（所以测试集里，失败句永远比成功标准多。）
落到 sdd-site-agent：验收标准怎么定
回到贯穿项目。给 sdd-site-agent 的产出定三层验收标准：
格式层（确定性）：代码能跑吗？文档五个部分齐吗？
规则层（确定性）：符合架构规范吗？命名一致吗？
质量层（LLM+人）：方案合理吗？需求覆盖全吗？
指标：任务成功率为主，评估标准打分做诊断
测试集：从 5 个真实任务起步，失败 case 持续加入第 8 讲作业①的拆分决策文档，现在有了验证手段：跑同一批任务，对比”单 Agent”和”拆编码子 Agent”的通过率和成本——拆得对不对，数据说了算。
实操演练（约 25 分钟）
必做部分 + 一步加餐。做完必做部分，本讲的核心手感就到手了。
检验一下
①sdd-site-agent 三层评估标准 + 首轮通过率记录：验收标准表 + 5 个任务的通过情况 + 失败归因——第 10 讲算成本账、定安全策略都要基于这份真实运行数据；
②测试集 v1：把作业里收集的失败 case 写成失败句，凑成第一个测试集——它会跟着咱们一直长到第 12 讲。
你如果想深挖一层，读这两篇：OpenAI · A practical guide to building agents 和 OpenAI · Evaluation best practices
“要不要上多 Agent 由 evals 驱动”的官方原话、评估的三个非确定性维度（指令遵循/输出正确/工具选择）都在里面。和我们第 8 讲的信号驱动对着读，体感会很完整。
但还有一个没解决的问题：评估能兜底质量，可有两件事它兜底不了——有人故意往输入里藏恶意指令（prompt 注入）怎么办？这套体系天天跑，一个月烧多少钱？——第 10 讲，我们讲安全与成本。
知其然，知其所以然。思路比结论更重要。