1. 别再只收藏“提示词”了把能力做成“skills”最近半年我明显感觉到圈子里讨论的重点从“怎么写 prompt”转移到了“怎么让 agent 稳定地具备某种完整能力”。前端开发也好、写论文也好、处理分镜脚本也好大家不再满足于把一段话复制给对话窗口而是开始主动整理“skills”。这个词在 AI 编程工具、代码助手、智能体框架里高频出现甚至有专门的下载站、市场、排行榜热门程度不亚于当年的“插件生态”。什么是 skills简单说就是把一件可以重复执行、有明确步骤、有边界条件、有产出格式的事情封装成一个 agent 能识别、能加载、能按流程执行的能力单元。它不是一段提示词也不是一个独立应用而是一个介于两者之间的东西底层是脚本和工具调用上层是描述触发条件和执行流程的元数据。贴近生活的理解是提示词像菜谱skills 像半成品净菜包——你不需要自己洗切配拿到手直接下锅而且口味和出品时间高度稳定。这篇文章不会堆概念我只讲自己在实际项目中拆解、编写、安装、排查 skills 的真实过程以及踩过的坑。适用人群很明确正在用 agent 编程、做文档自动化、做内容批量处理、或者想给别人交付“可复制能力”的开发者。看完你应该能自己搭一个能被多个 agent 工具识别的 skills 包也知道在什么场景下不一定要用 skills。2. 第一性原理skills 在 agent 体系里到底解决什么问题2.1 agent 的“超能力”不在模型在可复用工具链要理解 skills 为什么突然变热得先看 agent 的工作方式。模型本身是没有持久记忆的每次对话都是一次新的推理。你告诉它“按照这个风格写十篇产品文案”它能写但下一次换一个会话它又忘记了你的风格规范、关键词约束、推荐的段落结构。于是所有人都在做同一件事把经验外置。外置的载体曾经是文档、是 prompt 变量、是 few-shot 样例。但文档容易被忽略prompt 里塞太多样例又会挤占上下文长度。skills 解决的就是这个外置问题的标准化把一套流程、脚本、规则、模板打包成一个目录agent 在需要的时候去加载而不是在每次对话里被动接收。我个人的体会是skills 真正带来的不是单次回答质量的提升而是跨会话的一致性。同一个 skill周一跑和周五跑输出的结构不会漂移这才是“工程化”的开始。2.2 skill 包的数据结构其实就是“说明书 工具箱”拆开一个典型的 skill 包大概包含三类内容。首先是描述性与索引信息比如名称、版本、适用场景、触发关键词这一层让 agent 知道“什么时候该想起它”其次是指令模板也就是给模型看的流程提示告诉它先做什么、后做什么、产出什么格式最后是配套脚本、Python 文件、Shell 命令或 API 调用程序实现真正需要计算或访问外部系统的部分。用第一性原理拆解它的设计动机非常朴素。模型擅长理解语义和生成文本但不擅长精确计算、遍历本地文件、调用外部接口、控制环境变量。而普通脚本擅长这些却不知道什么时候该运行。把两者粘合起来中间靠一层格式化的元数据做路由——这就是 skills 的核心定义。明白这一点之后你就不容易把它想复杂它本质上是一个“更聪明的工具封装协议”。2.3 上下文长度焦虑是它走红的重要推手还有一个很现实的原因上下文是稀缺资源。现代 agent 产品虽然窗口越开越大但真正有效的注意力还是有限的。如果把所有规范、示例、工具说明都塞进对话里那模型刚启动就已经有了几千 token 的负担还没干活就先背了包袱。skills 采用按需加载之后这个压力被解决了——用得多、匹配度高才加载类似于程序运行时的延迟初始化。这会带来一个很容易被忽略的工程收益同一个心智模型可以被很多独立技能共享。比如某个技能里需要调用浏览器自动化不必每个技能都重复写一遍环境配置只要在对应技能脚本里统一引用公共模块。我后文会提到这种“共享核心 独立技能”的结构是让技能库规模从 10 个扩张到 200 个而不崩坏的关键。3. 我如何从零搭建一个可用的 skills 工作区3.1 第一步确定边界skills 不该是什么都装的大杂烩很多新手拿到“skills”这个概念后的第一反应是把所有常见任务都做成技能。结果目录越来越大名字越来越长agent 反而不知道该选哪个。我踩过这个坑。第一次搭技能库的时候我塞了格式化代码、生成单元测试、写提交信息、审查 PR、翻译文档、整理周报二十多个技能触发规则相互重叠最后执行哪一个完全不可控。后来我重新定了边界只有同时满足“流程相对固定”“跨会话高频复用”“有明确的产出检查点”三件事才值得做进 skills。比如写营销文案就不适合因为风格千变万化一次性的东西不如直接用对话。而“按既定模板批量生成分镜脚本”就适合因为流程固定、字段频繁、格式要求强。边界想清楚了技能库才开始变得干净。3.2 目录结构、命名逻辑与最小可运行模板我现在的标准技能目录是这种结构一级目录按技能用途分比如research/、writing/、frontend/、automation/每个技能内部至少包含一个说明文件、一个指令模板文件、一个可执行脚本目录。说明文件里写名称、描述、依赖环境、触发关键词指令模板里写执行步骤和输出格式脚本目录里放真正跑逻辑的代码。命名上我坚持一条原则名称既是人类可读的也是 agent 可匹配的。不要叫skills_v3_final要么叫storyboard-generator要么叫frontend-code-reviewer。描述文本要写清楚它擅长的事情以及常见调用场景。这段描述太重要了实际运行中我发现 agent 是否发现并加载某个技能很大程度上取决于它是否理解了你的描述而不是你的脚本是否优雅。3.3 从机器可执行到模型可理解一个技能的两层演进写第一个可用技能时我还没有分区概念只写了一段 Python 脚本然后试图用一句提示词把脚本描述清楚。效果很差agent 经常不看脚本内容或者看了也不知道在什么情况下运行。后来我花了大量时间改描述部分每次迭代之后命中率明显提升。我的结论是在一个技能包里面向模型的“说明书”与面向机器的“可执行代码”拥有同等的重要性。举个具体场景。我想做一个“前端代码审查 skills”脚本本身只是几个 grep 和 lint 规则检查但说明文件里我详细列举了触发它的场景当用户要求检查组件代码性能问题、当用户需要分析依赖体积、当代码里有 TODO 标记需要梳理。这些触发场景不写清楚agent 可能只会把你给的代码丢给通用模型去硬看根本不会加载技能脚本。描述准确比代码完美更值得先投入。3.4 安装与作用域从单机文件夹到可共享的包格式技能装到哪、怎么装不同工具大概有三类方式。最简单的当然是文件夹路径式把技能目录放进 agent 配置指定的目录软件启动时会扫描加载更正式一点的是打包成归档包带版本号和依赖清单用包管理器安装第三种是远程仓库式直接引用代码仓库里某个子目录便于团队共享。我常用的是前两种个人项目用目录交付给团队时打成包。在作用域的选择上我的建议是个人技能放用户目录团队共用技能放项目级目录。如果你把一个个人习惯很强的技能放到团队级目录里很可能干扰别人的工作流。比如我习惯在代码审查技能里强制检查某个命名规范同事用的却是另一种风格。与其让大家靠记忆去规避不如做好作用域隔离各自维护自己的“技能区”。4. 制作一个前端审查技能时我总结的关键细节4.1 千万不敢把只用一次的检查硬编码进去前端开发相关的 skills 是搜索热词里最高频的之一但这门类的技能也最容易写废。我见过有人把 Tailwind、ESLint、TypeScript 配置全写死在一个技能里换了项目就崩。正确做法是把配置读取的逻辑与检查逻辑分开脚本负责读当前项目的配置文件然后按配置执行检查而不是预设一套全局规则。如果检测到当前项目没有任何 lint 配置脚本要能优雅降级给出提示而不是报错中断。这种“宽容式设计”对 agent 技能特别重要因为 agent 无法像人类开发者一样随时问你项目情况你的脚本就得自己感知环境。这是我在多次失败里打磨出来的经验。4.2 模型执行流与脚本执行流的衔接点另一个容易忽略的地方是输入输出格式。模型加载技能后会依据描述中的步骤执行但它的“步骤”最终还是要落到脚本调用上。你要明确告诉模型第一步读哪个文件、第二步调哪个脚本、第三步把结果贴回到对话里。如果不把这些执行流连接点写清楚会出现一个很滑稽的场面技能被加载了模型对着它点头称是然后完全绕开脚本用通用知识给了个模棱两可的答案。我在技能描述里加了一个“执行清单”用编号步骤写清楚每一步该做什么还特别标注“不要跳过第 2 步调用检测脚本直接凭印象给结论”。做完这个调整之后输出的可验证性上升了一大截。你要相信模型有很强的“礼貌性从众”你不强约束它它就会回到最熟悉的自由发挥模式。4.3 日志、退出码和可观察性脚本跑起来后你要能看到它结果agent 也要能理解它结果。我一开始写的技能脚本只输出一个“OK”完全没有细节agent 拿不到可复用的信息还得自己再猜。后来我把脚本输出改成三层结构第一层是执行概况第二层是具体问题列表第三层是修复建议。agent 拿到之后可以直接基于修复建议给出答案而不是重新推理。同时我建议所有脚本都返回明确的退出码尤其是提供给 agent 调用时。因为很多 agent 框架会用退出码判断脚本是否成功而不是读你的英文输出。退出码非 0 的情况下框架会走异常分支可能触发重试逻辑也可能直接放弃。一个只输出提示但返回 0 的失败脚本反而是最迷惑系统的东西。5. 从哪找现成 skills下载平台与筛选方法论5.1 热门来源的盘点与分类目前社区里能下载到 skills 的地方集中在几个渠道官方文档带的一些示例库、代码托管平台上聚合的仓库集合、个人博主发布的技能包以及少数独立的 skills 导航站。搜索热词里“skills 下载平台有哪些”“skills 安装包下载”都说明了需求侧对“现成可用”的强烈期待。好的一面是生态初期敢发布出来的大多是作者实战中提炼过的东西质量普遍还行坏的一面是缺少统一的元数据和版本校验你很难在下载前知道它是否适配自己的 agent 环境。我的习惯是优先找带示例和测试用例的技能仓库再看更新日期最后自己跑一次最小场景验证。名称再炫酷也不如一次真实运行可靠。5.2 用“四看”查验第三方技能的可信度既然没有统一沙箱你就得靠自己的火眼金睛。我的查验方法是四看看依赖清单是否明确、看脚本是否有危害性操作、看描述是否与脚本逻辑一致、看作者回复 issue 的频率。尤其是第二点如果一个技能脚本里有下载远程文件并执行的逻辑你最好仔细读完每一行再决定是否安装。我不建议直接以 root 权限运行第三方技能包也不建议让它读取私钥、上传 token 到非官方服务。即便发布者没有恶意第三方代码也经常包含过时的路径、错误的权限处理风险是你承担的。所以安全审查不是“对人不信任”而是对代码必然的不完美保持敬畏。5.3 本地仓库 vs 官方市场我们的选择策略随着生态成熟有些 agent 工具开始提供内置的“市场”频道形式上类似插件商店。在这个选项出现后我不再建议普通用户自行去代码托管平台海淘技能原因很简单市场有统一的安装流程、依赖锁定、版本兼容记录。它牺牲了部分自由度但换来了确定性。我的策略是“市场优先仓库次之自写兜底”。核心业务技能、与企业内部系统深度绑定的技能一定自写通用办公、格式转换、常用审查这类技能优先用市场版第三方的惊喜仓库只在小规模试验环境里试玩不再直接迁移到生产工作区。这套策略帮我省了很多折腾时间。6. 实操心法自动巡检、分镜脚本与长文本写作场景6.1 把零散工具链组装成可复用的自动化巡检我想用更接近“自动化编排”的例子来说明 agents 的组装价值。比如我做过一个覆盖多站点的动态内容健康巡检系统本质上是把浏览器抓取、链接检查、页面状态记录、报告生成几件事串成一个管线。如果不用技能思想每轮巡检都要重新交代工具参数、输出路径、报告模板非常低效。后来我把“巡检脚本”做成一个技能描述里写清楚触发词是“巡检某站点”执行脚本会读配置文件里的站点列表跑完后以 markdown 摘要输出结果。它带来的最大变化是我可以在一个自然语言指令里同时触发多轮巡检任务agent 自动完成分布调度而不需要我反复贴命令。这种多层次复用的方式才是把工具沉淀成团队资产的正道。6.2 分镜脚本技能让输出格式和情绪要求不再走样分镜脚本是一个特别典型的“格式强依赖”场景尤其是在短视频与广告制作中。导演、文案、摄影、剪辑多方协作时字段名如果飘忽不定后面所有环节都会跟着乱。我写过对应的技能给团队用它包含了片名、镜头编号、景别、画面描述、对白提示、情绪参考、转场方式等字段并用固定模板输出表格视图。最考验人的地方是“情绪参考”这个字段它偏主观模型每次自由发挥都会给出不同的描述。我后来把它做成枚举值冷静、紧张、轻快、温馨、诙谐、庄重。模型在枚举内做选择稳定性就大幅提升。这也算是我对“技能设计”的一个理解能用结构化约束解决的问题就不要指望模型每次自觉保持一致。6.3 面对长文档写作技能如何避免变成耿直的模板机写论文、写报告的技能也很火但有一个陷阱任务复杂时一个模板描述根本不够用容易逼着模型输出空壳内容。我自己测试过不少“论文写作 skill”不少技能的描述写得天花乱坠真到执行时却只是把标题替换了一下正文依旧泛泛而谈。我的解決方案是把大型任务拆成阶段技能比如“检索提纲”技能、“段落扩写”技能、“文献引用规范化”技能每一步只负责一个可检查的子任务。写论文需要的是多个子技能的串联而不是一个巨大的黑盒技能。在实际工作流里只需要一个总调度指令剩下的由 agent 自己递归调用子技能。虽然步骤变多但每一阶段的可干预性都提高了。7. 故障排查与避坑清单你一定会遇到的几个典型问题7.1 装了技能却没有触发命中的关键居然在描述这大概是最高频的求助帖类型。我排查过很多次最终发现 80% 的情况不是脚本坏了而是描述文本里的触发条件没有与 agent 的语义理解对齐。比如你想让它在“用户希望分析产品文案”时触发但描述里只写了“文案分析”agent 可能无法联想到这个场景。排查路线是先看日志确认识别阶段有没有扫到该技能再检查描述文本看它是否明确列举了多种触发说法最后才是看代码问题。想快速提升触发率可以把同一场景的常见说法写成同义词列表比如“检查一下这些推广语”“看看活动文案哪里不对”“帮我评估一下这几条 slogan”这比只写一个笼统的描述管用得多。7.2 技能之间互相干扰优先级和命名空间缺失技能多了碰撞就来了。两个技能可能对同一个用户诉求“沾边”但一个负责生成、一个负责审查。若没有明确的优先级规则agent 有可能随机选一个或者尝试在一个步骤里同时调用结果一团糟。我的做法是在描述里开头加一个“领域声明”并在脚本开头做一个前置判断如果当前用户的诉求更符合另一技能的描述则建议用户切换。更进一步我会在技能说明文件里增加“不适用场景”段落。别小看这个负向清单它能让 agent 明显减少错误加载。这很像程序里的提前返回明确告诉模型什么时候不要用反而能提高正确命中率比单纯强调“什么时候可以用”更有效。7.3 升级与回滚给技能加上版本意识技能也是代码会迭代、会坏。我给技能仓库引入了版本号控制但版本号不能只写在文件里还要让 agent 能看到。否则你更新了技能逻辑老会话还拉着旧版本上下文行为完全不可预期。最简单的做法是在技能目录里放一个VERSION文件并在加载日志中输出它。回滚方面我的要求是必须能在秒级完成。具体操作就是用 git 标签管理技能版本。日常改坏一个技能没关系只要在执行时发现输出异常立即切回上一个 tag。不必为每一次小改动写大量文档但git revert的能力一定得有。这个习惯救过我很多次强烈建议所有技能仓库都启用版本控制。7.4 对环境变化过度敏感一场“工具链漂移”的隐患技能脚本经常会依赖 Python 版本、Node 版本、系统命令路径。你上个月跑得好好的技能这个月因为某次系统更新就罢工了。我发现最省事的方法是技能启动时先做环境检查打印关键依赖的版本并明确告诉我哪里不满足。这里牺牲一点点首次执行速度却能在后续排查里成倍地节约时间。更进一步的建议是能用容器封装的技能尽量做成容器。不要留恋“复制目录即用”的轻便因为环境漂移带来的隐性成本往往更高。这是我从无数个“昨天还好好的”的报障里总结出的血泪经验。8. 把 skills 用到什么程度才算“内化”了我的最终评价标准不是“我装了多少个技能”而是“我是否在每一个重要工作流里都建立了稳定的能力单元”。如果你只是热衷下载别人的技能包今天这个、明天那个那充其量是在尝鲜当你开始动手修改一份技能的指令模板把它改得更贴合你自己的业务流程那一刻才算是把这套思维方式真正内化。我常对刚入门的朋友说先选中一个你每周重复三次以上的任务做成技能。从自己能改脚本的最小版本做起不要一开始就追求覆盖全流程。一个 200 行以内、但是你真在用的小技能比一个功能完整但你从不调用的豪华技能更有价值。说到底skills 本质是“把专业判断结构化的能力”。你越是能把隐性经验显性化把显性过程自动化你的工作就越不会被具体工具绑定。工具会变、模型会升级但留下来的那套“可沉淀的流程与检查点”才是真正的长期资产。