ChatGPT开发实战：从提示词到代码审查的完整指南

先声明一下这篇文章不教你“用ChatGPT偷懒把代码糊出来”而是聊聊怎么把ChatGPT用成真正的开发搭子——从需求拆解、报错排查、代码重构到测试用例生成每个环节都有合理的工作方式。我用它写了大半年代码从最开始“让它写一小段函数”到现在把它接入完整开发流程踩过不少坑也攒了真金白银的经验。这里面的核心思路一句话就能说清ChatGPT不是替代你写代码的工具而是逼着你把思路讲清楚、把边界定明白的“结对伙伴”。它能不能发挥价值关键不在模型能力多强而在于你怎么喂需求、怎么验收结果、怎么把它输出的代码变成自己代码库的一部分。适用的人很广刚入门的新手可以用它减少卡壳时间工作三五年的开发者可以用它做代码审查和重构建议团队leader可以用它帮忙捋技术方案的边界和风险。前提只有一个——你得有判断力知道自己要什么也知道它给的答案哪些能信、哪些必须重写。1. 先搞清楚边界ChatGPT擅长什么又在哪些地方会坑你1.1 它真正擅长的场景用久了你会发现ChatGPT最稳的应用场景其实非常集中基本逃不出这几类小而具体的算法函数比如“给一段数组按多个字段排序支持中英文混排”这种输入输出明确、约束清楚它一次写对的概率很高。样板代码和轮子补齐读写文件的模板、连接数据库的连接池封装、导出Excel的表格工具类这些“有固定套路但记不全细节”的代码让它生成效率极高。错误信息翻译与排查指引你贴一段报错它能很快告诉你大概率和哪个模块有关下一步该查什么比自己瞎猜快得多。测试用例生成给它一个纯函数让它列出正常输入、边界输入、异常输入的测试表省掉大量脑力。代码解释和文档化一段别人留下的祖传代码贴进去让它逐行解释再把解释整理成注释省心省力。你可以把这理解为“一个读过大量开源代码、但没实际跑过你项目的实习生”。它的优势是知识面宽、反应快、不知疲倦劣势是它不知道你项目的真实上下文也不保证记忆里那些API用法是对的。1.2 它不擅长什么对应的下面这几个场景你要格外警惕我踩坑的几率极高跨模块的大改动涉及多个服务、多个数据表、多处调用链的改动它会简化掉很多关键细节给你的方案看着完整实施起来到处漏风。本地环境特有报错比如某些Windows路径编码问题、某个依赖版本冲突它看不到你的环境经常给一个“理论上正确、跑起来就报别的错”的答案。新框架、新API模型训练数据有截断时间太新的语法和版本改动它不知道经常一本正经地给出已废弃的调用方式。安全敏感的代码生成正则表达式处理用户输入、写鉴权逻辑、处理加密协议时它的输出往往不够严谨直接用在生产环境风险极大。大型重构涉及几百个文件、几十个接口的变动它一次根本记不住硬要它做只会给你一个局部最优的假方案。所以开篇第一课把它当“单点工具”不要把它当“架构师”。凡是超过500行的系统级改动先自己在脑子里想清楚方案再用它做局部的编码辅助这样才稳。2. 提示词不是玄学是需求和约束的翻译过程2.1 为什么你写的提示词不奏效很多人抱怨ChatGPT生成的代码“答非所问”问题八成出在提示词和需求脱节。我给你看个典型对比你品一下差别。低效写法帮我写一个用户登录功能。模型拿到这种输入只能从最常见的模板里挑一个大概率给你Spring MVC风格的登录接口带一个login方法、一个User实体、一个token返回——但它不知道你用不用框架、要不要验证码、密码是MD5还是加盐哈希、Redis存session还是JWT更不知道你的异常处理规范。最后生成的代码你能用的部分不足三分之一。高效写法这个项目用的是Spring Boot 2.7 MyBatis-Plus前端通过JSON提交用户名和密码。登录流程要求先校验参数非空再去查用户表用户存在且状态为1才继续比对密码密码存储用的是BCrypt加盐哈希。登录成功后返回一个包含userId的JWT token过期时间2小时Redis里存一份当前tokenkey是login:token:{userId}。请帮我实现Controller层的方法、Service层的接口和实现注意参数校验和错误码要统一走项目里的Result类和BizException。看出来区别没有需求越具体约束越明确模型越不容易自由发挥。它给出的代码可能还是不能直接跑但“能用的比例”从三成能跳到八成以上。2.2 写提示词的四个要素根据我大量实操的经验每次让ChatGPT写代码起码要包含四类信息缺一不可。第一类交代技术背景。语言、框架、版本、数据库类型、前端还是后端、工具类还是完整接口。别嫌啰嗦模型知道越多上下文就越不容易跑偏。举个例子你说“用Java写一个读取CSV的工具类”它可能会用opencsv库你要是补充一句“项目里不允许引入新的第三方依赖标准库实现就行”它立刻会改成BufferedReader手动解析风格完全不同。第二类说清输入输出。输入参数是什么类型取值范围有没有边界输出希望是什么数据结构。比如排序函数你得告诉它“数组里可能有百万条数据内存有限”它才会考虑流式处理你说“数据量很小”它就直接Collections.sort()。第三类指定约束和偏好。不能用某个库、必须兼容IE11、错误处理走哪个统一类、日志格式是什么、性能要求多少毫秒内返回。约束越清楚生成结果越接近你的预期后面需要修改的地方就越少。第四类提供示例few-shot。这是最容易忽略的。你给它一对“输入 - 期望输出”的示例它马上能理解你要什么风格。尤其生成SQL、正则表达式、JSON转换这类代码时给一个正确的例子比描述一百句都有用。2.3 一个可以直接套用的模板我自己现在每次写“稍复杂”的开发请求时基本都用下面这个模板你也可以存起来改着用技术栈Java 17 / Spring Boot 3 / MyBatis-Plus 3.5 任务写一个分页查询用户列表的Service方法 输入pageNum, pageSize, keyword用户名模糊查询, status可空不传则查全部 输出返回IPageUserVO其中不含密码字段 约束 1. keyword不为空时才拼接条件避免空条件查全表 2. status为空时不作为查询条件 3. 排序按create_time倒序 4. 不要使用BeanUtils手工映射VO 示例 keyword张, status1, pageNum1, pageSize10 返回第1页每页10条包含用户名含“张”且状态为1的用户 请先列出你理解的要点再输出代码。最后那句“请先列出你理解的要点再输出代码”是个小技巧——逼着模型先复述需求能帮你提前发现需求理解偏差比让它直接写代码再改效率高得多。2.4 多轮对话的上下文维护ChatGPT的对话是一次性上下文但代码开发注定是多轮的。实际开发里我的习惯是第一轮丢全量需求让它产出完整方案或代码第二轮开始只丢增量修改比如“上一版代码里把排序改成支持两个字段createTime倒序、id正序”第三轮如果它开始遗忘前文回答明显和前面矛盾了就重新贴一遍关键方法签名和核心约束不要抱怨它记性差。记住一个原则每次提问占据的上下文窗口是有限的代码和约束的重复成本远低于方案跑偏的修正成本。该重新贴的代码不要懒。3. 把ChatGPT嵌进实际开发流程从需求到上线的每一步3.1 需求分析和方案设计阶段很多人以为ChatGPT只能写代码其实我用得最爽的环节是方案设计的前置讨论。你别一上来就问“怎么做”而是问“我遇到这个问题有哪些可行路径各自优缺点是什么”。举个例子我最近做一个文件上传功能需求不复杂支持大文件分片、断点续传、秒传。我没直接让它写代码而是问它我用Spring Boot实现文件上传需要支持分片和断点续传第二次上传能跳过已上传的分片。请给出三种实现方案说明每种方案对前端的要求、后端存储的结构、以及并发冲突怎么处理。它列了三种方案一是前端切片后端根据分片编号合并二是后端维护上传会话分片索引三是和对象存储结合、预签名URL直传。看完对比我心里就有了数再让它展开方案二的具体表结构和接口设计。这个流程的价值在于它把你自己没想到的路径和风险提前摆出来了等于花五分钟做了一个小型的咨询讨论。3.2 编码阶段不是让它整段写而是让它写零件我观察到一个规律让ChatGPT写1000行的完整模块质量一定崩让它写50-200行的零件一个工具方法、一个转换函数、一个正则、一个SQL质量相当高。所以我的编码流程是自己把模块拆成函数和类的粒度拆出“通用性高、逻辑独立、能跑单测”的零件让ChatGPT逐个生成这些零件自己负责拼接和集成。比如做一个数据清洗的功能我不会让它写完整流程而是让它写“把手机号中间四位脱敏的函数”输入、输出、边界都想清楚让它写“从文本中提取所有URL的正则要支持http和https要去掉尾部标点”让它写“把Excel中的日期字符串统一转成LocalDateTime兼容多种格式”。请求的颗粒度越小它的准确率越高你审核代码的压力也越小。这个经验适用于任何框架写微服务也好写脚本也好都建议把大任务掰开揉碎了喂。3.3 报错排查的黄金流程其实报错排查是ChatGPT最被低估的技能。它读报错信息的阅读理解能力比大多数人自己看控制台强得多。我的操作步骤先把报错信息完整贴进去再把相关代码块也贴进去最后告诉它“这段代码在本地跑没问题放到容器里就报这个错”。它会分析环境和编码差异给出可能性排序。比如有一次我在生产环境跑定时任务报ORA-01000: maximum open cursors exceeded本地和测试环境都没事请帮我分析可能的原因。它给出的第一个方向就是连接池配置问题——因为生产环境并发高Statement没关闭导致游标耗尽。我顺着这个方向去查果然发现有个PreparedStatement放在循环外没正确close。这个排查方向如果自己盲查至少得一两个小时它帮我在十分钟内锁定了范围。但要注意它给的第一个原因往往不是唯一原因所以别拿到答案就动手改要按概率排序逐个排查。它给的是“可能性列表”不是终极结论。我习惯让它先写一段“按可能性从高到低的排查清单”然后按清单逐步验证。3.4 代码审查和重构代码审查也是ChatGPT一个非常实用的场景。我经常把一段“刚写完但感觉哪里不对”的代码贴过去问它三个问题这段代码有没有潜在Bug有没有更简洁、更符合现有写法的替代实现并发场景下有没有线程安全问题它给出的审查意见通常比我同事的review意见还细因为同行看代码往往只关注业务逻辑正不正确而这种“边界条件、资源泄漏、异常处理缺失”的审查恰好是模型的强项。推荐一个高效的审查提示词假设你是一位有10年后端经验的架构师请审查以下代码。重点检查1. 空指针和边界条件2. 资源管理是否安全3. 多线程或异步场景下是否有竞态4. 是否违反常见代码规范。先列出问题清单再给出修改建议不要直接输出重写后的完整代码。先来问题清单这个要求很重要它避免模型直接“包办重写”让你能对照清单逐项决策而不是被一整片新代码糊住眼睛。3.5 测试用例和文档生成写完业务代码后我习惯让ChatGPT负责“产出测试表”而不是直接写测试代码。我给它一个纯函数要求列一下这个函数需要覆盖的测试场景包括正常输入、边界值、空值、超长值、特殊字符、并发调用等每个场景给出输入和预期的输出或异常类型。它给的测试场景经常能覆盖到我自己没想的角落比如时间边界、时区问题、浮点数精度。然后我再挑其中关键场景让它生成具体的测试代码。这样既保证了测试覆盖率又避免了让模型一次性生成大量测试文件时出现的“张冠李戴”问题。文档这块就更简单了让模型把代码的流程用文字讲出来再整理成接口文档的结构方法描述、参数、返回、异常、调用示例。只要代码逻辑清晰它整理出来的文档比自己写节省的时间相当可观。4. 安全底线都不知道保密这关怎么敢往上提4.1 敏感信息绝对不要直接贴这是我最想强调的一点。涉及公司内部核心代码、数据库连接串、云服务器密钥、用户个人信息永远不要原封不动地贴给ChatGPT。别高估什么“对话不会泄露”一旦数据上传第三方服务脱离了你的控制出了事你担不起。我刚接触的时候就踩过类似边缘差点把生产环境的数据库IP和账号密码贴进对话里后来反应过来赶紧脱敏。现在的做法是先把真实信息替换成xxx或test只保留代码结构和逻辑。具体脱敏手法数据库连接直接改成jdbc:mysql://localhost:3306/test服务器IP改成192.0.2.1文档保留段地址密码、Token改成******真实类名和业务名改成UserX、OrderServiceX等中性代称。脱敏之后模型依然能理解代码逻辑但敏感信息就出不了门了。这条习惯比任何提示词技巧都重要。4.2 生成代码的依赖与版本陷阱ChatGPT生成代码时经常附带上“你需要安装某个依赖”“你可以用这个库实现”而且它给的库名、版本号、API用法经常和实际存在的不完全一致。模型训练数据里有大量开源库但它不知道某个库是否已经改名、某个版本是否已停止维护。所以拿到带依赖的代码我的动作是先去包管理仓库确认这个库是否存在、最新版本号是多少、API是否是示例里那么写的。不要因为它给出了看起来完整的pom.xml或package.json就直接复制。比如它曾经给我生成了一段用某私有JSON库的代码我去一查发现这个库在Maven中央仓库根本不存在是模型“一本正经编造”的依赖名。这种情况不止一次所以凡是编译不过先别慌检查“依赖是否真实存在”往往比查代码语法更快。4.3 生成代码的License问题让ChatGPT生成代码时它可能在无意识中“参考”了某些开源协议的代码片段。如果你的项目是商业闭源软件直接拿来用可能有License风险。国内对这个不敏感但真收到律师函的时候已经晚了。我的自查习惯是让它生成的代码尽量以“通用实现思路”为主避免让它整段复刻某种特定开源的实现涉及重要算法自己再用其他资料交叉验证。目前我还没遇到过实际的License纠纷但这类风险意识必须有。5. 踩坑实录这些坑能避一个是一个5.1 上下文爆炸后的“记忆错乱”有一次我让它帮忙改造一个多线程数据同步的模块对话进行了十几轮中间反复贴了多次代码。突然它给我输出一个方案里面对同一个方法名一会儿叫syncTask一会儿叫executeTask明显是上下文窗口记混了。后来我重新开了一个新会话把关键类名、方法签名、需求约束重新写清楚一次就正常了。经验一个会话聊太深入了与其继续修补不如果断开新会话把核心上下文重新交代一遍。新会话的“清醒头脑”远胜过旧会话里混乱的前文记忆。5.2 生成的代码“看起来很对跑起来必挂”有个经典的例子让它写一个“判断字符串是否是合法日期”的函数。它给我的第一版用了SimpleDateFormat的setLenient(false)但没处理空字符串和yyyyMMdd这种纯数字格式的情况。测试数据里有202401这种半截字符串结果直接过了校验跑到业务层才发现异常。教训模型生成的代码尤其是涉及格式解析、用户输入、时间日期这类逻辑必须自己补边界测试。它的自信程度和正确率不成正比测试用例才是真正的裁判。5.3 生成的SQL没走索引还有一次我让它基于MyBatis-Plus写一个复杂查询它给的条件里用了LOWER(name) LIKE CONCAT(%, #{keyword}, %)逻辑上没错但生产环境有十几万数据这个查询直接全表扫描。模型没法知道你哪个字段建了索引也没法评估数据量所以在性能敏感的SQL上生成结果只能当草稿索引和性能优化必须自己动手。5.4 编造不存在的API我在前文提过编造依赖名的问题这里再补一个变体它可能编造某个语言标准库根本不存在的方法比如编一个StringUtil.isBlank()而这个工具类只存在于某个第三方包中。解决办法有两个一是让它“只能使用JDK8自带API不要引入任何第三方工具类”二是代码拿到后对着官方文档把每个API过一遍。识别这种幻觉的最快办法是问它“这个API在哪个版本的标准库里给我列出官方文档的类签名”。它如果支支吾吾或者给不出具体版本多半是编的。5.5 测试全绿但等于没测最迷惑人的坑让它生成的单元测试全跑通过但你仔细看它只测了“正常路径”而且断言写得极其宽松比如只断言返回结果不为空根本没有验证结果是否正确。这种行为在模型里非常普遍生成的单测只能当“探索性测试的起草”不能当信心来源。我的做法是拿到生成的测试后故意删掉其中几个核心断言看测试是否仍然通过如果删了也没事就说明这个测试没用必须重写关键断言。6. 我的一点真实体会用ChatGPT做开发到现在最大的变化不是“写代码变快了”而是“想得比以前更清楚了”。你每喂给它一个需求都得先把它拆成机器能理解的语言你每验收一段它写的代码都得先在心里划定验收标准。这个过程本质上是逼着自己变得更专业。我的建议是别把ChatGPT当“答案机器”把它当成“校验镜”你觉得方案没问题让它吹毛求疵挑漏洞你觉得逻辑很简单让它找边界你觉得测试写够了让它列遗漏场景。你会发现它最大的价值不是替你省时间而是把你从“自我感觉良好”里拽出来逼你把每个细节都夯实。最后奉劝一句能在一个领域站稳脚跟的永远是那些既会用AI提效、又能对AI输出负责的人。工具会迭代模型会升级但你的判断力、代码品味、对业务的理解才是真正搬不走的东西。