Agent Skills实战：从提示词工程到技能系统，重塑AI协作方式

过去大半年我几乎把所有重复性的AI协作流程都改造成了Skills。起因很朴素我再也受不了每次开新对话都要重新粘贴一大段提示词了。分镜要贴分镜规则写论文要贴论文规范做前端要贴组件约束——贴完还得担心模型有没有真正遵守。把流程打包成Skill之后模型在规划阶段就能发现“这里有现成的技能可用”然后自己完成装载、执行和迭代。这个转变最让我意外的不是省了多少时间而是Agent的行为方式真的不一样了它不再是一个每次都要从头教的实习生而是一个带着工具箱、知道自己该干什么的熟练工。这篇文章写给两类人一是被提示词工程搞得心力交瘁、想寻找更结构化方案的人二是已经在用Claude或Codex但还没碰过Skills、想了解它到底解决了什么的人。我不打算泛泛讲概念而是从第一性原理拆一下Skills在系统里到底做了什么再拿我实测的Claude、Codex和开源社区方案做个横评最后手把手带你把一个可用的分镜Skill从零搭出来。全程都是真实操作踩过的坑也会讲清楚。1. 一个看似轻量的功能为什么能改变Agent的使用方式1.1 从“复制提示词”到“技能装载”的范式变化先说说我之前的工作流有多蠢。做动漫分镜的时候我有大概两千字的分镜规范包含景别定义、运镜规则、台词格式、情绪标注方式。每次开新对话第一件事就是把规范贴进去然后再贴小说原文再补一句“按上述规范输出分镜”。这中间有大量的重复劳动更麻烦的是模型经常“贴完就忘”——对话一长它就开始自己发挥景别叫法混乱台词格式变形最后我还要人工改一遍。这个问题在写论文、做前端组件、做数据分析时一模一样。你每次都要重新解释背景、规则、输出格式而模型每次都是“第一次听说”。如果把这些东西固化成文件让模型在需要的时候自己去读、自己去遵守情况就完全不同了。Skills解决的就是这个它把规则、示例、工作流程打包成一个可命名的单元模型通过一段简短的描述就知道“这个技能是干什么的、什么时候该用”然后自动把对应的指令和资源加载进来。我用一个很糙的类比来理解它普通提示词是“你每次给临时工手写一份作业要求”Skills是“你给这个员工发了一本岗位手册他上岗前自己翻”。前者靠你重复劳动后者靠系统结构化。1.2 Skills不是插件也不是MCP它到底算什么很多人第一次接触Skills会陷入一个误区把它当成插件或者MCPModel Context Protocol的替代品。我一开始也这么想过后来实测下来发现根本不是一回事。我做了个简单的对比维度普通提示词SkillsMCP/插件持久性无每次粘贴有文件常驻有服务常驻触发方式人工指定模型自主发现模型/用户显式调用核心作用约束输出塑造行为模式扩展能力边界数据来源对话上下文本地文件指令外部服务/API依赖关系无无额外服务需要连接和鉴权这个表格想说明一件事MCP解决的是“Agent能碰到什么”Skills解决的是“Agent知道该怎么干”。前者是触手后者是大脑里的工作程序。两者可以配合比如Skill里可以规定“需要查天气时调用weather MCP工具”但就算没有MCP一个纯指令型Skill也完全能工作。想通这一点之后我对Skills的定位就清晰多了它是Agent行为塑造层的东西而不是工具集成层的东西。这个认知直接影响了我后面做Skill时的设计思路——我该重点打磨的是规则、流程和示例而不是纠结要不要给它挂个API。2. 第一性原理拆解Agent Skills究竟在系统里做了什么2.1 声明式元数据驱动的能力发现机制Skills底层依赖一个很关键的设计Agent在规划阶段会扫描所有可用的Skill根据描述信息判断当前任务是否匹配。所以SKILL.md开头的YAML元数据name和description不是摆设它是整个技能发现机制的入口。我见过不少人写description写得特别随意比如“用于生成分镜脚本”。这句话对模型来说信息量是不够的。模型是在什么场景下会考虑用这个技能如果用户只是想简单描述一个画面该不该触发如果用户给了一整本小说该不该触发我在实测中总结出一个好的description应该包含触发场景、输入要求、输出承诺。比如--- name: storyboard-generator description: 当用户提供小说章节、剧本片段或叙事性文字并希望转换为分镜脚本时使用。输入需要包含场景发生的段落输出为结构化分镜表含景别、运镜、台词、情绪标注。 ---这样模型在读到用户消息时就能比较准确地判断“现在是不是该调用这个技能”。description写得太宽模型会在不该用的时候强行用写得太窄模型又会错过该用的时机。这个度需要反复测试我后面会详细讲。2.2 指令注入的深度模型是怎么被“改变”的当模型决定使用某个Skill时SKILL.md的正文部分会被注入到模型的上下文里。这个注入不是简单叠加一段用户消息而是作为一种类似系统指令的存在影响模型后续的推理和行为。这意味着Skill对你的整个工作流有持续的约束力而不是像普通提示词那样贴完就淹没在长对话里。我做了个小实验来验证这个差异同一个对话里我先用普通提示词定义了一种输出格式然后聊了十几轮无关话题最后再让它按那个格式输出——结果格式已经歪了。但我在Claude里装了一个Skill同样聊了十几轮再触发相关任务时模型输出的格式和规范依然稳定。原因就在于Skill的指令在上下文中的权重与普通用户消息不同它更像一层常驻的“职业素养”。这个特性非常实用尤其是做长流程任务时。比如用Codex写论文从摘要、引言到结论中间要经过很多轮对话如果靠普通提示词约束早就在某一步就跑偏了但打包成Skill后模型全程都记得“自己是按学术写作规范工作的”章节结构、引用格式、论证节奏都会保持一致。2.3 资源文件与few-shot示例让技能可复用SKILL.md解决的是“规则”问题但如果只有规则模型很多时候还是不知道“好”的标准是什么。这时候就需要资源文件。我习惯在Skill目录下放一个resources文件夹里面装模板、术语表、范例输出。模型在需要时会主动去读这些文件相当于给了它几个高质量的参考样本。这其实就是few-shot的思想只不过不再局限于对话上下文里塞几条示例而是以文件形式挂在技能背后。我做个分镜Skill时在里面放了一份完整的分镜表模板和一篇示例输出。实测效果非常明显没有示例时模型输出的分镜表虽然格式对但镜头之间的逻辑衔接很差有了示例后它学会了按“场景建立→人物动作→情绪特写→节奏切分”的顺序来组织镜头输出质量直接上了个台阶。2.4 从被动到主动Agent形态的关键变化前面说的都是技术机制这一节我想聊一个更抽象但很重要的变化Skill会让Agent从“被动响应”变成“主动提案”。以前用聊天式AI流程完全由用户主导你问一句它答一句。但当你装了一批设计良好的Skill后模型开始学会“抢活”了。比如我给它一段小说原文它会先判断这个场景需要什么风格的分镜然后主动说“检测到这是一段高情绪冲突场景建议使用storyboard-generator技能并突出节奏切分”。它不再只是回答你的问题而是像一个真正的工作伙伴在提方案。这个变化是怎么发生的我理解是Skill的description给了模型一个“能力清单”而长对话给了它上下文让它可以结合两者做规划。当模型发现自己手里的工具正好匹配用户需求时它就会进入“技能应用模式”。对于重度用户来说这个变化的意义很大你不需要再精确地发号施令只要给出原始材料Agent自己会知道该用哪把刀。3. 实测横评Claude、Codex与GitHub上开源方案的真实差异3.1 Claude官方市场与本地安装实测Claude的Skill生态是目前最成熟的官方市场里已经有不少经过验证的技能可以直接装。安装流程很顺在Agent配置界面进入技能市场找到合适的Skill一键安装然后就能在对话里触发。我装了官方推荐的数据分析类和文档处理类Skill体验还算稳定。不过我更推荐关心行为的工程师自己去写Skill而不是完全依赖市场。官方市场的Skill为了通用性通常会把规则写得比较宽泛。比如市场里某个分镜Skill它对景别的定义就是标准术语但如果你所在团队的规范里有一套自己约定俗成的叫法比如“大特写”和“微距镜头”的区别官方Skill就没法满足。这种时候自建Skill的成本很低收益反而更高。如果你用的是Claude官网或者桌面端本地安装Skill其实就是建一个文件夹的事在配置目录下新建一个以技能命名的文件夹里面放SKILL.md和resources然后在配置里声明这个技能目录的位置。我第一次建的时候还担心要做各种注册结果发现根本不需要——只要文件结构对了Agent会自动扫描到。3.2 Codex Skills工程化工作流的正确用法Codex的Skill机制和Claude类似但因为它更侧重代码场景我在里面跑的Skill主要以开发规范为主。我做了一个前端开发Skill里面规定了组件命名规则、样式方案、测试要求。以前我给Codex描述一个页面需求它写出来的代码风格和团队既有代码总有出入装上Skill之后它生成的组件从命名到目录结构都符合团队规范直接被代码审查放行的概率高了很多。写论文的Skill我也在Codex里试过。它的目录下放了一个academic_writing_guide.md内容包含论文结构、引用格式、论证逻辑检查清单。我最喜欢的一个细节是Skill里的资源文件会要求模型在生成每一章之后先自我检查一遍逻辑链再输出给用户。这个“在输出之前先反思”的步骤虽然看起来只是多了一道指令但对学术写作的提升是实打实的——至少模型不会再给我生成那种“火车跑着跑着突然拐进一条岔路”的论证了。Codex的Skills存放路径一般是在用户目录下的.codex/skills文件夹里每个技能一个子文件夹同样是SKILL.md加资源的组织方式。如果你之前配过Codex的AGENTS.md或者项目规则你会发现Skills其实就是一种更细粒度、可组合的“按需加载规则”两者搭配使用效果很好。3.3 GitHub生态从分镜到安全测试的典型样本GitHub和各类下载平台上已经冒出来大量成熟Skills我大致扫了一圈按使用热度排个序的话大概是开发效率类、内容创作类、数据分析类、安全测试类。其中分镜类Skills的火爆程度超乎我预期可能是最近动漫和短剧创作人群涌进来的原因。这些Skill的思路基本一致把分镜规则、景别定义、镜头语言术语打包让模型把文字内容自动拆解成可视化分镜。“自动挖洞”方向的Skill也很有代表性当然这里说的不是那种不分青红皂白乱扫的工具而是把漏洞挖掘流程规范化的技能。GitHub上有个项目把资产收集、指纹识别、漏洞验证这几个阶段用SKILL.md串联了起来模型会按阶段推进每个阶段结束还会输出一份结构化的测试报告。这种安全方向的Skill和普通业务Skill有个很大的不同它必须有严格的范围判定和授权校验逻辑否则模型容易在错误的场景下做出危险动作。我也会在下一节讲写这类Skill时安全边界要先写进SKILL.md的第一条规则。3.4 我实测下来踩过的几个Key坑第一坑是description写得太泛导致乱触发。我给某个通用写作Skill写的描述是“帮助用户写作”结果模型在用户要求列购物清单的时候都去调用它反而把输出格式搞复杂了。后来我把描述改成了“当用户需要撰写长文、需要结构化段落和连贯修辞时使用”误触发率明显下降。第二坑是Skill里塞了过多指令导致模型“精神分裂”。我一开始追求大而全把几十条规则都写进一份SKILL.md结果模型的输出变得僵硬每句话都像在照着规则念稿。后来我把指令精简到核心10条以内把细节放进resources里让模型按需阅读效果反而好了很多。核心逻辑是指令文件负责引导方向资源文件负责提供深度别把两者混在一起。第三坑是安装位置不对导致技能根本没被识别。Claude和Codex扫描的目录是固定的如果你把Skill文件夹放错地方它不会报错但你的Skill永远也不会被加载。遇到“装了但完全没效果”的情况第一件事不是检查内容而是检查目录路径。4. 手把手实现一个真正可用的Skill分镜生成全流程4.1 定义一个不宽不窄的Skill边界很多人第一次动手做Skill最容易犯的错误就是边界不对。我以分镜Skill为例讲讲怎么定义边界。你希望这个Skill处理什么样的输入是小说章节还是短视频脚本这两者的分镜逻辑完全不同——小说需要先做场景抽取和人物状态分析短视频脚本更多是逐镜头的文字转译。如果把两者混在一个Skill里模型会陷入“到底按哪套逻辑来”的纠结。我第一次做的时候就把两者混了结果模型生成的镜头序列很不稳定。正确的做法是先聚焦一个场景。我做的第一版只处理“小说章节转动漫分镜”输入是连续的叙事段落输出是带镜头编号、景别、运镜方式、角色动作、台词和情绪标注的分镜表。等这个版本跑稳了再扩展第二个场景。Skill的迭代和软件一样先做单点穿透再做横向覆盖。4.2 SKILL.md核心配置逐行拆解下面是我实际在用的一个SKILL.md的结构我把核心部分剥出来讲一下设计意图--- name: storyboard-generator description: 当用户提供小说原文、剧本片段或叙事性文本并希望生成动漫分镜脚本时使用。输入应包含需要分镜的具体段落输出为结构化分镜脚本包含镜头编号、景别、运镜、角色动作、台词、情绪标注。 --- # 动漫分镜脚本生成 你是一名资深动漫分镜师擅长将叙事文本转化为符合影视节奏的分镜脚本。 ## 工作流程 1. 阅读输入文本提取场景、角色、情绪基调。 2. 根据情绪节奏决定镜头切分密度平静场景3-5个镜头情绪高潮场景可适当增加镜头数。 3. 输出分镜脚本每个镜头严格遵循下述字段结构。 ## 输出格式 | 镜头号 | 景别 | 运镜 | 画面内容 | 角色动作 | 台词 | 情绪标注 | |---|---|---|---|---|---|---| | 1 | 全景 | 缓推 | 黄昏的街道 | 主角独自行走 | 无 | 孤独、压抑 | ## 硬性规则 - 景别只能用大远景、远景、全景、中景、近景、特写、大特写。 - 运镜只能用推、拉、摇、移、跟、升降、手持、固定。 - 情绪标注必须使用1-2个情绪词禁止情绪描写句子。关键设计有两个。第一description里明确写了输入和输出模型在规划阶段就能精准判断是否调用。第二硬性规则控制了输出格式的“枚举范围”这样无论怎么跑模型都不会编出第三种景别叫法。表格结构比自然语言描述更约束模型强烈建议能用表格定义的格式就用表格。4.3 资源文件与示例设计SKILL.md本身可以把规则说清楚但“做得像不像资深分镜师”靠的是resources里的示例。我的目录结构长这样storyboard-generator/ ├── SKILL.md └── resources/ ├── shot_list_template.md ├── camera_terminology.md └── examples/ └── sample_storyboard.mdshot_list_template.md是空表模板模型可以拿着它直接填空camera_terminology.md里补充了一些进阶的镜头运用说明比如“手持镜头适合表达慌乱感”“缓推适合制造压迫感”这些不在SKILL.md里写死否则指令太长sample_storyboard.md则是我手工打磨的一个完整示例包含8个镜头展示从平静到高潮的节奏变化。我实测下来模型在读取示例后对节奏的把控明显比只读规则要好它学会了在情绪转折时主动切近景和特写。这里有一个细节示例不要给得太“完美”。我给过一个满分示例结果模型每次输出都往这个示例的结构上硬套场景一变就显得生硬。后来我放了三份不同节奏的示例慢节奏文戏、快节奏动作戏、内心独白戏模型就有了更丰富的参考空间输出适配性上升不少。4.4 测试迭代与常见翻车现场装好Skill之后一定要先做一轮边界测试。我会准备三组输入一段日常对话文本、一段符合Skill目标的叙事段落、一段介于两者之间的模糊文本。第一组的预期是“不触发Skill”第二组是“正常触发并高质量输出”第三组看它会不会误判。我第一轮测试时翻了个车一段用户闲聊的口语化文字触发了分镜Skill模型给一段日常聊天配了8个镜头非常滑稽。问题出在description里“叙事性文本”这个词太宽聊天记录也是叙事。后来我把描述改成“用户提供小说章节、剧本片段等文学性叙事文本且明确表示需要生成分镜时使用”把触发场景收紧到带文学属性的输入误触发才降下来。迭代时不要只改文字描述必要时要改示例文件。我发现模型特别喜欢模仿示例里的第一句话开头所以我刻意让三份示例的开头方式不一样防止输出产生固定套路。另外如果你修改了SKILL.md有些平台需要重启会话或者重新加载技能才能生效别改完发现没变化就以为写错了。5. Skills的边界、局限与下一步创作空间5.1 选型判断Skills、MCP、还是普通提示词用了大半年Skills之后我形成了一个简单的选型判断逻辑。如果任务是一次性的比如“帮我写封邮件”“解释一下这个概念”普通提示词就够了没必要建Skill。如果任务需要模型连接到外部系统、读写数据库、调用API那该上MCP而不是Skills。如果任务是“一类工作”有固定的规则、流程、输出格式且你会反复做那就值得做成Skill。还有第三种情况任务既需要规则又需要外部数据那就Skill加MCP组合Skill负责行为约束MCP负责能力供给。拿我做论文Skill的经验来说论文写作本身不需要外部系统纯规则和示例就能搞定所以一个纯Skills方案就够了。但我的竞品分析Skill就挂了MCP因为它需要实时抓取资料Skill部分负责分析框架MCP部分负责搜数据。这个组合是目前我认为最优雅的Agent工作流组织方式。5.2 我总结的五条经验法则第一条description比正文重要花时间打磨触发条件永远值得。一个触发精准但内容普通的Skill比一个乱触发但内容精良的Skill有用得多。第二条Skill是“写给别人看的文档”你要想象自己是那个第一次接触这个技能的模型按照你写的说明书能不能做到位。写完后隔几天再读一遍最能发现问题。第三条把规则分级。SKILL.md只放硬性规则和流程柔性的经验、参考案例、扩展内容都放到resources里。混合在一起的结果就是模型的选择困难症。第四条版本管理要跟上。我吃过只改不记的亏改了好几版SKILL.md之后都不知道哪个参数导致的输出变化。现在我会记录每次改动的原因和效果这个清单比Skill本身还值钱。第五条多把Agent行为当作产品去打磨。Skills不只是技术方案它是你给Agent立的工作规矩的综合体。好的规矩让Agent成为一个可靠的伙伴坏的规矩让Agent变成一个听话的笨蛋。5.3 下一步的创作空间Skills现在还在很早期的阶段官方市场、第三方平台都还像最开始的应用商店一样品类稀少。我比较看好的几个方向一是垂直行业的Skill套件比如医疗科普、法律文书、教育培训这类有行业规范的内容二是“Skill组合”设计通过多个Skill串联出一个完整流水线三是个人知识库与Skills结合把你的个人经验沉淀成可复用的行为模板。我自己接下来的计划是把手头已经验证过的分镜、论文、前端组件三个Skill整理成一套“创作者工作流”并在GitHub开源出来。我始终觉得AI时代最值钱的不是模型而是你教模型怎么干活的那一套方法论。Skills恰好就是这套方法论的载体这也是我愿意花这么多篇幅来拆它的原因。最后说点个人体会。从最初手动粘贴提示词到如今各平台里躺着一排我亲手做的Skill这种改变带来的不仅是效率提升更是心态上的变化——我现在更愿意把复杂的、专业的事情交给Agent去做因为我知道它的行为方式是被我定义过的而不是每次都在自由发挥。如果你还没试过自己动手写一个Skill我强烈建议你从手头最重复、最标准化的那个任务开始把它变成你的第一个Skill。做成功的那一刻你会觉得之前的提示词工程都白干了。