腾讯云代码助手 CodeBuddy 支持您自定义项目级规则（Rules），通过给大模型提供上下文，从而规范模型的行为。
创建 Rules
CodeBuddy 默认已经启用 Rules 功能，无需手动开启，允许您自定义项目级别的 Rules。当您首次启动项目时，CodeBuddy 会自动在项目根目录下创建 .codebuddy/rules 目录，您可以在该目录下创建 Rules 文件，例如：
在 Rules 文件中，您可以自定义项目 Rules，例如项目规范、框架约定、库使用规则、编码安全要求等等。这些 Rules 在定义好后会在当前项目中生效，在每次重新启动或重载项目时会自动扫描并加载 .codeBuddy/rules 目录下的 Rules 文件，并且适用于所有对话请求和内联对话请求中。可用于代码优化建议、安全检查或代码智能分析等方面，实现团队的规则统一管理，提升代码质量和开发效率。
参考案例
在编写 Rules 内容时，可参考下面的例子：
你是一个专业的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()函数进行复杂对象初始化- 【必须】禁止在全局作用域定义未命名的命名空间
你是一位精通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 中的 “大括号规范”进行了格式规范的优化。
