最近有个问题一直在我脑子里转Skill到底能不能自己变强我在Claude Code里攒了十几个skill有的越用越顺手有的用两次就扔了。后来我琢磨明白一件事——Skill本身不会变强但设计得当的Skill机制可以持续让它变强。这篇文章就围绕“从轨迹归纳到文本空间优化”这条进化路径结合我自己折腾AI编程和Agent工具的经验聊聊Skill技能系统的底层逻辑以及它离“自我进化”到底还有多远。如果你也好奇为什么别人的Skill一用一个准、自己的Skill总是关键时刻掉链子或者想知道那些“自动生成”“自动优化”的Skill工具到底靠不靠谱这篇文章应该能给你一个比较完整的答案。1. Skill到底是什么从提示词模板到技能封装1.1 为什么我们不再满足于“把话说明白”早期用AI聊天的时候我的习惯是尽量把需求描述得具体背景是什么、目标是什么、输出格式是什么。这套做法在对话式AI时代很好用因为模型足够聪明你说清楚它就能做。但等我开始大量使用Codex、Claude Code这类Agent工具问题就来了同样一堆指令我每天要重复输入好几遍而且每次还不太一样漏一句效果就差一截。后来我意识到真正需要的不是一段“临时的说明文字”而是一个“可复用的步骤包”。这就是Skill存在的意义。通俗地说Skill是把某个领域做成一件事情的完整经验——包括触发条件、执行步骤、判断规则、示例输出、边界约束——封装成一个独立文件让AI在需要的时候自动加载并执行。它看起来像提示词但比提示词多了一层结构化和可管理性。1.2 一个Skill的解剖结构我以Claude Code和CodeBuddy这类工具的Skill格式为例拆解一个完整Skill的构成。大家在热词里看到的“skill脚本”“skill插件”“skill creator”本质上都是围绕这套结构做文章。一个典型的Skill文件SKILL.md大概长这样--- name: log_analyzer description: 分析错误日志定位根因。当用户提到“日志”“报错”“异常”时使用。 --- ## 步骤 1. 收集日志文件路径确认文件存在 2. 过滤出 ERROR 和 WARN 级别 3. 按时间窗口聚合找出高频错误 4. 结合上下文输出根因假设 ## 示例 输入: 帮我看看这个日志 输出: 在13:54-14:02窗口出现87次 MySQL 连接超时疑似连接池耗尽 ## 约束 - 不臆测错误原因必须基于日志证据 - 输出不超过200字这个结构里description是灵魂steps是骨架examples是血肉constraints是护栏。我见过很多新手写Skill把大量精力花在步骤上描述却写得很敷衍结果AI根本不知道该不该启用这个技能最后Skill成了摆设。1.3 Skill和Agent的区别热词里的高频问题这次热搜词里有一个“skill和agent的区别”我猜很多人被这两个概念绕晕了。我的理解很简单Agent是“主体”Skill是“能力”。Agent负责感知环境、制定计划、调用工具、迭代执行它像一个员工Skill是这个员工掌握的一项项专项技能像刀工、火候、摆盘。员工可以暂缺某种技能但技能离开了员工也无法独立干活。一个更准确的类比是Agent是厨师长Skill是后厨的标准化操作手册。厨师长决定今天做什么菜、怎么搭配但具体到“切葱丝必须多细”“炒肉几分熟”靠的是手册。所以你在一个Agent里可以挂十几个SkillAgent根据任务动态决定用哪个。这也引出了上下文工程里另一个高频问题Skill太多会不会互相干扰这个我放到后面专门讲。2. 轨迹归纳Skill诞生的第一步2.1 什么是“轨迹”为什么它这么值钱轨迹trajectory这个词在AI学术圈已经用了很多年近一年因为Agent学习方法论被重新带火。所谓轨迹就是AI在完成一次完整任务时的全过程记录它收到了什么指令、中途调用过哪些工具、写了什么代码、跑了什么命令、遇到什么报错、怎么修改、最终结果是什么。为什么轨迹值钱因为模型本身不知道自己是怎么做对的。一次成功任务的轨迹相当于一份“过程性经验”里面藏着大量细节——比如“先格式化再解析”“遇到编码问题就切换终端编码”——这些细节在最终结果里根本看不出来但它们才是任务成功的真正原因。我最早用Skill Recorder这类工具就是被这个点吸引住的把一次手动排查的完整过程录下来让AI自己回放、总结这比让人从零写一份保姆级说明书省力得多。2.2 从N条轨迹到一份Skill归纳的实操流程轨迹归纳Trajectory Induction不是AI自动就能完成的它需要人为设计一套流程。我现在常用的做法分四步。第一步收集。同一个任务至少收集5到10次成功执行的轨迹。注意是“同类型”任务不是“同一任务”。比如“分析线上日志”算一类它可以涵盖不同语言的报错、不同格式的日志文件、不同规模的输出。第二步对齐。把各条轨迹中的操作序列拉平找出公共步骤。比如5条轨迹里有4条都做了“先筛选级别再按时间聚类”那这就是公共步骤。有的轨迹多了一步“识别日志格式”有的没有那这可能是条件分支不是公共步骤。对齐的过程可以借助脚本自动完成但最终检查还是得由人来看因为有些步骤顺序不同但结果相同有些则一步都不能乱。第三步去噪。这一步最考验人。轨迹里大量操作是试错产生的比如“改了一下正则没生效又回滚了”。这类无效操作必须剔除否则Skill会变得臃肿。怎么判断有效操作只有一个标准去掉它最终结果还成立吗成立就删不成立就留。这个判断AI做不好因为它很难体会“没有这个步骤会怎样”需要人来把关。第四步结构化。把公共步骤写成步骤列表把条件分支写成“如果…则…”把典型输入输出写成示例最后加上约束。这个过程看起来不复杂但每一步都有坑其中最隐蔽的坑是过拟合。2.3 轨迹归纳的三个难点噪声、过拟合与泛化噪声的核心来源是模型自己。Agent在执行任务时经常会有试错动作这在人看来是“走弯路”但对轨迹记录来说它们是真实的路径。如果直接把轨迹当作标准答案去构造SkillSkill会继承大量无效步骤。我见过一个自动生成出来的Skill里面居然有一句“如果命令失败再试一次”这就是典型的噪声被当成经验了。过拟合的痛点是AI从少量轨迹里学到的“规律”很可能只是巧合。比如某一段时间所有日志都包含一个固定的前缀AI就把“删除该前缀”写成固定步骤等换了环境没有这个前缀Skill反而把正常内容误删了。这个坑我踩过不止一次后来养成了习惯任何从轨迹里归纳出来的步骤都要问一句“这个规律在所有场景下都成立吗”不成立的改成条件分支。泛化的本质是数据多样性问题。要解决过拟合不是靠聪明而是靠样本量。我建议至少准备三类不同场景的轨迹比如日志分析就分别找后端日志、前端日志、数据库日志各几次再让归纳环节自己识别公共模式。条件允许的话可以故意加入一两种极端边缘场景让Skill在归纳阶段就接触足够多的“变量”这样生成的步骤才不会在第一个陌生场景就崩溃。2.4 Skill Recorder从“录屏”到“技能回放”热词里反复出现“skill recorder”Codex、Claude Code这些工具目前都有类似能力。它的工作方式很像录屏软件你手动完成一次操作它把整个过程记录下来生成一段可复用的操作记录。区别在于录屏存的是画面它存的是结构化的步骤和工具调用。我自己用下来的感受是Skill Recorder是很好用的“素材收集器”但它不等于Skill。录出来的是原始轨迹最多帮你省掉手工整理步骤的功夫最终还是要经过一轮归纳清洗。很多人以为用Recorder录一次就能得到能打的Skill这是误解。真正有价值的不是“录”而是“清洗后形成的可复用逻辑”。3. 文本空间优化Skill变强的关键战场3.1 什么是“文本空间”它和模型训练有什么关系这是这篇文章的核心概念。“文本空间优化”听起来很高深其实一句话就能说清Skill的本质是文本我们改变Skill的方式是在文本这个空间里做编辑而不是去调整模型权重。传统意义上让AI变强靠的是训练和微调那是在参数空间里操作Skill给了我们另一条路——不动模型改作为输入的那段结构化文本也能改变AI的行为。打个比方参数空间优化是“改厨师的大脑”文本空间优化是“改菜谱”。改大脑成本高、周期长、风险大改菜谱成本低、见效快、可回滚。这也是为什么过去一年“skill”“提示词工程”“上下文工程”会被反复讨论——大家发现在Agent时代决定一个AI系统强不强的不只是基础模型还有你喂给它的那份“菜谱”。3.2 文本空间里到底能优化什么我梳理了一下Skill在文本空间里能被优化的维度至少有五个。第一描述优化。这是性价比最高的优化点。description写得好不好直接决定Skill能否被正确触发。我写描述有一个经验公式场景词加任务动词加触发条件加反例。比如“分析错误日志定位根因。当用户提到日志、报错、异常时使用。不要在用户只问日志含义时使用。”最后那句反例特别重要它能让AI少做很多误判。第二步骤优化。步骤的粒度是关键。太粗模型不知道具体怎么执行太细Skill会变得僵硬稍微换个环境就卡壳。我一般是“三步到六步”的粒度每步用动宾短语必要时再加一句解释性备注。步骤数量超过十步时我第一反应不是扩写而是思考能不能拆成多个子任务。第三示例优化。示例是给模型做参照的“标准答案”价值在于告诉模型“输出长什么样才叫好”。理想情况下两到三个正例就够关键是正例之间要有明显差异分别覆盖不同输入形态。比如日志分析Skill一个示例覆盖堆栈日志另一个覆盖业务日志模型就能学到“不同格式下我应该如何处理”。有些Skill还会放一个反例明确告诉模型“这种情况不要这么做”这种反向约束在防止模型跑偏时尤其管用。第四约束优化。约束是Skill的护栏包括输出格式、长度限制、安全边界。好的约束能让模型在跑偏时自动纠偏。我见过一个写得特别好的约束是“如果日志里没有直接证据输出‘证据不足’而不是猜测原因”这一句话几乎让整个Skill的可靠性提升了一个台阶。第五压缩优化。这对应热词里的“codex省token的skill”。Skill里塞了太多冗余描述和长示例每次调用都会烧掉大量token。压缩的核心原则只有一句话删掉不触发任何行为的语句。比如“这个Skill用于帮助用户分析日志”这种自我描述就是典型的冗余真正有用的是“当用户提到日志、报错、异常时使用”这样的触发指令。3.3 靠反馈自动优化从手工改到AI改前面说的都是手工优化但真正让Skill“自己变强”的关键是引入反馈闭环。最简单的做法是“执行后复盘”每次Skill执行完让Agent输出一段简短的复盘日志内容包括这次执行是否顺利、哪个步骤理解有偏差、最终结果是否达到预期、如果重来一次会怎么改。把几十次复盘日志汇总调用一次大模型让它在文本空间里直接把Skill更新一版。这个方案我在“日志分析Skill”上试过效果很直观。最初版本只有四个步骤第一轮优化增加了“识别日志格式”这一前置步骤因为复盘日志显示超过一半的失败都发生在格式识别环节。第二轮优化调整了输出格式让它更适配后续自动化流程。三轮下来这个Skill的测试集通过率从62%提到了88%。这就是文本空间优化的实证模型没变数据没变只是Skill文本变了行为就变了。3.4 蒸馏与去AI味文本空间优化的高级玩法热词里的“蒸馏skill”“humanizer skill”“去AI味的skill”本质上也是文本空间优化的不同方向。蒸馏是把大模型在大量案例上的表现浓缩成一小段可复用的Skill。它的核心是信息压缩把一堆完整示例、详细解释变成几行精炼的规则。这和模型蒸馏的思路一脉相承只不过蒸馏对象是文本而不是参数。蒸馏的好处是执行效率高、token消耗低代价是细节会被压缩掉遇到边界情况时稳健性会差一些。去AI味则是一个很有意思的优化目标。目标是让Skill输出更接近自然人类写作而不是一眼看上去就是机器味。做法一般是在约束里加“避免总结式开头”“少用首先其次最后”“允许适度口语化”再配几个“人类风格”的正例。这个方向在写作类Agent里特别流行我之前见过一个“hmmanizer skill”跑出来的文案几乎没有模板痕迹靠的就是这种文本层面的约束调整。4. Skill能自己变强吗机制比魔法更现实4.1 变强的是“系统”不是“Skill”现在回到标题的核心问题Skill能自己变强吗我的答案是单独一个Skill文件不会自己变强但如果把它放进一个“执行-反馈-归纳-更新”的闭环系统里它就能持续变强。这个闭环的完整链路是Agent在执行任务时生成轨迹轨迹经过归纳变成SkillSkill在文本空间中被优化优化后的新Skill回到Agent库中下一次执行产生新的轨迹如此循环。每一次循环Skill都能更准确、更精简、更贴合真实使用场景。听起来很美好但这里有一个残酷的现实闭环里最核心的“评估”环节目前仍然高度依赖人工判断。Skill改了一版它是变好了还是变差了不是改了就算变好要看测试集的通过率需要有人在真实任务里验证。如果没有稳定的评估信号自动化优化就成了瞎改。这也是为什么很多号称“自动进化”的框架最后都要留一个人工确认的按钮。4.2 受控进化更稳健的现实路径我提一个和“完全自主进化”不同的概念——受控进化。意思是AI负责收集轨迹、生成修改建议、跑测试集人负责拍板。AI像实习生把所有可能的改进方案整理好交给你你决定要不要合并。这套模式我用了很长时间非常稳。每次更新Skill之前我会让大模型输出三个候选版本分别说明它们的改动点和预计收益。我挑一个或者综合一下再放到测试集上跑一遍确认没有退化才合并。整个过程里AI做了90%的体力活但它无法独立完成剩下的10%——因为它缺乏对业务目标本身的判断力。Skill优化的终点是业务结果而业务结果往往不在模型可感知的范围内。还有一个非常现实的问题完全自主进化意味着每次迭代都要调用大模型来改写Skill这个成本并不低。受控进化至少能保证每一轮改写都物有所值——至少是朝着人认可的方向在改。4.3 从“自动挖掘漏洞”到“数学建模”不同领域的自进化尝试热词里还有“测试用例skill”“数学建模skill”“国赛skill”这些其实说明了一个趋势Skill已经被各领域玩家当成“经验资产”来经营。高手写一套测试用例Skill新手直接下载使用再结合自己的轨迹做本地优化这就形成了一种社区化的“技能进化”。以“ai自动挖掘漏洞skill”为例这类Skill的自进化潜力很大因为漏洞挖掘有明确的正反馈信号——挖到真漏洞就是成功。这种强反馈场景最适合自动化优化。反观写作类Skill什么叫“好”就很主观自动化优化就难很多。所以我的判断是Skill能不能自我进化不取决于模型多聪明而取决于这个领域有没有清晰可量化的“成功信号”。有信号进化就发生没有信号所谓的进化只是换个说法罢了。5. 实操从0到1做一个能自进化的Skill5.1 第一步选定场景定好评估指标我拿“代码评审Skill”举例因为代码评审这个场景有天然的客观信号评审意见能不能发现真实问题。你不需要事先有完美答案只要有一批历史代码变更记录其中标注了哪些评论是有效的。评估指标建议用两个发现率评审中发现的真实缺陷占人工确认缺陷的比例和误报率评审意见中无关紧要或错误的占比。没有这两个指标后面的自动化优化就是无源之水。5.2 第二步用轨迹收集素材让Agent处理5到10个历史代码变更每次处理都开启轨迹记录。收集完成后你会得到一批原始轨迹。这里有个小技巧不要只收集成功的轨迹。失败案例同样重要。成功的轨迹告诉你“怎么做是对的”失败的轨迹告诉你“什么不能做”。我在归纳时会刻意把失败轨迹里的错误操作整理成约束条款放进Skill的constraints里效果比正面示例还好。5.3 第三步归纳初版Skill按之前说的四步法——收集、对齐、去噪、结构化。初版Skill我建议从简开始先保证主干流程正确不追求面面俱到。初版越简单后续优化空间越大。写完后简单跑两三个测试用例确认能跑通就可以进入迭代循环。这一步最忌讳的是“一开始就追求完美”。我见过有人花了一整天把Skill写得事无巨细结果测试时发现核心流程反而是错的全部推倒重来。先跑通再优化成本最低。5.4 第四步构建反馈闭环在Skill里加一个“执行后复盘”的步骤要求Agent每次执行完输出一份复盘记录内容包括本次评审覆盖了哪些文件、哪些评论是模型自己确认有价值的、有没有发现明显遗漏。把几十次复盘记录定期汇总让大模型基于这些记录生成Skill的改进版本再回填。这里要注意复盘记录本身也占token所以在设计Skill时要让它输出极简格式比如一行一个要点否则一轮优化下来成本会有点高。我一般把复盘输出控制在三行以内只保留“做得好的地方”“卡壳的地方”“建议改动”三个字段。5.5 第五步工具链与团队协作如果你和我一样在团队里用强烈建议把Skill纳入版本管理。一个Skill目录建议这样组织skills/code_review/ ├── SKILL.md # 主文件 ├── examples/ # 示例集 ├── feedbacks/ # 复盘记录 └── tests/ # 测试用例纳入Git管理后Skill的每一次变更都可追溯出了回归一查就清楚。团队协作时经验丰富的工程师负责“格式化和去噪”新人负责“跑测试集和提疑问”这样的分工能让Skill的进化速度明显加快。我见过不少团队把Skill当“私有文档”各自维护最后版本冲突得一塌糊涂所以版本管理这件事越早做越好。6. 常见问题与避坑指南6.1 Skill唤不醒问题八成在描述这是我最常遇到的问题。Skill文件写了一大堆结果AI就是不用它。排查思路很简单描述里有没有明确的触发词以及有没有反例。描述里写“当用户提到日志、报错、异常时使用”比写“这是一个强大的日志分析工具”有效得多。后一种写法在大模型眼里没有任何触发线索。6.2 Skill太多互相干扰Skill墙Skill Wall是真实存在的。我在一个Agent里挂了十几个Skill之后发现模型的响应质量不升反降。原因很简单上下文里塞了太多不相关的Skill定义等于给模型制造了大量干扰信息。解决办法是分层把高频Skill放在默认加载层低频Skill改成“按需加载”。描述写得精准让模型只在匹配时才读入对应文件能大幅缓解干扰问题。另外Skill的命名也要避免重叠两个Skill描述里频繁出现同一个触发词模型很容易选错。6.3 自动归纳的Skill太啰嗦很多自动生成的Skill继承了轨迹里的全部细节动辄几十个步骤这种Skill基本没法用。我处理的办法是“三步简化法”第一步删掉所有“如果失败就重试”之类的兜底句第二步把同类步骤合并成一步第三步把超过三行长的步骤全部改写。简化完如果步骤数还超过十个我就考虑拆分成两个Skill而不是硬塞一个。6.4 省token的Skill到底怎么省热词里“codex省token的skill”是个高频需求其实省token的诀窍就四个字删、压、换。删掉不触发行为的废话把长示例换成最短的典型代表把重复性表述换成表格或结构化描述。另外要控制复盘类输出的长度一段复盘记录控制在三行以内几十次下来就是不小的节省。6.5 常见问题速查表症状可能原因处理建议Skill唤不醒描述缺少触发词、无反例重写描述加入场景词与禁用场景执行到一半中断步骤粒度过大拆步骤补分支条件多个Skill冲突触发词重叠调整描述降频Skill改按需加载结果不稳定示例太少或太偏补2-3个差异化正例自动归纳太啰嗦噪声未被剔除手动去噪删无效兜底句更新后效果变差缺少测试集验证建立回归测试用数据判断最后再分享一个真实体会。Skill这个东西本质上是在和AI的“健忘”对抗。模型本身不记得上周你在某个项目里踩过的坑但Skill可以替它记住。而且我越来越确认一件事设计Skill时把“怎么做”写清楚很重要把“为什么这么做”写进去更重要。因为AI在遇到边界情况时只有理解了目的才能做出超出Skill文本本身的正确判断。这是我从“轨迹归纳”到“文本空间优化”这条进化之路上踩过很多坑之后最想跟大家说的一点。
从轨迹归纳到文本空间优化：Skill技能系统的自我进化之路
最近有个问题一直在我脑子里转Skill到底能不能自己变强我在Claude Code里攒了十几个skill有的越用越顺手有的用两次就扔了。后来我琢磨明白一件事——Skill本身不会变强但设计得当的Skill机制可以持续让它变强。这篇文章就围绕“从轨迹归纳到文本空间优化”这条进化路径结合我自己折腾AI编程和Agent工具的经验聊聊Skill技能系统的底层逻辑以及它离“自我进化”到底还有多远。如果你也好奇为什么别人的Skill一用一个准、自己的Skill总是关键时刻掉链子或者想知道那些“自动生成”“自动优化”的Skill工具到底靠不靠谱这篇文章应该能给你一个比较完整的答案。1. Skill到底是什么从提示词模板到技能封装1.1 为什么我们不再满足于“把话说明白”早期用AI聊天的时候我的习惯是尽量把需求描述得具体背景是什么、目标是什么、输出格式是什么。这套做法在对话式AI时代很好用因为模型足够聪明你说清楚它就能做。但等我开始大量使用Codex、Claude Code这类Agent工具问题就来了同样一堆指令我每天要重复输入好几遍而且每次还不太一样漏一句效果就差一截。后来我意识到真正需要的不是一段“临时的说明文字”而是一个“可复用的步骤包”。这就是Skill存在的意义。通俗地说Skill是把某个领域做成一件事情的完整经验——包括触发条件、执行步骤、判断规则、示例输出、边界约束——封装成一个独立文件让AI在需要的时候自动加载并执行。它看起来像提示词但比提示词多了一层结构化和可管理性。1.2 一个Skill的解剖结构我以Claude Code和CodeBuddy这类工具的Skill格式为例拆解一个完整Skill的构成。大家在热词里看到的“skill脚本”“skill插件”“skill creator”本质上都是围绕这套结构做文章。一个典型的Skill文件SKILL.md大概长这样--- name: log_analyzer description: 分析错误日志定位根因。当用户提到“日志”“报错”“异常”时使用。 --- ## 步骤 1. 收集日志文件路径确认文件存在 2. 过滤出 ERROR 和 WARN 级别 3. 按时间窗口聚合找出高频错误 4. 结合上下文输出根因假设 ## 示例 输入: 帮我看看这个日志 输出: 在13:54-14:02窗口出现87次 MySQL 连接超时疑似连接池耗尽 ## 约束 - 不臆测错误原因必须基于日志证据 - 输出不超过200字这个结构里description是灵魂steps是骨架examples是血肉constraints是护栏。我见过很多新手写Skill把大量精力花在步骤上描述却写得很敷衍结果AI根本不知道该不该启用这个技能最后Skill成了摆设。1.3 Skill和Agent的区别热词里的高频问题这次热搜词里有一个“skill和agent的区别”我猜很多人被这两个概念绕晕了。我的理解很简单Agent是“主体”Skill是“能力”。Agent负责感知环境、制定计划、调用工具、迭代执行它像一个员工Skill是这个员工掌握的一项项专项技能像刀工、火候、摆盘。员工可以暂缺某种技能但技能离开了员工也无法独立干活。一个更准确的类比是Agent是厨师长Skill是后厨的标准化操作手册。厨师长决定今天做什么菜、怎么搭配但具体到“切葱丝必须多细”“炒肉几分熟”靠的是手册。所以你在一个Agent里可以挂十几个SkillAgent根据任务动态决定用哪个。这也引出了上下文工程里另一个高频问题Skill太多会不会互相干扰这个我放到后面专门讲。2. 轨迹归纳Skill诞生的第一步2.1 什么是“轨迹”为什么它这么值钱轨迹trajectory这个词在AI学术圈已经用了很多年近一年因为Agent学习方法论被重新带火。所谓轨迹就是AI在完成一次完整任务时的全过程记录它收到了什么指令、中途调用过哪些工具、写了什么代码、跑了什么命令、遇到什么报错、怎么修改、最终结果是什么。为什么轨迹值钱因为模型本身不知道自己是怎么做对的。一次成功任务的轨迹相当于一份“过程性经验”里面藏着大量细节——比如“先格式化再解析”“遇到编码问题就切换终端编码”——这些细节在最终结果里根本看不出来但它们才是任务成功的真正原因。我最早用Skill Recorder这类工具就是被这个点吸引住的把一次手动排查的完整过程录下来让AI自己回放、总结这比让人从零写一份保姆级说明书省力得多。2.2 从N条轨迹到一份Skill归纳的实操流程轨迹归纳Trajectory Induction不是AI自动就能完成的它需要人为设计一套流程。我现在常用的做法分四步。第一步收集。同一个任务至少收集5到10次成功执行的轨迹。注意是“同类型”任务不是“同一任务”。比如“分析线上日志”算一类它可以涵盖不同语言的报错、不同格式的日志文件、不同规模的输出。第二步对齐。把各条轨迹中的操作序列拉平找出公共步骤。比如5条轨迹里有4条都做了“先筛选级别再按时间聚类”那这就是公共步骤。有的轨迹多了一步“识别日志格式”有的没有那这可能是条件分支不是公共步骤。对齐的过程可以借助脚本自动完成但最终检查还是得由人来看因为有些步骤顺序不同但结果相同有些则一步都不能乱。第三步去噪。这一步最考验人。轨迹里大量操作是试错产生的比如“改了一下正则没生效又回滚了”。这类无效操作必须剔除否则Skill会变得臃肿。怎么判断有效操作只有一个标准去掉它最终结果还成立吗成立就删不成立就留。这个判断AI做不好因为它很难体会“没有这个步骤会怎样”需要人来把关。第四步结构化。把公共步骤写成步骤列表把条件分支写成“如果…则…”把典型输入输出写成示例最后加上约束。这个过程看起来不复杂但每一步都有坑其中最隐蔽的坑是过拟合。2.3 轨迹归纳的三个难点噪声、过拟合与泛化噪声的核心来源是模型自己。Agent在执行任务时经常会有试错动作这在人看来是“走弯路”但对轨迹记录来说它们是真实的路径。如果直接把轨迹当作标准答案去构造SkillSkill会继承大量无效步骤。我见过一个自动生成出来的Skill里面居然有一句“如果命令失败再试一次”这就是典型的噪声被当成经验了。过拟合的痛点是AI从少量轨迹里学到的“规律”很可能只是巧合。比如某一段时间所有日志都包含一个固定的前缀AI就把“删除该前缀”写成固定步骤等换了环境没有这个前缀Skill反而把正常内容误删了。这个坑我踩过不止一次后来养成了习惯任何从轨迹里归纳出来的步骤都要问一句“这个规律在所有场景下都成立吗”不成立的改成条件分支。泛化的本质是数据多样性问题。要解决过拟合不是靠聪明而是靠样本量。我建议至少准备三类不同场景的轨迹比如日志分析就分别找后端日志、前端日志、数据库日志各几次再让归纳环节自己识别公共模式。条件允许的话可以故意加入一两种极端边缘场景让Skill在归纳阶段就接触足够多的“变量”这样生成的步骤才不会在第一个陌生场景就崩溃。2.4 Skill Recorder从“录屏”到“技能回放”热词里反复出现“skill recorder”Codex、Claude Code这些工具目前都有类似能力。它的工作方式很像录屏软件你手动完成一次操作它把整个过程记录下来生成一段可复用的操作记录。区别在于录屏存的是画面它存的是结构化的步骤和工具调用。我自己用下来的感受是Skill Recorder是很好用的“素材收集器”但它不等于Skill。录出来的是原始轨迹最多帮你省掉手工整理步骤的功夫最终还是要经过一轮归纳清洗。很多人以为用Recorder录一次就能得到能打的Skill这是误解。真正有价值的不是“录”而是“清洗后形成的可复用逻辑”。3. 文本空间优化Skill变强的关键战场3.1 什么是“文本空间”它和模型训练有什么关系这是这篇文章的核心概念。“文本空间优化”听起来很高深其实一句话就能说清Skill的本质是文本我们改变Skill的方式是在文本这个空间里做编辑而不是去调整模型权重。传统意义上让AI变强靠的是训练和微调那是在参数空间里操作Skill给了我们另一条路——不动模型改作为输入的那段结构化文本也能改变AI的行为。打个比方参数空间优化是“改厨师的大脑”文本空间优化是“改菜谱”。改大脑成本高、周期长、风险大改菜谱成本低、见效快、可回滚。这也是为什么过去一年“skill”“提示词工程”“上下文工程”会被反复讨论——大家发现在Agent时代决定一个AI系统强不强的不只是基础模型还有你喂给它的那份“菜谱”。3.2 文本空间里到底能优化什么我梳理了一下Skill在文本空间里能被优化的维度至少有五个。第一描述优化。这是性价比最高的优化点。description写得好不好直接决定Skill能否被正确触发。我写描述有一个经验公式场景词加任务动词加触发条件加反例。比如“分析错误日志定位根因。当用户提到日志、报错、异常时使用。不要在用户只问日志含义时使用。”最后那句反例特别重要它能让AI少做很多误判。第二步骤优化。步骤的粒度是关键。太粗模型不知道具体怎么执行太细Skill会变得僵硬稍微换个环境就卡壳。我一般是“三步到六步”的粒度每步用动宾短语必要时再加一句解释性备注。步骤数量超过十步时我第一反应不是扩写而是思考能不能拆成多个子任务。第三示例优化。示例是给模型做参照的“标准答案”价值在于告诉模型“输出长什么样才叫好”。理想情况下两到三个正例就够关键是正例之间要有明显差异分别覆盖不同输入形态。比如日志分析Skill一个示例覆盖堆栈日志另一个覆盖业务日志模型就能学到“不同格式下我应该如何处理”。有些Skill还会放一个反例明确告诉模型“这种情况不要这么做”这种反向约束在防止模型跑偏时尤其管用。第四约束优化。约束是Skill的护栏包括输出格式、长度限制、安全边界。好的约束能让模型在跑偏时自动纠偏。我见过一个写得特别好的约束是“如果日志里没有直接证据输出‘证据不足’而不是猜测原因”这一句话几乎让整个Skill的可靠性提升了一个台阶。第五压缩优化。这对应热词里的“codex省token的skill”。Skill里塞了太多冗余描述和长示例每次调用都会烧掉大量token。压缩的核心原则只有一句话删掉不触发任何行为的语句。比如“这个Skill用于帮助用户分析日志”这种自我描述就是典型的冗余真正有用的是“当用户提到日志、报错、异常时使用”这样的触发指令。3.3 靠反馈自动优化从手工改到AI改前面说的都是手工优化但真正让Skill“自己变强”的关键是引入反馈闭环。最简单的做法是“执行后复盘”每次Skill执行完让Agent输出一段简短的复盘日志内容包括这次执行是否顺利、哪个步骤理解有偏差、最终结果是否达到预期、如果重来一次会怎么改。把几十次复盘日志汇总调用一次大模型让它在文本空间里直接把Skill更新一版。这个方案我在“日志分析Skill”上试过效果很直观。最初版本只有四个步骤第一轮优化增加了“识别日志格式”这一前置步骤因为复盘日志显示超过一半的失败都发生在格式识别环节。第二轮优化调整了输出格式让它更适配后续自动化流程。三轮下来这个Skill的测试集通过率从62%提到了88%。这就是文本空间优化的实证模型没变数据没变只是Skill文本变了行为就变了。3.4 蒸馏与去AI味文本空间优化的高级玩法热词里的“蒸馏skill”“humanizer skill”“去AI味的skill”本质上也是文本空间优化的不同方向。蒸馏是把大模型在大量案例上的表现浓缩成一小段可复用的Skill。它的核心是信息压缩把一堆完整示例、详细解释变成几行精炼的规则。这和模型蒸馏的思路一脉相承只不过蒸馏对象是文本而不是参数。蒸馏的好处是执行效率高、token消耗低代价是细节会被压缩掉遇到边界情况时稳健性会差一些。去AI味则是一个很有意思的优化目标。目标是让Skill输出更接近自然人类写作而不是一眼看上去就是机器味。做法一般是在约束里加“避免总结式开头”“少用首先其次最后”“允许适度口语化”再配几个“人类风格”的正例。这个方向在写作类Agent里特别流行我之前见过一个“hmmanizer skill”跑出来的文案几乎没有模板痕迹靠的就是这种文本层面的约束调整。4. Skill能自己变强吗机制比魔法更现实4.1 变强的是“系统”不是“Skill”现在回到标题的核心问题Skill能自己变强吗我的答案是单独一个Skill文件不会自己变强但如果把它放进一个“执行-反馈-归纳-更新”的闭环系统里它就能持续变强。这个闭环的完整链路是Agent在执行任务时生成轨迹轨迹经过归纳变成SkillSkill在文本空间中被优化优化后的新Skill回到Agent库中下一次执行产生新的轨迹如此循环。每一次循环Skill都能更准确、更精简、更贴合真实使用场景。听起来很美好但这里有一个残酷的现实闭环里最核心的“评估”环节目前仍然高度依赖人工判断。Skill改了一版它是变好了还是变差了不是改了就算变好要看测试集的通过率需要有人在真实任务里验证。如果没有稳定的评估信号自动化优化就成了瞎改。这也是为什么很多号称“自动进化”的框架最后都要留一个人工确认的按钮。4.2 受控进化更稳健的现实路径我提一个和“完全自主进化”不同的概念——受控进化。意思是AI负责收集轨迹、生成修改建议、跑测试集人负责拍板。AI像实习生把所有可能的改进方案整理好交给你你决定要不要合并。这套模式我用了很长时间非常稳。每次更新Skill之前我会让大模型输出三个候选版本分别说明它们的改动点和预计收益。我挑一个或者综合一下再放到测试集上跑一遍确认没有退化才合并。整个过程里AI做了90%的体力活但它无法独立完成剩下的10%——因为它缺乏对业务目标本身的判断力。Skill优化的终点是业务结果而业务结果往往不在模型可感知的范围内。还有一个非常现实的问题完全自主进化意味着每次迭代都要调用大模型来改写Skill这个成本并不低。受控进化至少能保证每一轮改写都物有所值——至少是朝着人认可的方向在改。4.3 从“自动挖掘漏洞”到“数学建模”不同领域的自进化尝试热词里还有“测试用例skill”“数学建模skill”“国赛skill”这些其实说明了一个趋势Skill已经被各领域玩家当成“经验资产”来经营。高手写一套测试用例Skill新手直接下载使用再结合自己的轨迹做本地优化这就形成了一种社区化的“技能进化”。以“ai自动挖掘漏洞skill”为例这类Skill的自进化潜力很大因为漏洞挖掘有明确的正反馈信号——挖到真漏洞就是成功。这种强反馈场景最适合自动化优化。反观写作类Skill什么叫“好”就很主观自动化优化就难很多。所以我的判断是Skill能不能自我进化不取决于模型多聪明而取决于这个领域有没有清晰可量化的“成功信号”。有信号进化就发生没有信号所谓的进化只是换个说法罢了。5. 实操从0到1做一个能自进化的Skill5.1 第一步选定场景定好评估指标我拿“代码评审Skill”举例因为代码评审这个场景有天然的客观信号评审意见能不能发现真实问题。你不需要事先有完美答案只要有一批历史代码变更记录其中标注了哪些评论是有效的。评估指标建议用两个发现率评审中发现的真实缺陷占人工确认缺陷的比例和误报率评审意见中无关紧要或错误的占比。没有这两个指标后面的自动化优化就是无源之水。5.2 第二步用轨迹收集素材让Agent处理5到10个历史代码变更每次处理都开启轨迹记录。收集完成后你会得到一批原始轨迹。这里有个小技巧不要只收集成功的轨迹。失败案例同样重要。成功的轨迹告诉你“怎么做是对的”失败的轨迹告诉你“什么不能做”。我在归纳时会刻意把失败轨迹里的错误操作整理成约束条款放进Skill的constraints里效果比正面示例还好。5.3 第三步归纳初版Skill按之前说的四步法——收集、对齐、去噪、结构化。初版Skill我建议从简开始先保证主干流程正确不追求面面俱到。初版越简单后续优化空间越大。写完后简单跑两三个测试用例确认能跑通就可以进入迭代循环。这一步最忌讳的是“一开始就追求完美”。我见过有人花了一整天把Skill写得事无巨细结果测试时发现核心流程反而是错的全部推倒重来。先跑通再优化成本最低。5.4 第四步构建反馈闭环在Skill里加一个“执行后复盘”的步骤要求Agent每次执行完输出一份复盘记录内容包括本次评审覆盖了哪些文件、哪些评论是模型自己确认有价值的、有没有发现明显遗漏。把几十次复盘记录定期汇总让大模型基于这些记录生成Skill的改进版本再回填。这里要注意复盘记录本身也占token所以在设计Skill时要让它输出极简格式比如一行一个要点否则一轮优化下来成本会有点高。我一般把复盘输出控制在三行以内只保留“做得好的地方”“卡壳的地方”“建议改动”三个字段。5.5 第五步工具链与团队协作如果你和我一样在团队里用强烈建议把Skill纳入版本管理。一个Skill目录建议这样组织skills/code_review/ ├── SKILL.md # 主文件 ├── examples/ # 示例集 ├── feedbacks/ # 复盘记录 └── tests/ # 测试用例纳入Git管理后Skill的每一次变更都可追溯出了回归一查就清楚。团队协作时经验丰富的工程师负责“格式化和去噪”新人负责“跑测试集和提疑问”这样的分工能让Skill的进化速度明显加快。我见过不少团队把Skill当“私有文档”各自维护最后版本冲突得一塌糊涂所以版本管理这件事越早做越好。6. 常见问题与避坑指南6.1 Skill唤不醒问题八成在描述这是我最常遇到的问题。Skill文件写了一大堆结果AI就是不用它。排查思路很简单描述里有没有明确的触发词以及有没有反例。描述里写“当用户提到日志、报错、异常时使用”比写“这是一个强大的日志分析工具”有效得多。后一种写法在大模型眼里没有任何触发线索。6.2 Skill太多互相干扰Skill墙Skill Wall是真实存在的。我在一个Agent里挂了十几个Skill之后发现模型的响应质量不升反降。原因很简单上下文里塞了太多不相关的Skill定义等于给模型制造了大量干扰信息。解决办法是分层把高频Skill放在默认加载层低频Skill改成“按需加载”。描述写得精准让模型只在匹配时才读入对应文件能大幅缓解干扰问题。另外Skill的命名也要避免重叠两个Skill描述里频繁出现同一个触发词模型很容易选错。6.3 自动归纳的Skill太啰嗦很多自动生成的Skill继承了轨迹里的全部细节动辄几十个步骤这种Skill基本没法用。我处理的办法是“三步简化法”第一步删掉所有“如果失败就重试”之类的兜底句第二步把同类步骤合并成一步第三步把超过三行长的步骤全部改写。简化完如果步骤数还超过十个我就考虑拆分成两个Skill而不是硬塞一个。6.4 省token的Skill到底怎么省热词里“codex省token的skill”是个高频需求其实省token的诀窍就四个字删、压、换。删掉不触发行为的废话把长示例换成最短的典型代表把重复性表述换成表格或结构化描述。另外要控制复盘类输出的长度一段复盘记录控制在三行以内几十次下来就是不小的节省。6.5 常见问题速查表症状可能原因处理建议Skill唤不醒描述缺少触发词、无反例重写描述加入场景词与禁用场景执行到一半中断步骤粒度过大拆步骤补分支条件多个Skill冲突触发词重叠调整描述降频Skill改按需加载结果不稳定示例太少或太偏补2-3个差异化正例自动归纳太啰嗦噪声未被剔除手动去噪删无效兜底句更新后效果变差缺少测试集验证建立回归测试用数据判断最后再分享一个真实体会。Skill这个东西本质上是在和AI的“健忘”对抗。模型本身不记得上周你在某个项目里踩过的坑但Skill可以替它记住。而且我越来越确认一件事设计Skill时把“怎么做”写清楚很重要把“为什么这么做”写进去更重要。因为AI在遇到边界情况时只有理解了目的才能做出超出Skill文本本身的正确判断。这是我从“轨迹归纳”到“文本空间优化”这条进化之路上踩过很多坑之后最想跟大家说的一点。
前的五级穿透法)
