AI编程提问法：5个实战Prompt模板，从需求拆解到Bug排查效率翻倍

先说一个我自己的体会AI写代码这件事真正拉开差距的从来不是模型选哪个而是你会不会提问。同一个模型有人拿它一天写三个脚本有人拿它改三行代码改了半小时还没改对。过去两年我把日常开发里的重复劳动几乎都交给了AI从写脚本、查Bug、补测试到重构老代码慢慢磨出了一套自己的Prompt用法。今天不聊那些花哨的Agent框架就讲讲我平时真实在用的5个场景以及可以直接复制过去改改就用的Prompt模板。开始之前先声明下面所有Prompt都是我在实际项目中验证过、能稳定产出结果的写法。它们不一定是最优解但胜在“拿来就能用”。如果你有自己的更好模板也欢迎按这个思路继续迭代。1. 把“模糊需求”翻译成“AI能懂的精确指令”1.1 为什么你问AI写代码它总给你一堆用不上的东西很多人第一次用AI写代码的体验是这样的把需求打字发过去AI回了一大段代码复制运行报错。把报错发给它它改一版再运行报另一个错。来回三五轮之后心态就崩了最后得出结论“AI写代码不靠谱”。但真相往往不是AI不行而是你的第一句话就没说清楚。打个比方你跟一位新同事说“帮我把这个数据处理一下”他大概率也会一脸懵——处理成什么样用什么工具数据在哪边界情况怎么算AI也是这样它的“理解”完全基于你给的信息密度。信息越少它就越依赖训练数据里的“平均情况”来猜猜出来的东西自然离你的真实场景很远。所以我给AI写代码的第一原则是别把它当搜索引擎把它当一个基础不错但完全不了解你项目背景的新同事。需求描述必须包含四件事背景、目标、约束、输出格式。背景是“这个代码用在哪”目标是“我要它完成什么”约束是“环境是什么、不能用什么”输出格式是“你要给我什么形态的结果”。1.2 写Prompt前花两分钟做一次“需求拆解”我通常在写Prompt之前会在草稿纸上花两分钟快速拆一遍需求。这个习惯是从产品经理那里学的后来发现放在Prompt上一样适用拆解维度要回答的问题示例背景这段代码在什么环境里运行Windows 10Python 3.11目标代码的输入是什么输出是什么读取CSV清洗后输出JSON约束有哪些限制条件只能用标准库不能联网边界什么情况算异常空文件、重复数据、非法字符交付物要代码本身还是带注释和说明完整代码逐行注释这个过程看起来很笨但效果立竿见影。我做过一个粗略统计认真做需求拆解之后写的PromptAI第一次就给到可用代码的概率能从三成左右提升到七成以上。1.3 一个核心模板让AI“先复述再动手”我现在有一个雷打不动的习惯凡是稍微复杂一点的需求都会在Prompt里加上最后一行先复述一遍你对需求的理解确认无误后再开始写代码。你现在是我的Python开发助手。我会给你一个需求请你 1. 先用自己的话复述一遍需求重点说明你理解的输入、输出和边界条件 2. 等我确认无误后再输出完整代码 3. 代码需要包含注释并在最后列出你做的关键假设。这个“先复述再动手”的设计是我用过最有效的一招。AI一旦先说出自己的理解你在它动手之前就能发现偏差而不是等它写完上千行代码才发现方向错了。尤其是涉及业务逻辑的时候这个步骤能帮你省下大量来回修改的时间。很多人嫌这一步多余但我可以很肯定地说你宁可在这里花30秒也不要等它写完三十分钟代码再让你校验。2. 我平时写代码最常用的3个Prompt场景2.1 让AI写一个“一次性脚本”的最佳Prompt写法平时开发里最常见的需求其实是那种用完就扔的小脚本批量重命名文件、转换数据格式、抓取某个网页信息、统计日志里某个关键词的出现次数等等。这类需求的特点是范围清楚、逻辑简单但又懒得自己写。我常用的模板是这样的角色定位你是一位精通Shell和Python的自动化脚本工程师。 任务目标请用Python写一个脚本完成以下功能 1. 批量重命名当前目录下所有.jpg文件文件名前缀加日期如20250101_xxx.jpg 2. 遇到重名文件自动加序号如xxx_1.jpg 3. 支持命令行参数指定目录。 环境约束脚本运行在Windows 10已安装Python 3.11无第三方依赖只允许使用标准库。 输出要求给出完整脚本并逐行注释关键逻辑如果在Windows上运行请额外提醒路径分隔符和编码问题。这个模板比直接说“给我一个重命名脚本”强在哪里强在我把环境和约束说清楚了。AI在训练数据里见过大量Windows路径的坑你一旦明确环境是Windows它就会主动避开/和\混用、中文路径编码这类问题你一旦说“只能用标准库”它就不会擅自引入pandas这种重型依赖。实测下来这个模板写出来的脚本我基本复制就能跑通。2.2 让AI“改代码”时要把目标说清楚而不是命令它改哪一行改代码比写代码更容易翻车。我见过很多朋友这么问把第12行的foo改成bar结果AI改完后又引发了一连串其他问题。原因很简单你只告诉它“改什么”没告诉它“为什么改”AI不理解你的意图自然也不知道这个改动会影响哪些关联逻辑。正确的姿势是把“目标”描述给它现有脚本功能是批量重命名当前目录下的jpg文件。我想让它更通用 1. 同时支持.png和.pdf格式 2. 重命名规则不再是固定前缀而是支持从Excel表格里读取新文件名 3. 原文件不在当前目录子目录里也要能处理。 要求在现有代码结构上修改不要重写保持原有命令行参数的兼容性。这样AI就知道你不是在改一个点而是在扩展一组能力。它会主动考虑原有逻辑的复用、函数参数的调整、异常情况的处理。以我的经验描述目标比描述步骤能减少至少一半的无效返工。2.3 让AI“不要只给我代码先给我方案”遇到稍微复杂一点的需求比如涉及多线程、数据库、队列或者文件读写顺序我不太喜欢让AI直接甩代码而是要求它先给方案对比。我需要用Python实现一个功能从一个包含500万行记录的CSV文件里按条件筛选数据并统计分组结果。请先给出三种实现方案的对比包括算法思路、时间复杂度、内存占用、代码复杂度。然后推荐其中一种适合普通性能电脑的方案并说明理由。这一步的意义在于它逼着AI思考“为什么选这个方案”而不只是“怎么把这个功能写出来”。很多AI生成的代码跑起来没问题但性能差得离谱——比如用Pandas逐行遍历一个几十万行的DataFrame或者用同步方式请求成百上千个API。让AI先给方案实际上是在动手之前就把这些坑拦下来了。3. 排查Bug时我不用“帮我看看哪里错了”这种问法3.1 贴报错信息的高效姿势排查Bug是AI最擅长、也最容易被人用得稀烂的场景。最常见的错误问法是“我的代码报错了帮我看看怎么回事”然后贴一大段代码。AI面对这种信息密度极低的提问只能泛泛而谈。我现在的做法是把完整报错堆栈、代码文件、运行环境、操作步骤都一并给AI。我在运行下面的Python代码时遇到了报错。 代码功能从API拉取数据并写入SQLite数据库。 运行环境Python 3.11.2Windows 11代码文件路径为D:\projects\fetch_data.py。 完整报错堆栈如下 Traceback (most recent call last): File D:\projects\fetch_data.py, line 25, in module cursor.execute(...) sqlite3.OperationalError: no such table: users 请帮我分析可能的原因并给出修复后的完整代码。修复时请保持原有设计思路不要引入新的依赖。这个Prompt的关键信息密度非常高它告诉AI代码是干什么的、在什么环境跑、哪里报错、报什么错、修复边界是什么。AI能直接从报错堆栈里定位到第25行结合“写入SQLite”这个背景推测出可能是建表语句没有先执行或者是表名拼写不一致。相比之下你要是只贴一句“sqlite3.OperationalError: no such table: users”AI可能要猜半天你到底怎么建的表。3.2 让AI自己“多看几遍代码”而不是只看报错那一行很多报错只是“果”“因”往往藏在更早的逻辑里。比如报错提示“索引越界”但真正的毛病可能出现在数据预处理阶段把数组长度搞短了。如果只盯着报错那一行让AI改改了大概率还是会报错。这时候我一般会用这种Prompt我有一段代码功能是把用户上传的Excel数据做清洗后入库。目前运行时偶尔会抛异常完整堆栈如下粘贴。 请帮我从整个代码结构上分析从数据读入、清洗、转换到入库有哪些潜在问题会导致这个异常请不要只盯着报错行而是按数据流的顺序一步步展开列出每个环节的隐患点。这一下就把AI的思路从“局部修Bug”拉到了“全链路排查”。实测效果非常明显它能指出我在数据清洗那一步没有过滤空值导致后面入库时产生了唯一约束冲突。这种问题单看报错行永远发现不了。3.3 用“角色扮演”让AI扮演一个审查者另一种对我帮助极大的Bug排查方式是让AI扮演“代码审查者”而不是“代码修复者”。审查者和修复者的工作方式完全不一样修复者会顺着你的代码找问题审查者是拿着放大镜逐行找茬。你是一位资深的Python代码审查专家。请审查下面这段代码粘贴重点检查 1. 是否存在潜在的竞态条件或者线程安全问题 2. 是否有可能的内存泄漏或资源未释放 3. 异常处理是否覆盖了所有可能失败的路径 4. 是否有边界条件未考虑到。 请按严重程度从高到低排列你发现的问题每个问题描述触发场景和修复建议。这个方法特别适合那种“代码能跑但偶尔出问题”的场景。很多时候不是逻辑错而是异常处理不完整、资源没释放、边界没兜住。AI作为审查者会主动往这些方向想这也是它能发现你思维盲区的关键。3.4 排查Bug时的三大纪律用AI排查Bug这几年我总结出三条铁律第一永远贴完整堆栈不要只贴报错那行。完整堆栈能让AI知道调用链很多时候问题出在底层但报错信息却在顶层。第二永远告诉它代码“本来想干什么”。AI如果不知道代码的业务目标就很难判断是逻辑写错还是数据有问题。第三永远给它一个修复边界比如“不要引入新依赖”“不要大改结构”。没有这个约束AI经常会递给你一个完全重写的版本改得面目全非反而带来新Bug。4. 写测试用例和Mock数据AI是最佳苦力4.1 一个能自动生成pytest测试用例的Prompt让AI写测试用例是我现在最常做的事之一因为太省心了。以前自己写测试最痛苦的就是“用例覆盖不全”AI恰恰相反只要Prompt里引导到位它会覆盖到很多你想不到的边界条件。请为一个Python函数生成pytest测试用例。 函数功能计算购物车中商品的总价支持按会员等级打折。 函数签名calc_total(items, member_level) 其中items是列表每个元素包含price和quantitymember_level取值为normal、vip、vvip。 已有正常路径逻辑 - normal无折扣 - vip打95折 - vvip打88折。 请覆盖以下测试场景 1. items为空时返回0 2. quantity为0时该项不计费 3. 折扣后金额的浮点数精度处理 4. 极端情况大金额、多商品、负数price 5. 对非法member_level的处理。 输出要求每个测试用例一个函数命名清晰包含断言说明。AI生成测试用例的最大价值是它绝对不会不耐烦。你让它补十个用例它就补十个你让它再想五个边界情况它还照做。我经常用这种方式把一个函数的测试从“只有快乐路径”补到“异常、边界、极限情况全覆盖”这在以前自己写的时候至少得花两个小时。4.2 让AI“生成测试数据”比写测试用例还常用有时候代码本身没问题缺的是数据。特别是前端开发经常需要模拟各种状态的接口返回。让AI造Mock数据比手写JSON快太多了。请生成一份模拟用户订单列表的Mock数据格式为JSON数组包含20条记录。每个订单需要有以下字段order_id、user_id、order_amount、order_status、created_at。其中order_status按比例分布已支付60%、待支付20%、已取消15%、退款中5%。created_at分布在最近30天内字段格式为ISO 8601。order_amount取值在50到5000之间保留两位小数。这类需求你描述得越细AI生成的数据质量越高。它甚至会在数据里做出一些“看起来随机”的分布。拿到手直接存成JSON文件前端联调时直接导入就能用。4.3 让AI“补充测试用例”而不是“生成全套”如果项目里已经有一套测试你不想让它推翻重写那就别让它“生成测试用例”而是让它“补充”。这俩问法区别非常大。下面是我现有的一组pytest测试用例粘贴。请分析它们覆盖了哪些场景哪些场景还没有覆盖。然后只补充缺失的测试用例不要修改已有的测试代码。AI一旦知道边界是“只补充不修改”就会把注意力全部放在差异分析上不会擅自改动你的已有代码。这个问法我很常用因为它既保留了人的控制权又充分利用了AI的覆盖面。5. 让AI重构老代码我踩过的几个坑5.1 一上来就让“重构”它可能给你一套“全新代码”老代码重构是我最近用得比较多的场景。这里最大的坑在于你一说“重构”AI的理解往往是“用更现代的方式重写”而不是“在保持行为不变的前提下优化内部结构”。结果就是它给你一套语法更新、结构更优雅、但行为细节全部变了的代码——接口换了、异常行为换了甚至输出格式都换了。所以我现在重构类需求都会加这么一句保持对外行为完全不变只修改内部实现。请对下面这段代码做重构要求 1. 保持对外函数签名和返回值完全不变 2. 保持现有异常抛出行为不变 3. 内部实现可以优化包括减少重复代码、提高可读性、改进性能 4. 重构后请用注释标出每处修改的原因。加了这个边界AI就会老老实实地“内部优化”而不是“另起炉灶”。这一点非常关键否则你的代码评审会上会收获一堆意外惊喜。5.2 让AI解释老代码是重构前必做的一步重构一个你自己没写过的老模块时我强烈建议先让AI把代码逻辑翻译成人类语言而不是直接让它改。请用通俗的语言解释下面这段代码的功能和实现思路。我需要向同事转述这段逻辑因此请按以下结构输出 1. 整体功能概述 2. 核心流程分步说明 3. 关键变量的意义 4. 潜在缺陷或可改进点提示。这一步看起来慢实际快。AI解释完你心里对这段代码有了一个完整的模型重构时该保留什么、该砍什么、该注意什么一目了然。省掉这一步重构就是在裸奔。5.3 重构完“对比新旧代码逻辑”是最稳的保险每次AI重构完代码我都会让它再做一步输出一份“新旧逻辑对比说明”。你刚刚完成了对这段代码的重构。请输出一份对比说明逐条列出 1. 旧代码中的核心逻辑点分别被迁移到了新代码的哪些位置 2. 哪些逻辑被合并或拆分 3. 哪些地方的行为有潜在差异即使你本意是保持一致。这一步能逼着AI自己反思重构过程中有没有“手滑”改变行为。我经历过几次AI在对比说明里承认某个边界条件的处理方式变了而这恰恰是我不希望发生的。如果没有这一步这些改变大概率会在测试阶段才暴露出来那时排查的成本就高多了。6. 我踩过的坑和现在固定的排查流程6.1 AI给出的代码无法运行先看执行报错信息这是最常见的场景。很多人拿到AI的代码跑一下报错立刻回贴“不行啊报错了”。其实这样低效。正确姿势是把完整的报错堆栈贴给AI我运行你给的代码报了以下错误 粘贴完整堆栈 运行环境Python 3.11.2Windows 10代码文件名为test.py。 请根据报错堆栈给出修复建议并说明根因。AI对“报错堆栈”的理解能力非常强它可以从堆栈中推断出变量类型不匹配、函数参数缺失、路径拼接错误等。你不用自己分析直接贴堆栈就是最高效的沟通方式。6.2 AI答非所问很可能是上下文污染有一次我问AI“如何优化这段Python代码的性能”它的回答却扯到了“重构代码结构”。后来发现是因为之前的对话里已经讨论过重构上下文脏了。解决办法很简单开新对话只保留当前问题相关的历史记录或者在提问时明确“忽略我们之前讨论过的所有重构方案”。我现在的习惯是一个会话只干一件事。要写脚本就开新会话要查Bug就再开一个绝不在同一个会话里既改需求又问问题。上下文一长AI就会把前面的讨论当作背景回答问题时容易跑偏。6.3 中文乱码问题别急着怀疑AIAI生成的脚本一打印中文就乱码这在Windows上经常遇到。别急着怀疑AI先确认三点文件编码是否为UTF-8控制台是否设置为UTF-8系统区域设置是否支持UTF-8。排查时可以用这个命令python -X utf8 test.py加了-X utf8参数Python就会强制使用UTF-8乱码问题基本能定位。如果加了这个参数后乱码消失说明是控制台或终端编码问题如果还在说明是文件编码问题你就要检查源文件的开头是否有# -*- coding: utf-8 -*-或在写文件时指定encodingutf-8。6.4 前端Bug打断点从数据边界入手如果你用AI生成前端代码更常见的是在浏览器里断点调试。我的习惯是打开浏览器DevTools切到Sources面板找到AI生成的那个JS文件点击行号设置断点刷新页面触发问题路径在Console里输入变量名观察中间值。前端打断点这个方向很多教程都只讲了“怎么打开DevTools”却没说“在AI生成的代码上具体怎么找可疑行”。我的判断方法先在fetch或axios调用之后设置断点看返回数据是否正常如果数据正常就往函数计算逻辑里面继续断点逐步缩小范围。AI生成的代码一般比较大而全从数据边界入手比从渲染层入手更高效。6.5 常见问题速查表我把日常遇到频率最高的问题整理如下方便大家直接对照现象可能原因排查/修复手段代码能跑但结果不对Prompt目标描述不清先明确“目标”而非“步骤”代码直接报错堆栈未贴全贴完整堆栈并附环境信息中文乱码编码不一致用python -X utf8快速定位AI扯到无关内容上下文污染开新对话或明确“忽略之前方案”前端页面无反应断点未设置到数据边界从fetch/axios返回处开始打断点脚本修改后出现新问题只告诉AI改哪行没说为什么改用“目标驱动”方式描述改动需求这张表是我长期实践下来的一个快速自查清单。每次报错先对照一下再行动能省很多冤枉时间。最后说到底AI写代码和排查Bug这件事真正值钱的不是AI本身而是你组织信息、描述问题、划定边界的能力。我见过太多人抱怨AI不靠谱但细聊之后发现他们连需求都没讲清楚。如果你只记住三件事我的建议是第一写Prompt前先问自己“AI知不知道我的环境、目标和边界”第二遇到Bug先贴完整堆栈、说明代码意图再让AI分析第三别在一个会话里混着聊多个任务保持上下文干净。做到这三点你手里的AI会用得比现在好一个台阶。我自己至今还在不断调整Prompt写法因为AI模型在变任务类型也在变。但只要沟通的逻辑不变——信息充分、边界明确、意图清晰——这套方法是永远适用的。