老王是某大厂的一位高级工程师，一头秀发直垂肩背，人不谈不上英俊，但气宇不凡。

他的第一个问题是：“你简历上写的熟悉 Agent Skills，那你说说 Skills 和 Prompt 到底有什么区别？”

瞅着老王的秀发出了神，以至于那一刻我脑子一片空白，支支吾吾说了句“Skills 就是封装好的 Prompt”。

话音刚落，回过神的我明显感觉老王不是很满意。

但老王很有耐心，没有 KPI 我，仍然给我聊了 35 分钟 Skills 的本质。

说真心话，遇到这样的面试官，真的打心眼里佩服，不会因为一时的得失就挂你，反而会引导你，让你敞开心扉地表达自己。

感恩。

全文比较肝，大家最好做好收藏夹吃亏，哦不，吃灰的准备。😄

01、Skills 和 Prompt 的本质区别

老王： 能具体说说吗？

好的，王哥。Prompt 就像你跟 AI 的一次对话，你说完就完了。下次再想用同样的能力，你得重新说一遍，或者从聊天记录里翻出来复制粘贴。

Skills 不一样。它是把一类问题的解决方案固化下来，变成一个可以反复调用的模块。就像写代码时封装的工具类，一次开发，到处复用。

老王： 那不就是 Prompt 的模板化吗？

王哥，不只是模板化。模板化是静态的，Skills 是动态的、可进化的。

举个例子。假设我们经常让 AI 帮做代码审查。用 Prompt 的方式，每次都要说：“帮我审查这段代码，关注安全性、性能、可读性，按照阿里巴巴 Java 规范。”

用 Skills 的方式，变成了把这套审查逻辑封装成一个 Skill。下次直接说“用 code-review Skill”，AI 就知道要做什么、怎么做、做到什么程度。

更重要的是，这个 Skill 可以不断优化。我们发现漏掉了并发安全检查，就加进去；团队规范更新了，就同步更新。所有用这个 Skill 的人，都能立刻享受到改进。

老王： 有点意思。那你觉得 Skills 的核心价值是什么？

王哥，可以用三个词：沉淀、复用、进化。

沉淀是把个人经验变成团队资产。复用是让好的实践快速传播。进化是让能力持续迭代升级。

这三点 Prompt 都做不到，或者说做得很差。

老王： 能举个例子说明“进化”吗？

当然。我们小组早期有一个代码审查的 Prompt，大概是这样的：“帮我审查这段代码，关注安全性和性能。”

用了一段时间后，我们发现总是漏掉并发安全问题。于是 Prompt 改成了：“帮我审查这段代码，关注安全性（包括并发安全）、性能、代码可读性。”

又过了一段时间，小组规范更新了，要求所有方法必须有 JavaDoc 注释。Prompt 又得改。

问题是，这个 Prompt 可能散落在各个同事的笔记里、聊天记录里。你改了你的版本，别人还在用旧版本。团队执行的标准是不统一的。

用 Skills 就不一样了。把审查逻辑封装成 Skill，发现漏掉并发安全，就更新 Skill；规范更新了，就同步更新 Skill。所有用这个 Skill 的人，立刻就能用上最新版本。

这就是进化能力。Prompt 是静态的，Skills 是动态的、可迭代的。

02、Skills 在团队协作中的价值

老王： 你刚才提到了团队资产，能展开说说 Skills 在团队协作中的价值吗？

王哥，这正是我觉得 Skills 最有价值的地方。

传统的团队协作是这样的，老带新，口口相传。一个资深工程师积累了一套代码审查的经验，新人来了，他得一对一地教，教完还不一定能记住。

有了 Skills，这套经验可以被封装成一个 Skill。新人来了，直接用就行。资深工程师的经验，以 Skills 的形式在团队里快速传播。

老王： 但这和文档有什么区别？写个代码审查规范文档不也一样吗？

文档是给人看的，Skills 是给 AI 用的。这是本质区别。

人看文档，需要理解、记忆、应用。理解有偏差，记忆有遗漏，应用有变形。最后每个人执行出来的效果都不一样。

Skills 直接给 AI 用，AI 的执行是确定的。你定义了什么，AI 就做什么，不会走样。

老王： 那团队里每个人都用同一个 Skill，会不会导致思维僵化？

恰恰相反，Skills 让团队有更多精力去做创造性工作。

是这样，代码审查这种重复性工作，本来就不需要每个人有自己的“创意”。规范就是规范，按照最好的实践来就行。

但 Skills 节省下来的时间，可以用来做真正有创造性的事情。比如设计更好的架构、解决更复杂的技术难题。

而且 Skills 本身也是可以迭代的。团队在实践中发现更好的做法，可以更新 Skill，所有人立刻受益。这是一种良性的进化机制。

老王： 你们小组现在有多少个 Skills？

王哥，我们小组这半年时间下来，沉淀了 20 多个我认为比较精华的 Skills，覆盖代码审查、文档生成、测试用例设计、技术方案评审等场景。

最常用的是代码审查 Skill。以前人工审查一个 PR 平均要 60 分钟，现在用 Skill 辅助，30 分钟就能完成，而且遗漏的问题更少。

