真省时间的环节#

写 SQL 和查文档。 这是最没悬念的。复杂一点的统计 SQL，比如带窗口函数的分组汇总，我给 AI 讲清楚表结构和需求，它给的初稿十有八九能用，我只需要跑一遍看结果。Oracle 的函数用法、MyBatis 的配置细节这类”记得住大半但记不全”的知识，问 AI 比翻文档快一个数量级。

单元测试和重复样板。 Controller、Service、Mapper 三层的 CRUD 测试，模式高度统一，AI 生成完我补边界用例，效率提升明显。接口的 DTO/VO 转换、分页查询、异常包装这些样板代码同理。

文档和注释。 接口文档、数据库设计文档的初稿，AI 写得好且快，我再补充业务上下文。以前最烦写文档，现在反而是 AI 处理得最好的部分。

Code Review 的第二双眼睛。 让 AI 帮我 review 自己刚写的 diff，经常能抓出我漏掉的空指针判断、资源没关这种低级但致命的问题。

必须自己把关的环节#

架构决策。 该不该上多租户、缓存放在哪一层、接口怎么拆分——这些 AI 只能给”参考意见”，它对系统的真实约束（谁在用、数据量多大、运维能力如何）一无所知。让它选型，等于让一个读了很多书但没见过你系统的人做决定。

业务规则和数据一致性。 企业系统的核心是业务逻辑，不是代码。审批流的状态机、对账的规则、租户隔离的边界——这些出错的代价是钱和信任，必须人来定，AI 只能实现。

AI 生成代码的审查。 这不是可选项。下面两个坑都是真实发生的。

两个翻车案例#

案例一：AI 生成的 SQL 没走索引。 给 AI 描述需求时，我习惯性省略了数据量这个前提。它生成了一条逻辑正确的 SQL，但查的是几百万行的表，关联条件上没索引，生产环境慢查询直接拉满。教训：给 AI 的信息越完整，它犯的错越少。数据量级、表规模、并发情况，这些”常识”它不知道，必须说清楚。

案例二：AI 重构引入了 N+1 查询。 让 AI 把一个循环里的单条查询优化成批量查询，它确实做到了，但顺手把另一处本来好好的批量查询”优化”成了循环里的单条查询。逻辑测试全过，性能测试才发现。从此以后，AI 改动的代码，我必看 diff，而且重点看它”顺手”改的部分。

现在的固定流程#

1. 需求先自己拆清楚，画好接口和数据模型——这部分 AI 只做参谋
2. 让 AI 生成初稿，明确告诉它约束条件（数据量、并发、不走索引的坑）
3. 逐行看 diff，重点盯它”顺手优化”和”假设前提”的部分
4. 测试全部自己写核心用例，AI 生成的测试只作补充
5. 提交前让 AI 做一轮 review，抓低级错误

结论#

AI 不会替代开发，但会替代”不会用 AI 的开发”。真正拉开差距的不是谁生成的代码多，而是谁更清楚哪些环节可以放手、哪些环节必须自己扛。这个边界，三个月前我不懂，现在也只是摸了个大概。