最近这大半年我几乎每周都会被问到同一个问题“Skills 到底是真的趋势还是大模型厂商造出来的又一个新概念”。一开始我也挺谨慎毕竟这行里概念泡沫见过太多了。但当我真把一个团队里的日常 Agent 拆开开始系统性地用 Skills 去重构它的能力边界之后我的结论变了这玩意儿不是提示词工程的包装它是目前少数能让 Agent 从“聪明但不可控”走向“稳定且可复用”的路径。这篇文章不会去复读官方文档我想以一个实际做过、上线过、踩过坑的开发者视角跟你聊聊我对 Skills 的理解它解决的问题是什么内部结构怎么设计上线时最容易在哪个环节翻车以及怎么把它从“一个人的小工具”变成“一支团队的基础设施”。如果你正在做 Agent 应用或者刚被领导指派去调研这个方向这篇文章应该能帮你省下不少试错的时间。1. Skills 不是提示词升级版它是 Agent 的“肌肉记忆”先说一个很多人都有的误解以为 Skills 就是把一段写得很长的 Prompt 套个壳、起个名字、存成文件。如果只是这样那确实没什么新意提示词工程早几年就玩透了。我理解的 Skills本质上是把“一次性会话里的临时聪明”沉淀成“可反复调用的稳定能力”它至少包含指令、工具绑定、验证机制、失败兜底和元信息五样东西缺一不可。1.1 一页说明书和一套工具箱的区别拿新员工入职来打个比方。你给一个刚毕业的聪明人一页说明上面写着“请负责代码仓库的日常维护”他大概率会愣在原地或者自己发挥出一套你完全没想到的流程。这相当于纯靠 Prompt 驱动的 Agent——模型很聪明但它不知道你仓库的分支规范、不知道历史安全红线、不知道哪些目录不能随便动。而 Skills 更像是你递给他一个完整的工作台一本写着“遇到哪种情况要怎么处理”的作业手册一套已经对齐口径的工具箱还有一张明确写着“哪些事你有权做、哪些事必须停下来问”的授权清单。这样新人哪怕完全没有你的经验也能用 70 分的水平完成任务而且不会闯祸。这就是 Skills 和提示词的核心分界线提示词负责“说清楚要什么”Skills 负责“把怎么做的路径固化成可执行、可验证的流程”。大模型这几年最大的变化是推理能力越来越强但推理再强每次都在裸奔状态、没有任何脚手架产出质量就永远只能靠概率。1.2 一个 Skill 的完整解剖五个必须有的部分我在团队内部用一套中性的结构描述 Skill落到任何具体平台上都可以按这套思路翻译。你手里的 Skill 文件不管长什么样内部都应该能拆出这五块组成作用类比描述与触发条件告诉模型这个 Skill 什么时候该用、什么时候不该用工具箱上的标签输入 Schema定义调用它必须提供哪些结构化参数申请单上的必填字段执行流程分步骤的核心逻辑含推理步骤和工具调用作业手册工具绑定封装好权限边界的外部工具与数据源已授权的工具箱验证与兜底输出校验、失败分支、能力边界声明质检员和保险丝这里特别想强调最后一项。很多自己写 Skill 的人会忽略“兜底”觉得只要流程写清楚就行了。但真实生产环境里模型一定会在你没想到的地方跑偏。一个没有声明“自己不会什么”的 Skill就像个什么都敢答应的实习生最后出事了背锅的还是你。2. 为什么 Agent 能力越来越强反而让 Skills 成为瓶颈按理说模型越智能我们越不需要做这种结构化的整理。但实际观察到的现象恰恰相反推理能力过剩之后真正拖后腿的反而是“能力的标准化程度”。你可以把模型想象成一台马力极大的发动机但没有合适的变速箱马力再大也跑不出速度。2.1 长上下文解决不了“经验沉淀”的问题有人说现在上下文窗口都上百万 token 了把所有文档塞进去不就行了理论上可以实际做过的都知道这不叫解决问题叫转移问题。把海量资料塞进上下文带来的是更高的成本、更慢的响应速度以及更不可控的输出——模型在几万字里“大海捞针”式找答案翻车的概率不比人少。Skills 提供的是另一条思路把处理问题的路径固化下来让模型每次只需要处理“当前这一步”而不需要从零开始理解整个背景。就像老中医的方子你把辩证和配伍的逻辑沉淀成了一张方子新来的大夫照着方子抓药不需要每次从黄帝内经开始读起。上下文解决“这个病人今天的特殊情况”Skills 解决“这个病以前是怎么治好的”。2.2 三个反直觉信号Skills 的时机已经到了我判断一个概念是不是真需求不看发布会看三个信号。第一个信号是我身边真正在做 Agent 落地的人已经不再无止境地优化那一百行 Prompt 了——因为他们发现收益边际递减得太厉害改一个字可能产生连锁反应最后不得不把所有分支状态塞进一条指令里那体验简直是灾难。第二个信号更直观长上下文的价格在被击穿但大家反而开始讨论“如何不把东西塞进上下文”。这说明行业里已经默认了把知识塞给模型不是最优雅的方案建立调用路径才是。第三个信号最实际各大 Agent 平台和模型服务商都在悄悄做类似“技能市场”的东西。资本和产品团队不会集体押注一个纯概念他们的动作已经证明了Skills 是当前阶段少数能把模型能力产品化的抓手。2.3 先有 Skills 还是先有大 Agent这个顺序问题我纠结过很久。一开始我倾向于先搭一个大的 Agent 框架把各种能力都接进来再慢慢整理。实践下来的感觉是反过来的先积累一批高质量的 Skills再让 Agent 去编排它们效果远好于先有框架再往里塞能力。一个 Agent 的实际能力大约等于“模型基础能力 × 工具质量 × Skills 数量和质量”。模型是产品自带的工具是标准化接口唯一能让你做出长期差异化、别人拿不走的东西其实是 Skills——因为它沉淀了你对具体业务的理解。所以我的建议是如果团队还在犹豫先别急着搭那套宏大架构从三到五个用得最频繁的 Skill 开始把流程跑顺了再说。3. 动手做一个能用的 Skill以“代码变更审查”为例概念聊太多容易飘我来分享一个我实际做过、用于团队日常 Code Review 的 Skill。选这个例子是因为它足够典型有明确的输入输出、需要调用外部工具、有判断逻辑、也有需要兜底的复杂分支几乎覆盖了一个 Skill 会遇到的全部设计问题。3.1 第一步先定义输入输出再写流程很多人做 Skill 有个坏毛病上来就写执行流程写到一半发现不知道最终要产出什么格式。正确顺序是先锁死输入和输出。我的“代码变更审查”Skill 输入是这样设计的{ diff: git diff 的原始文本, repo_path: 本地仓库路径, check_focus: [security, performance], max_report_size: 10 }输出必须是结构化报告每个问题都要包含文件路径、起始行号、风险等级、问题描述、修复建议五个字段。这种强结构的好处是后边不管是接自动化流程还是人工查看成本都极低。你可以灵活调整但千万别把输出设计成一段开放式的文字——那样你的验证机制就形同虚设了。3.2 第二步从零开始定义流程与工具绑定输入输出定了之后流程就顺了。我的 Skill 内部执行逻辑分成四段第一步读取 diff按文件拆分第二步根据文件后缀识别语言类型匹配对应的静态检查规则第三步对疑似风险点做上下文检索查一下相关模块的历史改动和已知问题第四步把中间分析结果汇总成最终的审查报告。工具绑定这部分容易翻车。我的经验是能少绑就少绑。这个 Skill 里我只保留了三个工具接口git 命令封装、静态检查器入口、内部文档检索服务。工具每多一个模型选错工具的概率就多一分别高估它的辨识能力。每个工具接口的说明里都写清楚“这个工具返回什么、什么时候不用它”这比在流程里反复强调“不要调用 XXX”更有效。3.3 第三步验证与失败兜底我的强制要求我个人对 Skill 有个强制性要求必须有验证和兜底否则不上线。这个审查 Skill 的验证环节做了三件事一是校验输出报告的字段完整度和风险等级的取值合法性二是检查修复建议里的路径和行号能不能在 diff 里对上避免模型编出行号三是对于拿不准的发现强制标记为“需人工确认”而不是让模型硬撑着下结论。失败兜底想得足够细生产环境才能睡得着觉。diff 太大时我的策略是拒绝一次性处理提示调用方把变更拆小或者只审查指定文件静态检查工具执行超时就走一个降级逻辑退化成纯规则匹配最关键的一条是所有涉及安全红线的问题即使模型置信度再高也默认转人工复核。这套 Skill 上线之后团队的人工 Code Review 量降了不少但更重要的变化是——大家不用再从头看一遍所有 diff只需要盯着模型标记出来的重点区域整个人效提升很明显。4. 上线后最常踩的五个坑完整排查链路Skill 本地写起来很爽跑几个测试用例也漂漂亮亮的一放到真实生产环境就开始花式出问题。我这几个月积累下来的教训基本都集中在这五个坑上。逐个说每个都有自己的完整排查链路。4.1 坑一描述写得太宽模型总是选错 Skill第一个坑出在 Skill 的描述description上。起初我写得很省事“用于代码审查”结果模型在用户询问“这段代码有什么问题”时居然调用了另一个“技术方案评审”的 Skill答非所问。排查了很久最后发现元信息里的触发条件描述太宽泛模型根本分不清两个 Skill 的边界。修复方式把描述当“选择分类器”来写。我现在的策略是写清楚三层信息使用场景、一定不要用的场景、以及核心关键词示例。例如我这个审查 Skill 的描述最后几行会写“仅用于已有 git diff 的变更审查。不要用于讨论整体架构设计。适用于 PR 合并前的快速风险扫描。”改完之后选错率直接降了一个数量级。模型不会读心它只能靠你给的指引来归类。4.2 坑二参数 Schema 太严把 Skill 变成了运气游戏第二个坑是输入参数的 Schema 设计得过于严苛。我一开始要求调用方必须传一个严格枚举的值传给 check_focus比如只能传 security、performance、correctness。结果实际使用中模型经常生成一个我没定义过的枚举值比如 maintainability然后整个调用直接失败。更尴尬的是失败信息不够友好用户看到的就是一句“参数校验失败”。排查了日志之后想明白一个问题模型从自然语言里提取结构化参数本来就是概率事件没有哪条规则能覆盖所有表达。修复方案是放宽枚举限制保留原始字符串在 Skill 内部做模糊匹配匹配不上的值不报错而是丢进一个“其他关注点”的文本字段让执行流程自己决定怎么处理。改完之后调用失败率几乎降到了零。参数校验这块合适的做法是“入口宽松、内部收敛”而不是把校验当成大门把用户挡在外面。4.3 坑三流程缺少退出条件Skill 陷入自循环这个坑最隐蔽也是最让我头疼的。有一阵子我的 Skill 在处理某些复杂 diff 时会出现反复调用检索接口的情况——模型觉得信息不够就继续查查完还不够再查。直到超时才中止。从日志看它在一个“更深入了解上下文”的循环里出不来了消费的 token 非常可观。根因是执行流程里没有明确的终止条件。我加了一条硬性规则上下文检索最多执行一次如果一次检索仍然无法确认风险就直接把问题标记为“需人工确认”不再继续追加检索。这相当于给 Skill 装了个保险丝——宁可让结果不那么完美也不允许它无限耗下去。这个思路后来也被我应用到了其他所有 Skill 上效果很显著整个系统的延迟和成本都更可控了。4.4 坑四工具权限过大一个失误把风险放大第四个坑跟安全相关印象特别深刻。我在某个版本里给代码审查 Skill 绑了一个工具作用是“自动拉取远程仓库最新代码”。本意是保证审查的是最新代码但有一次模型在处理一个边界情况时居然触发了“强制推送”相关的操作差点就把别人的分支覆盖了。虽然最后没有造成实际损失但那一次真的把我吓出一身冷汗。排查链路其实很简单日志显示模型拿到了一个权限过大的 git 接口。修复方案也不复杂就是做权限最小化——Skill 里的 git 操作只保留读取类命令凡是有写操作的命令一律先验证是否有交互确认。可能有人觉得这是平台层面的事但我的看法是Skill 的作者必须对自己封装的工具负责不能把希望寄托在模型的自律上。4.5 坑五缺少输出校验模型把幻觉包装得很像回事最后一个坑是关于输出不校验的问题。模型最擅长的就是用坚定无比的语气说胡话。在早期版本里我的审查报告偶尔会出现一些不存在的文件路径——但它会用特别合理的格式写出来通篇读过可能都发现不了。直到有一次一位细心的同事按报告里的行号去找问题结果那个文件压根不存在才知道出了问题。排查后发现我的输出校验只检查了字段是否存在没有校验字段间的语义一致性。修复办法是把“文件路径是否存在于 diff 中”当成硬性校验条件但凡路径对不上就直接拦截重新生成。模型被拦了几次之后生成符合要求的报告的比例也明显提高了——这说明正确的校验机制不光是安全网更是让模型学会收敛的约束力。5. 从一个小 Skill 到团队技能体系版本、度量与共享单点的 Skill 做完只是一个开始。真正让 Skills 产生指数级价值的是把它们从一个“个人脚本”升级为团队的“公共资产”。我在这条路上踩过一些坑也有些体会最后这块正好做个总结。5.1 把 Skill 当代码管理而不是当 Prompt 收藏夹很多人把 Skill 文件往文件夹里一扔改了一版之后旧版去哪了都不知道。我的建议是把 Skill 当成正经代码来管进 Git 仓库有独立的版本记录每次改动都要写清楚变更说明并且过一遍评审。我见过太多因为改了 Skill 的一个小逻辑结果影响了一堆下游 Agent 的案例——没有版本记录的时候连回滚都是奢望。倒也不是说要多重的流程至少要让每个 Skill 有 owner、有 changelog、有 Deadline这就已经比 90% 的团队强了。5.2 给每个 Skill 配一套“黄金测试集”Skill 的重构和升级非常容易引入回归问题。我采取的办法是给每个 Skill 配一个“黄金测试集”就是一小组真实的、固定不变的历史输入配上预期输出。每次改完 Skill先跑一遍这些测试用例管它跑得通跑不通结果一目了然。这个测试集的构建不需要一开始就很完善从三五个最常见的使用场景开始就行后续遇到线上问题就把它补进测试集里。慢慢地测试集就成了这个 Skill 的护城河它既是验收标准也是技能行为的说明书。我甚至可以这么说如果一个 Skill 还没有测试集那它还不算在“生产可用”状态。5.3 共享机制比知识库更轻、比代码库更人话团队协作里Skill 的共享也是个值得琢磨的事。知识库太重写一堆文档没人看代码库太硬核非技术同事根本没法参与。我现在的做法是维护一份“技能清单”每个 Skill 一页纸用途一句话说明、输入输出示例、适用和不适用场景、维护者是谁。这份清单由维护者定期更新团队所有相关成员都能看到相当于一个轻量级的技能目录。这么做的好处有两个一是避免重复造轮子想做什么先查一眼清单说不定已经有人做过了二是帮助团队识别技能覆盖的空白——比如每周都有人在手工做数据分析那就值得投入做一个数据处理类的 Skill。把 Skill 当成一个目录来运营团队对它的认可度就会高很多。5.4 值得优先投入的 Skill 方向排序最后说几个我实际生产环境里认为最值得优先投入的方向按价值从高到低排代码相关类审查、安全扫描、性能分析、代码迁移。这类 Skill 的输入输出最结构化也最容易验证。数据处理类清洗、格式转换、异常检测。业务方需求频繁且可以直接复用成熟的工具库。文档输出类周报汇总、会议纪要、项目复盘。见效快、日常使用频率极高但也最容易卷注意保持边界清晰。知识问答类绑定内部文档或数据库做垂直领域问答。这里最考察上下文检索的质量Skill 只是外壳底层库的质量才是关键。如果一个团队刚起步我建议先从第 1、3 类里各挑一个高频场景做起来跑通流程之后团队就会更有信心投入更多精力把体系建起来。我个人用了这段时间之后最大的体会是Skill 本质上是一种写给未来的固定格式的信——你把自己对业务的理解、踩过的坑、处理过的边界情况都化成结构化、可执行、带验证和兜底的能力单元。它不追求让模型变得更有创意而是让模型在重复劳动中变得稳定。能接受“稳定的 80 分”这件事往往比追求“时好时坏的 95 分”更实用。如果你正准备在自己的项目里引入 Skills我建议你先选一个每天都做、又有点烦的脚本化任务尝试把它变成你的第一个 Skill。等你真正跑通一次应该就能理解我为什么这么看好这件事了。