1. 先聊清楚：我把 AI 当结对程序员，而不是搜索引擎
我先说个结论：AI 写代码这件事，用得好的人跟用得差的人，差距根本不在模型选哪个，而在输入方式。大部分人把 AI 当搜索引擎用——"帮我写个登录功能"，然后拿到一段代码，复制粘贴，跑不通再来一轮。这么用，AI 就是个高级版的代码片段库，价值有限。
我的用法完全不同。我把 AI 当成一个坐在旁边的结对程序员，它有上下文、有推理过程、能参与讨论，前提是——你得按"和人沟通"的方式来跟它说话。
具体来说，我得先给它讲清楚：我在哪个项目里、用的什么技术栈、这文件叫什么、函数大概长什么样、依赖里有什么。然后再说我要干什么、为什么这么干、遇到了什么问题。这跟带新人是一个逻辑，你上来甩一句"帮我把登录做出来"，哪怕是个真人同事也得懵。
这篇文章里我整理了五个我平时最高频的使用场景，每个场景都附了可以直接复制粘贴的 Prompt 模板，以及我会在里面做了什么调整。用这些模板的时候不用字字照搬，把名称、路径、报错信息换掉就行。
适用的人：正在用 AI 辅助开发但觉得效果不稳的、想系统学一下怎么写 Prompt 的、以及被 Bug 折磨到想换个思路的。以下内容全部来自我自己的实操经验，踩过的坑都写在里面了。
2. 场景一：把模糊需求变成能跑的模块骨架
这个场景最常用，但也最容易翻车。很多人上来就说"给我写个用户注册接口"，然后 AI 给你一套 Spring Boot 或者 Express 的代码，跟你的项目对不上，改起来比从零写还累。
我的做法是：先让 AI 理解项目语境，再让它产出骨架，最后逐块填充。这一步做好了，后面所有环节都顺。
2.1 我给 AI 喂的“项目体检式” Prompt
这是我自己一直在用、效果稳定的模板：
我在做一个 [项目简述，比如：基于 Flask + PostgreSQL 的待办事项 API]， 目前项目结构如下：[贴目录树，只贴到二级就行] 其中 [某个文件] 的代码是：[贴 20~50 行关键代码] 现在我需要实现一个 [具体功能，比如：任务列表的分页查询接口，支持按状态筛选]。 请帮我在 [指定文件/模块] 里设计： 1. 路由和参数校验的写法 2. 数据库查询逻辑（注意索引和分页） 3. 异常处理的规范 4. 返回的数据结构 先不要写完整代码，先给我方案和关键代码片段。你看，这里面有几个关键动作：
- 目录树：让 AI 知道项目长什么样，不然它可能给你生成一个跟你现有结构完全不兼容的模块。
- 关键代码：给它看 20 行左右现有代码，它就知道你的缩进风格、命名习惯、返回格式是什么样的。
- "先不要写完整代码"：这一步非常重要。如果一上来就要完整代码，AI 经常给你生成一大坨，然后里面一堆不存在的依赖。先要方案，确认逻辑没问题，再让它展开写。
2.2 从方案到代码的执行细节
拿到 AI 给的方案之后，我会逐条审一遍。不是全信，而是对照我自己的项目经验去判断：这个分页逻辑放在服务层还是数据访问层？异常是全局捕获还是局部处理？返回值是直接返回模型还是包一层响应结构？
确认没问题了，再发第二次 Prompt：
方案收到，第二、三条没问题。第一条分页参数校验写得太简单了， 我需要支持页码超出范围时返回 400 和清晰的错误信息。 请按这个调整后，给出完整的代码。这个过程本质上是在跟 AI 做代码评审。你不需要一次到位，而是来回两三轮，把 AI 当同事一样提意见。我实测下来，这种交互方式生成的代码质量，比一锤子买卖高非常多，尤其是复杂模块，差距尤其明显。
2.3 为什么这个 Prompt 结构有效
我自己分析过这里面的原理。AI 模型的推理能力很依赖上下文完整性，你给的上下文越完整，它的输出越稳。目录树和现有代码提供的是"项目局部语境"，而"先方案后代码"则是把需求拆成两个阶段，避免信息过载。
说到底，这就是prompt engineering 里最核心的概念：给模型足够的上下文 + 控制输出粒度。不用搞太玄乎的技巧，这两点做到位，效果就有质的提升。
3. 场景二：排查 Bug 时最值钱的不是答案，而是方向
说到排查 Bug，我先说个反直觉的判断——让 AI 直接告诉你 Bug 在哪，是最浪费它价值的方式。因为 AI 可能猜错，而它一旦猜错，你会花更多时间验证这个错误答案。
我把 AI 当排查助手的方式是：让它帮我缩小范围、理顺因果链，而不是直接给我甩一个"改成这样就好了"的结论。
3.1 我用的 Bug 排查 Prompt（附带报错信息）
我的项目 [技术栈+项目简述] 出现了一个 Bug，信息如下： - 报错信息：[原样粘贴，不要修改，包括行号和堆栈] - 触发条件：[做了什么操作后出现的，比如：上传文件后点击保存] - 预期行为：[应该是什么样] - 实际行为：[实际变成什么样] - 我尝试过但没解决的方法：[这一步可以帮助 AI 排除无效路径] 请不要直接告诉我答案。请先列出最可能的原因排序， 每个原因给一个验证方案，我从第一个开始验证。这个 Prompt 的核心是最后那两句。我不要答案，我要排查路径。原因排序之后的每个验证方案，通常都是一段命令或者一段日志检查，照着做能确认或排除原因。
举一个我实际遇到的例子。之前有个接口偶发超时，报错是TimeoutError，但堆栈指向的代码位置明显不是真正卡住的地方。我用上面的模板发给 AI，它列了四个可能原因，第二个是"连接池耗尽，但表面报错在业务代码里"。我按它的验证方案去看连接池监控，果然发现池被占满，原因是某个异步任务里没释放连接。这个排查思路比我一个人对着堆栈猜快太多了。
3.2 堆栈长、报错乱的时候怎么处理
模型对超长堆栈的处理能力是有限制的，输入过长反而影响准确性。我的做法是：只贴前 30 行左右的堆栈 + 关键的业务代码帧，把重复的无用帧删掉。同时明确指出"这些帧是我自己的代码，这些是框架代码"。
Prompt 里可以加上一句：
堆栈我只贴了前 30 行，后面还有大约 80 行库内部的调用帧， 跟业务逻辑无关，我判断是伪装层。请基于这些信息给排查方向。这种"帮 AI 做了初步信息过滤"的 Prompt，比我试过的任何花哨技巧都管用。本质上是把你自己对问题的初步判断喂给 AI，让它基于你的预分析去深挖，输出质量直接上一个台阶。
3.3 排查完之后一定要做的一步
找到原因并修复后，别急着关掉对话。把最终的根因分析结果和修复方案喂回给 AI，加一句：
这个 Bug 的根因是 [根因]，修复方式是 [方案]。 以后遇到类似现象，应该第一时间检查什么？请总结成一个排查清单。这样你就在 AI 对话里积累了一份"自己的排错手册"。下次再遇到类似问题，可以直接让 AI 按这个清单来排查。长期下来，等于有了一个非常懂你项目历史的排错搭档，这个价值远远超过单次提问。
4. 场景三：让 AI 当“翻译官”，快速读懂别人的代码
接手一个老项目时最痛苦的事是什么？不是代码难，而是你看不到代码背后的设计意图。文件为什么这样拆？这个变量为什么要用全局的？这个函数为什么接收三个看起来无关的参数？
没有项目文档的情况下，直接问同事成本高，自己看又效率低。AI 在这里可以当个尽职的"翻译官"，但前提是——你得让它逐层翻译，而不是一口吃成胖子。
4.1 用“倒序阅读法”读一个不熟悉的模块
我的方法叫倒序阅读：先看接口和数据结构，再看实现，最后看调用点。AI 每次只做一层。
我在看 [项目名] 的 [文件路径]，这个文件是 [模块名] 的实现。 我目前完全不了解这个模块，请帮我看代码前先回答这些问题： 1. 这个模块的对外接口有哪些，入参出参分别是什么 2. 核心依赖哪些外部服务或数据，读还是写 3. 代码里最核心的流程分支是哪些，我用 [行号范围] 标注了 先回答这三个问题，不用展开细节。第二轮再把行号范围精确到具体函数，让它解释函数内部逻辑。第三轮看调用点，搞清楚谁在调用、传什么参数、假设什么情况成立。
整个过程下来，你对这个模块的理解比看十遍代码都深。因为 AI 给出的解释是按我的问题组织的，而不是按代码顺序念一遍。
4.2 让 AI 标出“一定有坑”的地方
老项目的坑通常藏在看起来很正常的代码里，新人不踩几遍根本发现不了。我特别喜欢让 AI 做一件事：
这是 [文件] 里的 [函数]，它看起来一切正常，但我怀疑里面有几个隐藏的坑。 请逐行阅读，指出： 1. 边界条件没处理的地方 2. 隐式的变量或状态更改（副作用） 3. 不合理的错误吞掉方式 4. 可能存在的线程安全或资源泄漏问题 每个问题给一句话解释，并标上行号。这个 Prompt 算是可靠的。尤其是隐式状态更改，AI 很擅长识别函数里那些"顺手改了个全局变量"的代码——这类逻辑人眼看很容易漏，但对线上故障的影响却很大。
4.3 “翻译”出来的结论，自己跑一遍验证
我强调一下：AI 读代码的结论不是 100% 准确的。它对意图的理解经常跟实际代码有偏差，特别是那些用了大量技巧的代码。所以我每让 AI 解释一个关键函数，都会自己跑一遍，或者写个小的测试来验证它说的行为是不是真的。
这不是不信任它，而是方式问题。AI 像经验丰富的同事，他给你描述的内容大部分是对的，但"大部分"不等于全对。代码这件事，跑一遍验证永远比嘴说可靠。
5. 场景四：用 AI 做代码审查，免费且不用等人
代码评审这件事，理想状态是每次提交前都有同事帮你过一遍，但现实往往是你写完直接合入，出了问题再回头看。我现在用 AI 做一轮快速的"预审查"，它发现的问题不一定全对，但可以作为第一次扫描，把低级错误扼杀在合入前。
5.1 通用审查 Prompt，我每次都在用
请审查以下代码，它是我在 [项目] 里的 [功能] 实现，文件是 [路径]。 审查的维度： 1. 是否有可能导致运行时异常的问题（空指针、越界、类型错误） 2. 资源有没有正确释放（文件、连接、锁） 3. 有没有明显影响性能的写法（循环里查库、重复计算） 4. 事务边界是否合理（如果涉及数据库操作） 5. 有没有更好的替代写法，但注意我不要“炫技”式的重构 代码： [粘贴代码，长度控制在 100~150 行，超长就分段审] 最后按严重程度排序，最高级是必须改，最低级是可改可不改。这个 Prompt 的几个要点：
- 限定视觉半径：100~150 行。代码太长，AI 的分析精度会下降。宁可分几次提交，也不要一次性塞给它 500 行。
- 明确"不炫技"：否则它会给你一个大量使用高阶特性的"优雅方案"，好看但难维护。
- 按严重程度排序：让你一眼看到优先级，不用逐条判断。
我实测下来，AI 审查的精确度大概在 70% 到 85% 之间，看代码质量而定。那些真正严重的问题，低级错误部分，它几乎都能一眼命中。剩下 15% 可能是误报，但误报一般是"风格建议"偏多，问题不大。
5.2 代码审查最后的“人类环节”
AI 审查完之后，我会补一个环节——把它的意见全部过一遍，然后只接受其中确实符合我对代码质量预期的部分。尤其是性能相关的建议，我会看它说的是"理论上更优"还是"在这个场景下确实需要优化"。
例：它建议把某个查询从循环里提出来改成批量处理，这确实对。但它建议把一个简单的if改成策略模式，我会直接忽略。策略模式是好东西，但为了一个两分支的 if 引入整个框架，是过度设计。
判断力永远是人的活，AI 只是帮你把本该你一个个过的问题提前放大给你看。
6. 场景五：让 AI 给我的代码写测试，从“应付差事”到真正跑起来
说实话，写测试是我自己最不喜欢干的活，但又不能不做。回归测试靠手点、Debug 靠肉眼，长期下来绝对会出事。所以我现在把 AI 用在"生成测试初稿"上，人工只做两件事：补充边界场景、检查断言是否合理。
6.1 一个能让 AI 好好写测试的 Prompt
我在写 [模块功能] 的单元测试，测试框架是 [Jest/pytest/go test 等]。 已有代码在 [文件]，这是核心函数 [函数名] 的实现： [粘贴代码，100 行以内] 请帮我生成覆盖这些场景的测试用例： 1. 正常的输入和期望输出 2. 输入边界值（空值、极值、超长字符串等） 3. 异常输入的处理（非法参数、格式错误等） 4. 依赖的 mock 策略（如果有 IO、网络、时间依赖） 每个用例给： - 测试名称 - 输入 - 期望结果 - 如果无法直接测试，说明需要重构的接口 另外，请注意现有代码里有没有难以测试的硬编码依赖。关键在最后一个问题——"有没有难以测试的硬编码依赖"。AI 不仅帮你写测试，还会指出代码写的不好测的地方。比如函数里直接new了一个 HTTP 客户端，或者直接读环境变量，这些都是测试的难点。AI 提出来了，你就有机会做小重构，把依赖注入进去，这样重新测试就容易多了。
6.2 让 AI 帮你理解“测试为什么挂了”
测试挂了是家常便饭，但我发现 AI 在"解读测试输出"这件事上特别有价值。
我改了 [文件]，运行测试后 [测试名] 挂了。 失败信息：[粘贴失败断言的内容] 这是我的修改：[粘贴 diff 或相关代码] 请分析： 1. 是我的代码行为改变导致测试需要更新，还是我的改法本身有误？ 2. 如果是测试需要更新，那新的期望值应该是什么？为什么？ 3. 这个变化有没有可能影响其他我没注意到的测试？这个问题问法很关键，让 AI 分别考虑"代码错 vs 测试错"两种情况。我实际经验里，大概四六开，四成情况确实是测试不该更新，代码行为才是错的。它能把这里面分清楚，省了我自己对照旧测试逻辑的半天时间。
6.3 写测试时的核心原则
AI 生成的测试，你永远不要直接跑完绿灯就收工。因为 AI 生成的测试通常是"快乐路径覆盖"——它看到代码的输入输出，自然照着写了，但真正的测试价值在边界和异常里。
我的习惯是：AI 生成初版、我手动补三个用例——空数组、重复数据、超长文本/超大数字。这三个用例是 80% 项目里最容易炸的边界，AI 反而容易漏。补完之后，这套测试才算能真正防回归。
7. 避坑指南：我踩过的坑和现在怎么绕开
这部分是重头戏，全部是真实经历换来的教训。一条条列出来，比任何理论都实在。
7.1 坑一：对话上下文越长，AI 越容易"跑偏"
我用 AI 写代码最大的坑，是把所有东西都塞在一个对话里。修完 A 问题，继续聊 B、C、D，聊到第 30 轮的时候，它已经记不清最开始的需求了，回答质量下降得很明显。
我的解决办法是一个任务一个对话，重要项目语境放 system prompt 或固定在第一轮消息里。10 轮之内聊不完就重新开对话，把关键上下文精简后带过去。
7.2 坑二：AI 的"自信感"不等于"正确"
AI 给代码的时候，语气非常笃定，这是它的语言习惯，不代表它真的保证正确。我见过它一本正经地推荐一个不存在的 API，也见过它把函数参数写错顺序还振振有词。
所以我把 AI 的输出当成"一个刚来的实习生给的方案"来对待。实习生给的东西你不会直接上生产，你会检查、会问测试、会让它跑一遍。对 AI 也是一样。最终验收标准永远是跑起来的结果，不是它解释得多动听。
7.3 坑三：让它干活之前，先给它"固定的规章制度"
带过新人的人都知道，新人刚来你得先说清楚编码规范、目录结构、提交规范，不然他能给你搞出一堆不合规的东西。AI 也一样。
我除了给上下文，还会在 Prompt 里固定规则，比如：
本项目要求： - Python 3.10+，使用类型标注 - 所有新函数必须有 docstring - 错误处理使用自定义异常类型，不裸抛 Exception - 遵循项目的 PEP8 风格，已有代码风格优先于通用规范这个列表放对话开头，比每次提醒强一万倍。模型会把它当成约束条件来遵循，输出的代码风格和你手写的基本一致，后续改起来成本低很多。
7.4 坑四：Prompt 里出现具体名字时，多给它一个"指路牌"
代码里同名变量、同名函数其实挺常见的。如果你在 Prompt 里提到userService，它可能理解成另一个模块里的那个。我的做法是：
我说的 userService 是 [文件路径] 里第 [行号] 开始的那个类， 不是 service/user_service.py 里那个同名函数。给 AI 一个精确的指路牌，能避免它找错对象。这看起来是小事，但在多模块项目里，方向搞错了，后面全是白做。
8. 写完这些之后，我再补充一点体会
上面五套场景模板，我用了大半年，从最开始每轮都费力调 Prompt，到现在基本形成肌肉记忆。有个体会特别明显：用 AI 写代码最大的成本不是 token，是沟通成本。你花在解释项目、整理上下文、澄清需求上的时间，决定了 AI 产出的天花板。
一开始我也嫌麻烦，觉得直接甩一句需求让它写不就完了。后来我发现，好好解释省下的时间远远大于解释花的时间，尤其是排 Bug 的场景，一两条有效信息能省一个小时的瞎猜时间。
最后分享一个小习惯：我每周会花 15 分钟翻一下自己跟 AI 的对话记录，看看哪些 Prompt 效果差、哪些效果好。效果差的就改，效果好的就存下来做模板。这是最朴素的"提示工程"实践——不追求花哨的技巧，只追求重复有效的模板。
如果这篇文章里的模板你觉得能用，就拿去改改试试。如果跑下来发现某些场景效果不理想，多半是上下文没给够，不是"AI 写代码不行"。给它多喂点准确的信息，它会还你一个靠谱的结果。