老王： 30 分钟是怎么做到的？

分两步。第一步，AI 用 Skill 自动扫描代码，找出潜在问题。这一步大概 10 分钟。第二步，人工 review AI 的扫描结果，确认问题、补充上下文。这一步大概 20 分钟。

以前人工审查，要从头到尾读代码，理解逻辑，再找问题。现在 AI 帮你把问题都标出来了，你只需要判断“这是不是真问题”、“严重程度如何”。

而且 AI 不会疲劳。人工审查到第 5 个 PR 的时候，注意力已经涣散了，容易漏掉问题。AI 不会，每个 PR 都是同样的标准。

老王： 那 AI 会不会误报？

会，但比例不高。大概 2% 的 AI 提示是误报。但即使这样，也比人工审查遗漏问题要好。

而且随着 Skill 的迭代，误报率会越来越低。我们发现某类误报比较多，就在 Skill 里加规则排除。这是持续优化的过程。

03、Skills 的工作原理

老王： 你刚才说 Skills 是动态加载的，能解释一下原理吗？

好的。这涉及到 AI 的上下文窗口限制。

我们知道 AI 的上下文窗口是有限的，比如 Claude 是 200K。如果把所有的 Skills 都塞进去，窗口很快就满了，AI 还没开始干活就没资源了。

所以 Skills 采用了一种叫“渐进式披露”的架构。

老王： 渐进式披露？

王哥： 对。简单说就是：不是让 AI 知道更多，而是让 AI 在恰当的时间知道恰当的事。

具体分为三步：

第一步，发现阶段。AI 启动时，只加载所有 Skills 的元数据，比如名称、描述、触发关键词。这就像图书馆的目录，只占很小空间。

第二步，语义匹配。当用户输入问题，AI 会根据语义匹配相关的 Skills。比如你问“帮我审查这段代码”，AI 就会匹配到代码审查 Skill。

第三步，执行阶段。匹配成功后，才会加载这个 Skill 的完整内容。这时候 AI 才真正“看到”详细的指令和约束。

老王： 这个匹配过程是怎么实现的？

基于向量相似度计算。

每个 Skill 的元数据会被转换成向量，用户输入的问题也会被转换成向量。然后计算相似度，相似度高的就是匹配的 Skill。

这个过程很快，用户基本感知不到延迟。而且只有匹配到的 Skill 才会加载完整内容，其他的只占几个 token 的元数据空间。

这就是为什么你可以有几十个甚至上百个 Skills，却不用担心上下文爆炸。

老王： 你说 Skills 可以迭代进化，那创建一个 Skill 的过程是怎样的？

王哥。我正好拆解过 Claude Code 内置的 create-skill 源码，它整个创建流程分 6 步：

第一步，Understanding——先搞清楚你要做什么。系统会主动问你：这个 Skill 解决什么问题？有哪些使用场景？触发条件是什么？很多人一上来就写，结果写出来的东西根本不符合实际需求。

第二步，Planning——把需求拆解成可复用的资源类型。哪些功能需要脚本实现，放 scripts/ 目录；哪些是参考文档，放 references/。这步本质上就是在做架构设计。

第三步，Initializing——调用 init_skill.py 脚本，自动生成标准目录结构和模板文件，每个需要填写的地方都有 TODO 标记。

第四步，Editing——填充具体内容。这是最耗时的环节，也是决定 Skill 质量的关键。description 必须写清楚触发条件，SKILL.md 不超过 500 行。

第五步，Packaging——调用 package_skill.py 打包。打包前要经过六重验证：文件存在性、Frontmatter 格式、YAML 解析、必填字段、命名规范（必须是 hyphen-case）、长度限制（description 不超过 1024 字符）。全部通过才能打包成 .skill 文件。

第六步，Iteration——根据实际使用反馈持续优化。

老王： 六重验证，这个设计挺严格的。

是的，就像代码提交前的 CI 检查，在最后一刻把关。而且整个流程有个很精妙的设计叫显式复杂、隐式简单——底层涉及 3 个 Python 脚本、数十个函数调用，但用户体验是流畅的、引导式的。我们不需要知道背后发生了什么，按提示一步步走就行。

04、Skills 与 MCP 的关系

老王： 去年，MCP 很火，你觉得 Skills 和 MCP 是什么关系？

我觉得它们是互补的，不是竞争关系。

MCP（Model Context Protocol）解决的是 AI 与外部系统的连接问题。比如让 AI 调用 GitHub API、查询数据库、操作文件系统、打开浏览器等。

我就经常用 Chrome 的 Devtools MCP 让 AI 进行自动化测试。

Skills 解决的是 AI 的能力封装问题。比如让 AI 具备代码审查的能力、文档生成的能力、技术方案评审的能力。

老王： 能打个比方吗？

可以。MCP 像是给 AI 装上了机械臂，让它能接触外部世界。Skills 像是给了 AI 使用说明书，让它知道怎么做事。

两者结合起来，AI 才能真正成为生产力工具。

老王： 那未来会是一个什么样的格局？

我觉得会有两个趋势。

