Rule（规则）（Rule）
一句话定义：Rule 是 AI 协作中用于约束行为、对齐意图和确保输出质量的“显性契约”，是实现从“随意聊天”到“专业工程”转化的底层基础设施。
科普速读
- 解决问题：把“抽象约束”变成可执行规则。
- 适用场景：团队协作、合规要求、策略驱动自动化。
- 使用边界：不做验证的规则会很快过时。
概览
在 Vibe Coding 的语料库中，Rule（规则） 是一切可控 AI 的核心。AI 像是一个充满创造力但也极不稳定的“水”，而规则就是那个“容器”。没有规则，AI 可能会写出运行如飞但无法维护、或者风格杂乱的代码。通过精心设计的规则体系（如 .cursorrules），我们可以把团队过去十年的工程经验和忌讳，在几毫秒内同步给 AI 助手，使其瞬间具备“资深员工”般的常识感。
核心定义
标准定义
Rule 是一组明确定义的约束指令或准则，通常以自然语言编写，旨在限制 AI 模型在处理任务时的决策空间。它涵盖了代码风格、安全准则、输出结构、工具调用倾向以及特定的业务逻辑限制。
通俗解释
你可以把 Rule 理解为 “AI 智能体的入职培训手册 + 自动化红线”。你不必每次都嘱咐他“写 Python 别忘了加 Type Hint”，你只需要把它写在规则里，他就像是你的分身一样，永远记得公司的代码规范。他是你为 AI 设置的“护栏”。
背景与发展
起源
- 提出背景：早期提示工程（Prompt Engineering）由于太随机、难管理，导致大型团队在推广 AI 辅助工具时遇到了严重的“输出风格不一致”问题。
- 关注重点：如何通过一种声明式的、持久化的方式，将规则从单次对话中剥离出来。
演进
- 1.0 时代（System Prompt）：单向的指令注入，难修改、难拆分，且对上下文占用极大。
- 2.0 时代（Config-based Rules）：以
.cursorrules为代表，规则开始与项目文件并存，具备了“按项目自动激活”的能力。 - 3.0 时代（Dynamic & Managed Rules）：规则开始具备层级体系（全局规则、项目规则、针对特定文件的微观规则），并能通过 Git 进行版本管理和团队分发。
工作机制（How It Works）
- 规则定义 (Declaration)：用精确、无歧义的自然语言描述约束（例如：“所有 SQL 必须使用参数化查询”）。
- 上下文检索 (Retrieval)：当开发者在特定目录下呼唤 AI 时，IDE 自动搜寻附近的
.cursorrules文件并注入提示词头部。 - 输出过滤与对齐 (Alignment)：模型在推理过程中，将规则作为强约束，优先过滤掉不满足规则的候选方案。
- 验证机制 (Verification)：配合 Linters 和自动化测试，对违反规则的 AI 输出进行拦截并报错。
在软件测试与开发中的应用
- 统一架构风格：规则“严禁在 Controller 层直接写 SQL”，强制 AI 通过 Service 层进行调用。
- 自动化测试规范：规则“必须为每个新函数同步生成对应的单元测试，且覆盖率不低于 80%”。
- 安全检查预警：规则“禁止在代码块中硬编码任何 API Key 或密码占位符”。
优势与局限
优势
- 极低的学习成本：用中文或英文写几句话就能显著改变 AI 的行为，无需复杂微调。
- 知识沉淀：老员工总结的“坑”，可以通过规则一秒传授给所有正在由 AI 协助的新员工。
- 高度透明：规则写在代码库里，所有人都能看到 AI 为什么会这么建议，方便审计。
局限与风险
- 规则冲突 (Conflicts)：当全局规则和项目规则互相矛盾时，容易导致模型出现“死锁”或胡言乱语。
- “规则过载” (Rule Bloat)：注入太多规则会吃掉大量的上下文 Token，导致模型能阅读的代码量变少。
- 绕过风险：极其聪明的模型（如 o1）偶尔会为了完成任务而“抄近路”，甚至在不经意间违反含糊的规则。
与相近术语对比
| 维度 | Rule (规则) | Prompt (提示词) | Logic (硬代码逻辑) |
|---|---|---|---|
| 持久度 | 长期稳定、项目共有 | 临时、单次对话有效 | 绝对、不可更改 |
| 灵活性 | 高，自然语言修订 | 极高，随口即说 | 极低，需重新编译/部署 |
| 执行机制 | 语义约束 | 意图引导 | 确定性执行 |
实施建议（Best Practices）
- 原子化描述：不要写“请写出好代码”，要写“变量名必须使用 camelCase，且长度不超过 25 个字符”。
- 使用 Markdown 结构：在规则文件中使用标题和加粗，帮助模型更快定位关键约束。
- 建立“规则版本仓库”：在公司内部建立一个优秀规则的精选库（Awesome Rules），方便各项目进行引用。
常见误区（Pitfalls）
- 以为规则越多越好：过多的规则会增加模型的认知负担。保留最重要的 10-15 条规则往往最具性价比。
- 忽略负面约束：告诉 AI “不要做什么”往往比告诉他“要做什么”更有效（例如：禁止使用 jQuery）。
FAQ
Q1: Rule 需要写在代码注释里吗？
A: 不需要。虽然有用，但最好的实践是写在单独的配置文件（如 .cursorrules）中，这样可以让代码更干净，且不属于正式编译范畴。
Q2: 自从有了 Rule，AI 就再也不会写 Bug 了吗？
A: 绝非如此。规则能大幅减少“低级风格错误”和“常见逻辑疏忽”，但对于本质性的算法缺陷，依然需要通过 Code Review 解决。