别再复制粘贴提示词了：什么时候该把它沉淀成 Agent Skill

每个 vibe coder 的收藏夹里，都躺着几十个"神级提示词"：代码评审模板、Commit 信息生成器、PRD 拆解指令……它们被复制、粘贴、再复制，直到某天你发现：同一段 300 行的评审提示词，这个月你已经粘贴了第十一次，每次还要手动改三处项目名。问题不在提示词写得不好，而在于——你一直在用"一次性指令"的方式，干"可复用能力"的事。

2026 年，随着 Claude Code 带火 Agent Skills，局面正在改变：提示词不再只是一段文本，而可以打包成可安装、可版本管理、可按需加载的技能包。但很多人用错了方向：要么把所有提示词一股脑转成 skill，要么继续在聊天框里复制粘贴。本文给一个明确的判断框架：什么时候提示词就够了，什么时候必须沉淀成 skill，以及一个 skill 的目录结构到底该怎么写。

提示词和 Skill，差的不只是格式

先把概念掰开。提示词（prompt）是一次性指令：它活在某次对话里，解决当下这一个任务，任务结束，它的使命也就结束了。下次还想用，只能重新粘贴——附带手动改项目名、路径、技术栈的"体力活"。

Skill 则是可安装的能力包。以 Agent Skills 这套规范为例，一个 skill 是一个目录：SKILL.md 负责说明"这个技能是什么、何时触发、怎么用"，还可以带上 scripts/（可执行的脚本）和 references/（参考文档、检查清单、示例）。Agent 在需要时自动发现、按需加载——这叫渐进披露（progressive disclosure）：平时只占几十个 token 的元信息，真正触发时才把详细内容读进上下文。

打个比方：提示词是便利贴，skill 是工具箱里的专用工具。便利贴适合"提醒一次"的事；但如果你每周都要拧同一种螺丝，就该去买一把真正的螺丝刀，而不是每次都手写一张"记得逆时针拧"的纸条。

更关键的区别在可维护性。提示词散落在聊天记录、Notion、收藏夹里，改了一处，别处还是旧的。Skill 是文件，可以进 git：改了检查清单，所有项目下次自动用新版；回滚、diff、code review，全套软件工程的纪律都能用上。提示词是消耗品，skill 是资产——这是全文最重要的一个判断，记住它。

三个信号：你的提示词该"升级"了

不是所有提示词都值得变成 skill。我的判断标准是三个信号，命中任意一个，就该动手：

• 信号一：同一段提示词，你粘贴了第三次。"事不过三"是铁律。第一次粘贴是尝试，第二次是验证，第三次意味着这是一个稳定、可复用的工作流。每多粘贴一次，你都在支付三笔隐性成本：手动改参数的体力、占用的上下文 token、以及"这次用的到底是不是最新版"的不确定性。第三次，就是沉淀的时机。
• 信号二：它涉及多步骤和文件操作，光靠文字讲不清楚。如果你的提示词里出现"先运行 X 脚本检查，再按检查清单逐项核对，最后输出 Y 格式的报告"——这已经不是"一句话指令"，而是一个"流程"。流程需要结构：脚本就该是真正的脚本（scripts/），检查清单就该是真正的文档（references/），而不是挤在一段提示词里让 agent 自由发挥。
• 信号三：你希望别人（或未来的你）在别的项目里也能用。团队协作、多项目并行时，提示词的复制粘贴式传播是灾难：A 改了个措辞，B 还在用旧版，C 根本不知道有这东西。Skill 可以装进 git 仓库，一次编写，处处安装，版本统一。这是从"个人技巧"到"组织能力"的分水岭。

反过来，如果一段提示词只用一次、纯靠模型临场发挥（比如"帮我想个产品名"）、或者你还在高频修改措辞——别急着做成 skill。过早结构化是另一种浪费：先让提示词在实战里稳定下来，再沉淀。

多说一句关于误触发：skill 最大的隐性成本不是编写，而是误触发。description 写得太宽泛（比如"帮助用户写代码"），agent 动不动就加载它，白白烧掉几千 token。我的经验是：description 里必须写清"负面条件"——明确什么情况下不要触发。每次发现一次误触发，就回来看一眼 description，把这次的场景补进"不要用"清单。好的 skill 是"调"出来的，不是"写"出来的，前两周的微调，决定了它未来半年的体验。

真实案例：从一段 300 行提示词到一个 Skill（附目录结构实操）

独立开发者阿 K（化名）同时维护 5 个小项目，他有一段打磨了半年的代码评审提示词：300 多行，涵盖安全、性能、可读性三类检查项，外加严格的输出格式要求。每次使用前，他要手动替换项目名、技术栈，还要删掉不相关的检查项。更糟的是，这段提示词每次要吃掉约 8000 token 的上下文——评审还没开始，上下文窗口已经去了一大块。

他把它改造成了一个叫 code-reviewer 的 skill。改造后的变化是立竿见影的：

• SKILL.md 只剩 800 字。只写清"何时触发"（用户说 review，或提交 PR 前）、评审流程三步、输出格式。原来 300 行的检查项细节，搬进了 references/ 下的三个文件，agent 按需读取——不相关的检查项不再占用上下文。
• 可执行的脚本代替了文字描述。原来提示词里"先跑一遍 lint 和类型检查"这句话，变成了 scripts/precheck.sh，agent 直接执行，输出稳定可预期，不再靠模型"记得"去跑。
• 一次编写，五处复用。skill 装进他的 dotfiles 仓库，5 个项目全部安装。某天他给安全检查项加了一条"检查 SQL 字符串拼接"，git push 之后所有项目下次评审自动生效——以前这种更新，他得逐个聊天记录去翻。

