在使用 AI 工具过程中，什么时候应该使用 Rule 和 Skills？
很多团队一开始用 AI 时，会把所有约束都塞进一段大 prompt。这样短期看似能跑，长期却很难维护。更稳的做法是把“长期稳定的约束”沉淀成 Rule，把“某类任务的执行套路”沉淀成 Skill。 这两者不是替代关系，而是分工关系。
0. 面试速答（30 秒版 TL;DR）
- Rule 更适合放“始终有效、必须遵守、偏约束型”的内容。
- Skill 更适合放“某类任务怎么做、按什么步骤做、如何验收”的内容。
- 一个简单判断方法：
- 如果它像“红线”或“默认制度”，优先放 Rule
- 如果它像“操作手册”或“任务模板”，优先放 Skill
- 实际工程里最稳的组合通常是：Rule 负责兜底，Skill 负责提效。
- 一句话总结：Rule 管边界，Skill 管流程。
1. 先分清两个概念
1.1 Rule 是什么
Rule 可以理解为：默认生效、尽量稳定、跨任务通用的约束条件。
它回答的是：
- 什么事情不能做
- 什么事情必须做
- 输出至少要满足哪些底线
典型例子：
- 不允许改工作区外文件
- 删除命令必须确认
- 回答 review 时必须给文件路径
- 修改代码前必须先搜索上下文
- 涉及高风险操作必须升级审批
你会发现，这类内容和具体任务关系不大，但和整体安全性、稳定性关系很大。
1.2 Skill 是什么
Skill 可以理解为：面向某类任务的标准做法。
它回答的是：
- 这类任务什么时候用
- 输入需要准备什么
- 执行时按什么步骤推进
- 最后怎样算完成
典型例子：
- “前端 bug 修复” Skill
- “新增技术文档” Skill
- “代码 Review” Skill
- “排查构建失败” Skill
这类内容强调的是“流程复用”，不是“全局约束”。
2. 什么时候该用 Rule
出现下面几种情况时，更适合沉淀成 Rule。
2.1 这条要求对大多数任务都成立
例如：
- 先读上下文再改代码
- 不要宣称已经验证，除非真的跑过
- 输出必须说明未验证项
这类要求越通用，越不应该藏在某一个 Skill 里，而应该直接升级成全局 Rule。
2.2 这条要求本质上是“底线”
例如：
- 不允许执行高风险删除命令
- 不允许擅自联网安装依赖
- 不允许泄露敏感配置
底线型要求如果只放在某个 Skill 里，会有漏网场景。它应该始终生效。
2.3 这条要求主要在控制风险，而不是指导步骤
Rule 更像护栏，不像导航。
如果你的重点是：
- 限目录
- 限权限
- 限命令
- 限输出格式
那它通常更像 Rule。
3. 什么时候该用 Skill
出现下面几种情况时，更适合沉淀成 Skill。
3.1 这是一类反复出现的任务
例如团队每周都会反复做：
- 补一篇技术文档
- 修一个前端交互 bug
- 做一次 PR 风险审查
如果每次都从头临时组织 prompt，稳定性和效率都会很差。这时就该把经验抽成 Skill。
3.2 这类任务需要固定步骤
比如“排查 bug”通常应该是：
- 先复现
- 再定位
- 再做最小改动
- 再跑验证
- 最后输出说明
这类“多步骤、可复用、顺序重要”的工作，非常适合做成 Skill。
3.3 这类任务需要专门上下文
有些任务不是所有场景都需要，但一旦触发就需要固定资料。
例如“新增文档” Skill 可能要求：
- 先看目录结构
- 遵守特定写作模板
- 必要时补 Mermaid 图
- 跑文档校验
这些都更像任务专属方法论，不适合升格成全局 Rule。
4. 一个实用判断法：看它回答的是“能不能”，还是“怎么做”
如果一条内容主要回答：
- 能不能做
- 必须不做什么
- 最低必须满足什么
它更像 Rule。
如果一条内容主要回答：
- 这类任务怎么启动
- 过程怎么走
- 结果怎么验收
它更像 Skill。
所以可以把它们记成一句话：
- Rule 决定可行动作边界
- Skill 决定任务执行路径
5. 前端团队里的典型例子
| 场景 | 更适合 Rule 的内容 | 更适合 Skill 的内容 |
|---|---|---|
| 修 bug | 只改允许目录；高风险命令要确认 | 复现、定位、最小修复、验证的流程 |
| 写文档 | 必须中文为主；图表要校验 | 新文档的结构模板、图表示例、验收步骤 |
| Code Review | 结论必须附文件依据 | Review 时优先看回归、测试缺口、风险项 |
| 调试构建问题 | 不要随意升级依赖 | 如何收集日志、定位缓存、缩小范围 |
你会发现，一个真实任务里，两者往往同时存在。
6. 为什么不要把所有东西都塞进 Skill
这是很多团队的常见误区。
如果你把本该全局生效的约束都塞进 Skill，会出现两个问题：
- 没走这个 Skill 时，约束就失效了
- Skill 会越来越肿，最后没人维护
反过来，如果你把所有流程都硬塞进 Rule，也会出问题：
- Rule 过长，模型难以稳定执行
- 不同任务之间互相打架
- 团队无法针对具体任务迭代方法
所以真正成熟的做法不是二选一，而是分层。
7. 一套推荐分层
可以用这套方式理解：
- Rule 层 负责权限、边界、输出底线、验证底线
- Skill 层 负责任务定义、步骤、输入、工具使用方式、验收模板
- 临时 Prompt 层 负责这次任务的特殊背景、当前目标和额外说明
这三层叠起来，比一段超长 prompt 更稳定。
8. 典型题 & 标准答法
Q1：Rule 和 Skill 的核心区别是什么？
答：
Rule 更像跨任务通用的约束和底线，强调始终有效；Skill 更像某类任务的操作手册，强调流程复用和稳定执行。
Q2：为什么说 Rule 更适合放底线约束？
答：
因为底线约束不能依赖“这次刚好走了哪个 Skill”。像权限、安全、验证要求这类内容，应该默认始终生效，否则容易出现治理空洞。
Q3：一个团队应该先建设 Rule 还是先建设 Skill？
答：
通常先补最关键的 Rule，先把风险收住；然后再针对高频任务建设 Skill，把效率做起来。也就是先兜底，再提效。
9. 常见误区
- 把所有经验都塞进 Rule 结果是规则臃肿，执行噪音很大。
- 把所有约束都塞进 Skill 结果是只在部分场景生效，风险兜不住。
- 只做文档沉淀，不做版本维护 Rule 和 Skill 都会过时。
- 没有验收机制 沉淀了规则和流程，不代表团队真的会稳定执行。
10. 速记要点（可背诵）
- Rule 管边界，Skill 管流程。
- Rule 适合放：长期稳定、跨任务通用、偏风险控制 的要求。
- Skill 适合放：高频可复用、步骤明确、可验收 的任务套路。
- 更成熟的工程实践不是只选一个，而是 Rule 兜底，Skill 提效，临时 Prompt 补充现场信息。