点击蓝字
关注我们
一、 测试人员为什么要关注 Skill 开发
在传统软件开发中，测试人员的职责边界很清晰：产品写好需求，开发写好代码，测试负责验证。但在 AI Agent 的场景下，这个边界变得模糊了。
当我们给 Agent 装备了一个 Skill（技能扩展包）时，Skill 本身就成了一个“黑箱组件”——它的触发逻辑、执行路径、错误处理都会直接影响最终产出质量。
换句话说：如果 Skill 写得不好，即使大模型本身能力再强，输出也会“跟着跳坑”。而测试人员恰恰是最擅长“找坑”和“填坑”的角色。
本文不是一篇通用的 Skill 开发教程。它的特殊之处在于：全程从测试人员的视角出发，关注的不是“怎么写”而是“怎么写才不会出问题”，并用实际试验数据而非理论推演来支撑每一个结论。
1.1 Skill 质量问题的“辐射半径”
一个写得不好的 Skill 会向外“辐射”出多种质量问题，而且往往不是发生在 Skill 自身范围内：
● 触发漂移：用户问了一个无关问题，Agent 却加载了这个 Skill，产出偏离预期。
● 流程断裂：Skill 指引的操作步骤有缺失，Agent 在半路不知所措，输出不完整。
● 环境不兼容：Skill 中的脚本在某个操作系统上报错，但换一台机器就好，难以复现。
●输出波动：同样的输入，两次执行结果不一样，让回归测试形同虚设。
这些问题的根源往往不在大模型，而在于 Skill 的设计质量。因此，测试人员越早介入 Skill 开发，就越能有效地预防这类“辐射性缺陷”。
二、用测试思维解构 Skill 的结构
一个 Skill 由一个必需的 SKILL.md 和三类可选资源组成。但测试人员不需要记忆复杂的目录规则，只需要理解一个原则：每个文件都对应一种质量风险，也对应一种测试策略。
2.1 SKILL.md：触发准确性的“守门人”
SKILL.md 是每个 Skill 的必备文件，分为两部分：开头的 YAML 元数据定义了“触发条件”，后面的 Markdown 正文定义了“执行流程”。
从测试视角看，元数据中的 description 字段是整个 Skill 最关键的质量缺口。它决定了 Agent 何时加载这个 Skill，写得不好就会导致触发漂移或触发漏失。正文则是 Agent 被触发后的操作指南，流程不清晰就会导致执行断裂。
---name: pdf-rotatordescription: Rotate PDF pages. Use when user asks torotate, flip, or change orientation of a PDF.name_cn: PDF旋转description_cn: 旋转或翻转PDF页面方向---# PDF旋转1. 确认文件路径存在2. 解析用户指定的旋转角度（默认90°）3. 调用 scripts/rotate_pdf.py 执行
2.2 三类可选资源及其质量风险
● scripts/（可执行脚本）：质量风险——环境依赖、异常未捕获、路径处理错误。测试策略——单元测试 + 边界值 + 多平台验证。
● references/（参考文档）：质量风险——信息过时、与实际接口不一致。测试策略——定期核查文档与实际系统的一致性。
● assets/（输出素材）：质量风险——模板损坏、字体缺失。测试策略——对比检查素材完整性。
文件夹结构示例：
pdf-rotator/SKILL.md # 必备：触发 + 流程scripts/rotate_pdf.py # 确定性操作封装为脚本references/pdf_api_spec.md # 参考文档按需加载assets/default_output.pdf # 输出素材
2.3 渐进式加载与质量风险的关系
Skill 采用三层渐进式加载：元数据始终在上下文中（100 字左右），正文触发后加载，附加资源按需加载。这意味着上下文窗口资源的“爆仓”风险在这一层被分救了，但并非完全没有：
● 元数据始终占用上下文→ 写得冗长会挤压其他信息的空间，降低 Agent 整体表现
● 正文触发后加载→ 过长的正文会导致“注意力稀释”，关键指令被淡化
● 脚本可以不加载而直接执行→ 节省上下文占用，同时也封锁了确定性行为
测试视角的核心原则
Skill 应该只补充“大模型不知道的”信息。如果一段内容删掉后 Agent 仍能正确执行，那这段内容就是多余的——它不仅浪费上下文，还可能干扰决策。
三、六条质量原则:
测试人员的Skill开发守则
以下六条原则均来自实践中的缺陷复盘，而非理论推导。每条原则背后都有真实的“踩坑”场景。
3.1 description 要精准而非全面
缺陷复盘：某“PDF 处理”技能的 description 列举了旋转、合并、拆分、添加水印等 6 种功能。结果用户说“帮我编辑 PDF 里的文字”时也触发了该技能，产出了无关内容。
原则：description 只写“做什么 + 什么时候用”，1–2 句话即可。不列举覆盖范围，只用“核心场景”筛选。
3.2 正文要有骨有肉但不冗长
缺陷复盘：合同审查技能的 SKILL.md 正文超过 400 行，把所有法律条文都贴进去。实际测试中发现，正文超过 300 行后，三层审查的覆盖率反而下降（从 89% 跌到 83%），因为“注意力被稀释了”。
原则：正文只写流程步骤和关键约束，宦规细则和参考材料放在 references/ 目录中由 Agent 按需加载。110 到 150 行是实践中的最佳区间。
3.3 确定性操作必须封装为脚本
缺陷复盘：一个“PDF 合并”任务让 Agent 从零写代码，20 次执行有 7 次失败。原因包括：用了环境未装的库、Windows 反斜杠未转义、用了 PowerShell 5.1 不支持的语法。同样的任务封装为脚本后，20 次仅 1 次失败（文件不存在，属于预期内失败）。
原则：只要是“同样输入应得到同样输出”的操作，就应该封装为脚本。脚本的确定性意味着可重现性，可重现性意味着可测试性。
3.4 每个脚本必须有异常处理
缺陷复盘：旋转 PDF 的脚本未处理“文件不存在”的情况。当用户给出一个不存在的路径时，脚本直接报系统错误并中断，Agent 将堆栈信息原封不动地呈现给用户。
原则：脚本必须对常见异常做防御性处理——捕获异常并输出友好提示，而非抛出原始错误。至少覆盖：文件不存在、格式不支持、参数超出范围。
def rotate_pdf(path, angle=90):ifnot os.path.exists(path):print(f'Error: File not found: {path}')return Falseifnot path.lower().endswith('.pdf'):print('Error: Only PDF files are supported')return False# ... 正常逻辑 ...
3.5 不放任何“给人看”的文件
缺陷复盘：某团队在 Skill 中放了 README.md、CHANGELOG.md、开发日志.md。这些文件对 Agent 执行任务没有任何帮助，碰巧被加载后反而占用了上下文窗口，导致关键指令被截断。
原则：Skill 是给 Agent 用的操作手册，不是给开发者看的项目文档。只放 Agent 执行任务所必需的文件。
3.6 自由度与可测试性成反比
给 Agent 的自由度越高，行为的不确定性就越大，回归测试就越难做。因此要根据任务特点设定恰当的自由度：
经验法则
如果一个步骤写错会导致数据损坏或文件损坏，那就必须用低自由度的方式书写——即明确写步骤顺序和约束条件，而不是只写目标让 Agent 自己探索。
四、开发流程：六步走完一个 Skill
以下流程不同于常见的“先写再测”模式。测试人员从第一步就参与，每一步都内嵌了质量检查点。
4.1 明确触发域与执行域
先回答两个问题：用户的哪些请求应该触发这个 Skill？Agent 被触发后需要哪些“外部知识”才能完成任务？第一个问题决定 description，第二个问题决定要不要 scripts 和 references。
测试检查点：列出 5–10 条边界请求（应触发但可能不会触发的、不应触发但可能误触发的），作为后续验证的基准。
4.2 规划资源布局
根据第一步的分析，确定哪些操作封装为脚本、哪些知识放入参考文档、哪些素材放入 assets。判断标准很简单：“同样输入是否应该得到完全相同的结果”——如果是，封装为脚本；如果不是，写在正文中留给 Agent 判断。
4.3 初始化目录结构
运行初始化脚本生成模板：
python scripts/init_skill.py my-skill --path ~/.config/skills/模板包含占位符，替换为实际内容即可。不需要的示例目录直接删除。
4.4 编写脚本和文档
脚本侧重点：异常处理、参数校验、友好提示。写完后必须在目标环境实际运行一遍。
SKILL.md 侧重点：流程步骤清晰、约束条件明确、description 精准。正文控制在 150 行以内。
4.5 验证与注册
python scripts/quick_validate.py my-skillpython scripts/add_skill_remote.py my-skill/SKILL.md
验证脚本检查元数据完整性和命名规范。注册后刷新技能列表即可使用。
4.6 回归测试与迭代
上线后持续收集触发偏差和执行异常，回流到 Skill 进行修正。常见迭代场景：
● 触发漂移→缩窄 description 描述范围
● 流程断裂→补充步骤或约束条件
● 输出波动→将该步骤封装为脚本
五、实践与试验结果
下面的每组试验都经过实际运行，数据可复现。我们的目标不是证明某种写法“绝对正确”，而是用数据揭示不同策略的质量边界。
5.1 试验一：description 精准度与触发准确率
对象：一个 PDF 旋转技能。测试集：30 条用户请求，其中 20 条应触发、10 条不应触发。三种 description 写法分别测试。
结论：简短写法漏触发严重，列举写法误触发激增。“两句式”——一句说功能，一句说场景——取得了最佳平衡。
5.2 试验二：正文长度与任务完成质量
对象：合同审查技能（需完成基础层、业务层、法律层三轮审查）。同一份合同，三种长度的正文对比。
结论：30 行版信息严重不足；450 行版“注意力稀释”导致覆盖率和格式规范双双下降；120 行版在三个维度均表现最优。这说明 Skill 正文存在一个“最优精简区间”，而非越精简或越详细越好。
5.3 试验三：脚本封装与代码生成的稳定性对比
对象：PDF 合并任务。对比“从零写代码”与“调用封装脚本”两种模式，各运行 20 次。
进一步拆解“从零写”的失败样本，三大高频问题：
● 依赖缺失（40%）：生成的代码引用了环境未装的库。
● 路径处理错误（35%）：Windows 反斜杠未转义、空格路径未加引号。
● 语法不兼容（25%）：用了 PowerShell 5.1 不支持的 await 等语法。
结论：封装为脚本后成功率和一致性大幅提升。核心原因是脚本的确定性——同样的输入永远得到同样的输出，而生成代码的每次微小差异都可能引入错误。特别在 Windows 环境下，路径处理和编码兼容性是重灾区。
5.4 试验四：异常处理对用户体验的影响
对象：PDF 旋转技能。对比有无异常处理的两个版本，分别传入 10 组异常输入（不存在的文件、非 PDF 文件、负数角度等）。
结论：没有异常处理时，80% 的异常输入导致原始错误堆栈直接暴露给用户，大部分用户不知道该怎么办。加上异常处理后，90% 的反馈都是清晰可操作的提示，用户可以根据提示自行纠正输入。
关键洞察
异常处理的价值不在于“防止报错”，而在于“报错时给出有意义的引导”。对于测试人员而言，这意味着每个脚本的异常分支和正常分支同样重要，都应该被纳入测试用例。
六、总结：三条核心发现与速查清单
6.1 三条核心发现
● 发现一：description 要“精准而非全面”。“两句式”写法（一句功能、一句场景）触发准确率 83%，显著优于简短一句的 50% 和列举多场景的 67%。
● 发现二：SKILL.md 正文要“有骨有肉但不冗长”。120 行版在覆盖率、格式规范、效率三个维度均优于 30 行版和 450 行版。存在明确的“最优精简区间”。
● 发现三：确定性操作必须封装为脚本，且脚本必须有异常处理。封装后成功率 95%、输出一致性 100%；异常处理将友好提示率从 10% 提升到 90%。
6.2 Skill 质量速查清单
每次发布新的 Skill 或迭代现有 Skill 时，用这张清单自查：
E n d
声明：本文为51Testing软件测试网 刘晓佳Rachel 用户投稿内容，该用户投稿时已经承诺独立承担涉及知识产权的相关法律责任，并且已经向51Testing承诺此文并无抄袭内容。发布本文的用途仅仅为学习交流，不做任何商用，未经授权请勿转载，否则作者和51Testing有权追究责任。如果您发现本公众号中有涉嫌抄袭的内容，欢迎发送邮件至:editor@51testing.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
