你是不是也这样？AI给你写了一堆代码，然后你花三小时debug
上周五凌晨一点，我一个做后端的哥们在群里甩了张截图：AI给他生成了一段用户权限校验的中间件，逻辑看着挺美，一跑——直接把admin角色的token校验绕过去了。他说："我信了它，差点上线把自己埋了。"
这种事太常见了。你用AI编码工具已经半年多，基础用法没问题，但两个坑始终绕不开：
误区一：觉得AI写出来的代码能直接用。 它生成的是"看起来对"的代码，不是"在你工程里能跑"的代码。
误区二：觉得自己检查一遍就够了。 尤其在复杂业务逻辑里，AI幻觉不是偶发bug，是系统性盲区——它擅长模式匹配，弱在理解你项目的上下文约束。
今天这篇，不讲概念，只讲我和身边一圈后端/全栈开发者真正在用的实战方法。
一、三个可以直接照搬的高效技巧
1.1 先给"约束锚点"，再让AI写代码
大多数人用AI写代码的方式是："帮我写一个JWT认证中间件。"——太泛了。
实操步骤：
- 先把你项目的技术栈、框架版本、依赖库列出来（比如
Express 4.18 + jsonwebtoken 9.0 + TypeScript 5.x）； - 把你现有的代码风格贴一段进去（比如你项目里错误处理统一用
AppError类）； - 明确告诉它"不要用任何我没提到的第三方库"。
真实案例： 我们团队有个项目用 NestJS 做后端，之前直接让AI生成守卫（Guard），它塞了个 passport-jwt，但我们项目根本没装这个。后来我每次先贴一段 package.json 的依赖快照，AI生成的代码命中率直接从40%拉到80%以上。
1.2 "分片喂料"：别一次让AI写整个模块
你让AI"帮我写一个完整的订单服务"，它大概率给你一个300行的大文件，改都没法改。
正确做法：
- 先让它写数据模型定义（Entity/Schema）；
- 再单独让它写单个CRUD接口；
- 最后让它写服务层的业务编排。
每一步你确认没问题，再喂下一步。像搭积木，不是让它一口气盖栋楼。
1.3 用"反向验证提示"逼AI自查
写完代码后，追加一句："请列出这段代码可能存在的3个安全漏洞或边界条件问题，并给出修复方案。"
这招特别好用。AI自己生成的代码，让它自己挑毛病，比你肉眼扫一遍靠谱得多。我在一个支付回调接口上试过，它自己揪出了一个没做幂等校验的问题——那正是我差点漏的。
【金句：AI不是你的代笔，是你的陪练。你得先出题，再让它作答，最后让它自查。】
二、五个高频踩坑点，个个都是血泪教训
坑1：AI幻觉函数——它会编造不存在的API
现象： AI给你调用了一个 fs.readFileSyncAsync()，Node.js根本没这玩意。
危害： 编译不过，浪费排查时间；更狠的是有些静态分析查不出来，运行时才炸。
规避： 生成代码后，先复制函数名去官方文档搜一遍，30秒的事。
坑2：上下文溢出——你的项目历史它根本不知道
现象： 你在一个有十年历史的Java项目里用AI，它不知道你三年前废弃的那个工具类还在被三个地方引用。
危害： AI给你重构，把旧依赖删了，线上直接报错。
规避： 涉及老项目改动，必须手动把相关文件的关键片段贴给它，别指望它"理解"你的repo。
坑3：过度泛化——它给你"教科书式"代码，不是"工程级"代码
现象： 代码逻辑完美，但没有日志、没有监控埋点、没有降级策略。
危害： 上线后出问题你根本没法定位。
规避： 在提示词里明确要求："请按生产环境标准，加入错误日志、超时控制和熔断逻辑。"
坑4：测试代码它写得特别烂
现象： AI生成的单元测试覆盖率看着高，但全是happy path，边界条件一个没覆盖。
危害： 你以为有测试了，其实是假安全感。
规避： 让AI写测试时，指定"包含边界值、空值、异常输入三组用例"，别接受它默认的那套。
坑5：你改了AI的代码，下次它又改回去
现象： 你手动修了一个bug，下次让AI优化同一段，它把你的修复覆盖了。
危害： 同一个bug反复出现，你开始怀疑人生。
规避： 把你手动改过的版本用注释标记好，或者直接把修正后的代码作为"参考实现"喂回去，告诉它"以此为准"。
【金句：AI生成的代码，默认只能当草稿。你不审，它就敢上线。】
三、真实案例复盘：用AI三小时搞定一个数据同步服务
背景： 我们一个客户项目，需要把MySQL的订单数据同步到Elasticsearch做搜索，之前纯手写，预估两天。
第一轮输入提示词：
"我有一个Node.js项目，用TypeScript，MySQL 8.0，用TypeORM做ORM。需要写一个定时同步服务，把orders表增量同步到ES。要求：只同步过去24小时变更的数据，处理好断点续传，有错误重试机制。不要用任何我没提到的库。"
AI输出： 给了一个基本框架，但有两个问题——它用了 node-cron，而我们项目用的是 bull 队列；ES客户端它用了旧版API，和我们装的 @elastic/elasticsearch 8.x不兼容。
中间问题： 我把项目的 package.json 关键部分和现有队列服务代码贴过去，让它重写。第二版好了很多，但漏了一个坑：它没处理MySQL主从延迟导致的数据不一致。
最终修正： 我追加提示："请考虑MySQL主从复制延迟场景，同步时加一个水位线（watermark）机制。"它补上了，代码量大概280行，包含完整的错误处理和日志。
成果： 从开始到可运行代码，三小时出头。后续我又花了一小时做压测调参。比纯手写快了大概60%，但前提是我每一步都在审。
【金句：AI帮你从0到1，但从1到10的脏活累活，还得你自己蹲在那改。】
总结：今天就能动手的三件事
- 找一个你最近写过的接口，把代码贴给AI，让它挑毛病。 看看它能不能发现你自己没注意的问题——这是最快的训练方式。
- 下次用AI生成代码时，先贴你的依赖快照和代码风格样本。 花两分钟，省两小时debug。
- 建一个"AI踩坑记录文档"。 每次AI给你挖坑就记下来，三个月后你会发现自己对它的盲区了如指掌。
最后说句实话：AI编码工具现在能帮你提速，但它不懂你的业务、你的团队、你的历史债务。它是个快但粗心的实习生——你得带着它干活，不能把活甩给它。
觉得有用可以收藏转发，评论区聊聊你被AI坑过最狠的一次是什么？
