当 Agent 从“会调用工具”走向“能稳定做事”，Skill 开始变成一层真正的工程封装。

导语

最近 Codex 官方把 custom prompts 明确标成 deprecated，建议直接用 skills 承载可复用指令。我觉得这不是一个孤立的产品改动，而是一个很值得注意的信号：AI coding / Agent 工具，正在从“临时 prompt 驱动”走向“结构化任务封装驱动”。

Windsurf 在推 Workflows，Claude Code 在把 instructions、skills、hooks 分层，Codex 也在把 reusable prompt 往 skill 收敛。很多人还把 Skill 当成提示词文件的别名，但从第一性原理看，它其实已经更接近一种任务级的工程封装。

这篇文章想聊的，就是为什么我越来越觉得：Skill 不是 Prompt Engineering 的边角料，而是 Prompt Engineering 开始工程化之后的重要产物。

摘要

• 为什么 Codex、Windsurf、Claude Code 都在往 Skill / Workflow 收敛
• Skill 和 Prompt 的根本区别到底是什么
• 为什么 Skill 本质上是在解决执行治理，而不只是提示技巧
• 当 Agent 真正进入重复任务场景后，为什么迟早会回到 Skill 这一层

最近我注意到一个很有意思的变化：Codex 官方已经明确把 custom prompts 标成 deprecated，建议直接用 skills 来承载可复用指令。

这件事本身看起来像个产品细节，但我第一反应不是“噢，功能改版了”，而是：终于，连产品层也开始承认，可复用 prompt 的终点，其实不是 prompt 收藏夹，而是 skill。

我为什么会对这件事这么敏感？

因为过去一年里，我自己在用这些 AI coding / agent 工具时，已经反复遇到同一种变化：

• 一开始，大家都在教模型“这次怎么做”
• 用久了，就开始沉淀“这类事以后怎么做”
• 再往后，就会发现：真正值钱的不是某一句 prompt，而是那套可复用的方法、边界和路径

因为如果你把视角放大一点，会发现不只是 Codex 在这么做。

• Windsurf 早就在推 Workflows，把重复任务沉淀成可调用、可共享、可版本化的工作流文件
• Claude Code 也在往 CLAUDE.md、skills、hooks 这一套可复用任务封装演进
• Codex CLI 则更直接，连官方文档都已经明确：可复用 prompt 的方向，正在收敛到 skills

换句话说，这不是某一个产品偶然改了个名字。
而是 AI coding / agent 工具，正在从“临时 prompt 驱动”走向“结构化任务封装驱动”的一个共同趋势。

这也是我写这篇文章的契机。

因为我越来越强烈地感觉到，很多人讨论 Agent，视线都放在更显眼的地方：模型够不够强、上下文够不够长、工具接得够不够多、框架够不够新。

这些当然都重要。
但如果你真的开始把 Agent 往真实任务里用，很快就会发现，真正决定它“能不能稳定干活”的，往往不是这些最热闹的部分。

而是一个很容易被忽略的层：Skill。

很多人第一次听到 Skill，会下意识把它理解成“提示词模板”“一段 system prompt”“给 Agent 塞进去的操作说明”。

这么理解不能说完全错，但太轻了。
因为在真实使用里，Skill 真正承担的，从来不只是“告诉模型怎么说”，而是把一类任务的做事方法、约束边界、调用路径、输出规范，固化成一个可复用、可迭代、可治理的执行单元。

从这个角度看，Skill 不是 Prompt Engineering 的边角料。
它更像是 Agent 时代里，被很多人低估的一层工程封装。

为什么现在重新谈 Skill？

我觉得一个很重要的原因是：产品演化正在替 Skill 这个概念“正名”。

以前大家会觉得，Skill 只是某个框架里的实现细节，或者只是把 prompt 文件化、模块化的一种管理方式。
但现在越来越多产品都在收敛到类似方向，这意味着它已经不是偶然设计，而是在解决一个共性问题。

Codex：从 custom prompts 走向 skills

Codex 官方文档已经明确写了：

Custom prompts are deprecated. Use skills for reusable instructions and workflows instead.

这句话信息量其实很大。
因为它不是单纯在说“旧功能下线，新功能上线”，而是在重定义一件事：

可复用指令，不再被理解成“prompt 收藏夹”，而开始被理解成“skill / workflow 级别的任务封装”。

这说明在 Codex 的产品演化里，重点已经不再是“如何存几段随时调用的文本”，而是“如何让一类可复用经验变成可被显式调用、也可被系统自动选中的能力单元”。

这背后的变化，其实非常关键：

• 从一次性 prompt 走向 长期复用能力
• 从手动触发文案 走向 结构化任务单元
• 从个人习惯 走向 团队共享和工程治理

