做Claude技能定制这件事我入坑有一段时间了。最早的时候每天打开对话框都要把同样的背景、角色、规则原封不动地再敲一遍稍微换一个问法Claude的产出风格就飘了。后来我开始尝试把一些高频场景沉淀成结构化的技能包也就是用Claude Skill Creator 2.0来做自定义技能把散落在提示词里的经验固化成一个一个可复用的文件才算是真正解决了这些困扰。这篇文章把自己从入门到实际落地这段过程里最关键的东西整理了出来不绕弯子直接讲清楚三件事Claude Skill Creator 2.0是什么、怎么用它创建一个真正能用的技能、以及从调试到发布全流程里那些文档里找不到的坑。内容比较长但我尽量做到全程都是手把手级别的细节每一个步骤都是我能直接照做的那种。如果你是那种重度依赖Claude来完成写作、复盘、审校、数据分析或者代码审查的人或者你正在帮团队搭建一套统一的AI工作流这文章基本就是冲着你写的。哪怕是完全零基础的小白只要跟着第二部分把环境准备好后面每一步都是可以稳着走完的。1. 先搞清楚Claude Skill Creator 2.0到底解决了什么问题1.1 没有Skill之前你的Claude是什么样的先回忆一个场景。假设你希望Claude帮你写周报你每次都得把自己的岗位、项目进展、本周重点全部描述一遍。某天项目有变动你又得重头说换了一个新话题前面那些上下文全成了干扰项。更麻烦的是你花大篇幅调教出来的输出风格隔天去开个会回来又得从头再来一遍。我把这个状态叫做一次性对话困境。在这个阶段你和Claude之间没有沉淀没有资产每一次交互都是从零开始。对于那些偶尔问个百科问题的人来说这没所谓但如果你是靠Claude处理文档、生成内容、做批量分析的这种低效就会被放大得非常明显。我统计过自己早期的使用情况同一个文档审校任务我每次都要先花大约2000字的上下文去描述规则再给两三个示例最后还要反复强调不要改动术语。一次两次还能忍时间一长这些重复劳动消耗的其实是你的耐心和判断力。1.2 Skill本质上是把经验打包成文件Claude Skill Creator 2.0做的事简单说就是提供一个标准化的方式让你把反复使用的那套角色规则示例禁忌打包成一个技能文件。这个技能文件通常长这样skills/ 样式很清晰的目录结构最核心的是每个技能目录下的SKILL.md它用结构化的方式定义了Claude在触发这个技能后应该扮演什么角色、遵循什么流程、输出什么格式。旁边的assets目录则用来放术语表、检查清单、参考模板这类篇幅较大的辅助资源。你可以把Skill理解成给Claude交了一份岗位说明书SOP案例库。以前你每次都要站在工位旁边口头叮嘱半天现在你直接把一份文档扔给它说按这个来它就知道该怎么做了。2.0版本相比最初的概念最大的变化不是功能数量而是把文件结构、描述解析、测试验证这几个环节规范化了。一个技能包不再是随手写的一段Markdown而是有明确frontmatter、有清晰触发描述、有可执行测试、有版本记录的完整单元。这带来的直接好处是你可以像管理代码一样管理自己的AI技能。1.3 为什么这件事值得认真做可能有人会觉得我直接用一个写好的长提示词不也一样吗早期我也这么想。直到我做了一个实验同一个竞品分析任务用长提示词的方式和用Skill的方式各跑十次。长提示词的结果是输出有七成概率会跑偏要么格式对但深度不够要么深度有了但忘了对比维度而Skill方式下十次里有九次输出稳定在同一个水准线上。这就点出了Skill的真正价值质量的一致性。长提示词依赖Claude对你那段文字的临时理解而Skill通过结构化描述和资源文件把理解这件事的成本前置到了你编写技能的那一刻。你把规则想得越清楚运行时的行为就越可控。此外Skill还有很强的复用和协作价值。一个团队里只要一个人把代码审查Skill做好了其他人放到自己的工作里就能用不需要每个人都去调教一遍。长期积累下来你手头这些技能包就是一套属于你自己的AI工具库而且是越用越值钱的那种。2. 环境准备与基础概念动手之前先弄清这几件事2.1 准备一个干净的技能开发环境开始创建Skill之前先把环境准备好。我的建议是建一个专门的目录来放所有技能包结构大致是D:\claude-skills\ 或任意你喜欢的位置我个人的习惯是working-directory/ skills/ doc-review/ SKILL.md assets/ terminology.csv checklist.md examples/ tests/ test_case_01.md test_case_02.md CHANGELOG.md编辑器方面VS Code就够了关键是装一个支持Markdown预览的插件这样写SKILL.md的时候可以实时看到渲染效果结构哪里有问题一眼就能发现。建议把自动保存打开改完文件切到对话里直接测试这个节奏最舒服。命名规范值得从一开始就养成。技能目录统一用小写字母和连字符比如doc-review、meeting-notes、code-audit不要用空格或者中文目录名。原因很简单技能名称后面会出现在路径和引用里用连字符风格的命名不容易出编码或路径问题。2.2 SKILL.md的结构拆解SKILL.md是整个技能的核心文件它由两部分组成YAML形式的frontmatter和Markdown正文。frontmatter部分至少需要两个字段name技能的唯一标识要跟目录名保持一致比如doc-review。description对技能能力和触发场景的描述这部分极其关键因为Claude是靠它来判断什么时候该用这个技能。正文部分没有强制的固定格式但经过我大量实验一个能稳定工作的SKILL.md正文通常会包含以下几块角色定义Claude要以什么身份来处理这个任务。工作流程处理任务时需要遵循的步骤顺序。决策规则遇到不同情况时怎么选择方案通常用如果...那么...的结构写。输出格式最终结果必须遵守的模板。边界与回退遇到能力范围之外的问题时如何处理。变更记录记录这个技能的修改历史方便日后回溯。2.3 理解描述与触发机制写description这件事我见过很多人踩坑包括我自己。最常见的错误是写得太虚比如帮助用户进行文档审校。这种描述谁都能匹配结果就是你在做任何事的时候Claude都可能试图调用这个技能或者反过来真正的任务来了它又不触发。一个有效的description应该包含三个要素行为、任务、场景。拿文档审校来举例一个合格的description长这样帮助用户审查中英文技术文档找出事实性错误、术语不一致和逻辑跳跃问题并在不改动原文意图的前提下给出修改建议。适用于用户提交论文、技术方案、产品说明书等需要审校的文档场景。它说清楚了做什么审校并给出建议、针对什么任务事实错误、术语、逻辑和在什么场景用论文、方案、说明书。Claude解析这个描述后才可能做到该触发的时候触发不该触发的时候不打扰。3. 从头动手创建一个文档审校Skill的完整过程3.1 明确需求与设计边界下面用一个能落地的例子把整个流程走一遍。这个技能叫文档审校目标很单一帮用户审查中英文技术文档输出一份审校意见。设计之前先逼自己回答几个问题这个技能的核心输出是什么答一份结构化审校报告。哪些事情是它必须做好的答抓事实错误、查术语一致性、找逻辑断点。哪些事情是它不应该做的答不能直接改写用户的原文不能凭感觉添加信息来源。这些问题想清楚了边界也就出来了。边界越清晰后面写指令的时候就越不容易偏。我自己的习惯是先用一两句话写下技能的目标声明再列一个三到五行的必须/禁止清单。这比上来就写长篇大论要靠谱得多因为你写指令的时候往往容易陷入细节有了目标声明和红線清单写跑偏了随时能拉回来。3.2 编写SKILL.md的完整模板直接给出来一个我自己在用的模板你可以照着抄然后按需修改--- name: doc-review description: 帮助用户审查中英文技术文档找出事实性错误、术语不一致和逻辑跳跃问题并在不改动原文意图的前提下给出修改建议。适用于用户提交论文、技术方案、产品说明书等需要审校的文档场景。 --- # 文档审校专家 你是一名资深技术文档审校专家擅长中英文技术文档的质量检查与修改建议输出。你的目标是在保留作者原意和风格的基础上发现文档中隐藏的问题。 ## 工作流程 1. 通读全文先建立整体理解不要边读边改。 2. 按事实性错误→术语一致性→逻辑连贯性→表达与格式四个维度逐项检查。 3. 每发现一个问题记录其原文、类型、严重程度、修改建议。 4. 汇总输出审校报告按严重程度降序排列。 ## 决策规则 - 如果文档中某个章节存在明显的逻辑跳跃或者论证缺环标记为逻辑问题并指出缺了什么。 - 如果同一术语在文中出现了两种及以上译法标记为术语不一致列出首次出现的位置并建议统一。 - 如果出现对数据、研究结果或历史事件的陈述且无法从上下文中找到依据标记为待核实不要直接判错。 - 如果不确定某个修改建议是否改变原意宁可只提示风险也不要强行给出改写版本。 ## 输出格式 严格按照以下结构输出 ## 审校报告 ### 严重问题 - 原文位置 - 问题类型 - 问题描述 - 修改建议 ### 一般问题 同一格式逐条列出 ### 术语表建议 - 出现不一致的术语列表以及建议的统一译法 ## 边界与回退 - 你不负责对文档进行全文重写只输出审校建议。 - 如果用户要求你直接改写全文礼貌说明你的职责范围并提示用户可以开启全文润色技能。 - 如果文档内容超出你的专业判断范围明确标注超出审查范围不要强行审校。 ## 变更记录 - v1.0 初始化版本建立基础审校流程与输出格式。这个模板里的每一块都不是摆设。工作流程规定了先通读后检查的顺序防止Claude在没理解全文的情况下就急着改细节决策规则里对数据陈述标待核实而不是直接判错这条就是为了堵住它胡编乱造来源的毛病边界与回退则确保它不会因为指令含糊就擅自越权去做全文重写。3.3 创建辅助资源与术语表SKILL.md里不宜塞太多东西特别是不宜放进大量的术语表和示例。我的做法是凡是超过两屏的内容一律丢到assets目录。以文档审校Skill为例我会在assets里维护两个文件terminology.csv存放项目组指定的中英文术语对照表Claude在审校的时候遇到歧义会先查这个表。checklist.md一份审校检查清单把需要逐项核查的点列出来比如所有图表是否有编号和标题所有引用是否有出处。为什么非要拆出来因为SKILL.md是要被模型完整读入上下文的写得越长占用的上下文就越多。调用Skill的时候模型未必需要把整个术语表都载入但如果它发现某处术语有问题它可以告诉用户建议参考assets/terminology.csv中的统一译法。这样既保证了准确性又没有让大块文本白白挤占有限的上下文空间。3.4 测试技能的三种方式技能写好了怎么知道它真的能用第一种是模拟测试。开一个新对话把一份提前准备好的样本文档直接丢进去看它能不能自动触发这个技能输出格式是否符合预期。这一步能发现大多数明显问题。第二种是构建带标准答案的验证集。准备三到五份文档每份里都人为埋几个错误比如故意把同一个术语翻成两种写法、塞一个逻辑断裂的段落。然后给Claude审校看它能否把这些埋点全部找出来。这个测试非常有效因为你有标准答案对就是对错就是错。第三种是回归测试。每次修改了SKILL.md之后把之前跑过的验证集重新跑一遍确认改动没有让原本正确的能力退化。这和软件开发里的回归测试是一个道理特别适合技能进入维护期之后使用。4. 核心机制进阶让Skill真正好用的七个细节4.1 描述越具体触发越准确前面说description要包含行为、任务、场景三要素这里再补充一点可以在description里写一些排除性的内容。比如文档审校技能可以加一句如果你只是想让我润色文笔不要使用本技能。这个反向描述的价值在于Claude在判断要不要调用这个技能的时候不仅知道什么时候该用还知道什么时候不该用。这在你的技能库里同时存在文档审校和全文润色两个技能时尤其重要能够有效避免技能之间的互相抢触发。我自己遇到过最典型的场景是我同时装了周报助手和文档总结两个技能结果每次丢会议纪要进去两个技能都会抢着响应输出乱成一团。后来我在各自的description里明确加了排除条件冲突才消失。4.2 指令要写成决策框架而不是命令列表很多新手写指令喜欢列清单你要检查语法你要检查术语你要检查逻辑。这种写法最大的问题是它只告诉Claude做什么没有告诉它在什么情况下怎么做。决策框架的写法是不同的它给的是条件分支。举个例子如果同一术语在文中出现了两种以上译法标记为术语不一致并列出首次出现位置。如果段落之间存在逻辑跳跃标记为逻辑问题并尝试补全中间缺失的论证步骤。如果你无法判断某个陈述是否正确标记为待核实不要猜测。看到了吗同样是做什么决策框架的写法把做这个动作挂在了具体条件下。这带来的直接效果是Claude的输出更稳定不会出现那种你让它看书它给你总结全书的荒谬偏移。生活化类比一下命令列表像一张购物清单你照着买但遇到缺货就不知道怎么办了决策框架像购物时带了个老手他会告诉你如果这个牌子缺货挑同价位另一个牌子顶一下。4.3 少用模糊形容词多用结构我问过很多人你给Claude说认真检查的时候你期待它做什么答案五花八门有的人希望它逐句读有的人希望它对照参考资料还有的人希望它只改错别字。同一个词在不同人心里的含义完全不同Claude就更难猜了。所以我的原则是指令中出现形容词的时候问自己一句这个形容词对应什么可观察的行为如果有就把它换成行为描述。认真检查换成按照checklist.md中的条目逐项核对并在报告中标注每项的检查结果。 高质量输出换成输出内容必须包含数据出处且每条建议都有具体的修改前后对照。这是一条能显著提升所有技能质量的习惯。技能的本质是确定性而确定性来自具体的行为描述不来自抽象的质量标准。4.4 给足示例但别让示例喧宾夺主示例是锚定行为的最好工具因为模型对模仿这件事的完成度通常高于对规则的遵循度。一个问题你解释三遍不如直接给它看一遍标准答案。但示例也不是越多越好。我见过有人把一个技能里塞了十几个示例结果每次调用都要消耗大量上下文而且Claude会开始过度贴合最近的示例忽略了你真正想让它做的当前任务。我的经验是一个技能里放一到两个最能代表典型场景的示例就够了其余全部放到assets/examples/目录下遇到需要的时候再按需引用。另外示例一定要标注这是示例只用于参考格式不要照搬内容否则它很容易把示例里的细节复刻到你的真实输出里。4.5 设置回退策略处理边界情况Skills的一大优点是能主动处理边界情况而不仅仅是遇到不会的就道歉。我在编写所有技能的时候都会刻意加上一节超出范围时怎么办。这部分不是套话而是给Claude一个明确的兜底路径。比如文档审校技能回退策略是如果文档内容超出你的专业判断范围明确标注超出审查范围不要强行审校。这句话解决的是以往最让人头疼的问题——Claude硬着头皮对一篇高度专业的论文发表外行意见。有了这条它至少会诚实地说这块我看不太准建议找领域专家复核。这个思路也可以扩展到其他场景一个客服技能可以说如果用户情绪激动先共情再处理问题不要急于解释一个代码审查技能可以说如果遇到无法确认的依赖包行为标记为待验证不要臆断。回退策略写得好不好直接决定了一个技能是靠谱助手还是不靠谱嘴替。4.6 控制Skill的上下文占用Skill再好也不能无限膨胀。因为每次调用SKILL.md都会占据模型的上下文窗口如果技能本身写得像一篇长篇小说可用上下文就会骤减处理长文档时会变得力不从心。我给自己定了一个简单的预算单个SKILL.md正文尽量控制在300到500行的量级超过就考虑拆分或外置。术语表、长示例、详细SOP这些高篇幅的内容统一放进assets让它们按需加载而不是全程占据上下文。还有个小技巧在SKILL.md里用链接或者指向性描述来引用外部文件而不是把文件内容整个粘进来。比如不写下面是术语表全文...而是写遇到术语不统一时参考assets/terminology.csv中的对照关系。这样既能让Claude知道去哪里找信息又不用预先支付上下文成本。4.7 版本管理与更新规范技能不是写完就不动的它是需要持续迭代的活物。我在早期吃了不少苦头因为改动一个技能后效果反而变差又找不到原因最后只能全部推翻重来。后来我养成了一个习惯每个技能目录下放一个CHANGELOG.md每次修改都要记录。记录格式很简单## [1.2.0] - 2025-01-15 ### Changed - 修改了术语不一致的处理规则从直接给出建议译法改为列出首次出现位置并建议统一 ### Added - 新增了一个安全法规审查的专项检查项 ### Fixed - 修复了输出格式中严重问题与一般问题排序混乱的问题版本记录的意义不只是方便回溯它还能在出问题的时候帮你快速定位是从哪次改动开始变差的省下整晚排查的时间。5. 实战演练打造一个会议纪要速记员Skill5.1 需求描述与交付物定义换一个场景再走一遍这次做一个会议纪要速记员Skill目的是把一段混乱的口语记录转成结构化会议纪要。这个场景特别适合Skill因为会议口语记录通常有很多口水话、插话、跳跃直接扔给Claude让它整理一下它很容易整理出一份你自己都看不懂的文字流。但如果明确告诉它输出模板和决策规则即使是同样一段口语输入它的输出能稳定达到可以直接抄进文档的可用度。我先定义交付物会议纪要必须包含会议主题、时间、参与人、背景摘要、关键决策、行动项含负责人和截止时间、待讨论问题、风险提示这几块内容。每一条行动项必须是从口语里明确提取了谁要在什么时候前做什么没有明确归属的只能放待确认。5.2 SKILL.md的完整实现--- name: meeting-notes description: 将混乱的口语化会议记录转换为结构化的会议纪要提取关键决策、行动项和风险点。适用于用户上传会议录音转文字稿、速记笔记、聊天记录等需要整理成纪要的场景。 --- # 会议纪要速记员 你是一名经验丰富的会议记录整理专家擅长从杂乱的口语信息中提炼结构化要点并确保不遗漏任何关键行动项。 ## 工作流程 1. 通读全部会议记录识别主要讨论线索。 2. 将记录切分为信息片段决策、行动项、讨论、问题、风险。 3. 对每个行动项提取责任人、动作、截止时间无法提取的标记为待确认。 4. 输出标准格式会议纪要。 ## 决策规则 - 如果一句话以我们决定了最后敲定就按这个方案吧等开头标记为决策。 - 如果出现某人要做某事且有限定时间标记为行动项没有时间的标记为无明确截止时间。 - 如果出现这个还没定需要进一步评估等标记为待讨论问题。 - 如果出现可能有问题有点担心风险在于等标记为风险。 - 口语中同一件事被重复多次时只保留信息最完整的那一次不重复罗列。 ## 输出格式 # 会议纪要 ## 会议信息 - 会议主题根据内容推断推断不出则写未明确 - 会议时间缺失则省略 ## 背景摘要 3-5句话概括会议整体目标与主要议题 ## 关键决策 - 决策1 - 决策2 ## 行动项 | 序号 | 行动内容 | 负责人 | 截止时间 | 状态 | | --- | --- | --- | --- | --- | | 1 | | | | 待执行 | ## 待讨论问题 - 问题1 ## 风险提示 - 风险1 ## 边界与回退 - 你不负责补充会议中没有提到的内容。如果信息缺失明确标注缺失即可。 - 如果记录中有大段无法判断含义的文本放在待确认内容部分不要强行归类。 - 如果用户要求你给行动项补充更合理的截止时间礼貌拒绝并说明这需要负责人确认。 ## 变更记录 - v1.0 初始版本建立会议纪要基础流程与输出模板。这份SKILL.md里最有含金量的其实是决策规则那一段。会议记录里有大量自然语言表达判断一段话是决策还是讨论还是行动项光靠理解大意是不够的必须有明确的信号词触发规则。我在实际测试中发现这类信号词规则能让分类准确率从七成直接拉到九成以上。5.3 从草稿到可用的三次迭代这个Skill做完之后我做了三次迭代修正这里分享真实的调试记录。第一次测试我丢进去一段大约800字的会议速记。它的输出框架是对的但问题也明显所有没有明确时间点的行动项都被它强行标成了无明确截止时间这没错但它把待讨论问题和决策搞混了有一段明显还在争论的话题被它写成了决策。第二次迭代我在决策规则里加了出现就按这个方案吧最终定了这类确认语气才标为决策带有要不要考虑的句式一律归入讨论。这次效果好多了同一段测试输入决策和讨论的区分基本正确。第三次迭代主要改输出格式。我注意到模型在输出行动项时会用尽快近期这类模糊时间词这会降低纪要的执行价值。于是我在决策规则里加了硬性约束如果口语记录中没有出现具体日期或相对时间如本周五、下周内截止时间位置写待确认不允许使用模糊时间词。 后面跑了几轮输出稳定没有再出现模糊截止时间。这三次迭代的启示是不要指望一次写对而是要建立一个写-测-改的闭环。每一次改动都带明确目的改完立刻用同一份测试输入验证你很快就会看到技能的质量曲线稳步上升。6. 调试、验证与发布从能用做到好用6.1 调试心态调整Skill是常态刚写完一个Skill的时候第一次测试不通过是大概率事件。这不是你写得差而是模型行为本身就具有不确定性。我见过很多人一次测试失败就放弃了觉得AI太笨其实问题往往出在一个很小的描述歧义上。调试的时候要有工程思维一次只改一个变量。如果你同时改了description、工作流程和输出格式然后测试发现行为还是不对你根本不知道是哪个改动造成的。一次只动一处、每动一处就立刻跑验证集效率反而最高。另外要区分问题出在哪个层面。测试失败先归类是触发失败description有歧义、流程失败工作顺序不对、还是输出失败格式模板没写清楚。归类之后再去对应的位置改不要上来就全盘推翻。6.2 用结构化测试保证回归质量我在第三节已经提过测试的三种方式这里重点讲讲怎么把测试变成日常的流程。准备一个tests目录把验证集文档按场景分好类。文档审校Skill有审校类的验证集会议纪要Skill有自己的标准速记样本。每个验证集文件开头留一段预期结果注释写明这份样本里埋了哪些点、应该输出什么。每轮修改之后跑一遍全部验证集记录通过率。我自己的标准是主要场景的通过率掉到80%以下就不发布新版本先修回去再说。有人问过要不要完全自动化跑测试。如果你有API接入条件可以写一个简单的批量调用脚本把验证集逐条丢给模型然后比对输出是否包含预期关键词。这个秒级完成能省很多手动复制粘贴的时间。没有接入条件的手动跑也行关键是每次改动后都跑这个习惯必须坚持。6.3 发布与分享的规范技能改到稳定之后就到了发布的环节。即使是你自己一个人用我也建议按一个固定的打包规范来。我的做法是每个技能目录压缩成一个zip包包内包含SKILL.md、assets/、tests/、CHANGELOG.md、README.md。README里写清楚这个技能解决什么问题、怎么安装、怎么使用、依赖哪些外部文件。这样即使你几个月后再回头安装这个技能也不需要重新读一遍SKILL.md去猜它是干嘛的。版本号我直接沿用语义化版本规则大版本改动输出结构变化、工作流程重写升主版本小改动规则补充、描述优化升次版本错别字和格式微调升补丁版本。有版本号你在聊天记录里说我用的是doc-review v1.2和我用的旧版才能对上。6.4 维护与迭代的节奏好技能不是写完就行的它需要定期维护。我的节奏是每次使用后留意异常如果发现某次输出明显不对立刻记下来等攒够两三个同类问题就集中修一次。每月一次全面自查重新读一遍SKILL.md站在新用户视角问自己如果我现在第一次打开这个技能能看懂它在干什么吗版本节奏不要贪多一次只改一个核心点。我见过很多人在一次更新里塞了七八处改动测试通过就以为自己成功了结果换一个场景就翻车。维护不是额外的工作量它其实在为你省未来的时间。今天花二十分钟修一个规则以后每次调用这个技能都会少一点出错的概率。这笔账怎么算都不亏的。7. 常见问题速查与避坑经验7.1 高频问题与解决方案速查表下面这张表是从我自己的调试记录里整理出来的覆盖了新手最容易遇到的几类问题。症状可能原因解决方案该触发时不触发description写得太抽象缺少场景关键词把用户提交XX类文本时使用这类场景描述加进去不相关任务也触发description没有排除性描述加一句如果你只是想...不要使用本技能输出格式乱输出格式说明不够硬给一个具体的模板框架并注明必须严格按此结构输出行为不稳定指令里用了模糊形容词把认真仔细换成逐条对照checklist等具体行为上下文不够用SKILL.md太长塞了过多示例和术语把大块内容移到assets目录按需引用修改后效果反而变差没有做回归测试不知道哪次改动引起的建立验证集每次改动后全部重跑一遍技能之间互相抢触发多个description里有重叠的触发条件给每个技能添加明确的排除性描述这张表其实涵盖了我过去踩过的绝大多数坑。如果你遇到的问题是表里没有的建议按触发-流程-输出三分类法定位后再来找比盲目问人要高效得多。7.2 我踩过的三个坑第一个坑出在description上。最开始我嫌麻烦description只写了一句话帮助用户审校文档。结果这个技能上线后我发现Claude在我要求它写推广文案的时候也企图触发它输出完全没法用。后来我重写了description把使用场景限定在提交论文、技术方案、产品说明书等需要审校的文档场景这个问题就消失了。关键词要具体宁可多写几行也不要图省事。第二个坑是规则冲突。有一次我同时修改了工作流程和决策规则结果发现它输出的报告里一部分条目按新的逻辑走了另一部分还是旧逻辑。原因就是我没有一次只改一处导致新旧规则在模型的理解里产生了混淆。从那以后我给自己立了一条铁律每次更新只改一个模块测试过了再动下一个。第三个坑是上下文爆炸。早期我把整个术语表和十来个示例全部塞进了SKILL.md结果每次调用都要花掉几千字的上下文。处理短文档还行一处理长文档就开始丢前面的信息。后来我把能外置的内容全部外置SKILL.md瘦身到500行以内这个问题就再没出现过。写技能这件事克制和不克制效果差距真的很大。7.3 最后的实用建议如果你正准备开始搭建自己的技能库我建议你从需求最小、边界最清晰的场景入手。不要一上来就试图做一个全能助理技能那种大而全的技能通常最难写稳定而且调试周期极长。先把文档审校会议纪要这类单一功能的技能跑通你对这套机制的掌握会突飞猛进之后再做复杂的就顺了。还有一个容易被忽略的小事在技能里给你自己留一条后续扩展的备注。比如在CHANGELOG.md里专门放一个Idea区把使用中冒出来的新想法随手记进去。这样你每次迭代都有素材技能库是在持续生长的而不是停滞在初版。我在实际使用中还养成了一个习惯每个技能的第一版都故意不做完美而是先跑通主链路然后靠真实使用中的反馈来打磨细节。原因很简单坐在电脑前拍脑袋想出来的边界条件永远没有真实场景里冒出来的问题更贴近实际。与其闭门造车不如先放出去跑一跑再一步步收口。这也是我建议你采用的方式——先让技能活起来再让它好起来。