提示工程这行当有个特别迷惑人的表象很多人以为把提示词写得越长、越花哨、结构越复杂效果就越好。我在生产环境里折腾过一段时间之后得出了一个相反的结论——单个提示词再精彩也只是“武林招数”真正扛住真实流量、业务逻辑复杂、需要长期迭代的场景你得把它升级成一套“系统”。今天的文章就想聊聊提示系统到底长什么样又该怎么一步步搭起来。这篇文章不是来教你怎么写一个惊艳的 prompt 的而是给“提示工程架构师”这个角色准备的实操思路。它适合已经在用大模型接口做业务、但总觉得效果不稳定、改 prompt 像打地鼠的同学也适合准备从“写 prompt”过渡到“设计提示系统”的开发者。我会用一个真实的内部项目作为贯穿案例把上下文管理、指令设计、输出约束、缓存路由、评测迭代这些模块拆开讲尽量说人话。1. 从“单个提示词”到“提示系统”我在生产环境里踩过的那道坎1.1 那次让我意识到“提示词不是写出来的是养出来的”先讲一个我自己的经历。之前在某电商平台做一个售后工单分类的功能用户提交一条售后申请系统要自动判断是“质量问题”“物流延迟”“退货退款”还是“其他”。最开始我觉得这事太简单了写一段提示词往里一丢就行解释任务背景列几个分类选项要求输出 JSON完事。结果第一轮灰度就出问题了。真实工单长什么样用户会说“客服能不能帮我催一下快递东西一个星期了还在路上也没人联系我”里面有“催快递”“一个星期”“没人联系”三组关键信号其中“催快递”直接命中“物流延迟”但“没人联系”会诱导模型判断成“服务投诉”。单个提示词再怎么写也覆盖不住这种语义重叠和用户表达的多变。更麻烦的是随着我们不断往提示词里追加规则提示词本身变成了一个几百行的“脏文档”。每加一条规则前面某条规则可能就被稀释了。到后来同一个提示词上午调用和下午调用效果都不一样不是因为模型变了而是因为提示词内部的动作互相打架。从那时起我开始意识到提示词不是“写”出来的是“养”出来的。你需要把它当成一套有结构、有生命周期、有评测反馈的代码系统来管理而不是一个可以被随手粘贴的长文本。1.2 提示系统的边界它到底解决什么问题既然要谈系统先得圈定边界。一套完整的提示系统在我的理解里要解决四件事动态组装上下文让每次调用只携带和本次任务相关的信息而不是把所有背景知识全塞进去。稳定控制输出让模型输出符合业务格式不漂移、不跑偏、不夹带乱七八糟的说明。管理成本和延迟减少重复计算缓存可以复用的结果合理分配模型规格。可评测、可回归每次改动提示逻辑都能用一套离线数据证明“改好了”而不是“感觉更好了”。这四点分开看都不玄乎但放在一起就构成了一套独立于单个提示词之外的工程结构。接下来的内容是围绕怎么搭这套结构展开的。2. 提示系统的四层骨架上下文、指令、输出约束与路由2.1 第一层上下文组装决定模型“看什么”有时候你觉得模型答非所问不是因为提示词写得不好而是因为它看到的上下文里塞了太多无关信息。模型和人一样注意力是有限的——你把一段 3000 字的客服政策全文丢给它让它从中找出“退换货条件”它会找但找出来的重点可能和你期望的不一样。我的做法是引入一个“上下文组装器”它的职责不是写提示词而是决定每一轮对话中模型到底应该“看哪几块材料”。整个系统里维护一个素材库每一块素材都有类型、优先级、有效期。比如售后政策库按类目维护只加载命中当前类目的条目用户行为摘要只加载最近 5 条关键行为记录而不是一整年的订单流水历史会话记录只保留最近 3 轮对话避免上下文膨胀。这个组装器在运行时会先根据当前工单的类目、用户 ID、会话状态动态拼出一份“最小必要上下文”再交到下层的指令模板里。你可以把它理解成一个“特助”——在你向老板汇报之前他先帮你把无关材料全部拿走只把最相关的三份文件放在你桌上。2.2 第二层指令层决定模型“怎么做”指令层是大家最熟悉的“提示词正文”但它不该是一坨纯文本而应该是一套结构化模板。我把指令层拆成四个固定板块角色边界一句话说明模型在这个任务里是什么。注意不是“你是客服”而是“你是售后工单分类器只负责判断工单类型不做其他回应”。任务规则跟业务强相关的判定逻辑用编号列出来方便后续排查。比如“规则 3当用户同时提到物流和服务态度问题时优先归类为物流延迟”。思维脚手架给模型一个隐式的推理步骤。有时候我会让它在输出答案前先写一行“关键信号提取”把命中的规则列一遍这样分类结果会稳健很多。禁区列表什么不能做。比如“不得询问用户个人隐私”“不得输出 JSON 之外的内容”。这里有个很重要的经验规则用编号写不要用长篇段落写。原因是你之后做评测、做回归定位问题的时候能直接说“规则 7 导致误判”而不是“那段关于退款的话有问题”。可定位性是一项提示系统的隐藏需求。2.3 第三层输出约束决定模型“说什么”输出约束是提示系统里最容易被忽视、却最影响工程质量的一层。许多人只写“请输出 JSON”然后就开始在解析层写正则、处理各种意外字段。这不叫输出约束这叫亡羊补牢。真正可靠的输出约束层至少要包含三个手段格式指引在提示词里给一个具体的 JSON 示例而不是描述结构。给示例比为刺猬扎针还管用——模型不是按语法理解你的话而是按模式模仿你的样本。后置校验器用代码控制输出格式而不是靠模型自觉。比如要求输出 JSON 时系统里跑一段 schema 校验不通过就自动重试一次重试时把上一次的输出作为纠错样本塞回提示里。降级路径如果重试两次仍不符合格式就不该继续在提示词上耗而是走规则兜底或者人工兜底。生产系统必须接受“模型也是会摆烂的”这个事实。我在实践中发现加了后置校验和降级路径之后整个系统的格式异常率从最初的 5% 左右降到了 0.3% 以下。这不是提示词写得多好而是说明你用工程手段兜住了模型的不确定性。2.4 第四层缓存与路由决定系统“跑多快”缓存与路由很容易被归到“普通后端优化”但它在提示系统里有自己的特殊性缓存的内容不是数据而是“模型推理过的结论”。举个例子同样是“退货退款流程”相关的工单分类用户问法变了但业务结论可能完全相同。如果我每次都调用大模型接口成本高、延迟也高。于是我建了一个“语义缓存”把问题文本做向量化和过去七天内的问题算相似度相似度超过阈值就直接返回历史结论不再调用模型。路由层的逻辑更细同一套系统内可能混用几个不同规格的模型简单分类任务走轻量模型复杂纠纷走更强但更贵的模型。路由规则不是拍脑袋定的而是靠离线评测算出来的——拿一批带标签的数据在多个模型上分别跑按准确率和成本画一条曲线选择性价比拐点作为路由阈值。说实话缓存和路由做得好不好直接决定一套提示系统能不能从 demo 走向商业化。很多团队做 demo 很兴奋一上生产就发现账单烧得太快本质上是缺了这一层。3. 一个可落地的提示系统实例客服工单分类提示管线3.1 需求拆解不要把“分类”做成“聊天”工具层面的东西讲多了容易飘落到实际项目才能看出门道。我用前文提到的售后工单分类来串一遍完整搭建流程。先做需求拆解。这个任务有三个特点输入是用户提交的一段原始文本通常带口语、错别字、情绪宣泄输出是严格的单标签分类附带一句简短的判定理由不允许模型反问用户不允许输出“不确定性判断”。这意味着它不是一个对话任务而是一个“单轮分类任务”。任务定位错了后面全错。比如有人会设计成“先问用户一些问题再判断”——这看起来更准确但真实客服工单场景用户根本不会等你问完系统也承受不住多轮交互的延迟。所以一开始就要明确这是一条提示流水线不是聊天机器人。3.2 提示流水线的三段式组装我把这条提示流水线拆成三段预处理段、判定段、校验段。每一段有单独的职责方便独立调优。下面是判定段的伪代码结构展示整个提示是怎么被动态组装的def build_classification_prompt(order_id, user_text, user_profile): context context_assembler.load( order_idorder_id, need[policy, order_summary, recent_actions] ) rules load_active_rules(order_id.category) # 从规则库加载当前类目下的生效规则而不是全部规则 examples few_shot_picker.pick(user_text, k3) # 根据当前文本语义相似度挑3个最接近的历史样例 system render_template( templates/system_classifier.md, rulesrules, output_schemaSCHEMA, forbiddenFORBIDDEN_LIST ) user_prompt f 用户原文 {user_text} 附加信息 {context} 请按系统指令输出JSON不要输出任何解释。 return system, user_prompt预处理段干三件事清洗文本去掉无意义的“在吗”“谢谢”、提取用户 ID 和订单 ID、调用实体识别服务把商品名、物流单号等抽出来。这些信息会被拼进 context 里让模型少猜很多事。校验段就是前文提到的 format validator 重试机制。每一轮输出只有通过 schema 校验才会进入业务接口校验不通过则自动带上前一轮失败输出重新请求一次并把“这是错误示例”写进提示里。整个流程对上层业务方是透明的他们只管调接口拿结果。3.3 参数与成本调优让系统跑得稳又省这一段说几个我常用的参数控制思路都是实打实跑过多次验证的温度参数分类任务我推荐0 到 0.2不要再高了。温度是给创意生成用的分类任务需要的是确定性。0 不代表永远是同一个输出但能显著降低随机漂移。max_tokens 控制不要随手设一个 2048。先跑一批历史数据统计正确 JSON 输出的长度分布然后设成 p99 再加一小段余量。设太长会让模型有时间输出废话设太短会截断 JSON。频率惩罚与存在惩罚分类任务通常关掉或设极低。你要的是遵循格式而不是辞藻变化过度惩罚反而会导致模型遗漏必要字段。成本侧除了前文说的语义缓存还有一招是“类别路由”先用最便宜的模型把所有工单跑一遍如果它的置信度分数低于阈值再升级到高阶模型复判。实测这个方案能把整体成本压低 40%~55%而准确率损失控制在 1% 以内。4. 提示系统最常见的三个“静默杀手”4.1 格式化漂移模型突然不听话了格式化漂移是我最头疼的问题没有之一。具体表现是某天什么都没改模型突然开始在 JSON 前面加一句“好的根据您的描述我的分析如下”然后你的解析器就崩了。为什么会这样大概率不是模型“变了”而是提示词里的某部分触发了它的“对话模式”。比如你用了“请你帮我分析一下”这种措辞模型的角色就不知不觉从分类器切回了聊天助手。我的解法是双重保险。第一层在提示词里明确给出“输出以{开头以}结尾禁止任何其他字符”并且在 few-shot 样例里全部只放——注意是“只放”——纯 JSON 样本一个都不要带解释文字。第二层在代码层不依赖字符串开头判断而是用正则找到第一个“{”和最后一个“}”来截取片段再做解析。就算模型偶尔抽风也不会让整个系统挂掉。4.2 上下文污染问答越多效果越差如果你的提示系统是单轮任务上下文污染相对好控制。但如果是带历史会话的助手类系统这个问题会随着轮次增长越来越严重。在客服工单那个项目里我们也踩过一次把用户近 20 轮历史对话全部拼接进提示词想让模型“更懂用户”。结果分类准确率不升反降因为历史对话里有大量寒暄、情绪词、无关追问这些信息淹没了当前工单的核心信号。后来我们做了两个改动一是把历史会话截断到最近 3 轮并且只保留“用户发言”不保留客服侧回复二是每条历史记录都在前面加一个元信息标签比如[用户-提问] [用户-补充说明]让模型明确知道这段内容的角色和时序。上完这两板斧分类准确率从 82% 回升到了 91%。多不一定好关键看你给它看什么。4.3 评测失真离线打分离线线上该挂还是挂这是一个很“讽刺”的坑我在实验室里测分类准确率 96%上线后真实用户面前只有 75%。不是模型变了是我的评测集失真了。后来复盘发现三个问题离线评测集里“干净文本”占了八成但线上真实工单大部分是脏文本离线标注是在理想类目下标的真实数据里有很多“既像这个又像那个”的边缘case评测只看“分类对错”没看“理由是否合理”——有时标签对了模型给出的理由完全站不住脚这种输出在下游环节照样会捅娄子。开始做线上抽检之后我才意识到提示系统的评测必须让真实分布的样本参与进来。从线上日志随机抽 300 条历史工单让两个标注同事独立打标签不一致的丢给第三人仲裁用这批数据当过回归集。自此以后再改动提示词至少有一个“多少靠点谱”的基准线。5. 提示系统的评测与迭代没有度量就没有优化5.1 构造评测集三种必须有的样本说到评测得把构造评测集的方法展开讲透因为太多人倒在第一步。我的经验是评测集里至少要有三类样本黄金样本业务团队人工确认过标签的经典 case建议 200~500 条覆盖所有类目和主要表达变体。这部分是基准线用来防止回归。边界样本单看文本两个类目都说得通的 case至少 50 条。这类样本是模型最容易翻车的区域也是评测集里最有价值的部分它能逼你把规则写得清楚。脏样本含错别字、口语、情绪化表达、甚至夹杂着怼客服内容的 case。模型不能因为用户语气差就改变分类结论这类样本就是用来给模型“脱敏”的。评测集建好之后每次改动提示词或规则我要求团队先在本地跑一遍全量回归算出三类样本各自的准确率、格式异常率、平均延迟全部达标才能进灰度。没有评测结果的日子不许任何人改线上提示词。5.2 回归测试与灰度策略改提示词像改代码一样严肃改动提示词之前一定要意识到你改的不是一段文字而是算法本身。凡是未经评测、直接往生产环境里替换提示词的团队都迟早会“翻车”。我把改提示词的过程拉成了一条流水线写改动方案明确要解决什么问题在离线评测集上跑一遍对比改动前后的全部指标小流量灰度通常先放 10% 的流量跑两三天看线上抽检和投诉率再逐步放量。保持新旧版本并行支持一键回滚。实际操作中我特意给提示词加了一个version字段新版一律带v2.1这种标记。出问题时直接链路日志搜版本号几秒钟就能定位到是哪次改动惹的祸不需要靠回忆。5.3 版本管理提示词也是要“提 PR”的最后聊一个可能偏“组织文化”的话题——提示词版本管理。很多人觉得提示词存个备份文档就够了这是远远不够的。它会变会和代码协同演进会有人今天改一句、明天改一句最后谁都不知道线上跑的是哪个版本。我给团队立了一条规矩提示词与代码同库管理。提示词以模板文件的形式放在仓库里任何改动走代码评审流程留下 diff 记录和评测报告。这个 repo 里的“提交记录”就是整套提示系统的体检报告。这套流程运行半年后我们最大的收益不是效率而是可追溯性。业务方跑来问“这个判断逻辑是谁定的”我们查一下提交记录就能答上来。新同学接手时也不至于靠翻聊天记录猜提示词演进历史。就凭这一点我认为值得每个团队认真推行。说到底提示工程架构师这个角色主要工作不是“写词”而是“搭架子、定流程、立标准”。我手上每个项目的提示词本身最后都变成了很小的一块真正撑住效果的是那个看不见的系统上下文怎么选、输出怎么验证、改了之后怎么证明没改坏。这些才是提示系统能不能从实验室走到生产环境的关键。