AI写代码翻车实录：5个坑，踩一个线上就出事

P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。

用 AI 编程最容易踩的 5 个坑

先聊个身边的事。

上周，同事让 AI 写一个删除接口。AI 很敬业，写完代码还贴心地附了一行注释：此操作不可恢复，请谨慎调用。

注释没毛病，可惜我同事没看。

于是线上库少了一部分数据——不多，也就够他复盘一个礼拜的。

这件事跟 AI 强不强没关系，跟"怎么用"有关系。

AI 能写代码这事传开以后，开发者的第一反应都差不多：

以后是不是不用加班了？

答案是：有可能。但会把加班换成"改 bug"。

毕竟 AI 给你的是代码，不是保险。

具体来说，你大概率遇到过下面这五种灵异事件：

• AI 生成的代码一进项目，项目就开始闹脾气。
• 同一个问题问三次，AI 给你三个答案，像极了三个不同星座的算命先生。
• AI 排障给了一堆建议，你按图索骥修完，bug 还在原地等你。
• 代码本地跑得欢，一上线就给你表演当场去世。
• 工具换了一大堆，效率稳如老狗——稳得让人想哭。

这些破事的根子，大多不在"模型不够强"，而在我们把 AI 当成了许愿池。

中级开发者真正该学的，不是哪家工具更香，而是怎么把 AI 的输出，变成一条能审查、能验证、能复用的流水线。

今天不吹工具，也不教"一句话生成整个项目"的玄学。
只聊五个坑——五个我掉进去过、爬出来还摔了一跤的坑。

一、为什么中级开发者更容易踩坑

初级开发者用 AI，像请了个家教：不懂就问，问完就完。

中级开发者用 AI，像请了个同事：得干活，得交差，还得给这个记性不太好的同事擦屁股。

到了这个阶段，你手里的活开始变复杂：老项目、接口联调、线上事故、团队扯皮。
AI 的输出不再是一段"写着玩"的代码，而是要直接塞进一个到处是雷的工程环境。

这环境里全是隐藏条款：

• 项目有它自己的架构和规范，AI 不知道，但代码得遵守。
• 业务规则不光长在需求文档里，还长在老板的脑子里。
• 数据库、缓存、权限、第三方服务，牵一发而动全身。
• 你以为的小改动，可能让三个调用方同时问候你。
• "能运行"和"能上线"之间，隔着测试、监控、灰度、回滚四座大山。

所以中级开发者最危险的状态，不是不会用 AI，而是：
AI 回答得太流利，你就信了。

AI 说话好听，跟销售似的。可代码不是销售——代码是要进生产环境的。
下面这 5 个坑，本质都是同一个病：过度信任一份没验证过的输出。

二、这 5 个坑的共同问题是什么

先给一个自测标准。

如果你的协作流程长这样：

抛出一句需求 → 拿到一段代码 → 复制进项目 → 出问题继续追问

恭喜，你已经拿到了"返工年度会员"。

比较靠谱的流程是这样：

补全问题和上下文 → 确认规则与约束 → 让 AI 提供方案或草稿 → 人工审查并验证 → 补齐测试和边界场景 → 沉淀有效的 Prompt 与检查清单

这 5 个坑，分别对应这条流水线上最容易被跳过的环节。

三、中级开发者最容易掉进的 5 个坑

1. 需求只说一句话，就让 AI 直接写代码

老板甩过来一句话：
给用户中心加一个修改手机号的接口。

你转头就把这句话原封不动翻译给 AI：

请用 Node.js + TypeScript 写一个修改手机号的接口。

你自己说说，这句话除了"要做什么"，还剩什么？

规则呢？边界呢？手机号要不要短信验证码？能不能改成别人正在用的号？改完要不要把其他设备踢下线？改频繁了要不要限流？审计日志记不记？失败返回什么错误？

AI 面对这些问题，不会说"我不知道"，它会默默替你脑补。
AI 脑补出来的实现，看起来完整，实际上是个薛定谔的接口——你不测试，它就不会炸。

正确姿势：先让 AI 帮你列问题，别让它急着写代码。

现在需要设计"修改手机号"接口。
请先不要写代码，而是按下面格式输出：
1. 需要和产品或业务确认的规则。
2. 可能涉及的安全、权限和数据一致性风险。
3. 正常、边界和异常场景。
4. 建议的接口输入、输出和错误类型。

项目上下文：
- 服务端使用 Node.js + TypeScript
- 用户使用手机号和验证码登录
- 已有统一的鉴权中间件与业务异常类

等规则问明白了，再让它出草稿。

