腾讯云代码助手 CodeBuddy 支持您自定义项目级规则（Rules），通过给大模型提供上下文，从而规范模型的行为。

创建 Rules

CodeBuddy 默认已经启用 Rules 功能，无需手动开启，允许您自定义项目级别的 Rules。当您首次启动项目时，CodeBuddy 会自动在项目根目录下创建 .codebuddy/rules 目录，您可以在该目录下创建 Rules 文件，例如：

在 Rules 文件中，您可以自定义项目 Rules，例如项目规范、框架约定、库使用规则、编码安全要求等等。这些 Rules 在定义好后会在当前项目中生效，在每次重新启动或重载项目时会自动扫描并加载 .codeBuddy/rules 目录下的 Rules 文件，并且适用于所有对话请求和内联对话请求中。可用于代码优化建议、安全检查或代码智能分析等方面，实现团队的规则统一管理，提升代码质量和开发效率。

参考案例

在编写 Rules 内容时，可参考下面的例子：

【C++ 规范】

你是一个专业的C++开发助手，所有代码必须严格遵循以下编码规范。

**注意：如果没有明确说明，需要遵循Google C++代码规范。**

## 规范等级定义：
- **【必须】**：代码必须遵循
- **【推荐】**：代码应当遵循，但在特殊情况下可以例外  
- **【可选】**：可以参考，根据具体情况决定是否采用

## 1. C++版本规范
- 【必须】使用C++17，不使用C++2a功能
- 【必须】不使用非标准扩展
- 【推荐】使用C++14和C++17功能前考虑可移植性问题

## 2. 头文件规范
- 【必须】头文件应该是self-contained，以.h结尾
- 【必须】所有头文件都应该使用#define或#pragma once防止重复包含
- 【推荐】避免使用前置声明，优先使用#include
- 【推荐】内联函数只在10行或更少时使用
- 【必须】#include顺序：相关头文件、C系统头文件、C++标准库头文件、其他库.h文件、本项目内.h文件

## 3. 作用域规范
- 【必须】必须使用命名空间，基于项目名或相对路径命名
- 【必须】不要在头文件全局作用域使用using指令
- 【必须】禁止使用内联命名空间
- 【必须】在源文件中使用匿名命名空间或static声明
- 【必须】使用静态成员函数或命名空间内的非成员函数，避免裸全局函数
- 【推荐】将函数变量置于最小作用域内，并在声明时初始化
- 【必须】禁止使用具有静态存储期的非平凡析构对象  
- 【必须】非函数内的thread_local变量必须初始化为编译时常量

## 4. 类规范
- 【必须】不要在构造函数中调用虚函数
- 【必须】不要定义隐式类型转换，对转换运算符和单参数构造函数使用explicit关键字
- 【必须】如果需要，让类型支持拷贝/移动，否则显式禁用
- 【必须】仅对承载数据的被动对象使用struct，其它使用class
- 【必须】使用组合优于继承，如果使用继承定义为public继承
- 【必须】如果可以给字段取有意义的名字，优先使用结构体而不是pair和tuple
- 【必须】除少数特定环境外，不要重载运算符
- 【必须】将所有数据成员声明为private，除非是static const常量
- 【必须】类定义以public段开始，后跟protected段，最后是private段

## 5. 函数规范
- 【推荐】优先使用返回值作为函数输出
- 【推荐】编写简短且内聚的函数（超过40行需要考虑拆分）
- 【必须】函数重载必须让读者一看调用点就明了
- 【推荐】只在非虚函数中使用缺省参数，且必须保证缺省参数值始终一致
- 【可选】只在常规写法无法满足要求或可读性很差时使用返回类型后置语法

## 6. 其他C++特性规范
- 【推荐】使用右值引用定义移动构造函数与移动赋值操作
- 【必须】允许合理使用友元类及友元函数
- 【必须】根据项目特点和团队能力决定是否使用异常，但必须保持一致
- 【可选】在正确且切实有效时可以使用noexcept限定符
- 【推荐】禁止使用RTTI
- 【必须】使用C++风格的类型转换，不使用C风格类型转换
- 【必须】在合适的时候使用流，并保持简洁
- 【必须】对于迭代器和其他模板对象使用前置自增和自减（++i）
- 【必须】在API中合理使用const
- 【推荐】使用constexpr定义真正的常量或实现常量初始化
- 【推荐】C++内建整型中仅使用int，需要不同大小时使用stdint.h中的精确宽度整数类型
- 【推荐】代码应该对64位和32位系统友好
- 【必须】使用宏时要非常谨慎，尽量以内联函数、枚举和常量代替
- 【必须】整数用0，浮点数用0.0，指针用nullptr或NULL，字符用'\0'
- 【必须】尽可能用sizeof(varname)代替sizeof(type)
- 【推荐】使用类型推导仅在能让代码更清晰或更安全的情况下

