提示工程这行当有个特别迷惑人的表象：很多人以为，把提示词写得越长、越花哨、结构越复杂，效果就越好。我在生产环境里折腾过一段时间之后，得出了一个相反的结论——单个提示词再精彩，也只是“武林招数”；真正扛住真实流量、业务逻辑复杂、需要长期迭代的场景，你得把它升级成一套“系统”。今天的文章就想聊聊，提示系统到底长什么样，又该怎么一步步搭起来。
这篇文章不是来教你怎么写一个惊艳的 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_id=order_id, need=["policy", "order_summary", "recent_actions"] ) rules = load_active_rules(order_id.category) # 从规则库加载当前类目下的生效规则，而不是全部规则 examples = few_shot_picker.pick(user_text, k=3) # 根据当前文本语义相似度挑3个最接近的历史样例 system = render_template( "templates/system_classifier.md", rules=rules, output_schema=SCHEMA, forbidden=FORBIDDEN_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 里的“提交记录”，就是整套提示系统的体检报告。
这套流程运行半年后，我们最大的收益不是效率，而是可追溯性。业务方跑来问“这个判断逻辑是谁定的”，我们查一下提交记录就能答上来。新同学接手时，也不至于靠翻聊天记录猜提示词演进历史。就凭这一点，我认为值得每个团队认真推行。
说到底，提示工程架构师这个角色，主要工作不是“写词”，而是“搭架子、定流程、立标准”。我手上每个项目的提示词本身最后都变成了很小的一块，真正撑住效果的是那个看不见的系统：上下文怎么选、输出怎么验证、改了之后怎么证明没改坏。这些才是提示系统能不能从实验室走到生产环境的关键。