第一个趋势是 Skills 标准化。现在每个团队的 Skills 格式可能都不一样，未来可能会出现行业标准，就像 npm、pip 一样。

第二个趋势是 Skills 商店化。个人开发者可以把 Skills 发布到商店，其他人付费或免费使用。这会催生一个新的生态。

老王： 这个观点很有意思。那你觉得未来程序员的核心竞争力是什么？

王哥： 我觉得是三个能力。

第一，问题定义能力。AI 能帮我们解决问题，但前提是我们要能准确定义问题。很多人连自己想要什么都说不清楚，AI 再强也没用。

第二，系统设计能力。AI 能写代码，但架构设计、模块划分、接口定义，这些还是需要人来把控。AI 是执行者，人是设计者。

第三，持续学习能力。技术更新这么快，今天有用的 Skills，明天可能就过时了。保持学习，才能保持竞争力。

Skills 恰恰能帮助程序员提升这三个能力。它帮我们节省时间，让我们有更多精力去思考问题定义、系统设计。

05、如何设计一个好的 Skill

老王： 假设我现在要你设计一个“技术方案评审”的 Skill，你会怎么设计？

首先，明确这个 Skill 的目标：帮助团队快速评审技术方案，发现潜在风险，给出改进建议。

然后，定义评审维度：

• 可行性：技术方案是否可行，有没有技术难点
• 性能：是否满足性能要求，有没有瓶颈
• 安全：有没有安全风险，数据保护是否到位
• 可维护性：代码是否易于维护，文档是否清晰
• 成本：实现成本是否合理，有没有更优方案

老王： 这些维度会不会太通用？

有一点，所以还需要根据具体业务定制。比如金融系统要重点关注安全，电商系统要重点关注性能和并发。

接下来，定义输出格式：

## 方案概述
[一句话概括这个方案]

## 评审结果
- 可行性：✅/⚠️/❌ [说明]
- 性能：✅/⚠️/❌ [说明]
- 安全：✅/⚠️/❌ [说明]
- 可维护性：✅/⚠️/❌ [说明]
- 成本：✅/⚠️/❌ [说明]

## 主要风险
1. [风险描述]
2. [风险描述]

## 改进建议
1. [建议]
2. [建议]

## 总体评价
[优秀/良好/需改进]

老王： 这个 Skill 怎么使用？

在对话中输入：“用 tech-review Skill 评审这个方案：[粘贴方案内容]”

AI 会自动加载 Skill，按照定义的维度和格式输出评审结果。

老王： 如果评审结果不满意怎么办？

可以迭代优化 Skill。比如发现总是漏掉某个风险点，就在 Skill 里增加对应的检查项。发现输出格式不够清晰，就调整格式。

Skill 是活的，不是死的。随着使用，它会越来越符合团队的需求。

老王： 设计 Skill 时，约束程度怎么把握？太严会僵硬，太松会失控。

王哥，这就涉及到一个核心设计理念——自由度分级。

高自由度：纯文本指令，适用于有多种有效方法的场景。比如用合适的方式优化这段代码，AI 可以自由发挥。

中自由度：伪代码或带参数的脚本，有推荐模式但允许变化。比如技术方案评审，定义好维度，但允许根据项目特点调整权重。

低自由度：特定脚本，少量参数，适用于需要严格一致性的操作。比如代码格式化，必须用指定的 format_code.py，不允许修改格式规则。

06、Skills 如何提升职场竞争力

老王： 最后一个问题。你觉得掌握 Skills 开发能力，对程序员的职场竞争力有什么帮助？

我觉得是三个层面的提升。

第一层，效率提升。 会用 Skills 的程序员，工作效率明显高于不会用的。同样的任务，别人 2 小时，你 20 分钟，这就是竞争力。

第二层，经验沉淀。 普通程序员解决问题，解决完就完了。会用 Skills 的程序员，会把解决方案沉淀下来，变成可复用的资产。这是从“解决问题”到“沉淀方法论”的跃迁。

第三层，影响力扩大。 你写的 Skills 被团队使用，你的经验以 Skills 的形式传播。这比写文档、做分享更有穿透力，因为 Skills 是直接可用的。

老王： 如果让你给初学者一个建议，你会说什么？

不要贪多，从一个小场景开始。

很多人一开始就想写一个“万能”的 Skill，结果写得很复杂，用起来也不顺手。

我的建议是：先观察你工作中重复做的事情，选一个最简单的，把它封装成 Skill。比如“生成 Git 提交信息”、“格式化代码注释”。

用起来了，再慢慢迭代，增加功能。 Skills 是长出来的，不是设计出来的。

ending

面试结束了，但关于 Skills 的思考还在继续。

Skills 不是什么高深的技术，它只是一种新的工作方式。把重复的事情交给 AI，把创造性的工作留给自己。

【技术的本质不是工具，而是思维方式的升级。Skills 让我们重新思考：什么是值得做的，什么是可以交给 AI 的。】

如果你还没开始用 Skills，现在就是最好的时候。从一个小场景开始，写你的第一个 Skill。

别担心写得不好，Skills 是迭代出来的。先用起来，再慢慢优化。

我们下期见。