如果你正在考虑把AI编程引入生产项目，这篇复盘值得一读。某中厂Java后端团队用Cursor+Claude Opus 4.6，15天人效完成原本需要100人日的APP项目，AI代码占比达95%。以下是关键经验总结。

一、为什么AI编程在生产级项目里「用了但没完全用」

很多团队遇到同一个困境：AI辅助写代码看起来很美，但真正用到生产上却发现「不review不敢用，review完觉得自己写更快」。原因在于代码库大、逻辑复杂时，AI输出的代码质量无法保证。

突破口在两个条件同时满足时出现：AI对代码结构的理解能力突破 + 给AI一套明确的「员工手册」。后者比前者更重要。

二、核心工作流：砍掉评审会，用AI做需求对齐

传统流程是「评审会→设计稿→定接口→排期」，串行且响应慢。中厂团队的打法是直接进入「AI Leader模式」：需求来了直接和AI对齐，AI会针对异常处理、状态流转、边界情况提问，这些问题往往是人想不到的。

核心差异在于：传统评审会是人在对齐，AI Leader模式是AI在对齐过程中主动暴露问题。

三、规则文件体系：给AI立规矩

这套Rules文件是整个体系的灵魂，分为四层：

1. 设计原则（红线禁令+自检清单）

4条红线：逻辑收口（禁止相同逻辑多处各写一份）、复用优先（禁止复制粘贴微调）、禁止循环依赖、禁止魔法值。

9条原则：幂等性、防御性编程、副作用可预测、优雅降级、可测试性、日志有效性、开闭原则、模块化设计、设计模式使用。

经验是「多写禁止，少写建议」——AI对明确禁令执行力接近100%。

2. 项目架构（域边界表+数据访问分层）

域边界表把20多个业务模块全列出来，每个域写清楚入口Service和DAO。数据访问严格分层：Controller→Service→DAO，禁止跨层调用。

3. 编码规范（统一风格）

用构造器注入、日志规范、安全规范（SQL参数化）。目的是让5个并行的AI对话产出风格一致的代码。

4. 开发流程（角色切换+测试分层）

三个角色：Leader（规划）、Worker（执行）、Judge（审查）。关键词切换行为模式。

测试三分法：单元测试（Service内部逻辑分支）→ API集成测试（单接口全链路）→ 流程串联测试（多接口业务流程）。

四、AI用例逐条校验：ROI最高的环节

测试和产品先人工过一遍用例，补齐需求文档里的细节和边界。然后把测试用例和全量代码一起喂给AI，让AI逐条做逻辑校验。

关键价值：AI能发现「用例通过了但没测到真正场景」的问题。比如「余额0时下单失败」用例通过了，但「余额正数但不足」这个分支根本没有用例覆盖。

五、六个踩坑经验

坑1：第一天别搞微服务。AI coding硬性前提是所有代码在一个项目里、能本地跑起来。拆成微服务后AI看不到跨服务代码，本地要同时跑5个服务，调试成本极高。建议单体多模块，够用就好。

坑2：勤开新窗口。单次对话超过1800条消息后AI明显忘事。建议新模块、新功能、Judge审查、BugFix全部开新窗口，每个窗口上下文独立，文件持久化做记忆。

坑3：修Bug别让AI顺手优化。让AI修空指针，它可能顺手把整个方法重构了——变量名全改、代码结构全调。BugFix模式要锁定四步：定位根因→最小改动→补测试→跑通。

坑4：手动改了一半的代码，AI会改回去。人手动改了几行但没改单测没改plan，AI下次读到会以「原来逻辑应该是那样」把你手动改的也改回去。解法：尽量让AI改，全局搜索关联位置一起改。

坑5：AI看不见「全局」。跨文件重复、命名不一致、死代码，AI单文件能力强但全局维度基本盲区。解法：静态检查工具（Checkstyle/PMD/ SpotBugs）做基础扫描，AI做精准修复。

坑6：对话里名称要稳定。第一次叫「积分发放」，第二次叫「奖励逻辑」，第三次叫「活动结算」——AI会以为这是三个不同的东西。方案文档里每个功能点要有唯一名称，对话里严格用这个词。

六、能直接抄的部分

Rules按「换个项目要改多少」分三层：

通用层（直接复制，5分钟，任何语言框架都适用）：Leader-Worker-Judge流程、禁令清单、自检清单。

技术栈层（半小时改完）：编码规范、工程原则、质量工具+测试分层配置。

项目层（必须根据自己项目写）：域边界表、配置项清单、业务枚举。

写在最后

AI编程的瓶颈不在AI，在人。同样是Cursor+Claude Opus，不给规矩就是「第一天爽，第三天乱，第五天想重写」。给规矩就能稳定输出。

这跟带团队一个道理——招来的人再厉害，没有规范、没有流程、没有测试要求，项目一样烂。AI也是。

先跑起来，边用边踩坑，边踩坑边加规则。这套系统会越用越值钱。