Windsurf：从 Rules 走向 Workflows

Windsurf 去年推出 Workflows 的时候，我就觉得这个方向很值得注意。

因为它让我第一次很明确地意识到：产品已经不满足于让你“多写几段提示词”了，它开始鼓励你把完整做事路径沉淀下来。

因为 Workflows 本质上并不是让你“多存几段提示词”，而是在鼓励你把一类重复动作沉淀成一条结构化路径。

比如：

• 拉代码 → 改配置 → 部署到测试环境 → 生成 PR
• 拉 PR 评论 → 逐条处理 → 修复 → 汇总结果
• 更新依赖 → 跑测试 → 修复问题 → 提交变更

这些都不是单轮回答问题，而是一组有顺序、有上下文、有目标结果的动作。

Windsurf 的一个重要点在于，它把这类 workflow 直接放进 repo，让团队可以共享、版本化、持续迭代。
这其实已经非常接近 Skill 的核心精神了：

不是让模型临场发挥，而是把组织里反复出现的工作方法沉淀下来。

Claude Code：从项目说明走向 instructions + skills + hooks

Claude Code 这边的演化也很典型。

如果说 Windsurf 给我的感觉是“把重复动作写成 workflow”，那 Claude Code 更像是在告诉你：Agent 的稳定执行，本来就不该只靠一段大 prompt 硬扛。

它不是单独强调某一个功能点，而是在逐步把任务执行所需的几个层次拆清楚：

• CLAUDE.md：项目级的长期说明和约束
• skills：可复用的任务能力封装
• hooks：更确定性的自动化执行点

这套设计背后的逻辑很清楚：

• 什么是长期有效的上下文
• 什么是某类任务的可复用经验
• 什么是应该交给确定性机制处理的动作

也就是说，它不是把所有事情都塞进一段 prompt 里解决，而是在试图把 Agent 的“做事体系”分层。

我觉得这件事特别重要。
因为它意味着行业开始默认接受一个事实：

让 Agent 稳定工作，不能只靠一段越来越长的 prompt。

为什么 Skill 这个概念容易被低估？

我觉得还有一个很现实的原因：很多人其实不是没见过 Skill 的价值，而是已经在享受它带来的好处，却还在用 prompt 的语言理解它。

你会说“我有一套常用提示词”； 你会说“我把这个套路固化下来了”； 你会说“这个流程以后都这么跑”。

但当这些东西开始具备下面这些特征时，它其实就已经不只是 prompt 了：

• 能被复用
• 能被共享
• 能被迭代
• 能被约束
• 能被组合进更大的任务流程

到了这个阶段，它更接近的其实就是 Skill。

1）它看起来太像“提示词”

很多人看到 Skill 文件，第一反应往往是：

• 不就是一段说明文案？
• 不就是 system prompt 换了个名字？
• 不就是把 prompt 拆成文件管理？

问题在于，表面形式像 prompt，不代表它的系统作用也只是 prompt。

一个真正有用的 Skill，里面通常不只是角色设定和语气约束，还会包含：

• 这类任务的处理目标
• 默认执行顺序
• 应优先使用的工具与路径
• 哪些情况需要停下来确认
• 输出结果应该长什么样
• 失败时该如何收敛和兜底

所以它不是一句“请你扮演某某专家”就能替代的东西。

2）行业更爱讨论那些更性感的词

现在整个 Agent 领域，大家更愿意聊的是：

• 更强的模型
• 更长的上下文
• 多 Agent 协作
• MCP / A2A / Agent Framework
• IDE Agent / Coding Agent

这些概念都代表能力边界，天然更吸引注意力。
而 Skill 更像执行稳定性建设，没那么炫，但更接近真实落地。

换句话说，大家容易高估“让 Agent 看起来更聪明”的东西，低估“让 Agent 真正把事做稳”的东西。

3）很多团队还没进入“重复任务工程化”阶段

如果 Agent 还停留在 demo、试验、单次对话阶段，Skill 的价值确实不明显。
因为这时候你完全可以靠一段临时 prompt、一次即时纠偏，把结果做得还不错。

但一旦进入下面这些场景，Skill 的价值会立刻变得非常具体：

• 同类任务会被反复执行
• 输出风格和格式需要稳定
• 涉及固定工具链和系统边界
• 不是只有一个人会用这套能力
• 需要逐步积累经验，而不是每次重新教

这时候你很快就会发现：

• 任务不能每次都从头解释
• 规则不能每轮都临时补充
• 工具路径不能全靠模型现场发挥
• 风险边界不能寄希望于模型“自己懂”

