引言

近几年，AI编程工具如雨后春笋般涌现而出，这些工具在提高我们编码效率的同时也带来了困扰：有时候生成的代码看似高效，却总因不符合项目规范需要反复调整……这些细节像无形的“效率黑洞”，消耗着我们的时间与精力。

问题的核心或许在于：当前的AI编程工具更擅长“自由生成”，却难以适配我们具体的编码规则——团队需要的不只是“能写代码”的AI，更是“按我们的规矩写代码”的智能助手。

这就需要我们给AI工具制定一个规则，通过自定义配置让AI在编码过程中主动“遵守”我们的规范：从代码缩进、注释格式到业务逻辑约束，从新人上手的“防错指南”到团队协作的“风格统一”，它能让AI从“自由发挥”转向“精准执行”。

今天，笔者将结合实战经验，和大家分享一下在Cursor使用过程中总结的Cursor Rule。如果你也想让AI“听话”，不妨跟着我们一起，把规则变成编码效率的杠杆。

Rule

基础交互规范

• 语言要求：默认情况下，所有回复都必须是中文
• 任务拆解：复杂需求拆解成小任务，分步实现，每完成一个小任务后再继续
• 代码检查：代码实现前后要仔细检查，确保没有遗漏
• 功能保护：在已有功能基础上添加新功能时，必须确保：
  • 不影响原有功能
  • 不添加其他功能、代码、逻辑、文件、配置、依赖
• 架构一致性：遵循架构设计，保持代码风格一致
• 单一职责：代码修改遵循单一职责原则，不混合多个变更
• 设计原则：在进行代码设计规划的时候，请符合"第一性原理"
• 实现原则：在代码实现的时候，请符合"KISS原则"和"SOLID原则"
• 代码复用：尽量复用已有代码，避免重复代码
• 依赖管理：不引入不必要的依赖，避免增加维护成本
• 可读性：确保代码可读性与可维护性，必要时加简要注释
• 变更范围：代码变更范围最小化，避免大范围修改
• 逻辑自检：实现后进行基本逻辑自检，确保无错误
• 疑问处理：如果有疑问，先询问再修改，不要擅自做决定

命名规范

• 包名：全小写，采用公司域名反转+项目+模块（如：com.xxx.xxx.bff）
• 类名：使用大驼峰（PascalCase），如 UserService
• 方法名、变量名：使用小驼峰（camelCase），如 getUserName
• 常量名：禁止使用魔法值，统一用常量或枚举，常量名全大写，单词间用下划线分隔，如 MAX_SIZE
• 函数参数：使用小驼峰，如 userId
• 后缀：DTO/VO/Request/Response 等后缀清晰区分数据类型，明确分层，禁止混用

注释规范

• 所有类、接口、方法必须有 Javadoc 注释，描述其功能、参数、返回值和异常
• 复杂逻辑需有注释，注释内容简明扼要
• 禁止无意义注释（如 // TODO: xxx）
• 禁止行末注释

日志规范

• 日志框架：统一使用 slf4j 作为日志门面
• 日志级别：日志分级合理（info、warn、error），禁止输出敏感信息
• 日志场景：重要操作、异常必须有日志记录
• 日志格式：日志格式统一，可读性高
• 日志脱敏：避免打印敏感信息

依赖管理

• 统一使用 Maven/Gradle 管理依赖，禁止私自引入 jar 包
• 依赖版本需锁定，避免版本冲突

单元测试

• 业务代码必须有单元测试，覆盖率不低于40%
• 测试类与被测类同包，命名为 XxxTest
• 测试用例应覆盖正常、异常、边界情况
• 单元测试覆盖主要业务逻辑，使用 Mock 隔离外部依赖

架构约定

• 遵循分层架构（Controller、Service、Repository/Mapper、Entity、DTO）
• Controller 层只做参数校验和路由，业务逻辑放在 Service 层
• 禁止在 Controller 层直接操作数据库
• DTO 用于数据传输，Entity 仅用于 ORM 映射

异常处理

