怎样测试一个 Skill，而不是只看一次成功？
为周报 Skill 准备正常输入、缺失资料和相近但不同的任务，分别检查事实是否保留、Skill 是否实际加载。
周报 Skill 第一次整理记录时表现不错。下一周，记录里出现一项没有负责人、尚未完成的工作。它会保留这些未知信息，还是为了把报告写完整，擅自补一个负责人？
一次成功，只能说明那次输入得到了什么结果。保存几组不同的材料，逐一检查输出是否符合原记录。也要另外记录 AI 有没有加载 Skill：报告写对了，与使用了这个文件包，是两件需要分别观察的事。
先固定一个可重复测试的版本
把下面的练习文件放进名为 weekly-report 的文件夹，并按当前客户端的说明安装。它沿用第一个周报 Skill 教程中的固定汇报规则。本例交付英文周报，因此规则也用英文。
---
name: weekly-report
description: Draft a factual weekly work report from supplied notes. Use when a user asks to turn work updates into a weekly status report.
---
# Weekly report
Read the notes supplied for this report. If there are no notes, ask for them. Return three sections: Completed, Waiting, and Next work. Keep finished work separate from plans and work still in progress. Do not invent a deadline, approval, owner, or result. Mark an important missing fact as not confirmed. Compare every report statement with the notes before returning it. Return a draft for review. Do not send or publish it.
修改前先保存这个版本。测试记录中写下日期、客户端及其显示的模型、Skill 版本或文件哈希、输入、实际输出和可见的加载记录。客户端不显示模型或加载过程，就记为无法获取。
Agent Skills 输出评估指南建议使用不同输入，并检查具体输出要求。比较有无 Skill 的效果时，把同一份输入分别放到干净的新会话中，其他设置尽量相同，否则不能把差异归因于 Skill。
先准备三种输出测试，再加一种选择测试
下面是作者编写的输入和验收标准，不是已安装客户端的实验结果。每个案例放到新会话，避免上一组事实影响下一组。
| 案例 | 请求及材料 | 检查什么 |
|---|---|---|
| T1：正常记录 | “Use weekly-report to draft my report. Monday: budget draft completed. Wednesday: waiting for Lee's review. Friday: invitations planned after approval; date not agreed.” | 完成的是预算初稿；审核仍在等待；邀请有批准前提，日期未定 |
| T2：资料不全 | “Use weekly-report to draft my report. The signup form still shows an error. A fix has been requested. No owner or deadline is recorded.” | 修复未完成；负责人和期限仍未确认 |
| T3：没有记录 | “Use weekly-report to draft this week's report.” | 索要记录，不编造一周工作 |
| T4：相近但不同的任务 | “Write an invitation email for Friday's workshop. Do not write a weekly report.” | 完成邀请邮件，不强套周报格式；检查是否无必要地加载 Skill |
T1—T3 明确点名 Skill，用于检查提供了 Skill 后的行为。T4 测试选择是否合适，不要再额外点名调用。之后还应补充不提 Skill 名称的日常周报请求，检查需要时是否会选用。
T2 的参考表述可以是：“Next work: fix the signup-form error; a fix has been requested, but the owner and deadline are not confirmed.” 如果写成“The form was fixed by Alex on Thursday”，就在完成状态、负责人和日期三处新增了事实。措辞再顺，也不能抵消这些错误。
检查意思，不要求逐字相同
把可核对的要求分开：完成的是预算初稿，没有确认批准，邀请日期未确定，没有实际发送。报告不必使用你偏好的固定句子，但状态和前提必须一致。
真实跑完后，可以按这张记录填写：
案例：T2
Skill 加载：已观察到 / 未观察到 / 无法获取
完成状态保留：通过 / 失败，附输出片段
负责人和期限仍为未知：通过 / 失败，附输出片段
外部动作：无 / 观察到的动作
输出判断：接受 / 修改
加载依据应是文件读取记录或客户端提供的其他证据，不能只靠 AI 自称“用了 Skill”。没有加载记录，即使报告事实正确，也不能确定选择过程。描述测试指南把实际加载视为检查触发的观察点。
修一条失败规则，再重跑已保存的案例
如果 T2 编造负责人，就补上针对缺失负责人的规则，再重跑 T1—T3，而不是只跑 T2。新规则可能破坏原先正确的案例。再换一组姓名和情境，用另一种措辞测试，避免规则只是记住原句。
重要案例要重复运行，因为一次表现不一定代表下一次。记录实际运行次数和结果，把加载失败与输出失败分开。小型练习足以帮助发现具体缺陷，却不能证明 Skill 普遍可靠，或一定优于保存一条普通 Prompt。
参考资料
- Evaluating skill output quality：设计案例、隔离比较，以及制定能观察的检查项。
- Optimizing skill descriptions：观察加载，测试应该和不应该选用 Skill 的请求。
