做AI大模型应用开发这一年多，我被问得最多的不是“选哪个模型”，而是“提示词到底怎么写才靠谱”。同一批用户评论，有人写一条提示词就能分类得整整齐齐，有人折腾半天结果还是乱七八糟。这不是模型的锅，差在提示词工程上。提示词工程不是让你背几句好听的套话，而是把模糊的业务需求翻译成模型能稳定执行的指令，再用一套可复制、可迭代的流程去逼近最佳方案。这篇文章我会用OpenAI API跑一条完整实战链路：从最小调用开始，拆解角色设定、示例驱动、结构化输出、思维链这几个核心方法，最后把我在项目里踩过的坑和优化技巧一起整理出来。适合刚接触大模型开发、或者已经在调API但总被输出格式和稳定性折磨的朋友。
1. 提示词工程到底在解决什么问题
1.1 模型不是人，指令需要翻译
很多人第一次接触提示词时会想：“我正常说话它不就能听懂吗？”但实际用下来你会发现，大模型更像一个“阅读理解能力很强的实习生，但完全不知道你现在想要什么”。
如果我直接说“帮我总结一下”，模型大概率会回一段写得很漂亮但不可控的文字。可我想要的是“第一句给结论、后面跟要点、不要有前缀、控制在150字以内”，这些约束如果不在提示词里写出来，模型只能靠猜。它不是在跟你对着干，而是你真的没说清楚。
这就像跟一个不熟悉行业黑话的同事交代工作，你脑子里有完整画面，对方接收到的只是你嘴里说的那几句话。提示词工程要做的，就是把我们脑子里的“完整画面”翻译成模型能一步步照做的“指令”。注意，是命令式的指令，不是聊天式的商量。越接近“命令”，越接近“可执行”，模型的输出稳定性就越高。
还有一个容易忽略的点：模型对同一个问题的理解路径不唯一。同样一句“帮我分析”，它可能从情感角度分析，也可能从商业角度分析。你如果不点名角度，它就自己选一个。所以提示词的第一层价值，就是帮模型把“理解路径”收敛到你想要的那一条上。
1.2 为什么叫“工程”而不是“话术”
这里有一个很关键的认知转变：提示词不是一个一次性写出来的文案，而是一个需要持续迭代和维护的系统。
我在项目里会把提示词当成代码一样管理。每条提示词都有版本号，改一个词都会记录效果。因为模型本身的生成过程带有概率性，同样的提示词在不同参数下可能产出不同结果。如果你不记录“当时用了什么参数、什么示例、得到什么输出”，那你永远说不清“这次为什么变好了”或者“这次为什么变差了”。
“工程”背后是三个能力：可复现、可评估、可迭代。可复现意味着固定模型版本、参数、提示词后，在相同输入下能拿到稳定输出；可评估意味着你给每个任务定义清楚“什么叫做好了”，是分类准确率、格式合规率、还是用户满意度；可迭代意味着每次只改一个变量，对比结果后再决定是否保留。
如果你只是靠感觉写提示词，那叫“话术”。如果你用实验记录、版本对比、灰度验证来调整，那才叫“提示词工程”。这也是为什么一些团队提示词看起来差不多，但上线效果差异很大——他们差在迭代机制上，而不只是词句上。
2. OpenAI API实战：从一次最小调用开始
2.1 环境准备与第一次调用
不管方法论多漂亮，最后都要落在一个能跑起来的调用上。我先讲最小环境，如果你已经熟悉API调用，可以直接跳到2.2的参数部分。
准备三样东西：Python环境、一个可用的API Key、安装好官方SDK。安装很简单：
pip install openai然后准备一个最简单的文本分类任务。先说一个错误示范：很多人把要求全写在一条user消息里，比如“请你帮我看一下这个句子是好评还是差评，我要做数据统计，谢谢”。这种提示词不是不能用，而是输出极不稳定，模型经常会多解释几句，或者换一套说法。
更好的做法是把系统指令和用户内容分开。系统消息定义行为，用户消息只放真正要处理的内容：
from openai import OpenAI client = OpenAI(api_key="sk-你的密钥") resp = client.chat.completions.create( model="gpt-4o-mini", messages=[ { "role": "system", "content": "你是一个文本分类助手。只输出一个词：正面 或 负面，不要输出任何解释。" }, { "role": "user", "content": "今天天气真好，适合出门走走。" } ], temperature=0 ) print(resp.choices[0].message.content)API Key不要直接硬编码在代码里，我习惯放在环境变量：
export OPENAI_API_KEY="sk-你的密钥"代码里这样读：
import os client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))这条链路跑通后，你已经能做一次“受控输出”了。但受控制的程度取决于你对关键参数的理解，以及你把提示词的结构搭建到了什么水平。下一步就是把这几个变量吃透。
2.2 关键参数对结果的影响这次讲全
很多初学者只调temperature，其实后面几个参数在真实项目里同样关键。我整理了一张实测参数表：
| 参数 | 取值范围 | 作用 | 我的使用建议 |
|---|---|---|---|
| temperature | 0-2 | 控制随机性，越低越确定 | 分类、抽取、格式转换用0-0.2；创意写作、头脑风暴用0.7-1.0 |
| top_p | 0-1 | 核采样，只从累积概率达到p的词中选择 | 和temperature二选一调整，一般固定不动 |
| max_tokens | 正整数 | 限制生成的最大token数 | 务必设置，防止费用失控和模型跑飞 |
| presence_penalty | -2到2 | 鼓励讨论新话题、新概念 | 对话续写、长文生成时可调0.3-0.6 |
| frequency_penalty | -2到2 | 对重复出现的token降权，减少复读 | 生成长报告、广告语时可调0.3-0.8 |
注意，temperature不等于“聪明度”。它只是采样时的随机性权重。调成0，模型该不会做的题还是不会做，只是每次给出的结果更接近同一个模式。反过来，temperature调得很高，模型不是“更有创意”，而是“更可能胡说八道”。
还有两个项目里常见的坑。第一，不是所有模型都支持全部参数，新的推理模型系列和普通对话模型的行为差异很大，有的不接受temperature调整，有的对输出格式有额外要求。升级模型版本后，最好先用同一批测试样本跑一遍，确认行为有没有变化。第二，max_tokens只限制输出长度，不限制输入长度。输入太长仍然会报错或触发上下文窗口限制，这个问题后面会展开讲。
2.3 先用参数还是先改提示词
这里有一个我在团队里反复强调的排错顺序：先提示词，后参数。
有朋友遇到输出不稳定，第一反应是把temperature降到0，结果发现偶尔还是乱。实际上temperature=0并不等于百分百确定性，模型内部仍有采样过程，只是概率分布更尖锐。真正解决不稳定问题的，往往是把指令写得更明确、把输出格式约束得更死。
我建议的调试顺序是：先用temperature=0跑一个基准版本。如果结果格式不稳定，就去改提示词和示例，而不是先调参数。只有当你确认提示词已经把该说的都说了，但仍然希望输出更多样或更集中时，才去动temperature、top_p这类参数。
参数和提示词的关系可以理解成“方向盘和油门”。提示词负责定义方向，参数负责控制车速。方向偏了，踩油门只会跑得更远。先改方向，再调车速，这个顺序能省掉大量无效调试时间。
3. 核心提示词方法论拆解：从入门到优化
3.1 角色设定：让模型进入正确的“频道”
最简单却最容易被忽略的一招是角色设定。它不是让模型“扮演一个角色”那么肤浅，而是给模型一个稳定的立场、判断基准和工作范式。
我的系统提示词通常包含三层信息：你是谁、你要遵守的规则、你的输出风格。举个例子，在做客户评价分析时，我会这样写：
system_prompt = """ 你是一位资深的数据分析师，擅长把原始用户评价整理成可执行的业务建议。 【工作规则】 1. 先给结论，再列数据依据； 2. 不得编造数据源中不存在的信息； 3. 如有不确定项，明确写“信息不足”。 【输出风格】 使用中文，正文不超过200字，使用项目符号列出要点。 """这样写的好处是，模型在生成时有了一个基础框架，而不是从一片模糊的概率分布里随机挑词。角色设定还能帮模型调用“相关的领域知识”。你说“你是一位资深数据分析师”，模型在生成时就更倾向使用数据分析领域的术语和思考方式，输出更像一份专业报告，而不是闲聊。
这里有一个坑：角色设定不要过度。有些人写“你是世界顶级、无所不能、拥有数十年经验的……”这种堆形容词的角色，效果不一定更好，反而可能让模型过于自信，开始编造细节。角色设定应服务于任务约束，而不是服务于“看起来厉害”。真正的判断标准只有一个：加了这句角色描述之后，输出准确率和稳定性有没有提升。
3.2 示例驱动：用few-shot定义“标准答案的长相”
角色设定是给模型“价值观”，示例是给模型“标准答案的样子”。模型对模式特别敏感，你给它什么样的示例，它就更倾向于产出同样类型的答案。
我用few-shot最典型的场景是分类和抽取。比如要分三类时，我会在user消息里先放几个示例，再放真实任务：
messages = [ {"role": "system", "content": "你是一个评论分类器。"}, {"role": "user", "content": """ 示例1：物流很快，包装完好，非常满意。 分类：正面 示例2：客服一直不回复，已经三天了，差评。 分类：负面 示例3：东西质量还行，就是包装有点旧。 分类：中性 现在分类下面这句话，只输出分类结果： 一次不错的购物体验，质量超出预期。 """} ]示例为什么比抽象描述更管用？因为抽象描述需要你把它翻译成规则，模型再执行；而示例直接给出了“输入到输出”的映射关系，模型只需要做模式匹配，这是大模型最擅长的事情。
实操上有三个细节。第一，示例数量通常2-5个就够。太少约束不住，太多会增加token成本。第二，示例要覆盖容易混淆的边界情况。分类任务最怕的往往是“看似正面其实中性”这种边界，这类典型示例放进去，比放十个明显例子更有效。第三，正例反例可以搭配使用。“不要输出什么”和“要输出什么”同样重要，反例能显著降低模型跑偏的概率。
3.3 结构化输出：把JSON格式彻底钉死
做应用开发的人最关心的一件事：模型返回能不能直接转成代码能用的数据。自由文本看着舒服，但落到系统里就是灾难。所以在任何需要程序消费的场景下，建议直接要求模型输出JSON。
这是我在多次踩坑后沉淀出来的写法：
prompt = """ 请从下面的会议记录中提取结构化信息，输出JSON对象。 必须遵守： 1. 字段名严格按要求； 2. 不要输出```json代码块标记； 3. 不要添加任何说明文字。 { "会议主题": "string", "参会人": ["string"], "决议事项": ["string"], "待办": [ {"事项": "string", "负责人": "string", "截止日期": "string"} ] } 会议记录： 今天下午讨论了新版App的登录改造，参会人有小李、小王、小张。最终决定采用短信验证码方案，接口改造由小王负责，下周五前完成；新UI由小李负责，同时推进。下周再开一次进度同步会。 """很多教程没告诉你，即使你写得这么细，模型偶尔还是会手滑：加一个代码块、把字段名换成驼峰、把空数组写成null。所以成品的代码里一定要有兜底解析逻辑：
import json text = resp.choices[0].message.content text = text.strip() if text.startswith("```"): text = text.strip("`").removeprefix("json").strip() data = json.loads(text)如果使用较新的模型能力，还可以直接开启接口层的结构化输出模式，用schema约束保证格式。但我个人建议，不要在提示词阶段就把可靠性全押在模型自觉上，代码侧做兜底永远是最后一道防线。双向保障，才是生产环境该有的态度。
3.4 思维链：让复杂任务自己拆成步骤
对于推理、计算、逻辑判断类任务，直接问模型，它经常“快速”给出一个错误答案，因为它跳过了中间推导过程。思维链的核心思想是：要求模型在给出最终结果前，先把推理步骤写出来。
一个直观的例子：
prompt = """ 请判断下面的逻辑是否成立，一步步推理，最后给出结论“成立”或“不成立”： 前提：所有程序员都会写代码。小明不会写代码。 结论：小明不是程序员。 """模型在“一步步推理”的压力下，会把过程写出来：所有程序员都会写代码，如果某人是程序员，那么他一定会写代码；小明不会写代码，所以小明不满足“程序员”的必要条件，因此“小明不是程序员”这个结论是成立的。
你可能会发现，让模型把步骤写出来之后，不只是答案更稳，你还获得了“查错依据”。它哪一步错了，你能直接指出来，并把这个正确的推理逻辑加进提示词里，下一次就能纠正。
思维链也有注意点。第一，它不是万能药。简单的分类和抽取任务不需要用，加了反而增加token和延迟。第二，如果你只想要最终答案、不希望看到推理过程，可以在system里加一句“先在内部自行推理，再输出最终结论”，这样效果接近，但输出更干净。第三，对特别复杂的任务，不要指望一个提示词搞定。子任务拆分比长思维链更可靠，这个在4.3里展开说。
3.5 一个通用的四维优化方法论
把前面这些技巧串起来，我会用四个维度来审视任何一条提示词：任务指令、上下文背景、示例支撑、输出格式约束。
先看任务指令：这条提示词是否清楚定义了“要做什么、判断标准是什么、不能做什么”。再看上下文背景：历史对话、输入数据、行业背景这些信息是否足够，模型有没有足够的上下文来做出正确判断。再看示例支撑：确定性要求越高，越需要示例兜底，尤其是边界情况。最后看输出格式约束：是否明确指定了格式、字段、长度、语气。
我自己检查提示词时会按这个顺序过一遍。哪一环缺失就补哪一环。效果不好时先定位到具体维度再改，而不是整段推翻重写。
举一个真实工作流：先用一个基础版本跑20条测试样本，记录成功率；然后只修改一个维度，比如增加两个边界示例，再跑20条；如果准确率提升了，就保留这次修改，接着优化下一个维度。看起来有点笨，但这是提示词工程稳定进步的底层方法。
再补充一个提示词结构模板，方便你直接套用：
[角色定义] 你是一个什么样的角色，具备什么能力。 [任务描述] 你本次要完成的任务是什么，判断标准是什么。 [上下文] 提供必要的历史信息、输入数据、业务背景。 [示例] 输入与输出的对应关系，至少覆盖边界情况。 [输出格式] 字段、格式、长度、风格、必须禁止的事项。 [进阶约束] 如果遇到某种情况，应该如何处理。4. 常见问题与排查技巧实录
4.1 输出格式飘忽不定怎么根治
常见现象：要求输出JSON，但它偶尔给你包一段```json代码块；要求三选一，它非要解释两句；要求用冒号，它用破折号。
我的排查顺序是固定的：先确认提示词里有没有“只输出、不要解释、不要代码块”这类否定约束；再看示例里是否提供了完整的目标格式；再看有没有开启接口层的结构化输出能力；最后才是写代码解析时做兜底。
否定约束要有一个度。写“不要做”太多，模型容易把注意力放在“不要”上，反而更容易犯错。比较好的写法是“肯定句为主，否定句为辅”：明确告诉它“输出以下JSON字段”，再加一句“不要在JSON之外写任何文字”。
还有一个容易被忽略的因素：上一轮历史输出会影响下一轮的格式。在连续对话场景里，如果之前你让模型生成了散文，下一轮突然要JSON，它很可能延续散文风格。所以聊天场景里要切换任务类型时，最好新开会话，或者精简历史消息，只保留必要信息。
4.2 角色设定失效：上下文被“压塌”了
用过长对话的朋友应该都有体会：聊到二十轮以上，模型好像忘了自己是谁，系统开头的指令越来越不顶用。原因很简单，上下文有窗口限制，而注意力会被更靠近当前的位置占满。早期的system指令，在长对话里会逐渐被淹没。
我常用的解法有三个。
第一个解法：在用户消息里重复关键约束，每轮都带上。虽然浪费一点token，但效果最可靠。第二个解法：对话达到一定长度后截断历史，用一段摘要代替旧内容，塞回system里。第三个解法：把不可丢失的核心约束从system尾部挪到靠近用户输入的位置，因为更靠近当前内容的指令，权重通常更高。
这个问题的本质是“指令与最终输出之间的距离”。距离越远，约束力越弱。理解了这一点，你在设计长对话prompt时，就会主动把最核心的约束放在距离输出最近的位置。
4.3 输出太长或太短，怎么拿捏
模型经常把答案写得又长又啰嗦。另一方面，max_tokens设得太小，输出会被硬截断，造成JSON解析失败或者内容缺尾。
长度问题要分两类处理。
第一类是单次输出太长。可以先跑一次测试，估算目标内容大概占多少token，再按峰值设置max_tokens，留出20%的余量。同时，提示词里明确写“正文不超过200字”，这类字面约束对大多数模型是有效的，虽然不算精确，但比没有强。
第二类是任务本身数据量太大。比如你要总结200条评论，核心矛盾不是单次输出多长，而是怎么拆分子任务。我通常把数据分批，每批20条，让模型按固定格式输出中间结果，最后再聚合。千万不要让模型一次性吞下所有数据，费用高，质量还不可控。
被截断有一个很隐蔽的现象：JSON输出到一半被切断后，你就算调大max_tokens重新生成，也可能因为中间多了半个字段而解析失败。所以我在解析前会先判断是否有截断标志，如果有，不直接解析，而是让模型续写残段。
4.4 别让提示词变成“碎钞机”：成本与token优化
提示词越长，每次调用越贵。尤其是一个长上下文提示词被循环调用时，成本会快速放大。我总结了一套降本思路。
第一，精简上下文。不是每一轮都需要携带完整历史，只保留最近的关键几条或一段摘要就够了。第二，示例要少而精。两个示例能把格式说清楚，就不要放八个冷门示例。第三，能用小模型解决的问题，不要用大模型。文本分类、信息抽取这类简单任务，小模型已经覆盖了大多数场景；更复杂的摘要和推理，才值得上更强的模型。
第四，设置max_tokens上限。防止模型偶尔写出一篇长文，导致单次费用暴涨。第五，重试要有熔断机制。不要模型一报错就无限重试。如果同一个请求连续失败三次，通常是提示词本身有问题，先去改提示词，而不是加重试次数。
要补充一句：不要把调试阶段的API消耗算进生产成本。调试阶段反复调用是正常的，但上了生产环境，要尽量走缓存和批处理，把同一份提示词的重复调用降到最低。这比单次省几百个token带来的收益大得多。
写提示词这一年多，我最大的感受是，它比想象中更接近“工程学”而不是“灵感”。那些看起来“很会写提示词”的人，无非是把角色、示例、格式、参数这几个变量控制得比其他人更干净。如果你刚开始做AI应用开发，不用急着把所有技巧一次用完。先拿一个任务跑通最小闭环，然后每次只改一个维度、记录一组结果。用不了半个月，你自己就会形成一套判断标准：什么场合调低温度，什么场合加示例，什么场合必须上结构化输出。所谓稳定的输出，其实就是你把需求翻译得足够清晰的回报。希望这篇实战总结能帮你少走几步弯路。
