会用 Skills，AI 才能像工程师

AI 编程工具越来越强之后，开发者遇到的问题反而变得更微妙了。以前大家担心模型不会写代码，现在更常见的问题是：模型写得太快，快到还没搞清楚需求、边界和风险，就已经开始改文件、跑命令、生成测试，然后告诉你“完成了”。

这种体验一开始很爽，但放到真实项目里往往很危险。因为工程项目中最贵的错误，通常不是代码写慢了，而是方向一开始就错了。让 AI 修一个线上 bug，它扫一眼报错，改三个文件，跑一次测试，然后告诉你已经修好。结果原来的报错消失了，但旁边另一个功能被改坏了。

问题不一定是模型不聪明，而是它跳过了工程里最基础、最麻烦、也最关键的一步：先确认问题到底是什么，再决定怎么动手。

这也是为什么 Skills 这个概念会越来越火。GitHub 上 mattpocock/skills 项目曾获得 143766 个 Star，近一周新增 11784 个 Star。这个数据足以说明，开发者已经不满足于单纯让 AI “帮我写代码”，而是希望 AI 能按照更稳定、更可复用的工程流程做事。

但收藏 Skills 不等于会用 AI 编程。就像收藏 Prompt 模板不会自动提升提问能力一样，收藏 Skills 也不会自动提升工程能力。真正有价值的，不是把别人的工作流复制到本地，而是把自己的工程经验、判断标准、失败处理和复用规范，封装成 Agent 能执行的流程资产。

一、Skills 不是 Prompt，而是工作方法的封装

很多人会把 Skills 理解成“更高级的 Prompt”，这其实不准确。Prompt 更像一次性的指令，例如“帮我写一个接口”“帮我解释这段代码”“帮我优化这个 SQL”。它解决的是当下这一次怎么问、怎么说、怎么让模型理解任务。

Skills 更像给 Agent 使用的一份工作手册。它通常不是一句话，而是一个包含说明、流程、脚本、参考资料和输出规范的文件夹。Agent 不会一开始就把所有内容塞进上下文，而是在需要时按需加载，这种方式也常被称为 progressive disclosure，也就是渐进式披露。

可以把一个 Skill 理解成下面这种结构：

skills/
  diagnosing-bugs/
    SKILL.md
    checklist.md
    scripts/
      reproduce.sh
      regression-test.sh
    resources/
      bug-template.md

其中，SKILL.md 负责告诉 Agent 什么时候使用这个 Skill、需要遵循哪些步骤、最终输出什么格式；scripts 可以放自动化脚本；resources 可以放模板、规范或参考文档。

Skills 的意义不是让 AI “知道更多”，而是让 AI “按某种流程做事”。

这就是 Skills 和 Prompt 的关键区别：Prompt 更偏临时表达，Skills 更偏长期复用；Prompt 解决单次任务，Skills 固化稳定流程。一个好的 Prompt 可以让模型这一次回答得更好，而一个好的 Skill 可以让 Agent 在同类任务中持续保持稳定表现。

二、收藏 Skills 没用，真正有用的是封装流程

为什么收藏了 100 个 Skills，还是不一定能用好 AI 编程？因为收藏下来的往往是别人的工作方法、别人的工程习惯、别人的团队规范。

比如 diagnosing-bugs 这类 Skill，核心流程通常可以概括为：

reproduce → minimise → hypothesise → instrument → fix → regression-test

也就是先复现问题，再缩小范围，然后提出假设、增加观测手段、修复问题，最后补回归测试。这个流程看起来很普通，甚至有点“基础”，但它正是经验丰富的工程师修 bug 时最关键的方法。

很多 AI 修 bug 翻车，不是因为模型完全不会写代码，而是因为它没有被约束在正确流程里。它看到报错就猜原因，猜到原因就改代码，改完代码就认为完成。但真实工程里，bug 修复必须回答几个问题：问题是否稳定复现？影响范围是否足够小？修复方案是否验证过？有没有补回归测试？是否影响旁边功能？

如果这些问题没有回答清楚，AI 生成的修改越快，返工风险越高。

所以 Skills 本质上是流程的放大器。如果流程清晰，它会放大清晰；如果流程混乱，它也会放大混乱。一个没有工程判断的人，即使装了很多 Skills，也很难判断 Agent 每一步做得对不对。它复现充分吗？最小化范围合理吗？假设有效吗？观测手段够吗？回归测试有没有覆盖关键路径？这些仍然需要开发者判断。

三、五类 Skills 背后，是五种工程判断

真正有价值的 Skills，不是让 AI 写得更快，而是让 AI 在关键节点慢下来、想清楚、按流程执行。

第一类是需求澄清型 Skill。它的价值不是马上写代码，而是在动手前追问关键问题。比如要做一个用户邀请返利功能，Agent 不应该直接生成数据表和接口，而应该先确认：邀请关系是否支持多级？退款后返利如何处理？自己邀请自己如何防刷？老用户能否补绑邀请人？是否需要风控策略？这些问题不问清楚，代码写得越快，返工越快。

第二类是 bug 诊断型 Skill。它强调“别猜，先复现”。很多 AI 修 bug 时喜欢直接根据报错定位代码，但真实工程里，最危险的就是没有复现、没有缩小范围、没有假设验证就开始修。可靠的 bug 修复流程，必须包含复现步骤、观测手段和回归测试。

