上周我发了一篇写 Android Skill 的文章,被大号转发之后,评论区炸了。有人说"这根本不叫 Skill",有人说"这应该放 Rule",还有人说"你只是在写规范化 Prompt"。

说实话,看到评论我的第一反应不是辩解,而是觉得有意思–这说明大家在这三个词上,确实没有共识。今天就彻底把这个问题说清楚。不只是某一个工具的定义,而是横跨整个 AI 编程工具生态,梳理一遍 Prompt、Rule、Skill 三者到底是什么关系,谁能干谁的活,以及什么时候用哪个。

这三个词现在满天飞,但每个工具赋予它们的含义都不一样。想讲清楚,得先把生态铺开来看。

先来看各个主流 AI 编程工具,它们实际上用的是什么机制、叫什么名字:

一个很关键的发现:大多数 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 是最基础的东西,就是你输入给 AI 的这条消息。它是一次性的,针对当前任务。写完这条消息,下次对话它消失了。

Prompt Engineering 本质是在研究"怎么说这句话让 AI 表现更好"--用 Chain-of-Thought、few-shot 示例、角色设定......这些都是 Prompt 层的技巧,解决的是单次对话质量问题。

Prompt 的核心特征:一次性、针对当前任务、由人实时输入或由系统注入、不沉淀团队知识。

Rule 是持久化的约束,不针对某次对话,而是针对所有对话全局生效。它回答的问题是:"在这个项目/团队里,我们始终怎么做事。"

比如你在 .cursorrules 里写"用 Hilt 不用 Koin",这条规则从此在每次 AI 帮你写 Android 代码时都会生效,你不需要每次重复说。这就是 Rule 的价值:一次写入,永久约束。

各工具的 Rule 机制本质上都是在做同一件事:把这些约束注入到 System Prompt 或对话上下文里,让 AI 在每次回复前都"记得"这些规则。

Rule 的核心特征:持久化、全局或项目级生效、无需每次重申、沉淀团队规范和历史踩坑。

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 相比，即面很像，又有自己的独特设计。

• 都用 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 把这种情况明确区分出来，很务实。

现在可以回答评论区的争议了。

说"这是 Rule 不是 Skill"的人--从 Cursor/Windsurf 的视角看,没错 。在这些工具里没有 Skill 层,你把团队规范写进 .cursorrules 就是标准做法,那里的内容确实叫 Rule。

但在 OpenClaw 的体系里,Skill 的设计本来就不只是存规范,它支持触发条件 + 按需加载 + 引用外部文件 + 工具调用。把团队规范放进 Skill 的 references/ 目录里,再在 SKILL.md 里写清楚触发条件,这是 OpenClaw 支持的正确用法。

所以争议的根源不是谁对谁错,而是站的框架不同。不同工具对这三个词的定义存在交叉和重叠,用某个工具的术语去评判另一个工具的设计,当然会觉得"不对劲"。

来一份实操指南:根据你用的工具和想做的事,选择正确的层。

有一个实用判断标准:如果你需要反复跟 AI 解释同一件事,它就应该是 Rule 或 Skill,而不是每次重新在 Prompt 里说。至于该用 Rule 还是 Skill,看它是否需要工具调用和流程控制--需要就是 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 里,工程师不需要每次自己写。

现在争论叫什么名字,是因为我们还在这个封装完成之前。用行话说:底层正在被抽象,争论的是抽象层命名,不是核心问题。