企业官网建设流程全解析

说实话，我做了十几年开发，最近半年最强烈的感受是：写代码这件事本身在贬值，“说清楚要什么”在升值。这句话不是我一个人的体会，团队里几个效率明显拉开差距的同事，差距不在编码速度，而在他们向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. 返回结构统一为 Result<T>，格式为 { code, message, data } 3. 分页参数 pageNo/pageSize，pageSize上限为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; 表结构： orders：id, user_id, amount, status, created_at, 索引 idx_status(status), idx_created_at(created_at) users：id, 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的输出并追问“为什么”

拿到代码后我没有直接信任，而是进行了一轮“追问式审查”。我故意挑了几个点问它“为什么这样做”：

1. 为什么用乐观锁，而不是直接UPDATE加条件判断？
2. 为什么每批次只捞500条，这个值是怎么定的？
3. 为什么把扫描时间窗口设为created_at < NOW() - INTERVAL 30 MINUTE，而不是查出来再判断？

AI的回答解释了第一个问题是因为“既要保证状态能正确变更，又要避免并发下重复关闭”，第二个是因为“单批次处理时间控制在100ms内比较安全，500条×每条一次简单UPDATE实测在常规MySQL上是安全的”，第三个是为了“把超时判断下沉到数据库，减少数据传输量”。

这些追问让代码背后的设计决策全部浮出水面。我发现AI做设计是有“自知力”的，只要你去问，它能把理由说得清清楚楚。这也给了我们程序员一个机会：AI负责出方案，你负责审方案。这会逼你真正理解每一行代码为什么存在。

4.4 第四轮：让AI补测试与边界处理

确认主流程没问题后，我把上一段代码交给AI，让它补测试，重点覆盖边界场景。这次我发现AI主动补了两个我没想到的场景：

1. 订单状态被手动改成“退款中”后，定时任务扫描到这条数据，会不会误关闭退款中的订单？
2. 如果一次执行过程中，数据库连接突然断开，已经关闭了一半订单，剩余部分怎么办？

针对第一个，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仓库里，像维护代码一样维护它们——每一次用后发现效果不佳就修改、提交、记录版本。因为提示词的迭代和其他代码一样，是最值得持续打磨的个人资产。工具不会取代程序员，但我越来越确定一件事：那些会用工具的程序员，正在用同样的时间，完成两倍甚至三倍的工作量。而这一切的起点，就只是把“帮我写个功能”改成“我有一个需求，背景是……约束是……对象是……输出格式是……”。