你是不是也经历过这种崩溃？
周五下午四点半，你让AI帮你写一个订单分库分表的中间件，它慷慨地吐出200行代码，逻辑看着挺漂亮。你兴冲冲合进项目，跑了一遍单元测试——全红。再细看，它用了一个根本不存在的Spring注解，数据库字段名跟你实际表结构差了两个字母。
你骂了一句，回滚代码，手动重写。
这不是段子，是我身边后端同事的真实日常。
很多人对AI编程有两个误解：一是觉得"让它写就完了"，二是觉得"它写的我看不懂肯定是我水平不够"。真相是——AI是个很能编的实习生，你不盯着它，它就敢给你交一份全是幻觉的周报。
今天这篇，不讲概念，全是我自己和团队踩过坑之后总结出来的实操。
一、三个能直接搬用的高效技巧
1.1 先给上下文，再提需求——别让AI"盲猜"
多数人的提示词是这样的："帮我写一个JWT鉴权中间件。"
AI不知道你用的是Gin还是Echo，不知道你的用户表叫users还是t_user，不知道你要不要支持刷新token。它只能根据训练数据里出现频率最高的模式去猜，猜错的概率不低。
正确姿势分三步：
- 贴一段你现有项目的代码结构（路由注册方式、数据库模型定义）
- 明确说"基于以上代码风格，帮我写……"
- 限定范围："只写核心逻辑，不要补全import和注释"
我在一个Go微服务项目里试过，光是加了一句"我们用Gin框架，数据库用GORM，模型文件在models/user.go"，AI输出的可运行率从40%直接跳到85%。
【金句：AI不是读心术大师，你给的上下文越精确，它编的幻觉就越少。】
1.2 让AI"先出方案再写代码"——分两轮对话
直接要代码，等于让一个人没打草稿就写作文。
我现在的习惯是：第一轮问"订单系统要支持多商户，技术方案怎么选型？"让它列出2-3种方案及取舍。确认方向后，第二轮再说"按方案B，帮我写DAO层的实现"。
这样做有两个好处：第一，你能在方案阶段就发现它的逻辑漏洞；第二，生成的代码250;跟前一轮的方案对齐，不容易跑偏。
团队里做电商项目时，我们用这个方法搞定了一个多租户SaaS的数据隔离层，前后总共三轮对话，比直接要代码省了大概半天返工时间。
1.3 用"断言式提示"锁定边界
别说"帮我优化这段SQL"，要说"这段SQL在MySQL 8.0下执行，orders表有500万数据，created_at有索引，请优化并说明为什么你选这个方案"。
你把环境、数据量、约束条件全丢进去，AI就不会给你推荐一个SQLite才有的语法，也不会给你写一个需要全表扫描的"优化方案"。
【金句：好的提示词不是问句，是带着答案框架的限定题。】
二、五个最容易踩的坑
| 坑 | 现象 | 危害 | 怎么避 |
|---|---|---|---|
| 1. 盲目信任生成的依赖版本 | AI给你写pom.xml或go.mod，版本号看着没问题 |
合进去编译报错，甚至拉到有漏洞的旧版本 | 生成后手动查一眼官网最新稳定版，尤其是安全相关的库 |
| 2. 让AI改老代码不给diff | 直接说"把这段改成异步的"，它重写整块 | 原本能跑的逻辑被改坏，git diff一片红，根本没法review | 明确说"只改这三行，其余不动，输出diff格式" |
| 3. 一次性丢500行让它重构 | 觉得反正AI能处理大上下文 | 输出截断、逻辑断裂、前后变量对不上 | 拆成50-80行的小块，逐函数喂 |
| 4. 用AI生成测试用例但不跑 | 它写了测试代码你觉得"看着对"就合了 | 测试通过但断言全是假通过，上线才发现 | AI写的测试必须你本地跑一遍，并且自己再补边界case |
| 5. 让AI写配置文件和Dockerfile | 它给你编一个看着完整的docker-compose.yml |
端口冲突、 volume路径不对、健康检查缺失 | 配置文件类的东西，AI只是起稿，你必须对照官方文档逐字核 |
【金句：AI给你的代码是"初稿"，不是"定稿"。没有review的AI代码，等于没有测试的上线。】
三、一个完整案例复盘：AI辅助搞定支付回调重试机制
背景： 我们有个电商后端，支付回调偶尔因为网络抖动丢消息，之前靠定时任务轮询补单，效率低还有延迟。
第一轮提示词：
我们是Go+Gin项目，用Redis做队列。现在支付回调通过HTTP接口进入，偶尔超时无响应。
请给出3种保证回调最终被处理的方案，分析每种的优缺点。AI给了"消息队列异步化"、"本地消息表"、"指数退避重试"三种。我们选了消息队列方案。
第二轮提示词：
基于Redis Stream，帮我写一个消费者，要求：
1. 消费失败后进入重试队列，最多重试5次
2. 每次重试间隔2^attempt秒
3. 超过5次写入死信队列并告警
4. 代码风格参考我们现有的handlers/payment.go中间出的问题： 它生成的代码用了redigo库，但我们项目实际用的是go-redis。变量名也跟我们项目约定不一致（我们用驼峰，它给了蛇形）。
我的处理： 把不对的地方指出来，追加一句"用go-redis v8版本，变量名改成驼峰"，它10秒内修正。
最终成果： 加上我自己补的单元测试和监控埋点，整个功能从需求到上线用了大半天。如果纯手写，预估要两天。
【金句：AI帮你省的不是"写代码"的时间，是"从零搭思路"的时间。思路你定，细节它填。】
四、说句实话：AI编程的短板
它不擅长的事你得心里有数：
- 复杂业务逻辑的全局理解——它看不懂你整条业务链路的隐含规则
- 性能调优的真实压测判断——它能写代码，但不知道你的机器扛不扛得住
- 安全漏洞的深度审计——它会写SQL注入的代码，你不review就用了那是你的锅
工具就是工具，别把它当合伙人。
五、你今天就能动手的三件事
- 找一段你自己项目里最烂的代码（别超过80行），丢给AI让它重构，然后逐行对比原来的——练你的review眼光
- 下次写新功能前，先让AI出方案，你挑一个方向再动手写——练你的需求拆解能力
- 建一个"AI踩坑笔记"，每次它给你编错的地方记下来，两周后你会发现规律
觉得有用可以收藏转发，也欢迎在评论区聊聊你被AI坑过最离谱的一次——我先说，我被它编过一个不存在的Go标准库函数，查了半小时。