**避坑原则：**需求里带业务动作、状态变化、权限或金额的，先让 AI 问问题，再让它写代码。

一句话需求配 AI，等于让一个自信的人去猜谜——他猜得特别快，也特别不准。

2. 不提供项目上下文，却期待 AI 写出能直接合并的代码

同样是"加一个接口"，在不同项目里可能根本是两个物种。
有的项目 Controller-Service-Repository 层层分明，有的项目一股脑函数式；有的统一返回错误码，有的直接抛业务异常；有的金额按分存，有的按元存。

你不说，AI 就按全网最通用的写法来。
通用写法不一定是错的，但它大概率跟你的项目八字不合。

比如你甩一句：

帮我给订单模块增加取消订单功能。

AI 心想：订单？取消？懂了。然后给你写了个把订单表清空的"取消"。

更好的姿势，是给足上下文：

请在现有订单模块中设计"取消订单"功能，暂时先给方案，不要写完整代码。

项目上下文：
- 后端使用 Java + Spring Boot。
- 订单状态包括：PENDING_PAYMENT、PAID、SHIPPED、CANCELLED。
- 只有 PENDING_PAYMENT 状态允许用户取消。
- 管理员可以取消 PAID 状态订单，但必须记录取消原因。
- 数据访问使用 Repository，业务逻辑放在 Service。
- 项目通过领域异常统一处理业务错误。

请输出：
1. 需要修改的模块和方法。
2. 状态流转和校验逻辑。
3. 并发更新可能产生的问题。
4. 需要补充的测试场景。
5. 仍需要人工确认的业务假设。

这段 Prompt 并不复杂，只是把你脑子里那点信息，搬到了 AI 眼前。

**避坑原则：**别只报任务目标。技术栈、相关模块、既有规范、输入输出、业务约束、验收标准，能报多少报多少。

把 AI 当新同事想想：你入职第一天啥都不说，就让人家写核心代码——出事了，这锅你说谁背？

3. 看到 AI 代码能运行，就跳过审查和测试

这是最常见的一个坑，也是翻车率最高的一个坑。

AI 的代码过演示场景轻轻松松，但背地里可能藏着：

• 空值和异常输入，直接裸奔。
• 错误信息跟项目规范各说各话。
• 权限校验直接缺勤。
• 异步逻辑没等完就跑了。
• 数据更新没事务，并发一来就乱。
• 变量命名随缘，依赖方式随心。

比如 AI 给你这么一段"人畜无害"的金额计算：

function calculatePayableAmount(total: number, coupon: number) {
  return total - coupon;
}

total=100、coupon=20，得出 80，看起来天衣无缝。

但真实场景里，要确认的问题能装一卡车：

• total 和 coupon 是有限数字吗？
• 优惠券金额能是负数吗？
• 优惠券比总价还大，最后金额是负数怎么办？
• 金额精度怎么处理？
• 项目里到底按分算还是按元算？

所以 AI 交代码之后，别急着问"还能不能优化"，先让它自审：

请审查下面这段代码。
请从以下维度逐项检查：
1. 输入校验与空值处理。
2. 边界条件与异常分支。
3. 安全与权限风险。
4. 并发、事务或资源释放问题。
5. 可测试性与可维护性。

请区分：
- 必须修改的问题。
- 需要结合项目确认的问题。
- 可以优化但不影响正确性的问题。

[粘贴代码]

然后你再结合代码库和测试结果，决定哪些建议是真药，哪些是安慰剂。

**避坑原则：**AI 生成代码只是实现的开始。审查、运行、测试，才决定它能不能活着进项目。

"能运行"和"能上线"之间的距离，约等于"能呼吸"和"能毕业"之间的距离。

4. 把 AI 的排障建议，当成最终根因

线上报错，很多人的第一反应是：
把异常栈甩给 AI。

这个报错怎么解决？
[粘贴异常信息]

然后你会收到一份"可能原因"全家桶：

• 配置没生效。
• 依赖版本冲突。
• 网络或权限问题。
• 参数为空。
• 数据库连接异常。

每个方向都沾点边，每个方向都不是根因。
这感觉就像你问路，AI 给你画了五条路，每条路的尽头都写着"大概可能也许"。

你随便挑一条走下去，轻则白干一场，重则把真 bug 埋得更深。

正确的排障姿势，是先给证据，再要结论：

请协助分析一个接口偶发 500 的问题。

现象：
- 只有创建订单接口偶发失败。
- 失败比例约为少量请求。
- 重试后部分请求可以成功。

