CodeBuddy 生成的代码默认遵循通用最佳实践，但在实际项目中，团队往往有自己的命名约定、架构分层或格式要求。通过自定义编码规范，你可以让 AI 直接输出符合标准的代码，减少生成后的手动调整。
配置入口与生效范围
- 项目级规范：在项目根目录创建规则文件（如
.codebuddyrules或版本对应的 JSON/YAML 文件），写入团队约定并提交至 Git。CodeBuddy 在索引项目时会自动加载，所有基于该项目的对话与补全都默认遵循。 - 全局规范：在客户端 设置 > 个性化 > 编码规范 中填写个人偏好，适用于所有无项目级配置约束的场景。
- 临时规范：在侧边栏对话中通过
@规则手动引用特定文件（详见 3.4.4），适合为单次任务注入特殊要求，而不影响全局配置。
规则内容编写建议
规则应避免笼统口号，聚焦 AI 容易出错或团队强约束的点：
- 命名与风格：如"变量使用 camelCase，React 组件使用 PascalCase，常量使用 UPPER_SNAKE_CASE"；"缩进为 2 个空格，字符串优先单引号"。
- 架构约束：如"HTTP 请求必须封装在
services/目录，禁止在页面组件内直接调用 axios"；"数据库操作统一使用 ORM，禁止手写拼接 SQL"。 - 语言特性：如"TypeScript 严格模式开启，禁止使用
any"；"Python 类型注解必须标注返回值"。 - 安全与性能：如"用户输入必须做 XSS 过滤"；"循环体内避免重复查询数据库"。
- 注释与文档：如"公共函数必须附带 JSDoc"；"业务代码禁止拼音命名"。
实用技巧
- 给具体阈值，不给抽象描述：与其写"代码要简洁"，不如写"单行不超过 120 字符，函数不超过 50 行"。越可量化，AI 执行越稳定。
- 按技术栈拆分：若项目包含前后端多种语言，可在规则文件内按语言分段（如
frontend:/backend:），或在对应子目录放置独立的规则文件，实现精细化绑定。 - 纳入版本控制：将项目级规则文件加入 Git，并在 README 中说明。新成员 clone 项目后，CodeBuddy 自动同步该规范，保证团队输出风格一致。
- 即时验证：配置完成后，在对话中输入"生成一个用户列表组件"或"写一个订单查询接口"，观察生成结果是否已应用规范。若未生效，检查文件命名是否符合客户端要求，或尝试在对话中手动
@规则文件以强制引用。