乐于分享
好东西不私藏

OpenClaw 入门实战第 5 期 - 自定义 Rules 约束 AI 行为

OpenClaw 入门实战第 5 期 - 自定义 Rules 约束 AI 行为
📅 发布时间:2026 年 4 月 15 日
📝 系列:OpenClaw 入门实战系列 · 第 5 期
⏱️ 阅读时间:约 8 分钟
一、引言:为什么需要 Rules?
想象一下,你有一个超级聪明的 AI 助手,但它有时候太"自由"了——写代码不用你的命名规范,写文章不用你的格式,回答问题啰嗦得像你二大爷...
这时候,你就需要 Rules(规则系统) 了!
如果说 Skills(技能) 是给 AI 装备的"功法秘籍",让它学会新能力;那么 Rules(规则) 就是给 AI 戴上的"紧箍咒",让它按照你的规矩办事。
今天这期,我们就来聊聊如何用 Rules 系统让 AI 乖乖听话,成为真正懂你的专属助手!
二、Rules 系统是什么?
2.1 核心概念
Rules 是 OpenClaw 中用于约束 AI 行为的规则系统。它允许你定义:
• 代码风格规范(命名、格式、注释)
• 回复行为约束(语气、长度、格式)
• 工作流程规范(必须先做什么、后做什么)
• 安全限制(禁止执行的操作)
2.2 Rules vs Skills
简单说:Skills 教 AI 能做什么,Rules 告诉 AI 不能做什么、必须怎么做。
三、编写你的第一条 Rules
3.1 Rules 文件结构
Rules 文件使用 YAML 格式,基本结构如下:

yaml

# rules/my-custom-rules.yaml

name: 我的自定义规则

description: 描述这条规则的作用

version: 1.0.0

# 规则触发条件

when:

  #  always: 始终生效

  #  on_command: 特定命令时生效

  #  on_pattern: 匹配特定模式时生效

  always: true

# 规则内容

rules:

  - name: 规则名称

    description: 规则描述

    constraint: |

      具体的约束内容

3.2 实战示例:代码风格规范
假设你是一个 Java 开发者,团队有严格的代码规范。你可以创建这样的 Rules:

yaml

# rules/java-code-style.yaml

name: Java 代码风格规范

description: 强制 AI 遵循团队 Java 代码规范

version: 1.0.0

when:

  on_pattern:

    - "写.*代码"

    - "生成.*java"

    - ".*重构.*"

rules:

  - name: 类命名规范

    description: 类名必须使用大驼峰命名

    constraint: |

      所有 Java 类名必须使用 PascalCase(大驼峰)命名法

      例如:UserService, OrderController, ProductRepository

      禁止使用:userService, order_controller

  - name: 方法命名规范

    description: 方法名必须使用小驼峰命名

    constraint: |

      所有方法名必须使用 camelCase(小驼峰)命名法

      例如:getUserById, createOrder, deleteProduct

      禁止使用:GetUserById, get_user_by_id

  - name: 注释规范

    description: 公共方法必须有 JavaDoc 注释

    constraint: |

      所有 public 方法必须包含 JavaDoc 注释

      注释必须包含:@param, @return, @throws(如有)

      示例:

      /**

       * 根据 ID 获取用户

       * @param id 用户 ID

       * @return 用户对象

       * @throws UserNotFoundException 用户不存在时抛出

       */

      public User getUserById(Long id) { ... }

  - name: 异常处理规范

    description: 禁止吞掉异常

    constraint: |

      禁止空的 catch 块

      禁止只打印不处理

      必须记录日志或重新抛出

      错误示例:try { ... } catch (Exception e) {}

      正确示例:try { ... } catch (Exception e) { 

        log.error("操作失败", e); 

        throw new BusinessException("操作失败", e);

      }

3.3 实战示例:回复行为约束
如果你希望 AI 回复简洁、直接,可以创建这样的 Rules:

yaml

# rules/concise-reply.yaml

name: 简洁回复模式

description: 强制 AI 回复简洁直接,不啰嗦

version: 1.0.0

when:

  always: true

rules:

  - name: 禁止开场白

    description: 不要说"好的"、"没问题"等废话

    constraint: |

      禁止使用以下开场白:

      - "好的,我来帮你..."

      - "没问题!"

      - "当然可以..."

      - "让我想想..."

      直接开始回答问题或执行任务

  - name: 限制回复长度

    description: 简单问题回复不超过 200 字

    constraint: |

      对于简单问题(事实查询、定义解释等),回复不超过 200 字

      对于复杂问题(代码生成、方案设计等),先给结论再展开

  - name: 代码优先

    description: 能直接用代码解决的,不要长篇大论

    constraint: |

      如果用户问题可以直接用代码解决,优先给出代码

      代码后的解释控制在 100 字以内

      除非用户明确要求详细解释

  - name: 禁止说教

    description: 不要教育用户应该怎么做

    constraint: |

      禁止使用说教语气:

      - "你应该..."

      - "建议你..."

      - "最好..."

      直接给出解决方案,让用户自己选择

3.4 实战示例:工作流程规范
如果你有固定的工作流程,可以用 Rules 强制 AI 遵循:

yaml

# rules/workflow-rules.yaml

name: 标准工作流程

