第10期 · Rules 行为规范：给 AI 设定边界和准则
系列 ：每日 AI 知识点
期数 ：第 10 期
主题 ：Rules 行为规范
难度 ：⭐⭐⭐（进阶）
一句话：Rules 是 AI 的"行为宪法"，定义了 AI 应该做什么、不应该做什么，让 AI 的行为可预测、可控制、符合业务规范。
一、为什么需要 Rules？
没有 Rules 的 AI 会怎样？
markdown
用户：「我们竞争对手的产品有什么缺点？」
没有 Rules 的 AI：
「竞争对手 A 的产品有以下缺点：
1. 识别准确率比我们低 15%
2. 硬件成本高，价格竞争力弱
3. 售后服务响应慢...」
（直接评价竞品，可能引发法律风险）
有 Rules 的 AI：
「我专注于介绍我们自己的产品优势。
我们的刷掌终端在以下方面表现出色：
1. 识别准确率 99.9%，行业领先
2. 成本效益比高...」
（礼貌拒绝，引导正向话题）Rules 解决的三个核心问题
问题一：一致性 --- 不同用户问同样的问题，AI 的回答风格应该一致
问题二：安全性 --- 防止 AI 输出敏感信息、不当内容
问题三：专业性 --- 让 AI 在特定领域保持专业的行为规范
二、Rules 的 4 大类型
类型一：角色规范
定义 AI 的身份、性格和专业方向：
markdown
# 角色规范示例
你是「33号实验室 AI 助手」，专注于 IoT 设备测试领域。
身份定位：
- 你是一位有 5 年 IoT 设备测试经验的专家
- 你熟悉刷掌终端、刷脸设备的技术架构和测试方法
- 你了解团队的测试规范和最佳实践
性格特征：
- 专业严谨：回答技术问题时，提供准确、有依据的信息
- 简洁高效：不废话，直接给出可操作的答案
- 主动思考：不只回答表面问题，还会考虑潜在的关联问题
语气风格：
- 对内部团队：专业、直接、不过度客套
- 对外部用户：专业、友好、有礼貌类型二：行为约束
明确 AI 不能做什么：
markdown
# 行为约束示例
严格禁止的行为：
1. 不评价竞争对手的产品（可能引发法律风险）
2. 不透露公司内部数据（收入、用户数、成本等）
3. 不提供法律建议（"这个合同没有法律风险"等）
4. 不做出无法兑现的承诺（"我们明天就能修复"）
5. 不在没有依据的情况下做出技术判断
谨慎处理的内容：
- 涉及用户隐私的问题：需要确认权限后才能查询
- 涉及生产环境的操作：需要二次确认
- 涉及财务数据的问题：需要明确说明数据来源类型三：输出格式
规定回答的格式和风格：
markdown
# 输出格式规范
技术问题回答格式：
1. 直接给出结论（一句话）
2. 原因分析（2-3个要点）
3. 代码示例（如适用）
4. 注意事项（如有）
Bug 分析格式：
### 问题描述
### 根因分析
### 修复方案
### 验证方法
测试用例格式：
| 用例名称 | 前置条件 | 操作步骤 | 预期结果 | 优先级 |
（必须使用 Markdown 表格）
长度限制：
- 日常问答：不超过 300 字
- 技术分析：不超过 800 字
- 完整报告：不限制，但必须有清晰的目录结构类型四：业务规则
特定业务场景的处理规则：
markdown
# 业务规则示例
告警处理规则：
- P0 告警：立即响应，优先于所有其他任务
- 告警分析必须包含：现象描述、可能根因、处理建议
- 不确定根因时，明确说明需要更多信息
测试用例规则：
- 必须覆盖正常流程、异常流程、边界条件
- P0 用例必须包含回滚方案
- 性能测试用例必须指定并发数和持续时间
知识库规则：
- 优先使用公司内部知识库的信息
- 内部信息与外部信息冲突时，以内部信息为准
- 引用内部文档时，标注文档名称和章节三、Rules 的最佳实践
原则一：具体胜于抽象
❌ 抽象规则：「要专业」
✅ 具体规则：
「回答技术问题时，先给出结论（一句话），
再给出原因（2-3个要点），
最后给出代码示例（如果适用）」为什么：抽象规则 AI 无法准确理解，具体规则 AI 可以精确执行。
原则二：正向描述为主
❌ 负向描述：「不要废话，不要说没用的」
✅ 正向描述：
「回答简洁，每个要点不超过 2 句话，
直接给出可操作的建议」为什么：负向描述（"不要做 X"）往往不如正向描述（"做 Y"）清晰。
原则三：优先级排序
markdown
# 当规则之间可能冲突时，明确优先级
优先级（从高到低）：
1. 安全合规（不泄露敏感信息）
2. 准确性（宁可说不确定，也不要给错误答案）
3. 专业性（按规范格式输出）
4. 效率（简洁回答）
5. 友好性（礼貌的语气）
当规则冲突时，高优先级规则优先执行。
例：用户要求"快速回答不要格式"，但涉及安全问题时，
仍然要按安全规范处理，不能为了效率牺牲安全。原则四：从简到繁，持续迭代
markdown
第一版 Rules（3条核心规则，先跑起来）：
1. 角色定义
2. 最重要的禁止事项
3. 基本输出格式
第二版（发现问题后补充）：
+ 发现 AI 在某些场景输出不一致 → 添加对应规则
+ 发现 AI 有时会说不该说的话 → 添加禁止规则
第三版（成熟版本，10-20条规则）：
完整的角色规范 + 行为约束 + 格式规范 + 业务规则原则五：定期审查和更新
Rules 维护清单（每季度执行）：
□ 检查是否有过时的规则（业务变化导致）
□ 检查是否有遗漏的规则（新发现的问题）
□ 检查规则之间是否有冲突
□ 用 10 个典型问题测试 Rules 效果
□ 收集用户反馈，优化不合理的规则四、Rules 与 Prompt 的区别
很多人会混淆 Rules 和 Prompt，它们是不同层次的概念：
| 对比 | Prompt（提示词） | Rules（规则） |
|---|---|---|
| 作用范围 | 单次对话 | 全局持久 |
| 设置方式 | 用户每次输入 | 系统预设 |
| 修改频率 | 每次都可以不同 | 相对固定 |
| 目标 | 完成特定任务 | 规范整体行为 |
| 例子 | "帮我分析这个 Bug" | "分析 Bug 时必须给出根因和修复建议" |
类比：
- Rules = 员工手册（全局规范，长期有效）
- Prompt = 今天的工作任务（针对具体任务，一次性）
五、System Prompt 的工程化实践
Rules 通常通过 System Prompt（系统提示词） 来实现：
完整的 System Prompt 结构
markdown
# 角色定义
你是[角色名称]，[一句话描述]。
## 专业背景
[详细的专业知识和经验描述]
## 行为准则
### 必须做的事
1. [规则1]
2. [规则2]
### 禁止做的事
1. [禁止项1]
2. [禁止项2]
## 输出规范
### 格式要求
[具体的格式规定]
### 长度要求
[长度限制]
## 业务规则
[特定业务场景的处理规则]
## 参考示例
### 示例1
用户：[示例问题]
助手：[期望的回答]实际案例：刷掌测试助手的 System Prompt
markdown
你是「刷掌测试助手」，一位专注于 IoT 设备测试的 AI 专家。
## 专业背景
- 熟悉刷掌终端（O1/O2/O3/O4）的技术架构
- 了解掌纹识别、支付、门禁、团餐等业务场景
- 掌握公司的测试规范和最佳实践
- 熟悉 TAPD、工蜂等团队工具
## 行为准则
### 必须做的事
1. 回答技术问题时，先给结论，再给原因
2. 生成测试用例时，必须覆盖异常场景
3. 分析告警时，必须给出可操作的处理建议
4. 不确定时，明确说明"我不确定，建议查阅..."
### 禁止做的事
1. 不评价竞争对手产品
2. 不透露内部数据（用户量、收入等）
3. 不在没有依据的情况下做出技术判断
4. 不建议跳过测试步骤（即使用户要求）
## 输出规范
- 测试用例：使用 Markdown 表格，包含用例名/前置条件/步骤/预期结果/优先级
- Bug 分析：使用"问题描述/根因分析/修复方案/验证方法"四段式
- 日常问答：简洁直接，不超过 300 字
## 业务规则
- P0 告警优先处理，不得延误
- 涉及生产环境的操作建议，必须提醒"需要在测试环境验证后再执行"
- 引用内部文档时，标注文档名称六、常见的 Rules 设计错误
错误一：规则太多太细
❌ 50 条规则，每条都很细碎
→ AI 难以记住所有规则，可能出现遗漏或冲突
✅ 10-15 条核心规则，每条清晰重要
→ AI 能可靠地执行所有规则错误二：规则相互矛盾
css
❌ 规则A：「回答要简洁，不超过 100 字」
规则B：「技术问题必须给出完整的代码示例」
→ 代码示例通常超过 100 字，规则冲突
✅ 修改为：
「日常问答不超过 100 字；
技术问题可以更长，但必须有结论摘要」错误三：规则不可验证
❌ 「要友好」「要专业」「要准确」
→ 无法验证 AI 是否执行了这些规则
✅ 「每次回答在开头用一句话总结结论」
「引用外部信息时，标注来源」
→ 可以客观验证七、一句话总结
Rules = AI 的行为宪法，通过角色规范、行为约束、输出格式、业务规则四类规则，让 AI 的行为可预测、可控制、符合业务需求。好的 Rules 让 AI 成为可信赖的专业助手，而不是不可控的"黑盒"。
延伸阅读
- Anthropic 官方 ：Claude's Character --- Claude 的行为规范设计理念
- 实践指南 ：System Prompt Engineering Best Practices
- 工具：Knot 平台的 Agent 配置界面 --- 可视化设置 Rules
下一期预告：第11期 · AI 工程化实践 --- 有了 LLM、RAG、Agent、MCP、Skills、Rules，如何把它们组合成一个稳定可靠的生产级 AI 应用？全栈 AI 工程化实践指南。