有一次我被一个临时需求绊了一下午某个内部数据平台要出一份按用户聚合的订单报表字段对不上、文件编码还不统一。折腾到一半我抱着试试看的心态把需求整理成一段话发给了ChatGPT它给的Python脚本帮我省掉了大半天的重复劳动。那一刻我意识到用ChatGPT提升开发效率这件事是真实的但真正决定效率上限的不是模型本身多聪明而是我提问的方式和验证的习惯。这篇文章就把我在日常开发里用ChatGPT的完整思路写下来从需求拆解、提示词写法到测试、重构、排查报错再到那些曾经骗过我的错误答案。内容适合经常和脚本、临时需求打交道的开发者也适合想从“偶尔问一句”过渡到“把ChatGPT接进工作流”的人。我会尽量把每一步的“为什么”也讲清楚这样你看完可以直接套用而不是只收藏一堆碎片技巧。1. 先摆正位置ChatGPT是结对开发者不是自动代码机1.1 用错姿势的人迟早会失望我第一次用ChatGPT写代码时也把它当成一个“输入需求就吐完整项目”的自动代码机。结果当然碰壁需求写得越宏观输出越空泛问题问得越模糊代码越像模板。后来我才想明白一个类比它更像一个刚入职、知识面极广但完全不了解你业务背景的结对同事。你让它“优化这个模块”它不知道模块在哪、依赖什么、被谁调用只能给你一套放之四海而皆准的建议。把定位从“工具”换成“结对开发者”很多使用姿势就顺了。结对开发者需要你给上下文、给约束、给验收标准你也需要对它的产出负责。ChatGPT可以帮你加速思考、生成初稿、查漏补缺但它不该替你做架构判断更不该在你完全没有验证能力的时候直接决定生产代码怎么写。1.2 真正能提效的三类任务我用了大半年后发现效率提升最明显的始终是这几类任务一次性脚本和数据处理批量改文件名、日志清洗、CSV转换、目录结构整理。这类任务需求容易描述清楚结果可以立即运行验证非常适合让ChatGPT直接生成。陌生代码和报错解释把一段看不懂的历史代码贴给它让它用白话讲逻辑把一堆堆栈丢给它让它先定位根因再给修复方向。这比逐行搜文档快得多。模板性、脚手架式代码单元测试骨架、接口文档、配置样例、SQL查询、正则表达式。这些内容结构性强重复度高模型非常擅长。这类任务的共同点是目标明确、上下文适量、结果可验证。只要满足这三点ChatGPT的产出质量通常能直接拉满。1.3 哪些事不该交给它与之相对的有三类事情我会刻意少做第一需求还没定义清楚时的系统设计。你让它“帮我想想这个平台怎么设计”它只能给出平均水平的方案。平均水平的方案放在具体业务里往往就是不可落地的方案。第二高度依赖业务规则的逻辑。比如复杂的计费规则、审批流、权限模型模型不了解你的内部约定生成的代码大概率要推翻重写。第三安全敏感的关键路径。涉及支付、密钥、用户隐私的部分至少要人工review到每个分支甚至干脆只把ChatGPT当作思路参考。所以在打开对话框之前我会问自己三个问题我清楚自己要什么吗我能判断输出对不对吗我会去验证吗如果答案有任何一个是否定那当前任务还不适合让模型直接产出代码。2. 一次完整实战把含糊需求变成可运行的报表脚本2.1 第一版提示词像给同事布置任务一样说话空谈定位没用直接看一次完整流程。假设我现在要处理一批用户订单数据需求是“把多个CSV文件按用户ID去重合并最后生成一个统计报表”。这种需求在业务里很常见但直接丢给ChatGPT很容易得到太随意的结果。我实际写的第一版提示词是这样的你是一位有经验的Python开发者。我有一批用户订单数据存放在同目录下的多个CSV文件中每个文件的字段顺序完全一致user_id, order_id, amount, created_at。 请帮我写一个Python脚本读取同目录下所有CSV文件按user_id聚合输出一个summary.csv包含三列user_id、订单总数、订单总金额。 要求 1. 只使用Python标准库尤其是csv模块不要引入pandas等第三方依赖 2. 遇到空文件或缺失字段时在命令行输出警告但不要中断整个任务 3. amount字段可能为空字符串按0处理 4. 输出文件按user_id排序 5. 请给出完整代码和运行方式。这段提示词看起来啰嗦但每一句都有目的。指定“不要pandas”是防止它选型自由度太大引入一个当前环境可能没有的依赖“字段顺序一致”这种说明是为了消除它对着未知数据结构的猜测要求“完整代码和运行方式”是为了少一次来回。2.2 拿到代码后的第一步不是复制而是追问ChatGPT会给出一个可运行的脚本但我的习惯是先不急着复制。我先把它生成的代码放进临时目录用一小份造假数据试跑确认基本流程能通。然后再回过头来追问边界问题。这是我自己很关键的一步把边界场景作为增量需求而不是让它一次性考虑完。一次说得太多模型容易顾此失彼。我通常这样追问脚本基础功能可以跑通。现在再帮我检查几个边界 1. 如果某个amount字段是纯空格当前逻辑会不会出错 2. 如果有两个文件里出现相同的user_id但大小写不一致比如USER_001和user_001要不要合并 3. 如果CSV文件带UTF-8 BOM用csv库读取时会不会把第一列列名读成\ufeffuser_id 请针对这些情况更新代码并在代码之外单独列一遍你做了哪些改动。这种追问的意图很明确让模型做增量修改同时把改动点显式暴露出来方便我做人工检查。它给出来的答案通常比第一次生成更可靠因为有了具体场景而不是泛泛的“考虑边界”。2.3 让ChatGPT给自己生成测试数据很多人在这一步就结束了但我建议再补一个动作让ChatGPT生成一份带脏数据的测试样本。请帮我写一个generate_sample_data.py生成5个CSV文件模拟上面的订单数据。要求包含以下脏数据 - 至少一个空文件 - 至少一个amount字段为空字符串 - 至少一个文件带UTF-8 BOM - 至少两行user_id大小写不一致 - 最后一个文件里包含一个格式错误的列。这个脚本跑一遍生成的测试数据直接喂给报表脚本。如果它能处理完这堆乱七八糟的输入那么这个脚本才算真正有了可交付的底气。让模型生成数据、再让同样的模型生成处理代码本质上是用它的知识盲区互相暴露问题处理代码可能漏边界测试数据就专门造边界。2.4 这个案例沉淀出的流程模板做完这个需求后我把流程整理成了一个固定套路写提示词角色、背景、数据格式、约束、输出要求一次说清。先生成初稿不要追求一步到位拿到能跑的基础版本更重要。边界追问把边界场景拆成几轮一轮一个主题地喂给模型。生成测试数据用脏数据主动制造“出问题”的机会。独立执行验证在干净环境里跑脚本确认输入输出都符合预期。补注释和文档让模型为最终代码补一段使用说明方便交接。这套模板我后来几乎套用到了所有一次性脚本任务上。它不神奇但非常稳。3. 让ChatGPT真正理解项目上下文注入与提示词写法3.1 上下文注入的四个层次ChatGPT不读你的项目仓库它只知道你贴给它的内容。所以“上下文注入”的质量直接决定产出质量。我一般按需贴四类信息而不是一股脑把所有代码都丢进去技术栈和运行环境比如“Python 3.10后端服务”“前端React TypeScript”“脚本运行在Windows的Git Bash里”。这能让它避开你环境里不存在的语法和依赖。相关函数或类的签名如果你要新增功能最好把现有接口签名贴出来明确“不要改变对外签名”。输入输出样例给它一组具体数据告诉它输入长什么样期望输出长什么样。模型对具体例子的理解能力远强于抽象描述。存量代码片段不是贴整个文件而是贴与当前任务直接相关的函数段落让它模仿现有风格。举一个我常遇到的例子。如果我只说“帮我重构这个函数”它不知道函数几百行、有没有被别处调用。但如果我这样说项目背景这是一个Python后端服务目前所有业务入口都会先经过validate_order这个函数。 任务以下函数太长了请把参数校验部分抽成独立函数并在原函数中调用。 现有代码 def validate_order(order, config): # 50行参数校验 # 30行业务规则 # 20行异常处理 约束 - 不要改变validate_order的对外签名 - 不要引入新的第三方库 - 保持原有注释风格。 请给出抽离后的完整代码并说明你的改动覆盖了哪些分支。这样它就知道这是存量项目、有外部调用约束、不能顺手换技术栈。上下文一给足回答质量马上不一样。3.2 一套可以复用的提示词模板用了很久之后我沉淀出一个通用模板基本能覆盖大多数“让ChatGPT写代码”的场景背景项目的简要说明包括技术栈、运行环境、当前模块的作用。 角色你希望它扮演的角色比如“有经验的Python后端工程师”。 任务要完成的具体事情越具体越好。 约束不要做什么、必须做什么例如“不要引入新依赖”“不要改变函数签名”。 输入要处理的数据样例或代码片段。 输出格式希望它输出的形式例如“完整代码运行方式”“代码逐行注释”。 请先复述一遍你对任务的理解确认无误后再开始。最后那句“请先复述一遍你对任务的理解”是我最推荐的技巧。很多答非所问都发生在任务描述有歧义的时候。让模型先复述相当于用一轮对话换一次对齐成本极低收益非常大。3.3 用“外置记忆”对抗上下文流失长对话聊久了模型会慢慢忘记最初的要求。最典型的表现是第一轮要求“只用标准库”聊到第五轮它突然给你一段pandas代码。这不是它变笨了而是上下文窗口里新旧信息互相挤压早期的约束被冲淡了。我的对策是“外置记忆”当对话很重要时我会在聊到一定深度后补一句请把我们刚才达成的结论用三条关键信息总结出来包括技术约束、最终方案、还没解决的边界问题。把这段总结复制进一个新的对话作为开头上下文。这样相当于给模型做了一次“记忆压缩”既不丢失关键决策又避免长对话里的漂移。这个方法在处理多轮重构任务时救了我很多次。4. 写代码只是其中一环我更常用的四个辅助场景4.1 排查报错先定位根因再谈修复日常开发里写新代码的时间其实远没有排错的时间多。ChatGPT在排错时最大的价值不是直接给修复代码而是帮你把根因从模糊的堆栈里捞出来。我会把报错堆栈、相关代码、期望行为一起贴进去下面这段代码在读取文件时会抛异常。请先根据堆栈定位最可能的根因再给出修复方案。不要只给结果请解释为什么会发生。 代码 import csv with open(data.csv, r) as f: reader csv.reader(f) for row in reader: print(row[1]) 报错 IndexError: list index out of range 期望行为 在遇到不完整行时跳过该行并打印警告。注意我要求“先定位根因再给修复方案”。这一步很关键因为ChatGPT有时候会跳过分析直接给代码而那些代码常常只是撞对了并不是理解了问题。让它先解释你可以从解释里判断它是真懂还是在编。4.2 生成单元测试让模型先列边界策略让ChatGPT直接生成测试用例最大的坑是它只会写“Happy Path”专挑正常输入测。解决的办法是让它先列测试策略再写测试代码。请为一个纯函数generate_summary(rows)设计单元测试策略。这个函数接收一个字典列表每个字典包含user_id、amount、created_at字段返回按user_id聚合并排序后的列表。 请先列出至少5个边界场景覆盖空列表、amount为空、user_id重复、日期格式异常、超大整数金额。然后基于pytest为这些场景生成测试代码。不要mock尚未接触过的外部依赖。这样出来的测试代码覆盖面明显更广。更重要的是它列出的边界策略可以直接当作你手工测试的检查清单即使最终代码不适合全盘复用这份清单也值回票价。4.3 代码Review让它当挑刺的人而不是鼓掌的人让ChatGPT review代码时我一般会指定“挑刺方向”否则它大概率会说“代码整体良好一些小建议如下”。请从以下角度review这段Python函数 1. 是否存在文件或网络资源没有关闭的问题 2. 是否存在异常被吞掉的情况 3. 是否存在明显的并发安全隐患即使当前是单线程运行 4. 是否有重复计算可以提取 5. 是否有魔法数字应该定义为常量。 对每个问题请给出所在行号、风险等级和修改建议。如果没有发现问题请明确说“该角度未发现问题”不要为了凑建议而编造。最后那句“没有发现就直说”很关键能明显减少那种为了显得认真而硬挑出来的问题。它给的review结果我会当作第二轮自查清单逐条确认后再决定改不改。4.4 提交信息、注释、接口文档全包了代码写完后的收尾工作我也基本交给ChatGPT处理。比如准备commit message时我会给它diff或一段变更描述根据以下变更内容生成一个符合Conventional Commits的提交信息。要求格式为type(scope): description正文控制在三行以内。变更修复CSV导入时BOM导致第一列列名带前缀的问题新增对空文件的警告。写注释时也一样我不让它做“逐行翻译”而是让它用两三句话概括函数的设计意图和边界注意点。这类工作的特点是结构固定、评价标准明确模型产出的质量非常稳定我只需要做少量删改。5. 实战避坑清单那些曾经骗过我的错误答案5.1 幻觉API和过时库看起来天衣无缝一跑就错ChatGPT有个很迷惑人的毛病它会把不存在的API说得跟真的一样或者使用一个旧版本已经废弃的写法。我有一次让它写一段ORM查询它给出来的方法是旧版本里的写法在现行版本中直接抛AttributeError。报错那一刻我才意识到它会一本正经地编造“记忆里的API”。对策有两层。第一层是在提示词里加一句硬约束“请只使用你知识范围内稳定且通用的API如果不确定某个库的具体写法请明确说‘我不确定’不要猜测。”第二层是养成查官方文档的习惯。重要代码里的关键API我一定会去官方文档确认一次。把ChatGPT当成“说人话的文档索引”可以但不要当成“权威文档本体”。5.2 上下文漂移聊得越久离最初的约束越远前面提到过长对话会丢失早期约束。这不仅仅是“忘了”那么简单它可能在某个环节为了满足你新提的需求悄悄换掉了之前的既定方案。我经历过一次前两轮都在用标准库写第三轮它突然引入了一个第三方库理由是“更方便处理大数据”而我的原始约束明明是不允许第三方依赖。现在我养成了两个习惯一是关键约束在每轮提示词里重复一遍比如“继续使用标准库不新增依赖”二是每完成一个重要阶段就做一次上下文总结然后开新对话重述。把模型当成一个记忆有限但能力尚可的协作者你自然会为它设计“外置记忆”。5.3 隐私和密钥泄露比代码错误更严重这是我最想强调的一条。有些人为了省事会把真实的数据库连接串、密钥、用户手机号直接贴在对话里。我见过最危险的一次是同事为了调试把一段包含生产环境连接信息的配置原文发了过去。ChatGPT不是本地工具你发上去的内容应默认视为不可控的。安全的做法是脱敏之后再问。你可以把真实数据替换成结构相同的假数据甚至把敏感逻辑抽象成只有字段名和类型的伪代码。如果在提示词里需要“一个包含用户手机号的样例行”那就写成这里用脱敏示例数据替代真实数据字段类型和格式保持一致 {user_id: U1001, phone: 13800000000, email: userexample.com}这种习惯既不影响模型理解结构又能避免把真实信息泄漏出去。5.4 “能跑”不等于“可以上生产”ChatGPT生成的代码放到样例数据上经常跑得很顺但这不代表它能应对真实环境的全部情况。它不会主动替你处理事务边界、并发冲突、重试策略、日志埋点、服务降级。有一次它给我生成的导入脚本在单测环境完美运行放到生产数据上一跑因为数据量大了几倍内存直接暴涨。从那以后我把“能跑”和“可以上线”严格分开。脚本类任务跑通数据就算完成服务端核心代码我会额外review资源释放、异常处理、并发、性能边界。模型负责把初稿铺出来但也仅此而已。5.5 提问越模糊答案越没用模糊提问是ChatGPT使用效率的最大杀手。做个对比就清楚了提问方式实际效果“帮我优化一下这段代码”得到一堆泛泛的建议甚至可能改了风格但没改性能“这个函数负责按user_id聚合金额当前数据量约10万行当前实现遍历两次。请改成一次遍历并说明复杂度变化。”得到具体可落地的代码、复杂度分析和验证建议“帮我写个脚本处理Excel”得到一段与你真实环境大概率不匹配的代码“生成一个脚本读取同目录下所有xlsx文件按B列合并数据输出到result.xlsx要求保留A列格式”得到能直接跑并接近交付的代码我把这个规律总结成一句话你愿意多花三十秒把问题说清楚就能省下后面三十分钟的返工。6. 沉淀下来的工作流我每天如何用ChatGPT写代码6.1 我的日常节奏现在我的用法已经比较固定了。接到任务后先自己把需求拆成几个可独立验证的小任务再逐个开新对话和ChatGPT协作。每个任务都走“上下文注入、生成初稿、边界追问、运行验证、人工review”这条线。这个节奏最大的好处是每个对话的目标都足够小上下文不会被污染模型的输出质量很稳定同时因为每个阶段都有验证动作哪一步出了问题我一清二楚不会出现“到最后一跑才发现方向错了”的情况。6.2 把提示词模板沉淀成团队资产用的时间久了我攒下一批适合自己的提示词模板按场景分类存放一次性脚本类、单元测试类、报错排查类、代码review类、文档生成类。每次用完后我会顺手把“这次踩到的坑”“模型在哪一步理解偏了”补在模板后面。这些东西不一定要神秘它就是一份“怎么给AI布置任务”的实操手册。我在团队内部也做过一点分享大家把各自用得顺手的提示词放进来很快形成了一个小小的提示词库。新人来了不用从零摸索提问姿势直接照着模板改改就能用。6.3 最后一个提升幅度最大的技巧保存验证过的对话而不是生成结果如果只让我留一条经验那就是比起保存ChatGPT生成代码的最终结果更应该保存那条验证过、调整过的提示词链路。我在本地笔记里会这样记录一个任务目标合并多个CSV按user_id聚合输出统计报表 关键约束只用标准库、空字段按0处理、BOM兼容 踩坑点模型在第三轮试图引入pandas已拒绝UTF-8 BOM首次未处理 提示词版本见下方链接 最终代码存档脚本路径下一次遇到类似任务我不用重新思考怎么提问直接打开旧记录复制提示词链路替换字段名和业务规则几分钟就能生成一版可靠度很高的结果。这比把每次生成的代码当作一次性答案丢掉要划算得多。我自己试过之后最大的感受是ChatGPT提升开发效率是真的但效率的天花板取决于你为它建立的流程和校验体系。那些把AI用成“高级搜索框”的人和我后来这种“把它当成可复用的协作流程”的用法产出差距会越来越大。 用ChatGPT提升开发效率：从提示词到代码落地的完整工作流
有一次我被一个临时需求绊了一下午某个内部数据平台要出一份按用户聚合的订单报表字段对不上、文件编码还不统一。折腾到一半我抱着试试看的心态把需求整理成一段话发给了ChatGPT它给的Python脚本帮我省掉了大半天的重复劳动。那一刻我意识到用ChatGPT提升开发效率这件事是真实的但真正决定效率上限的不是模型本身多聪明而是我提问的方式和验证的习惯。这篇文章就把我在日常开发里用ChatGPT的完整思路写下来从需求拆解、提示词写法到测试、重构、排查报错再到那些曾经骗过我的错误答案。内容适合经常和脚本、临时需求打交道的开发者也适合想从“偶尔问一句”过渡到“把ChatGPT接进工作流”的人。我会尽量把每一步的“为什么”也讲清楚这样你看完可以直接套用而不是只收藏一堆碎片技巧。1. 先摆正位置ChatGPT是结对开发者不是自动代码机1.1 用错姿势的人迟早会失望我第一次用ChatGPT写代码时也把它当成一个“输入需求就吐完整项目”的自动代码机。结果当然碰壁需求写得越宏观输出越空泛问题问得越模糊代码越像模板。后来我才想明白一个类比它更像一个刚入职、知识面极广但完全不了解你业务背景的结对同事。你让它“优化这个模块”它不知道模块在哪、依赖什么、被谁调用只能给你一套放之四海而皆准的建议。把定位从“工具”换成“结对开发者”很多使用姿势就顺了。结对开发者需要你给上下文、给约束、给验收标准你也需要对它的产出负责。ChatGPT可以帮你加速思考、生成初稿、查漏补缺但它不该替你做架构判断更不该在你完全没有验证能力的时候直接决定生产代码怎么写。1.2 真正能提效的三类任务我用了大半年后发现效率提升最明显的始终是这几类任务一次性脚本和数据处理批量改文件名、日志清洗、CSV转换、目录结构整理。这类任务需求容易描述清楚结果可以立即运行验证非常适合让ChatGPT直接生成。陌生代码和报错解释把一段看不懂的历史代码贴给它让它用白话讲逻辑把一堆堆栈丢给它让它先定位根因再给修复方向。这比逐行搜文档快得多。模板性、脚手架式代码单元测试骨架、接口文档、配置样例、SQL查询、正则表达式。这些内容结构性强重复度高模型非常擅长。这类任务的共同点是目标明确、上下文适量、结果可验证。只要满足这三点ChatGPT的产出质量通常能直接拉满。1.3 哪些事不该交给它与之相对的有三类事情我会刻意少做第一需求还没定义清楚时的系统设计。你让它“帮我想想这个平台怎么设计”它只能给出平均水平的方案。平均水平的方案放在具体业务里往往就是不可落地的方案。第二高度依赖业务规则的逻辑。比如复杂的计费规则、审批流、权限模型模型不了解你的内部约定生成的代码大概率要推翻重写。第三安全敏感的关键路径。涉及支付、密钥、用户隐私的部分至少要人工review到每个分支甚至干脆只把ChatGPT当作思路参考。所以在打开对话框之前我会问自己三个问题我清楚自己要什么吗我能判断输出对不对吗我会去验证吗如果答案有任何一个是否定那当前任务还不适合让模型直接产出代码。2. 一次完整实战把含糊需求变成可运行的报表脚本2.1 第一版提示词像给同事布置任务一样说话空谈定位没用直接看一次完整流程。假设我现在要处理一批用户订单数据需求是“把多个CSV文件按用户ID去重合并最后生成一个统计报表”。这种需求在业务里很常见但直接丢给ChatGPT很容易得到太随意的结果。我实际写的第一版提示词是这样的你是一位有经验的Python开发者。我有一批用户订单数据存放在同目录下的多个CSV文件中每个文件的字段顺序完全一致user_id, order_id, amount, created_at。 请帮我写一个Python脚本读取同目录下所有CSV文件按user_id聚合输出一个summary.csv包含三列user_id、订单总数、订单总金额。 要求 1. 只使用Python标准库尤其是csv模块不要引入pandas等第三方依赖 2. 遇到空文件或缺失字段时在命令行输出警告但不要中断整个任务 3. amount字段可能为空字符串按0处理 4. 输出文件按user_id排序 5. 请给出完整代码和运行方式。这段提示词看起来啰嗦但每一句都有目的。指定“不要pandas”是防止它选型自由度太大引入一个当前环境可能没有的依赖“字段顺序一致”这种说明是为了消除它对着未知数据结构的猜测要求“完整代码和运行方式”是为了少一次来回。2.2 拿到代码后的第一步不是复制而是追问ChatGPT会给出一个可运行的脚本但我的习惯是先不急着复制。我先把它生成的代码放进临时目录用一小份造假数据试跑确认基本流程能通。然后再回过头来追问边界问题。这是我自己很关键的一步把边界场景作为增量需求而不是让它一次性考虑完。一次说得太多模型容易顾此失彼。我通常这样追问脚本基础功能可以跑通。现在再帮我检查几个边界 1. 如果某个amount字段是纯空格当前逻辑会不会出错 2. 如果有两个文件里出现相同的user_id但大小写不一致比如USER_001和user_001要不要合并 3. 如果CSV文件带UTF-8 BOM用csv库读取时会不会把第一列列名读成\ufeffuser_id 请针对这些情况更新代码并在代码之外单独列一遍你做了哪些改动。这种追问的意图很明确让模型做增量修改同时把改动点显式暴露出来方便我做人工检查。它给出来的答案通常比第一次生成更可靠因为有了具体场景而不是泛泛的“考虑边界”。2.3 让ChatGPT给自己生成测试数据很多人在这一步就结束了但我建议再补一个动作让ChatGPT生成一份带脏数据的测试样本。请帮我写一个generate_sample_data.py生成5个CSV文件模拟上面的订单数据。要求包含以下脏数据 - 至少一个空文件 - 至少一个amount字段为空字符串 - 至少一个文件带UTF-8 BOM - 至少两行user_id大小写不一致 - 最后一个文件里包含一个格式错误的列。这个脚本跑一遍生成的测试数据直接喂给报表脚本。如果它能处理完这堆乱七八糟的输入那么这个脚本才算真正有了可交付的底气。让模型生成数据、再让同样的模型生成处理代码本质上是用它的知识盲区互相暴露问题处理代码可能漏边界测试数据就专门造边界。2.4 这个案例沉淀出的流程模板做完这个需求后我把流程整理成了一个固定套路写提示词角色、背景、数据格式、约束、输出要求一次说清。先生成初稿不要追求一步到位拿到能跑的基础版本更重要。边界追问把边界场景拆成几轮一轮一个主题地喂给模型。生成测试数据用脏数据主动制造“出问题”的机会。独立执行验证在干净环境里跑脚本确认输入输出都符合预期。补注释和文档让模型为最终代码补一段使用说明方便交接。这套模板我后来几乎套用到了所有一次性脚本任务上。它不神奇但非常稳。3. 让ChatGPT真正理解项目上下文注入与提示词写法3.1 上下文注入的四个层次ChatGPT不读你的项目仓库它只知道你贴给它的内容。所以“上下文注入”的质量直接决定产出质量。我一般按需贴四类信息而不是一股脑把所有代码都丢进去技术栈和运行环境比如“Python 3.10后端服务”“前端React TypeScript”“脚本运行在Windows的Git Bash里”。这能让它避开你环境里不存在的语法和依赖。相关函数或类的签名如果你要新增功能最好把现有接口签名贴出来明确“不要改变对外签名”。输入输出样例给它一组具体数据告诉它输入长什么样期望输出长什么样。模型对具体例子的理解能力远强于抽象描述。存量代码片段不是贴整个文件而是贴与当前任务直接相关的函数段落让它模仿现有风格。举一个我常遇到的例子。如果我只说“帮我重构这个函数”它不知道函数几百行、有没有被别处调用。但如果我这样说项目背景这是一个Python后端服务目前所有业务入口都会先经过validate_order这个函数。 任务以下函数太长了请把参数校验部分抽成独立函数并在原函数中调用。 现有代码 def validate_order(order, config): # 50行参数校验 # 30行业务规则 # 20行异常处理 约束 - 不要改变validate_order的对外签名 - 不要引入新的第三方库 - 保持原有注释风格。 请给出抽离后的完整代码并说明你的改动覆盖了哪些分支。这样它就知道这是存量项目、有外部调用约束、不能顺手换技术栈。上下文一给足回答质量马上不一样。3.2 一套可以复用的提示词模板用了很久之后我沉淀出一个通用模板基本能覆盖大多数“让ChatGPT写代码”的场景背景项目的简要说明包括技术栈、运行环境、当前模块的作用。 角色你希望它扮演的角色比如“有经验的Python后端工程师”。 任务要完成的具体事情越具体越好。 约束不要做什么、必须做什么例如“不要引入新依赖”“不要改变函数签名”。 输入要处理的数据样例或代码片段。 输出格式希望它输出的形式例如“完整代码运行方式”“代码逐行注释”。 请先复述一遍你对任务的理解确认无误后再开始。最后那句“请先复述一遍你对任务的理解”是我最推荐的技巧。很多答非所问都发生在任务描述有歧义的时候。让模型先复述相当于用一轮对话换一次对齐成本极低收益非常大。3.3 用“外置记忆”对抗上下文流失长对话聊久了模型会慢慢忘记最初的要求。最典型的表现是第一轮要求“只用标准库”聊到第五轮它突然给你一段pandas代码。这不是它变笨了而是上下文窗口里新旧信息互相挤压早期的约束被冲淡了。我的对策是“外置记忆”当对话很重要时我会在聊到一定深度后补一句请把我们刚才达成的结论用三条关键信息总结出来包括技术约束、最终方案、还没解决的边界问题。把这段总结复制进一个新的对话作为开头上下文。这样相当于给模型做了一次“记忆压缩”既不丢失关键决策又避免长对话里的漂移。这个方法在处理多轮重构任务时救了我很多次。4. 写代码只是其中一环我更常用的四个辅助场景4.1 排查报错先定位根因再谈修复日常开发里写新代码的时间其实远没有排错的时间多。ChatGPT在排错时最大的价值不是直接给修复代码而是帮你把根因从模糊的堆栈里捞出来。我会把报错堆栈、相关代码、期望行为一起贴进去下面这段代码在读取文件时会抛异常。请先根据堆栈定位最可能的根因再给出修复方案。不要只给结果请解释为什么会发生。 代码 import csv with open(data.csv, r) as f: reader csv.reader(f) for row in reader: print(row[1]) 报错 IndexError: list index out of range 期望行为 在遇到不完整行时跳过该行并打印警告。注意我要求“先定位根因再给修复方案”。这一步很关键因为ChatGPT有时候会跳过分析直接给代码而那些代码常常只是撞对了并不是理解了问题。让它先解释你可以从解释里判断它是真懂还是在编。4.2 生成单元测试让模型先列边界策略让ChatGPT直接生成测试用例最大的坑是它只会写“Happy Path”专挑正常输入测。解决的办法是让它先列测试策略再写测试代码。请为一个纯函数generate_summary(rows)设计单元测试策略。这个函数接收一个字典列表每个字典包含user_id、amount、created_at字段返回按user_id聚合并排序后的列表。 请先列出至少5个边界场景覆盖空列表、amount为空、user_id重复、日期格式异常、超大整数金额。然后基于pytest为这些场景生成测试代码。不要mock尚未接触过的外部依赖。这样出来的测试代码覆盖面明显更广。更重要的是它列出的边界策略可以直接当作你手工测试的检查清单即使最终代码不适合全盘复用这份清单也值回票价。4.3 代码Review让它当挑刺的人而不是鼓掌的人让ChatGPT review代码时我一般会指定“挑刺方向”否则它大概率会说“代码整体良好一些小建议如下”。请从以下角度review这段Python函数 1. 是否存在文件或网络资源没有关闭的问题 2. 是否存在异常被吞掉的情况 3. 是否存在明显的并发安全隐患即使当前是单线程运行 4. 是否有重复计算可以提取 5. 是否有魔法数字应该定义为常量。 对每个问题请给出所在行号、风险等级和修改建议。如果没有发现问题请明确说“该角度未发现问题”不要为了凑建议而编造。最后那句“没有发现就直说”很关键能明显减少那种为了显得认真而硬挑出来的问题。它给的review结果我会当作第二轮自查清单逐条确认后再决定改不改。4.4 提交信息、注释、接口文档全包了代码写完后的收尾工作我也基本交给ChatGPT处理。比如准备commit message时我会给它diff或一段变更描述根据以下变更内容生成一个符合Conventional Commits的提交信息。要求格式为type(scope): description正文控制在三行以内。变更修复CSV导入时BOM导致第一列列名带前缀的问题新增对空文件的警告。写注释时也一样我不让它做“逐行翻译”而是让它用两三句话概括函数的设计意图和边界注意点。这类工作的特点是结构固定、评价标准明确模型产出的质量非常稳定我只需要做少量删改。5. 实战避坑清单那些曾经骗过我的错误答案5.1 幻觉API和过时库看起来天衣无缝一跑就错ChatGPT有个很迷惑人的毛病它会把不存在的API说得跟真的一样或者使用一个旧版本已经废弃的写法。我有一次让它写一段ORM查询它给出来的方法是旧版本里的写法在现行版本中直接抛AttributeError。报错那一刻我才意识到它会一本正经地编造“记忆里的API”。对策有两层。第一层是在提示词里加一句硬约束“请只使用你知识范围内稳定且通用的API如果不确定某个库的具体写法请明确说‘我不确定’不要猜测。”第二层是养成查官方文档的习惯。重要代码里的关键API我一定会去官方文档确认一次。把ChatGPT当成“说人话的文档索引”可以但不要当成“权威文档本体”。5.2 上下文漂移聊得越久离最初的约束越远前面提到过长对话会丢失早期约束。这不仅仅是“忘了”那么简单它可能在某个环节为了满足你新提的需求悄悄换掉了之前的既定方案。我经历过一次前两轮都在用标准库写第三轮它突然引入了一个第三方库理由是“更方便处理大数据”而我的原始约束明明是不允许第三方依赖。现在我养成了两个习惯一是关键约束在每轮提示词里重复一遍比如“继续使用标准库不新增依赖”二是每完成一个重要阶段就做一次上下文总结然后开新对话重述。把模型当成一个记忆有限但能力尚可的协作者你自然会为它设计“外置记忆”。5.3 隐私和密钥泄露比代码错误更严重这是我最想强调的一条。有些人为了省事会把真实的数据库连接串、密钥、用户手机号直接贴在对话里。我见过最危险的一次是同事为了调试把一段包含生产环境连接信息的配置原文发了过去。ChatGPT不是本地工具你发上去的内容应默认视为不可控的。安全的做法是脱敏之后再问。你可以把真实数据替换成结构相同的假数据甚至把敏感逻辑抽象成只有字段名和类型的伪代码。如果在提示词里需要“一个包含用户手机号的样例行”那就写成这里用脱敏示例数据替代真实数据字段类型和格式保持一致 {user_id: U1001, phone: 13800000000, email: userexample.com}这种习惯既不影响模型理解结构又能避免把真实信息泄漏出去。5.4 “能跑”不等于“可以上生产”ChatGPT生成的代码放到样例数据上经常跑得很顺但这不代表它能应对真实环境的全部情况。它不会主动替你处理事务边界、并发冲突、重试策略、日志埋点、服务降级。有一次它给我生成的导入脚本在单测环境完美运行放到生产数据上一跑因为数据量大了几倍内存直接暴涨。从那以后我把“能跑”和“可以上线”严格分开。脚本类任务跑通数据就算完成服务端核心代码我会额外review资源释放、异常处理、并发、性能边界。模型负责把初稿铺出来但也仅此而已。5.5 提问越模糊答案越没用模糊提问是ChatGPT使用效率的最大杀手。做个对比就清楚了提问方式实际效果“帮我优化一下这段代码”得到一堆泛泛的建议甚至可能改了风格但没改性能“这个函数负责按user_id聚合金额当前数据量约10万行当前实现遍历两次。请改成一次遍历并说明复杂度变化。”得到具体可落地的代码、复杂度分析和验证建议“帮我写个脚本处理Excel”得到一段与你真实环境大概率不匹配的代码“生成一个脚本读取同目录下所有xlsx文件按B列合并数据输出到result.xlsx要求保留A列格式”得到能直接跑并接近交付的代码我把这个规律总结成一句话你愿意多花三十秒把问题说清楚就能省下后面三十分钟的返工。6. 沉淀下来的工作流我每天如何用ChatGPT写代码6.1 我的日常节奏现在我的用法已经比较固定了。接到任务后先自己把需求拆成几个可独立验证的小任务再逐个开新对话和ChatGPT协作。每个任务都走“上下文注入、生成初稿、边界追问、运行验证、人工review”这条线。这个节奏最大的好处是每个对话的目标都足够小上下文不会被污染模型的输出质量很稳定同时因为每个阶段都有验证动作哪一步出了问题我一清二楚不会出现“到最后一跑才发现方向错了”的情况。6.2 把提示词模板沉淀成团队资产用的时间久了我攒下一批适合自己的提示词模板按场景分类存放一次性脚本类、单元测试类、报错排查类、代码review类、文档生成类。每次用完后我会顺手把“这次踩到的坑”“模型在哪一步理解偏了”补在模板后面。这些东西不一定要神秘它就是一份“怎么给AI布置任务”的实操手册。我在团队内部也做过一点分享大家把各自用得顺手的提示词放进来很快形成了一个小小的提示词库。新人来了不用从零摸索提问姿势直接照着模板改改就能用。6.3 最后一个提升幅度最大的技巧保存验证过的对话而不是生成结果如果只让我留一条经验那就是比起保存ChatGPT生成代码的最终结果更应该保存那条验证过、调整过的提示词链路。我在本地笔记里会这样记录一个任务目标合并多个CSV按user_id聚合输出统计报表 关键约束只用标准库、空字段按0处理、BOM兼容 踩坑点模型在第三轮试图引入pandas已拒绝UTF-8 BOM首次未处理 提示词版本见下方链接 最终代码存档脚本路径下一次遇到类似任务我不用重新思考怎么提问直接打开旧记录复制提示词链路替换字段名和业务规则几分钟就能生成一版可靠度很高的结果。这比把每次生成的代码当作一次性答案丢掉要划算得多。我自己试过之后最大的感受是ChatGPT提升开发效率是真的但效率的天花板取决于你为它建立的流程和校验体系。那些把AI用成“高级搜索框”的人和我后来这种“把它当成可复用的协作流程”的用法产出差距会越来越大。