大厂 Evals 经验系列 · EDD 专题
“让 Agent 帮客户开通试用，处理失败时给出合理指引。”这句话可以放进需求文档，也足以启动一个演示。到验收时，分歧才出现：说了“已开通”算成功吗？客户没权限时应拒绝、补资料，还是转人工？
我认为，评测驱动开发对产品经理最直接的价值，是把这些分歧提前暴露。微软的指南提供了一条可借用的路径：先明确情境，再写可检查的预期，最后组织评测结果。它的 HR 入职案例是教学示例，不能当成已经上线并取得成效的战报。微软评测概览
需求里没有写出的条件，先放进情境
下面是一条本文设计的假设需求，不是微软案例：客户管理员可以为一个测试租户开通七天试用；普通成员没有开通权限；已有有效试用时，不能重复创建；企业合同中的例外期限，由客户经理处理。
仅写“帮我开通试用”，无法确定应有结果。测试至少需要指定身份、租户、当前试用状态、权限规则和接口返回。比如固定为：管理员甲、租户 T01、未开通过试用，接口返回成功及到期日。此时才有一份可比较的预期。
微软的提示词设计文档建议，单轮题目使用单一意图、真实表达、具体数据和自足的上下文。设计评测提示词
解读批注｜单一意图不等于抹掉业务背景。客户身份会改变动作权限，当前状态会改变应有动作，它们都属于题目条件。把条件写完整，是为了让失败有确定含义。
我会把“普通成员要求开通”和“管理员要求重复开通”分成两道题。虽然都围绕试用，预期分别是权限拒绝和返回既有状态。合成一道长题，失败后很难知道是哪条规则没被遵守。
还应明确测试环境中的时间。假设七天按自然日计算，生效日、时区和到期边界都要固定；如果产品实际按满七个二十四小时计算，预期必须随之改变。评测不能替团队决定业务规则。
断言要能让两个人判出同一个结果
断言就是一条可检查的预期。微软给出的要求是单项、二元、关注结果、可验证，并建议用两名领域专家能否独立作出相同判断来检查它。编写断言
精选译句：“每条断言都应是单项的、二元的、关注结果的、可验证的。”原句：“Every assertion should be atomic, binary, outcome-focused, and verifiable.”
原创批注｜“处理得合理”没有交代判分依据。更具体的写法应指出检查什么、从哪里检查、什么情况下通过。二元表示这条条件通过或失败，不表示所有质量维度只能用二元评分。
沿用前面的假设，成功开通可以拆为四项：请求指向 T01；期限符合七天规则；后端记录存在且状态有效；回复中的到期日与记录一致。每项单独留结果，才能区分动作错误与表达错误。
如果只留一句“开通成功且解释清楚”，后端没有创建、日期说错、话术绕口都会落进同一个失败桶。修复人员仍要重新读一遍对话，才能猜测问题位置。
断言也不宜拘泥于表面形式。我建议允许“试用已生效”和“已为该租户开通试用”两种等价表达；但租户 ID、权限和期限必须准确。文案自由度与业务容差应分别定义，不能统称为“差不多”。
工具的返回，要改变 Agent 的交付
微软在工具断言中分别讨论调用、参数与结果处理；失败示例要求识别错误，不能在操作失败时表示成功。工具结果处理断言
回到本文的试用场景，可以准备下面几份固定返回。它们是用于隔离测试的假设，不是实际接口定义。
| 固定条件 | 应有行为 | 可核验证据 |
|---|---|---|
| 创建成功，返回试用编号 | 告知生效状态和到期日 | 编号、状态与后端记录对应 |
| 已存在有效试用 | 说明当前状态 | 没有额外新增试用记录 |
| 明确返回权限不足 | 说明无法开通及可行下一步 | 没有成功承诺，也没有越权写入 |
| 结果暂时未知 | 说明尚待核实 | 保留同一操作的查询线索 |
最后一行尤其需要在需求中写清。暂时拿不到结果时，评测记录应为“证据不足”，而不是因为回答礼貌就通过，也不是直接认定后端失败。这是本文提出的状态设计，需要由实际系统提供查询能力才能落实。
对本例来说，回复检查与后端检查应分别保留。客户看到的状态错了，即使后端开通成功，也构成交付问题；后端没有开通，回复再完整也无法证明任务完成。
转人工，也需要定义完成到哪一步
微软的升级处理断言示例包含说明需要 HR 专家帮助、提供联系办法，以及避免自行判断指定的敏感资格问题。升级处理断言
本文的企业合同例外可以据此延伸：Agent 应识别该事项超出标准试用规则，说明由客户经理处理，并提供约定入口。它不应为了完成请求，自己承诺一个新期限。
但“建议联系客户经理”和“已经创建并分派工单”是不同交付。若产品承诺前者，检查入口与说明即可；若承诺后者，还要检查工单对象、接收人和状态。需求未承诺自动分派时，不应硬性要求一次写操作。
还要补一条相邻场景：普通管理员的标准开通应可自动完成。否则，只要所有问题都转人工，也可能在狭窄题集上拿到高分。我建议同时保留“必须转”和“可以自行处理”的题，检查边界两侧。
质量信号负责组织失败，不代替证据
微软将质量信号定义为评测结果中的模式类别：断言用于判定条件是否通过，信号用于聚合失败；指南建议先观察结果，再提炼反复出现的模式。提炼质量信号
我的建议是先跑一小组具体情境，再组织看板。如果多条题都出现“后台失败、回复却成功”，可以归到“工具结果处理”；如果管理员和成员被混淆，归到“权限识别”。这些是待证据支持的分类建议。
分类之后，仍需回到原记录定位原因。“权限识别失败”不证明一定是提示词问题，也可能是身份信息没有传入。质量信号让团队看到集中出现的问题，原始对话、参数与后端状态才支持进一步判断。
微软概览提供了测试数量和通过率的指导，也给 HR 示例配置了不同目标。它们不是通用上线标准。原文指导与示例
对试用开通，我会单独记录权限错误和重复写入；不能让大量普通问答的通过，抵消少数错误开通。阈值应由业务损失、可恢复性和样本覆盖来制定。报告还要交代统计的是题目、断言还是运行次数，同一题重复跑后的波动也要保留。
下一次评审这类需求，可以先带三条记录：一个正常动作、一个明确失败、一个边界外请求。每条都附上固定背景、独立断言和判分证据。团队若仍无法对它们形成一致判断，应先修订需求中的空白，再讨论 Agent 实现。
来源为 Microsoft Learn 官方指南，访问于 2026-10-11。本文保留一条精选译句；试用场景、验收扩展与取舍为原创分析，尚无实测结果。
系列相关阅读
本专题阅读顺序：完整理解 EDD → Google 的提示词实验 → OpenAI 的评测位置 → 微软的需求断言 → MLflow 的回归任务 → AWS 的协作验收 → 美团的双环评测。
评测基础可回读再读A社博文：怎样建立可信的 Agent 评测；判断评分可靠性，可继续阅读谁来给 AI 裁判打分与Agent 分数涨了，能力真的变强了吗。