这也是 Skill 开始从“可有可无”变成“必须显式存在”的分水岭。

从第一性原理看，Skill 到底在解决什么问题？

如果从第一性原理去看，Skill 本质上不是在解决“怎么把话说得更好听”，而是在解决三个更底层的问题。

说得更直白一点，它解决的不是“模型这一轮怎么答”，而是：

同一类任务，系统以后怎么才能稳定、低成本、少走弯路地重复完成。

1）把经验从人脑里拿出来

一个成熟的操作者，做久了以后一定会积累一套隐性经验：

• 这个任务应该先查什么
• 该优先用哪个工具
• 哪些坑最容易踩
• 哪种输出才算真正完成
• 什么情况下必须先问一句

如果这些经验只存在人脑里，Agent 的表现就会极不稳定。
今天是你在用，你知道怎么引导；明天换个人来问，效果就飘了；后天换个场景，又得重新教一遍。

Skill 的意义，就是把这些原本分散在人脑里的经验，外化、显式化、结构化。

说白了，它是在把“熟练工的手感”，逐步沉淀成“系统可复用的方法”。

2）把任务从一次性对话变成可复用流程

Prompt 更像一次性交代。
你告诉模型：这次要怎么答、按什么格式答、强调什么、避开什么。

但 Skill 不是在回答“这次怎么做”，而是在回答：

以后这类事，通常应该怎么做？

这其实是两个完全不同的问题。

前者是面向单轮生成，后者是面向任务沉淀。
前者追求的是一次结果，后者追求的是长期复用。

所以 Skill 的本质，不是为了让某一次回答更惊艳，
而是为了让某一类任务以后都别再从零开始。

3）把模型自由发挥压缩到可控边界内

Agent 最容易出问题的地方，很多时候不是不会做，而是：

• 做得不稳
• 路径漂移
• 每次处理方式都不一样
• 明明知道一点，却不按你的方式来

这时候问题不在于模型“没有能力”，而在于系统“没有约束”。

Skill 的一个核心作用，就是把这种自由度往回收：

• 优先走哪条路径
• 哪些工具优先，哪些工具谨慎
• 哪些动作需要确认
• 哪些规则不允许越过
• 输出结构必须怎样

所以 Skill 不是在增加模型的想象力，
而是在降低它执行时的波动性。

这就是为什么我越来越觉得：Skill 本质上是一种执行治理，而不只是提示技巧。

Skill 和 Prompt，到底差在哪？

很多人会觉得，Skill 和 Prompt 不就是同一回事吗？
我觉得它们确实有重叠，但解决的问题并不一样。

我现在越来越倾向于用一个更直观的方式来区分它们：

• Prompt 更像一次对话中的战术动作
• Skill 更像一类任务里的作战手册

一个告诉模型这次怎么应对， 一个告诉系统以后遇到这种事通常该怎么推进。

Prompt 更像什么？

Prompt 更像：

• 一次性指令
• 面向当前问题
• 重点是“这一轮回答怎么生成”
• 更依赖即时上下文

它的目标是让模型在当前这一轮里，输出得更准、更像样、更符合要求。

Skill 更像什么？

Skill 更像：

• 任务级封装
• 面向一类重复任务
• 重点是“这类事以后怎么做”
• 自带方法论、工具路径、边界约束和输出规范

所以如果非要用一句话概括，我会这么说：

Prompt 解决“说什么”，Skill 解决“怎么长期稳定地做”。

再进一步一点：

Prompt 是生成层，Skill 是执行层。

一个强 prompt，可以让模型这次回答得很好；
一个强 skill，才能让 Agent 下次、下下次、换个人来用时，依然按一套相对稳定的方法交付结果。

为什么说 Skill 是被低估的 Prompt 工程？

很多人一说 Prompt Engineering，首先想到的往往是这些：

• 角色设定
• few-shot 示例
• 输出格式控制
• JSON schema
• 分隔符和结构化约束

这些当然都属于 Prompt Engineering。
但如果只把 Prompt Engineering 理解成“如何让模型一轮回答更像样”，这个理解其实已经有点窄了。

因为到了 Agent 时代，Prompt Engineering 更重要的一面，开始变成：

• 如何定义任务边界
• 如何规定执行顺序
• 如何约束工具使用
• 如何固化经验路径
• 如何减少行为漂移
• 如何让同类任务长期稳定复现

从这个角度看，Skill 就是 Prompt Engineering 工程化之后的一种产物。

它不是更花哨的 prompt，
而是把 prompt 从“写一句话”推进到了“设计一个任务执行单元”。

这也是为什么我会觉得，Skill 本质上是被低估的 Prompt 工程。
因为很多人还在用“文案优化”的眼光看 prompt，而没有意识到它已经开始进入“执行系统设计”的阶段。

