1. 从官方文档里挖出的三个Skill改进思路先交代一下背景。最近Anthropic官方放出了一份关于Skill编写的实践建议主题是“让你的Skill工作流变得更好用”。我仔细读完之后最大的感受是官方文档没有教你怎么写一个能跑的Skill——那太基础了——它真正在讲的是怎么把一个“勉强能用”的Skill打磨成一个“真正顺手”的Skill。这里先给还不熟悉Skill的读者补个底。所谓Skill在Anthropic的语境里就是一组结构化的指令包通常包含技能描述、触发条件、使用步骤、示例和输出规范。你可以把它理解成给AI写的一本“操作手册”告诉它什么时候该用这个技能、具体怎么用、输出长什么样。跟普通Prompt相比Skill最大的区别在于它是可复用、可组合、可版本化的——你不需要每次都在对话里重复一大堆背景说明而是把它封装成一个独立单元随取随用。我自己在过去几个月里用Claude的Agent SDK和Skill机制做了不少实际项目从小的文档处理脚本到多步骤的调研工作流都试过。踩过不少坑也总结出了一些行之有效的技巧。这篇文章就结合官方的最佳实践把三个我认为最关键的改进思路拆开来讲每个都会配上具体的实操示例和踩坑记录。先说一个总体的判断很多人写Skill容易犯两个极端——要么写得太粗一句话完事AI根本不知道边界在哪要么写得太细事无巨细全塞进去结果AI反而被冗长的指令拖慢甚至出现“选择性失明”——关键规则淹没在无关紧要的细节里。官方这次给出的三个技巧恰好就是针对这两个极端问题的。2. 技巧一把“隐式知识”变成“显式规则”2.1 为什么Skill经常“看起来懂了实际没懂”我第一个要讲的核心技巧是官方文档里反复强调的一点不要假设模型能自动理解你脑子里的隐含逻辑要把所有决策依据都写出来。举个例子。之前我写过一个用于“会议纪要整理”的Skill。最初版本是这么写的将会议录音转写文本整理为会议纪要提取行动项和负责人。看起来没问题对吧但实际跑起来AI给我的结果总是差一口气。比如它把“讨论过程”也当成行动项提取进去了。它分不清“张总说下周给方案”和“张总建议李工下周给方案”的区别把建议者也当成了负责人。它把“尽快”“近期”这类模糊时间词直接保留而没有转成具体日期。问题就出在我“以为AI懂”但实际上AI并不懂什么叫“行动项”、什么叫“负责人”、什么叫“可执行的下一步”。这些在我脑子里是常识的知识对模型来说只是一堆模糊的自然语言。2.2 显式化的具体做法用“决策树”而不是“描述句”官方最佳实践里提了一个非常关键的点与其告诉Skill“要做什么”不如告诉它“在什么情况下怎么做选择”。受这个思路启发我把上面的Skill改成了带决策逻辑的版本。核心部分是这样设计的对于转写文本中的每一段发言按以下顺序判断它是否需要提取为行动项 1. 该发言是否包含一个明确的待办事项动词目标时间 - 是继续下一步判断 - 否跳过不作为行动项 2. 该待办事项的负责人是谁 - 若说话者直接承诺自己完成负责人为说话者本人 - 若说话者将任务指派给其他人负责人为被指派者 - 若说话者仅提出建议但未明确指派则标记为“待确认”不要臆测负责人 3. 该待办事项的截止时间如何确定 - 文本中有明确日期直接采用 - 文本中有“明天”“下周”等相对时间词以本次会议日期为基准换算成具体日期 - 无任何时间信息标记为“未设定”不要随意猜测改完之后同样的输入AI输出的行动项准确率高了很多。最明显的变化是它不再把“讨论性发言”误判成“行动项”了也学会了遇到不确定信息时标注“待确认”而不是硬编一个答案。2.3 实操心得从“你的输出不对”反向推导规则这里分享一个我自己反复使用的推导方法。当你发现Skill输出不符合预期时不要只改Prompt让它“注意一点”而要去问AI“你是怎么判断的”——注意不是让AI改输出而是让它描述自己的推理过程。这一步特别有价值因为它会暴露你规则中的漏洞。比如我那个会议纪要Skill当时AI解释自己提取负责人时“根据发言上下文推断张总可能是负责人”。这就是问题根源AI在用“可能”“推测”的方式做决策而真正可靠的Skill应该让AI只依据文本中明确的指认关系来决策没有明确指认就标记待确认。当我把这条明确写进规则后输出稳定性一下就上来了。注意这里的关键不是告诉AI“不要猜测”而是给它一套“什么情况下可以判断、什么情况下不能判断”的明确标准。光喊口号式的“不要瞎猜”对模型约束力很弱因为模型并不知道“瞎猜”在你这里的具体定义是什么。3. 技巧二为Skill设计清晰的“触发-执行-终止”边界3.1 不清边界带来的典型问题第二个技巧是我在实际使用中感受最深的一个。官方文档里专门提到了Skill应该明确“何时该用”和“何时不该用”但很多人写Skill时容易忽略这个问题或者说根本没想到要规定“何时不该用”。一个真实案例。我写过一个小工具类Skill用来将碎片化笔记整理成结构化文档。最初版本是这样将用户提供的笔记整理为结构化文档包含标题、摘要、正文、要点。听起来很通用对吧结果在真实使用中就翻车了。用户有时候提供的是闲聊内容有时候是已经整理好的文章有时候是一堆诗或者心情记录这个Skill照样一股脑全给塞进“摘要正文要点”的框架里。把一首诗整理成“要点1、要点2、要点3”这体验能好吗问题就出在这个Skill的触发条件写得太宽了——只要用户说“帮我整理笔记”它就触发但它又缺乏终止条件——没规定“什么情况下这个Skill不应该使用”。3.2 三条边界规则的具体写法基于这个教训我后来把Skill的边界设计分为三层第一层强触发条件。明确列出哪些情况下Skill必须启用包括可以量化的特征比如输入格式、关键词、用户的意图标志。触发条件满足任一即可 - 用户明确要求“整理”“结构化”“做笔记”“重排格式” - 用户输入内容超过300字且包含多个独立主题 - 用户输入包含明显的信息层级如列表、编号、章节标题第二层模糊区判断。列出那些容易被误判为触发、但实际上不该触发的情况告诉AI遇到这种情况应该怎么做。模糊区以下情况请与用户确认后再执行 - 用户输入以闲聊开头且未明确表达整理意图 - 用户已经提供了一份成品文档仅希望发表评论或修改意见 - 用户输入是诗歌、小说、对话稿等非说明性文体 处理方式先回复一句简短的确认语例如“我注意到这看起来像是X类型内容你希望我按结构化笔记处理还是保持原样”第三层终止条件。这个很多人完全没想过。一个Skill不能是万能的必须有明确的终止条件——当AI发现输入超出自己的能力范围或授权范围时应该主动停止。终止条件满足任一即可停止处理 - 用户输入涉及医疗诊断、法律裁决、金融投资等专业决策且用户要求输出权威结论 - 用户要求删除或篡改已有文档中的关键信息且无合理授权 - 用户要求将整理结果用于明显不当的用途如伪造记录这三个边界划分到位后这个Skill的“存在感”反而变低了——因为它在不该出现的时候会主动退出而不是硬着头皮处理。用户也说不清哪里变了但整体体验就是“舒服了”。这就是好Skill的特质平时低调需要时可靠。3.3 和Agent工作流的配合方式顺带说一个与边界相关的进阶用法。如果你把Skill嵌在Agent工作流里使用比如通过Claude Agent SDK那边界规则还有一个额外价值——它可以帮Agent节省大量的无效调用。我在一个调研类Agent里挂了多个Skill分别处理资料收集、文档生成、数据提取。过去因为Skill边界不清Agent经常在错误的时间调用错误的Skill比如用户明明在闲聊Agent却莫名其妙触发了一次“资料收集”。加上边界规则后Agent会先根据对话内容判断该不该调Skill、调哪个而不是一上来就盲目调用。这个优化看起来不起眼但对Token消耗和响应速度的影响非常明显尤其是在跑比较长的工作流时。4. 技巧三用“示例驱动”替代“规则堆砌”4.1 模型更擅长模仿而不是遵循抽象指令第三个技巧来自官方文档里关于“Few-shot示例”的强调。Anthropic官方在多个场合都提过给模型看具体的输入输出示例比给它写十条抽象规则更有效。这其实很符合语言模型的工作机制——它是靠预测下一个token来生成内容的给它看一个“标准答案”的分布它会自然地模仿而给它看一堆规则它需要先将规则“翻译”成输出分布这个翻译过程就容易丢信息。我自己早期写Skill的时候习惯用大段大段的“要求”“必须”“禁止”。后来发现规则写得越多模型反而越容易“跑偏”。一个很典型的现象你列了十条规则模型可能会完美遵守前三条然后从第四条开始逐渐“遗忘”但如果给三条示例模型几乎能完整复现示例中的输出风格和细节处理方式。4.2 如何设计高质量示例示例的质量直接决定Skill的表现。这里分享几个我总结的设计要点示例要覆盖“典型情况”而不是“极端情况”。很多人喜欢给Skill配一个特别复杂的示例来展示能力上限但实际使用中模型遇到最多的反而是常规情况。所以示例应该尽量贴近日常输入让模型掌握“常规输出长什么样”然后再额外给一个“略复杂”的示例展示如何处理边界。示例要展示完整过程而不只是输入输出。最好的示例是带“推理过程”的。在示例中用注释的方式展示AI是如何一步步得出最终结果的。这比只给配对的输入输出更有效因为模型能看到你希望的决策路径。下面是我在一个“信息提取Skill”里使用的示例片段结构可以直观感受到这种带过程注释的示例示例输入 “小张上周五把项目报告发给了刘总刘总看完后觉得数据部分需要补充让小王这周二之前重新统计并更新。” 示例处理过程 - 识别关键事件项目报告提交上周五、审阅反馈数据部分需补充、重新统计任务这周二前 - 任务负责人小王刘总指派非原说话者 - 截止时间这周二以文档生成日期为基准换算若文档中未记录今天日期则标记为待确认 - 输出行动项 1. 负责人小王”任务重新统计项目报告数据截止时间这周二请确认具体日期状态进行中这个示例的价值在于它不仅告诉模型“要提取什么”还告诉模型“遇到模棱两可的信息时应该怎么处理”。4.3 示例的“最小必要数量”经验关于示例数量一个常见的疑问是“到底放几个示例合适”。我的经验是3-5个高质量示例通常是最优区间。少于3个模型对输出风格的把握不够稳多于5个Skill体积变大同时Token消耗也随之上升而带来回报的边际效益却不明显。如果Skill涉及多种类型输入比如同时处理会议纪要、文章笔记、日程记录建议按类型各给1-2个示例而不是只给一种类型的多个示例。这样能帮助模型把不同输入映射到不同的输出模式比单一类型堆示例效果更好。下面是一个对比效果表来自我自己做过的一组小实验示例数量输出风格稳定性输出格式准确率处理“模糊输入”的能力平均Token消耗0个示例差风格漂移低格式随意差不知道怎么办最低但返工多1个示例一般会模仿中较差中等3个示例稳定高中上适中5个示例很稳定高好略高10个示例稳定但过度死板极高反而下降过于依赖模板消耗明显增加每次打磨Skill遇到棘手情况我首先动手调整的就是示例部分而不是去加规则——这是一个屡试不爽的方向。5. 实操案例将三个技巧应用到“简历筛选Skill”到这里如果只是泛泛讲技巧多少有点“纸上谈兵”。下面用一个完整的实操案例把上面三个技巧串起来展示它们是如何在一个真实的Skill里协同生效的。这个案例我会结合一个使用频率很高的场景简历筛选 Skill——毕竟招聘HR和团队Leader经常会用到它来大批量筛选投递简历。5.1 场景需求与Skill目标假设我们收到了一大批简历希望用Skill快速完成初筛分类、标记优势点、给出建议。目标不是“替代HR判断”而是将简历中的关键信息提炼出来降低HR逐份阅读的时间成本。在动笔之前先明确几个设计决策输出要结构化。一份简历筛选结果应该包含候选人基本信息、匹配度评分、核心优势、风险点、建议。这样团队可以批量对比而不需要每份都翻原始简历。评分标准要明确。匹配度评分不应该是一个模糊的“8分”而要能解释为什么给8分。功能上需要给出评分依据清单。边界要设定好。该Skill无法验证简历真伪也无法代替面试判断这些要在输出中明确标识防止AI“越权”。5.2 构建Skill的核心结构基于上面的目标我设计了如下Skill结构简化版示意技能名称简历筛选助手 触发条件 - 用户提供一份或多份简历文本 - 用户要求进行简历评估、筛选、排序 处理流程 1. 提取基本信息姓名、年龄、学历、工作经验年限、当前岗位、期望岗位 2. 提取技能栈技术栈、工具、行业领域经验、证书资质 3. 匹配度评估根据用户提供的岗位JD职位描述逐项对照候选人的经历、技能 4. 评分与建议输出匹配度评分百分制、理由、建议关注点 输出格式要求 - 每位候选人输出一段JSON结构化摘要包含字段basic_info, skills, score, strengths, risks, suggestions - 其中score必须附带评估理由不能只说分数 终止条件 - 若简历中信息严重缺失无法评估则输出“信息不足建议补充” - 若简历数量超过50份建议分批处理以避免输出过长这个结构本身不算复杂但它为AI划定了清晰的流程边界——先做什么、再做什么、最后输出什么、什么情况下不继续。5.3 在Skill中加入决策规则接下来是关键部分给匹配度评分写一套明确的决策规则。这是用第一个技巧——“把隐式知识变成显式规则”——的地方。很多人写简历筛选Skill时只会说“请评估候选人与岗位的匹配度”但什么是匹配度匹配度是由哪些具体因素组成的这些因素各自占多重的权重不写清楚AI给出的评分就会有比较大的随机性。我设计的评分模型如下你可以根据自己团队的需求调整权重匹配度评分 硬技能匹配40% 行业/项目经验匹配30% 软技能信号15% 稳定性信号10% 学习潜力信号5% 硬技能匹配40分 - 核心技能与JD中的技能完全重合的每项计10分最多计30分 - 有JD中没列但明显相关的技能每项计2分最多计5分 - 无重合技能但具备同类工具/框架经验计5分 行业/项目经验匹配30分 - 有同行业项目经验计15分 - 项目规模与JD中描述的团队规模相近计5分 - 有端到端负责项目的经验而非只负责其中片段计10分 软技能信号15分基于文本线索判断 - 描述中体现主动推动、跨部门协调、结果导向等词汇或案例每项计5分最多计入10分 - 体现抗压能力或在复杂环境中完成目标的例子计5分 稳定性信号10分 - 每段工作经验少于1年扣除3分/段最多扣6分 - 工作年限与岗位级别是否匹配如候选人3年经验应聘初级岗位不额外扣分但要备注 学习潜力信号5分 - 有自学项目、开源贡献、新技能学习记录计3分 - 有培训证书或相关课程计2分这套模型并不完美但它给了AI一个明确的框架避免“凭感觉打分”。5.4 配置示例让AI学会处理模糊信息最后用几个示例来巩固这个Skill的行为。我特意让示例覆盖三种不同情况理想匹配、部分匹配、信息不足。下面摘录关键示例说明示例输入 岗位JD产品经理 3年以上经验负责B端产品规划熟悉需求分析、项目管理、数据分析。 候选人A简历摘要 3年产品经理经验在某SaaS公司负责B端产品从0到1设计独立完成需求调研、PRD撰写、数据分析推动开发团队完成迭代。此前做过UI设计。 示例输出 basic_info: 姓名候选人A工作年限3年当前岗位产品经理 skills: 需求分析、PRD撰写、数据分析、项目管理、UI设计辅助技能、SaaS业务 score: 82分 得分理由 - 硬技能匹配满足需求分析、项目管理、数据分析、B端产品规划加权后共30分 - 行业经验匹配有SaaS B端产品经验符合行业方向计20分 - 软技能信号有“从0到1设计”“推动开发团队完成迭代”等主动结果导向案例计10分 - 稳定性信号每段工作超过1年无扣分计10分 - 学习潜力信号未体现明确自学证据计2分 - 总分72分不对重新计算30201010272分82分不合理。 重新计算 - 硬技能30分 - 行业经验20分 - 软技能10分 - 稳定性10分 - 学习潜力2分 总分72分 建议可进入面试重点考察B端复杂业务的理解深度。这个示例之所以要写得这么详细甚至包含一次“重新计算”是为了告诉AI评分必须基于规则逐项加总中途即使觉得哪里不对也要重新核算而不是直接编一个最终印象分。这能显著降低评分漂移问题。5.5 实操中遇到的坑与解决这个Skill在实际使用中我遇到了几个值得分享的坑坑一JD缺失时AI自动 “脑补”。有时候用户只丢过来一份简历说“帮我筛一下”但没提供JD。最初版本AI会自行假设一个“常见产品经理岗位”然后评分这其实是错误的。后来我在触发条件里加了一条未提供JD时先询问用户或默认不输出评分只输出信息摘要。这个小小的修改避免了大量无意义的“假评分”。坑二输出格式有时候会变成Markdown而非JSON。尽管Skill里明确要求了JSON结构化输出但模型偶尔会“自作主张”换成更易读的Markdown格式。这看起来没毛病但对后续批量处理非常不友好。解决办法是在示例中增加一个“错误格式与正确格式”的对照告诉AI“如果你用了Markdown输出请立即改回JSON”。示例驱动在这个场景下比规则描述更有效。坑三一个候选人对应多份不同版本简历。实际招聘中经常遇到一种情况一位候选人在不同招聘网站上有多个版本的简历信息还互相矛盾。Skill如果只看其中一份就会被不完整信息带偏。我在处理流程里加了一步若检测到同姓名候选人提供多份简历先做字段去重和冲突标记再进入评分流程。这一步看似简单但实际帮我们避免了很多低级错误。6. 更多实战技巧与常见问题速查6.1 Skill调试中的常用技巧调试Skill是门手艺活。我用了很长时间才从“瞎调”进化到“有套路地调”。这里分享几个我觉得最实用的调试方法逐模块测试法。别每次都把完整Skill丢进去测试把流程拆开分别测试“提取信息”“评分”“输出格式”这几个环节看看哪个环节最容易出问题。我自己的经验是大多数Skill的瓶颈出在“规则与示例不一致”——比如规则说“输出JSON”示例却展示的是Markdown这时模型往往会优先跟示例走。检查一遍Skill内部的一致性能解决很多莫名其妙的问题。用“极端输入”做压力测试。我发现很多Skill的bug只有在输入边界情况时才会暴露。比如简历筛选Skill可以故意输入一份格式很差、内容很少、甚至有乱码的简历看看它能输出什么。好的Skill应该在这种情况下给出“信息不足”的提示而不是强行编造一个分数。经常做这种测试能让你提前发现规则漏洞。记录“错误样本”并反推规则。和之前提到过的“让AI描述推理过程”类似当你发现某个输出离谱时不要只改一次就完事。最好把错误输出保存下来分析它出错的“触发点”是什么然后针对那个点写规则。我自己的经验是一个Skill前前后后要改五六版才能稳定下来这非常正常。6.2 常见问题速查表下面整理一份通用的Skill调试问题速查表适配各类Skill场景。这本身也是我在日常工作中持续维护的一份私有文档临床症状可能的原因推荐的解决手段Skill输出风格每次都不稳定示例过少或示例覆盖不全增加到3-5个示例覆盖输入类型变化Skill对边界情况完全没反应触发条件和终止条件缺失明确“何时该用”“何时不该用”评分/判断类输出随机性大决策规则不够显式设计带权重的评分模型或决策树格式经常变来变去规则与示例不一致或示例中没有“正确/错误格式对照”强制示例中使用目标格式必要时给出反例模型“自作主张”猜测信息未规定“信息缺失时如何处理”增加“未知→标记为待确认”的规则Skill在长对话中逐渐“失灵”上下文过长导致早期指令稀释在Skill开头重复关键约束或拆分多个小型Skill组合调用输出过于冗长废话多示例中输出本身就冗长缺少“简洁范式”在示例中展示一个“理想简洁输出”并明确要求字数范围6.3 一些进阶但有用的冷门技巧除了上述三个核心技巧这里再补充几个我在实践中觉得非常有用的冷门细节给Skill写一个“自我介绍”小节。也就是说Skill开头应该有一小段话用自然语言概括这个Skill的核心价值和边界。很多人觉得这是废话但实际上它有两个作用一是让模型在长对话中对Skill的记忆更牢靠因为它会反复引用这个自我描述二是让后续阅读Skill的人快速理解设计意图。示例中故意加入一个“反例”。官方文档里很少提到这一点但它真的很管用。比如你要模型输出JSON格式在示例里放一个“错误的Markdown输出”告诉它“这不是期望格式不要这样输出”。反例能帮助模型更精准地锁定边界比只给正例效果好得多。在Skill中预留“反馈循环”。你可以在Skill末尾加一个小小的“自检提示”让模型在输出之前先对照检查一遍“检查输出是否符合以上所有格式与内容要求若不符合请你重新生成。” 这个提示能明显减少模型“跑飞”的次数代价只是多消耗一点点Token物超所值。7. 从Skill到工作流一套完整的落地思路最后一个部分我想把视角从单个Skill拉远一点聊聊Skill和工作流的关系。因为在实际项目中很少有人会只用一个Skill通常是一个工作流里挂好几个Skill每个Skill负责一个环节配合起来完成任务。7.1 什么时候适合用Skill什么时候适合用工作流这是一个特别容易被混淆的问题。我自己的判断标准很简单当一个任务可以相对独立地复用并且每次触发时输入输出形式都类似那适合做成Skill。当一个任务涉及多个阶段的顺序处理、需要中间状态流转、需要条件分支那更适合做成工作流Workflow。比如“收集资料 → 分析 → 生成报告 → 格式化输出”这种多步处理明显是工作流的范畴。换句话说Skill适合封装“子能力”工作流适合编排“完整流程”。两者并不互斥配合使用才能发挥最大价值。7.2 Skill组合与冲突处理在实际项目中几个Skill同时存在时容易产生“冲突”。最常见的冲突是两个Skill有不同的输出格式要求而模型在同一个上下文中不知道该听谁的。解决思路是在更高一层比如工作流或系统Prompt显式声明Skill的调用顺序和优先级。例如“先调用简历信息提取Skill得到结构化数据后再调用简历评分Skill。两者输出格式不同以评分Skill的输出为准。”这个问题听起来简单但处理不好会带来非常大的调试成本。我过去就把两个互相对立的Skill放在同一个Agent里结果模型被搞得一会用这种格式、一会用那种格式浪费了很长时间才排查出问题。7.3 轻量化设计给团队的实践建议如果你是在团队里引入Skill机制我的建议是先从轻量级开始建立一套“可读性优先”的Skill规范再逐步追求复杂度。很多团队一开始就试图搭建巨型Skill库把所有业务逻辑都塞进去结果维护成本极高效果也差——因为模型在长指令下的表现会随着指令长度增加而衰减。具体来说可以这样做每个Skill尽量控制在一屏内200~300行以内只做一件明确的事。Skill之间通过命名规范避免歧义例如前缀统一用“skill_简历_评分”这种格式。版本控制必须跟代码一样纳入Git每次修改记录原因方便回滚。Skill的测试集要逐步沉淀下来形成一份回归测试专用的输入输出样例。把这些基础工作做扎实了Skill库的扩展才不会被历史包袱拖垮。8. 最后的一点个人体会写了这么多回头看Anthropic官方这份最佳实践其实它传递的核心思想非常朴素想让模型稳定可靠地完成任务你需要把不确定变成确定把隐式变成显式把抽象规则变成具体示例。这三个技巧听起来像废话但真正做到的人在少数。我自己在多次迭代Skill的过程中最深的体会是打磨Skill是一个持续对抗“信息衰减”的过程——模型不短路规则不冗余则输出自然就稳定。每一次从“AI输出离谱”到“AI输出稳定”的跨越背后都是靠更清晰的边界、更严谨的措辞、更贴近真实使用的示例堆出来的。如果你正在被某个Skill的稳定性问题折磨我的建议是先别急着加更多规则回头看看三个地方——触发/终止边界是否清晰、决策规则是否显式、示例是否覆盖了不同情况。把这三个基础点打磨到位大部分问题都会迎刃而解。以上是我基于实战踩坑得出的一些方法。如果你在自己的Skill调试中有更好的技巧或心得也很欢迎一起交流讨论。技能工程这件事最好的学习方式就是在真实项目中一遍遍打磨、试错、总结然后把好的经验沉淀成可复用的资产。