在实践中一般可以通过Skill创建器例如Codex自带的 Skill Creator来协助创建Skill但是高质量的Skill的标准需要我们自己来把关推荐通过下面五个流程来创建Skill。标准答案参考在实践中一般可以通过Skill创建器例如Codex自带的 Skill Creator来协助创建Skill但是高质量的Skill的标准需要我们自己来把关推荐通过下面五个流程来创建Skill判断这个任务值不值得封装提取专家决策和常见反模式把指令写得简洁且约束合适配齐模板、参考资料和脚本用真实任务反复验证执行效果编写高质量skill流程详解一、判断任务值不值得做成skill1. 任务里有没有“专家直觉”如果一个任务里熟手和新手的差距主要体现在边界判断、风险识别、优先级取舍那它就很适合做成 Skill。2. 任务是不是足够复杂如果一个任务一句 Prompt 就能说清或者三步以内就能完成通常没必要专门做成 Skill。Skill 不是越多越好。它有维护成本要写说明、配资源、做测试、反复迭代。3. 任务会不会反复出现Skill 的价值在复用。如果你的团队每周都会做类似的分析、审核、发布、改写或生成任务那么把它沉淀成 Skill长期收益通常很高。当一个任务同时具备以上这三个特征时建议投入去做成Skill。二、提取 Skill 该写什么确定任务需要做成skill后按照下面步骤来提取Skill需要做什么1. 提取决策树高质量的 Skill 应该告诉 Agent什么条件下走方案 A什么条件下切到方案 B什么情况下应该停止、降级或者补充信息2. 提取反模式和不要做的事情在工程里反模式往往非常重要比如不要把来源不明的内容当成事实写进输出不要在高风险操作里直接执行修改应该先生成计划再验证不要为了把结果写完整擅自编造缺失信息3. 提取模板和示例如果任务对输出结构要求很高那么可以使用模板来描述如果任务对表达风格、组织方式要求很高那就使用示例来说明。三、写清楚指令Skill里面的指令要符合三个原则1. 简洁Skill不是独占上下文的还要和 system prompt、对话历史、其他技能信息一起共享窗口所以每一句话都要值回它的 token 成本。原则很简单模型本来就知道的东西不要重复教只有任务特有的判断、约束、入口和资源导航才值得写进 Skill。2. 自由度匹配如果任务本身风险很高比如批量改文件、数据库迁移、部署执行那就应该给低自由度约束必要时直接要求调用固定脚本。如果任务本身需要分析、判断、归纳比如代码审查、内容策划、方案评估那就应该保留更高自由度只给流程边界和质量标准。3. 渐进式披露不要把所有细节都塞进SKILL.md按照下面这些原则组织主文件里只保留核心流程、触发条件和资源导航详细规则放到references/需要确定性执行的动作放到scripts/四、配好工具和资源对一些具有标准流程的子任务不要让大模型来猜用工作流来写清楚任务要求。1. 给 Agent建立工作流在复杂任务里checklist非常重要因为任务链一长如果没有中间进度和阶段目标Agent 很容易漏步骤一个工作流示例如下先抽取输入、再运行检查、然后整理问题、修复后重新验证、最后再生成结果。2. 把验证做成闭环如果任务需要校验Skill 里不要只写“执行完即可”写成反馈循环运行验证器、读取结果、修复问题、再次运行验证器、通过后再进入下一步。3. 高风险操作先过计划再执行如果任务涉及大规模修改、高成本调用或者不可逆操作最好再加一层“先验证计划”的前置检查。4. 脚本要对 Agent 友好Skill如果有脚本要符合以下要求输出最好结构化优先 JSON错误信息里要带修复线索不要只返回一个exit code能降级就降级不要一出错就直接崩尽量幂等避免 Agent 重复调用时把结果越做越乱五、用真实任务验证再迭代 Skill在应用实践中我推荐一套很实用的迭代方式如下图所示1. 先建立基线先不用任何 Skill让 Agent 直接做一次真实任务。记录它会犯哪些典型错误哪些信息需要你反复补充这些失败样本后面就是 Skill 的评测用例。2. 再提取 Skill 初稿根据上面提到的内容标准整理Skill 的首版哪些是固定流程哪些是判断标准哪些是常见错误哪些应该由脚本负责3. 用新会话重新测试换一个全新的会话按真实使用方式重新跑评测用例如果在新会话里任务效果明显更好说明 Skill 真正起作用了。4. 持续迭代直到结果稳定这一步主要是验证不同场景多次执行任务观察效果当然也可以建立测评集持续优化。
在实践中一般可以通过Skill创建器例如Codex自带的 Skill Creator来协助创建Skill但是高质量的Skill的标准需要我们自己来把关推荐通过下面五个流程来创建Skill。标准答案参考在实践中一般可以通过Skill创建器例如Codex自带的 Skill Creator来协助创建Skill但是高质量的Skill的标准需要我们自己来把关推荐通过下面五个流程来创建Skill判断这个任务值不值得封装提取专家决策和常见反模式把指令写得简洁且约束合适配齐模板、参考资料和脚本用真实任务反复验证执行效果编写高质量skill流程详解一、判断任务值不值得做成skill1. 任务里有没有“专家直觉”如果一个任务里熟手和新手的差距主要体现在边界判断、风险识别、优先级取舍那它就很适合做成 Skill。2. 任务是不是足够复杂如果一个任务一句 Prompt 就能说清或者三步以内就能完成通常没必要专门做成 Skill。Skill 不是越多越好。它有维护成本要写说明、配资源、做测试、反复迭代。3. 任务会不会反复出现Skill 的价值在复用。如果你的团队每周都会做类似的分析、审核、发布、改写或生成任务那么把它沉淀成 Skill长期收益通常很高。当一个任务同时具备以上这三个特征时建议投入去做成Skill。二、提取 Skill 该写什么确定任务需要做成skill后按照下面步骤来提取Skill需要做什么1. 提取决策树高质量的 Skill 应该告诉 Agent什么条件下走方案 A什么条件下切到方案 B什么情况下应该停止、降级或者补充信息2. 提取反模式和不要做的事情在工程里反模式往往非常重要比如不要把来源不明的内容当成事实写进输出不要在高风险操作里直接执行修改应该先生成计划再验证不要为了把结果写完整擅自编造缺失信息3. 提取模板和示例如果任务对输出结构要求很高那么可以使用模板来描述如果任务对表达风格、组织方式要求很高那就使用示例来说明。三、写清楚指令Skill里面的指令要符合三个原则1. 简洁Skill不是独占上下文的还要和 system prompt、对话历史、其他技能信息一起共享窗口所以每一句话都要值回它的 token 成本。原则很简单模型本来就知道的东西不要重复教只有任务特有的判断、约束、入口和资源导航才值得写进 Skill。2. 自由度匹配如果任务本身风险很高比如批量改文件、数据库迁移、部署执行那就应该给低自由度约束必要时直接要求调用固定脚本。如果任务本身需要分析、判断、归纳比如代码审查、内容策划、方案评估那就应该保留更高自由度只给流程边界和质量标准。3. 渐进式披露不要把所有细节都塞进SKILL.md按照下面这些原则组织主文件里只保留核心流程、触发条件和资源导航详细规则放到references/需要确定性执行的动作放到scripts/四、配好工具和资源对一些具有标准流程的子任务不要让大模型来猜用工作流来写清楚任务要求。1. 给 Agent建立工作流在复杂任务里checklist非常重要因为任务链一长如果没有中间进度和阶段目标Agent 很容易漏步骤一个工作流示例如下先抽取输入、再运行检查、然后整理问题、修复后重新验证、最后再生成结果。2. 把验证做成闭环如果任务需要校验Skill 里不要只写“执行完即可”写成反馈循环运行验证器、读取结果、修复问题、再次运行验证器、通过后再进入下一步。3. 高风险操作先过计划再执行如果任务涉及大规模修改、高成本调用或者不可逆操作最好再加一层“先验证计划”的前置检查。4. 脚本要对 Agent 友好Skill如果有脚本要符合以下要求输出最好结构化优先 JSON错误信息里要带修复线索不要只返回一个exit code能降级就降级不要一出错就直接崩尽量幂等避免 Agent 重复调用时把结果越做越乱五、用真实任务验证再迭代 Skill在应用实践中我推荐一套很实用的迭代方式如下图所示1. 先建立基线先不用任何 Skill让 Agent 直接做一次真实任务。记录它会犯哪些典型错误哪些信息需要你反复补充这些失败样本后面就是 Skill 的评测用例。2. 再提取 Skill 初稿根据上面提到的内容标准整理Skill 的首版哪些是固定流程哪些是判断标准哪些是常见错误哪些应该由脚本负责3. 用新会话重新测试换一个全新的会话按真实使用方式重新跑评测用例如果在新会话里任务效果明显更好说明 Skill 真正起作用了。4. 持续迭代直到结果稳定这一步主要是验证不同场景多次执行任务观察效果当然也可以建立测评集持续优化。
