一、背景与成果
一名 9 年中厂 Java 后端工程师，在接到一个新 APP 项目时（预估 100 人日工作量），选择用 AI 编程完成。最终成果：
- 开发周期：15 个工作日
- 工具：Cursor + Claude Opus 4.6
- AI 代码占比：~95%
- 代码规模：10 万行+，674 个文件
- Token 费用：~2 万元人民币
项目包含 20+ 业务模块：用户体系、即时通信、会话管理、内容审核、支付钱包、推送通知、活动系统、任务系统、发现页等。
二、核心发现：传统工程经验在 AI 时代更值钱
很多人觉得 AI 编程时代传统架构经验没用了。实际体验恰恰相反——传统软件工程的分层思想、设计原则，在 AI 开发时代反而更重要。
因为人可以凭直觉把代码放对地方，AI 不行。你的架构经验越扎实，写出来的 Rules 就越精准，AI 产出的代码质量就越高。经验不是被替代了，是换了一种方式发挥价值——从「自己写好代码」变成「教 AI 写好代码」。
三、AI 编程的正确工作流：Leader-Worker-Judge
与传统的「评审会→设计稿→定接口→排期」串行流程不同，AI 编程采用三角色切换模式：
3.1 Leader（规划阶段）
关键词：分析需求 / 方案设计 / 定接口
行为：多问少做，逐步确认，不写实现代码。
产出：需求确认清单 → 技术方案 → API 骨架（锁定）→ 任务清单
Leader 不只是读开发流程——它会同时加载设计原则（知道哪些是红线）、项目架构（知道现有的域和模块划分）、编码规范（知道技术栈约束）。带着这些「背景知识」来对齐需求，问出来的问题质量完全不一样。
3.2 Worker（执行阶段）
关键词：开始开发 / 写代码 / coding
行为：专注执行，不发散讨论，先读懂现有代码再改。
步骤：搭骨架 → 逐个填充逻辑 → 写测试 → 部署准备
3.3 Judge（审查阶段）
关键词：review / 跑测试 / 能部署了吗
行为：严格验证，给出证据再下结论。
检查清单：代码规范 → 安全检查 → 单测通过 → API测试通过 → 接口一致性 → 静态检查 → 编译通过
四、Rules 体系——AI 的「员工手册」
AI 编程的核心不是某一次对话能写出什么，而是把 Code Review 该关注的东西提前写成规则文件，让 AI 写代码的时候就遵守。不是事后检查，是事前约束。
4.1 四条红线——AI 最容易犯的结构性错误
- 逻辑收口：同一职责只有一个归属，禁止相同逻辑多处各写一份
- 复用优先：新增代码前必须搜索已有逻辑，禁止复制-粘贴-微调
- 禁止循环依赖：模块间依赖必须是 DAG
- 禁止魔法值：所有业务语义值用枚举/常量，禁止硬编码字符串和数字
4.2 九条重要原则——传统工程经验的显式教学
| 幂等性 | 所有状态变更操作必须做幂等保护 |
| 防御性编程 | 参数校验和前置条件检查 |
| 副作用可预测 | 方法名必须体现真实行为 |
| 优雅降级 | 非核心外部依赖失败时降级，不打挂主流程 |
| 可测试性 | 用构造器注入，纯计算逻辑抽成无副作用方法 |
| 日志有效性 | 状态变更必须 log，异常路径必须 log |
| 开闭原则 | 分支 ≥3 且有增长趋势才引入策略/工厂模式 |
| 模块化设计 | 复杂业务拆成边界清晰、可独立演进的模块 |
| 设计模式使用 | 问题驱动，先有问题再匹配模式 |
4.3 禁令写法——对 AI 特别有效的格式
❌ 禁止用 @Lazy 注解掩盖循环依赖
❌ 禁止仅检查一跳直接依赖就声称「无循环依赖风险」
❌ 禁止 get/find 方法包含写操作
❌ 禁止在循环体内高频打 log.info
每条禁令背后都有一个真实踩过的坑。AI 对正面「建议」选择性接收，但对明确「禁止」几乎 100% 遵守。规则越像「法条」，AI 执行力越强。
五、测试分层规范
什么改动写什么测试：
- Service 内部逻辑分支 → 必须写单元测试
- 新增或修改 API 接口 → 必须写 API 集成测试
- 多 API 交互流程 → 必须写流程串联测试
- 仅改工具类/枚举 → 必须写单元测试
人开发的时候自测经常偷懒，但 AI 写测试成本低。让 AI 写测试拉满，项目结束时测试代码比业务代码还多。
六、六个踩坑雷区
坑 1：别第一天就搞微服务
AI coding 有个硬性前提：所有代码在一个项目里，本地能跑起来。拆成微服务之后，AI 写订单模块的时候看不到用户模块的代码，跨服务调用全靠猜。
单体多模块就没这些问题——代码在一个项目里，AI 能看到全貌；本地一键启动，改了就能跑。
坑 2：一个窗口聊到底，不如勤开新窗口
最长一次对话 1800 条消息，到后面 AI 明显开始忘事。这是上下文窗口的物理限制。
原则：新模块、新功能、Judge 审查、BugFix——全部开新窗口。对话会忘，文件不会。
坑 3：修 Bug 别让 AI「顺手优化」
让 AI 修一个空指针，它修完了顺手把整个方法重构了——变量名全改、代码结构调整。空指针好了，新来俩 Bug。
BugFix 四步闭环：定位根因 → 最小改动 → 补测试 → 跑通。想重构？开个新窗口。修 Bug 和重构，永远不要混在一起。
坑 4：手动改了一半代码，AI 给你改回去
有时候手动改几行代码（调个参数、改个判断条件），但改得不彻底。下一次让 AI 改这个模块时，它会把手动改的那一处也改回去。
尽量都让 AI 改（它会全局搜索关联位置一起改）。
坑 5：AI 看不见「全局」
AI 单文件能力很强，但全项目维度的代码质量——跨文件重复、命名不一致、潜在性能问题——它基本看不见。
解法：把全局工程质量交给 Checkstyle、PMD、SpotBugs 这些原生专业工具。AI 负责写，工具负责查，人负责判断。
坑 6：跟 AI 对话，名称得稳定
你跟 AI 讨论一个功能，第一次叫它「积分发放」，第二次叫「奖励逻辑」，第三次叫「活动结算」——AI 会以为这是三个不同的东西，然后给你写三份代码。
方案文档里每个功能点有唯一的名称，对话里严格用这个名称，不用同义词、不用缩写。
七、实操路径
Day 1：通用层 + 技术栈层复制进 .cursor/rules/，5 分钟搞定。AI 的行为马上就会不一样。
第一周：补项目层——先写 3-5 个核心域的边界表，不用一步到位。
持续：每踩一次坑就加一条禁令。这是最有复利的事。
八、总结
AI 编程的瓶颈不在 AI，在你。
同样是 Cursor + Claude Opus，不给它立规矩就是「第一天爽，第三天乱，第五天想重写」。给它一套完善的 Rules 就能稳定输出。
这跟带团队一个道理——招来的人再厉害，没有规范、没有流程、没有测试要求，项目一样烂。AI 也是。
2 万块 Token，15 天，10 万行生产级代码。传统方式 2-3 个人干 2-3 个月。但这个效率不是白来的——你得花时间把「规矩」立好。