上周我发了一篇写 Android Skill 的文章,被大号转发之后,评论区炸了。有人说"这根本不叫 Skill",有人说"这应该放 Rule",还有人说"你只是在写规范化 Prompt"。
说实话,看到评论我的第一反应不是辩解,而是觉得有意思--这说明大家在这三个词上,确实没有共识。今天就彻底把这个问题说清楚。不只是某一个工具的定义,而是横跨整个 AI 编程工具生态,梳理一遍 Prompt、Rule、Skill 三者到底是什么关系,谁能干谁的活,以及什么时候用哪个。
这三个词现在满天飞,但每个工具赋予它们的含义都不一样。想讲清楚,得先把生态铺开来看。
从各工具的实际叫法开始说
先来看各个主流 AI 编程工具,它们实际上用的是什么机制、叫什么名字:
| 工具 | Rule 层叫什么 | Skill 层 | 文件名/位置 |
|---|---|---|---|
| Cursor | Rules for AI | 仅 Rule,无 Skill | .cursorrules 或 Settings |
| Windsurf | Global/Workspace Rules | 仅 Rule,无 Skill | global_rules.md |
| Claude Code | Memory / Instructions | 仅 Rule,无 Skill | CLAUDE.md |
| GitHub Copilot | Custom Instructions | 仅 Rule,无 Skill | .github/copilot-instructions.md |
| Aider | Conventions | 仅 Rule,无 Skill | CONVENTIONS.md |
| CodeBuddy | User Rules + Project Rules | Rule + Skill 双层 | Settings + .codebuddy/skills/ |
| OpenClaw | AGENTS.md 全局约束 | Rule + Skill 双层 | AGENTS.md + SKILL.md |
一个很关键的发现:大多数 AI 编程工具只有 Rule 这一层,没有 Skill。Cursor 叫 Rule,Windsurf 叫 Rule,Claude Code 叫 Memory/Instructions,Copilot 叫 Custom Instructions--叫法各异,但本质相同:把团队规范、项目约束持久化进去,让 AI 每次都知道该怎么做。
CodeBuddy 和 OpenClaw 是两个例外 --同时具备 Rule 和 Skill 双层。CodeBuddy 的 Rules 分为 User Rules(个人偏好,跨项目生效)和 Project Rules(项目级,放在 .codebuddy/ 目录下);Skills 通过 .codebuddy/skills/ 目录定义,用 SKILL.md 描述触发条件和工具权限(allowed-tools),由 AI 自动识别调用。这个架构跟 OpenClaw 几乎完全一致。
这就是评论区那些人说"你写的是 Rule 不是 Skill"的背景--他们用的是 Cursor 或 Windsurf 的语境,在他们的工具里,确实没有 Skill 这个层,你文章里的内容放进 .cursorrules 就搞定了。他们说的没错,只是框架不同。
三个词的本质区别
把框架放下,从功能本质来拆解这三个概念:
Prompt:这次对话说什么
Prompt 是最基础的东西,就是你输入给 AI 的这条消息。它是一次性的,针对当前任务。写完这条消息,下次对话它消失了。
Prompt Engineering 本质是在研究"怎么说这句话让 AI 表现更好"--用 Chain-of-Thought、few-shot 示例、角色设定......这些都是 Prompt 层的技巧,解决的是单次对话质量问题。
Prompt 的核心特征:一次性、针对当前任务、由人实时输入或由系统注入、不沉淀团队知识。
Rule:这类任务始终怎么做
Rule 是持久化的约束,不针对某次对话,而是针对所有对话全局生效。它回答的问题是:"在这个项目/团队里,我们始终怎么做事。"
比如你在 .cursorrules 里写"用 Hilt 不用 Koin",这条规则从此在每次 AI 帮你写 Android 代码时都会生效,你不需要每次重复说。这就是 Rule 的价值:一次写入,永久约束。
各工具的 Rule 机制本质上都是在做同一件事:把这些约束注入到 System Prompt 或对话上下文里,让 AI 在每次回复前都"记得"这些规则。
Rule 的核心特征:持久化、全局或项目级生效、无需每次重申、沉淀团队规范和历史踩坑。
Skill:这类任务按需触发,带工具调用
Skill 是三者里最"重"的一个。它不只是告诉 AI 怎么做,它还定义了:什么情况下触发、需要调用哪些外部工具、如何与其他系统交互。
举个例子:一个"查 TAPD Bug"的 Skill,包含了--触发条件(用户提到 Bug 数据时)、工具调用(TAPD API)、输出格式(固定报告结构)、处理流程(按优先级排序、过滤已关闭)。这些东西 Rule 做不了,Prompt 也做不了,只有 Skill 能承载。
所以 Skill ≠ 规范化 Prompt。Prompt 解决"这次怎么说",Skill 解决"这类任务如何稳定、可复用地执行"--而且通常包含工具调用、外部依赖、结构化流程。
Skill 的核心特征:按需触发、包含工具调用、有明确执行流程、可复用的能力模块,而非单纯的文字约束。
一张图说清楚三者的关系
用户发出请求
↓
Prompt - 当前消息本体,描述本次任务
↓ 注入
Rule - 全局持久约束,自动拼入上下文(团队规范、反模式、版本要求)
↓ 若匹配触发条件
Skill - 按需加载的能力模块,带工具调用和执行流程
↓
AI 生成最终回复
每次 AI 处理请求时,这三层都可能同时在场:Prompt 是你说的话,Rule 是背景约束,Skill 是在需要时被激活的执行能力。它们不是互相替代的关系,而是分工协作。
CodeBuddy 的 Skill ：和 OpenClaw 的异同
CodeBuddy 的 Skill 设计值得单独说一下。它跟 OpenClaw 相比，即面很像，又有自己的独特设计。
相同的地方
• 都用 SKILL.md 作为 Skill 定义文件，目录结构几乎完全一致
• 都支持 AI 按需自动触发，不需要用户手动输入命令
• 都支持工具权限控制（CodeBuddy: allowed-tools）
• 都支持项目级和用户级两个粒度，可共享给团队
不同的地方
CodeBuddy Skill 有两个 OpenClaw 目前还没有的独特设计：
• context: fork：Skill 在隔离的子 Agent 上下文里执行，不携带主对话历史。适合深度研究、代码扫描这类需要独立上下文的任务。
• user-invocable: false ：Skill 从用户的 / 菜单中隐藏，只作为 AI 内部的背景知识加载，适合放项目规范类的内容（纯规范约束，不需要手动触发）。
这两个设计其实在承认一个实际上存在的需求：Skill 里的内容并不都需要工具调用 。有时候你只是要把项目规范注入到上下文里让 AI 知道------这其实更接近 Rule 的语义。CodeBuddy 用 user-invocable: false 把这种情况明确区分出来，很务实。
回到 Android Skill 的争议：谁说得对？
现在可以回答评论区的争议了。
说"这是 Rule 不是 Skill"的人--从 Cursor/Windsurf 的视角看,没错 。在这些工具里没有 Skill 层,你把团队规范写进 .cursorrules 就是标准做法,那里的内容确实叫 Rule。
但在 OpenClaw 的体系里,Skill 的设计本来就不只是存规范,它支持触发条件 + 按需加载 + 引用外部文件 + 工具调用。把团队规范放进 Skill 的 references/ 目录里,再在 SKILL.md 里写清楚触发条件,这是 OpenClaw 支持的正确用法。
所以争议的根源不是谁对谁错,而是站的框架不同。不同工具对这三个词的定义存在交叉和重叠,用某个工具的术语去评判另一个工具的设计,当然会觉得"不对劲"。
不同工具该用哪个层?
来一份实操指南:根据你用的工具和想做的事,选择正确的层。
| 你想做的事 | Cursor / Windsurf | OpenClaw |
|---|---|---|
| 沉淀团队规范(框架选择、命名约定) | Rule(.cursorrules) | Skill references/ 或 AGENTS.md |
| 记录反模式(禁用 GlobalScope、禁用 LiveData) | Rule | Skill references/conventions.md |
| 调用外部 API(查 TAPD、读日历、搜 Bug) | Agent 或 Extension | Skill(含工具调用) |
| 按需触发的复杂任务流程 | 无原生支持,靠 Prompt 实现 | Skill(触发条件 + 执行步骤) |
| 单次对话的临时指令 | Prompt(直接说) | Prompt(直接说) |
有一个实用判断标准:如果你需要反复跟 AI 解释同一件事,它就应该是 Rule 或 Skill,而不是每次重新在 Prompt 里说。至于该用 Rule 还是 Skill,看它是否需要工具调用和流程控制--需要就是 Skill,不需要就是 Rule。
Skill 比 Rule 多出来的那部分
有人在评论里说"Skill 只是规范化 Prompt 的一种",这个判断我不同意。规范化 Prompt 最多到 Rule 这一层,Skill 的核心价值在于它是一个可执行的能力模块,而不仅仅是文字约束。
Rule 能告诉 AI "你应该怎么写代码",但 Skill 能做到"当用户问 Crash 分析时,自动加载 crash_patterns.md,调用日志分析工具,按照固定流程输出报告"。这是两件性质完全不同的事。
一个好的类比:Rule 是公司的行为准则手册,Skill 是培训好的工作流程 SOP。手册告诉员工"应该怎么做人",SOP 告诉员工"这类事情第一步干什么第二步干什么",两者都需要,但不能互换。
为什么这三个词会被混用
混乱的根本原因是:这个领域太新,术语还没有标准化。LangChain 里的"Tool"、AutoGPT 里的"Command"、Dify 里的"工作流"、Cursor 里的"Rule"......做的事情有交集,但叫法完全不同。
当社区里用 Cursor 的人和用 OpenClaw 的人用同一个词"Skill"来讨论时,他们脑子里的模型其实完全不同。这不是谁的错,是行业处于早期阶段的自然现象。
我更倾向于从功能本质去理解,而不是拘泥于某个工具的命名:
• 解决"这次说什么" → Prompt
• 解决"始终怎么做" → Rule(或各工具里对应的持久化约束层)
• 解决"这类任务如何稳定执行"且涉及工具调用和流程 → Skill(或 Agent、工作流)
用这个框架来理解任何工具的设计,都不会跑偏。
最后说一句
评论区的争议让我意识到,现在很多关于"怎么用 AI 编程工具"的讨论,还停留在各自工具的局部视角里。Cursor 用户讲 Rule,OpenClaw 用户讲 Skill,Dify 用户讲工作流......大家都在解决同一类问题,但因为工具命名不同,互相看对方的方案都觉得"叫错了"。
其实更值得关注的是功能本质:你的团队知识有没有被有效沉淀?AI 的行为有没有被有效约束?复杂任务有没有被结构化为可复用的能力? 至于叫什么名字,工具迭代几个版本可能就统一了。
行业在往这个方向走,MCP(Model Context Protocol)的出现就是一个信号--工具调用层正在被标准化,Skill/Tool/Agent 的边界迟早会有共识。
我的判断是:两年内,这三层的分工会变成共识,Rule 会成为 AI 编程工具的标配,Skill/Agent 会成为企业内 AI 平台的核心竞争力,而 Prompt Engineering 会逐渐退出工程师的日常词汇--不是因为 Prompt 不重要,而是它会被封装进 Rule 和 Skill 里,工程师不需要每次自己写。
现在争论叫什么名字,是因为我们还在这个封装完成之前。用行话说:底层正在被抽象,争论的是抽象层命名,不是核心问题。