中级开发者用 AI，最容易掉进的 5 个坑

✍创作者：全栈弄潮儿²⁰²⁶

🏡 个人主页：全栈弄潮儿²⁰²⁶

📙 专栏地址：AI 编程进阶实战

开篇

当 AI 可以生成代码、解释报错、补齐测试时，很多开发者的第一反应是：

以后写代码是不是会轻松很多？

答案是：有可能。

但前提是，你没有掉进下面这些常见陷阱：

• AI 明明生成了代码，为什么接入项目后问题更多了？
• 同一个问题问了好几次，为什么每次答案都不一样？
• AI 给出的排障建议很多，为什么还是没有定位根因？
• 代码看起来可以运行，为什么测试和线上场景却过不去？
• 用了很多 AI 工具，为什么工作效率没有稳定提升？

这些问题的根源通常不在于“模型不够强”，而在于我们把 AI 当成了可以直接交付结果的黑盒。

对于中级开发者而言，真正需要掌握的不是更多工具，而是如何让 AI 输出进入一条可审查、可验证、可复用的工程流程。

本文不讨论哪个工具更强，也不提供“一句话生成完整项目”的捷径。

我们只讨论最常见、最容易在真实项目中造成返工的 5 个坑，以及如何避开它们。

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

初学者使用 AI 时，通常会把它当作解释概念和生成练习代码的助手。

中级开发者则不同。

我们已经开始处理真实需求、旧项目、接口联调、线上问题和团队协作。此时，AI 的输出会直接进入更复杂的工程环境。

复杂环境意味着更多隐藏条件：

• 项目已经有既定架构和代码规范。
• 业务规则不只存在于需求文档里。
• 数据库、缓存、权限和第三方服务相互影响。
• 一个看似简单的改动，可能影响多个调用方。
• “能运行”与“能上线”之间，还有测试、监控、灰度和回滚。

因此，中级开发者最危险的状态不是不会用 AI，而是：

因为 AI 的回答足够流畅，就误以为它已经理解了全部上下文。

接下来这 5 个坑，本质上都和“过度相信未经验证的输出”有关。

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

在进入具体场景前，先给出一个简单判断标准。

如果你和 AI 的协作过程是这样的：

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

那么你很可能会在后续开发中不断返工。

更可靠的方式应该是：

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

下面的 5 个坑，分别对应这条流程中最容易被跳过的环节。

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

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

假设你收到一个需求：

给用户中心增加一个修改手机号接口。

很多人的第一反应是：

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

这类提问的问题是：它只说明了要做什么，没有说明规则是什么。

AI 只能自行补全大量关键假设，例如：

• 手机号是否需要短信验证码验证？
• 是否允许修改为已被其他账号使用的手机号？
• 修改后是否要让其他设备重新登录？
• 是否有修改频率限制？
• 审计日志记录什么内容？
• 失败时返回哪类业务错误？

如果这些问题没有先确认，AI 生成的代码即使看起来完整，也只是“基于假设的实现”。

更稳妥的做法，是先让 AI 帮你列问题：

现在需要设计“修改手机号”接口。 请先不要写代码，而是按下面格式输出： 1. 需要和产品或业务确认的规则。 2. 可能涉及的安全、权限和数据一致性风险。 3. 正常、边界和异常场景。 4. 建议的接口输入、输出和错误类型。 项目上下文： - 服务端使用 Node.js + TypeScript - 用户使用手机号和验证码登录 - 已有统一的鉴权中间件与业务异常类

等规则明确后，再让 AI 生成接口草稿。

避坑原则：

当需求里存在业务动作、状态变化、权限或金额时，先让 AI 帮你问问题，再让它写代码。

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

同样是“新增一个接口”，在不同项目里可能意味着完全不同的实现方式。

有的项目使用 Controller - Service - Repository 分层，有的项目采用函数式模块；有的统一返回错误码，有的直接抛业务异常；有的金额以分存储，有的以元存储。

如果不提供上下文，AI 往往会按最通用的写法回答。

通用写法不一定错误，但很可能不适合你的项目。

例如，下面这个请求的信息明显不足：

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

更好的请求应该包含最小必要上下文：

请在现有订单模块中设计“取消订单”功能，暂时先给方案，不要写完整代码。 项目上下文： - 后端使用 Java + Spring Boot。 - 订单状态包括：PENDING_PAYMENT、PAID、SHIPPED、CANCELLED。 - 只有 PENDING_PAYMENT 状态允许用户取消。 - 管理员可以取消 PAID 状态订单，但必须记录取消原因。 - 数据访问使用 Repository，业务逻辑放在 Service。 - 项目通过领域异常统一处理业务错误。 请输出： 1. 需要修改的模块和方法。 2. 状态流转和校验逻辑。 3. 并发更新可能产生的问题。 4. 需要补充的测试场景。 5. 仍需要人工确认的业务假设。

