AI编程工具里的 Skill、MCP、Workflow、

---

你给AI写了一堆规则，它反而变蠢了？我踩过的坑，一次给你说清楚

你猜怎么着？我差点把键盘砸了。

那天我对着Cursor，气得脸都绿了。我辛辛苦苦写了十几条规则——技术栈、命名规范、目录结构、注释要求、Git提交格式……洋洋洒洒一整页。然后我让它“帮我把这段代码重构一下”，你猜它怎么回？

它先问我：“你确定要改吗？要不要我先建个分支？”

我说：“你直接改吧。”

它又来了句：“为了避免风险，我先给你写个修改计划你看看？”

我：？？？

那一刻我突然理解了什么叫“搬起石头砸自己的脚”。我花大把时间配这配那，最后发现——不是AI不行，是我自己把概念混着用了。

你看，是不是特眼熟？为什么别人说MCP多牛逼，你配完之后AI还是记不住你的代码习惯？为什么一口气装上七八个Skill，AI反而不知道该先干哪个？

这些坑，我一个不落全踩过。

今天这篇，我不说废话。咱们就掰开揉碎，把五个概念彻底给你讲清楚。

---

Rules：你以为越多越好？错！只写“底线级”的

说到这个我就想叹气。我以前觉得，规则嘛，越细越好，AI才不会跑偏。

结果呢？它跑偏是没跑偏——它压根不敢跑了。

Rules最大的价值是防呆——你不在的时候，AI不会做出你绝对不允许的事。

想想看。你不是在教AI怎么干活，你是在给它划禁区。“永远不要删除文件”“不要自动修改package.json”“别往生产环境推代码”——就这种级别的，才值得写进Rules。

写多了呢？AI就只顾着“不犯错”，顾不上“干正事”了。

我现在只写3条，放在工程根目录的.cursorrules或.windsurfrules里：

1. 不允许AI修改锁文件

2. 删除文件前必须确认

3. 所有API Key都用环境变量，不许硬编码

够了。再多，AI就废了。

---

Memories：这才是让AI真正“记住你”的东西

很多人把Rules和Memories混着用，一锅乱炖。

有个事儿我到现在还记得。有一次我在Cursor里写React组件，连着干了三天。第四天新开了一个对话，你猜怎么着？AI居然还记得我上次说的“这个模块不要用class组件，用hooks”。

我当时愣住了。后来才反应过来，这是Cursor的Memories在自动记录。

Memories是AI的工作笔记。 你随口说一句“别用any”，或者“数据库连接池配20个”，AI就自动记下来。下次新对话，它翻出来接着用。

不用你手动写。写也行，但最好让它自己积累。

我项目里的Memories长什么样？举个例子，有一次我抱怨“每次生成tsx文件都要手动补一下CSS modules的声明”，AI记住了。后面我新建组件，它自动在文件头加了一行declare module '*.module.css'。

挺神奇的吧？前提是你得允许它自动捕捉。

Rules和Memories的区别，一句话：Rules是你逼着AI必须听，Memories是AI自己记住了你的事。

---

MCP：让AI从“嘴炮”变成“动手”

MCP刚出来的时候，我看了一堆文章，愣是没懂。

直到我亲手试了一个MCP服务器——让AI直接读本地SQLite数据库。

那天我有个本地小项目，数据库文件在data/db.sqlite。我装了sqlite的MCP服务器，然后跟Cursor说：“帮我查一下最近一周的订单，按金额排序。”

AI直接连上数据库，查了，返回结果，还附了一句：“你这个订单表缺了索引，要加吗？”

我当时就一个感觉：以前AI是嘴炮，现在AI是真的能干活了。

MCP就是给AI装上了手脚。它能读你本地的文件，连接你的数据库，操作你的GitHub仓库，还能发飞书消息——前提是你给它配了对应的MCP服务器。

但有个误区我得说清楚：MCP不是知识库。

很多人把一堆文档塞进MCP，指望AI能“记住”。不对。那是Memories该干的事。MCP只管“能不能做”，不管“记不记得”。

我现在的配置：一个GitHub MCP（用来操作仓库）、一个文件系统MCP（读写本地文件）、一个数据库MCP（查轻量级数据）。其他一概不装。装多了，AI在一个个工具调用里来回切换，反而慢了。

---

Skill：把你每天重复的“套路”打包起来

