AI编程别急着让AI写代码：3个落地法+5个坑
凌晨一点半，你盯着订单服务，只想让 AI 帮你把支付回调改成幂等。提示词写了一大段，它回得也快：加个 @Idempotent 注解，抽一个 IdempotentUtil，再把状态判断删掉。你一看，挺像那么回事。结果本地编译不过，那个工具类根本不存在；改完上线，重复回调把已退款订单又推回已支付。
这种事不稀奇。会用 AI 写代码之后，真正的问题才刚开始：它写得快，错得也快；它能补全，也能把原有工程搅乱。
很多人有两个误区。第一个误区，觉得提示词越长，AI 越懂项目。其实你贴 3000 字需求，不如贴 30 行真实接口和表结构。第二个误区，觉得 AI 能理解整个工程。它看到的只有你给它的上下文，剩下的全靠猜。猜对了是运气，猜错了就是事故。
下面这些方法，是我在订单、库存、结算这类后端项目里反复试出来的。不神化 AI，也不把它当玩具。你照着改，至少能少熬几个夜。
一、先喂“项目地图”，再让它动刀
AI 改坏代码，多数时候不是它笨，是你没给它边界。它不知道你的项目里已经有 Redisson，不知道订单状态 2 代表已关闭，不知道退款任务表叫什么。你让它自由发挥，它只能编。
操作步骤
- 建一个
AI_CONTEXT.md，只放四样东西：目录树、核心接口签名、关键表字段、现有依赖清单。 - 每轮对话先贴这个文件，再贴你要改的那个类，别一次塞整个工程。
- 给硬约束：只能改我指定的文件；只能使用现有依赖；新增方法必须写清入参出参；先输出计划，我确认后你再写代码。
- 让它复述关键业务规则。比如“订单状态 0 待支付、1 已支付、2 已关闭、3 退款中、4 已退款”。复述不对，立刻纠正。
真实项目案例
优惠券核销接口要加防重复提交。AI 第一版建议引入 Redis 分布式锁，还写了 RedisTemplate 配置。可项目里已经有 RedissonClient，根本不需要再配。我把依赖清单和现有配置贴过去，要求“基于 RedissonClient 的 tryLock 实现，锁 key 用券码+用户 ID，等待 0 秒，租期 10 秒”。第二版直接能用，改动不到 40 行。
你给 AI 的地图越准，它瞎编的空间越小。
【金句：AI 不缺代码能力，缺的是你项目的边界。】
二、用“契约+测试”锁住边界
让 AI 直接写实现，它容易写飞。更稳的做法：先让它写契约，再让它写测试，最后填实现。契约就是接口签名、入参出参、失败码、事务边界、幂等键。测试就是失败分支，不是只测成功。
操作步骤
- 你先写接口签名，或者让 AI 根据现有 Controller 反推，但你必须确认。
- 让它列出测试用例：正常、参数缺失、重复请求、并发请求、下游超时、数据库更新 0 行。
- 要求它先写测试代码，再写实现代码。跑不过就继续改。
- 明确事务：哪些操作在一个事务里，哪些要异步补偿，哪些必须加唯一索引。
真实项目案例
库存扣减。AI 第一版写的是“先查库存，再更新库存”。这代码在并发下就是超卖。我让它改成条件更新：update stock set num = num - 1 where sku_id = ? and num >= 1。然后补测试：两个线程同时扣最后一件，只能成功一个。它一开始只写了单线程测试，我要求加并发测试和数据库唯一约束说明。最后方案落地，没上锁，靠一条 SQL 和唯一索引扛住。
测试不是给领导看的，是给 AI 划红线的。
【金句：别让 AI 自由发挥，让它先过测试再进主流程。】
三、让 AI 输出“改动说明+回滚方案”
AI 写代码快，但你看 diff 更慢。如果它一次改 8 个文件，你很难判断哪里埋了雷。所以每轮必须让它交四样东西：改了什么、影响哪些文件、数据库要不要变、怎么回滚。
操作步骤
- 提示词里加一句：“输出 unified diff，不要只给完整文件。”
- 要求列出影响
