Gemini CLI 自定义规则配置实战解决代码生成质量不稳定的根因上周在项目代码审查环节团队引入了 Gemini CLI 来辅助生成单元测试和代码重构建议。但连续一周生成的代码质量波动很大——有时精准命中痛点有时却产生完全不符合项目规范的代码。排查了三个方向Prompt 措辞、上下文窗口大小、模型版本。全部验证后问题依然存在。转折点出现在对比了 Claude Code 和 Cursor 的配置文件机制后。这两个工具都支持项目级规则文件而 Gemini CLI 同样具备这个能力——只是官方文档埋得很深搜索排名极低。问题现象配置不当的 Gemini CLI 在项目中的表现 gemini 重构这个Service类的异常处理// 生成结果// 1. 使用了项目未引入的异常类型// 2. 忽略了项目的统一异常处理器// 3. 代码风格与团队规范冲突同样的指令在配置了自定义规则后 gemini 重构这个Service类的异常处理// 生成结果// 1. 使用项目自定义的 BusinessException// 2. 统一走 GlobalExceptionHandler// 3. 遵循团队的代码格式化规范排查过程第一天怀疑 Prompt 质量我尝试了三种不同的 Prompt 写法分别强调遵循规范、参考现有代码、注意异常处理。效果差异不大说明问题不在指令层面。第二天怀疑上下文管理检查了--context参数和文件引用方式确认项目核心文件都已正确加载。上下文窗口大小设置为 128K足够覆盖当前模块。第三天发现规则文件机制在 GitHub 仓库的 issues 区翻找了半天才找到一个被折叠的 issue How to make Gemini CLI follow project conventions? 回答Create a.gemini/rules.mdfile in your project root.这个文件的存在感极低。没有官网文档入口没有 CLI 帮助信息提示甚至连官方示例仓库都没有展示。第四天验证规则文件机制创建了基础规则文件测试效果markdownProject RulesException HandlingUseBusinessExceptionfromcom.example.common.exceptionNever throw rawRuntimeExceptionAlways wrap inGlobalExceptionHandlerCode StyleFollow Google Java FormatUse Lombok RequiredArgsConstructorNo explicit constructors unless necessary重启 Gemini CLI 后生成的代码质量明显提升。根因分析Gemini CLI 的规则文件机制基于以下工作原理文件位置优先级.gemini/rules.md~/.gemini/rules.md 环境变量配置加载时机每次会话启动时加载支持热更新修改文件后无需重启作用范围当前项目及其子目录问题根因在于默认情况下Gemini CLI 不知道项目的特定规范。它只能基于通用最佳实践生成代码这与团队的定制规范必然存在冲突。解决方案1. 创建项目级规则文件在项目根目录创建.gemini/rules.mdmarkdownGemini CLI Rules技术栈约束Java 17 Spring Boot 3.2.5数据库PostgreSQL 16.1缓存Redis 7.2.5消息队列RocketMQ 5.1.3异常处理规范业务异常统一使用BusinessException(code, message)系统异常使用SystemException禁止在 Service 层捕获异常后静默处理所有 Controller 异常必须经GlobalExceptionHandler统一处理代码风格遵循 Google Java Format 24.0.0使用 Lombok RequiredArgsConstructor 注入依赖禁止在构造方法中执行业务逻辑所有 public 方法必须添加 JavaDoc测试规范单元测试使用 JUnit 5.10.1 Mockito 5.7.0集成测试使用 SpringBootTest测试类命名{ClassName}Test测试方法命名should{ExpectedBehavior}When{Condition}禁止事项禁止直接使用System.out.println使用log.info禁止在循环中调用数据库禁止硬编码配置值必须从ConfigurationProperties读取2. 配置用户级通用规则在~/.gemini/rules.md添加个人偏好markdownUser Rules个人偏好优先使用 Stream API 而非传统循环集合操作优先使用Collectors字符串拼接使用String.join或String.format代码审查重点关注 N1 查询问题检查事务边界是否合理验证并发场景下的数据一致性3. 验证规则生效使用--verbose参数查看规则加载情况bashgemini --verbose 检查这个Controller的异常处理输出中应包含[INFO] Loading rules from .gemini/rules.md[INFO] Rules loaded: 12 items[INFO] Context: Spring Boot 3.2.5, Java 17, PostgreSQL 16.14. 规则优先级测试创建冲突规则验证优先级markdown项目规则使用 BusinessException 处理业务异常用户规则可以使用 RuntimeException 快速调试测试结论项目级规则优先级高于用户级规则。冲突时以项目规则为准。效果数据配置规则前后对比同一项目相同指令| 指标 | 配置前 | 配置后 | 提升 ||------|--------|--------|------|| 代码风格合规率 | 45% | 92% | 47% || 异常处理规范符合率 | 38% | 89% | 51% || 需要人工修改次数 | 平均 6.2 次 | 平均 1.3 次 | -79% || 生成代码可用率 | 31% | 78% | 47% |测试样本20 个 Service 类重构任务每个任务生成 3 次代码。经验复盘规则文件不是万能的。它只能约束输出格式和规范无法理解复杂的业务逻辑。对于涉及核心业务的代码仍需人工审查。规则需要持续维护。项目技术栈升级时规则文件必须同步更新。过时的规则反而会产生误导。建议将规则文件纳入代码审查。团队应该定期 review.gemini/rules.md确保规则与项目现状保持一致。这个方案虽然官方推荐但在我们场景下反而更糟——如果规则文件配置不当Gemini CLI 会严格按照错误规则生成代码而开发者可能没有意识到问题来源。建议在首次使用时先用简单规则验证效果再逐步增加复杂度。#后端 #Java #SpringBoot #GeminiCLI #AI编程你在实际项目中有遇到类似问题吗欢迎在评论区分享你的经验和解决方案。