最近Codex把Skill这个概念彻底带火了Cursor、Trae这些工具也都在跟进我身边不少朋友都在问同一个问题Skill到底是什么它能不能自己越变越强作为一个从去年就开始折腾Agent工作流的人我想借这篇东西把Skill的底层逻辑掰开揉碎讲清楚。这篇文章适合正在用Agent做正经事的人也适合想自己动手写Skill的人尤其适合那些已经发现“直接对话让Agent干活”越来越不靠谱、想换个思路提高稳定性的朋友。我的核心观点先放这儿Skill确实有自我进化的潜力但它的进化路径不是玄学而是两条非常具体的路——一条是从操作轨迹里归纳经验一条是在文本空间里持续优化指令描述。两条路合流之后Skill才能从“能用”变成“好用”。1. Skill的基本盘它不是插件而是一份“经验包”1.1 Skill和插件、Agent、Prompt到底有什么区别我见过特别多人在讨论Skill的时候把它和插件、Agent、Prompt混在一起说。它们确实有关系但完全是四层东西。Prompt是最原始的指令就是你在对话框里跟模型说的那段话。插件是外部工具比如浏览器插件、搜索插件、画图插件它们负责给Agent“接上手和脚”。Agent是一个完整的执行体它能接收任务、拆解步骤、调用工具、输出结果。而Skill你可以把它理解成“针对某类任务的完整方法论”——它不只是一个Prompt它可能包含指令、示例、约束条件、检查清单甚至包含一两个配套脚本。我打个比方。插件是工具箱里的电钻Agent是个施工队Prompt是工头喊的一句话“把这面墙打个孔”Skill则是施工队手里的那本《标准打孔作业指导书》里面写了怎么定位、用什么钻头、打到什么深度算合格、遇到钢筋怎么办。没有Skill的Agent也能干活但有Skill的Agent干活的质量、稳定性和复现性完全不是一个量级。1.2 为什么Skill突然这么火Skill本身不是新东西老早就有RAG、Few-shot这些概念本质上都是在给模型“喂经验”。但Skill真正变成大众话题是因为Codex和Cursor把它的产品形态做出来了普通用户也能通过一个“Skill Creator”或者“Skill Recorder”把自己的操作沉淀成Skill。这里有一个关键转变过去我们让Agent变好靠的是“调Prompt”——模型发挥不稳定我们就一遍遍改描述本质是在文本空间里做工程。而Skill给了一条新路子让Agent先做事把做事的轨迹记录下来然后从轨迹里归纳出规律和步骤最后再把这些规律写回文本指令。这一下子就把“怎么让AI变强”从纯手工调教变成了半自动化的流程。另外还有一个现实原因就是Agent模型本身越来越强但光靠强模型远远不够。模型再聪明遇到一个行业特有流程比如电商运营里的竞品分析、物流发货里的异常排查没有经验输入一样会踩坑。Skill就是那个“经验输入”它让模型在不需要重训的情况下把特定领域的know-how带进每一次对话。2. 轨迹归纳Skill的“观察学习”阶段2.1 什么是轨迹归纳它解决什么问题轨迹归纳这个概念听起来玄其实特别直白——就是让Agent自己干活然后把它的操作过程记录下来再从中提取出稳定、可复用的步骤。我举一个具体场景。假设你想让Agent帮你写一份数学建模比赛用的摘要。你直接说“帮我写数学建模摘要”它大概率写出一篇空话连篇的玩意儿。但如果你先让Agent做几次实验性任务每一轮都记录它做了什么、在哪里卡住、你给了什么修正最后把这几轮轨迹放在一起对比你会发现成功的摘要往往都有固定的结构——背景一句、问题一句、方法引用一句、结果数据一句、创新点一句。这个结构就是从轨迹里归纳出来的Skill核心。而且轨迹归纳最大的价值是能把那些“用户自己都说不清”的经验挖出来。很多时候你心里觉得“这份报告写得好”但你说不出好在哪里。可如果你让它反复写十次对比你反馈“好”和“不好”的那些轨迹差异点自然就浮现出来了。这就是从数据中学习而不是从语言中学习。2.2 Skill Recorder的工作原理与完整流程现在很多工具里已经内置了Skill Recorder用法大同小异但背后流程基本是四步采集轨迹、清洗归并、提炼步骤、生成Skill文件。第一步采集轨迹就是给Agent一个稍微大一点的任务让它连续操作过程中把每次动作、每轮对话、每个工具调用结果全部记录下来。这步的核心是任务选型——任务不能太小太小归纳不出规律也不能太大太大全是噪声。我一般会选一个“做完之后有明显优劣之分”的任务这样方便后续对比。第二步清洗归并就是把轨迹里那些无关的中间步骤去掉。比如Agent可能在搜索阶段多翻了两页或者在格式化输出时试了三次这些都属于噪声。清洗的时候要看“这步是否直接服务于最终结果”而不是“这步是不是被调用过”。第三步提炼步骤是把清洗后的轨迹转成“步骤序列”。我用的是最朴素的方法先把轨迹按阶段切分再给每个阶段写一句“这一步在干什么”最后检查这些描述能不能被另一个人或另一个模型理解。如果某一步描述很模糊说明这一步还要继续拆。第四步生成Skill文件就是把这些步骤、约束、示例按照固定的格式写进一个文件里通常叫SKILL.md。Codex的Skill文件里会有name、description、instructionsinstructions里就是归纳出来的步骤。这一步的关键是“描述要抽象到适用范围又要具体到可执行”。2.3 轨迹归纳的边界为什么纯记录容易翻车我踩过最大的一个坑就是以为记录得足够多Skill就足够强。实际完全不是。首先是“过拟合”问题。如果你只记录一次成功轨迹归纳出来的Skill大概率只适合那一种情况。比如你让Agent整理一个Excel表如果轨迹里恰好没有处理合并单元格的步骤那这个Skill遇到合并单元格就会懵。解决办法是多记录几条轨迹至少三条最好覆盖边界情况。其次是“噪声污染”问题。Agent在执行任务时经常会有一些“看似相关但其实没必要”的动作比如重复调用搜索、过度验证、甚至绕远路。如果轨迹清洗不干净这些噪声会被当成经验写进Skill导致以后每次执行都会做一遍无意义的操作。我见过有人归纳出来的Skill里有“每写一段就重新读一遍全部资料”这种冗余步骤效率被拖慢好几倍。还有一个更隐蔽的问题轨迹归纳只能归纳“做过的事”归纳不出“没做过的更优方案”。如果你的操作路径本身就不是最优的那轨迹归纳只是在把次优方案固化下来。所以我现在给自己定了个规矩轨迹归纳只能作为Skill的初稿不能作为最终版本它必须再过一遍文本空间优化。3. 文本空间优化Skill的“认知迭代”阶段3.1 文本空间优化到底是什么如果说轨迹归纳是从行为中学习文本空间优化就是从语言中学习。它做的事情其实非常像传统的Prompt Engineering但对象不是一次性对话而是Skill文件里的那段“方法论描述”。文本空间不是物理空间它是一个抽象的语义空间。模型对一段文字的理解本质上是在这个空间里做向量匹配。你写进Skill里的每个词、每句话都会影响模型把它“激活”到什么程度。文本空间优化就是通过调整Skill里的描述方式让模型在推理时更准确地命中你想要的那个行为模式。我举个很直观的例子。有一条Skill要求是“写一份数据分析报告”。这个描述太宽泛模型可能给出各种类型的报告。改成“写一份面向业务决策者的数据分析报告结论在前、过程在后图表解释不超过两行所有数字必须注明来源”。后者在文本空间里更接近“结构化表达”和“决策简报”这两个语义簇模型输出的稳定性一下子就不一样了。3.2 从Prompt Engineering到Skill工程最大的变化是什么很多人觉得文本空间优化就是Prompt Engineering换了个皮我一开始也这么想。但后来发现有个本质区别Prompt Engineering优化的是“单次对话的触发词”Skill工程优化的是“一套可复用的方法论描述”它要兼顾多层目标。第一层是“触发准确性”。模型的调度器看到你的Skill描述之后要能判断什么场景调用这个Skill。如果描述里的关键词和实际任务匹配不上Skill再优秀也不会被调用。我在日志分析Skill里就吃过这个亏——我把它描述成“解析日志并统计异常”结果模型在遇到“日志报错排查”这种任务时根本不调用它因为“报错排查”和“解析日志”在语义上匹配度不够。第二层是“步骤可执行性”。每个步骤的描述必须让模型知道具体做什么。如果你写“评估数据质量”模型可能不知道到底怎么评估你要写“检查缺失值占比、检查重复记录数、检查数值列是否有异常极值”这样模型才有手可下。第三层是“边界约束力”。你要让模型知道什么不能做、做到什么程度算停。个人经验是“你不允许”这类硬约束的效果通常好于“你尽量不要”这种软约束。所以Skill工程里的文本优化不是改一句两句话而是要对整个描述体系做分层打磨。这比传统Prompt工程要重得多但效果也持久得多。3.3 文本空间优化的四种常用操作与实战示例我这几百个Skill优化下来真正的有效操作基本可以归成四类浓缩抽象、关键注入、约束重写、反例补充。浓缩抽象是把原来冗长的描述压缩成高信息密度的短句去掉修饰词保留动作和对象。同一个意思“请尽可能详细地把报告中的每个部分都写到内容要丰富”不如“报告包含背景、方法、结果、建议四个部分每部分不少于200字”有效。前者在文本空间里指向“长作文”后者指向“结构化文档”。关键注入是把那些最能激活目标行为的词写进描述。比如做电商运营的竞品分析Skill就一定要写“价格段、销量区间、评价关键词、卖点差异”这些电商场里的核心语义词而不是只写“分析竞品”。这些词会直接把模型的注意力拉到正确的维度上。约束重写是把模糊的偏好变成明确的规则。比如“输出要专业”这种话它在文本空间里的指向非常稀薄。我会重写成“不使用感叹号、不使用‘我认为’每条结论附带数据引用结论段不超过三行”。实测下来约束越具体模型输出越稳。反例补充是我非常推荐的一招就是在Skill里明确写一段“不要这样做”。比如我在写“去AI味文章Skill”的时候就专门写了一条“不要使用‘随着时代的发展’‘综上所述’‘通过本文我们可以了解到’这类句式”。反例在文本空间优化里特别有用因为模型对否定指令的响应往往比肯定指令更干脆。每条核心约束配一个反例这个Skill的稳定性会有一个明显提升。4. Skill能不能自己变强两条进化路线的合流4.1 对比轨迹归纳是行为路径文本空间优化是语义路径现在我们可以回到标题那个问题了Skill到底能不能自己变强我的答案是可以但它的强不是凭空来的而是通过两条路径的交替推进实现的。轨迹归纳这条路解决的是“我不知道该怎么做”的问题。它从行为层面提取步骤和顺序让Skill从无到有。它的优势是贴近真实操作所归纳的步骤往往能被直接执行劣势是只能复现已有行为无法突破既有路径的天花板。文本空间优化这条路解决的是“我知道怎么做但做得不够好”的问题。它从语义层面优化描述方式让Skill从粗糙到精准。它的优势是能大幅提升稳定性和泛化性劣势是如果你连基础的步骤都没有纯做文本优化等于在空气上盖楼。两条路缺一不可。纯轨迹归纳产出的Skill往往笨重、过拟合、冗余纯文本优化产出的Skill往往空泛、落地性差、缺乏真实操作校验。我倾向于把轨迹归纳当作“发现”把文本空间优化当作“精炼”两者合流Skill才真正形成闭环。4.2 Skill的自我进化闭环记录、归纳、优化、再验证理论上最理想的状态是Skill能自己完成这个闭环跑任务、记录轨迹、从轨迹里发现偏差、把偏差优化进描述、再跑一次验证、通过后更新Skill文件。这件事现在已经有半自动化的雏形了你会在Agent的执行日志里看到“本次执行与Skill描述存在偏差”这类提示多半就是系统在帮你做轨迹对比。但在实际工程里我建议至少保留一个“人工验证闸门”。原因很简单自动归纳出来的偏差里有相当一部分是噪声而不是真问题。我见过一个案例系统把“模型在对话中多确认了一次用户需求”归纳为“用户偏好完整确认”结果以后每次执行都要强制做一轮重复确认反而拖慢效率。在自动进化机制还不完全成熟的阶段机器负责归纳人来负责判断这是目前最稳的组合。我自己的实践节奏是三个“一遍”第一遍跑完任务检查轨迹把明显的失败点和偏差记下来第二遍根据偏差去优化Skill描述重点看“是哪句话导致模型理解偏了”第三遍重新跑任务对比输出质量是否提升。三轮之后这个Skill基本就能达到稳定可用的状态。4.3 如何衡量一个Skill真的变强了很多人在优化Skill的时候没有指标稀里糊涂改了一通也不知道改得对不对。我分享三个我实测最有用的衡量维度。第一是成功率。同样一个任务给没有Skill的Agent和有Skill的Agent各跑十次统计成功次数。成功率提升是最直观的指标。注意跑的次数不能太少三次以内偶然性太大。第二是稳定性也就是输出的方差。有些Skill跑十次成功八次但失败的两次输出完全跑偏有些Skill跑十次每次都八十分没有惊喜也不出错。在绝大多数业务场景里稳定性比上限更重要。我会把十次输出的关键指标拿出来对比比如输出格式是否统一、关键结论是否一致。第三是泛化能力就是把这个Skill用到相近但不完全相同的任务上看还能不能站得住。写“竞品分析Skill”的时候拿它分析一个全新品类如果依然能输出结构完整、维度正确的分析说明这个Skill没有过拟合到某一个具体品类上。这三个指标我一般会做成一个简单表格每次优化前后各记录一次。很多你觉得“很强”的Skill一旦量化之后会发现其实只是自我感觉良好。有了量化对比Skill的进化方向才真正可控。5. 实操手把手写一个自己的Skill5.1 从零开发一个Skill的标准流程不管你是用Codex、Cursor、Claude还是自己写的Agent框架写Skill的标准流程大致相同。我建议按下面四步走。第一步设计任务边界。先想清楚这个Skill要覆盖的任务范围不要一开始就想着“大而全”。比如你想写一个“日志分析Skill”先确定它只处理Java后端日志还是也要处理前端错误日志、云平台审计日志。边界越清晰后面每一步都更好做。第二步搭建Skill文件骨架。目前比较通用的是一个目录里放SKILL.md主文件同目录下可以放examples、scripts等辅助资源。SKILL.md里通常包含三块name给Skill起个简洁的名字description写什么时候该调用它instructions写具体操作步骤和约束。如果平台支持前置条件检查也建议加上。第三步注入一次轨迹。这一步不能用“我以为”来写要真实跑一轮任务把行为记录导出来再从中归纳步骤。你可以用内置的Recorder直接生成也可以手动打开对话历史对着真实日志提炼。第四步做文本空间优化。把上一步归纳好的指令用我在第3章说的方法做一轮优化浓缩抽象、注入关键词、重写约束、补充反例。改完之后拿着优化版Skill再跑新任务验证。5.2 一个可直接参考的示例日志分析Skill我把我实际在用的一个日志分析Skill的核心结构简化后贴出来你可以直接拿去改一改用。假设场景是给Agent一份服务器日志文本它要做异常统计和根因初判。--- name: backend-log-anomaly-analysis description: 适用于Java后端应用日志的异常统计和根因初步定位。当输入内容包含 log、exception、error、堆栈信息且任务目标涉及排查、统计、定位问题时优先调用此Skill。 --- # 后端日志异常分析 ## 任务目标 从原始日志中整理出异常清单并对Top3异常做根因初判。 ## 执行步骤 1. 扫描全文提取所有包含 ERROR、Exception、Caused by 的行。 2. 按异常类型聚合统计每个类型出现的次数和时间范围。 3. 对出现次数最高的3种异常查找它们首次出现的时间点之前的20行日志定位触发上下文。 4. 对每种Top异常给出“异常名次数首次时间可能根因建议排查方向”格式的输出。 5. 最终输出必须包含一个汇总表按次数降序排列。 ## 硬性约束 - 不分析业务代码逻辑只依据日志文本。 - 不修改原始日志所有输出必须标注时间戳来源。 - 当某类异常出现次数少于3次时不纳入Top统计避免噪声。 - 禁止输出“疑似系统问题”这类无指向性的结论必须给出具体证据。 ## 反例 - 不要写“日志中出现大量错误建议关注系统稳定性”这句话没有任何排查价值。 - 不要把ERROR和Exception分开统计后放在两个表里必须合并成一张总表。这个Skill的核心就是明确适用边界、规定执行顺序、量化输出格式、禁止无价值结论。跑真实日志时稳定性比让Agent裸写要高不少。5.3 写Skill时的几个关键参数和自查清单最后再补充几个我在写Skill时一定会检查的参数。一是模型上下文窗口。Skill文件不宜写得过长如果instructions部分超过1500字很多模型的执行质量会下降因为大量上下文被Skill描述占用了。我一般控制核心指令在800到1200字再长就要拆分子Skill。二是description的触发命中率。写完之后用一个测试集去验证给一个任务看模型是否自动正确调用这个Skill。如果十次只命中五次说明description里的关键词和业务场景不匹配需要调整语义表述。三是示例的覆盖方向。我建议至少准备一个正常成功示例、一个边界情况示例、一个失败反例。示例的选取直接影响模型对Skill的理解深度比堆数量有用得多。四是指令的冲突检测。多个Skill并存时描述里不要有互相矛盾的规则。比如一个写作Skill要求“输出1500字长文”另一个摘要Skill要求“核心结论必须在开头200字内”同时被调用时模型就会精分。这时候你要通过Skill描述上的优先级标注来消除冲突。6. 避坑指南我踩过的几个坑与排查方法6.1 典型问题速查表我把自己和身边朋友踩过的Skill相关坑整理成了一张表按问题、现象、原因、解决办法四列来查。这不是什么官方文档是真实的翻车记录。问题现象常见原因解决办法Skill不被自动调用任务描述很明确但模型就是不触发Skilldescription里的关键词和任务语义不匹配用任务原词反推改写description加入同义词和业务术语输出格式不稳定同样一张表上次数值横排这次竖排约束项里没有规定“最终必须输出的固定结构”在Skill里给出明确的输出模板或字段顺序步骤跳过明明写了按顺序执行模型却只做第1步和第4步步骤描述太长模型在长指令中丢失了中间的步骤精简步骤数量每步只保留一个动作必要处改为子列表过拟合严重Skill换个数据集就不会写了轨迹归纳时只记录了一条成功轨迹至少补录三条轨迹覆盖不同边界指令冲突两个Skill同时被调用输出互相矛盾多个Skill描述有重叠或冲突规则在description里标注适用优先级或合并为一个Skill修改后不如之前优化一轮之后输出质量反而下降改动了核心步骤或者新加的约束和原步骤产生了矛盾用git记录Skill历史版本对比后决定是否回滚这张表背后有一个共同思路任何Skill问题先分清是“触发层问题”还是“执行层问题”。触发层问题去改description执行层问题去改instructions。很多人在写Skill时两个文件一股脑混在一起改结果越改越乱。6.2 独家心得什么Skill值得写什么不值得写写了上百个Skill之后我最大的心得其实是一个“反直觉”的结论不是所有东西都值得做成Skill。值得写的是那些“高频、有固定套路、犯错了代价高”的任务。比如电商运营的竞品分析、日志异常排查、周报生成、PPT大纲设计、数学建模摘要这些任务一周可能干好几次而且每次都有基本固定的套路做错了会很费劲。这种任务写成Skill一次投入长期受益。不值得写的是那些“低频、强创意、非结构化”的任务。比如让Agent帮你头脑风暴一个营销点子这种任务本身就是越散越好给Skill反而会限制它的发散能力。再比如纯闲聊类的任务做成Skill纯属浪费。还有一个我个人的判断标准如果你能在一句话里说清楚这个任务的固定套路那它不值得专门写Skill如果要用一大段话才能说清楚才值得写。另外一个很实际的心得是Skill的维护成本比你想象得高。Agent的能力在持续升级同一个Skill在上个版本模型里效果很好换到新版模型可能会因为调度策略变化而失灵。所以我会每隔两三周系统性检查一遍常用Skill跑三个标准任务验证是否还稳定。结尾一点个人的实操体会最后再分享一个我最近才真正想明白的事。很多人听到“Skill能自己变强”就很兴奋觉得以后可以完全放手让Agent自动进化。但从我这些天反复折腾的实际情况来看现阶段Skill的进化更像是一场“人机协作的接力赛”——机器负责从轨迹里发现规律人负责在文本空间里做决策和判断。你问Skill能不能自己变强我的回答是能但它需要你帮它看清方向。一个好的Skill开发者某种程度上更像是一位教练你不是替选手去跑而是通过录像回放轨迹归纳和战术板文本空间优化让选手下一场比赛比上一场打得更聪明。这套流程上手不难关键是愿意多跑几轮、多记录、多对比。按照我说的三步走——跑一遍、记下偏差、改描述你现在手头最简单的那个Agent任务说不定明天就能变成你的第一个Skill。