1. 为什么装了一堆Skill反而让AI变笨了先说一个我观察到的现象。过去大半年Skill这个词在AI圈子里被反复提起从Claude Code到Codex从Agent框架到各种插件市场几乎每个平台都在推自己的Skill体系。很多人第一反应是多多益善看到别人分享的Skill就装装完发现AI不但没变聪明反而开始胡言乱语、答非所问、动不动就触发一堆莫名其妙的工具调用。问题出在哪出在大多数人把Skill当成了功能插件来理解而它本质上更接近给AI写的一份岗位说明书。你给一个员工塞十份互相冲突的岗位说明书他当然会精神分裂。我自己踩过这个坑。早期给一个代码助手装了七八个Skill结果它每次回答前都要纠结用哪个最后干脆把所有Skill的格式混在一起输出代码块里夹着文档模板文档里又混着命令行。后来我把Skill砍到三个效果立刻回来了。所以这篇内容不是给你列十个下载即用的Skill清单那种东西你搜一下到处都是。我想聊的是什么样的Skill真正值得装、它们各自解决什么问题、以及怎么组合起来让AI的能力产生质变。这十个方向是我从实际项目里筛出来的覆盖了从代码生成、文档处理、数学建模到Agent编排的核心场景每一个我都会讲清楚它背后的机制和适用边界。如果你刚开始接触Skill这个概念可以把它理解成预置的专家人格工具权限输出规范的三合一封装。装对了AI从通才变成专才装错了AI从专才变成话痨。2. 先搞清楚Skill和Agent到底差在哪2.1 一个容易被混淆的边界热搜词里skill和agent的区别出现频率很高说明这不是我一个人困惑过的问题。我用一个类比说清楚Agent是项目经理Skill是岗位手册。Agent负责的是这件事该不该做、分几步做、做完怎么验收它管的是流程和决策。Skill负责的是这一步具体怎么做、用什么工具、输出成什么格式它管的是执行标准和知识注入。举个具体例子。你让AI帮你写一份专利交底书。Agent层面它会规划先检索相关技术背景再梳理创新点然后按交底书模板组织内容最后做格式校验。而Skill层面它提供的是专利交底书应该包含哪些章节、每个章节的写作规范是什么、技术术语怎么表述才准确这些具体知识。很多人把Skill写成了Agent在Skill里塞了一堆条件判断和流程控制结果就是AI每次调用都要跑一遍完整逻辑又慢又容易出错。正确的做法是Skill只负责知识格式工具绑定流程交给Agent或者直接交给模型自己判断。2.2 什么时候该用Skill什么时候不该用不是所有需求都适合封装成Skill。我总结了一个简单的判断标准场景特征适合Skill不适合Skill知识密度需要注入特定领域知识通用常识即可完成输出格式有严格的格式要求自由文本即可复用频率高频重复使用一次性任务工具依赖需要绑定特定工具链纯对话即可错误成本出错代价高需要规范约束出错可接受比如帮我写个周报这种任务如果你每周都要写、格式固定、需要读取特定数据源那就值得做成Skill。如果只是偶尔写一次直接对话就行封装反而增加维护成本。2.3 Skill的加载机制决定了它的能力上限这里要讲一个很多人忽略的技术细节。Skill在大多数框架里的加载方式是按需注入——模型先看到Skill的名称和简短描述判断是否需要调用需要时才把完整内容加载进上下文。这意味着两件事第一Skill的描述写得清不清楚直接决定了模型会不会在正确的时机调用它第二Skill的内容不能太长否则会挤占宝贵的上下文窗口。我见过有人写了一个三千字的Skill结果模型每次加载完就剩不下多少空间处理实际问题了。好的Skill应该像一份精炼的SOP核心信息密度高废话少该用表格用表格该用列表用列表。3. 代码类Skill从能写到写得对3.1 代码规范Skill让AI写出团队能接受的代码这是我认为最值得优先配置的一类Skill。原因很简单AI写代码的能力已经很强了但它写出来的代码往往能跑但不像人写的——命名风格混乱、缺少必要的注释、错误处理敷衍、不符合团队的lint规则。代码规范Skill的核心不是教AI怎么编程而是告诉它我们这个团队的代码长什么样。具体要包含这几块内容命名约定变量用驼峰还是下划线常量全大写还是帕斯卡布尔值是否加is前缀注释规范什么情况下必须写注释注释用什么语言函数头注释的格式错误处理异常怎么抛、怎么捕获、日志怎么打目录结构新文件放哪个目录模块怎么划分依赖管理什么情况允许引入新依赖版本怎么锁定我自己的做法是把团队的ESLint配置和几个典型文件的片段直接塞进Skill里让AI照着模仿。实测下来代码review的返工率能降一半以上。注意Skill里不要写请写出高质量的代码这种空话模型对高质量的理解和你不一样。要给具体的、可验证的规则。3.2 调试排查Skill把排错经验固化下来这个Skill的价值在于把老手排查问题的思路变成可复用的流程。AI面对报错时默认行为是猜原因然后给一堆可能的修复方案但老手的做法是先定位再修复。一个调试Skill应该包含信息收集清单遇到报错先问哪些信息完整堆栈、复现步骤、环境版本、最近改动二分定位法怎么通过注释代码、加日志、缩小范围来定位问题常见错误模式库这类项目里最常见的十种错误及对应症状验证修复的步骤改完之后怎么确认真的修好了而不是碰巧不报了我特别想强调第四点。很多人改bug改到不报错了就收工结果过两天换个场景又炸了。Skill里应该强制要求修复后必须构造一个能复现原问题的测试用例这个习惯能省掉大量返工。3.3 代码审查Skill让AI当你的第一道reviewer代码审查Skill和代码规范Skill的区别在于规范Skill管的是写的时候审查Skill管的是写完之后。它要做的是模拟一个有经验的reviewer从几个维度检查代码正确性逻辑有没有漏洞边界条件处理了没有安全性有没有注入风险、敏感信息泄露、权限校验缺失性能有没有明显的性能陷阱比如循环里查数据库可维护性耦合度高不高以后改起来方不方便测试覆盖关键路径有没有测试这里有个实操技巧审查Skill的输出格式最好固定成问题等级位置原因建议修改这样你可以直接把它当checklist用。我一般会要求它把问题分成必须改和建议改两档避免被一堆鸡毛蒜皮的风格问题淹没。4. 文档与知识类Skill把散落的信息变成结构化输出4.1 技术文档Skill从代码到文档的自动转化写文档是大多数开发者的痛点但AI做这件事其实很有优势——它读得懂代码也能组织语言。问题在于如果不加约束AI写出来的文档要么太啰嗦要么漏掉关键信息。技术文档Skill要解决的核心问题是文档的读者是谁、他们需要什么。我通常会在Skill里定义几种文档类型每种对应不同的模板API文档接口说明、参数表、返回值、错误码、调用示例架构文档模块划分、数据流、关键设计决策及理由部署文档环境要求、步骤、配置项、常见问题变更日志版本号、变更类型、影响范围、迁移指南每种模板我都规定了必填项和选填项。比如API文档里错误码是必填的因为调用方最需要知道出错时怎么办。这个约束能逼着AI去代码里找全信息而不是含糊带过。4.2 知识库整理Skill把碎片信息变成可检索的结构这个Skill适合处理那种一堆零散笔记、聊天记录、邮件的场景。核心能力是提取、归类、建立关联。具体做法是让AI按实体-关系-属性的方式整理信息。比如你有一堆项目会议记录Skill会帮你提取出涉及哪些人、哪些任务、每个任务的负责人和截止时间、任务之间的依赖关系。整理完输出成结构化的表格或者可以直接导入知识库的格式。我实测过一个场景把半年的项目群聊记录丢进去让它整理出所有待办事项和决策记录。效果比人工翻聊天记录快太多了而且不会漏。关键是Skill里要明确定义什么算待办事项——有明确动作、有负责人、有时间的才算模糊的讨论不算。4.3 专利辅助Skill技术交底书的规范化写作热搜词里出现了专利相关辅助链接 ai辅助说明这个需求是真实存在的。专利交底书有非常固定的格式要求而且对技术描述的准确性要求极高这正是Skill能发挥价值的地方。一个专利辅助Skill应该包含技术背景的写法现有技术怎么描述、存在什么问题、为什么需要改进发明内容的写法技术方案要分层次描述核心创新点要突出实施例的写法至少一个完整实施例参数要具体步骤要可复现权利要求的草拟思路独立权利要求和从属权利要求的层次关系附图说明的规范每张图说明什么标号怎么对应注意Skill只能辅助整理和规范化不能替代专业的专利代理人。技术方案的新颖性和创造性判断必须由人来把关。我自己的经验是用Skill先把技术方案的结构理清楚把该填的信息填全然后再交给代理人沟通效率能提高不少。代理人最怕的就是交底书里缺关键信息来回问好几轮。5. 数学建模与数据分析类Skill让AI算得准、说得清5.1 数学建模Skill从问题到模型的完整链路数学建模是个典型的需要知识流程工具三合一的场景。热搜词里有数学建模skill说明不少人在做竞赛或者实际项目时需要这个。一个完整的数学建模Skill应该覆盖这几个阶段问题分析阶段怎么从一段文字描述里提取出变量、约束、目标。这里要教AI识别优化问题预测问题评价问题等不同类型因为不同类型的建模套路完全不同。模型选择阶段给定问题类型有哪些经典模型可选各自的适用条件和优缺点是什么。比如预测问题时间序列、回归、神经网络各适合什么数据特征。求解阶段用什么工具求解Python的scipy、sklearn还是自己写算法。参数怎么调结果怎么验证。论文写作阶段摘要怎么写、模型假设怎么列、符号说明怎么组织、灵敏度分析怎么做。我特别想说的是模型假设这一块。很多建模失败不是因为模型不好而是假设不合理或者没写清楚。Skill里应该强制要求列出所有假设并说明每个假设的合理性依据。5.2 数据分析Skill从原始数据到可执行结论数据分析Skill和数学建模Skill的区别在于建模偏向构建一个能解释或预测的模型分析偏向从数据里挖出对决策有用的信息。这个Skill的核心是规范分析流程数据理解字段含义、数据类型、取值范围、缺失情况数据清洗异常值处理、缺失值填充、重复值去重每一步都要记录理由探索性分析分布、相关性、趋势、分组对比统计检验需要验证什么假设用什么检验方法显著性水平怎么定结论输出每个结论都要有数据支撑区分相关和因果实操中最容易出问题的是第三步和第五步。探索性分析容易变成画一堆图但看不出重点结论输出容易变成数据是这样所以应该是那样的跳跃式推理。Skill里要明确要求每个图表必须配一句话说明它验证了什么每个结论必须标注置信程度。6. Agent编排类Skill让多个AI协同工作6.1 任务分解Skill把大目标拆成可执行的小步骤这是Agent场景下最核心的Skill。一个复杂任务丢给AI它默认会试图一步到位结果往往是中间步骤出错导致全盘皆输。任务分解Skill的作用是强制它先规划再执行。好的任务分解要满足几个条件每个子任务有明确的输入和输出不能是处理数据这种模糊描述要是读取csv文件输出清洗后的dataframe子任务之间有清晰的依赖关系哪些可以并行哪些必须串行每个子任务有验收标准怎么判断这一步做完了、做对了有失败回退方案某一步失败了怎么办是重试、跳过还是终止我在实际项目里会把任务分解Skill和执行日志绑定。每完成一个子任务就记录一条日志包括做了什么、结果是什么、耗时多少。这样出问题时能快速定位是哪一步出的错。6.2 工具调用Skill让AI知道什么时候该用什么工具Agent的能力边界很大程度上取决于它能调用哪些工具以及它知不知道什么时候该调用。工具调用Skill要解决的就是选择问题。我通常会在Skill里维护一张工具清单每个工具标注工具适用场景输入要求输出格式注意事项搜索需要外部信息查询词摘要链接结果需交叉验证代码执行需要计算或数据处理可运行代码执行结果注意超时和资源限制文件读写需要持久化数据路径内容操作结果注意权限和路径安全API调用需要外部服务请求参数响应数据注意频率限制和错误处理关键是注意事项这一列。很多工具调用失败不是因为不会用而是因为忽略了边界条件。比如代码执行工具如果不限制执行时间一个死循环就能把整个Agent卡死。6.3 结果验证Skill让AI学会自己检查作业这是最容易被忽略但价值最高的Skill。Agent执行完任务后默认行为是直接输出结果但结果对不对它自己也不知道。结果验证Skill的作用是让它在输出前先自查一遍。验证的维度包括完整性要求的所有部分都覆盖了吗一致性前后有没有矛盾数据对不对得上合理性结果在常识范围内吗有没有明显异常可复现性换个人按这个步骤能得出同样结果吗我一般会要求验证Skill输出一个自检报告列出检查了哪些项、每项的结果是什么、有没有存疑的地方。这个报告不一定要给最终用户看但能大幅降低低级错误流出的概率。7. 十个Skill的组合策略与加载顺序7.1 不是装得越多越好回到开头的问题。十个Skill不是让你全装上而是给你一个能力池根据具体场景选用。我自己的配置是分层的基础层常驻代码规范、任务分解、结果验证。这三个几乎任何场景都用得上而且互相不冲突。场景层按需加载调试排查、代码审查、技术文档、数据分析。做对应任务时才启用。专用层特定项目数学建模、专利辅助、知识库整理、工具调用。只在特定项目里配置。这样分层的好处是上下文占用可控模型不会因为Skill太多而选择困难。7.2 加载顺序会影响效果Skill的加载顺序不是随意的。我的经验是先加载约束类Skill规范、验证让模型先知道边界在哪再加载知识类Skill领域知识、模板给它填充内容最后加载工具类Skill工具调用、执行告诉它能用什么手段这个顺序符合先定规矩、再给知识、最后给工具的逻辑模型执行起来更顺畅。反过来先给工具再给约束模型容易先动手再发现违规返工率高。7.3 冲突处理当两个Skill打架时Skill之间冲突是常见问题。比如代码规范Skill要求函数不超过50行但某个领域Skill要求所有逻辑写在一个函数里方便复制。这种冲突如果不处理模型会随机选一个执行结果不可预测。处理原则是约束类Skill优先级高于知识类Skill。因为约束类通常代表硬性要求团队规范、安全红线知识类代表软性建议。在Skill描述里可以显式标注优先级或者在系统提示里说明冲突时的取舍规则。8. 实测中踩过的坑和对应的解法8.1 Skill描述写得太泛模型不知道什么时候用我最早写的一个Skill描述是帮助处理文档相关任务。结果模型几乎从不主动调用它因为文档相关太模糊了模型判断不了当前任务算不算。后来改成当用户要求生成API文档、架构文档、部署文档或变更日志时使用输入为代码文件或模块说明输出为对应格式的Markdown文档。调用率立刻上来了。教训Skill描述要写清楚触发条件输入输出越具体越好。8.2 Skill内容太长挤爆上下文前面提过有人写了三千字的Skill。我自己的上限是控制在800字以内超过就拆成多个Skill或者精简内容。精简的方法把解释性文字删掉只留规则和示例。比如不要写命名规范很重要因为好的命名能提高可读性直接写变量用驼峰常量用全大写布尔值加is前缀。8.3 Skill之间输出格式不统一这个问题在多Skill协同时特别明显。代码规范Skill输出的代码块用python标注文档Skill输出的代码块用不加语言结果拼在一起格式乱七八糟。解法是在基础层加一个格式统一Skill规定所有代码块必须标注语言、所有表格必须有表头、所有列表必须用短横线。这个Skill不干别的就管格式。8.4 模型绕过Skill直接回答有时候模型会忽略Skill的存在按自己的默认方式回答。原因通常是Skill的约束和模型的默认行为冲突模型选择了更省事的路径。解法有两个一是在系统提示里强调必须遵循已加载的Skill二是把Skill的关键约束写进系统提示本身双保险。我一般两个都用。9. 怎么判断一个Skill值不值得装最后分享一套我自己的评估标准帮你从一堆Skill里筛出真正有用的第一看它解决的是不是高频问题。一周用不到一次的Skill维护成本大于收益。第二看它的约束是不是可验证的。写出优雅的代码不可验证函数不超过50行可验证。可验证的约束才能真正生效。第三看它有没有明确的适用边界。好的Skill会告诉你什么情况下不要用我这比告诉你什么情况下用我更重要。第四看它的输出能不能直接进入下一步。如果Skill的输出还需要大量人工整理才能用那它的价值就打了折扣。第五看它和现有Skill冲不冲突。装之前先想想它和已经装了的Skill有没有矛盾的地方。按这五条筛下来市面上大部分Skill其实都不值得装。但剩下那少数几个确实能让AI的能力上一个台阶。我目前常驻的Skill只有四个但覆盖了我80%的使用场景这比装四十个用不上的强得多。如果你刚开始配Skill建议从代码规范和结果验证这两个入手它们最通用、最容易看到效果。等用顺了再按需扩展。别一上来就追求大而全那是给自己找麻烦。