我一直觉得，AI 用得顺不顺手，差距往往不在模型本身，而在你会不会给模型“配技能”。
现在大家都在聊 skills（技能），这个从 AI Agent 生态里火起来的概念，说白了就是把模型会做的事提前结构化，让它按固定流程、固定参数去执行，不再每次对话都从零摸索。我花了不少时间把日常重复的活儿整理成一个个 skill，实测下来，效果比想象中明显：原来要反复提示七八轮的事，现在一句话就能触发完成。
这篇文章就聊聊我拆解 skills 的完整思路，包括技能文件怎么设计、参数怎么定、踩过哪些坑，以及怎么把零散技能整理成一套可复用的个人技能库。适合刚接触 Agent/Skill 机制、或者已经被各种自定义指令折腾得够呛的朋友参考。
1. 先搞明白：skills 到底是什么
很多人一听 skills，第一反应是“这不就是提示词模板吗”。说实话，这两者确实有关系，但完全不是一回事。
1.1 从提示词到技能：本质区别在哪
提示词模板解决的是“这次对话怎么说更清楚”，核心作用是把你的需求翻译成模型容易理解的语言，用完即走，没有状态，也没有稳定的执行边界。而 skills 本质上是一套可复用的执行单元，它不只是告诉模型“你要做什么”，还规定了“要做到什么标准”“按什么顺序做”“输入输出长什么样”。
我自己的理解是：提示词是给模型的一封信，skills 是给模型的一本岗位手册。信写得再详细，模型也只能看完就忘；但岗位手册不一样，它可以被随时翻出来，按里面的职位说明、工作流程、交付标准去执行任务。
举个实际例子。我早期写周报，每次都把上一条提示词复制过来，改填充内容。后来改成 skill 形式之后，只需要告诉它“这周做了123”，它会自动按照技能定义好的结构化模板输出：本周完成项、数据变化、风险点、下周计划。关键触动点是：同一个 skill 可以被反复调用，而且每次输出格式都稳定，不需要我再做二次整理。
1.2 技能系统解决了什么痛点
我总结下来，skills 解决的核心痛点有三个：
第一个是上下文浪费。传统的长对话里，模型要不停从历史消息里找线索，上下文一长，前面的关键信息被稀释，输出质量断崖式下跌。技能模块把核心规则固化成独立文件，模型按需加载，不再把大量 token 花在重复理解指令上。
第二个是输出不稳定。同一个需求，换个说法去问模型，结果天差地别。技能把输入参数和执行步骤都定死，模型从“自由发挥”变成“按规程办事”，输出稳定性显著提升。
第三个是流程不可复用。用提示词，这次搞完下次要重新组织语言；用技能，这次调试好了，下次直接调用，还可以分享给别人。这一点对我来说吸引力最大，我花一次时间打磨技能，后面每次使用都在吃复利。
1.3 技能文件的基础结构
一个标准的 skill，通常由两部分构成：一个是描述文件，记录技能的名称、功能描述、适用场景；另一个是执行步骤文件，详细定义任务的流程和规范。
这个结构很关键。描述文件帮模型判断“什么时候该调用这个技能”，执行文件告诉模型“调用了之后具体怎么做”。就像你招了一个实习生，先给他看岗位介绍让他知道什么时候该做什么，再给他看 SOP 手册让他知道每一步怎么落地。
2. 核心细节拆解：怎么写一份能用的技能规范
很多人自己动手写 skill 时最容易犯的一个错误，就是把它当成写作文，恨不得把所有可能性都写进去。实际上，好的技能规范恰恰是克制的。
2.1 描述信息的设计原则
描述信息决定了模型能不能正确触发这个技能，写得好不好用了之后感受特别明显。我认为描述信息必须包含三个要素：这个技能是做什么的、什么时候该用、绝对不要什么时候用。
举个例子。我写了一个“周报生成”技能，它的描述信息是：生成结构化中英文周报，适合每周五或项目节点后使用，不适合用于日报或项目复盘。后一句“不适合”看起来多余，但实际帮助很大。我发现加上边界条件之后，模型触发错误的概率降低了非常多。
另外，建议把触发场景写成具体的行为描述，而不是抽象的功能描述。比如“当用户提供本周任务清单或项目进度更新时”这种，就比“用于周报”要准确得多。模型匹配触发条件的时候，具体场景比抽象短语更可靠。
2.2 执行步骤怎么写才不会被误解
执行步骤是技能的核心，它直接决定了模型输出的质量。我自己的经验是，步骤要满足三条标准：有明确顺序、有检查条件、有输出模板。
先说顺序。模型执行复杂任务时，如果步骤没有强顺序，很容易跳步或者重复。我在技能里会给每个步骤编号，并且明确写清楚“先做什么，完成之后才做什么”。
再说检查条件。每一步做完之后，最好有一个自检环节。比如“生成初稿后，检查是否包含全部输入要点，缺失则补充”。这一步实际上是双保险，模型即使中间跑偏了，自检也能拉回来。
最后是输出模板。我可以接受模型在中间过程里自由发挥，但在最终交付物上，必须有稳定模板。模板里预留变量位，模型只需要填内容，结构不用变。这样输出的东西，可以直接拿去用，不需要我再排版。
2.3 参数与变量的坑
技能里经常要定义参数，比如输入内容、目标受众、语气风格。这里的坑在于：模型对参数的处理能力，比我们想象中弱很多。
我第一次写技能的时候，一口气定义了七八个参数，结果模型经常漏填或者乱填。后来我学聪明了，能不定义参数就不定义，把非核心参数全部降级成“可选补充说明”。核心参数最多留两到三个，这样模型的记忆负担小很多，执行成功率明显上升。
还有一个小技巧：参数名要起得足够直观。不要叫“input_data”这种，要叫“本周任务列表”或者“用户提供的原始材料”。模型在阅读自然语言时，对形象化命名比抽象命名敏感得多。这一点测试的时候体会特别深。
3. 实操过程：从零构建一个可用技能
理论讲一堆，不如实操一遍有用。下面我用一个“竞品信息整理”技能作为例子，把完整流程走一遍。
3.1 场景选择与目标拆解
先说为什么选这个场景。竞品信息整理是我日常做得最多、也最重复的事：拿到一堆链接或者截图，需要提取功能点、定价、更新动态，最后汇总成一张对比表。这种任务重复度高、流程固定、输出格式明确，非常适合技能化。
目标拆解之后，我把任务切成了三步：
- 从用户提供的材料中提取竞品名称和核心功能点
- 查询并整理价格与版本信息
- 按照固定模板输出对比表
三步之间是严格顺序关系，不存在并行可能，所以整体流程设计比较简单。如果是更复杂的任务，我一般会先把任务画成流程草稿，标清楚哪些是顺序、哪些是分支，再动手写。
3.2 技能文件的完整示例
这个技能我给它取名“竞品扫描”，描述文件里写着：当用户提供竞品名称、链接或宣传物料时，自动提取关键信息并生成对比表；不适用于市场趋势分析或用户调研采集。
执行步骤的核心部分结构大致如下：
- 步骤一：读取用户输入材料，提取所有竞品名称与一句话简介。
- 步骤二：逐条识别功能特征，标注免费、付费或限制项。
- 步骤三：整理定价，按工具、版本、价格三列呈现。
- 步骤四：生成 Markdown 表格，包含竞品名称、核心功能、定价、更新时间四列。
- 步骤五：输出前自检，确认每条竞品都有对应信息，缺失处标注“待补充”。
这里我特别强调一下步骤五的自检。不加自检之前，模型经常漏掉一两个竞品信息，输出表格里出现空白单元格；加上自检之后，漏项情况少了非常多。这个改动成本特别低，收益却很明显。
3.3 测试与调优记录
技能写完之后，一定要做三类测试：正常输入测试、边界输入测试、干扰输入测试。
正常输入测试是看整个技能能不能跑通；边界输入是看输入内容特别少或特别多时有没有异常；干扰输入是看信息里夹带无关内容时，模型会不会受影响。我第一次测试就发现问题：用户材料里附带了一大段新闻报道，模型把新闻内容也当成了竞品信息提取进去。
解决办法是在执行步骤里加了一句话：“只提取与竞品直接相关的产品功能与价格信息，忽略新闻、评论和个人观点”。加上这句话之后，干扰问题明显改善。这个经历让我养成了一个习惯：技能里必须写清“忽略什么”，这比“提取什么”更重要。
4. 常见问题与排查技巧实录
技能跑起来之后，我遇到的问题和坑，远比想象中多。这里按出现频率整理一份速查表，给需要的人参考。
4.1 触发失败：技能完全不起作用
技能不被触发，是最常见的问题。原因通常是描述信息写得过于宽泛，模型不知道该不该调用。我遇到过最夸张的一次，是因为描述信息里没有写明“当用户提到某关键词时使用”，导致模型完全无视技能，走了默认对话模式。
解决办法是回看描述信息，尽量写清楚触发条件和边界。还可以在测试时用不同的说法反复触发，看看模型到底在哪些表述下才会调用技能。这本质上是个匹配率问题，可以多试几种触发话术。
4.2 输出格式漂移：每次结果都不一样
明明同一个技能，这次输出的格式和上次不一样，这种问题也遇到过不少。主要原因往往出现在输入内容对格式的干扰上。比如用户输入里带了一个项目符号列表，模型就跟着学了那种格式。
应对方式是在技能里写死“必须输出一个 Markdown 表格，且表头固定为特定列名”。把格式约束放到最高优先级，模型就没那么多自由发挥空间了。如果还是漂移，就升级做法：在输出模板里直接把空表格结构写出来，让模型只填内容。
4.3 参数过载：模型漏掉关键参数
这个问题我在设计技能阶段就踩过。技能里参数定义太多，模型记不全，执行的时候漏参数。解决思路有两个方向。
第一个方向是强制前置：把参数收集放在执行步骤的第一步，先让模型确认所有参数收集完毕，再进入主流程。这样可以尽早暴露漏参问题。第二个方向是减参数：把不关键的参数全部从正式参数表里拿掉，改成“可选补充说明”放进步骤描述里。参数少了，模型的执行成功率立竿见影。
4.4 技能冲突：多个技能抢同一个场景
技能库稍微大一点之后，会碰到多个技能描述相似、模型不知道该调哪个的情况。我早期有“竞品扫描”和“市场信息整理”两个技能，描述信息高度重叠，模型经常随机触发。
解决思路是给技能划分清晰的领域边界，并在每个描述信息里写明“不要用于XX场景”。如果两个技能确实相似，那就合并成一个，用参数来控制不同模式。技能库讲究的是少而精，不是大而全。
5. 个人技能库的整理与扩展思路
技能数量多起来之后，管理成本会快速上升。我现在的做法是把技能按用途分成几类：信息整理类、写作类、数据分析类、流程编排类。每个技能都有自己的边界，不跨类使用。
5.1 技能库日常维护的三个习惯
第一个习惯是不断迭代：每次用技能遇到问题时，顺手在文件里补一条注意事项。技能是养出来的，不是一次写出来的。
第二个习惯是定期清理：每个月检查一次技能列表，删掉三个月没用过的技能。不用的技能没价值，反而会干扰模型在相似场景下做判断。
第三个习惯是版本意识：每改一版技能，备注一下改动时间。下次觉得“之前那版好像更好”的时候，能快速回退。
5.2 从单技能走向协同
当技能用熟了之后，可以试试技能之间的组合。比如“竞品扫描”输出对比表，“汇报生成”消费对比表，两者一结合，就变成了一条自动化的竞品调研流水线。
这个组合思路是我后期用得最多的地方。单个技能解决单点问题，组合技能解决流程问题。每天省下来的时间，攒在一起非常可观。
6. 最后说几点实在话
文章写到这里，该讲的都讲得差不多了，最后分享几个我自己的心得。
第一，不要一开始就追求完美技能。你先写一个粗糙版本用起来，然后在使用中不断迭代，比花一周时间憋一个“完美”技能更靠谱。
第二，好技能的标准不是“内容多”，而是“边界清楚、步骤清楚、模板清楚”。我见过最实用的技能，全文不到两百行，但每一个字都在点上。
第三，技能库会越用越顺手，也会越用越“私有化”。因为你对技能的修改越符合自己的工作习惯，别人拿去就越不一定适配。所以不用纠结于跟别人一模一样，适合自己的就是好技能。
我后来回忆这段折腾 skills 的过程，最终发现收益最大的不是我写好了多少个技能，而是我在不断拆解和定义技能的过程中，把自己手上重复的活儿都梳理清楚了。哪些流程可以标准化、哪些环节需要人为判断、哪些输出必须固定格式，这些认知本身就是效率提升的来源。哪怕你最后只用上了其中一两个技能，把工作拆解清楚这件事，也值得做。
