文章目录开篇一、为什么中级开发者更容易踩坑二、这 5 个坑的共同问题是什么三、中级开发者最容易掉进的 5 个坑1. 需求只说一句话就让 AI 直接写代码2. 不提供项目上下文却期待 AI 写出可直接合并的代码3. 看到 AI 代码能运行就跳过审查和测试4. 把 AI 的排障建议当成最终根因5. 不断换工具和 Prompt却没有形成自己的工作流四、AI 编程不能替你完成哪些判断五、中级开发者如何建立一条避坑工作流六、总结✍创作者全栈弄潮儿²⁰²⁶ 个人主页全栈弄潮儿²⁰²⁶ 专栏地址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 归类为接口设计模板 代码审查模板 测试矩阵模板 异常排查模板 需求澄清模板当这些模板逐渐积累起来AI 才会从一个临时工具变成你的个人工程工作流。避坑原则不要追求“最强 Prompt”要建立能持续迭代的 Prompt 库和检查清单。四、AI 编程不能替你完成哪些判断上面 5 个坑之所以容易发生是因为我们把本应由开发者负责的判断过早交给了 AI。下面这些责任必须牢牢保留在自己手里场景不能跳过的开发者判断业务实现需求是否完整规则是否符合真实业务架构方案是否适合现有项目、团队能力和长期维护代码合并是否符合规范是否影响已有调用方测试验证是否覆盖关键路径、边界与异常场景线上排障证据是否充分修复是否可回滚安全合规是否包含权限、隐私、注入和依赖风险可以把 AI 看作一个善于给出候选答案的协作伙伴。但候选答案并不等于经过验证的结论。五、中级开发者如何建立一条避坑工作流如果你想从今天开始改变使用 AI 的方式可以先执行下面这 6 步先写清问题。明确任务目标、已有事实和未知条件。补齐上下文。提供技术栈、相关代码、约束和验收标准。先要方案。对复杂任务先讨论分层、风险和测试再生成代码。把输出当草稿。审查 AI 的假设、依赖、异常处理和边界。用证据验证。通过单测、日志、接口联调和代码评审确认结果。沉淀有效经验。保存 Prompt、检查清单和失败复盘而不是只保留聊天记录。你可以把每次 AI 协作都套进下面这份最小检查清单[ ] 我是否说明了任务目标和项目上下文 [ ] 我是否列出了已确认规则和仍待确认的问题 [ ] 我是否要求 AI 标出它做出的假设 [ ] 我是否审查了异常、边界、安全和并发问题 [ ] 我是否通过运行、测试或日志验证了输出 [ ] 我是否保存了这次任务中可复用的 Prompt 或清单不需要一次性做到完美。先让这 6 步出现在一个真实任务中再慢慢调整成适合自己项目的节奏。六、总结中级开发者使用 AI 时最容易掉进的 5 个坑是需求只说一句话就让 AI 直接写代码。不提供项目上下文却期待得到可合并的实现。看到代码能运行就跳过审查和测试。把 AI 的排障建议当成最终根因。不断换工具和 Prompt却没有形成自己的工作流。这 5 个坑看起来不同但解决方式是一致的给 AI 足够的上下文把输出当成草稿用工程验证完成闭环并把有效方法沉淀下来。当你开始这样使用 AI它带来的就不只是“更快写出一段代码”而是更快地理解问题、发现风险和交付结果。下一篇文章我们不急着比较工具。先做一件更重要的事不要先问“用哪个 AI”先盘点你的开发工作流。如果这篇文章对你有帮助欢迎点赞、收藏、关注专栏。你也可以在评论区留言上面 5 个坑里你最容易踩中哪一个