1. 任务里有没有专家判断？如果一个任务，熟手和新手做出来差距很大，那它通常适合做成 Skill。比如测试开发场景里：根据 PRD 生成测试用例判断接口测试覆盖是否充分分析线上缺陷根因评估自动化用例是否值得写Review 测试报告是否可信判断一次发版有没有高风险点这些任务不是简单执行步骤，而是包含大量经验判断。新手可能只会根据需求写几个正常流程。但有经验的测试开发会继续追问：有没有异常流程？有没有边界条件？有没有权限问题？有没有数据一致性问题？有没有幂等问题？有没有灰度和回滚风险？哪些场景适合自动化？哪些场景反而不值得自动化？这些判断，才是 Skill 最值得沉淀的部分。Skill 的价值，不是让 Agent “照着做”，而是让 Agent 具备接近专家的判断框架。2. 任务是不是足够复杂？如果一个任务一句 Prompt 就能说清楚，通常没必要做成 Skill。比如：帮我润色这段话。这种任务直接写 Prompt 就够了。但如果任务变成：根据 PRD、接口文档、历史缺陷和业务规则，生成高质量测试用例，并标注优先级、风险点、自动化建议和验收标准。这就明显复杂很多。因为它涉及：输入信息抽取业务流程理解测试场景拆解风险识别优先级判断自动化价值评估输出格式约束质量自检这种任务就很适合沉淀成 Skill。3. 任务会不会反复出现？Skill 的核心价值是复用。如果一个任务只做一次，没必要封装。但如果团队每天、每周都在做类似事情，就很值得 Skill 化。比如：每个需求都要写测试用例每次发版都要做风险评估每次接口变更都要补充自动化用例每次线上事故都要做缺陷复盘每次代码提交都要做质量 Review这些任务一旦沉淀成 Skill，长期收益会非常明显。可以总结成一个判断公式：适合做成 Skill 的任务 =反复出现+ 足够复杂+ 有专家判断+ 对输出质量有要求反过来，如果只是简单、低频、一次性的任务，就不要强行做成 Skill。Skill 不是越多越好，能稳定解决高价值重复问题才重要。
发布于 北京
分享
评论
1
未登录
友善发言
评论
加载中