环境信息：
- 问题发生在测试环境。
- 数据库连接池和消息队列都已启用。
- 最近修改过库存扣减逻辑。

已知证据：
- 完整错误栈：[粘贴]
- 失败请求参数：[脱敏后粘贴]
- 相关日志时间线：[粘贴]
- 已排除的方向：[写明已经验证过什么]

请输出：
1. 按可能性排序的假设。
2. 每个假设需要补充的证据。
3. 最小验证步骤。
4. 不建议直接修改的地方及原因。

这时候 AI 的作用，是帮你整理假设、规划验证路径，而不是替你拍板。

**避坑原则：**排障先要证据和验证步骤，再要修复方案。

让 AI 当侦探，别让它当法官。侦探负责给线索，判案还得你自己来。

5. 不断换工具和 Prompt，却没有形成自己的工作流

工具党的日常：

• 今天用它生成接口。
• 明天换一个写单测。
• 后天再换一种做代码审查。

每次都觉得"这次有戏"，过两天又回到"想到啥问啥"。
问题不在工具不够多，在于经验没沉淀。

建议从今天开始，建一个简单的个人 AI 开发记录：

记录项	要保存什么
任务类型	需求拆解、代码阅读、编码、测试、排障、文档
有效 Prompt	给了哪些上下文，要求了什么输出格式
验证方式	用了哪些测试、日志、代码审查或人工确认
结果	哪些建议被采用，哪些被否决
踩坑记录	AI 漏掉了什么，为什么会漏掉

比如完成一次接口开发，把成功的 Prompt 分门别类收好：

接口设计模板 代码审查模板 测试矩阵模板 异常排查模板 需求澄清模板

等这些模板攒多了，AI 就从"临时工"变成了你的"工程搭档"。

**避坑原则：**别追"最强 Prompt"，要建一个能持续迭代的 Prompt 库和检查清单。

工具换得比对象还勤，不等于你会谈恋爱。

四、AI 编程不能替你完成哪些判断

上面 5 个坑，本质都是同一个动作：把本该自己拍的板，提前交给了 AI。

下面这些责任，请焊死在手里：

场景	不能跳过的开发者判断
业务实现	需求是否完整，规则是否符合真实业务
架构方案	是否适合现有项目、团队能力和长期维护
代码合并	是否符合规范，是否影响已有调用方
测试验证	是否覆盖关键路径、边界与异常场景
线上排障	证据是否充分，修复是否可回滚
安全合规	是否包含权限、隐私、注入和依赖风险

把 AI 当那个特别能聊的同事就行：他给你一堆候选答案，但候选答案不等于正确答案。
聊得再欢，锅还是你的。

五、中级开发者如何建立一条避坑工作流

想从今天开始改，先执行这 6 步：

1. **先写清问题。**明确任务目标、已有事实和未知条件。
2. **补齐上下文。**提供技术栈、相关代码、约束和验收标准。
3. **先要方案。**复杂任务先聊分层、风险和测试，再谈代码。
4. **把输出当草稿。**审查 AI 的假设、依赖、异常处理和边界。
5. **用证据验证。**单测、日志、接口联调、代码评审，一个都不能少。
6. **沉淀有效经验。**保存 Prompt、检查清单和失败复盘，别只留聊天记录。

每次跟 AI 协作，都可以套这份最小检查清单：

[ ] 我是否说明了任务目标和项目上下文？
[ ] 我是否列出了已确认规则和仍待确认的问题？
[ ] 我是否要求 AI 标出它做出的假设？
[ ] 我是否审查了异常、边界、安全和并发问题？
[ ] 我是否通过运行、测试或日志验证了输出？
[ ] 我是否保存了这次任务中可复用的 Prompt 或清单？

别想一次性做到完美。
先让这 6 步在一个真实任务里跑起来，再慢慢调成你自己的节奏。
这份清单不是给 AI 看的，是给三小时后的你看的——那时候你已经忘了自己刚才想干嘛。

六、总结

中级开发者用 AI 最容易掉的 5 个坑，再来一遍：

1. 需求只说一句话，就让 AI 直接写代码。
2. 不提供项目上下文，却期待得到可合并的实现。
3. 看到代码能运行，就跳过审查和测试。
4. 把 AI 的排障建议，当成最终根因。
5. 不断换工具和 Prompt，却没有形成自己的工作流。

这 5 个坑长得不一样，药方却是同一副：
把上下文给够，把输出当草稿，用工程验证闭环，把有效方法沉淀下来。

当你开始这么用 AI，它带给你的就不只是"代码写得快"，而是"问题想得清、风险看得见、结果交得稳"。

P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。