量化一下收益：单次评审的上下文占用从约 8000 token 降到约 1500 token（按需加载），手动改参数的时间归零，版本混乱彻底消失。阿 K 的原话是："以前我是在'喂' agent 干活，现在我是'装备' agent 干活。"

目录结构实操：下面是一个可以直接照抄的最小可用结构：

• skills/code-reviewer/SKILL.md —— 技能的"说明书 + 触发器"。开头用 frontmatter 写 name 和 description。注意，description 是 agent 决定"何时加载它"的路由依据，要写触发场景而不是功能介绍——写"当用户要求代码评审、或在提交 PR 前检查代码质量时使用"，而不是"一个代码评审工具"。正文分四段：这个技能解决什么问题、何时用它、何时不要用它、执行步骤与输出格式。"何时不要用"和"何时用"同样重要，它能防止误触发，省掉大量 token 和等待时间。全文控制在 800 到 1500 字，写多了 agent 反而抓不住重点。
• skills/code-reviewer/scripts/ —— 可执行的脚本。比如 precheck.sh（一键跑 lint、类型检查、单元测试）、extract-diff.sh（提取本次变更的文件列表）。原则：凡是确定性的机械步骤，都写成脚本，别让模型用文字"表演"执行。脚本要有可执行权限，输出要机器可读。
• skills/code-reviewer/references/ —— 按需查阅的参考资料。比如 checklist-security.md（安全检查项）、checklist-performance.md（性能检查项）、examples/good-review.md（一份优秀评审报告的示例）。Agent 只在 SKILL.md 的指引下按需读取，不一次性塞进上下文——这就是渐进披露真正省 token 的地方。

写 SKILL.md 还有三个实操要点：第一，步骤写"做什么"而不是"怎么做"。步骤是给 agent 的行动纲领，细节下沉到 scripts 和 references，这是渐进披露能生效的前提。第二，给技能起一个动词化的名字。code-reviewer、db-migrator、api-tester——名字即意图，agent 路由时更准。第三，先在小项目上试跑三次再推广。观察 agent 的触发是否准确、输出是否稳定，调完 description 和步骤再装进主力项目。

从今天开始的四步行动清单：

• 第一步：建一个"提示词坟场"，开始计数。新建一个文档，每次复制粘贴提示词时记一笔：日期、哪段提示词、用在哪。当某段提示词出现第三次，它就是你的第一个 skill 候选。没有计数，你永远觉得"下次再说"。
• 第二步：用上面的目录结构，做第一个 skill。别贪多，就选粘贴次数最多的那一段。先写 SKILL.md（800 字），再把提示词里的"机械步骤"抽成脚本、"参考细节"抽成 references 文件。第一次动手，一小时内能完成。
• 第三步：用 git 管理你的 skills 仓库。个人用就放进 dotfiles，多设备同步；团队用就建独立仓库，新人入职装一次。给每个 skill 写一行 README 说明用途——三个月后的你，会感谢现在的自己。
• 第四步：每季度给 skill 做一次"减法"。Skill 也会腐烂：模型变强了，某些检查项不再需要；流程变了，脚本要更新。定期 review：这个 skill 上季度被触发了几次？省了多少时间？没人用的 skill 果断删除——不存在维护成本为零的 skill。

还有一个反直觉的提醒：skill 不是越多越好。我见过有人做了 40 多个 skill，结果 agent 每次路由都要读一遍 40 个 description，触发准确率反而下降，还不如 5 个精心维护的。个人建议维持在 5 到 10 个，团队 10 到 20 个，超过就先做减法。同时警惕"简历型 skill"——为了显得专业，把"帮我写周报"这种一次性需求也做成 skill，纯属自我感动。检验标准永远只有一个：它下个月还会被触发吗？不会，就让它安心留在提示词坟场里。Skill 是资产，资产需要打理，囤积不是投资。

补一句：skill 和 MCP、插件是什么关系？简单说，MCP 给 agent 接的是"外部世界"（数据库、API、浏览器），skill 给 agent 装的是"做事方法"（流程、规范、检查清单）。两者互补，不互斥。在一个成熟的 agent 工作流里，MCP 负责"够得着"，skill 负责"做得对"。先把手头的提示词沉淀成 skill，再去折腾 MCP 生态——顺序别反。

我的观点：Skill 正在成为 agent 时代的新分工线

回头看，提示词工程的红利期正在过去：模型越来越擅长理解模糊指令，"措辞技巧"的价值在衰减。但另一端的价值在上升——把"怎么做事"的知识，沉淀成 agent 可复用的结构化资产。Skill 就是这种资产的载体。

我的判断是：未来一年，"会写 skill"会从极客玩具变成团队标配，就像当年"会写 Dockerfile"一样。它衡量的不是你多会"调教"模型，而是你多会把隐性工作流显性化、把一次性经验变成可复用的基础设施。而这，恰恰是 AI 替代不了的那部分——因为"事情该怎么做"，永远来自你的实战。

所以，今晚就做一件事：打开你的提示词收藏夹，找到粘贴次数最多的那一段，问自己——它还值得第四次、第五次粘贴吗？如果答案是"还会用很多次"，那就别再复制了：给它一个目录，一个名字，一次版本管理。你的 agent 值得更好的装备。