说实话我做了十几年开发最近半年最强烈的感受是写代码这件事本身在贬值“说清楚要什么”在升值。这句话不是我一个人的体会团队里几个效率明显拉开差距的同事差距不在编码速度而在他们向AI提问的质量。上周帮一位刚转正的小伙子review代码发现他用AI生成的代码比我手写的还稳定。我问他怎么做到的他说其实就是“把需求说细了一点”。这个“说细一点”的背后就是提示词工程的那套方法论。这篇笔记是我几个月来在真实项目中用AI辅助开发的记录和沉淀重点面向程序员群体整理了一份可以直接抄作业的提示词模板库顺便聊聊我踩过的坑。如果你是日常写业务代码、写SQL、做运维、准备面试的程序员这篇文章值得你花十分钟从头到尾读一遍。它不是讲理论而是讲怎么把提示词工程落到每天的开发工作里。1. 先想清楚一个问题AI写代码时代程序员的核心能力变成了什么1.1 大部分人的AI用法还停留在“搬运工模式”过去一年我发现很多程序员用AI的方式是打开对话框输入“帮我写个登录接口”然后把生成结果复制粘贴跑不通就再贴一次报错再不行就多试几次实在不行就放弃自己写。这种用法本质上是把AI当成一个更智能的搜索引擎或者说是代码生成的“运气盒子”。运气好生成的东西能用运气不好来回改的时间已经足够自己写完了。用这种方式工作效率提升有限是正常的。原因在于你扔给AI的需求太模糊了。“帮我写个登录接口”——登录方式是什么JWT还是Session用哪个框架数据库表结构长什么样异常处理怎么设计这些信息AI全不知道它只能根据训练数据里的统计概率给你一个“最常见”的登录接口。如果你恰好在一个冷门技术栈里或者项目有独特的架构约束生成结果必然和你的期望差一大截。1.2 提示词工程的本质把隐性经验显性化我理解的提示词工程本质上不是“会聊天”而是“把需求表达清楚”的能力。和人协作时你把需求说清楚对方能听懂七成剩下的靠项目上下文自己补但和AI协作时它没有你的项目上下文它唯一的信息来源就是你的提示词。所以提示词工程就是在做一件事把你脑子里那些“不用说出来对方也懂”的东西全部显性化出来。举一个真实的例子。我让AI“写一个从CSV文件里读取数据然后入库的Python脚本”结果生成出来的代码用了pandas库是装过的但公司内网的机器限制多数仓环境里根本没有pandas。第二次我加了几个约束“纯Python标准库实现”“文件编码可能是GBK也可能是UTF-8需要自动检测”“每处理1000条打印一次进度”“遇到脏数据要记录到独立日志而不是直接跳过”。这次生成的结果直接就能上生产。差别在哪里我把那些“我以为它知道但实际上它不知道”的信息补上了。1.3 程序员学提示词工程有天然优势这一点我越来越确信程序员是学提示词工程最顺利的一群人。因为提示词工程底层的思维方式——结构化、拆解、约束条件、输入输出设计、边界情况——和写代码的思维高度重合。比如写提示词时要“明确角色、明确输出格式、明确约束条件再给示例”这个套路和写函数声明完全一样函数名角色、参数输入信息、返回值输出格式、异常抛出边界情况。我自己学提示词工程时几乎没有适应成本就是把写技术方案文档的经验搬了过来。所以程序员不要觉得提示词工程是一门从零开始的新学问你已有的编程素养已经有七八成可以迁移。2. 程序员高频场景提示词模板库我实测过可以直接抄的版本下面的模板都是我在真实开发中反复使用、调整过的版本。你不用一字不差地照搬但建议先照抄用几周用出感觉了再根据自己的项目定制。2.1 业务代码生成从“帮我写接口”到“规格说明式提问”这是最高频的场景。我以前也踩过“太抽象导致AI输出不可用”的坑现在固定成一套格式效果稳定很多。你是资深Java后端工程师擅长Spring Boot 3.x和MyBatis-Plus熟悉阿里巴巴Java开发规范。 需求实现一个用户列表分页查询接口支持按用户名模糊搜索、按创建时间范围筛选。 约束条件 1. 使用Java 17、Spring Boot 3.x、MyBatis-Plus不引入额外依赖 2. 返回结构统一为 ResultT格式为 { code, message, data } 3. 分页参数 pageNo/pageSizepageSize上限为100超过自动截断 4. 姓名搜索条件可为空为空时不拼该条件 5. 创建时间范围为左闭右开 [startTime, endTime) 输出要求 1. 先写一个5步以内的实现思路 2. 再给出Controller、Service、Mapper三层的完整代码 3. 最后用表格列出这个接口的异常场景和对应返回码这个模板的关键在“规格说明式”提问场景、角色、需求、约束、输出结构都拆开了。尤其是约束条件里的第5条“左闭右开”这类细节你不写AI大概率会写出between语法直接包含右边或者用导致边界重复。你写清楚结果就是一次成型。2.2 代码审查让AI当那个不说客套话的reviewer代码审查场景我试过十几种不同的提法最有用的版本是明确要求“不要客套、按严重程度排序、给出修改建议”。下面这段代码是我负责模块的核心逻辑。请以一名资深代码审查者的身份逐行审查。 审查重点空指针风险、并发安全、资源释放、边界条件、可读性、性能隐患。 要求 1. 不要客套不要用“整体不错”之类的开头 2. 按【严重】【一般】【建议】三级列出问题 3. 每个问题需要包含问题位置行号或函数名、原因分析、修复建议 4. 如果某项没有问题直接跳过不要为了凑数而提 代码 [粘贴代码]这个提示词的效果比我预期的好很多。有一次审查一段多线程缓存更新的代码AI指出了我忽略的一个问题ConcurrentHashMap的get和put之间没有加锁会导致缓存击穿。这个点我确实漏了而我自己团队里的同事也不一定每次都看出来因为人看代码时很容易顺着原作者的思路走AI的“盲区”反而小。2.3 Debug排错把报错信息变成破案线索Debug场景我反复强调一点让AI先分析原因不要直接给修复代码。原因很简单如果你只想要最终答案那出了新问题还得回来问如果你让AI解释原因你会慢慢提升定位问题的能力而且AI给的修复方案也会更对症。我在生产环境遇到一个报错但不确定根因是什么。请帮我分析可能原因并给出排查步骤。 场景订单服务偶尔在处理支付回调时抛出 java.io.IOException: Connection reset by peer不是每次都出现。高峰期频率高一些。 报错堆栈 [粘贴堆栈] 相关代码片段 [粘贴代码] 我目前已经尝试过 1. 调大数据库连接池问题仍在 2. 在方法入口加了重试部分缓解 请按可能性从高到低列出至少5种可能原因。每种原因请写明 1. 为什么会导致这个报错机制原理 2. 如何验证需要看什么日志或指标 3. 对应的修复方案这类“按可能性排序”的提问方式是我用下来最有价值的提示词技巧。因为AI的知识背景太宽了你要是问“这个报错怎么解决”它会把所有可能的答案都列出来信息量太大反而无从下手。加上“按可能性从高到低”之后它会结合你提供的场景去判断输出就变成了一个可执行的排查计划。2.4 重构与优化先定目标再谈动手重构是我过去不敢轻易让AI碰的场景怕它“好心办坏事”把行为改坏了。后来发现只要把重构目标和行为等价性检查明确写进提示词AI其实能做得比人更细尤其是大规模的重命名、提取方法这种机械操作。下面这段代码可以正常工作但可读性差、重复代码多。请帮我重构。 重构目标提高可读性消除重复保持行为完全不变。 约束 1. 不许改变对外接口的签名和返回值语义 2. 不许改变异常类型 3. 不许改变日志输出内容 请先说明重构思路说明你打算分几步做 然后给出重构后的完整代码 最后用表格列出5个行为等价性检查点分别说明重构前后在这些检查点上的表现不变。 代码 [粘贴代码]我实际用下来让AI列出“行为等价性检查点”这一步意义很大。即使你会做代码review也不一定想得全面。比如它可能会列出“当入参为null时重构前抛出NullPointerException重构后也抛出NullPointerException”——这种检查点看似废话但它逼着AI自己在输出前做一次回归检查。实测下来AI遗漏边界问题的概率明显降低。2.5 单元测试把“补测试”变成“先测后写”写测试是AI生成代码里最划算的场景之一因为测试逻辑相对固定而且AI不会像人那样犯“偷懒不写断言”的毛病。请为以下函数编写单元测试测试框架使用pytest。 函数代码 [粘贴代码] 覆盖要求 1. 正常输入场景 2. 边界值如空字符串、最大长度、最小数值 3. 异常输入场景如None、类型不符 4. 如果是纯函数至少要覆盖5个用例 每个用例需要包含 - 测试意图一句话说明测什么 - 输入数据 - 断言点 - 用例等价类划分的依据 请用表格汇总这份测试的覆盖率和遗漏风险点。要求AI“说明意图”和“等价类划分依据”是我摸索出来的关键。它不只是在帮你多写几个test case还在帮你想测试策略。很多时候AI能发现你忽略的边界条件比如一个日期转换函数AI会主动测试“闰年2月29日”和“跨时区的UTC时刻”这种边界你让同事写可能都想不到这么细。2.6 SQL优化与正则表达式两类最常见的“非编程”场景程序员日常不只写代码还有大量时间花在SQL优化和正则表达式上。这些场景表达能力要求更高——你要让AI理解表结构和执行计划它才能给出对的方案。这条SQL在数据量约500万时执行时间超过2秒请帮我分析并优化。 SQL SELECT o.order_id, o.amount, u.nickname FROM orders o LEFT JOIN users u ON o.user_id u.id WHERE o.status 0 AND o.created_at 2025-01-01 ORDER BY o.created_at DESC LIMIT 20 OFFSET 0; 表结构 ordersid, user_id, amount, status, created_at, 索引 idx_status(status), idx_created_at(created_at) usersid, nickname 请先解读这条SQL的执行计划可能长什么样基于现有索引推断 再给出优化后的SQL或索引建议 最后说明为什么改成这样能提升性能。正则表达式的场景我用得更多而且我发现你不需要懂正则语法也能写出来请帮我写一个正则表达式需求如下 1. 从nginx日志中提取IP、访问时间、请求路径 2. 日志格式127.0.0.1 - - [10/Oct/2025:13:55:36 0800] GET /api/users HTTP/1.1 200 512 3. 要求用命名捕获组Python环境 请同时给出Python代码示例并解释每部分正则的含义。这类非典型编程场景的提示词要点是把数据格式描述清楚。格式越明确AI的正确率越高。2.7 面试复习让AI当考官而不是背八股文这个场景是写这篇笔记前临时加的因为最近团队在招人我发现自己复习面试题时的效率很低——看八股文书看不进去自己出题又太熟悉了。于是试了让AI当考官效果出乎意料的好。我正在准备Java后端岗位的面试请扮演一名严格的面试官。 复习主题JVM内存模型。 规则 1. 先问我3个基础问题 2. 根据我的回答逐步追问2轮每次追问都要更深一层 3. 每轮问答结束后点评我的回答指出漏洞补充关键知识点 4. 语言风格像技术面试官那样直接不要安抚情绪 现在请开始第一轮提问。我自己试了一小时发现AI的追问逻辑比我预想的好。它问完“JVM内存结构有哪些”我回答完线程私有的部分后它下一轮就问“为什么需要虚拟机栈和本地方法栈分开”“栈帧里的大对象会不会直接进老年代”。这些问题正好卡在我记忆模糊的区域复习针对性强很多。这比盲目背一本PDF八股文高效多了。3. 三个让AI稳定输出高质量代码的核心技巧模板是形技巧是神。光有模板AI输出质量还是会被“当天状态”影响掌握下面三个技巧后你能把AI输出的稳定性拉到90%以上。3.1 角色设定要具体到“能验证的程度”很多人写提示词会用“你是一位资深全栈工程师”效果有但不稳定。我测试下来角色设定越具体越能调用模型里真正“资深”的知识分布。同样是让AI写一段Python爬虫代码两种角色设定的区别弱角色你是一个Python工程师帮我写一个爬虫。 强角色你是一个有多年爬虫工程实战经验的Python工程师熟悉requests、parse、scrapy框架重视反爬策略和异常处理请帮我写一个可以稳定运行在单机上的爬虫。“可以稳定运行在单机上”这个后缀会让AI主动考虑超时重试、断点续爬、限速等实际问题。原因大概是角色设定中的关键词会激活模型里对应的经验区域。你可以把角色看作是一个“先验概率分布”你给的关键词越精准分布越贴合你的需求。3.2 规则前置约束要写在需求前面大语言模型有一个特点上下文越靠前的内容对输出的影响权重越大。同一个需求放在第1段和放在第9段效果可能差很多。我推荐的提示词结构是角色 全局约束 → 具体需求 → 输入数据 → 输出格式 → 示例举例说明。我让AI写一段读取Excel并生成报表的脚本时把“不要使用第三方库只用标准库”放在开头第一句它后续生成代码就会老老实实用csv模块处理。有一天我把这句放在最后AI生成的代码引入了openpyxl依赖。同一份需求两种写法都通了但结果是我想要的差别。所以我的建议是把最重要的约束放在提示词开头位置哪怕是重复一遍也值得。我的模板里“约束条件”永远是紧跟需求之前的固定块。3.3 示例驱动三五个例子胜过一百句描述这一点是提示词工程里最容易被忽略的技巧。有时候你用文字描述半天“什么叫风格保持一致”不如直接给AI两个输入输出的例子。以生成提交信息commit message为例。让AI“写一个符合规范的中文commit message”AI会给你一堆花样百出的结果。但如果你在提示词里先给两个例子需求为下面的代码变更写一条规范的git commit message。 输出示例 feat(用户模块): 新增用户列表分页接口支持按用户名和创建时间筛选 fix(订单): 修复异步回调导致Connection reset by peer问题时多次重复支付的问题 变更内容 [粘贴diff摘要]给不给这两个例子输出质量天差地别。因为例子不仅定义了你想要的格式还定了你想要的语气和粒度。我在所有关键提示词里都会内置一个few-shot示例这是稳定输出的最强利器。4. 完整实战演练用AI实现一个“订单超时自动关闭”功能光看模板不过瘾我把最近一次完整的实战过程记录下来。这次我用的是“四轮迭代法”不带任何剪辑还原真实的AI协作过程。4.1 第一轮模糊需求下AI的表现惨但不意外原始需求写一个订单超时自动关闭的功能。我第一轮就把这句话扔给AI结果生成的代码是一个Spring的Scheduled定时任务每分钟扫一次订单表关闭超时订单。功能没错但完全不能用在生产环境——每次扫全表数据量过万就会出现性能问题没有考虑取消订单、退款中订单的处理连幂等性都没处理。这个结果说明模糊需求下AI会默认选一条“最简单通用”的路径也就是全表扫描。放在小项目里可能够用但对真实业务来说完全不可接受。换一个说法AI可以帮你写“一个东西”但能不能写“你的东西”取决于你描述得多细。4.2 第二轮加入角色、规则、约束之后第二轮我把项目背景和技术栈都补上提示词改成你是资深Java后端工程师负责一个电商平台的订单系统。请设计并实现“订单超时自动关闭”功能。 业务规则 1. 订单创建后超过30分钟未支付自动将状态改为“已关闭(CLOSED)” 2. 已取消、已支付、退款中的订单不做处理 3. 关闭操作需要记录操作日志 4. 关闭操作需要幂等重复执行不能报错 技术约束 1. Spring Boot 3.x MyBatis-Plus MySQL 2. 订单量约10万/天不能全表扫描 3. 不能引入额外的中间件如MQ/Redis——当前项目没有这些组件 4. 需要输出完整可运行的代码 输出要求 1. 先说明你的设计方案用什么方式避免全表扫描 2. 再给出完整代码 3. 最后列出你觉得这个设计在极端情况下可能失效的场景这轮生成的方案和第一轮完全不同。AI选择的是“分批扫描基于ID游标翻页”的方式每次都只捞一小撮满足条件的订单用主键游标避免深分页扫描完一批就离开不会把数据库拖垮。它还主动加了“状态更新IP加乐观锁”这种我没有直接提但确实需要的细节。这轮给我的启发是你给的约束越接近真实生产环境AI触发“资深经验”的概率就越高。如果是第一轮的写法它永远就是个“学生作业水平”的答案。4.3 第三轮审查AI的输出并追问“为什么”拿到代码后我没有直接信任而是进行了一轮“追问式审查”。我故意挑了几个点问它“为什么这样做”为什么用乐观锁而不是直接UPDATE加条件判断为什么每批次只捞500条这个值是怎么定的为什么把扫描时间窗口设为created_at NOW() - INTERVAL 30 MINUTE而不是查出来再判断AI的回答解释了第一个问题是因为“既要保证状态能正确变更又要避免并发下重复关闭”第二个是因为“单批次处理时间控制在100ms内比较安全500条×每条一次简单UPDATE实测在常规MySQL上是安全的”第三个是为了“把超时判断下沉到数据库减少数据传输量”。这些追问让代码背后的设计决策全部浮出水面。我发现AI做设计是有“自知力”的只要你去问它能把理由说得清清楚楚。这也给了我们程序员一个机会AI负责出方案你负责审方案。这会逼你真正理解每一行代码为什么存在。4.4 第四轮让AI补测试与边界处理确认主流程没问题后我把上一段代码交给AI让它补测试重点覆盖边界场景。这次我发现AI主动补了两个我没想到的场景订单状态被手动改成“退款中”后定时任务扫描到这条数据会不会误关闭退款中的订单如果一次执行过程中数据库连接突然断开已经关闭了一半订单剩余部分怎么办针对第一个AI在测试用例里专门加了“退款中订单不处理”的断言针对第二个AI给出的建议是在任务入口加一个分布式锁占位保证同一时间只有一个实例在跑。这个我本来打算后面再上AI提前提醒了我。4.5 这次实战给我的几个直观感受用AI做开发的效率和以往相比确实不一样了但我体会最深的是质量上限取决于提问的迭代次数。第1轮模糊提问出的代码大概20分第2轮补全上下文到了60分第3轮追问设计理由等于做了一次代码评审到了80分第4轮补测试和边界到了90分以上。这个过程中我全程没有手写一行核心逻辑但每一步我都知道AI在做什么、为什么这么做。这恰恰是我觉得提示词工程最核心的价值它把程序员的角色从一个执行者变成了一个架构师和审查者。剩下的10分在哪里就在你自己对业务的理解里AI取代不了。5. 资深程序员使用AI的翻车现场与避坑清单之前的内容讲的是“怎么用好”最后这一节聊聊“怎么不翻车”。下面这些坑我全部亲身踩过而且每一个都耽误过至少半天。5.1 幻觉问题AI一本正经地编造API有一次我让AI写一个文件分片上传的服务端代码它生成后看起来完美。但编译时发现它引用了一个第三方库的不存在的类。后来我查证了一下这个类在旧版本里叫别的名在新版本里被拆到了另一个包里。AI把记忆里的信息融合错了而且这种“融合错误”看起来很真实普通review发现不了。我的对策是两招第一在提示词里加上“请确保你使用的API在版本中真实存在不要使用训练数据中出现过但不确定是否存在的类不确定的地方请明确说明”第二对于生成的代码要求AI“列出所有用到的库和关键API的官方文档链接并说明使用时需要什么版本”。这能让AI在输出前自己检查API的可用性。5.2 上下文漂移聊着聊着它把我最初的需求忘了这个问题在长对话里尤其严重。我用AI写一个完整模块的时候通常会连续问十几个问题到后面AI开始的约束条件就慢慢“失忆”了。比如最初设定的“不使用第三方库”在第十次对话里它突然给你引了一个什么工具包进来。排查半天发现源头在对话中间某次它“自由发挥”了一下后面所有回答都以这个错误前提在继续。我的对策是一式三份一份是每次提问都重新粘贴“需求不变项”段另一份是当对话超过5轮时主动开一个新会话把关键上下文重新整理压缩到一段里第三份是让AI在每次回复前用自己的话复述一遍它理解的需求确认没有跑偏后再往下写。实测第三份最有价值因为“复述需求”会逼它强制回忆上下文并给你一个纠错的机会。5.3 安全红线生产代码不能随手贴给AI这一点要单独强调因为我见过太多同事没意识到问题的严重性。你把自己的生产环境代码、数据库表结构、甚至包含客户信息的日志直接粘贴给公网AI服务等于把内部信息外传了。这在很多公司是违反信息安全规定的而且风险不可控。我的做法是能脱敏的一定脱敏表名、字段名、日志里的IP/手机号全部替换成aaa/bbb这种占位符能把数据库连接串和密钥删掉的先删掉敏感业务逻辑和代码逻辑分开只把纯逻辑部分丢给AI。如果项目安全要求高我建议团队自己部署一套私有的模型服务彻底规避外传问题。5.4 编译通过不等于逻辑正确这是最后一个坑也最隐蔽。AI生成的代码多数情况下是能编译的但“能编译”和“逻辑正确”完全是两回事。有次AI写的日期处理工具直接用new Date()做了参数默认值每次调用都取当前时间。测试用例只传参的话根本测不出来只有线上跑到那个默认值场景才会出错。我现在对AI生成代码的验收标准是“四层验收”第一层编译通过第二层单测通过第三层关键业务场景手工验收第四层用AI自己生成的代码审查清单再过一遍。第四层就是前面2.2那个提示词模板相当于让AI自己审自己。它确实能抓住不少边界条件遗漏虽然不能100%保证但比直接裸奔上线要稳太多了。写到这里这篇提示词工程学习笔记该收尾了。最后分享一个我自己的小习惯我把高频使用的提示词模板存在一个Git仓库里像维护代码一样维护它们——每一次用后发现效果不佳就修改、提交、记录版本。因为提示词的迭代和其他代码一样是最值得持续打磨的个人资产。工具不会取代程序员但我越来越确定一件事那些会用工具的程序员正在用同样的时间完成两倍甚至三倍的工作量。而这一切的起点就只是把“帮我写个功能”改成“我有一个需求背景是……约束是……对象是……输出格式是……”。