3. 提供模板和示例，保证输出稳定如果任务对输出结构要求很高，就应该提供模板。比如测试用例模板：| 用例编号 | 场景类型 | 测试点 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 自动化建议 ||---|---|---|---|---|---|---|---|如果任务对表达风格、分析深度要求很高，就应该提供示例。比如缺陷复盘 Skill 可以给出这样的结构：## 一、问题现象## 二、影响范围## 三、复现路径## 四、根因分析## 五、风险等级## 六、修复方案## 七、回归验证点## 八、后续预防措施模板解决的是格式稳定。示例解决的是表达稳定。两者结合，才能让 Skill 的输出质量更可控。四、第三步：写 Skill 指令时，要控制上下文成本一个常见误区是：Skill 写得越详细，效果越好。其实不一定。Skill 不是独占上下文的。它要和系统提示词、用户输入、历史对话、工具说明、其他 Skill 一起共享上下文窗口。如果 Skill 里塞满了模型本来就知道的通用知识，反而会浪费上下文。例如下面这种内容价值就不高：你是一个专业、严谨、负责的智能助手。你需要认真分析用户需求。你需要给出高质量回答。这些话太通用了。更值得写进 Skill 的，是任务特有的判断和边界：当输入缺少业务规则时，不要自行补全。必须先列出缺失信息，再基于已有内容生成可确认的结果。涉及资金、权限、删除、审批类需求时，必须提升风险等级。Skill 里真正值得保留的是：触发条件任务边界专家判断禁止行为输出模板工具导航验证方式其他通用废话，都应该删除。五、第四步：高风险任务低自由度，分析任务高自由度不同类型的 Skill，对 Agent 的自由度要求不一样。不能所有任务都用同一种写法。1. 高风险任务：必须降低自由度比如：批量修改代码数据库迁移线上配置修改删除文件CI/CD 发布权限策略调整这些任务不能让 Agent 自由发挥。Skill 里必须明确要求：执行任何修改前，必须先输出计划。计划必须包含修改文件、修改原因、影响范围、验证方式和回滚方案。未完成计划验证前，不得直接执行修改。执行后必须运行验证命令。验证失败必须停止，并输出失败原因和修复建议。
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