这段 Prompt 并没有变得“复杂”，只是把原本藏在开发者脑中的信息显式提供给了 AI。

避坑原则：

不要只描述任务目标。至少说明技术栈、相关模块、既有规范、输入输出、业务约束和验收标准。

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

这是最常见，也最危险的一个坑。

AI 生成的代码经常能通过最简单的演示场景，但仍然可能存在：

• 空值和异常输入没有处理。
• 错误信息不符合项目规范。
• 权限校验遗漏。
• 异步逻辑没有正确等待。
• 数据更新缺少事务或并发控制。
• 变量命名和依赖方式不利于维护。

例如，AI 可能给出这样一段看似简单的金额计算：

functioncalculatePayableAmount(total:number,coupon:number){returntotal-coupon;}

它在total = 100、coupon = 20时当然可以得到80。

但真实场景至少还要确认：

• total和coupon是否为有限数字？
• 优惠券金额是否允许为负数？
• 优惠券超过总价时，最终金额是否允许为负数？
• 金额精度如何处理？
• 项目是否统一使用“分”而不是“元”？

因此，AI 生成代码后，不要立刻问“还有没有优化空间”，而应先问：

请审查下面这段代码。 请从以下维度逐项检查： 1. 输入校验与空值处理。 2. 边界条件与异常分支。 3. 安全与权限风险。 4. 并发、事务或资源释放问题。 5. 可测试性与可维护性。 请区分： - 必须修改的问题。 - 需要结合项目确认的问题。 - 可以优化但不影响正确性的问题。 [粘贴代码]

然后，再由你结合代码库和测试结果判断哪些建议应当采纳。

避坑原则：

AI 生成代码只是实现的开始。审查、运行和测试，才决定它能不能进入项目。

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

线上或测试环境报错时，很多人会直接把异常栈粘贴给 AI：

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

这样做得到的往往是一长串“可能原因”：

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

这些方向未必错误，但它们还不是根因。

如果你直接根据其中一个建议修改代码，很可能修错地方，甚至掩盖真正的问题。

更好的排障 Prompt 应该包含可验证信息：

请协助分析一个接口偶发 500 的问题。 现象： - 只有创建订单接口偶发失败。 - 失败比例约为少量请求。 - 重试后部分请求可以成功。 环境信息： - 问题发生在测试环境。 - 数据库连接池和消息队列都已启用。 - 最近修改过库存扣减逻辑。 已知证据： - 完整错误栈：[粘贴] - 失败请求参数：[脱敏后粘贴] - 相关日志时间线：[粘贴] - 已排除的方向：[写明已经验证过什么] 请输出： 1. 按可能性排序的假设。 2. 每个假设需要补充的证据。 3. 最小验证步骤。 4. 不建议直接修改的地方及原因。

此时，AI 的价值是帮助你整理假设和验证路径，而不是替你宣布结论。

避坑原则：

对排障问题，先要证据和验证步骤，再要修复方案。

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

有些开发者已经尝试过很多 AI 工具和 Prompt：

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

每次都觉得有一点帮助，但过几天又回到“想到什么问什么”的状态。

问题不在工具数量不够，而在没有把有效经验沉淀下来。

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

例如，完成一次接口开发后，可以把成功的 Prompt 归类为：

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

当这些模板逐渐积累起来，AI 才会从一个临时工具，变成你的个人工程工作流。

避坑原则：

不要追求“最强 Prompt”，要建立能持续迭代的 Prompt 库和检查清单。

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

上面 5 个坑之所以容易发生，是因为我们把本应由开发者负责的判断，过早交给了 AI。

下面这些责任必须牢牢保留在自己手里：

可以把 AI 看作一个善于给出候选答案的协作伙伴。

但候选答案并不等于经过验证的结论。

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

如果你想从今天开始改变使用 AI 的方式，可以先执行下面这 6 步：

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

你可以把每次 AI 协作都套进下面这份最小检查清单：

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

不需要一次性做到完美。

先让这 6 步出现在一个真实任务中，再慢慢调整成适合自己项目的节奏。

六、总结

中级开发者使用 AI 时，最容易掉进的 5 个坑是：

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

这 5 个坑看起来不同，但解决方式是一致的：

给 AI 足够的上下文，把输出当成草稿，用工程验证完成闭环，并把有效方法沉淀下来。

当你开始这样使用 AI，它带来的就不只是“更快写出一段代码”，而是更快地理解问题、发现风险和交付结果。

下一篇文章，我们不急着比较工具。

先做一件更重要的事：

不要先问“用哪个 AI”，先盘点你的开发工作流。

如果这篇文章对你有帮助，欢迎点赞、收藏、关注专栏。
你也可以在评论区留言：上面 5 个坑里，你最容易踩中哪一个？