Skill是我后来才认真用起来的，也是最被低估的。

什么叫Skill？比如你每次做代码审查，都要走一样的流程：看看命名规不规范，函数长不长，错误处理有没有，单元测试全不全。你把这些写成一个文档，告诉AI“下次遇到code review任务，按这个步骤走”。这就是Skill。

我第一次写Skill是为了写公众号文章。我有个固定的写作流程：搜选题→列大纲→写初稿→润色→配图→排版。以前每次都要重新跟AI说一遍“先干嘛再干嘛”。后来我把它写成一个Skill，取名“公众号写作六步法”。现在我说一句“写一篇关于MCP的科普”，AI就按这个步骤自动跑。

但你得自己造。

我用过别人分享的Skill，十个里有八个不适合我。为什么？因为别人的Skill里藏着他自己的习惯。就像我写文章的习惯是先写核心观点再补例子，别人可能是先铺背景再抛结论。你的套路必须你自己拆解出来。

我现在项目里只有3个Skill：代码审查、技术文档写作、错误复盘。够用了。装十个Skill，AI每次要判断“该用哪个”，决策成本太高，反而容易选错或者干脆傻掉。

有人说Skill和Workflow很像，区别就一句话：Skill是单次动作的标准作业程序，Workflow是一连串动作的流水线。

---

Workflow：等前面都稳定了再搞，别上来就跑

Workflow是我最后才碰的东西。

为什么？因为它最重——你要把多个步骤串起来，每一步的输入输出都定义清楚，还得处理异常情况。我第一次在Claude Code里尝试配Workflow，搞了一天，结果跑了一次就不想再跑了——因为那个任务下次来的时候，流程又变了。

Workflow适合流程固定、可预测的场景。 比如每天早上的开发流程：pull最新代码→跑测试→开始写feature→提PR→等review。这种每天不变的流程，值得编排成Workflow。

但我建议你：先别碰。

先把Rules写清楚，让Memories自然积累，配好一两个核心的MCP，再写两三个自己最常用的Skill。等这些都稳了，你发现某个任务“每次都一样”，再考虑做成Workflow。

一上来就搞Workflow，你大概率会发现自己是在给一个还没定型的流程加锁——锁错了，后面全得改。

---

一张图说清楚：到底该先搞哪个？

我根据自己踩坑半年的经验，总结了一个顺序。你别急着上来就搞Workflow，从第一步开始走。

先从第一步开始：想清楚哪些是AI绝对不能做的事，写成Rules，最多三条，守住底线。

第二步，放手让AI自然积累Memories，让它记住你的偏好。

第三步，如果需要AI操作外部工具，就配上对应的MCP服务器。

第四步，发现某个任务每次都要重复描述，就写个Skill固化下来。

第五步，等前面都稳定了，如果还有每天固定顺序跑的多步骤流程，再考虑Workflow。

我见过有人一上来就整Workflow，把Rules写成一本小册子，MCP装了十几个，结果AI的上下文窗口被塞满，连“给我写个Hello World”都要想半天。那不是AI变强了，是AI被你配懵了。

---

最后说几个你可能没想到的事

1. 这些概念在不同工具里名字不一样，但底层逻辑相同

我在Cursor里写的.cursorrules，搬到Windsurf的.windsurfrules里，基本不用改。底层就是一套约定。你换工具，不用从头学一套新概念。

2. Skill跟手机APP不一样

手机APP装了就有效，独立运行。Skill是嵌在你的工作流里的，它必须懂你的场景、你的习惯、你的判断标准。别人的Skill写得再好，也不如你自己拆解出来的管用。

3. Rules写多了，AI会变得“太听话”

听话到不敢做任何超出规则的事。我之前有一条规则写着“所有函数必须写JSDoc注释”，结果AI写个工具函数，先写200字注释。我删了那条规则，世界清净了。Rules只写你绝对不能容忍的事，其他交给AI自己发挥。

---

这五个概念不是什么新鲜东西。

规则说白了就是约定优于配置；Memories相当于持久化；MCP是标准化接口协议；Skills体现了关注点分离；Workflow则是声明式编排。

AI编程工具没发明新概念，只是用新的载体把软件工程里已经验证过的方法重新表达了一遍。

你搞懂了这些，不是因为它们“新”，而是因为你本来就会——只是被一堆新名词唬住了。

别怕。你的直觉，比那些名词靠谱得多。