任务做对了，测试仍可能没覆盖：阿里云用义务清单卡 Cloud Skill 发布

任务做对了，测试仍可能没覆盖：阿里云用义务清单卡 Cloud Skill 发布

阿里云的预印本 Are Production Cloud Skills Adequately Tested? Measuring and Governing Skill Test Adequacy in Practice，arXiv 公开戳记是 2026 年 7 月 24 日（2607.22015）。下载到的 PDF 页眉是 v3，2026 年 8 月 12 日。作者都写 Alibaba Cloud，其中 Shuyang Yu 同时标注哥伦比亚大学，Ruifeng Nie 同时标注阿尔托大学。下面的发布日用 v1 公开日。Skill Test Adequacy 量的不是 Agent 把任务做成功没有，而是这份 Skill 自己写明的操作，有没有被至少一条测试场景练到。

通过一条部署用例，看不出没测的分支

Cloud Skill 是给 Agent 的可复用操作说明，门户在 https://skills.aliyun.com/ 。论文引用的另一项研究看了 238 个真实 Skill；其中进入 H2 分类的 224 个 SKILL.md 里，49.2% 含有分步指令。那是别人的统计，不是这 157 个 Skill 的分步比例。

云上的 Skill 一旦发布，就是用户会靠的交付物。指引错了，可能配错、多花钱、恢复不完整，或改到别的资源。实验问题是「加上 Skill 之后任务成功率有没有升」。发布还要问「Skill 里写了的行为，测过没有」。

例子是在 ECS 上部署网页应用。Skill 可能要求：看 VPC 在不在、没有就创建、配安全组、建实例、绑公网 IP、校验、失败后清理。若初始状态里 VPC 和安全组已经有了，成功路径可以过，但 VPC 创建、安全组创建和失败清理都没被这条用例碰到。

代码覆盖率的分母是行和分支，执行可以被插桩看到。Skill 是多文件自然语言包，义务和「哪条测试练到它」都没有现成链接。表 1 把两边的困难对照开：分母是语义解释，漏一条不显眼的义务会制造虚假的充分；把参考材料算进去又会制造虚假的缺口。资源条件和用户选择往往只写在散文里，同一条命令在不同条件下可以是不同义务。散文一改，粒度就变，所以要留来源位置，不能只靠稳定的程序行号。

充分性是被测到的义务比例，80% 是发布政策

范围只包括面向用户的流程型 Skill：云操作、需要用户做的选择、校验、恢复。只罗列 API 语法、背景知识或开放问答、没有操作行为的，不算。

一条规范化测试用例是三元组：用户提示、初始资源状态、预期的用户决定。义务是一条可观察操作，加上触发条件、期望结果，以及 Skill 里的来源片段。同一操作、同一触发、同一结果的改写并成一条；命令文本相同但条件或结果不同，仍然是两条。环境级的搭建和拆除，只要不属于这条用户流程，就从分母拿掉。

一条用例覆盖某义务，当且仅当：在这份用例选定的初始状态和用户决定下，Skill 允许的每一种执行都会实现该义务。资源状态只是初始条件，不是「这个操作已经跑过」的证据。用例必须自洽，而且不能让同一义务在有的合法执行里发生、在有的里不发生。

套件分用并集，不用投票。任一经过复核的用例标了覆盖，这条义务就算覆盖。STA 是已覆盖义务数除以义务总数，落在 0 到 1。加测试不会让分数下降。分数为 1，当且仅当没有未覆盖义务。图 2 里的 8/10 等于 80%，是流程示意，不是下面 157 个 Skill 的某一条实测。

这不是运行时正确性。盖住了的义务仍可能参数错、断言弱、实现不安全。分数也不枚举参数组合，不证明任意顺序，不验证运行时安全。80% 是发布门槛，不是理论上的充分边界。

三个 Qwen3.7-Max 提案，人拍板，再进任务成功率

生产流程读整个 Skill 目录，不只读主文件。义务候选和用例状态都由 Qwen3.7-Max 驱动。每个候选回合是新的会话，避免共享对话把「一致」做成惯性。

每个 Skill 同时跑三个 Agent，同一标准：读包、找出参与用户流程的操作、边界不清就回到原文、交出完整清单。标准包括云资源操作、官方脚本和外部调用、会影响后续执行的用户选择、结果校验、恢复或清理。每条候选要能独立测试，并带命令、区分标签和期望结果。失败的回合会重试，不能悄悄把候选池缩小。三次是冗余，不是多数表决。只有一个 Agent 找出来、但能在 Skill 里对上的操作，仍然留下。语义相同的并成一条；粒度冲突和另一种切分并排给审阅者，聚合器不决定答案。

