夜雨聆风很多开发同学用 AI 写代码，刚开始都觉得爽。
丢一句话给 Cursor 或 Claude Code："帮我加一个订单查询接口。"几分钟后，Controller、Service、Repository 全出来了。
再过几分钟，问题也来了：参数校验没做，异常处理绕过了统一规范，事务边界写得很随意，DTO 和 Entity 混着用，权限校验漏了，测试也没有。
你让它改，它能改。改完又冒新问题。
于是很多人得出一个结论：AI 写代码还是不靠谱。
但我观察下来，大部分情况不是 AI 不行，是我们把它当成了自由发挥的外包——没给项目上下文，没给分层规则，没给接口规范，没给异常规范，也没给自动检查。AI 只能猜你的工程习惯。
这就像招了个执行力强的新人，但不给文档，不讲分层，不说权限模型，然后指望他一次写出生产级代码。不现实。
能把 AI 编程用起来的人，做的不是研究神奇 Prompt，而是搭一套 Harness——给 AI 套上缰绳、护栏和工作流，让它在设计好的轨道里跑。
好消息是，这事不需要大团队，也不需要复杂平台。一个 Spring Boot 项目，今天就能开始。
第一步：写一个 AGENTS.md
如果你只能做一件事，我建议先写这个。
AGENTS.md 本质上是给 AI 看的项目说明书。人类新人入职需要 onboarding 文档，AI 进你的代码仓库也需要上下文。
一个最小可用的版本长这样：
# AGENTS.md## 项目简介面向中小企业的订单管理系统，Spring Boot + Java 17 + MySQL + Redis## 仓库结构src/main/java/com/example/order/├── controller/ 接口入口层，只做请求参数和响应封装├── service/ 业务逻辑层├── repository/ 数据访问层├── domain/ 领域对象和实体├── dto/ 入参对象├── vo/ 出参对象├── config/ 配置类└── common/ 通用工具、异常、响应结构## 核心规则1. Controller 不写业务逻辑，只做参数校验、调用 Service、返回结果2. 所有入参必须使用 Bean Validation（@Valid、@NotNull、@NotBlank）3. Entity 不直接返回前端，必须转 VO4. 多表写入必须明确事务边界（@Transactional）5. 异常走统一处理，禁止 printStackTrace6. 新增核心业务逻辑必须补单元测试## 常用命令- 运行：mvn spring-boot:run- 测试：mvn test- 检查：mvn checkstyle:check- 打包：mvn clean package## 参考文档- 接口规范：docs/API.md- 数据库设计：docs/DATABASE.md- 异常码：docs/ERROR_CODE.md别小看这个文件。它解决的是 AI 写代码时最高频的那些问题：不知道分层、不知道返回格式、不知道异常怎么处理、不知道能不能暴露 Entity、不知道什么时候该加事务。
写 AGENTS.md 有个诀窍：不要写一堆漂亮但没人遵守的空话，写你项目里真实踩过的坑。
比如这些就比"保持代码整洁"有用得多：
• Controller 不能直接访问 Repository • 新增接口必须补错误码 • 金额字段必须用 BigDecimal，禁用 double • 数据库写操作要考虑幂等 • 用户数据接口必须校验登录态
规则越具体，AI 越容易执行。建议控制在几十行以内。
第二步：把规则变成自动检查
只写 AGENTS.md 还不够，文档是软约束，工具才是硬约束。
Spring Boot 项目可以从四件事起步：
Checkstyle — 统一代码风格
在 pom.xml 加这段：
<plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-checkstyle-plugin</artifactId><version>3.3.1</version><configuration><configLocation>google_checks.xml</configLocation><encoding>UTF-8</encoding><consoleOutput>true</consoleOutput><failsOnError>true</failsOnError></configuration><executions><execution><phase>verify</phase><goals><goal>check</goal></goals></execution></executions></plugin>SpotBugs — 扫描潜在 Bug
<plugin><groupId>com.github.spotbugs</groupId><artifactId>spotbugs-maven-plugin</artifactId><version>4.8.6.2</version><configuration><effort>Max</effort><threshold>Medium</threshold></configuration></plugin>JUnit — 给 AI 一个可验证的目标
别一上来追求 90% 覆盖率，先从最核心的业务逻辑开始：订单金额计算、退款规则、库存扣减、优惠券核销、状态机流转。
一个简单的 Service 测试：
classOrderServiceTest{privateOrderService orderService;@BeforeEachvoidsetUp(){ orderService =newOrderService();}@Testvoid 应该正确计算优惠券后的支付金额(){BigDecimal total =newBigDecimal("100.00");BigDecimal coupon =newBigDecimal("30.00");assertEquals(newBigDecimal("70.00"), orderService.calculatePayAmount(total, coupon));}@Testvoid 优惠券金额为负数时应抛异常(){assertThrows(IllegalArgumentException.class,()->{ orderService.calculatePayAmount(newBigDecimal("100.00"),newBigDecimal("-1.00"));});}}配好之后，AI 写完代码不是你凭感觉说"差不多"，而是跑这三条命令：
mvn testmvn checkstyle:checkmvn clean package能过再进人工 Review，不能过先让 AI 自己修。
第三步：挂上 Git 提交前检查
有了检查和测试，下一步挂到 Git 流程里。Java 后端项目可以用 pre-commit：
# .pre-commit-config.yamlrepos:-repo: localhooks:-id: maven-testname: Run Maven Testentry: mvn testlanguage: systempass_filenames:false-id: maven-checkstylename: Run Checkstyleentry: mvn checkstyle:checklanguage: systempass_filenames:false安装：pre-commit install
之后每次 git commit，系统会自动跑一轮基础检查。
这一步的价值在于：AI 写代码最大的问题不是完全不会写，而是经常写出"看着能跑但细节不稳"的代码。 提交前检查就是个最小质量闸门，拦住格式不统一、测试不过、构建失败这类低级问题。
第四步：别再用"许愿式开发"
很多人用 AI 写代码的流程是这样的：打开工具 → 输入"帮我做一个订单接口" → 全部接受 → 出问题再补救。
这种方式叫 Vibe Coding。问题是：设计和实现都交给 AI 了。但现阶段 AI 更适合做执行，不适合替你做业务判断和架构取舍。
后端开发里真正重要的往往不是"能不能写出接口"，而是这些事：
• 接口边界怎么定 • 事务边界放哪 • 异常怎么表达 • 权限在哪校验 • 幺等怎么处理 • 数据一致性怎么保证 • 哪些同步、哪些异步
这些判断不能完全丢给 AI。更稳的方式是：你负责设计，AI 负责实现。
花 5-10 分钟写清楚任务说明，比后面反复改省时间得多。比如这样：
任务：新增订单取消接口
目标：用户可取消自己未支付的订单接口：
POST /api/orders/{orderId}/cancel业务规则：
1. 只有 WAIT_PAY 状态可取消 2. 已支付/已发货/已取消不可重复取消 3. 取消后状态更新为 CANCELED 4. 锁定库存的需要释放 5. 整个流程必须在同一事务内完成 异常码：
• ORDER_NOT_FOUND（订单不存在） • ORDER_ACCESS_DENIED（无权限） • ORDER_STATUS_NOT_ALLOWED（状态不允许） 改动范围：OrderController / OrderService / OrderRepository / InventoryService / ErrorCode / 对应测试不要动：支付回调逻辑、订单创建逻辑验证：
mvn test→mvn checkstyle:check→mvn clean package
你看，这就跟一句"帮我写个取消订单接口"完全不一样了。任务越清楚，AI 走偏的概率越低。
第五步：建立人机循环
一个比较健康的 AI 后端开发节奏，我拆成五步：
① 你写任务说明
这一步别偷懒。任务说明是方向盘，不是装饰品。上面第四段的模板可以直接复用。
② 让 AI 读代码、改代码、跑测试
不用每行都盯着。AI 的价值就是替你干执行层的体力活。
③ 看 diff
重点看这几件事：Controller 有没有塞业务逻辑；事务边界合不合理；查询有没有性能风险；异常走没走统一错误码；权限漏没漏；Entity 有没有直接暴露；有没有动不该动的模块。
④ 跑验证命令
mvn test + mvn checkstyle:check + mvn clean package，有集成测试也一起跑。
⑤ 有问题写评论，让 AI 修
别一看到问题自己上手改。写成具体反馈扔回去：
• "OrderController 不要写状态判断，移到 OrderService" • "cancelOrder 涉及状态更新和库存释放，加 @Transactional" • "不能直接返回 OrderEntity，转 OrderVO" • "别抛 RuntimeException，用 BusinessException + ErrorCode"
反馈越具体，下一轮越稳定。
这套循环跑顺之后，你的角色会变。不再是逐行搬砖，更像技术负责人：定义目标、制定边界、设计规则、验收结果。AI 干执行。这是比较合理的人机分工。
第六步：每周 15 分钟"后端园艺"
AI 用多了，代码库里会慢慢积累一些"能用但工程味不一致"的东西。建议每周留 15 分钟做轻量整理：
Harness 不是一次性配置，是持续演化的系统。每沉淀一条规则，少一次人工提醒，AI 执行就更稳一点。时间长了，这就是复利。
30 天实践路线
想动手的话，可以按这个节奏来：
30 天后你不一定有完美的系统，但能明显感觉到：AI 从一个随机发挥的聊天框，变成了一个可管理、可约束、可复用的工程助手。
最后说几句
AI 编程的分水岭，不是你用了哪个模型或买了哪个插件。而是你有没有意识到一件事：AI 更像一个执行力很强但需要明确规则的协作者，而不是替你承担所有设计判断的救世主。
不给上下文，它就猜；不给分层，Controller 就写成大杂烩；不给异常规范，随手抛 RuntimeException；不给事务边界，就可能写出半成功半失败的流程；不给检查，就把问题留给你。
所以别再死磕"一句神奇 Prompt 打天下"了。从今天开始做三件小事：
这就是普通开发者的第一个 Harness 工作流。把你的判断沉淀成规则、文档和自动化流程，AI 就不再是灵感的玩具，而是能长期产生复利的生产工具。
