AI Skill 工程化

很多 AI 新手都会遇到一个问题，那就是同样的需求，AI 每次的实现方式都不一样。

比如你让 AI 写一篇技术文章：

第一次，它老老实实写到 draft。
第二次，它直接发到了正式目录。
第三次，frontmatter 丢了。
第四次，文章风格和之前完全不一样。

反复使用几次之后，你就会开始寻找一种能让 AI 稳定执行任务的方法，于是，Skills 出现了。

Prompt 是一次性指令，Skill 是长期沉淀的经验。

AI Agent 底层的大模型很重要，但是如果几个大模型能力差异不大的时候，拉开差距的可能就是它背后的 Skills 系统了。

一、Skills 是什么

Skills 是给 AI 的“专项教程”，它不是工具本身，也不只是几句长期提示词，而是一份可复用的任务说明：

什么时候使用
做这类任务的步骤
可以参考哪些文件
可以调用哪些工具
交付物应该是什么
怎么检查结果

比如一个写博客的 Skill：

适用场景：用户要求写技术文章、优化草稿、整理博客。

流程：
1. 先阅读现有文章风格。
2. 确认文章结构。
3. 写入 client/draft。
4. 保留 frontmatter。
5. 跑 Markdown 校验。
6. 返回文件路径和校验结果。

这样下次用户说“帮我写一篇 MCP 科普文”，AI 就会沿着这套流程做，减少很多临场发挥的可能。

二、为什么需要 Skills

大模型本身并不稳定。

它可能遗漏步骤、忘记约束、风格漂移，也可能在长 prompt 里抓不住重点。

所以 AI 想进入真实项目，不能只靠一次性 prompt。

人类公司也不会只靠每个人临场发挥，它们依赖 SOP、模板、规范、审核机制和最佳实践来保障业务的正常运行。

Skill 就是 AI 世界里的 SOP。

它把“怎么做一类任务”从 prompt 里抽出来，变成一份可以复用、可以维护、可以被团队共享的流程。

这也是 AI Agent 会走向 Skill 化的原因，Agent 不只是要会调用工具，还要能稳定地完成任务。

一个不会使用 Skill 的 Agent，很容易退化成“高级版聊天机器人”。

它也许能完成任务，但无法保证流程稳定、结果一致、团队协作可控。

进入生产环境之后，Agent 会更加需要长期规则、固定工作流、可复用经验和任务级能力沉淀。

这就是 Skill 化。

三、Prompt 工程正在代码化

过去很多人把 prompt 当成聊天技巧。但在 AI 工程里，prompt 正在被拆成更工程化的几部分：

Prompt：这一次要做什么。
Rules：长期要遵守什么。
Skills：这类任务怎么做。
MCP：可以调用什么工具。
Memory：哪些经验需要长期记住。

换句话说，Prompt 工程正在“代码化”。

与其把所有要求塞进一段超长 prompt，不如把规则、工具、流程、记忆放到合适的位置。

Skill 就是其中很关键的一块，它负责把人的经验变成 AI 可重复执行的工作流。

未来很多 AI 系统里，Prompt 可能会退到更靠后的位置。

Workflow、Skills、Memory、Tools 和 Rules 会变得更重要。

四、一个 Skill 通常长什么样

不同工具的细节不完全一样，但一个好的 Skill 通常包含三部分：

部分	作用
元信息	Skill 名称、描述、适用场景
工作流	做这类任务的步骤
资源	模板、脚本、示例、参考文档

最常见的形式是一个 SKILL.md：

---
name: blog-writing
description: 用于撰写、编辑或发布博客草稿。
---

# 博客撰写

## 工作流程

1. 阅读已有文章以匹配风格。
2. 不确定时确认文章结构。
3. 在 `client/draft` 下撰写草稿。
4. 保留 frontmatter。
5. 运行 Markdown 校验。
6. 汇报文件路径与校验结果。

## 避免

- 除非要求，不要直接发布到 `client/article`。
- 不要编造个人经历。

它看起来像文档，实际用途更接近一份给 AI 的任务操作手册。

五、主流 AI 编程工具里的 Skills

Claude Code、Codex、Cursor 等 AI 编程工具，都已经支持类似 Skills 的能力。

虽然他们的写法、目录都不完全一样，但方向是一致的，那就是把长期工作流沉淀下来。咱们也不用太纠结目录差异，更值得关注的是这个趋势：

AI 编程正在从“即时对话”
走向“长期能力系统”，能不能稳定完成工作才是真正重要的能力。

实际生产中先按照自己常用的编程工具写一份，先将内容沉淀下来就行了，如果以后涉及到工具的更换再做一些适配即可。

最近 AI 编程领域的概念比较多，而且基本上都是几个头部领头公司新发明出来的，可能有些概念有一些理解差异，咱们不需要完全领悟有个大致认知就行了，下面是我对这些概念的一些理解。

六、Skills 和 Rules 的关系

Rules 像公司制度，Skills 像岗位培训。

对比	Rules	Skills
解决问题	什么该做，什么不能做	某类任务怎么做
关注点	约束、边界、偏好	流程、方法、交付标准
例子	不要改无关代码、不要读 `.env`	如何写文章、如何做代码审查

