用 AI 写代码与定位 Bug：5 个实战场景和 Prompt 模板

AI 已经进入不少开发者的日常工作流，但同样一个模型，有人能用它快速梳理调用链和定位异常，有人得到的却只是无法落地的示例代码。差别往往不在工具本身，而在于上下文是否完整、任务是否清晰，以及开发者能否验证答案。下面从五个常见开发场景展开，说明如何更有效地与 AI 协作。

最近总看到"AI 会不会取代程序员"的讨论。我的答案是：短期内不会，但它确实改变了我写代码的方式。

用了大半年，我最深的感受是：

AI 不是用来帮你写完整个项目的，而是把你从重复劳动里解放出来。

它能帮你查 API、定为Bug、审查代码、解释陌生的源码；但它替不了你理解业务、积累经验、做技术决策。

这篇聊聊我日常在用的 5 个场景，每个都附上我实际在用的 Prompt 模板，可以直接复制去用。

场景一：写代码——关键是给它足够的上下文

先说一个大多数人的误区：直接甩一句"帮我写个登录接口"，然后抱怨 AI 写得不能用。

问题不在 AI，在你给的信息太少。它不知道你的技术栈、你的项目规范、你已有的代码结构，只能给你一个"网上教程版"的答案。

怎么问才对：

【角色】你是一个有 5 年经验的 Java 后端工程师
【背景】
- 项目：Spring Boot 3.5 + MyBatis-Plus + MySQL + Redis
- 规范：Controller 只做参数校验和调用，业务逻辑在 Service 层
- 统一返回 Result 结构，依赖用构造器注入
【任务】实现商品分页查询接口
【要求】
1. 支持按分类、关键词、价格区间筛选
2. 分页用 MyBatis-Plus 的分页插件
3. 参数校验用 @Valid
【输出】Controller + Service + ServiceImpl，代码带注释

还有一个我常用的技巧：让它先讲思路，别急着写代码。

实现"下单 + 扣库存"这个功能，会涉及跨服务调用和数据一致性。
先不要写代码，先告诉我：
1. 调用链路是怎样的
2. 数据一致性用什么方案保证，为什么
3. 可能有什么坑
我确认思路后，你再写代码。

这样有两个好处：一是能发现它理解偏了（及早纠正，比写完再返工省事）；二是你能顺便学到它的思路——这才是用 AI 的正确姿势，不是"拿到代码就走"。

场景二：排查 Bug——一定要贴完整堆栈

这是我觉得 AI 最值钱的用法。

但很多人不会用：只贴最后一行错误信息，比如"NullPointerException"，然后问"为什么报错"。

这等于让医生只看"你发烧了"就下诊断。完整堆栈里有类名、行号、嵌套异常，这些才是破案的关键。

我的用法：

【背景】跑"创建订单"接口时报错
【完整异常堆栈】
（把控制台里的异常信息一行不删全部贴进来）
【我已经排查的】
- 确认了订单表存在
- 商品 ID 是有效的
【请帮我】
1. 分析这个异常的根本原因（Root Cause），不要只讲表象
2. 告诉我还应该看哪些日志/信息来定位
3. 给出修复方案，并说明为什么这么修
【要求】如果有多种可能原因，按可能性从高到低排列

为什么要强调"分析根因，不要只讲表象"？

因为 AI 默认会给你一个"能让报错消失"的改法——比如加个判空、try-catch 包一下。但报错消失不等于问题解决，可能只是把 bug 藏起来了。

让它先分析根因，你才知道自己改的到底是什么。

场景三：Code Review——给维度，别让它泛泛而谈

写完一段代码，可以让 AI 帮忙过一遍。但如果你只说"帮我看看这段代码"，它给的反馈会很泛。

给它明确的检查维度：

请以高级工程师的身份审查这段代码（贴代码）：
1. 安全问题：有没有 SQL 注入、越权、敏感信息泄露
2. 性能问题：有没有 N+1 查询、循环里查库、锁粒度过大
3. 健壮性：异常处理、边界条件、空指针
4. 可读性：命名、分层、耦合度
请按严重程度排序，给出改进建议。

我自己的体会是：安全性和性能这两个维度最容易被忽略。比如很多人在循环里查数据库（N+1），自己写的时候完全没意识到，被点出来才发现。

场景四：读陌生代码——这是"读懂老项目"的加速I器

接手一个陌生项目时，面对一堆没注释的代码，读起来很痛苦。这种时候 AI 特别好用：

我在读一段代码（贴代码），请帮我：
1. 用一句话概括这段代码在做什么
2. 逐行解释关键逻辑
3. 推测作者的设计意图
4. 有没有潜在问题

读开源项目源码也适用：

我要学习 Spring Cloud Gateway 的鉴权实现，请告诉我：
1. 应该从哪些类和接口入手
2. 核心执行流程是怎样的
3. 给我画一个调用链路图（文字或 ASCII 都行）

最后这条我特别推荐——让它先给你一张"地图"，再往里钻，比自己一上来就啃源码效率高得多。

场景五：SQL 分析——Explain 结果交给它解读

慢 SQL 是后端绕不开的问题。我的用法：

【表结构】（贴 DDL）
【慢 SQL】（贴 SQL）
【Explain 结果】（贴结果）
请：
1. 分析这条 SQL 慢在哪里
2. 给出优化方案（索引、改写 SQL 或其他）
3. 说明优化前后的预期差异

它通常能准确指出问题：是没走索引、还是回表太多、还是索引失效（比如在索引列上做了函数运算）。

但有个前提：你得知道 type、key、rows、Extra 这几个字段是什么意思，才能判断它说得对不对。这属于基本功，不能外包给 AI。

最后，一条我用血换来的铁律

用 AI 用了这么久，我给自己定了一条规矩：

AI 给的代码，我必须能一行一行讲清楚它在干什么。

为什么？

因为你以为你"用了 AI 提效"，但如果代码出了线上问题，最后背锅的是你，不是 AI。而且面试官问"这段代码为什么这么写"，你答不上来，前面用 AI 提的效全白费。

所以我的习惯是：拿到 AI 的代码后，不急着用，先自己读一遍，有不懂的地方追问它"为什么这么写"。 确认理解了，再放进项目。

AI 是加速I器，不是替代品。它能让你一天干三天的活，但"判断它对不对"的能力，才是你真正的价值。

---

以上是我日常在用的 5 个场景。如果你也有好用的 Prompt 技巧，欢迎在评论区交流 ?

觉得有用的话点个赞，后面我可能会写写"怎么用 AI 辅助阅读源码"这个主题。