1. 为什么 Prompt 工程值得单独拎出来做实验手册很多人第一次接触大模型注意力全在模型参数、榜单排名、API 价格上觉得 Prompt 不过是把问题说清楚而已。真到项目里跑一圈才发现同一个模型、同一个接口换一种问法输出质量能差出两三个档次。这不是玄学而是因为大模型本质上是条件概率生成器——你给的上下文就是条件条件变了分布就变了。我最初做 Prompt 工程的时候也走过弯路觉得写提示词就是堆形容词把请你认真思考你是世界顶级专家这类话往上贴。后来在真实业务里反复调试才明白Prompt 工程的核心不是讨好模型而是把任务约束、输出格式、推理路径、边界条件用模型能稳定解析的方式表达出来。它更像写接口契约而不是写作文。这份实验手册式的学习笔记面向的是已经能调通 API、但输出质量忽高忽低的人。不管你是做智能客服、文档抽取、代码辅助还是数据分析只要你在用大模型解决实际问题Prompt 工程就是绕不开的基本功。下面我会按原理—结构—实操—排错—进阶的顺序把我在实际项目里验证过的做法拆开讲包括那些文档里不会写、只有踩过坑才知道的细节。2. 先搞清楚 Prompt 在大模型里到底做了什么2.1 从 token 到概率分布Prompt 的真实作用位置要理解 Prompt 为什么有效得先知道它在模型内部经历了什么。你输入的每一段文字会先被分词器切成 token然后转成向量进入 Transformer 的注意力计算。模型做的唯一一件事就是根据当前所有 token预测下一个 token 的概率分布然后采样出一个结果再把这个结果拼回输入继续预测下一个。所以 Prompt 的本质是在生成开始之前把概率分布往你期望的方向推。你写请用 JSON 输出模型在生成第一个字符时{的概率就会被显著抬高你写只回答是或否模型生成是或否的概率就会压过其他所有词。这不是模型听懂了而是条件概率被你的上下文改变了。理解这一点非常关键因为它解释了几个常见困惑为什么 Prompt 里加一句无关的话可能让输出崩掉改变了条件分布为什么同样的 Prompt 在不同模型上效果不同训练数据分布不同为什么长上下文里靠后的指令往往更有效注意力权重和位置编码的影响。2.2 指令、上下文、示例三类信息的权重差异一个完整的 Prompt 通常包含三类信息它们的话语权并不相同。指令告诉模型要做什么比如总结以下文本。它决定任务方向但对格式的控制力较弱。上下文模型需要处理的原始材料比如待总结的文章。它是任务的对象通常越长越容易稀释指令。示例给模型看的输入输出样例。它对格式和风格的约束力最强因为模型会直接模仿示例的模式。我在实际项目里总结出一个经验当格式要求复杂时示例比指令管用当任务逻辑复杂时分步指令比示例管用。比如让模型抽取合同里的甲乙方、金额、期限你写十句请准确抽取不如给两个完整的输入输出示例但让模型做多步推理计算示例反而会限制它的思考路径这时候拆成第一步先识别已知量第二步列方程更有效。2.3 为什么角色设定有时有用有时没用你是一名资深律师这类角色设定是 Prompt 里最常见的套路。它到底有没有用我的实测结论是对风格和领域词汇有用对事实准确性基本没用。角色设定会激活模型训练数据里与该角色相关的语料分布所以输出会更像那个领域的表达方式用词更专业。但它不会让模型真的变成律师也不会让它知道它原本不知道的法律条文。如果你的任务是用专业口吻写一段产品介绍角色设定很有效如果任务是准确回答某条法规的具体条款角色设定帮不上忙甚至可能让模型更自信地编造。所以我的做法是角色设定只用来控制语气和术语层级不用来指望它提升事实正确性。事实正确性要靠提供参考资料、要求引用来源、设置不知道就说不知道的约束来实现。3. 一套可复用的 Prompt 结构模板3.1 四段式骨架任务、约束、输入、输出经过多个项目的迭代我固定下来一个四段式结构几乎能覆盖八成以上的任务场景。任务段一句话说清楚要做什么动词开头避免模糊。比如从以下用户评论中抽取产品名称和情感倾向。约束段列出必须遵守的规则比如情感倾向只能是正面、负面、中性三者之一产品名称保持原文表述不要改写。输入段用明确的分隔符把待处理内容包起来比如三个反引号或 XML 标签。输出段给出输出格式最好带一个示例。这个结构的价值在于把不同性质的信息物理隔开减少模型混淆。我见过太多 Prompt 把任务、规则、数据混在一段话里模型经常把数据里的某句话当成指令执行。用分隔符隔开之后这类问题能减少一大半。3.2 分隔符的选择为什么我偏爱 XML 标签分隔符有很多选择三个反引号、三个井号、XML 标签、特殊符号串。我实测下来XML 标签的稳定性最好尤其是处理长文本和嵌套结构时。原因有两个。一是 XML 标签在训练数据里大量出现模型对content.../content这种结构非常熟悉能准确识别边界。二是标签可以带语义review和instruction一眼就能区分模型不容易搞混。相比之下三个反引号在 Markdown 语境里可能被当成代码块特殊符号串则可能和正文内容冲突。一个典型的写法是这样task从下面的用户评论中抽取产品名称和情感倾向/task rules 1. 情感倾向只能是正面、负面、中性 2. 产品名称保持原文不要翻译或改写 3. 如果评论中没有提到具体产品产品名称填未提及 /rules review 这个耳机音质不错但是续航太差了用了两天就想退货。 /review output_format {product: 产品名称, sentiment: 情感倾向} /output_format3.3 输出格式约束JSON、表格还是自然语言输出格式的选择取决于下游怎么用。如果结果要进程序解析JSON 是首选但要注意几个坑。第一模型可能输出带 Markdown 代码块的 JSON也就是外面包一层 json。解析前要么在 Prompt 里明确不要用代码块包裹要么在代码里做兼容处理。第二模型可能在 JSON 前后加解释性文字比如好的以下是结果{...}。稳妥的做法是在 Prompt 里要求只输出 JSON不要任何其他文字同时在解析时用正则提取第一个完整的 JSON 对象。如果结果给人看表格或分点列表更合适。如果结果要喂给另一个模型自然语言段落反而更好因为结构化格式可能损失语义细节。我一般会准备两套 Prompt一套面向程序解析输出严格 JSON一套面向人工阅读输出带小标题的段落。4. 从零跑通一个抽取任务的完整过程4.1 任务定义与基线 Prompt 的搭建假设我们要做一个电商评论分析工具从评论里抽取产品名称、情感倾向、以及提到的具体问题点。先写一个最朴素的基线 Prompt请分析以下评论告诉我产品名称、情感倾向和问题点。 评论这个耳机音质不错但是续航太差了用了两天就想退货。跑出来的结果大概率是能用的但格式不稳定有时是段落有时是列表字段名称也每次不一样。这个基线的作用不是直接用而是作为对照验证后续优化的提升幅度。我习惯把基线输出保存下来后面每改一版 Prompt 都对比一次避免感觉变好了这种主观判断。4.2 加入结构化约束后的效果对比把基线升级成结构化版本task从电商评论中抽取结构化信息/task rules 1. 产品名称评论中明确提到的产品保持原文 2. 情感倾向正面、负面、中性三选一 3. 问题点列出评论中提到的所有负面问题没有则填空数组 4. 只输出 JSON不要任何解释文字 /rules review 这个耳机音质不错但是续航太差了用了两天就想退货。 /review output_format { product: string, sentiment: 正面|负面|中性, issues: [string] } /output_format对比两次输出结构化版本的字段名、取值、格式都稳定了。这里的关键改动是把要什么和不要什么都写清楚尤其是只输出 JSON这一句能挡掉大部分多余文字。4.3 批量处理时的稳定性验证单条跑通不代表批量稳定。我拿一百条真实评论做了一轮测试发现几个问题一是评论里本身带引号或换行时JSON 容易解析失败二是有些评论同时提到多个产品模型只抽了一个三是极短的评论比如还行模型会硬凑情感倾向。针对这些问题我在 Prompt 里补了几条规则要求对引号做转义、要求多产品时输出数组、要求信息不足时字段填 null 而不是猜测。改完之后一百条里的解析成功率从八成出头提到了九成八以上。剩下的失败案例基本都是评论本身语义模糊属于任务本身的边界不是 Prompt 的问题。5. 那些让输出崩掉的 Prompt 反模式5.1 指令堆叠与相互冲突最常见的反模式是把一堆要求堆在一起彼此还打架。比如请详细回答但不要超过两句话请发挥创意但必须严格按模板输出。模型面对冲突指令时会随机偏向其中一条导致输出不稳定。我的处理原则是同一维度只保留一条指令。要控制长度就只写长度约束要控制格式就只写格式约束不要既要求详细又要求简短。如果确实需要分情况就用条件语句写清楚比如如果问题简单一句话回答如果问题复杂分点说明。5.2 否定式指令的陷阱不要编造不要输出无关内容不要用专业术语——这类否定式指令看起来合理实际效果往往很差。原因是模型生成时是逐 token 预测的你提到编造这个词反而激活了与编造相关的分布。更有效的做法是把否定转成肯定。不要编造改成只使用提供的资料回答资料中没有的信息填未知不要用专业术语改成用日常口语表达面向没有技术背景的读者。这样模型知道该往哪个方向生成而不是知道该避开什么却不知道去哪。5.3 示例污染坏例子比没例子更糟给示例是为了让模型模仿但如果示例本身有瑕疵模型会忠实复制瑕疵。我见过一个案例示例里的 JSON 少了一个逗号结果模型输出全都跟着少逗号。还有示例里的字段顺序和说明不一致模型就随机选一种。所以给示例前一定要自己先验证示例的正确性包括格式、字段名、取值、标点。示例宁少勿滥两三个高质量示例胜过十个凑数的。另外示例要覆盖边界情况比如空值、多值、异常输入否则模型遇到这些情况就自由发挥。6. 参数调优温度、Top-p 与 Prompt 的配合6.1 温度不是越高越有创意温度控制的是采样时的随机性。温度低模型倾向于选概率最高的 token输出稳定但可能呆板温度高低概率 token 也有机会被选中输出多样但可能跑偏。很多人以为创意任务就调高温度其实不完全对。我的经验是抽取、分类、格式转换这类任务温度调到接近 0保证每次输出一致文案生成、头脑风暴这类任务温度在 0.7 到 1.0 之间超过 1.0 之后输出质量下降明显容易出现语义断裂。而且温度要和 Prompt 配合——Prompt 约束越严温度可以适当高一点Prompt 越宽松温度越要压低否则输出会失控。6.2 Top-p 与温度的组合策略Top-p 是从概率累积到某个阈值为止的候选集合里采样。它和温度的作用有重叠一般不建议同时大调。我的常用组合是确定性任务用温度 0、Top-p 1.0创意任务用温度 0.8、Top-p 0.9。这样既保留一定多样性又不会采到概率极低的离谱 token。还有一个容易被忽略的参数是最大输出长度。设得太短输出被截断JSON 不完整设得太长模型可能在回答完之后继续编。我一般会根据任务预估一个合理上限比如抽取任务设 500 token长文生成设 4000 token并在 Prompt 里明确要求回答完整后立即停止。6.3 不同模型对同一 Prompt 的响应差异同一个 Prompt 换模型效果可能天差地别。有的模型对指令遵循度高你说只输出 JSON 它就只输出 JSON有的模型喜欢贴心地加解释你得反复强调。有的模型对长上下文处理得好塞一万字资料还能抓住重点有的模型超过几千字就开始丢信息。所以Prompt 不能跨模型直接复制必须针对目标模型重新验证。我的做法是维护一个测试集每次换模型或换版本都跑一遍测试集对比关键指标格式合规率、字段准确率、幻觉率用数据决定要不要调整 Prompt。7. 踩坑实录一次线上抽取任务的排查链路7.1 现象格式合规率突然从 98% 掉到 70%有一次线上评论抽取服务平稳跑了两周某天监控报警说 JSON 解析失败率飙升。第一反应是模型服务出问题查了接口状态和延迟都正常。然后怀疑是流量突增导致限流查了 QPS也没异常。接着我把失败样本捞出来看发现一个规律失败的基本都是评论里包含英文引号或特殊符号的。再往前追发现当天上线了一个新渠道这个渠道的评论里用户喜欢用英文引号和表情符号。问题定位到了这些字符破坏了 JSON 结构。7.2 定位是 Prompt 问题还是数据问题继续深挖发现两个层面的问题。一是 Prompt 里虽然要求了 JSON 输出但没要求对特殊字符转义二是后端的解析逻辑用的是严格 JSON 解析遇到未转义的引号直接抛异常。这里有个判断经验如果失败样本有共同的数据特征优先怀疑数据如果失败样本随机分布优先怀疑 Prompt 或模型。这次明显是数据特征集中所以主因在数据但 Prompt 没有做防御也是事实。7.3 修复Prompt 加固与解析兜底双管齐下修复分两步。Prompt 层面加了两条规则要求对字符串内的引号、换行、反斜杠做转义要求输出前自检 JSON 是否合法。解析层面加了一层容错先用宽松模式尝试解析失败则用正则提取字段再失败才记录错误样本。改完之后合规率回到 99% 以上。这次踩坑给我的教训是Prompt 工程不只是写提示词还要考虑上下游的数据流。模型输出只是中间环节后面的解析、存储、展示都可能出问题防御要做在每一层。8. 进阶让 Prompt 具备自我校验能力8.1 自检指令的写法与效果让模型在输出前自检是提升质量的有效手段。常见写法是在 Prompt 末尾加一段在给出最终答案前请先检查 1. 输出是否符合指定格式 2. 是否有字段缺失或取值超出范围 3. 是否有编造的信息 如果发现问题请修正后再输出。实测下来这段自检指令对格式类错误的修正效果明显对事实类错误的修正效果有限。原因是模型的自检也是生成过程它未必能发现自己不知道的东西。所以自检适合防格式错、防遗漏不适合防幻觉。8.2 分步推理与思维链的取舍思维链让模型一步步推理能显著提升复杂任务的准确率但有两个代价一是输出变长成本上升二是推理过程可能被下游误当成结果。我的做法是按需开启数学计算、逻辑推理、多条件判断这类任务开启思维链抽取、分类、格式转换这类任务关闭直接输出结果。如果既要推理又要干净输出可以用两段式第一段让模型推理第二段让它只输出结论。或者用结构化输出把推理过程放在reasoning字段结论放在answer字段下游只取answer。8.3 用少样本示例引导复杂格式当输出格式特别复杂比如嵌套 JSON、多级列表、带条件的字段光靠文字描述很难说清。这时候少样本示例是最有效的手段。给两三个完整的输入输出对模型就能准确模仿结构。示例的选择有讲究要覆盖主要分支比如正常情况、空值情况、多值情况各一个示例之间格式要完全一致不能一个用双引号一个用单引号示例内容要真实不要用foobar这种占位符否则模型可能把占位符也学过去。9. 把 Prompt 当代码来管理9.1 版本化与回归测试Prompt 改一版效果可能变好也可能变坏而且坏的地方未必是你改的那部分。所以 Prompt 必须像代码一样做版本管理。我的做法是每个 Prompt 存一个文件文件名带版本号改动记录写清楚改了什么、为什么改。同时维护一个回归测试集包含正常样本、边界样本、历史失败样本。每次改 Prompt 都跑一遍对比关键指标。没有测试集的 Prompt 优化就是盲改改到最后自己都不知道哪版最好。9.2 变量注入与模板复用很多 Prompt 的结构是固定的只有输入内容在变。这时候把 Prompt 做成模板用变量占位能大幅提升复用性。比如把任务描述、规则、输出格式固定下来只把review里的内容替换成实际数据。模板化还有个好处是便于统一修改。如果发现所有抽取任务都需要加一条对特殊字符转义的规则改模板一处就够了不用每个 Prompt 都改。我用的是简单的字符串替换复杂场景可以用模板引擎但要注意别让模板逻辑太复杂否则调试困难。9.3 成本与延迟的权衡Prompt 越长token 消耗越多延迟越高。一个塞满示例和规则的长 Prompt单次调用成本可能是短 Prompt 的好几倍。所以在生产环境里我会做分层简单任务用短 Prompt复杂任务用长 Prompt能缓存的上下文比如固定的规则说明尽量复用示例数量按任务难度动态调整。还有一个技巧是把不常变的长内容比如知识库片段放在 Prompt 前部把指令放在后部。因为部分模型对靠后的内容注意力更强指令放后面遵循度更高。这个规律不是所有模型都成立需要针对目标模型实测。10. 我在实际项目里沉淀的几条经验做了一段时间 Prompt 工程最大的体会是它介于工程和写作之间既要有结构化的严谨又要有对语言的敏感。纯工程思维的人容易把 Prompt 写成需求文档模型读不懂纯写作思维的人容易把 Prompt 写成散文模型抓不住重点。几条具体经验分享给同样在做这件事的人。第一先跑基线再优化没有基线就没有对比容易陷入自我感觉良好。第二失败样本比成功样本更有价值每次出问题都把样本存下来慢慢就攒出一个高质量的测试集。第三不要迷信任何万能 Prompt 模板任务不同、模型不同、数据不同模板只能当起点必须自己调。第四把 Prompt 和参数一起调只改 Prompt 不改温度有时候怎么改都差一口气。最后说一个容易被忽略的点Prompt 的可读性也很重要。你的 Prompt 可能要给同事看、要给未来的自己看写得清晰、分段、带注释比写得紧凑但一团乱麻要好得多。我现在的习惯是每个 Prompt 文件开头写一段注释说明任务、输入、输出、已知限制过几个月回头看还能快速捡起来。