如何用 AI 写出符合规范的 Java 代码？我总结了 7 条有效建议

不是吹嘘 AI 多强，也不是抱怨 AI 多蠢。这篇文章只讲一件事：作为一个写 Java 的，怎么让 AI 真正帮你提高效率和质量。

我从三个月前开始在日常工作中重度使用 AI 编码（项目有非常严格的规范）。踩过坑、也摸索出了一些方法。下面 7 条建议，每一条都是我自己验证过的。

建议一：写提示词时，把"规范要求"当作第一优先级

大多数人的提示词只描述"我要什么功能"，但忘了告诉 AI "你不能怎么做" 。

错误示例：

帮我写一个用户签到的接口。

正确示例（以你们项目的规范为例）：

写一个用户签到接口，要求：

查询 da_sign_record 表判断今日是否已签到 ------ SQL 必须手写在 XML，禁止 SELECT *

增加用户绘点（10点）------ 必须调用 IUserWalletManager.addUserPoints

加分布式锁，锁 Key 用 CacheConstants.USER_SIGN_LOCK_KEY 前缀

方法如果超过 3 个参数，用 Request 对象封装

所有注释用中文，类上带 @author

有效建议：

把你的项目规范（或者最关键的那几条）做成一个 "约束清单" ，每次让 AI 生成代码前，先贴几行约束。
如果你用 Cursor 这类能读取项目文件的工具，直接把 AGENTS.md 或规范文件拖进去，告诉 AI"先读这个"。
说清楚禁止项比说清楚要做的事更重要。

建议二：把需求拆成"核验 → 执行 → 后置"三步，分步让 AI 生成

一次性让 AI 生成整个复杂功能，它大概率会在某个细节翻车。拆开做，每一步都能 review。

示例（做一个"领取优惠券"功能）：

第 1 步：让 AI 只生成"校验用户今日是否已领过"的 SQL 和代码。

生成一个方法：根据 userId 和 couponId，查询 da_user_coupon 表今日是否已有记录。手写 XML，返回 boolean。

第 2 步：确认第一步没问题后，再让 AI 生成"扣减库存 + 插入领用记录"的核心逻辑。

第 3 步：最后让 AI 加上事务和分布式锁。

有效建议：

每生成一小段，立刻跑一下单元测试（也可以让 AI 帮你写测试）。
不要怕多轮对话，这比改一整段错误代码要快得多。

建议三：先让 AI 写单元测试，再写实现

这是我用过的最有效的质量保障方法。测试用例其实就是"需求的形式化描述"。让 AI 先写测试，它会把边界条件、异常情况都想一遍。

做法：

你写一个接口定义（或仅是一个方法签名）。
告诉 AI："根据这个接口，生成 JUnit 5 + Mockito 的单元测试，覆盖正常、参数为空、并发、重复请求等场景。"
拿到测试代码，人工调整一下断言逻辑。
再让 AI："根据这些测试用例，生成能通过所有测试的实现代码。"

效果：AI 写出来的代码，边界处理明显更完整。

有效建议：

如果你项目里已经有类似功能的测试类，把那个类贴给 AI 作为参考。
对于资金、库存等核心功能，这一步不能省。

建议四：用"检查清单"让 AI 做代码审查

你们项目的 规范-检查清单.md 是一个宝库。不要只给人看，也给 AI 看。

做法：

复制检查清单的内容。
贴上一段你写好的（或 AI 生成的）代码。
问 AI："根据这份检查清单，逐条核查这段代码，指出不符合项。"

实际效果 ：

AI 会发现诸如"SQL 中使用了 SELECT *"、"事务注解放在了 Controller 上"、"Redis key 硬编码了"这类人工容易忽略的问题。

有效建议：

养成习惯：每次 commit 前，让 AI 跑一次检查清单。
把检查清单做成一个"系统提示词"，在对话开始时就让 AI 加载。

建议五：针对不同任务，选对 AI 工具/模型

不是所有 AI 都一样。我用下来最直观的分工：

任务类型	推荐工具/模型	原因
日常写 CRUD、写工具类、写 getter/setter	GitHub Copilot（原 Codex 系列）	自动补全最快，不打断思路
复杂业务逻辑、需要理解项目规范的文件	Cursor + Claude	能读整个项目，理解 AGENTS.md，按规范生成代码
写国产中间件（Dubbo、RocketMQ）代码	通义灵码	示例代码最全，中文理解好
代码审查、检查规范符合性	Claude（任何能长上下文的工具）	适合逐条比对检查清单

有效建议：

不要只用一个工具。Copilot 开在 IDE 里，Cursor 随时打开处理复杂任务。
如果你只能用免费工具，CodeWhisperer + 自己写提示词也能凑合，但效率低不少。

建议六：维护你自己的"AI 提示词片段库"

不要每次都重新写提示词。把你常用的、效果好的提示词存下来。

我的片段库长这样（存于一个 Markdown 文件）：

markdown 复制代码

## 生成 Manager 层方法
> 生成 Manager 接口和实现类，业务逻辑放在实现类。要求：
> - 使用 @Transactional(rollbackFor = Exception.class)
> - 涉及钱包必须用 IUserWalletManager
> - 参数超过 3 个用 Request 对象
> - 中文注释，带 @author

## 生成手写 SQL
> 为下面的方法生成 MyBatis XML SQL：
> - 禁止 SELECT *
> - if 条件判断用 `<if test="... != null">`
> - 分页用 limit，不要用物理分页插件

## AI 代码审查
> 根据以下检查清单，逐项检查代码：
> [粘贴清单]
> 代码：
> [粘贴代码]

有效建议：

每当你发现一个提示词效果好，就把它存下来，下次直接改几个词复用。
团队可以共享一个提示词库，保持一致性。

建议七：知道什么时候不该用 AI

这是"有效使用"里最重要的一条。我总结了几个绝对不让 AI 碰的领域：

复杂的资金计算：比如佣金分成、退款金额核算。AI 对业务规则的理解可能漏掉细节。
并发控制的核心逻辑：AI 生成的分布式锁代码看起来没问题，但可能在 finally 块里 unlock 的位置出错，导致锁永不释放。
多表联查的复杂 SQL：AI 生成的 SQL 逻辑可能正确，但索引选择一塌糊涂。必须人工 review 执行计划。
生产环境的数据修复脚本：永远不要让 AI 生成直接操作生产数据的脚本。

有效建议：

把 AI 当成"高级代码补全 + 实习生级代码生成器"，而不是"架构师"。
你越懂的东西，用 AI 效率越高；你不懂的东西，用 AI 反而危险。

最后总结一下

想让 AI 真正帮你提效，不是把它当成神仙，而是把它当成一个懂基本语法但不懂业务规则的实习生。你需要做的是：

给清晰的约束（规范、禁止项）
拆解任务（分步生成）
用测试兜底（先写测试）
用检查清单审查（让 AI 自己审自己）
选对工具（任务不同，模型不同）
维护片段库（复用有效提示词）
知道边界（哪些事不让 AI 做）

做到这些，你的代码规范通过率会提高，重复劳动会减少，而且------你依然对每一行代码负责。