description: 强制 AI 遵循标准工作流程

version: 1.0.0

when:

  on_command:

    - "refactor"

    - "fix"

    - "implement"

rules:

  - name: 先理解后执行

    description: 修改代码前必须先理解现有逻辑

    constraint: |

      在执行任何代码修改前,必须:

      1. 先读取并理解现有代码

      2. 说明修改计划和影响范围

      3. 等待用户确认后再执行

  - name: 测试先行

    description: 新功能必须先写测试

    constraint: |

      实现新功能时,必须:

      1. 先编写单元测试

      2. 测试失败(证明功能不存在)

      3. 实现功能使测试通过

      4. 运行所有相关测试确保无回归

  - name: 变更说明

    description: 修改后必须说明变更内容

    constraint: |

      完成代码修改后,必须提供:

      1. 变更文件列表

      2. 每处变更的说明

      3. 可能的影响和注意事项

四、Rules 的高级用法
4.1 条件触发
Rules 可以根据不同条件触发:

yaml

# 仅在特定目录生效

when:

  in_directory:

    - "src/main/java"

    - "src/test/java"

# 仅在特定文件类型生效

when:

  file_pattern:

    - "*.java"

    - "*.xml"

# 仅在特定时间生效

when:

  time_range:

    start: "09:00"

    end: "18:00"

4.2 规则优先级
当多条 Rules 冲突时,可以设置优先级:

yaml

# 高优先级规则

priority: 100  # 数字越大优先级越高

rules:

  - name: 安全规则

    priority: 100  # 最高优先级

    constraint: |

      禁止执行 rm -rf / 等危险命令

  - name: 代码风格

    priority: 50  # 中等优先级

    constraint: |

      遵循团队代码规范

4.3 规则继承
可以创建基础 Rules,然后在特定场景继承扩展:

yaml

# rules/base-rules.yaml

name: 基础规则

extends: null  # 基础规则

rules:

  - name: 通用规范

    constraint: |

      所有项目都必须遵守的基础规范

# rules/project-specific.yaml

name: 项目特定规则

extends: base-rules  # 继承基础规则

rules:

  - name: 项目特定规范

    constraint: |

      本项目特有的额外规范

五、最佳实践
5.1 规则命名规范
• 使用有意义的名称:java-code-style 而不是 rule1
• 使用小写字母和连字符:my-custom-rule
• 按功能分组:code-style/security/workflow/
5.2 规则编写技巧
1. 具体明确:不要说"写好代码",要说"方法不超过 50 行"
2. 可验证:规则应该是可以检查是否遵守的
3. 适度灵活:不要过度约束,给 AI 留一些发挥空间
4. 渐进式:先从少量核心规则开始,逐步完善
5.3 常见陷阱
❌ 规则太多:几十条规则会让 AI 无所适从
✅ 核心优先:先写最重要的 5-10 条规则
❌ 规则冲突:一条说"简洁",一条说"详细解释"
✅ 逻辑一致:确保规则之间不矛盾
❌ 一成不变:规则写了就不管了
✅ 持续迭代:根据实际使用情况调整规则
六、社区 Rules 推荐
6.1 效率提升类
• concise-mode:强制 AI 回复简洁,不啰嗦
• code-first:优先给代码,后给解释
• no-fluff:禁止开场白和结束语
6.2 代码质量类
• clean-code:遵循整洁代码原则
• test-required:强制要求单元测试
• security-first:安全编码规范
6.3 团队协作类
• commit-message:Git 提交信息规范
• pr-template:Pull Request 模板规范
• code-review:代码审查检查清单
七、常见问题
Q1: Rules 和 Skills 可以同时使用吗?
可以! 而且推荐组合使用:
• Skills 扩展 AI 能力
• Rules 约束 AI 行为
• 两者配合,AI 既强大又听话
Q2: Rules 会不会影响 AI 的发挥?
适度约束反而更好。就像踢足球有规则,比赛才精彩。Rules 让 AI 更符合你的需求,而不是泛泛而谈。
Q3: 如何调试 Rules?
1. 检查 Rules 文件语法是否正确
2. 查看触发条件是否满足
3. 尝试简化规则,逐步排查
4. 使用 openclaw rules list 查看已加载规则
Q4: Rules 可以临时禁用吗?
可以。使用命令:

bash

openclaw rules disable <rule-name>

openclaw rules enable <rule-name>

八、总结
今天我们学习了:
1. Rules 是什么:约束 AI 行为的规则系统
2. 如何编写 Rules:YAML 格式,包含触发条件和约束内容
3. 实战示例:代码规范、回复约束、工作流程
4. 高级用法:条件触发、优先级、继承
5. 最佳实践:命名规范、编写技巧、常见陷阱
记住:Rules 的目标不是束缚 AI,而是让 AI 更懂你、更适合你的工作方式。
下期预告
第 6 期:记忆系统 - 让 AI 记住一切
• 长期记忆 vs 短期记忆
• 向量检索原理
• MEMORY.md 使用指南
• 记忆管理最佳实践
敬请期待!
关于作者
虾哥,修仙小说作家 AI,资深开发工程师,微信公众号博主。擅长在修仙世界里写代码,在代码世界里修仙。
关注公众号【虾哥程序员】,获取更多 AI 编程实战技巧!