## 7. 命名规范
- 【必须】文件名全部小写，可以包含下划线(_)或短横线(-)
- 【必须】类型名称每个单词首字母大写，不包含下划线
- 【必须】变量名一律小写，单词间用下划线连接
- 【必须】常量名声明为constexpr或const的变量，或运行期间值恒定的静态存储期变量，命名以"k"开头，大小写混合
- 【必须】函数名一般来说单词首字母大写，没有下划线
- 【必须】命名空间名全部小写，基于项目名称和目录结构
- 【必须】枚举的命名应当与常量一致
- 【必须】宏命名像枚举命名一样全部大写，使用下划线

## 8. 注释规范
- 【必须】每个文件都要有许可证版本声明
- 【必须】每个类的定义都要附带一份注释，描述类的功能和用法
- 【必须】每个函数声明处的注释描述函数功能；定义处的注释描述函数实现
- 【推荐】对于代码中巧妙的、晦涩的、有趣的、重要的地方加以注释
- 【推荐】使用TODO注释对那些临时的、短期的解决方案，或已经够好但仍不完美的代码进行标记

## 9. 格式规范
- 【必须】每一行代码字符数不超过80
- 【必须】只使用空格，每次缩进2个空格
- 【必须】返回类型和函数名在同一行，参数也尽量放在同一行
- 【必须】函数调用要么一行写完，要么在圆括号里对参数分行，每行一个参数
- 【必须】倾向于不在圆括号内使用空格
- 【必须】倾向于不在方括号内使用空格
- 【必须】大括号不另起新行
- 【必须】在单行语句块内，大括号可选
- 【必须】通常在单行function和选择语句中会要求大括号
- 【必须】指针和引用的操作符前没有空格，紧跟变量名
- 【必须】只有在参数列表为空或者包含单个参数时，布尔条件才可以用圆括号括起来
- 【必须】预处理指令不要缩进，从行首开始
- 【必须】访问控制块的声明依次序是public:、protected:、private:，每个都缩进1个空格
- 【必须】构造函数初始化列表放在同一行或按四空格缩进并排多行
- 【必须】命名空间内容不缩进
- 【必须】合理使用水平留白，永远不要在行尾添加没意义的留白
- 【必须】合理使用空行分隔逻辑相关的代码块

## 10. 异常处理规范（如果使用异常）
- 【必须】制定合适的异常类型体系，只抛出这些类型的对象
- 【必须】按值抛出异常，按引用（或常量引用）捕获异常
- 【必须】不要到处捕获异常，只捕获和处理你能处理的异常
- 【必须】不要用异常来报告代码逻辑错误，应该用assert或类似机制
- 【必须】不要随意忽略异常，如果确实需要忽略，应当有明确的注释/日志说明
- 【必须】不要用异常来代替正常的控制流
- 【必须】确保代码的异常安全，比如用RAII技术来避免资源泄漏
- 【必须】对于会抛出自定义异常的库，要在文档或注释中明确说明

## 11. 现代C++特性使用规范
- 【推荐】优先使用智能指针管理内存
- 【推荐】使用范围for循环替代传统for循环
- 【推荐】使用lambda表达式简化代码
- 【推荐】使用auto关键字进行类型推导（在适当的情况下）
- 【必须】使用nullptr代替NULL
- 【推荐】使用override和final关键字
- 【推荐】使用删除函数(= delete)禁用不需要的函数
- 【推荐】使用默认函数(= default)声明默认实现
- 【推荐】使用初始化列表进行统一初始化
- 【推荐】使用强类型枚举(enum class)
- 【推荐】使用static_assert进行编译时断言

## 12. 特殊规范补充
- 【必须】禁用拷贝构造和赋值操作时，使用= delete而不是私有声明
- 【必须】析构函数如果是虚函数，则应该声明为virtual或override
- 【必须】不要在析构函数中抛出异常
- 【推荐】优先使用基于范围的for循环而不是传统的for循环
- 【必须】不要在头文件中定义宏，必要时在使用后立即#undef
- 【推荐】类成员变量后缀使用下划线(_)
- 【必须】全局变量前缀使用g_
- 【推荐】使用工厂模式而不是Init()函数进行复杂对象初始化
- 【必须】禁止在全局作用域定义未命名的命名空间

【Spring 编程开发指南】

你是一位精通Java编程、Spring Boot、Spring Framework、Maven、JUnit以及相关Java技术的专家。

代码风格与结构
- 使用准确的Spring Boot示例编写干净、高效且有良好文档的Java代码。
- 在整个代码中遵循Spring Boot的最佳实践和约定。
- 创建Web服务时实现RESTful API设计模式。
- 使用遵循驼峰命名规范的描述性方法和变量名。
- 结构化Spring Boot应用程序：控制器、服务、存储库、模型、配置。

Spring Boot特定内容
- 使用Spring Boot starters快速设置项目并进行依赖管理。
- 使用注解的正确方式（例如，@SpringBootApplication、@RestController、@Service）。
- 有效地利用Spring Boot的自动配置功能。
- 使用@ControllerAdvice和@ExceptionHandler实现适当的异常处理。

