Skills 不是提示词，是给 AI 代理的工作手册

为什么单靠提示词会失控#

如果只是让模型“帮我润色一段话”，一段提示词当然够用。但项目一复杂，提示词就会开始漏水。

比如你真正想要的可能是：

• 先阅读现有设计系统，不要凭空发明一套组件风格。
• 如果涉及 3D 场景，必须确认 canvas 不是空白，移动端也没有遮挡。
• 如果是后台管理页，不要做营销落地页那种大 hero。
• 如果改的是线上站点，必须构建、检查、部署，并且不能影响正在跑的服务。
• 如果文件里已有用户改动，不能随手回滚。

这些要求不是“风格建议”，而是工作约束。它们不应该每次都靠用户重新说一遍，也不应该埋在一次性对话里，等上下文一长就被冲淡。

skill 的价值就在这里：把某一类任务的经验固化成可复用的操作规程。

它不替你写答案。它替你维护“怎么做这类事才算靠谱”。

一个 skill 到底应该装什么#

我更愿意把 skill 拆成四层。

第一层是触发条件。

它回答“什么时候该使用我”。这部分要写得像路标，而不是像广告。比如“当用户要求创建、编辑或审查 .docx 文件，并且格式保真很重要时使用”，就比“我是强大的文档专家”有用得多。

好的触发条件有边界感。它不仅说明自己管什么，也暗示自己不管什么。边界越清晰，代理越不容易拿锤子找钉子。

第二层是流程。

流程不是“先分析再执行”这种空话，而是具体到能改变行为的步骤。比如处理 Word 文档时，要先读取源文件，再用结构化库修改，然后渲染成图片检查版式。处理前端时，要先看现有页面和样式，再决定布局，而不是直接生成一套新视觉。

流程的作用是把模型从“凭感觉回答”拉回“按工序交付”。

第三层是工具选择。

AI 代理最容易犯的错之一，是把所有问题都当成文本问题。看文件用猜的，查依赖用记忆，验证页面只说“应该可以”。一个 skill 应该明确告诉它：什么时候该用浏览器，什么时候该跑构建，什么时候该渲染 PDF，什么时候该调用现成脚本。

工具不是装饰。它是把幻觉压下去的重量。

第四层是验收标准。

这部分最容易被忽略，但它决定一个 skill 是“能干活”还是“会表演”。验收标准要写清楚什么叫完成：测试通过、截图确认、导出文件可打开、移动端无横向溢出、密钥没有进入前端包、错误信息不会吞掉真实原因。

没有验收标准的 skill，很容易把“做过”误当成“做好”。

渐进式加载：别把整本书塞进脑子#

一个常见误区是把 skill 写成巨大的百科全书。什么都放进去，越多越安心。

但 AI 的上下文不是仓库，它更像工作台。工作台上堆太多东西，真正要用的扳手反而找不到。

所以好的 skill 往往采用渐进式加载：SKILL.md 只放路由和总流程；遇到具体分支时，再读取相关参考文件、模板或脚本。

这件事听起来普通，其实很关键。比如一个“文档处理”skill 可能同时支持 Word、PDF、表格、幻灯片。如果每次都把所有格式的规则塞进上下文，代理会被无关信息污染。更好的办法是：先判断任务是 .docx，再只读 Word 相关的参考和脚本。

这叫把注意力花在刀刃上。

skill 不是资料越多越好，而是让代理在正确时刻看到正确资料。

Skills 和工具调用不是同一种东西#

工具负责“能做什么”。skill 负责“该怎么做”。

比如一个代理可能有终端、浏览器、文件编辑器、图片查看器、部署权限。工具列表很强大，但它不会自动告诉代理：

• 改线上代码前要先看服务状态。
• 写文章前要符合 frontmatter 规范。
• 做移动端优化后要检查桌面端有没有倒退。
• 处理密钥时不能把真实 key 打包进静态文件。

这些都不是单个工具能解决的。它们是任务方法论。

工具像手，skill 像手艺。

没有工具，skill 只能空喊流程；没有 skill，工具很容易被乱用。

Skills 和 RAG 也不一样#

RAG 更像“查资料”。它擅长把相关文档找出来，让模型参考事实。

skill 更像“执行规程”。它不仅告诉模型资料在哪里，还告诉它资料该怎么被使用，哪些步骤不能跳，什么时候必须验证。

