1. 为什么我不把 AI 当“代码生成器”而是当“结对搭档”我平时写代码AI 已经深度嵌进了日常工作流。但如果你问我“哪个 AI 写代码最厉害”我一般不会直接回答因为这个问题本身就问偏了。真正决定效率的不是模型排行榜上那零点几个百分点的差距而是你有没有把 AI 放在正确的场景里用正确的 Prompt 去驱动它。举个很常见的例子有人让 AI “帮我写一个用户登录接口”结果拿到一堆看起来能跑、实际上跟项目现有鉴权体系完全不兼容的代码然后得出结论“AI 写代码不行”。但换个方式把项目用的框架、现有的中间件、数据库表结构、错误码规范都交代清楚再让它写出来的东西基本能直接用。差别不在模型在于你有没有把它当成一个需要上下文的搭档而不是一个许愿池。这篇内容我整理了自己平时最常用的 5 个场景每个场景都配上可以直接复制去用的 Prompt。这些场景覆盖了从写新代码、改老代码、排查 Bug、读懂陌生代码库到写测试的完整链路。适合已经有基本编程能力、想把 AI 真正用起来的开发者也适合刚入门、还在摸索怎么跟 AI 协作的新手。我不会讲太多“提示工程”的理论重点放在“我实际怎么问、为什么这么问、问完怎么验证”上。先说一个底层认知AI 写代码的质量约等于你给它的上下文质量乘以你验证它的严格程度。上下文给得越具体验证做得越扎实产出就越靠谱。下面这 5 个场景本质上都是在解决“怎么给上下文”和“怎么验证”这两件事。2. 场景一从零写一个新模块怎么让 AI 一次给对2.1 为什么直接说“帮我写个 XX”基本会翻车新手最容易犯的错就是给一句话需求。比如“写一个限流器”。AI 会给你一个令牌桶或者漏桶的实现但它不知道你用的是什么语言版本、有没有现成的依赖、限流粒度是接口级还是用户级、超限后是返回 429 还是排队等待。这些信息缺失它只能靠猜猜错就是返工。我的做法是在让 AI 写代码之前先花两分钟把“约束条件”列清楚。约束条件包括技术栈、运行环境、输入输出、边界情况、以及项目里已有的约定。这一步看起来麻烦但它能把返工率降下来一大半。2.2 我常用的“新模块生成”Prompt 模板下面这个模板我用了很久基本可以套用到大多数后端模块的开发上你是一名资深后端工程师。请帮我实现一个【模块名称】。 技术栈约束 - 语言/版本【如 Python 3.11 / Go 1.22 / Java 17】 - 框架【如 FastAPI / Gin / Spring Boot】 - 依赖限制【如只能用标准库 已有的 redis 客户端不要引入新依赖】 - 代码风格【如遵循 PEP8 / 项目使用 Google Java Style】 功能需求 1. 【需求点一写清楚输入、输出、行为】 2. 【需求点二】 3. 【需求点三】 边界与异常 - 【如参数为空时返回什么】 - 【如依赖服务超时如何处理】 - 【如并发场景下是否需要加锁】 请先输出实现思路不超过 10 行确认无误后再输出完整代码。 代码中关键逻辑请加注释并在最后列出你做的假设。这个模板里有两个关键设计。第一要求它先输出思路再输出代码。这一步能让你在它写一大堆代码之前就发现方向错误省时间。第二要求它列出假设。AI 在信息不全时一定会自己补全让它把假设显式写出来你就能快速判断哪些假设跟你的项目不符。2.3 拿到代码后我必做的三件事代码生成出来只是开始我一般会做三件事。第一是通读一遍重点看它有没有引入我没要求的依赖以及异常处理是不是符合项目规范。第二是跑一遍边界用例尤其是空值、超长输入、并发这些它容易忽略的地方。第三是让它自己 review 一遍Prompt 是“请以代码审查者的角度指出这段代码可能存在的 3 个问题并给出修复建议”。实测下来它自己找出的问题里大概有一半是我没注意到的。注意不要一次性让 AI 写太大的模块。一个模块超过 200 行它出错的概率会明显上升。我的经验是单次生成控制在 100 到 150 行以内超出的部分拆成多次每次基于上一次的产出继续。3. 场景二改老代码和加功能怎么避免它把逻辑改崩3.1 改代码比写代码更考验上下文在真实项目里写新代码的比例其实不高大部分时间是在改老代码。改代码的难点在于AI 看不到完整的调用链它只看到你贴给它的那一段。如果它不知道这个函数被谁调用、返回值被怎么用就很容易改出问题。我踩过的一个坑让 AI 给一个工具函数加个参数它直接把函数签名改了但没管所有调用方结果编译直接报错。后来我学乖了改代码之前一定先把调用关系交代清楚。3.2 “安全改代码”的 Prompt 写法我需要修改下面这段代码请严格按我的要求来不要做额外改动。 【粘贴原代码】 修改需求 - 【具体要改什么越具体越好】 上下文信息 - 这个函数被以下位置调用【列出调用方】 - 返回值的使用方式【说明】 - 项目中的相关约定【如错误码、日志格式】 要求 1. 只修改必要的部分保持其他逻辑不变。 2. 如果我的需求会导致调用方出问题请先指出来不要直接改。 3. 输出修改后的完整代码并用注释标出改动位置。这里最关键的一句是“如果我的需求会导致调用方出问题请先指出来”。这句话能让 AI 从“执行者”切换成“审查者”很多时候它会提醒你某个改动会破坏兼容性这种提醒价值很高。3.3 用 diff 思维验证改动改完之后我不会直接接受而是让它输出一个改动说明格式是“改了哪几行、为什么改、影响范围是什么”。然后我拿这个说明跟自己的预期对一遍。如果它改了我没要求的地方我会追问“你为什么改了第 X 行这不是我要求的”。多数情况下它会解释少数情况下它会承认是多余的改动然后改回去。这个来回的过程看起来费事但比改崩了再回滚要快得多。尤其是涉及核心业务逻辑的代码多问一句永远不亏。4. 场景三排查 Bug怎么让 AI 从“瞎猜”变成“有依据地推理”4.1 排查 Bug 是 AI 最被低估的用法很多人觉得 AI 排查 Bug 不靠谱因为它看不到运行环境。但实际上只要你把错误信息、相关代码、以及你已经做过的排查步骤给全它的推理能力相当强。关键在于你要给它“证据”而不是只给它“现象”。我见过太多人这样问“我的程序报错了怎么办”这种问法AI 只能给你一堆通用建议比如“检查依赖版本”“看看日志”。但如果你把完整的堆栈信息、出错的那段代码、以及你运行的环境版本都贴上去它往往能直接定位到问题。4.2 我的“Bug 排查”Prompt 结构我在排查一个 Bug请帮我分析根因。 现象描述 - 【什么操作触发了这个问题】 - 【期望结果 vs 实际结果】 错误信息 【粘贴完整堆栈或报错日志】 相关代码 【粘贴出错位置及上下游代码】 环境信息 - 语言/框架版本 - 操作系统 - 相关依赖版本 我已经排查过的方向 - 【如确认了数据库连接正常】 - 【如单独跑这个函数是正常的】 请按以下步骤分析 1. 根据错误信息列出最可能的 3 个原因按可能性排序。 2. 针对每个原因给出验证方法。 3. 不要直接给修复代码先确认根因。这个 Prompt 的精髓在最后一句“不要直接给修复代码先确认根因”。因为 AI 有个坏习惯看到报错就想直接给修复方案但很多时候它修的是表象不是根因。强制它先分析原因能避免你被带偏。4.3 一个真实的排查案例我之前遇到过一个接口偶发超时的问题日志里只有一句“request timeout”没有任何有用信息。我把这个现象、接口的完整代码、以及数据库查询语句都贴给 AI它分析后指出代码里有一个循环里嵌套了数据库查询在数据量大的时候会触发 N1 查询问题导致响应时间随数据量线性增长。这个判断是对的。我后来把循环内的查询改成了批量查询问题就解决了。如果我只贴一句“接口超时”它绝对给不出这个答案。所以排查 Bug 的核心还是把上下文给足。4.4 常见排查方向速查表现象优先排查方向让 AI 帮你做什么偶发超时慢查询、锁竞争、外部依赖分析代码中的循环查询和同步阻塞空指针异常参数校验、返回值判空检查所有可能为空的调用链内存持续增长缓存未清理、监听器未注销找出未释放的引用并发数据错乱共享变量、事务边界检查加锁范围和事务隔离级别编译通过但运行报错依赖版本冲突、配置缺失对比依赖树和配置文件提示排查 Bug 时把“我已经排查过什么”写清楚特别重要。这能避免 AI 重复给你已经试过的建议也能让它在你排除的方向之外找原因。5. 场景四读懂陌生代码库怎么快速建立全局认知5.1 接手老项目时的困境换项目或者接手别人代码的时候最痛苦的不是代码难而是你不知道从哪看起。一个几万行的项目文件几百个调用关系错综复杂。传统做法是顺着入口一点点跟效率很低。我的做法是让 AI 帮我做“代码地图”。5.2 用 AI 做代码结构梳理的 Prompt下面是一个项目的目录结构和部分核心文件请帮我梳理这个项目的架构。 目录结构 【粘贴 tree 命令的输出或者手写的目录树】 核心文件内容 【粘贴入口文件、配置文件、以及你认为最核心的 2-3 个文件】 请输出 1. 这个项目大致是做什么的用一句话概括。 2. 主要的模块划分以及模块之间的依赖关系。 3. 一个请求从入口到返回大致经过哪些环节。 4. 如果我要新增一个功能最可能改动的文件是哪几个。这个 Prompt 里目录结构比代码内容还重要。因为目录结构能反映项目的组织方式AI 通过目录名就能推断出很多信息。我一般会先用tree -L 3或者类似的命令把三层目录导出来再挑几个关键文件贴进去。5.3 从“看懂”到“能改”的过渡光看懂结构还不够真正要能改代码还得知道数据怎么流动。我通常会让 AI 针对某个具体功能画出调用链路。比如“用户下单这个功能从接口进来之后数据经过了哪些处理最后写到了哪些表”。这种问题它能回答得比较准因为它只需要顺着代码跟。这里有个技巧不要一次问整个项目而是挑一条最核心的业务链路让 AI 把这条链路讲透。一条链路搞明白了其他链路基本是类似的模式上手就快了。6. 场景五写测试和补文档把 AI 用在“没人愿意干”的活上6.1 测试和文档是 AI 性价比最高的场景写测试和补文档这两件事技术含量不算高但特别耗时间而且很多人不愿意干。这恰恰是 AI 最擅长的它有耐心不会烦而且能覆盖到你容易漏掉的边界情况。我现在的习惯是每写完一个函数就让 AI 生成对应的单元测试。它生成的测试用例覆盖的边界情况往往比我自己想的还全。尤其是那些“参数为 None”“列表为空”“数值为负数”之类的边界人写的时候容易忘AI 不会。6.2 生成测试的 Prompt 模板请为下面的函数生成单元测试。 【粘贴函数代码】 测试框架【如 pytest / JUnit / Go testing】 要求 1. 覆盖正常路径、边界情况、异常情况。 2. 每个测试用例要有清晰的命名说明测的是什么。 3. 对于依赖外部服务的部分使用 mock。 4. 如果发现函数本身有难以测试的设计请指出来。 请输出完整可运行的测试代码。最后那句“如果发现函数本身有难以测试的设计请指出来”很有用。有时候 AI 会告诉你这个函数因为耦合太紧所以不好测这其实是在提醒你重构。测试写不下去往往说明设计有问题。6.3 补文档的实用做法文档这块我一般不让 AI 从零写而是让它基于代码生成初稿我再改。Prompt 是“请为下面的模块生成 API 文档包括每个函数的用途、参数说明、返回值、以及使用示例”。生成的初稿可能不够准确但框架和格式是现成的我只需要填内容、改错误比从空白页开始快很多。注意AI 生成的测试和文档一定要人工过一遍。测试要确认断言是对的文档要确认参数说明跟实际代码一致。它偶尔会“想当然”地写一些不存在的参数这种错误必须靠人工兜住。7. 让 AI 真正好用的几个底层习惯7.1 上下文要给“够”不是给“多”很多人以为上下文给得越多越好其实不是。给太多无关代码反而会稀释重点让 AI 抓不住关键。我的原则是只给跟当前任务直接相关的代码加上必要的调用关系说明。一个函数能说清楚的事不要贴整个文件。7.2 把 AI 的输出当成“初稿”而不是“终稿”这是心态问题。AI 给的东西永远要经过你的判断。它能帮你省掉 70% 的体力活但剩下 30% 的判断和验证必须你自己来。把它当实习生而不是当专家你的预期就对了用起来也顺了。7.3 建立自己的 Prompt 库我把自己常用的 Prompt 都存成了一个文档按场景分类。下次遇到类似任务直接复制改改就能用。这个习惯坚持下来效率提升很明显。因为好的 Prompt 是打磨出来的每次踩坑后微调一点慢慢就形成了一套适合自己的模板。7.4 几个容易忽略的细节第一明确告诉 AI 你的语言版本。不同版本的语法差异很大不说清楚它可能给你过时的写法。第二涉及安全相关的代码比如鉴权、加密、SQL 拼接生成后一定要重点审查这部分不能偷懒。第三如果 AI 连续两次给出的方案都不对别再追问了换个思路重新描述问题往往比在错误方向上纠缠更快。我在实际使用中最大的体会是AI 写代码的上限取决于你对问题的描述能力。你越能把问题拆清楚、把约束讲明白它给出的东西就越接近可用。反过来如果你自己都没想清楚要什么它也只能给你一堆似是而非的代码。所以与其纠结用哪个模型不如先把“怎么问”这件事练好。这套方法我用了大半年从写新功能到排查线上问题基本都覆盖到了你可以直接拿去试根据自己的项目情况微调就行。
