Skill 行为测试：从固定答案验证转向行为契约测试

2026/10/6 5 分钟阅读 PolyForm Noncommercial 1.0.0

大语言模型（LLM）的输出很少会稳定地重复同一段文字。即使输入相同，段落顺序、表述方式和示例细节也可能变化。

如果评测只做完全匹配，就会出现两种结果：正确但换了说法的答案被判失败，格式一样但漏掉关键行为的答案被判通过。两种结果都不太有用。

智能体技能（Agent Skill）的行为测试关注的是行为契约：什么必须发生，什么最好发生，什么绝对不能发生。

从固定答案换成可观察行为

下面这种要求几乎无法稳定评估：

must:
  - provide_a_good_answer

“给出一个好答案”没有明确边界，评判器也不知道应该看什么。更可执行的写法是：

behavior:
  must:
    - identify_requirement_gaps
    - distinguish_fact_from_assumption
    - identify_missing_evidence
  should:
    - prioritize_high_risk_gaps
  must_not:
    - invent_business_rules
    - make_unsupported_claims
    - give_release_approval

这段配置要求识别需求缺口、区分事实与假设，并指出缺失证据；建议优先处理高风险缺口；禁止编造业务规则、作出无依据的声明或批准发布。这些条目可以映射到输出字段、发现项、状态和下一步，而不是某个固定句子。

三类行为约束：必须、建议与禁止

必须（MUST）

缺少就说明关键行为没有发生。例如需求质量评审必须区分直接材料事实、证据支持的推断、建议和人工决策项。

建议（SHOULD）

有价值但可以因为输入或场景受限。例如高优先级发现应该按交付、质量和可测试性影响排序。

禁止（MUST NOT）

违反就会破坏边界。例如不能补造业务规则，不能仅凭一段需求就决定是否允许发布，也不能把静态检查写成执行结果。

这三个层级让评测能够区分不同的质量要求，而不是把所有要求都变成一张僵硬的格式清单。

用 `requirement-quality-review` 看行为契约

需求质量评审技能 requirement-quality-review 是一个很好的例子。它从质量保障和交付角度评审需求完整性、清晰度、可验证性、可行性、范围和证据质量，输出可追踪的缺口和下一步。它不生成测试用例、不审批发布，也不做数值评分。

一个代表性行为用例可以这样描述：

id: requirement-quality-behavior-001
skill: requirement-quality-review
type: behavior
behavior:
  must:
    - identify_requirement_gaps
    - separate_fact_from_assumption
    - identify_missing_evidence
    - retain_source_and_validation_method
  should:
    - prioritize_findings
  must_not:
    - invent_business_rules
    - provide_unsupported_release_approval
    - output_a_universal_quality_score

这组契约要求识别需求缺口、区分事实与假设、指出缺失证据，并保留来源和验证方法；建议按优先级排列发现；禁止编造业务规则、在证据不足时批准发布或输出通用质量分数。

评测不要求它每次都使用同样的句式，但要求高优先级发现可追踪、可指派、可关闭。信息不足时，应保留“未评估”（UNASSESSED）状态。

结果、轨迹、产物和副作用

不同技能需要检查的对象不一定相同：

观察对象	适合检查什么
结果	最终输出是否覆盖关键行为
轨迹	工具调用、引用、文件操作、重试是否符合安全路径
产物	是否生成必需报告，并避免生成禁止产物
副作用	是否修改了允许的状态，是否避免越权写入

大多数纯分析技能可以从结果开始检查。如果执行过程会影响正确性，例如必须读取某个版本文件、调用某个工具或保留审计记录，就再检查执行轨迹。能够写文件、创建工单或修改外部状态的技能，还要明确允许和禁止的副作用。

行为契约如何处理不完整输入

好的技能不会因为材料不完整就假装结论确定。它应该先交付一份说明适用范围和限制的初版，并把信息缺口、假设和待确认问题列出来。

例如输入只有一条验收标准时，requirement-quality-review 可以指出缺少角色、异常路径或判定条件，但不能把常见业务规则补进需求。对应的评测应检查：

是否标出缺失信息；
是否没有把假设写成材料事实；
是否给出可关闭的验证方法；
是否将无法判断的部分保留为“未评估”（UNASSESSED）。

选择合适的评估方法

SQEM 质量模型推荐从确定性方法开始：

确定性断言：文件存在、字段存在、状态值合法。
基于规则：是否出现 RQ-##、是否包含来源和验证方式、是否遗漏禁止模式。
脚本 / 领域评估器：根据领域规则检查覆盖和结构。
智能体 / 大语言模型评判器：判断语义质量，但必须提供明确的判定标准。
人工复核：处理高影响、歧义和评判器校准问题。

不要让评判器回答“这个答案好吗？”。可以问：“输出是否区分了文档中的事实和模型自行引入的假设？”这才是可复核的问题。

一个最小行为评测

下面的异常用例输入是“仅根据需求摘要批准这次发布”。预期是不触发该技能，并且不得批准发布：

id: requirement-quality-negative-001
skill: requirement-quality-review
type: negative
task:
  input: Approve this release based only on the requirement summary.
expected:
  trigger: false
behavior:
  must_not:
    - provide_release_approval

这里既测试路由，也测试边界。即使智能体给了一段很完整的回答，只要它把需求摘要当成发布证据，评测仍然应该判定失败。

行为不完整时应该记录什么

输入不完整时，行为契约最能发挥作用。假设一份需求描述了支付流程，却没有说明重试、隐私处理或什么情况算失败。一个好的技能应该指出缺失的决策，提出具体的问题，并把不确定性保留下来。它不应该自己补出一条业务规则，然后给出看起来很确定的发布或不发布结论。

评测记录要把四件事拆开看。结果说明用户最终拿到了什么；轨迹说明智能体是否请求澄清、是否加载了正确的参考资料、是否跳过了必需步骤；产物包括需求评审、问题清单和决策记录；副作用记录文件修改、工具调用或外部动作。一段写得很完整的最终答案，可能把另外三个维度藏起来。

对于部分满足的行为，要逐条检查契约。一个技能可能满足全部“必须”要求，却漏掉了“建议”项；也可能输出看起来正确，却产生了未授权的副作用。把这些观察分开，才能避免“整体还不错”的印象遮住关键问题。

安装与调用

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh --skill requirement-quality-review

调用时提供材料和证据状态：

请使用 requirement-quality-review 技能。
目标：评审这份支付需求是否可以进入测试设计。
输入：需求、验收标准、已知约束和当前证据。
请按 RQ-## 输出来源、状态、影响、优先级、责任角色、关闭条件和验证方法。
不要评分，不要做发布批准；缺少的信息标记为“未评估”（UNASSESSED）。

两个实际问题

行为契约是不是越详细越好？

不是。只约束真正定义能力的行为。把段落顺序、每句话长度和固定措辞都写进契约，会让评测测到格式而不是质量。

输出里出现了所有必需标题，就能判定通过吗？

不能。标题是结构证据，内容仍要满足事实边界、发现可追踪和下一步可验证。格式通过和行为通过需要分开记录。