第三类是 TDD 型 Skill。它通常遵循 red-green-refactor 循环：先写失败测试，再实现最小功能，最后重构。这个流程真正限制的不是人，而是 Agent。因为 Agent 很容易同时写实现和测试，最后测试虽然全部通过，但只是证明“自己写的代码能跑”，并没有测到真正会坏的地方。

第四类是交接型 Skill。长上下文不是无限资源。在持续很多轮对话之后，Agent 往往会逐渐遗忘早期决策，输出质量开始下降。交接型 Skill 的价值，是把当前任务状态压缩成交接文档，包括哪些已经完成、哪些还没完成、关键决策是什么、风险点在哪里，让下一轮 Agent 可以继续接手，而不是在混乱上下文里硬撑。

第五类是代码设计型 Skill。AI 很容易把项目越改越碎：新增功能时到处贴逻辑，文件越来越多，模块越来越浅，边界越来越模糊。代码设计型 Skill 的价值，是在 Agent 动手改代码之前，先让它思考模块边界、接口暴露、测试方式和长期维护成本，避免项目表面能跑，长期却越来越难维护。

四、Prompt、Skills、MCP 和 Agent 不要混着讲

很多开发者现在容易把 Prompt、Skills、MCP、Agent 混在一起说，导致概念越来越乱。其实可以简单理解成四句话：

Prompt：告诉模型这次要说什么
Skills：告诉 Agent 这类任务应该怎么做
MCP：告诉 Agent 可以连接哪些外部工具
Agent：负责规划、调用工具并执行任务

Prompt 适合临时任务，不适合承载复杂流程。Skills 适合固化流程、规范和检查清单，但它不负责连接外部系统。MCP 解决的是数据库、文件系统、第三方 API 等外部工具访问问题，但它不会告诉 Agent 应该按什么流程干活。Agent 则是执行主体，如果没有好流程，它也可能乱干。

在企业级 AI 编程场景中，模型、工具和流程通常还需要统一管理。团队如果需要同时调用不同代码模型、控制 API Key、统计成本、切换任务模型，可以借助 koalaapi 这类大模型 API 聚合平台作为统一入口，减少每个开发者在本地重复维护多套调用配置的问题。

五、Skills 最大的坑：它不能替代工程能力

Skills 很有用，但它不是外挂。不会因为装了 diagnosing-bugs 就突然会修 bug，也不会因为装了 codebase-design 就突然会做架构。它可以让 Agent 按流程执行，但判断流程是否正确、输出是否合格，仍然是开发者的责任。

更危险的是，质量差的 Skill 比没有 Skill 更糟糕。如果没有 Skill，Agent 至少还有自由发挥空间；如果有一个错误 Skill，它会稳定地按照错误流程执行。这就像把错误的团队规范写进自动化系统里，执行越稳定，问题越严重。

安全风险也不能忽略。Skills 本质上是文件夹，里面可能包含脚本、命令和文件操作。来路不明的 Skill 不应该直接运行，因为这不是在收藏一张壁纸，而是在给 AI 一个可以执行动作的工作包。

对于团队来说，Skills 应该像代码一样进入版本管理、评审和安全扫描，而不是随手从网上复制到 .claude/skills 目录。尤其是包含 shell 脚本、文件操作、网络请求、权限修改的 Skill，更应该经过检查后再投入使用。

六、普通开发者应该怎么开始？

不要一上来收藏 100 个 Skills。更实用的方法是：找一个每周重复 3 次以上的任务，把它封装成自己的 Skill。

判断一个任务值不值得封装，可以看三个条件：每周做 3 次以上、步骤基本固定、做错了有后果。满足其中两个，就值得封装；如果只是偶尔用一次，临时 Prompt 就够了。

一个最小可用的 Skill 不需要很复杂。先写清楚 5 个步骤、3 个检查点、1 个输出模板，就已经足够起步。

比如可以先从代码审查 Skill 开始：

# code-review-skill

## 适用场景
当用户要求检查代码质量、潜在 bug 或重构风险时使用。

## 执行步骤
1. 先阅读变更文件和相关上下文
2. 判断是否影响核心业务路径
3. 检查异常处理、边界条件和数据一致性
4. 输出高风险问题和建议修改点
5. 给出是否需要补充测试的判断

## 检查点
- 是否存在空值、并发、权限或状态异常
- 是否影响已有接口行为
- 是否需要补充回归测试

## 输出格式
- 风险等级
- 问题位置
- 原因说明
- 修改建议
- 是否必须修复

这类 Skill 虽然简单，但它能把平时脑子里的判断过程固定下来。跑几次之后就会发现，真正有价值的不是网上整理好的文件，而是把自己的经验变成了 Agent 能执行的资产。

七、AI 编程的差距，正在从模型转向流程

Prompt 时代，大家比的是谁更会提问；Skills 时代，大家比的是谁更会整理自己的工作流。模型能力会越来越强，但模型越强，越会暴露另一个问题：需求是否想清楚了？流程是否稳定？判断标准是否明确？失败后是否知道如何处理？

未来 AI 编程的差距，不只在模型层面，更在流程层面。能够把工程经验拆解成步骤、标准、检查点和失败处理的人，会更容易把 AI 变成生产力工具；只会收藏 Prompt、收藏 Skills、收藏热门项目的人，最终大概率还是会停留在“帮我写个代码”的浅层用法。

所以，真正值得做的不是继续收藏更多 Skills，而是选一个每周重复三次以上的真实任务，把它写成第一个可复用 Skill。当它真正减少返工、减少废话、稳定复用时，AI 编程才算进入下一阶段。