本文从发现与选择、上下文经济、指令校准、工作流控制和可执行代码五个方面总结了14个可复用的Claude技能设计模式。通过激活元数据、排除条款、上下文预算、渐进式披露等模式帮助开发者更好地设计技能使其被有效利用。同时文章还介绍了控制调优、解释原因、模板脚手架等模式以平衡指令的严格性与灵活性。此外执行清单、自纠正循环、计划-验证-执行等模式则针对多步骤流程提供了有效的控制方法。最后实用工具包和自主校准模式帮助开发者提升技能的确定性和安全性。这些模式覆盖了技能设计中的关键点是新手程序员提升技能开发效率的必备知识。在 Agent Skills 的生态中技能大致可以分为两类。一类是任务型技能通常设置disable-model-invocation: true对应一整套步骤化流程比如部署、提交或安全审查用户一般通过/skill-name直接触发。另一类是参考型技能用户不可直接调用更像是背景知识比如风格指南或领域术语Claude 会在相关场景下自动应用。本文基于Anthropic官方的技能编写最佳实践总结了 14 个可以复用的设计模式分为五类发现与选择、上下文经济、指令校准、工作流控制和可执行代码。发现与选择技能写出来没人用写得好有什么意义前两个模式要解决的就是这个「怎么被用到」的问题。1. 激活元数据模式Activation Metadata pattern当你的技能库里有几十个技能时Claude 怎么知道该用哪一个答案就在description。但很多人把它当成「摘要」写成类似“用于处理文档”这种模糊描述。结果就是要么选错要么干脆不用。description不是摘要而是 Claude 做选择时最关键的信号。在会话开始时Claude 只能看到每个技能的name和description。如果这一步没选对后面写得再好也用不上。一个好的description通常要包含三点• 做什么功能• 什么时候用触发场景• 遇到哪些词要触发关键词Anthropic 的skill-creator甚至建议把description写得「更主动」一点因为 Claude 本身有点「触发不够」的倾向。比如“即使用户没有明确提到仪表盘只要提到数据可视化或内部指标就应该触发这个技能”。适用场景所有技能都应该用这个模式。入口没做好后面都没意义。权衡点在开放的 Agent Skills 规范中description上限是 1024 字符在 Claude Code 里description和可选的when_to_use一起最多 1536 字符。空间有限每句话都要在「触发词、排除条件和领域关键词」之间做取舍。2. 排除条款模式Exclusion Clause pattern只说「什么时候用」还不够还要说明「什么时候不用」。比如你同时有一个「文档处理」和一个「代码生成」技能如果它们都写成「处理所有文本相关任务」Claude 很难判断该选哪个。正向触发是把它拉进来排除条款是把它推出去。Ruben Hassid 把排除条款称为「description里最关键的一行」甚至比正向触发更重要。一个好的排除条款通常会说清楚• 哪些场景不适用• 哪些内容更应该交给其他技能• 哪些情况直接用 Claude 就够了比如“不要用于博客文章、通讯邮件、推文或长篇内容。”还有一个容易被忽略的点排除条款不是单独存在的它需要和整个技能库一起考虑。否则就可能出现两个技能都说「我能做」或者都说「我不做」。适用场景几乎所有技能尤其是和其他技能有重叠的那些。权衡点维护成本。技能一多排除条款也需要跟着调整否则很容易出现冲突或空白区。上下文经济上下文窗口是个共享资源每个 token 都在和其他技能、对话历史以及当前请求抢空间。3. 上下文预算模式Context Budget pattern很多技能喜欢从头解释一遍什么是 PDF、什么是库、JSON 是怎么工作的——但这些 Claude 本来就知道。这种冗余一旦在几十个技能里重复出现上下文窗口在用户开口之前就已经被占掉一大半。默认前提Claude 是聪明的。这个模式的核心是每一段话都要配得上它占用的 token。如果删掉一句话不会让一个「足够聪明的读者」困惑那它大概率就是多余的。另外还有两个容易忽略的点•术语要统一选一个说法就一直用比如只用field不要来回切换field / box / element•避免时间敏感表达像“2025 年 8 月之前”这种描述很快就会过时。更好的做法是把这类信息放到「旧模式」的附录里适用场景所有技能的基础要求可以当作默认纪律。权衡点如果你的技能要兼容多个模型就要按最弱模型来决定细节程度——对 Sonnet 来说刚好的简洁对 Haiku 可能就偏简略了。4. 渐进式披露模式Progressive Disclosure pattern很多人会把所有内容一股脑塞进SKILL.md不管用户问什么几百行甚至上千行内容一次性全加载。表格、API 文档、示例代码——不管用不用都占着上下文。核心思路是把 SKILL.md 当成目录而不是仓库。具体做法一般是• 主文件尽量控制在 500 行以内• 把细节拆到不同文件比如FORMS.md、REFERENCE.md、reference/finance.md• 只在需要的时候再加载这些文件还有两个实用技巧•scripts/里的脚本可以执行但不会被加载进上下文所以里面的实现细节通常不会占 token• 对于特别长的参考文件在顶部加目录TOC这样即使读取被截断Claude 也能知道整体结构适用场景当SKILL.md超过 ~300 行时基本就该考虑拆分了。权衡点拆分带来的复杂度。文件多了之后不仅作者更难把控全局Claude 也需要做「下一步该加载哪个文件」的判断一旦选错就会多走几轮。指令校准指令到底该写多细写得太死会限制发挥写得太松又容易跑偏。下面这几个模式主要就是在这两者之间找平衡。5. 控制调优模式Control Tuning pattern有些技能会把每一步都写死结果一遇到需要灵活处理的情况Claude 反而被卡住。反过来如果指令太模糊在那些「错一步就全错」的场景里又很容易出问题。这个模式的核心是根据任务的脆弱程度来决定指令该有多严格。可以一直问自己一个问题这里能接受多大的偏差•高自由度文本指令比如“用你的判断”适合开放型任务比如代码审查•中自由度伪代码、参数化步骤适合有流程但需要灵活调整的任务比如部署•低自由度精确脚本、强约束比如“不要修改”适合高风险操作比如数据库迁移语气本身也是一个调节手段。比如在开头设定角色“你是一个更关注正确性而不是风格的资深代码审查员”。这种设定会直接影响后面的判断标准在参考型技能里很常见。适用场景对每个步骤都问一句——这里允许多少偏差权衡点很多人会倾向于「写死一点更安全」但其实只是把失败方式换了一种从「做错」变成「做不了」。6. 解释原因模式Explain-the-Why pattern把规则写成一串 ALWAYS / NEVER / MUST看起来很清晰但其实缺少上下文。Claude 可能会按字面执行却在边界情况里用错或者在不该严格执行的时候也机械套用。Anthropic 的skill-creator甚至把这种全大写指令当作需要重构的信号。这个模式的核心是先说规则再说明原因。这样 Claude 不只是「照做」而是能理解背后的逻辑在规则没覆盖到的情况里也能自己做判断。比如“使用构造器注入。字段注入会破坏可测试性因为需要依赖 Spring 上下文来模拟字段。”就比“必须使用构造器注入绝不使用字段注入。”更稳一些。前者提供了推理依据后者只是限制行为。适用场景当你开始写 MUST / ALWAYS / NEVER 这类强制性规则时就应该考虑换成这种结构。权衡点解释会消耗 token——对于那些真正「不能出错」的步骤比如前面说的低自由度场景直接命令式反而更合适带原因的写法更适合需要 Claude 自己做判断的地方。7. 模板脚手架模式Template Scaffold pattern像报告、提交信息、API 请求、发布说明这类输出只要结构很重要Claude 每次生成的「形状」往往都不太一样。问题在于结构其实藏在示例里但技能本身没说清楚所以每次都在重新「猜」。这个模式的做法很直接给一个带占位符的模板让它按结构填空。模板一般分两种•严格模板“必须按这个结构来”适合数据契约、需要机器解析的场景•灵活模板“这是推荐结构可以调整”适合需要一定发挥空间的文档类输出可以简单理解为模板定结构示例定风格。适用场景只要输出有固定结构或者后面还要被解析不管是人还是程序就应该用模板。权衡点模板越严格越容易限制表达。在一些边缘情况里反而可能不够用。所以如果不是给机器用优先用灵活模板。8. 技能内示例模式In-Skill Examples pattern光靠描述很难把语气、格式和细节说清楚。常见情况是结构对了但风格不对——比如提交信息用了正确的 conventional commit 前缀但语气跟团队不一致。这个模式的做法是在技能里放几个输入 / 输出示例让它照着对齐。Input: [用户输入示例] Output: [期望输出示例]和 few-shot 类似给两到三个例子通常比一大段说明更管用。Claude 会优先对齐示例而不是从文字里自己猜。可以这么理解模板上一个模式解决的是结构问题示例解决的是风格问题。两者配合使用时效果最好模板定结构示例定风格。适用场景既有结构要求、又有表达风格要求的输出比如提交信息、发布说明、changelog、审查摘要等。权衡点Claude 很容易「学例子」。如果示例里带了某种习惯它会在所有输出里复现。所以示例要尽量覆盖不同情况而不是只给一种写法。9. 已知陷阱模式Known Gotchas pattern很多技能只覆盖「正常流程」告诉 Claude 该怎么做却没说哪些地方容易出错。一旦遇到真实环境里的边缘情况——字段不存在、命令在 macOS 能跑但在 Linux 失败、库悄悄返回空结果——Claude 没有参考就容易自己「编一个修复」。这个模式的做法是专门列出已知的陷阱。在SKILL.md里单独加一节把常见失败情况写清楚比如•“扫描 PDF 可能返回空数组需要先检查页码类型”•“页面旋转必须在列提取前设置 page.rotation 0”在实战里这一部分往往是一个技能最有价值的内容因为它直接来自踩过的坑。适用场景已经在真实环境跑过一段时间的技能可以根据实际问题不断补充。权衡点这些「陷阱」是会变化的。库升级、API 改动之后旧问题可能已经不存在如果不更新反而会误导 Claude 去排查一个已经不存在的错误。工作流控制多步骤流程该怎么控制从简单的线性步骤到带校验的执行再到基于计划的流程控制复杂度是逐步增加的。10. 执行清单模式Execution Checklist pattern在多步骤流程里常见问题不是做错而是没做完跳过验证、忘了当前进度甚至提前宣布完成——「应该已经好了」但其实只做到一半。这个模式的做法是把流程变成一份可勾选的清单。让 Claude 在对话中直接使用比如- [ ] 步骤1...- [ ] 步骤2...- [ ] 步骤3...每完成一步就勾掉没完成的会一直留在那。关键点在于未完成的项是「可见的」。清单会一直出现在对话里不只是 Claude 自己知道也让用户一眼就能看出进度。每一轮都要面对「还有哪些没做」自然就更难提前收工。适用场景超过三步的流程尤其是那些「少一步就可能出问题」的场景。权衡点清单每轮都会完整出现长对话里 token 会明显增加。对于很短的流程用这个模式反而有点重了。11. 自纠正循环模式Self-Correcting Loop pattern在生成代码、编辑 XML、或者按规范写文档时单次输出很容易留下问题——而这些问题本来是技能可以发现的。问题不在于「怎么写对」而在于没有人检查它写得对不对。这个模式的做法是引入一个显式的循环。流程很简单生成 → 验证 → 失败则修复 → 再验证验证可以是• 脚本比如python validate.py fields.json• 或规则检查比如重新对照STYLE_GUIDE.md一条条过只有通过验证流程才结束。适用场景对质量要求高、且可以验证的任务比如代码生成、配置文件、结构化输出等。权衡点可能不收敛。如果验证不够严格或者 Claude 一直在同一个地方出错就会反复循环。实际使用中需要设置重试上限并在失败时回退给用户处理。12. 计划-验证-执行模式Plan-Validate-Execute pattern对于批量或高风险操作——比如批量改表结构、数据迁移、整篇文档重写——如果直接「上来就做」一旦出错很容易一路错到底。等你发现问题时修改可能已经应用完了回滚成本很高。这个模式的做法是在「理解任务」和「执行操作」之间加一层可验证的中间产物。通常是一个结构化的计划比如 JSON流程变成计划 → 验证 → 通过后再执行关键点是所有验证都发生在副作用之前。这和前面的自纠正循环不一样——那是在结果出来之后反复修这里是在真正动手之前把问题提前挡住。Claude 可以在「计划」阶段反复调整只有当计划通过验证后才允许执行真实操作。适用场景批量操作、不可逆操作或者一旦出错代价很高的任务。权衡点流程更重。对于简单任务比如改两个字段这套流程本身的成本可能比任务还高。所以更适合那些「做错了很难补救」的场景。可执行代码把一部分工作从 Claude 的推理里拿出来交给确定性的脚本去做运行、返回结果——要么成功要么失败。13. 实用工具包模式Utility Bundle pattern如果每次都让 Claude 临时写验证脚本、PDF 解析器或者数据处理逻辑不仅慢还不太稳定而且这些「临时代码」也在白白消耗 token。很多时候其实是在反复写同一套逻辑只是细节有点不一样。这个模式的做法是把这些确定性的能力提前做成脚本放到scripts/里。之后让 Claude 通过 bash 调用而不是每次都现写一遍。好处是进入上下文的只有脚本输出而不是实现过程。这些脚本本身也有几个基本要求• 能自己处理常见错误而不是把问题再丢回给 Claude• 要么给出合理默认比如自动创建缺失文件要么快速失败并说明原因• 常量要写清楚用途比如「30s 超时是为了覆盖慢连接」避免魔法数字如果不确定哪些逻辑值得抽出来可以简单看一下跑几次技能翻翻日志——哪些辅助逻辑反复被「重新写」就应该提到scripts/。适用场景确定性强、经常重复、值得单独测试的操作。权衡点环境依赖。脚本是在用户环境里跑的不同机器、不同系统可能表现不一样。所以需要在SKILL.md里写清依赖并尽量避免平台相关问题比如路径写法。14. 自主校准模式Autonomy Calibration pattern如果一个技能默认拿到一整套工具它理论上什么都能做写文件、跑 shell、调外部服务——哪怕它的任务其实只是读点数据。比如一个带Write和Bash权限的安全审计技能就算SKILL.md写得再严格本身也是个隐患。这个模式的做法是在 YAML 里把allowed-tools写清楚只给它真正需要的能力。比如• 安全审计Read, Grep, Glob• 文档生成Read, Write• 部署任务只开放受限命令的Bash但有个容易被忽略的点allowed-tools更像是「预批准」不是「硬限制」。它可以减少审批但不等同于沙箱。在 Claude Code 里真正的约束还是要靠权限策略而不是只靠这里的声明。适用场景只需要少量能力的技能尤其是安全、审计、分析这类任务。权衡点很容易误用。如果allowed-tools 写得太宽其实是在放大权限而且很多人会把「预批准」当成「已经限制」。需要严格控制时一定要配合权限策略一起用。总结这 14 个模式基本覆盖了技能设计里最容易出问题的几个关键点。description决定技能会不会被用到渐进式披露决定它会占多少上下文解释原因和已知陷阱决定 Claude 在边界情况下能不能做出正确判断计划-验证-执行和自主校准则是在出问题时把风险控制在可接受范围内。每一个模式背后其实都对应着一种常见的失败方式。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取