审阅界面把原文和义务卡片放在一起。跨回合一致的预选，分歧和单方候选高亮。人可以补漏、删掉只是参考的条目、合并切得过碎的、拆开可以独立测试的，并去掉脱离用户流程的环境操作。人接受的集合才是分母。

然后另一个 Agent 拿到 Skill、已复核义务、提示、初始资源和预期决定，把每条义务标成覆盖或未覆盖。人可以改状态。套件报告按并集计算。只有人确认的缺口才进入建议；被否掉的 Agent 提案不能自己变成建议。

建议写清还没测的行为、要补的资源条件或用户选择、新用例应核对的结果。也可以指出用例没写清、Skill 本身含糊，或应记成明确例外。建议不自动改 Skill 或测试。作者和发布审阅决定改什么，改完再评。这篇的记录只包含初评时生成的建议，没有统计建议被接受了多少，也没有统计补测之后分数升了多少。

充分性是第一道强制门。过了才进入任务成功率和其他发布检查。已发布的阿里云 Skill 因此两道都过了。门槛是 80%。低于 80% 退回补测，其间不能做任务成功率测试。平台另外建议 90%，但不取代 80%。

157 个初评：中位数 91.3%，仍有 36.3% 过不了 80%

流程上线后评了 157 个开发中的 Cloud Skill。记录的是补测之前的第一次充分性，不是补完以后的分。均值 80.3%，中位数 91.3%，四分位距 68% 到 100%。67 个（42.7%）是 100%。第 10 百分位是 39.4%。

达到 80% 的是 100 个（63.7%）。57 个（36.3%）必须补测才能继续发布。达到建议的 90% 的是 81 个（51.6%），76 个（48.4%）不到。只看中位数会偏乐观。

132 份建议报告里有 639 条义务级建议。均值每份 4.84 条，中位数 4，四分位距 3 到 6，最多一份 17 条。这 132 份盖住了全部 57 个低于 80% 的 Skill，外加 75 个已经达到 80% 的。门槛决定能不能往下走；缺口清单说明即便过了门，还有什么没测。

论文自己写明，这些数还不能证明建议被采纳、补测后变好、标注者之间一致，也不能推广到阿里云以外。

32 个 Skill 做成探索集，这篇没有自动评测的 F1

复核记录被抽成 SkillAdeqBench，数据和评测器在 https://github.com/dawnvince/SkillAdqBench 。32 个流程型阿里云 Skill、123 条规范化用例，按 Skill 切开，训练和测试不共享 Skill。训练 16 个 Skill、64 条用例、872 条已复核的操作状态。测试 16 个 Skill、59 条用例、840 条记录。64+59=123，872+840=1712。

自动评测器不能拿到参考义务表。它要自己恢复完整操作清单，包括这条用例没练到的操作，再给每条标 covered 或 uncovered。对齐看 command、label、result 的语义，不看覆盖状态；状态在对齐之后再比。对上且状态相同算真正例。多出来的预测、没对上的参考、对上但状态错了，都算进假正例或假负例。主指标是每条用例 F1 的宏平均；没有真正例则该用例 F1 为 0。对齐器是温度 0 的 Qwen3.7-Max，配置固定。这篇没有报告任何自动评测器在这个集合上的 F1。

这些数不能被读成什么

157 是补测前的初评，不是发布后的质量，也不是任务成功率。80% 和 90% 是阿里云的发布政策。分数不证明运行正确。图 2 的 8/10 是示意。49.2% 来自另一项 224 个 SKILL.md 的分类，不是这 157 个的构成。132 份报告没有追踪建议是否被接受。SkillAdeqBench 只有一家云、流程型 Skill，而且没有模型分数。三个 Agent 的一致不是标注者间信度。PDF 是 2026-08-12 的 v3，公开戳记是 2026-07-24。预印本许可证是 arXiv.org perpetual non-exclusive license，这篇只复述口径和汇总数字。

出处：阿里云，Haotian Si、Junyi Chen、Shuyang Yu 等，Are Production Cloud Skills Adequately Tested? Measuring and Governing Skill Test Adequacy in Practice，2026-07-24，https://arxiv.org/abs/2607.22015