八、第七步：一定要关注 Skill 的触发质量很多人只关注 Skill 内容写得好不好，却忽略了一个更基础的问题：Agent 能不能在正确的时候调用这个 Skill？一个 Skill 如果触发不稳定，也很难算高质量。常见问题有两类。第一类是该触发时没触发。比如用户明明输入了：根据这个 PRD 帮我生成测试用例。但 Agent 没有调用“测试用例生成 Skill”，而是直接用普通对话方式回答。第二类是不该触发时乱触发。比如用户只是想简单问一个测试概念，Agent 却误触发了复杂 Skill，开始输出一大堆流程和表格。所以 Skill 的名称和描述非常重要。它们不是摆设，而是 Agent 判断是否调用 Skill 的重要依据。一个好的 Skill 描述，应该写清楚：这个 Skill 用于根据 PRD、接口文档或业务需求生成结构化测试用例。适用于需要输出测试场景、优先级、风险点和自动化建议的任务。不适用于简单概念解释、单句润色或无需结构化测试设计的任务。注意，这里不仅写了“什么时候用”，还写了“什么时候不用”。这能减少误触发，提高 Skill 的稳定性。九、第八步：验证闭环是高质量 Skill 的关键很多 Skill 效果不稳定，不是因为写得不够长，而是因为没有验证闭环。一个高质量 Skill，不能只写：完成后输出结果。而应该写成：完成初稿后，必须根据 checklist 自检：- 是否覆盖主流程- 是否覆盖异常流程- 是否覆盖边界条件- 是否标注优先级- 是否存在编造业务规则- 是否存在无法验证的结论- 是否给出自动化建议如果检查不通过，必须先修正，再输出最终结果。这就是反馈循环。对于能脚本化验证的内容，最好交给脚本，不要完全依赖模型自检。比如：Markdown 表格格式检查JSON Schema 校验文件命名规范检查测试用例字段完整性检查链接有效性检查代码格式检查单元测试执行可以写一个简单的校验脚本：
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
