一、项目背景：95%代码交给AI
2025年11月后，AI编程有了显著突破。一个原本估时100人日的新APP项目（包括用户体系、即时通信、会话管理、内容审核、支付钱包、推送通知、活动系统、任务系统等20多个业务模块），团队决定让AI承担95%的代码编写工作。
项目最终数据：15个工作日完成，10万行+代码，674个文件，199次Git提交，20多个业务模块，Token费用约2万元人民币。
二、核心工作流：Leader-Worker-Judge
区别于传统开发流程，这套AI编程方法有三个关键不同点：
2.1 砍掉需求评审，AI Leader一小时搞定对齐
传统”评审会→设计稿→定接口→排期”的串行流程跟不上需求变化。砍掉评审会后，需求来了直接进入AI Leader模式——AI会针对异常处理、状态流转、边界情况提问，不少问题连人类开发者都没想到。
2.2 AI用例逐条逻辑校验
这一步是整个流程ROI最高的环节。测试和产品先人工过用例，补齐需求文档里的细节和边界；然后把测试用例和全量代码一起喂给AI，让它逐条对照做逻辑校验。
举个例子：有一条用例”用户余额不足时下单应该返回失败”，测试传了余额0，确实会走到余额不足分支。但如果余额是正数但小于商品价格呢？代码里这个分支根本没有用例覆盖。测试只能告诉你”用例过了还是没过”，AI能告诉你”这个用例虽然过了，但它没测到你以为它测到的那个场景”。
三、Rules体系：AI的”员工手册”
把Code Review该关注的东西提前写成规则文件，让AI写代码时就遵守。这套Rules体系包含四份文件：
3.1 设计原则——红线禁令+传统工程原则
4条红线：
- 逻辑收口：同一职责只有一个归属，禁止相同逻辑多处各写一份
- 复用优先：新增代码前必须搜索已有逻辑，禁止复制-粘贴-微调
- 禁止循环依赖：模块间依赖必须是DAG，新增依赖时递归展开至少3跳验证
- 禁止魔法值：所有业务语义值用枚举/常量，禁止硬编码
9条重要原则：幂等性、防御性编程、副作用可预测、优雅降级、可测试性、日志有效性、开闭原则、模块化设计、设计模式使用。每条原则都附带明确的判定标准和代码示例。
3.2 项目架构——域边界表+数据访问分层
20多个域全列出来，每个域写清楚入口Service和DAO。AI写代码前先查：”这个功能归谁管？数据找谁要？”
数据访问分层约束：
- Controller层——接收请求、参数校验，禁止写业务逻辑
- Service层——核心业务逻辑，分编排Service（跨域流程）和领域Service（单域核心逻辑）
- Repository层——数据聚合+缓存，只调DAO，是依赖图的叶子节点
- DAO层——直接操作数据库，一个DAO对应一张表
3.3 编码规范——统一风格
依赖注入用构造器注入、异常处理统一抛自定义异常、返回值统一包装、日志按级别使用、安全用SQL参数化查询。这份规范保证5个并行的AI对话产出风格一致的代码。
3.4 开发流程——角色切换定义
通过关键词切换AI行为模式：
- Leader（规划）：关键词”分析需求/方案设计/定接口”，多问少做，产出技术方案和API骨架
- Worker（执行）：关键词”开始开发/写代码”，专注执行不发散，先读懂现有代码再改
- Judge（审查）：关键词”review/跑测试/能部署了吗”，严格验证，给出证据再下结论
- BugFix：四步闭环——定位根因→最小改动→补测试→跑测试通过
四、测试分层规范
什么改动写什么测试：
- Service内部逻辑分支 → 必须单元测试
- 新增或修改API接口 → 必须API集成测试
- 多API交互流程 → 必须流程串联测试
- 仅改工具类/枚举 → 必须单元测试
单元测试跑得快能抓逻辑分支错误，但只有API集成测试（跑真实数据库容器）才能抓到”数据库里真的写进去了吗”这类问题。
五、六个真实踩坑案例
坑1：别第一天就搞微服务
Day 1搭了一套Spring Cloud——5个独立服务+API网关+注册中心，当天全推翻改成单体多模块。AI coding有个硬性前提：所有代码在一个项目里，本地能跑起来。拆成微服务后，AI写订单模块时看不到用户模块的代码，跨服务调用全靠猜。
坑2：一个窗口聊到底，不如勤开新窗口
最长一次对话1800条消息后，AI明显开始忘事。摸索出的原则：新模块、新功能、Judge审查、BugFix——全部开新窗口。对话会忘，文件不会。
坑3：修Bug别让AI”顺手优化”
让AI修一个空指针，它修完了但顺手把整个方法重构了——变量名全改、代码结构调整。空指针好了，新来俩Bug。现在BugFix模式写死四步：定位根因→最小改动→补测试→跑通。想重构？开个新窗口。
坑4：手动改了一半代码，AI给你改回去
有时手动改几行但改得不彻底，只改了主代码，单测、plan忘了同步。下次让AI改这个模块时，它会把你手动改的那一处也改回去。建议：尽量都让AI改，它会全局搜索关联位置一起改。
坑5：AI看不见”全局”
AI单文件能力很强，但跨文件重复、命名不一致、潜在性能问题基本看不见。死代码也不会清除干净。解法是让Checkstyle、PMD、SpotBugs这些专业工具做全局扫描——AI负责写，工具负责查，人负责判断。
坑6：跟AI对话，名称得稳定
第一次叫”积分发放”，第二次叫”奖励逻辑”，第三次叫”活动结算”——AI会以为这是三个不同的东西，给你写三份代码。方案文档里每个功能点有唯一名称，对话里严格用这个名称，不用同义词、不用缩写。
六、结语：AI编程的瓶颈不在AI，在你
同样是Cursor+Claude Opus，不给它立规矩就是”第一天爽，第三天乱，第五天想重写”。给它一套完善的Rules就能稳定输出。这跟带团队一个道理——招来的人再厉害，没有规范、没有流程、没有测试要求，项目一样烂。AI也是。
这套Rules模板已开源至GitHub，包含通用层、技术栈层、项目层三部分，可直接用于任何AI编程项目。