一次视频配音任务明确指定使用 B 语音服务 生成口播，Agent 推进到配音环节时，建议将整篇稿件交给 A 语音服务处理。两类服务都能输出音频，但该建议直接偏离了用户给出的明确约束。
看到这种建议，很容易怀疑某个配音 Skill 误触发。但在没有执行轨迹的情况下，能确定的是建议偏离了服务约束，不能确定它为什么偏离。排查时先保留这个区别。
核对当时环境内的可用 Skill，可确认其中有一个通用配音 Skill 固定使用 A 语音服务，要求输入为 script.json，输出逐行时间码与合并音频。目前没有证据表明那次任务读取、选择或调用了该 Skill，无法断言它导致了偏差，仅将其作为分析 Skill 适用边界的参考样本。下面把一次排查拆成三个对象：原始请求写了什么、实际调用了什么、交付物证明了什么。
Skill 不是安装后自动接管任务的开关
很多人把 Skill 理解为"给 AI 新增一项能力"，这个比喻降低了入门门槛，但容易让人误以为安装完成后，所有相关任务都会自动进入正确流程。
以 OpenAI 公开的 Codex 机制为例，Skill 通常是独立目录，核心文件 SKILL.md 中记录名称、描述与工作说明，还可附带脚本、模板与参考资源。Agent 初始阶段仅能看到 Skill 的名称、描述等元信息，判断与当前请求相关后，才会按需读取完整说明与所需资源。也就是说，安装、被发现、被选中、正确执行是相互独立的环节，任意一环出错，都可能出现"装了 Skill 却没得到预期结果"的体验。
下文讨论的均为这套"元信息先发现、按需读全文"的机制，其他 Agent 系统请先核对自身 Skill 加载规则，不要直接套用。
第一类问题是没找到：Skill 的名称或描述没有准确覆盖使用场景；第二类问题是找到了但不该用：任务动词匹配，但服务、约束等核心条件不匹配；第三类问题是用了却未按要求执行：跳过必要步骤，仅生成看似符合要求的文件就结束流程；第四类问题是未做最终验收：流程标记完成，但音频、时间码或调用的服务不符合初始要求。
官方文档也明确区分了 Skill 与工具的定位：工具提供读写或操作的原子能力，Skill 负责定义何时调用工具、按什么顺序执行、最终产物的标准形态。配音 Skill 可以规定"先分段合成、再探测时长、最后输出时间码"，但它本身不是语音模型，也无法凭空调用自身未支持的服务。
"任务相关"和"本次适用"是两个独立判断
回到配音案例，假设这个固定使用 A 服务的 Skill 被当作候选，Agent 看到"使用 A 语音服务，将口播稿合成为音频和逐行时间码"的描述时，遇到"给这篇稿做配音"的请求，它可能进入相关候选。但用户已经明确指定 B 语音服务，这个候选就不再适配本次任务。此处仅做适用性逻辑分析，不还原那次任务的实际调用过程。
进一步拆解这份配音 Skill 的逻辑，它要求将文案整理为指定格式的 script.json，逐句合成音频，探测每段时长，再合并输出 narration.wav 与 timing.json。这些步骤对"使用 A 服务制作可剪辑配音"非常有价值，但任务一旦指定 B 服务，A 服务的合成步骤就不能原样照搬，仅逐句输出时间码的产物要求可以复用，整条服务调用链不能直接沿用。
此时不能以"至少能产出音频"为理由继续执行，正确的决策顺序应当优先保留用户给出的服务约束，再核对当前可用的 Skill 或工具是否支持该约束；如果没有匹配项，就寻找经授权的其他实现路径，或者明确告知用户缺失的条件。悄悄替换用户指定的服务，即便音频最终可以正常播放，也不能判定为任务完成。
这类偏差不限于配音场景：如果写作 Skill 的描述包含"撰写文章、关键词优化、平台适配"，当用户仅要求整理内部讨论用的技术底稿时，Agent 看到"文章"关键词就启动完整 SEO 流程，最终产出公域传播向的平台稿，就偏离了用户的初始需求；如果知识库检索 Skill 的描述仅标注"查询知识库内容"，当用户仅询问"知识库里有没有对应资料"时，Agent 也可能启动 Skill 内的全量宣传材料生成流程，忽略用户只是要一个"有/无"答复的诉求。
这些场景说明 Skill 描述不能只堆砌关键词，至少要回答两个问题：什么目标下应当使用该 Skill，哪些相邻目标下不应当使用。执行前 Agent 还需要把本次任务的格式、服务、权限、数据来源和验收标准，和 Skill 的实际能力逐一核对，用户明确提出的约束优先级应当高于 Skill 的默认规则。
如果维护这份配音 Skill，更清晰的描述可以参考如下示意（仅为改写示例，不代表现有线上配置，也不保证所有平台可直接部署）：
yaml
description: >
当用户有分段口播稿、允许使用 A 语音服务，且需要音频与逐句时间码时使用。
用户已提供真人录音，或明确指定 B 等其他语音服务时不要使用；
后者应先查找匹配的服务与配音流程。额外补充的排除条件，能帮助 Agent 在识别到"配音"动作后，进一步判断该 Skill 是否适配本次任务。
用请求、轨迹和产物定位问题
仅看 Agent 最终返回的"任务已完成"提示，通常无法定位问题：Agent 没有读取 Skill，也可能凭自身通用能力生成看似正常的结果；即便读取了 Skill，也可能漏掉其中的关键步骤。要诊断问题，需要同时核对执行过程和最终产物。
针对具体 Skill，可以设计四类测试请求，以下是尚未执行的测试设计，并非已验证的实测结果：
| 测试请求 | 可观察的通过条件 |
|---|---|
"使用 A 语音服务的配音 Skill 处理 script.json" |
运行记录显示读取该 Skill；产物包含音频和逐句时间码 |
| "使用 A 语音服务给这份口播稿生成逐句配音，后面要按时间码剪视频" | 未点名 Skill，但运行记录显示读取了适用的 Skill；产物满足服务与时间码要求 |
| "已有真人录音，需要对齐字幕" | 运行记录中没有重新合成配音；产物是现有录音对应的字幕时间码 |
| "这期指定使用 B 语音服务生成配音" | 运行记录中没有调用固定使用 A 服务的合成流程；如确实生成音频，实际服务为 B |
每次测试至少记录六项信息：原始请求、候选 Skill 清单、是否读取 Skill、实际调用的服务、产物文件、验收结果。对本文这个案例，按现有证据只能填写：
| 字段 | 当前可确认的值 |
|---|---|
| 原始请求 | 指定 B 语音服务 |
| 可见建议 | Agent 建议 A 语音服务 |
| 是否读取 A Skill | 未知 |
| 实际调用服务 | 未知 |
| 最终音频与时间码 | 未核实 |
这里不能把"建议 A"写成"已调用 A"，也不能把环境中存在 A Skill 写成它已被选择。如果平台不暴露完整运行轨迹，就将"是否读取"字段明确标记为「未知」，不能从最终输出反推调用状态。如果连续多次测试，还需要记录运行环境和 Skill 版本，避免把不同条件下的结果合并统计。
OpenAI 的 Skill 评测文档也提出了同类方法：用明确调用、隐式调用、带干扰信息的调用、"不该调用"的反例组成小型测试集，从执行轨迹和产物两个维度核对触发、步骤、结果，建议将结果、过程、风格与效率分开核验，不要用主观感受代替系统性评测。
通过这套方法可以把问题定位到具体环节：如果该触发却未触发，优先调整名称和描述；如果错用了相邻 Skill，补充排除条件；如果选对了 Skill 却漏掉关键步骤，检查正文说明和配套脚本；如果步骤全部执行但交付物不符合要求，补充验收规则。仅追加通用提示词"请认真遵守 Skill"，通常无法解决分层的定位问题。
普通使用者不需要维护 Skill 文件，也可以通过优化任务描述降低误选概率。与其仅说"制作配音"，不如同时明确四部分信息：要做什么、已有何种素材、必须使用或避开什么服务、怎样算完成。例如："把这份口播稿生成中文双人配音，使用 B 语音服务；保留逐句时间码，最后提供一段可试听音频。"明确的约束能帮助 Agent 排除仅在动词上相似的不相关流程。如果确认某个 Skill 完全适配当前任务，也可以明确点名调用，降低"未被发现"的不确定性，但点名调用不会自动修复 Skill 本身的逻辑缺陷，也不能覆盖本次任务提出的服务和格式要求。产物交付后，还要核对实际文件、执行记录与关键约束，不能仅以 Agent 的完成提示作为验收依据。
Skill 维护者可以从实际误用场景反推 Skill 的边界定义，与其写"适用于一切视频制作"，不如写明"输入已经定稿的分段口播文本；允许使用 A 语音服务；输出音频和逐句时间码；用户提供了录音或指定了其他配音服务时不使用"。把具体执行步骤放在 Skill 正文，较长的参考材料和配套脚本设置为按需加载，为容易混淆的相邻任务准备反例。官方资料也明确指出，清晰的使用边界和渐进加载机制，比把所有指导一次性塞进描述字段更有效。
一个 Skill 的价值不在于安装列表里多了一个条目，而在于用户下次提出同类任务时，它能在该出现时被选中，不该出现时主动让路，执行后交付符合约束的合格结果。如果某次任务出现偏差，先把它还原为三个可核查的问题：Agent 当时看到并选中了什么候选？它判断该候选适用于本次约束的依据是什么？最终产物和执行轨迹能证明什么？能清晰回答这三个问题，Skills 才能从"存储了一份流程的文件夹"，变成真正可复用的工作方法。