我观察到一个很有意思的现象最近身边搞AI应用的朋友聊天话题已经从“怎么写提示词”慢慢转向了“做Skills”。这个标题看起来简单其实就是当前AI Agent工程化里最核心的一个概念——把模型需要的能力打包成一套可以被复用、被调用、被管理的技能文件。你可以把Skills理解成给AI写的岗位说明书它比提示词更结构化比微调模型更轻量是目前把AI从“玩具”推向“生产力工具”最务实的一条路。这篇文章我就围绕这个标题把Skills是什么、为什么值得做、怎么设计、怎么写、怎么调试以及我踩过的一些坑完整分享出来适合正在做AI应用、Agent开发或者已经在用工具但觉得输出总差点意思的人参考。1. Skills到底是个什么东西先说个生活化的类比。你招了个实习生第一天你给他一份SOP告诉他“客户投诉的时候先道歉再记录问题超过三次转给主管”这叫流程文档。如果你什么都不给只跟他说“你看着办”那他就只能靠临场发挥结果时好时坏。大模型本质上就是那个极度聪明但缺乏经验的实习生你给它一个任务它靠的是训练时见过的大量模式来“猜”该怎么做。大多数时候能猜个大概但你要它稳定输出、按你的业务口径来、不犯低级错误光靠临场发挥是不够的。Skills就是那份SOP而且是一份模型能直接读懂、按步骤执行的SOP。在AI应用开发的技术栈里Skills通常是一组文件的集合核心是一个名为SKILL.md的Markdown文件里面写清楚这个技能是什么、在什么场景下触发、执行步骤是什么、输出格式是什么、注意事项有哪些。模型在运行时会读取这些文件把里面的内容当成行为准则来执行。说得更直白一点Prompt是给模型“看”的一段话Skills是给模型“长期收藏”的一整套操作手册。有朋友会问这不还是提示词吗搞这么大动静干嘛。区别在于三个地方。第一是结构性SKILL.md里通常会有结构化的frontmatter就像网页的meta标签描述这个技能的用途、参数、允许使用的工具模型可以靠这些字段来判断什么时候该调用哪个技能。第二是可复用性你可以把Skills放进一个目录跨项目、跨对话共享今天写好的技能明天还能用不用每次重新喂一遍。第三是进化能力Skills是独立于业务代码的文件资产你可以单独迭代它今天发现某个步骤有问题改一行Markdown就行不用重新训练模型。从我自己的实践看Skills解决的核心问题不是“让模型变聪明”而是“让模型按你的规矩办事”。模型本身的能力是够的缺的恰恰是稳定性和一致性。比如你让AI帮你写一份项目周报它可能这次记得写风险项下次就忘了。但如果有一个“周报生成器”的Skill里面明明白白写了“第一部分必须包含本周风险与对策”它就会每次都遵守因为这不是临时记住的要求而是它调用这个技能时的内置规则。还有一个容易混淆的概念需要理清Skills不是插件也不是Function Call。插件是做在系统里的模型通过API去调用外部程序Function Call是让模型输出结构化参数去触发代码函数。Skills则纯粹作用于模型自身的行为模式它不执行代码不发起网络请求它做的事情是“告诉模型用什么样的思考方式和流程去处理任务”。所以你可以理解成插件扩展了AI的手脚Skills规范了AI的大脑。2. 为什么突然大家都开始做Skills2.1 上下文窗口装不下真实经验做过AI应用的人都知道上下文窗口有多珍贵。很多人以为给模型的上下文越多越好实际上一段几千字的长篇大论塞进去真正被模型注意到的可能只有前后各一部分中间的内容权重很低。而一份真实场景下的操作经验动辄几千字根本塞不进每次对话。Skills的设计恰好绕开了这个限制。它不要求你把所有内容都塞进上下文中而是让模型在需要的时候主动去读取技能文件。看到SKILL.md的第一行有“此技能适用于需要生成数据分析报告的场合”模型就会自动加载对应的技能文件平时不加载。也就是说你不需要为一个低频操作长期占用上下文模型是按需读取的。这个机制我实测下来非常有用处理长文档和多轮对话时上下文被浪费的情况少了很多。2.2 一次性对话和经验沉淀之间有巨大鸿沟我见过很多团队用AI的方式是这样的遇到一个任务让AI生成一版结果人工改半天然后复制粘贴到文档里下次再做类似任务时又从零开始。这等于每次都在付“学费”但学到的经验全部浪费了。做Skills的核心价值就是把一次性的灵光一现沉淀成可复用的资产。你可以把上次对话里那句“这里还要补充客户反馈的数据”提炼成Skill里的检查项可以把人工修正过的输出格式设计成Skill里的模板。下次再让AI做同类任务它直接站在上次的最佳实践之上输出。这样积累三个月你的技能库就是你的团队最值钱的数字资产之一。2.3 团队协作需要一个标准接口几个人一起用AI的时候大家各自的提示词是散落在聊天记录里的根本没法统一维护。有人喜欢让AI用表格输出有人喜欢用要点每换一个人就要重新磨合一遍。Skills提供了一个很好的接口规范。你把技能文件放在共享目录里团队所有人统一引用同一个SKILL.mdAI的输出风格和流程就对齐了。这个体验有点像代码工程里的标准化接口——内部怎么实现不关心但对外的行为是恒定的。我们团队现在就是这样的每个场景维护一个Skill新人入职第一件事就是看一遍技能库而不是翻聊天记录。3. Skills的标准结构与核心写法3.1 目录结构让能力可以被发现如果你用Claude、Bytebase这类支持Skills的开源项目或者是自己搭的Agent框架推荐的目录结构大概是这样skills/ monthly-review/ SKILL.md scripts/ generate_chart.py assets/ template.md references/ examples.md每个子目录代表一个独立的技能命名要具体不要叫“helper”或者“utils”要叫“monthly-review”这种一看就知道干什么的名字。SKILL.md是这个技能的主文件描述技能本身scripts放辅助执行的脚本assets放模板、数据文件references放参考案例。这个结构不是硬性规定但按这个规范组织的好处是后续好维护也方便被支持Skills的框架自动识别。3.2 frontmatter技能的第一印象SKILL.md开头有一段YAML格式的frontmatter相当于技能的身份证。标准字段包含--- name: monthly-review description: 适用于生成月度项目复盘报告的场景。当用户提到“月报”、“月度复盘”、“本月总结”时应优先使用本技能。 max_iterations: 3 allowed-tools: bash, python ---name就是技能名注意不能有空格用连字符连接。description是最关键的字段这里写得越精准模型越能在正确的时候触发这个技能。我见过很多人把description写得又短又泛比如“用于生成报告”结果模型在写代码的时候也想着调用它乱套了。应该写清楚触发场景、触发关键词、使用时机甚至可以写明“当用户需要的是……时应使用本技能”这个“何时用”的标注是区分优质技能和普通说明文档的分水岭。max_iterations是限制模型在特定技能里最多执行多少轮这个字段在需要跑脚本或反复思考时特别有用防止模型陷入死循环。allowed-tools定义了该技能可以调用的工具范围能防止它做些你不期望的操作。3.3 正文部分告诉模型怎么把事做成写完frontmatter接下来就是正文这里是技术含量最高的地方。很多人的正文写得像产品说明书全是“你应该分析数据”“你应该注意细节”这类废话。模型看了等于没看因为没给出具体的判断标准和动作。好的正文应该包含四类内容。第一类是执行步骤用有序列表或分步骤标题让模型严格按顺序来比如“先读取输入文件再拆解指标再生成图表再撰写结论”。第二类是决策分支告诉它“当数据量小于100条时用表格展示当数据量大于100条时用图表展示”这类条件分支能让模型在不同输入下都能做出合理选择。第三类是禁忌事项明确写“不要在报告中出现‘我们觉得’这类主观表述”“不要输出超过一页的结论摘要”等这些负向约束往往比正向要求更有效。第四类是输出模板直接把最终输出结果的格式给出来让模型照着填填完即完成。我用一个非常接地气的例子来说明假设你要做一个“水果盲盒推荐”的Skill# 水果盲盒生成器 ## 前置信息 本技能用于根据用户口味偏好生成一份包含3种水果的盲盒推荐组合。 ## 执行步骤 1. 询问用户对甜度低甜/中甜/高甜、口感脆/软/多汁的偏好。 2. 根据偏好匹配水果库每类偏好选1种候选水果。 3. 组合成推荐清单每项注明匹配理由。 4. 输出最终格式。 ## 输出格式 盲盒名称xxx 包含水果 - 水果名xxx理由xxx - 水果名xxx理由xxx - 水果名xxx理由xxx 每日推荐理由一句话总结当日组合。模型看完这个文件就知道要做的事有边界、有路径、有输出物。它不会自由发挥成“我给你推荐苹果吧因为苹果健康”而是按你的逻辑来。3.4 别把SKILL.md写成论文写Skills一个很常见的冲动是面面俱到把一个技能写成几千字的操作手册。我一开始也犯过这个错误把能想到的注意事项全写进去结果模型在处理时反而抓不住重点表现为执行步骤混乱。经验法则单个SKILL.md控制在150到400行之间超过这个量就考虑拆分。如果你发现一个技能里同时包含了“生成周报”和“生成日报”两种逻辑就拆成两个独立的Skills各自维护。技能越小触发越精准越不容易出错。这个原则尤其适合团队合作拆小了以后大家各自维护自己负责的部分避免集中修改造成冲突。4. 一套能跑的Skills从0到1的实操过程理解了结构我们来完整走一遍从需求到落地。我就用“月度项目复盘助手”这个例子全程演示我是怎么做的。4.1 第一步明确边界宁可窄不要宽做Skills最忌讳的就是一开始就做一个“全能助手”。全能意味着什么都能干也就意味着它不知道什么时候该干什么。所以我的第一步永远是问自己这个技能要解决哪个具体的、反复出现的任务。月度复盘这个场景是我选定的因为它足够常见、足够标准化每个月底要汇总项目进展、发现风险、制定下月计划。边界定了以后还要定义输入输出。我这个技能的输入是用户提供的项目周报、指标数据或会议纪要输出是一份结构化的月度复盘报告包含本月成果、风险与问题、下月计划、资源需求四个部分。4.2 第二步先写一个最小可用版本不要一开始就想把所有细节写全先写一个20行的最小版本能够跑通主流程就够了。我第一版是这样写的--- name: monthly-review description: 生成月度项目复盘报告。当用户提出“写月报”“做月度复盘”“总结本月项目情况”时使用。 --- 1. 收集并整理用户提供的项目资料。 2. 按“本月成果、风险与问题、下月计划、资源需求”四块输出。 3. 每部分控制在5个要点以内。就这么简陋的版本测试下来已经能输出一个基本可用的报告了。虽然没有亮点但框架是对的。这一步最大的意义是让你验证“技能能不能被正确触发”——如果模型能在用户提出月报需求时自动读取并执行这个Skill说明路径是通的剩下的都是优化问题。4.3 第三步给AI建立验收用例做工程的人都知道没有测试的代码不是好代码。做Skills也一样我强烈建议你给每个技能建立两到三个验收用例每次修改完技能就跑到用例上验证一遍。我这个月报技能我设了三个验收标准给一段乱糟糟的聊天记录要能提炼出成果和风险。给一份表格数据要能挑出最重要的数据和变化趋势。不给输入直接说“写个月报”要能反问用户要材料而不是自己编数据。这三个用例覆盖了正常输入、结构化工件输入、信息缺失输入三种情况。跑用例的时候我发现第一版对第二种情况处理得很差表格数据基本上就是原样搬到报告里没有分析。于是我在Skill正文里加了一条规则当输入中包含表格数据时必须比较连续两个周期的变化并在“本月成果”中用“环比增长/下降x%”的句式描述。这个改动很小但效果立竿见影。这就是我做Skills的一个核心方法论用一个技能定义配一套测试用例再配合一次次跑用例发现差异循环迭代。4.4 第四步持续迭代积累“防呆”内容我用这个月报Skill大概用了三个月期间迭代了七八个版本。每次修改几乎都来自实际使用中的差错。比如发现模型偶尔会忽略用户手动指定的格式要求我就把“如用户明确指定输出格式则优先遵循用户格式而不是本技能默认格式”写进了步骤里。又比如发现模型常常把“风险”写成“挑战”然后给出一个模糊的描述我就在禁忌里写“风险部分必须包含具体事件描述、影响范围、建议负责人禁止使用‘需关注’‘有一定风险’这类空泛表述”。迭代时间长了你就能总结出一个规律好的Skills都是长出来的不是设计出来的。一开始写得很完美的Skill几乎不存在因为真实业务场景的复杂度远超你的预判。设计阶段只需搭好骨架后面的血肉要靠一次又一次的真实使用去填充。我整理了一个简单的迭代记录表供参考版本核心变更变更原因v1建立四段式输出结构初始化v2增加表格数据分析指令表格数据被原样搬运v3增加“用户指定格式优先”规则模型忽略用户格式要求v4风险部分增加三个“必须”风险描述过于空泛v5增加反问引导策略缺少输入时模型乱编数据5. 常见问题与排查技巧实录5.1 为什么技能没有被触发这是所有人都遇到过的问题SKILL.md写得好好的但模型就是不调用。最常见的两个原因一是description写得不够精准模型不知道这个技能跟当前任务的关系二是技能太多模型检索时选错了。排查方法非常简单检查模型输出的原始日志看看它读过了哪些文件、选择了哪个技能。如果是前者就把description写得再具体一些把触发场景的关键词直接写进描述里。如果是后者就要考虑减少技能数量或者把description里的触发条件写得更有区分度。比如“写代码”和“写周报”这两个技能描述里必须有明显的语义距离否则检索时会互相打架。5.2 模型执行技能但效果不符合预期顺着执行了但输出的东西不对。这种时候先别急着改正文先明确是流程问题还是内容问题。流程问题指的是模型没有按照步骤顺序执行比如先输出了结论再给数据那你需要加强步骤间的因果约束把“先分析再结论”这种依赖关系写清楚。内容问题指的是步骤执行了但每个步骤产出的质量不行那就需要单独加强那个步骤的约束和示例。我遇到过很典型的情况模型在“风险分析”这一步做得不好不管怎么催都只能列出“进度有延迟”“需求不明确”这种通项问题。后来我分析发现问题出在技能正文里没有给出“风险分析的角度”模型只能联想到培训时见过的泛泛风险。于是我在正文里加了一条“从进度、质量、成本、人员四个方面逐一排查”效果立刻好了。模型真的需要显式的引导你给它越具体的思考维度它输出越靠谱。5.3 技能文件越来越胖性能下降刚才说的迭代会让SKILL.md越来越完整但超过一定长度后性能不升反降。我见过一个技能写到上千行的模型加载时要读半天执行时还容易遗漏早前写的规则。这种情况我的处理办法是拆分或外置。把参考案例、输出模板、示例数据这类内容移到references目录或assets目录里SKILL.md只保留核心规则把“资格判断”和“内容生成”拆成两个技能前者负责筛选输入后者负责生成输出。另外一个技巧是利用“分块控制”在SKILL.md里用标题将内容分成明确的块模型按块读取时更容易定位到相关内容但这个技巧要求模型支持按需加载文件内容使用时要确认你的基础模型能力支持。5.4 常用调试动作清单这套Skills调试方法论我用了很久分享给你一套完整的动作清单动作一日志法。记录每次运行的原始日志看模型实际读取了哪些内容不靠猜靠数据。动作二单步法。把技能停用改为手写Prompt一步步执行对比和用技能时的差异定位到底哪一步被Skill扭曲了。动作三锚点法。在SKILL.md里把重要指令放在“##”级别的标题后让这些内容成为醒目的锚点模型更容易遵循。动作四换模型法。同一个技能换不同模型测试能判断是技能写得不好还是模型本身能力不足。5.5 一个速查表Skills调试现场现象大概率原因快速对策技能没触发description模糊重写description加入触发场景词技能触发但输出空泛正文缺少具体指令补充决策分支和输出模板步骤顺序错乱流程依赖未说明明确“先做A再做B基于A的结果做B”忽略某条规则规则藏在长段落中用加粗/引用/独立标题突出关键规则输出格式不对没有给出模板在正文末尾粘贴完整输出样例运行超时/死循环没有max_iterations在frontmatter中限制最大迭代次数6. 横向延伸Skills还能怎么用6.1 个人知识管理的视角每个人都有自己的工作流。比如我做知识管理以前是给AI一段资料让它帮我整理摘要。现在我会把这个流程做成一个“资料精读”Skill规定它必须先提取核心论点、再梳理论据链、最后给出我的可执行启发。这个思路特别适合写文章、做研究、准备提案的场景。你把资料丢进去AI按你的阅读习惯产出而不是AI按它的理解产出一个模板。6.2 团队协作与流程资产化到了团队层面Skills的意义就更大了。你可以把团队内部的标准操作流程做成Skills比如“客户支持工单处理”它规范了服务人员处理工单的步骤——先诊断优先级再搜索知识库查找失败则提供临时方案并升级。这类技能的价值不仅是提升个人效率更是把分散在个人脑子里的经验转化成了组织可以共享的数字资产。新人培训的周期会明显缩短因为AI可以把核心SOP完整执行给新人看。我经历过一个很实际的变化以前团队里只有一个人会写某些特定报告他休假的时候其他人完全接不上手。后来我们把他的工作流程做成了三个Skills现在任何一个人都可以让AI按那个流程生成报告再人工审核交付。虽然AI生成的版本不如老手那么精准但起码把“能力真空期”填上了。6.3 从Skills到产品功能如果你是做SaaS或做AI应用产品的Skills还有一层意义它可能会成为你产品的差异化能力。现在很多AI产品都在拼模型规模和提示词数量但真正拉开差距的是“基于场景的重度规则”。你花三个月积累的领域Skills对用户来说就是“这个AI真懂我们这行”的来源。这个资产别人很难复制因为它是你行业经验的数字化沉淀。我建议做产品的人可以从现在开始把每次跟用户的对话、每个高频反馈都留档慢慢整理成Skills。半年后你的产品背后的“技能库”就是你的竞争壁垒。6.4 从哪开始积累你自己的Skills库如果你还没开始我的建议是挑一个你本周就要做、且重复去做的工作把它做成第一个Skill。不要挑很难的就挑“写给客户的英文邮件”这种高频小事。把流程写下来跑几轮修正几轮。等你体会到每次都能让AI稳定产出合格邮件的感觉你自然会想把更多的事情沉淀成技能。我自己这几年做项目有一个体会AI能力的上限由模型决定但AI价值的底线是由工程和流程决定的。Skills就是那个把“灵光一现”变成“稳定可复制”的工程手段。每次写Skill时我都会先手写一遍流程再把它翻译成AI能理解的语言这让我想得更清楚。如果你也想让AI从随机发挥变成稳定交付从做一个Skill开始一定不会亏。