举个例子：如果我要修一个前端响应式问题，RAG 可以帮我找到 CSS 文件、组件说明、设计规范。skill 则会进一步要求我：先复现问题，再定位断点，再小范围修改，再分别看移动端和桌面端，最后确认没有横向滚动和文本重叠。

一个提供上下文，一个约束动作。

真正可靠的代理通常需要两者配合。

写 skill 时最该避免的几种坏味道#

第一种坏味道：人格设定太多，操作约束太少。

“你是世界顶级专家”“你拥有十年经验”“你会输出高质量内容”，这些句子听起来很热闹，但真正能约束行为的信息很少。skill 里最值钱的不是头衔，而是可执行判断。

第二种坏味道：把结果模板写得很满，却不写输入检查。

很多工作失败不是因为输出格式不漂亮，而是因为一开始就没看清材料。比如代码审计前不看 diff，部署前不查服务状态，写文章前不确认站点的 frontmatter 规范。skill 应该把“先看什么”写清楚。

第三种坏味道：没有失败路径。

真实项目不会永远顺利。依赖装不上，接口返回错，浏览器打不开，远端磁盘满了，权限不够。一个成熟的 skill 不应该只写 happy path，还要说明失败时怎么降级、怎么保护现场、什么时候停止写入。

第四种坏味道：验收停在“看起来完成”。

“页面已优化”“文档已生成”“功能已实现”都不算验收。能打开吗？能构建吗？移动端能用吗？敏感信息有没有泄漏？线上服务是否还健康？这些才是验收。

怎么判断一个 skill 写得好不好#

我会用三个问题测试。

第一，换一个代理执行，它会不会明显少犯错？

如果答案是否，那这个 skill 可能只是风格描述，没有提供真正的操作信息。

第二，任务变复杂时，它能不能稳住边界？

比如从“改一个按钮”变成“优化整个后台管理端”，skill 应该能让代理知道哪些地方要看、哪些地方要保守、哪些地方必须验证。

第三，它有没有让用户少重复说话？

如果用户每次都还要补一句“别影响桌面端”“别把 key 放前端”“记得跑构建”，那这些经验就该进入 skill。

一个好 skill 的效果不是让 AI 显得更聪明，而是让协作更省心。

Skills 最适合沉淀什么#

不是所有东西都值得写成 skill。

适合沉淀的是那些重复出现、风险较高、流程清晰、验收明确的任务：

• 文档生成和格式校验。
• 前端重构和响应式检查。
• 代码审计和安全预检。
• 部署、回滚和线上健康检查。
• 特定项目的发文流程、标签规则、构建方式。
• 某类研究、写作或数据处理的固定方法。

不适合沉淀的是一次性的偏好、临时情绪、还没想清楚的探索方向。那些东西更适合留在当前对话里，等它们反复出现、变成稳定经验，再写进 skill。

skill 不应该成为垃圾桶。它应该像工具箱里的定制夹具，只为那些经常需要对齐的位置服务。

给个人项目写 skill 的想象空间#

个人项目尤其适合 skills。

因为个人项目最大的问题不是没有想法，而是上下文太散：部署方式在一处，文章规范在一处，移动端注意事项在一处，API 密钥规则在一处，回滚策略又在另一处。每次让 AI 接手，都像让新同事第一天上班。

如果给项目写一个站点维护 skill，它可以明确：

• 发文章必须进 CMS 数据源，不能只改静态生成目录。
• 新增 AI 功能时，密钥只能存在后端配置，不能暴露到前端包。
• 移动端优化必须同时检查桌面端关键页面。
• 部署时只保留最新备份和上一版回滚，避免服务器磁盘被旧包塞满。
• 评论、搜索、文章阅读这些核心路径要优先验证。

这类规则写进 skill 之后，AI 不会突然变成永不犯错的神仙，但它会少踩很多重复的坑。

更重要的是，项目会开始拥有“自己的工作方式”。

结尾：把经验从对话里拿出来#

提示词像临场嘱咐，skill 像长期手册。

临场嘱咐当然有用。每个任务都有当下的语境和偏好，需要用户随时补充。但那些反复出现的经验，不应该永远靠嘴说。它们应该从对话里拿出来，变成可以复用、可以检查、可以迭代的工作规程。

我越来越觉得，skills 的重点不是让 AI 多记几条规则，而是让人与 AI 的协作从“每次重新磨合”变成“站在已有经验上继续做事”。

这就像给一个会干活的助手配上项目手册。它仍然需要判断，也仍然可能犯错；但它不再每次都从零开始。

而在真实工程里，不从零开始，本身就是一种巨大的生产力。