命名约定
- 类名使用帕斯卡命名法（例如，UserController、OrderService）。
- 方法和变量名使用驼峰命名法（例如，findUserById、isOrderValid）。
- 常量使用全大写（例如，MAX_RETRY_ATTEMPTS、DEFAULT_PAGE_SIZE）。

Java与Spring Boot使用
- 在适用时使用Java 17或更新版本的特性（例如，records、sealed classes、pattern matching）。
- 利用Spring Boot 3.x的特性和最佳实践。
- 在适用时使用Spring Data JPA进行数据库操作。
- 使用Bean Validation实现适当的验证（例如，@Valid、自定义验证器）。

配置与属性
- 使用application.properties或application.yml进行配置。
- 使用Spring Profiles实现特定于环境的配置。
- 使用@ConfigurationProperties进行类型安全的配置属性。

依赖注入与IoC
- 为了更好的可测试性，使用构造函数注入而不是字段注入。
- 利用Spring的IoC容器管理bean的生命周期。

测试
- 使用JUnit 5和Spring Boot Test编写单元测试。
- 使用MockMvc测试Web层。
- 使用@SpringBootTest实现集成测试。
- 使用@DataJpaTest进行存储库层测试。

性能与可扩展性
- 使用Spring Cache抽象实现缓存策略。
- 使用@Async进行非阻塞操作的异步处理。
- 实现适当的数据库索引和查询优化。

安全
- 使用Spring Security进行身份验证和授权。
- 使用适当的密码编码（例如，BCrypt）。
- 必要时实现CORS配置。

日志记录与监控
- 使用SLF4J与Logback进行日志记录。
- 实现适当的日志级别（ERROR、WARN、INFO、DEBUG）。
- 使用Spring Boot Actuator进行应用程序监控和指标收集。

API文档
- 使用Springdoc OpenAPI（前身为Swagger）进行API文档编写。

数据访问与ORM
- 使用Spring Data JPA进行数据库操作。
- 实现适当的实体关系和级联。
- 使用Flyway或Liquibase等工具进行数据库迁移。

构建与部署
- 使用Maven进行依赖管理和构建过程。
- 为不同环境（开发、测试、生产）实现适当的配置文件。
- 如适用，使用Docker进行容器化。

遵循最佳实践：
- RESTful API设计（正确使用HTTP方法、状态码等）。
- 微服务架构（如果适用）。
- 使用Spring的@Async或使用Spring WebFlux进行响应式编程的异步处理。

遵循SOLID原则，在Spring Boot应用程序设计中保持高内聚性和低耦合性。

Rules 管理

如果您希望修改或禁用 Rules，您可以：

• 修改 可以直接在创建的 Rules 文件中进行修改，Agent 会在下次触发分析时自动重新加载这些 Rules。

• 禁用 如果您不需要使用 Rules，可以直接清空 Rules 内容即可，或者直接把 Rules 文件删除。

应用效果

将以下面这个简单的 Rules 为例验证一下应用效果。

你是一个专业的Java开发助手，所有代码必须严格遵循以下编码规范。

**注意：如果没有明确说明，需要遵循Google Java Style Guide。**

## 代码规范等级定义
- **可选（Optional）**：可以参考，根据具体情况决定是否采用
- **推荐（Preferable）**：代码应当遵循，但在特殊情况下可以例外
- **必须（Mandatory）**：代码必须遵循

注：未明确指明的则默认为必须（Mandatory）

## 编程规范原则
- 遵循正确性、可读性、可维护性、可调试性、一致性、美观原则
- 永远不要对代码进行格式化操作，只完成修改代码的任务
- 对不在当前变更范围内的代码，尽量不要进行格式化

## 格式规范

### 【必须】大括号规范
- 所有可以使用大括号的地方都要加上大括号，即使只有一条语句
- 遵循K&R风格：左大括号前不换行，左大括号后换行，右大括号前换行
- 空块可以简洁写成{}，但多块语句中的空块右大括号也要换行

## 特别注意
- 永远不要对代码进行不必要的格式化操作
- 重要规则优先级：【必须】> 【推荐】> 【可选】
- 代码评审时重点关注【必须】级别的规范遵循情况
- 遵守"30秒规则"，提高代码的可读性
- 书写较短的代码行
- 为代码写注释文档
- 将代码从逻辑上分段
- 合理使用空行
- 如需对已有代码进行格式化，建议放置在单独版本中处理

## 重要提醒
在编写代码时，请始终牢记：编码规范的目的是提高代码的正确性、可读性、可维护性、可调试性、一致性和美观性。当遇到特殊情况时，应该优先考虑这些原则，而不是盲目遵循规则。

应用 Rules 前：

应用 Rules 后的效果如下，可以看到，Agent 根据 Rules 中的 “大括号规范” 进行了格式规范的优化。