• 统一使用自定义异常或标准异常，避免抛出Exception
• 异常必须捕获并记录日志，不能直接抛出到最外层
• 关键功能应提供异常处理机制，避免程序崩溃
• 涉及外部调用时，必须进行异常处理并记录日志

代码风格

• 使用 4 个空格缩进，不允许使用 Tab
• 每行代码不超过 120 个字符，必要时换行
• 大括号 {} 换行风格为 K&R（左大括号不换行，右大括号独占一行），且与语句对齐
• 类、方法、变量之间空一行

数据库操作规范

• SQL优化：优先使用MyBatis-Plus的Lambda查询，避免手写SQL
• 事务管理：合理使用@Transactional注解，注意事务传播机制
• 分页查询：大数据量查询必须使用分页，避免全表扫描
• 索引考虑：查询条件要考虑数据库索引，避免慢查询

服务层规范

• 接口设计：Service接口和实现分离，便于测试和扩展
• 参数校验：使用@Valid注解进行参数校验，或手动校验
• 返回值：统一使用Result或JsonResult包装返回结果
• 日志记录：关键业务操作必须记录日志，使用SLF4J

自动执行策略

• 编译验证：自动执行编译、验证等必要流程
• 文件操作：删除、移动、重命名文件等常规操作无需额外确认
• 命令行操作：非关键性指令（如清理缓存、构建项目）可直接执行
• 风险操作：涉及影响较大的操作（如覆盖文件、修改数据库结构）仍需确认

安全备份策略

• 自动备份：重要操作（如文件删除、数据库修改）应自动备份，避免误操作
• SQL脚本：涉及数据库变更的操作，优先生成SQL变更脚本，而非直接执行
• 影响检测：执行高风险操作前，AI代码编辑器应自动检测影响范围，必要时提供提示

Java特定优化

• 内存管理：注意Java内存管理，避免内存泄漏
• 并发安全：多线程环境下注意线程安全，合理使用锁机制
• 资源释放：使用try-with-resources确保资源正确释放

代码库分析

• 功能复用：AI代码编辑器应优先分析现有代码库，避免重复实现已有功能
• 模块复用：在添加新功能时，优先复用已有模块，而非从零编写
• 依赖整理：如遇架构不清晰的情况，先整理依赖关系，再执行修改

Spring生态感知

• Bean管理：合理使用Spring的IoC容器，避免循环依赖
• 配置管理：使用@ConfigurationProperties管理配置，避免硬编码
• AOP使用：合理使用AOP进行横切关注点处理
• 注解使用：合理使用Spring注解，避免过度注解

业务规范

• 状态管理：业务状态变更必须记录操作日志
• 数据校验：关键业务数据必须进行完整性校验
• 权限控制：敏感操作必须进行权限验证
• 审计日志：重要业务操作必须记录审计日志

性能规范

• 缓存使用：合理使用Redis缓存，避免频繁数据库查询
• 异步处理：耗时操作使用异步处理，避免阻塞主线程
• 批量操作：大量数据处理使用批量操作，提高性能
• 性能建议：对于可能影响性能的代码（如SQL查询、循环嵌套），提供优化建议

版本控制

• Commit信息：所有代码变更应附带清晰的commit信息，描述修改点和原因
• 变更日志：对于影响较大的改动（如架构调整），可自动生成变更日志
• API兼容：如涉及API变更，应提供新旧版本兼容策略

总结

总而言之，Cursor Rule的核心价值在于为AI编程工具装上“规则开关”——它打破了传统AI“自由生成”的局限性，通过自定义规则库让代码从“可能合规”变为“必然合规”。无论是减少重复编码的机械劳动，还是统一团队协作中的代码风格，亦或是避免AI生成代码的“返工陷阱”，Cursor Rule都通过“规则前置”的方式，将效率提升从“被动优化”转向“主动可控”。

对于开发者而言，掌握Cursor Rule不仅是学会一个工具的使用，更是学会用“规则思维”重新定义编码流程：当AI开始“听话”，我们的精力才能真正从“纠偏”转向“创造”。这或许就是智能编程时代，开发者最值得掌握的“效率杠杆”。

上述规则也可用于其他AI编程工具，欢迎大家在评论区留下你的AI编程工具使用心得～