把AI当结对程序员：五个Prompt模板搞定代码生成、排错与审查

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 写代码不行。给它多喂点准确的信息它会还你一个靠谱的结果。