在实际 AI 应用开发中直接调用大语言模型LLM并期望它理解你的意图往往得到的是通用、模糊甚至偏离预期的回答。真正决定模型输出质量的不是模型本身有多强大而是你如何向它描述任务。这个描述过程就是提示工程Prompt Engineering它已经成为 LLM 应用落地的核心技能。本文面向已经接触过 ChatGPT 或其他 LLM、但希望系统掌握提示词设计技巧的开发者。我们将从提示工程的基本概念出发通过具体案例拆解提示词的结构化设计方法涵盖清晰指令、角色设定、上下文控制、复杂任务分解等关键技巧并给出可复用的提示词模板和迭代优化路径。学完后你将能针对代码生成、技术问答、内容创作等常见场景设计出高质量、可预期的提示词显著提升 LLM 的使用效率。1. 理解提示工程为什么你的提问方式决定了模型的表现1.1 什么是提示词和提示工程提示词Prompt是你输入给大语言模型的文本指令它可以是问题、描述、对话开头或包含示例的模板。模型根据提示词生成后续内容。例如当你输入“用 Python 写一个快速排序函数”这就是一个基础提示词。提示工程Prompt Engineering是系统化设计、优化和评估提示词的过程目的是让模型更准确、可靠地完成特定任务。它不仅仅是“问得清楚点”而是包含任务分解、上下文管理、输出格式控制、错误预防等一系列工程化方法。注意同一个模型使用不同的提示词输出质量可能天差地别。提示工程的目标是减少模型猜测增加确定性。1.2 提示工程解决的核心问题在没有经过设计的提示词下LLM 容易产生以下问题答非所问模型理解偏差回答与预期不符。内容过于笼统缺乏细节和针对性像是百科全书摘要。忽略关键约束比如字数限制、格式要求、排除条件。陷入循环或发散在某些话题上不断重复或偏离主题。无法处理复杂逻辑多步骤任务被简化为单步响应。通过提示工程你可以明确告诉模型它应该扮演什么角色例如“你是一名资深 Java 架构师”。任务的具体目标和边界。需要遵循的思考过程或步骤。输出的格式和长度限制。应该避免哪些内容或倾向。1.3 提示词的基本结构一个有效的提示词通常包含多个部分而不是单一问题。典型结构如下角色设定定义模型的角色或领域专家身份。任务描述清晰说明需要完成的具体任务。上下文信息提供背景资料、输入数据或相关约束。输出指示明确输出格式、长度、风格等要求。示例可选给出输入输出对演示期望的形式。例如一个结构化提示词可能这样写你是一名经验丰富的技术文档工程师。任务是将下面这段 Python 代码的功能用 Markdown 格式写成技术文档。文档需要包含代码说明、输入输出示例和使用注意事项。代码是[此处粘贴代码]。请确保文档不超过 500 字用中文编写避免使用过于技术化的术语。这种结构化提示比直接问“解释这段代码”要有效得多。2. 设计高质量提示词的核心原则与技巧2.1 清晰与具体减少模糊空间模糊的提示词会给模型留下太多解释空间。清晰具体的提示词应包含可操作、可验证的指令。模糊提示“帮我写个函数计算平均值。”清晰提示用 Python 编写一个函数计算任意长度数字列表的算术平均值。函数名为 calculate_mean输入为一个数字列表返回一个浮点数。如果输入列表为空应返回 0 并打印警告信息“输入列表为空”。请包含函数定义和一行调用示例。清晰提示词的特点明确了编程语言和函数名。定义了输入输出类型。处理了边界情况空列表。要求了示例代码。2.2 使用角色扮演约束模型行为为模型设定特定角色可以显著改变其回答风格和深度。角色设定相当于激活了模型内部与该角色相关的知识模式和语言风格。普通提问“解释一下微服务架构。”角色扮演提问你是一家大型互联网公司的首席技术官正在向一群初级开发者介绍微服务架构。请用易懂的语言解释微服务的基本概念、主要优势、常见挑战以及适合采用微服务的场景。回答要体现技术领导者的视角避免过于学术化的表述。常见技术角色示例资深后端开发工程师系统架构师DevOps 专家技术面试官代码审查员技术文档撰写者2.3 提供上下文和约束条件模型不知道你的具体环境、约束或偏好除非你明确告诉它。缺乏上下文的提示“优化这个 SQL 查询。”包含上下文的提示现有以下 MySQL 查询表 orders 有百万级数据字段包括 id, customer_id, amount, order_date。查询目的是获取2023年每个客户的总金额按金额降序排列。当前查询是[原始查询]。请分析性能瓶颈并提供优化方案考虑索引设计和查询重写。关键上下文元素环境信息数据库类型、数据量大小、系统约束。业务目标查询的目的和业务场景。技术约束性能要求、兼容性限制、安全考虑。2.4 指定输出格式和结构明确要求输出格式确保结果可以直接使用或集成到你的工作流中。未指定格式“列出 Spring Boot 的常用注解。”指定格式以 Markdown 表格形式列出 Spring Boot 最常用的10个注解。表格包含三列注解名称、用途说明、使用示例。示例要简短明了展示基本用法。最后用一句话总结这些注解的共同特点。常用格式要求Markdown 表格、列表、代码块JSON 或 XML 结构分步骤的编号列表特定长度的段落如“每点不超过100字”包含特定章节的文档结构2.5 使用示例进行少样本学习给模型提供输入输出示例演示你期望的回答风格和内容深度。这种方法特别适用于格式固定或风格特定的任务。零样本提示“将以下技术术语翻译成中文API, DevOps, Kubernetes”少样本提示请将以下技术术语翻译成符合中文技术文档习惯的译法。参考示例 - 输入: Containerization → 输出: 容器化 - 输入: Load Balancer → 输出: 负载均衡器 现在请翻译 - API - DevOps - Kubernetes - Microservices - Continuous Integration少样本学习的优势确保术语一致性控制翻译风格处理一词多义的情况建立质量基准3. 复杂任务的提示词设计思维链与任务分解3.1 思维链提示让模型展示推理过程对于需要逻辑推理或多步思考的问题要求模型“展示思考过程”可以显著提高答案的准确性和可靠性。直接提问“这段代码为什么性能差”思维链提示请分析以下 Python 代码的性能问题并按照以下步骤给出回答 1. 首先识别代码中的性能瓶颈点 2. 解释每个瓶颈为什么影响性能 3. 给出具体的优化建议 4. 展示优化后的代码片段 代码[粘贴代码]思维链的典型结构理解问题重述问题确保理解正确分解分析将复杂问题拆解为子问题逐步推理展示每一步的逻辑和依据综合结论基于分析给出最终答案3.2 复杂任务的多步骤分解当面对复杂需求时将任务分解为明确的步骤指导模型按顺序处理。单一复杂提示“帮我设计一个用户管理系统。”多步骤分解提示请按以下步骤设计一个基本的用户管理系统 步骤1设计用户数据模型 - 列出必要的用户字段如id、用户名、邮箱等 - 说明每个字段的数据类型和约束 步骤2设计核心API接口 - 列出用户注册、登录、查询、更新、删除等接口 - 说明每个接口的HTTP方法、URL、参数和返回结果 步骤3描述关键业务逻辑 - 注册时的密码加密处理 - 登录时的身份验证流程 - 权限检查的基本逻辑 请确保每个步骤的输出清晰分开使用标题标识。任务分解的好处降低单次提示的复杂度确保覆盖所有关键方面便于分步验证和调整减少模型遗漏重要环节的风险3.3 使用模板化提示词提高效率对于重复性任务创建可复用的提示词模板只需替换变量内容即可快速生成高质量提示。代码审查模板示例角色你是一名严格的代码审查专家 任务对以下代码进行全面审查 代码语言[编程语言] 审查重点[如性能、安全、可读性等] 代码内容[代码片段]审查要求 1. 找出潜在bug和安全漏洞 2. 检查代码风格和规范符合性 3. 提出具体的改进建议 4. 按严重程度对问题分类严重、一般、建议 5. 对每个问题说明原因和修改方案 输出格式Markdown包含问题列表和改进后的代码示例。此类模板可以保存为代码片段或笔记在需要时快速调用和调整。4. 高级提示工程技术与实战模式4.1 自洽性检查与验证要求要求模型对生成的内容进行自我验证提高输出的可靠性。基础提示“编写一个Python函数验证电子邮件格式。”带验证的提示编写一个Python函数验证电子邮件格式。完成后请 1. 用3个有效邮箱和3个无效邮箱测试这个函数 2. 解释验证逻辑的关键部分 3. 指出这个函数可能漏掉的边缘情况 4. 提出改进建议以覆盖更多验证场景验证机制的类型测试用例生成要求模型创建测试用例验证自身输出逻辑一致性检查询问输出中是否存在矛盾或漏洞边缘情况分析要求识别当前方案未覆盖的特殊情况替代方案对比让模型比较不同实现方法的优劣4.2 多角度分析与对比提示对于有争议或复杂的技术选型问题要求模型从多个角度进行分析。单一角度提问“应该选择MySQL还是PostgreSQL”多角度分析提示从以下五个角度对比MySQL和PostgreSQL的优劣为新建Web项目做技术选型 1. 性能特点读写性能、并发处理、复杂查询能力 2. 功能特性数据类型支持、高级功能如JSON查询、全文搜索 3. 生态系统工具支持、社区活跃度、学习资源 4. 运维成本部署难度、监控工具、备份恢复机制 5. 长期发展版本更新频率、厂商支持路线图 请对每个角度给出具体比较最后基于中型Web项目的需求给出推荐意见。多角度分析的价值避免片面结论暴露不同方案的权衡取舍帮助建立全面的评估框架适合技术决策文档的编写4.3 迭代优化与提示词改进提示工程是一个迭代过程。基于模型的响应不断优化提示词。迭代优化流程初始提示编写第一版提示词获取初始响应问题识别分析响应中不符合预期的部分提示调整根据问题修改提示词增加约束、改变表述、提供示例再次测试用相同模型测试优化后的提示词循环优化重复2-4步直到满意示例迭代过程第一版提示解释什么是RESTful API。问题回答太理论化缺乏实际例子。第二版提示用实际例子解释RESTful API设计原则。包含GET、POST、PUT、DELETE的典型用例。问题例子过于简单没有展示真实项目中的复杂性。第三版提示以一个用户管理系统为例详细说明如何设计RESTful API。包括资源命名规范、HTTP方法使用、状态码选择、错误处理机制。给出具体的API端点示例和请求响应格式。4.4 上下文管理与长对话技巧在多轮对话中有效管理上下文是维持对话质量的关键。上下文丢失的对话用户如何配置Spring Security的基本认证 AI回答配置步骤... 用户那如何添加角色权限控制 AI回答角色权限概念...可能忘记之前讨论的Spring Security上下文上下文维护技巧关键信息重述在后续提问中提及之前的上下文基于刚才讨论的Spring Security基本配置现在如何添加基于角色的权限控制对话历史摘要在长对话中定期总结关键点我们已经讨论了Spring Security的基本配置和角色权限。现在请说明如何集成数据库进行用户认证。明确引用直接引用之前的对话内容在第一步配置中你提到了HttpSecurity的配置方法。现在如何在此基础上添加JWT支持5. 常见技术场景的提示词模板库5.1 代码生成与优化提示词代码生成模板作为[语言]专家编写一个[功能描述]的[函数/类/模块]。要求 - 输入[输入参数说明] - 输出[输出结果说明] - 约束[性能要求、库限制等] - 代码风格[编码规范要求] - 包含[测试用例/使用示例] 请确保代码有适当注释处理边界情况。代码优化模板分析以下[语言]代码的性能瓶颈和优化空间[代码内容]请 1. 识别主要性能问题时间复杂度、内存使用等 2. 提出具体的优化策略 3. 给出优化后的代码 4. 说明优化前后的性能对比预期5.2 技术方案设计提示词系统设计模板你是一名系统架构师需要设计一个[系统类型]系统。主要需求 - 功能需求[核心功能列表] - 非功能需求[用户量、性能要求等] - 技术约束[必须使用的技术栈等] 请提供 1. 系统架构图描述组件及其关系 2. 核心模块设计思路 3. 数据存储方案 4. 关键技术选型理由 5. 潜在风险及应对措施API设计模板设计一套完整的[业务领域] RESTful API包含 - 资源模型设计 - API端点规划URL、方法、参数 - 请求/响应数据格式 - 错误处理机制 - 身份认证方案 以Markdown表格形式列出API清单并为每个端点提供示例。5.3 技术文档编写提示词文档生成模板作为技术文档工程师为以下[技术组件/代码]编写使用文档[技术内容]文档应包含 1. 概述和用途说明 2. 快速开始指南 3. 详细功能说明 4. 配置参数说明 5. 常见问题排查 6. API参考如适用 使用清晰的中文面向[初学者/中级开发者/专家]读者。代码注释模板为以下代码添加详细的技术注释[代码内容]要求 - 文件头部注释说明模块功能、作者、版本 - 函数注释说明用途、参数、返回值、异常 - 复杂逻辑注释解释算法思路和关键步骤 - 使用标准的[语言]文档注释格式5.4 问题排查与调试提示词错误分析模板遇到以下错误信息[错误日志/堆栈跟踪]请分析 1. 错误类型和可能原因 2. 相关的代码上下文特征 3. 排查步骤建议 4. 可能的解决方案 5. 预防类似错误的建议 如果是常见错误提供参考文档链接。性能诊断模板系统出现性能问题[问题现象描述] 请提供诊断思路 1. 需要收集哪些指标数据 2. 使用什么工具进行监控和分析 3. 常见的性能瓶颈点检查清单 4. 优化建议的优先级排序6. 提示词迭代优化与效果评估6.1 建立提示词评估标准评估提示词效果需要明确的 criteria而不仅仅是“看起来不错”。技术性提示词的评估维度评估维度具体标准检查方法准确性技术内容正确无事实错误验证关键断言检查代码可运行性完整性覆盖任务所有要求无遗漏对照需求清单逐项检查相关性内容紧扣主题无发散检查是否包含无关信息实用性输出可直接使用或稍作调整尝试在实际场景中应用清晰度表达清晰易于理解让他人阅读确认无歧义6.2 提示词优化检查清单在迭代优化提示词时使用以下清单系统化改进[ ]角色设定是否明确了模型的专家身份[ ]任务边界是否清晰定义了任务范围和限制[ ]上下文信息是否提供了足够的背景资料[ ]输出格式是否指定了具体的格式要求[ ]示例质量如有示例是否足够典型和清晰[ ]约束条件是否包含了所有必要的约束[ ]避免歧义表述是否无歧义减少误解空间[ ]复杂度控制是否将复杂任务分解为步骤[ ]验证机制是否要求模型自我验证输出6.3 常见提示词问题与修复方案问题1模型回答过于笼统症状回答像是教科书摘要缺乏具体细节和针对性。修复增加具体场景约束要求结合实例说明。不佳解释数据库索引的作用。 改进以电商订单查询为例具体说明如何设计索引优化查询性能包括索引类型选择依据。问题2模型忽略格式要求症状虽然要求了特定格式但模型仍用段落式回答。修复强化格式指令放在提示词显眼位置。不佳用表格对比A和B。 改进必须使用Markdown表格格式包含三列比较维度、方案A、方案B。第一行是表头。问题3模型过度发挥或偏离主题症状回答包含大量无关信息或不断扩展话题。修复明确边界使用否定约束。不佳介绍Spring框架。 改进只介绍Spring Core的核心功能不要扩展至Spring Boot或其他模块。每点说明不超过2句话。问题4模型无法处理复杂逻辑症状多步骤任务被简化为单步响应或逻辑混乱。修复明确分解任务步骤要求逐步展示。不佳设计一个完整的登录系统。 改进按以下步骤设计1.用户表结构 2.密码加密方案 3.登录API设计 4.会话管理 5.安全防护措施。6.4 提示词版本管理与测试流程在实际项目中建议建立提示词的版本管理和测试流程提示词仓库使用Git或文档管理系统存储不同版本的提示词测试用例集为常用提示词建立标准测试输入和期望输出效果记录记录每个提示词在不同模型上的表现差异团队评审重要提示词经过团队评审和优化定期更新根据模型更新和业务变化调整提示词示例提示词版本记录# 代码审查提示词 v1.2 - 创建日期: 2024-03-15 - 更新内容: 增加安全审查重点明确输出格式 - 测试结果: GPT-4准确率85%Claude-3准确率82% - 适用模型: GPT-4, Claude-3, DeepSeek - 注意事项: 对复杂代码可能需要分解审查7. 生产环境中的提示工程最佳实践7.1 安全与合规考虑在生产环境中使用LLM时提示词设计需要包含安全防护敏感信息过滤在回答中绝对不要包含 - 任何形式的个人身份信息 - 内部系统架构细节 - 商业秘密或未公开代码 - 法律免责声明要求的内容 如果问题涉及上述内容请礼貌拒绝并说明原因。内容安全约束请确保所有技术建议 - 符合主流安全实践 - 不包含已知的安全漏洞模式 - 遵循最小权限原则 - 有适当的数据保护措施7.2 性能与成本优化提示词设计直接影响API调用成本和响应速度精简提示词删除不必要的修饰词和重复信息批量处理将相关任务合并到单个提示词中减少调用次数缓存策略对标准问答建立响应缓存避免重复计算分层提示先获取简略答案再根据需要请求详细信息7.3 监控与质量保障建立提示词使用监控机制响应质量监控定期抽样检查关键提示词的输出质量异常模式检测识别输出中的不一致性或质量下降用户反馈收集建立机制收集最终用户对回答质量的评价版本对比测试新提示词上线前与旧版本进行对比测试7.4 团队协作与知识共享提示工程应该是团队协作而非个人技能建立提示词库共享经过验证的有效提示词模板制定编写规范统一团队内的提示词结构和风格定期分享会交流提示词设计经验和最佳实践新人培训材料将提示工程纳入团队技术培训体系提示工程正在从艺术走向工程学科。随着工具链的完善未来可能会出现提示词编译器、调试器和版本管理系统。当前打下的坚实基础将在LLM应用开发的各个阶段持续产生价值。从今天开始系统化实践提示词设计比等待完美提示更重要。