什么时候你真的需要 Skill？

并不是所有任务都值得单独做 Skill。

如果只是偶尔问一次、没有固定步骤、输出也不敏感，那临时 prompt 完全够用。
但如果一个任务开始具备下面这些特征，你就应该认真考虑把它做成 Skill：

• 会被反复执行
• 有比较固定的方法和步骤
• 涉及特定工具或系统
• 对输出格式有明确要求
• 容易犯重复错误
• 有安全边界或确认节点
• 以后可能交给别人或别的 Agent 复用

比如这些场景，就都很典型：

• 每天早报生成
• 爆款文章分析
• Notion / 飞书文档入库
• 飞书任务创建与更新
• 简历分析与岗位匹配
• GitHub issue 跟进
• 文档批量整理

这些任务如果每次都靠临时 prompt，其实隐性成本很高。
因为你会不断重复说明、不断重复纠偏、不断处理风格漂移和边界失控。

一旦把它们沉淀成 Skill，系统的稳定性和复用性会明显提升。

Skill 真正重要的，不是“会不会写”，而是“会不会设计”

讲到这里，很多人会自然地问：

那是不是以后多写几个 Skill 就行了？

我觉得不是。

Skill 的关键不在“数量”，而在“抽象质量”。

一个差的 Skill，只是把糟糕 prompt 文件化。
一个好的 Skill，至少要想清楚下面这些问题：

• 它服务的到底是哪类任务？
• 边界在哪里？
• 默认路径是什么？
• 需要哪些工具？
• 什么情况要停下来问人？
• 输出什么样才算完成？
• 将来怎么维护和迭代？

也就是说，Skill 设计本质上已经不是单纯的文案工作了。
它更像是：

• 任务建模
• 经验封装
• 执行治理
• 人机分工设计

从这个意义上说，未来真正稀缺的，不只是会写 Agent 的人，
而是会把任务抽象清楚、把边界设计清楚、把执行方式沉淀清楚的人。

结语：Skill 不是配件，而是 Agent 落地的一层缓冲器

如果说大模型决定的是 Agent 的理解和生成能力，
那么 Skill 决定的，就是它做事时能不能少走弯路、少犯重复错误、少把系统带回“每次重新教一遍”的原始状态。

所以我越来越觉得，Skill 不是 Agent 世界里的配件。
它更像是连接“模型能力”和“真实交付”之间的一层缓冲器。

很多人低估 Skill，本质上是在低估一件事：

Agent 真正要解决的，从来不只是“会不会回答”，而是“能不能把一类事长期稳定地做好”。

而 Skill，正是把这件事往前推进的一种最朴素、也最有效的方法。

当行业还在兴奋地讨论更强模型、更长上下文、更多工具和更多 Agent 的时候，
我反而越来越觉得，那些真正能把 Agent 用起来、用稳、用久的人，迟早都会回到 Skill 这一层。

因为它决定的，不是 Agent 看起来有多聪明，
而是它最终能不能变成一个可靠的执行系统。

如果一定要把这篇文章压缩成一句话，我会写成这样：

Prompt 决定模型这次怎么说，Skill 决定系统以后怎么做。

再说得更狠一点：

Skill 不是 Prompt Engineering 的边角料，而是 Prompt Engineering 开始走向工程化之后的产物。

我觉得这才是它真正被低估的地方。

因为当一个行业开始从“写好一句 prompt”走向“沉淀一类任务”，它讨论的就已经不只是提示词技巧了，
而是在讨论：

• 如何把经验变成系统资产
• 如何把执行变成可复用能力
• 如何把 Agent 从一次性助手，推进成长期可运营的生产系统

从这个角度看，Skill 不是一个小功能。
它是 Agent 时代里，一个非常朴素、但非常关键的基础设施层。

文末

如果你最近也在频繁用 Claude Code、Codex、Windsurf、Cursor 这类工具，不妨留意一个细节：

你是不是已经不满足于“这次让它答对”，而开始在想：

• 这类事以后能不能都这么做？
• 这个套路能不能沉淀下来？
• 这套方法能不能共享给团队？
• 这一步能不能变成一个稳定能力，而不是临时发挥？

如果你开始问这些问题，其实你已经站在 Skill 这条路上了。

后面我也会继续写这个方向，包括：

• Skill / Workflow / Harness 之间到底是什么关系
• 为什么 Agent 真正走进生产，靠的不是更自由，而是更可控
• AI IDE 为什么会从“一个助手”逐渐演化成“一个多 Agent 工作台”

如果你也在观察这条线，欢迎一起交流。