比如：

Rule：不要直接发布文章到 client/article。
Skill：写文章时先确认结构，再写入 client/draft，最后跑校验。

Rules 规定边界，Skills 提供方法。

七、Skills 和 Workflow 的关系

AI 编程里，还有一个经常和 Skills 一起出现的概念：Workflow。

它们看起来很像，但其实是两个层面的东西。

Workflow 更关注：这件事应该按什么顺序执行。

比如写文章可以有一条 Workflow：

确认主题 -> 查资料 -> 列大纲 -> 写正文 -> 校验 -> 发布

它本质上是在描述任务流程。

而 Skill 更像对某类能力的封装。

除了流程，它通常还会包含：

什么时候触发
需要哪些输入
可以调用哪些工具
输出结果应该是什么
怎么验证结果

所以可以这样理解：

Workflow 是任务编排。
Skill 是能力封装。

或者：

Workflow 是 Skill 里的流程骨架。
Skill 是 Workflow + 触发条件 + 工具资源 + 验收标准。

简单任务里，一个 Skill 可能只对应一条 Workflow。

复杂任务里，一个 Skill 可能包含多条 Workflow。比如“写作 Skill”里，可以同时包含：

新文章写作
草稿优化
发布检查

几类不同流程。

而当系统进一步复杂后，Workflow 往往会被单独抽出来，成为更显式的编排层。

这时候：

Skill 更像“能力模块”。
Workflow 更像“任务调度系统”。

比如：

Workflow：
生成周报 -> 调用数据分析 Skill -> 调用图表 Skill -> 调用总结 Skill -> 发布

Skill 负责“会做什么”。

Workflow 负责“先做什么、后做什么”。

比较有意思的是，随着系统越来越复杂，你会发现：

Workflow 和 Skill 并不是严格的包含关系，而是不同维度的抽象。

在复杂系统里，它们甚至会互相嵌套、互相调度。

这时候：

Workflow 会越来越像“调度层”
Skill 会越来越像“能力层”

八、Skills 和 MCP 的关系

MCP 像给 AI 配工具箱，Skill 像老师傅教它怎么干活。

MCP 让 AI 获得工具，Skill 才让 AI 开始像“员工”。

这两个概念很容易混，但边界其实很清楚：

MCP 解决“能做”。
Skill 解决“稳定做”。

比如

Skill：先读取Jira、飞书文档，再结合 GitHub 代码和数据库变更 生成项目周报。
MCP：读取 Jira、飞书、GitHub、数据库。

只接上 MCP，并不等于 Agent 就能稳定工作。MCP 给了工具，但工具怎么组合、什么时候调用、结果怎么验收，还需要 Skill、Rules、Workflow 这些东西来约束。

九、Skills 和 AGENTS.md 的关系

如果你使用过 Claude Code 你肯定见过这两个文件，AGENTS.md 和 CLAUDE.md，他们更像项目级协作说明，和项目中常见的readme.md功能类似，只不过前者是给 AI 看的，后者是给人看的。

和 readme 一样，它们通常放在项目根目录，用来告诉 AI：

项目怎么启动
测试怎么跑
目录结构是什么
编码规范是什么
哪些文件不要动

区别可以这样看：

文件/机制	更适合放什么
`AGENTS.md`	给 Codex、OpenAI 系工具看的项目级协作说明
`CLAUDE.md`	给 Claude Code 看的项目级协作说明
Rules	项目内长期约束和偏好
Skills	某类任务的专项流程
MCP	可调用的外部工具和数据源

请注意，不要把所有内容都塞进一个地方。

项目长期规则可以放 AGENTS.md / CLAUDE.md / Rules；

某类任务的详细流程可以放 Skills；

真实工具能力则可以交给 MCP。

十、一个好 Skill 怎么写

好的 Skill 不需要很长，但要具体。

建议包含：

触发场景：什么时候使用这个 Skill。
执行步骤：按什么顺序做。
输入输出：需要什么信息，最终交付什么。
工具和资源：可以用哪些脚本、模板、文件。
验证方式：怎么确认结果可用。
注意事项：哪些事不要做。

少写这种：

请认真完成任务，输出高质量结果。

多写这种：

写博客时先读取 `client/article` 中 2-3 篇相近文章。
草稿写入 `client/draft`。
不要直接发布到 `client/article`。
完成后运行 `npm run verify:blog-md`。

它不负责提醒 AI “认真一点”，它要解决的是步骤稳定性。

十一、总结

AI 编码关键不在于把 prompt 写得越来越长，更重要的是如何把人的经验，沉淀成 AI 可重复执行的能力。

Skills 就是第一代 AI 工作流的雏形。

未来很多团队积累的壁垒，可能不只在模型本身，也在这些东西上：

有哪些 Skills
Skills 怎么编排
Skills 如何连接 MCP
Skills 如何沉淀业务经验

这也是 AI 工程开始变得像软件工程的地方。

过去的软件工程，一直在把人的操作流程程序化。

今天的 AI 工程，正在把人的经验和工作方式 Skill 化。

未来很多团队的资产，可能不只是代码仓库，还包括他们积累了多少可复用的 AI Skills。