AI编程总翻车？先把“改代码”换成“带团队”
周五下午，AI把事务注解删了
下午四点，你让AI给支付回调加一段重试逻辑。提示词写得很随意：“帮我优化这段代码，增加失败重试。”
十秒后，它返回了三十行。你看了一眼，逻辑挺顺，复制进项目，提交，跑测试。晚上八点，测试同学在群里发截图：订单重复入账，同一笔支付回调被处理了两次。
你回头翻diff，AI把 @Transactional 注解删了。它觉得“重试”应该独立事务，没问你业务边界。你也没看diff，因为你觉得“AI写这种小逻辑没问题”。
这类事故我见过太多。大家用AI编程常有两个误区。
第一个误区：把AI当高级代码补全。你只给它一句模糊需求，却指望它懂你的框架、事务、幂等、权限、历史包袱。它不懂，它只根据上下文猜。
第二个误区：把AI当黑盒外包。你让它一次改十几个文件，不设验收命令，不做小步提交。等发现线上问题，已经找不到哪一步引入的。
AI能帮你省时间，前提是你把它当施工队，你当项目经理。施工队需要图纸、边界、验收标准。
一、高效实战技巧：把AI当“施工队”，你当项目经理
1. 先画施工图：上下文锚点 + 硬约束 + 验收命令
很多人上来就贴代码，说“帮我改”。这等于让施工队闭眼拆墙。
可照搬的操作步骤：
- 让AI只读，不改。先让它总结关键文件、调用链、数据表、外部依赖。
- 给出硬约束。比如“只允许改
PaymentService.java和PaymentRetryJob.java，禁止动事务注解，禁止引入新依赖。” - 给出验收命令。比如
mvn test -Dtest=PaymentServiceTest，或者go test ./payment/...。 - 让它输出改动计划，你确认后再让它写代码。
短案例：一个订单回调重试需求。我先让AI读 PaymentCallbackController、PaymentService、OrderRepository、application.yml，让它画出“回调进来后哪些方法被调用”。它列出七步。我发现它漏了幂等表。补上上下文后，再让它只改重试调度和幂等校验。那次改动不到八十行，测试全绿。
注意：上下文不是越多越好。把整个仓库塞进去，AI会抓错重点。给关键文件、关键约束、关键命令，比给十万行代码有用。
【金句：AI写代码的质量，取决于你给它的施工图，不取决于你催它“快点”。】
2. 小步提交：一次只改一个行为
AI最危险的地方，是它改A的时候顺手“优化”B。你让它加日志，它把异常吞了；你让它改分页，它把排序字段换了。
操作步骤：
- 改之前先
git commit，保持干净工作区。 - 一次只给一个行为目标。加缓存就只加缓存，别同时让它重构。
- 让它先写失败测试，再实现。
- 跑测试，看diff，确认没有无关文件。
- 通过后立刻提交，commit信息写清“AI辅助：xxx”。
短案例：优惠券叠加计算。原逻辑支持满减和折扣，现在要加“互斥券”。我让AI先写四个测试：两张互斥券不能叠加、互斥券与普通券可叠加、过期券不参与、金额为负报错。它写完测试，两个失败。再让它实现，它只改了 CouponCalculator。diff干净，合并顺利。
注意：不要让AI写测试又让它自己判卷。关键断言你要亲自看。它可能把错误结果写成期望值，测试全绿，线上全红。
【金句：AI辅助开发的安全带，是git diff和小步提交，不是“我觉得它写得对”。】
3. 反向审问：让AI自己找风险
AI会顺着你的话往下写。你说“加个缓存”，它就加缓存，不提醒你缓存穿透、雪崩、数据一致性。
操作步骤：
- 代码写完后，追加一轮提示：“列出这次改动的边界条件、失败场景、回滚方案。”
- 要求它按严重程度排序，给出验证方法。
- 你挑前三条，让它补测试或补监控。
- 如果它说“没有问题”，换一个角度问：“如果数据库超时、Redis挂掉、消息重复，会发生什么？”
短案例：库存扣减。AI第一版用 decrement 直接扣。我追问失败场景，它列出并发超卖、Redis与DB不一致、扣减后订单创建失败。我们补了乐观锁和补偿任务。上线后有一次消息重复，补偿任务把库存加回，没出事故。
**【金句：让AI写代码只是开始，让AI自己找漏洞才是收尾。】
二、高频避坑要点：这5个坑，踩一次加班三天
坑1：幻觉依赖和API
现象：AI引入一个不存在的包，或者用了你项目里没有的版本方法。比如它写 import com.company.util.RetryTemplate，你项目根本没这个类。
危害：编译失败，或者本地能跑、CI挂掉。
规避方案：让它先读 pom.xml、go.mod、package.json。提示词里加一句：“只能使用现有依赖，禁止新增。若需要新依赖，先列出理由和版本。”
坑2：上下文污染，改坏无关工程
现象：你让它改订单模块，它顺手改了用户模块的日志格式、删了工具类方法。
危害：代码评审爆炸，回归范围失控。
规避方案：给文件白名单。提示词写：“只允许修改以下文件：A、B、C。其他文件只读。”提交前看 git diff --stat，超出白名单就回滚。
坑3：AI写测试给自己开绿灯
现象：AI实现了一个错误逻辑，又写了一个测试断言这个错误结果。测试通过，你误以为安全。
危害：线上问题被测试掩盖。
规避方案：关键业务测试由人写，或者人先写断言。AI可以补边界用例，不能决定期望值。对金额、库存、权限，必须人工复核。
坑4：大重构一把梭
现象：你让AI“把同步导出改成异步”，它一次性改了控制器、服务、DAO、配置、前端回调。
危害：问题定位困难，回滚成本高。
规避方案：用绞杀者模式。先加新接口，旧逻辑保留；再切流量；最后删旧代码。每次只改一层，每层可回滚。
坑5：安全与权限盲区
现象：AI为了“方便”，把内部接口鉴权去掉，或者把密钥硬编码进配置文件。
危害：
