★ FEATURED ARTICLE 过去两年我反复在提示相关项目里打转从给人精调单条提示到负责整套提示体系的设计与维护最大的感受是提示工程的瓶颈从来不在文案而在架构。很多人以为写提示词就是“把需求说得更像人话”但真把一个产品级项目跑起来之后你会发现真正花时间的不是措辞而是怎么确定边界、管理版本、设计评估、追踪变更。这种从“写提示”到“搭体系”的转变是我最想分享的核心经验。为了把这件事说透我会分几个部分展开先讲为什么单条提示撑不起产品级场景再讲八条系统设计原则最后用一个客服助手的例子把原则落成目录结构、评估流程和迭代节奏。不管你是刚接触提示词不久的新手还是已经在生产环境里维护几十条提示的工程师这篇文章里应该至少有一部分能直接拿去用而不是看完就忘。1. 为什么单条提示撑不起产品必须要体系化管理很多团队一开始都靠一两位“提示小能手”来维护提示词运行几天觉得效果不错但只要进入生产环境、涉及多人协作问题就会开始扎堆出现。体系化不是一种炫耀工作量的姿态而是被实际事故逼出来的选择。1.1 一条提示进入生产后会遇到的三类失控单个提示在原型阶段完全够用写一段话拿一个输入看一个输出效果不好就改措辞改到满意为止。但这个阶段有个隐蔽前提——你默认了只有你自己在使用这条提示需求的变更频率也被控制住了。一旦这条提示进入产品三个变化会很快出现。第一个变化是业务需求开始持续涌入。今天业务同学说要增加情绪安抚语气明天说要支持多个品类后天说“不要把结果输出成表格要改成列表”。这些需求听起来都很小但多数人会选择往原来的提示里继续堆规则而不是重新设计结构。于是提示文本越来越长逐渐变成一份比需求文档还要冗长的“规则堆”。第二个变化是模型版本不受你控制。今天聊得好好的措辞模型服务商做了一次升级行为可能完全变了。原始提示并没有变但输出变了。这种漂移非常考验人因为很多人会下意识认为是自己的提示写错了连夜改词改完发现原因是模型升级导致的白白浪费时间。第三个变化是多条提示之间很容易互相矛盾。比如一个客服产品里既有“只回答订单相关问题”的提示又有“可以适当闲聊活跃气氛”的提示当多个团队各自维护自己的提示时用户感知到的产品就会像精神分裂。这类一致性问题单靠人工提醒是管不住的。我做过一个客服助手项目早期就是一条总提示把身份、语气、回答范围、拒答规则全放在一起。后来业务要支持多个品类只能不断往里面塞规则。到第四个月那条提示比产品需求文档还长每次改动都会产生不可预期的连带反应。最终我们决定重做把所有职责拆开才从“改一行崩一片”的困境里走出来。1.2 四层结构指令层、上下文层、格式层、兜底层我习惯把提示体系定义为一组有明确职责边界、有依赖关系、有版本记录、可被单独评估和替换的提示集合。一个成熟体系至少包含四层结构这也是后面八条原则的框架基础。第一层是指令层告诉模型“怎么做事”。这一层包含角色、目标、规则、约束是提示里最稳定的部分。第二层是上下文层提供“做什么事”的信息包括用户输入、知识库片段、业务数据这一层是每次调用都会变化的部分。第三层是格式层规定输出结构例如 JSON 结构、标题层级、字段顺序、术语风格。第四层是兜底层处理异常情况包括拒答、澄清、重试、降级、人工接管。这四层不是要求你每次写提示都分成四个文件而是要求你在设计时想清楚哪部分是稳定的哪部分是变化的哪部分是可能出错的。想清楚边界体系才立得住。2. 原则一到三先拆职责、分层、隔离数据把提示骨架立稳这三条原则解决的是“提示写得乱不乱、能不能改”的问题。如果这三条做得好后续加新场景、调新模型时你会有清晰的修改入口而不是从头读一遍长文本。2.1 原则一单一职责一条提示只干一件事单一职责已是软件工程里的老话但放在提示词里经常被忽略。原因是写提示词时大家天然倾向“一步到位”希望一条提示解决所有问题省去路由和编排的麻烦。短期是省事长期是灾难。以客服助手的例子来说售前咨询、售后问题、闲聊是三件完全不同的事。如果写一条大提示让模型自己判断当前对话属于哪一类再执行哪类策略规则之间很容易冲突。比如提示里同时存在“不要闲聊”和“可以适当调节气氛”模型就会在边界地带表现出随机性今天这么回答明天那么回答用户和测试人员都很难受。我的建议是拆成多条提示由上层路由决定调用哪一条每条提示只保留一种职责。这样做有三个明显收益。第一出问题好排查哪条提示异常就只改哪条不需要通读十屏长的文本。第二评估更精确你可以针对一条提示构造专属测试集结果能准确反映它自身质量而不会被其他任务干扰。第三耦合度低新增场景就是新增一条提示而不是去拆一条已经被业务绑定的旧提示。我自己踩过一个坑曾为了追求单一职责把一条 200 字的提示拆成 5 条各 40 字的提示结果每条都因为缺乏上下文而表现变差。后来我总结出一个判断标准一条提示该不该拆分要看它能否独立定义输入和输出。能独立定义输入输出拆开才值得如果只是把相同上下文的规则硬切成几段拆了反而更差。注意单一职责不是颗粒度越小越好而是职责边界越清楚越好。判断边界就是把“输入是什么、输出是什么、失败时怎么办”写出来写不清楚就别拆。2.2 原则二上下文分层让角色、任务、格式各占其位我见过不少团队的提示是“一段超级自然语言”身份、背景、目标、要求、格式、禁忌全揉在一起。这种写法在模型只处理一种任务时效果尚可一旦业务复杂起来维护的人根本不知道该改哪个部分甚至会因为改了前半句而影响后半句的稳定性。上下文分层的意思是把提示信息按功能拆成独立区块每一层只关注一种信息类型。我在模板里常用的四个区块是 System 区、Task 区、Format 区、Constraint 区。System 区放固定身份与全局规则原则上不动。Task 区放本轮任务的具体目标和边界例如“从用户问题中抽取订单号、商品名、期望动作”。Format 区规定输出格式必要时要给出一个具体示例。Constraint 区写本轮明确禁止的事项例如“不要询问用户”“不要重复提问”“禁止输出 Markdown”。分层的价值在变更管理上体现得最明显。业务要求改输出格式只动 Format 区要求改变语气风格只动 System 区要求增加禁止事项只动 Constraint 区。大多数修改都变成局部替换而不是整段重写。还有一个容易被忽略的点把“可变的”内容用占位符标注把“不可变的”原文固化。System 区固定使用模板原文Task 区和用户输入拼装后放在末尾。这样做的目的在于用户句法不会污染固定的指令区模型不会偶然把用户输入里的某些话当成指令来执行。2.3 原则三模板与数据分离给提示建立入参白名单这一条原则和传统 Web 开发中的模板引擎思路非常接近。模板是静态的指令骨架数据是每次请求不同的动态内容两件事必须分离处理不要混在一个字符串里维护。第一层分离发生在文件层面。提示模板放在独立的提示目录中测试数据放在测试目录中业务数据通过变量注入。同一份模板可以被多组数据调用但模板文件本身不应包含任何一条具体业务数据。第二层分离发生在运行时层面。用变量占位符替代所有动态内容例如你是{assistant_name}负责解答与“{product_name}”相关的售前咨询。 用户问题{user_query} 请用不超过{max_words}词回答。在调用时把变量替换好之后再发送给模型。模板本身保持稳定接收的变量就是它的“入参白名单”。这个机制强制你思考一个问题这条提示到底能接受哪些输入白名单之外的内容不应该影响模型行为。这样你可追踪、可复现的能力才会真正落地。很多团队漏掉了另一层模型中间生成的结果也应该作为新变量回到模板变量中而不是直接拼接到模板中间。例如在反思类或改写类流程中模型第一次生成的文本应当被记为refined_text然后再注入到第二步模板里。如果直接拼接到原模板中间模板结构会在运行期悄悄改变之后的测试和日志全部失真。3. 原则四到六用日志、版本、模块复用让提示工程化骨架立起来之后下一步要解决的是“改不动、查不了、管不住”的问题。这三条原则全部朝工程化方向走。3.1 原则四可观测性每条调用留下可复现日志提示工程里最被低估的部分不是提示文案而是调用记录。没有日志你连问题是否真的出在提示上都说不清楚。我甚至见过团队为了排查一个线上问题花了三天时间人工复现结果发现模型版本早就升级了根本没法还原当时环境。一套可观测体系至少要覆盖三个层面。调用层记录每次请求的模型名称、版本、温度参数、原始输入、最终输出。提示层记录提示模板 ID、版本号、本次替换的具体变量值。指标层记录耗时、token 消耗、重试次数、成功状态、失败原因。有了这些日志才能真正回答一个关键问题当线上效果变差时是模型升级引起的、提示版本变更引起的还是业务输入结构变化引起的。我在非敏感场景里通常会把日志输出成 JSON 行方便检索和分析。字段至少包含这些prompt_template_id、prompt_version、model_name、model_version、input_hash、output_hash、latency_ms、token_count、trace_id。注意不要为了省存储只记录输出不记录输入。排查问题时输入和输出必须成对出现少一个都很难复现。这是我在项目里被反复教育过的一课。3.2 原则五版本化管理提示也要有变更记录和回滚能力提示词本质上也是代码只是它的运行环境是模型不是编译器。但很多团队维护提示词的方式还是靠一份“说明文档”甚至文档标题是“最终版v2(改).docx”。一看到这种文件名我就知道这不是版本管理是版本灾难。版本化的最低要求是三条。第一模板文件进入版本库每次修改产生 diff而不是直接覆盖原文件。第二发布版本时打 tag例如 prompt-v1.2.0方便回滚。第三线上服务记录当前使用的提示版本切换版本要走发布流程不能偷偷改上线。我在项目里的做法是每个模板文件头部加一段元信息包含 id、version、owner、change_log。运行时系统根据请求里携带的版本号去路由到对应模板。这样提示就从“一次性编辑”变成了“可回溯资产”。这里说一个我亲历过的教训。某次线上效果波动我查了很久最后发现同事直接改了共享模板并保存没有更新版本号新旧请求混用了同一个模板 ID。从此我们强制要求任何修改必须填写 change_log并由评审人确认后才能合入。评审不是走形式至少要一位懂业务的同事明确给出“同意”意见才能代表需求理解没有偏差。3.3 原则六模块化复用公共约束只维护一份提示体系规模上去之后最容易出现的问题就是隐性复制。团队里不同模块各自维护一份“语气友好”“不编造信息”“违规内容拒绝回答”等片段表面上进度很快实际上维护成本在暗中暴涨。模块化的思路就是把公共能力识别并提取成可复用片段。比如在内容安全场景里几乎所有提示都需要“涉及违规内容时拒绝回答并给出理由”的约束在客服场景几乎所有提示都需要“语气礼貌、不用专业术语”的指令。这类公共片段应统一放到公共目录供其他模板引用。我的引用做法有两种。简单做法是在渲染时代码拼接维护一个公共片段池按 key 注入模板。进阶做法是做成函数式模块支持带参数调用例如safety_block(levelhigh)会渲染出一段高风险拒答规则levellow则换成更宽松的表述。模块化之后有一个立竿见影的好处改公共约束只需改一处所有提示的该项能力同步更新一致性大幅提升。同时新成员的学习成本也大大降低。新人不再需要逐行读完整条提示而是先看公共模块清单再重点理解各模块的差异部分半小时就能上手。4. 原则七到八用测试集和兜底机制驱动提示持续进化前六条原则是保证体系“能用、能管、能改”最后两条解决的是“怎么越改越好而不是越改越乱”。4.1 原则七评估驱动迭代没有测试集就不谈优化每次迭代都要有依据不能凭感觉。我在项目里给提示迭代定过一条硬规矩先有测试集再谈优化。没有测试集就动手改提示本质上是在猜。测试集不用一开始就做得很庞大但需要覆盖三种典型场景。核心场景是覆盖率最高的主路径比如客服助手的“咨询-回答-结束”。边界场景是容易翻车的输入比如非常短的问题、包含错别字的表述、带有敏感词的输入。回归场景是历史上出过 bug 的输入每一条都要记录当时的期望行为。评估维度我常用四个指令遵循率、输出格式合法率、信息正确率、语气一致性。这四个维度可以根据业务权重调整分数。离线测试集跑完系统自动判分适合做回归检查人工抽样评估适合捕捉体验死角线上小流量对比实验适合做最终验收。这三件事形成一个循环离线评估发现问题人工评估发现体验问题线上实验确认最终效果。迭代节奏也从中固定下来变成稳定运行的队列而不是临时起意的手工修改。没有这个循环所谓的优化就是看谁嗓门大、谁运气好。4.2 原则八兜底与降级给提示体系装上保险丝再精心设计的提示体系也会面对不可控的情况模型返回格式错误、模型拒答、请求超时、上下文超长。体系设计的目标不是避免这些情况出现而是在它们出现时系统依然有清晰可预期的行为。我会给每条提示强制配三类兜底。第一类是输出校验兜底模型返回不符合格式要求时自动重试一次仍然失败就降级为固定话术。第二类是上下文压缩兜底请求超出模型上下文限制时用摘要工具或“丢弃非关键上下文”策略处理而不是直接报错。第三类是人工接管兜底当模型连续失败或内容风险偏高时把请求转入人工队列并完整保留全部上下文日志。这里我想专门强调一个问题兜底逻辑本身也应该被测试。不要以为写一个 if-else 就算完事。至少要把“模型返回空内容”“模型返回残缺 JSON”“模型拒绝回答三类风险输入”这几个场景纳入测试集确保每条提示在异常路径下都有明确行为。很多系统正常路径跑得很漂亮一到异常路径就裸奔本质上是测试覆盖没有延伸到兜底逻辑。5. 实操落地从零搭建可迭代提示体系的完整步骤原则讲得再顺落地才是真功夫。下面用一个简化的客服助手项目为例把从需求拆解到目录结构搭建的完整过程串一遍。你可以直接把它当模板换掉业务名称就能用。5.1 第一步业务需求拆解与提示职责划分假设我要做一个“订单查询与售后引导”的客服助手。先别急着写提示而是把任务拆一遍拆出四类核心任务。订单状态查询需要调用查询 API提示的职责是把用户问题抽取成结构化参数比如订单号、商品名、查询意图。售后流程引导不需要调用 API提示的职责是按售后规则给出分步骤建议。常见问题解答从知识库检索片段提示的职责是把片段转成友好答复。无法处理的请求识别超出范围的问题提示的职责是拒答并引导到人工客服。四类任务对应四条独立提示每条都定义自己的输入和输出。全局通用的“语气友好、不编造信息、不泄露他人隐私”等规则提取到公共模块common/style.md和common/safety.md里由渲染层统一注入。这样各模块的核心差异只体现在业务逻辑部分公共部分不再各写各的。5.2 第二步最小化评估集与标准化迭代流程针对四条提示各建一个最小测试集。测试集放在tests/eval目录下每条提示的固定输入输出对不少于 10 个边界输入不少于 5 个。所谓固定输入输出对是指对同一个输入你明确知道期望的输出行为是什么。回归测试要求的不是句式完全一致而是结构化行为一致比如字段齐全、拒答原因清晰、步骤顺序正确。迭代流程固定成五步修改模板或公共模块。在本地跑全部离线评估集查看分数变化。分数下降的样本逐条分析判断是预期调整还是回归问题。通过后合入测试分支发布新版本并打 tag。线上小流量灰度观察核心指标正常后全量发布。这套流程看起来比“改完直接上线”要重但长期算下来反而省时间。因为它让每次迭代都有可对比的基线不需要重复“凭感觉调词、靠线上心情好坏判断效果”的玄学循环。5.3 第三步一套可直接参考的目录结构下面这个目录结构我在一个小型项目中实际用过并运行良好可以直接抄作业prompt-system/ ├── README.md ├── common/ │ ├── style.md │ ├── safety.md │ └── format_json.md ├── modules/ │ ├── order_query/ │ │ ├── main.md │ │ ├── variables.json │ │ └── examples.md │ ├── after_sale/ │ │ ├── main.md │ │ ├── variables.json │ │ └── examples.md │ ├── faq_answer/ │ │ ├── main.md │ │ ├── variables.json │ │ └── examples.md │ └── reject_unknown/ │ ├── main.md │ ├── variables.json │ └── examples.md ├── tests/ │ ├── eval/ │ │ ├── order_query.json │ │ ├── after_sale.json │ │ ├── faq_answer.json │ │ └── reject_unknown.json │ └── fixtures/ ├── pipeline/ │ ├── render.py │ ├── evaluate.py │ └── deploy.py ├── logs/ └── versions/这个结构里最关键的设计是common目录只放公共片段不允许放业务私有逻辑modules目录按业务场景分模块每个模块包含提示主体、变量定义、示例三件套tests目录与业务代码分离方便测试人员只关注评估versions目录保存历史发布记录配合版本库 tag 使用。即使团队很小不上重型平台用这个目录结构配合版本库也能支撑起 10 到 20 条提示的中型项目并且足够支持后续扩展。不要一上来就追求复杂的编排平台先把目录、版本、测试这三件事做扎实已经能解决绝大部分团队的核心问题。6. 高频问题排障速查与避坑清单最后这部分把我在实践中反复遇到的高频问题整理成一张速查表。这些问题几乎每一套提示体系都会碰到出现频率极高。现象可能原因排查思路同一模板输出很不稳定用户输入被拼进了指令区污染了固定规则检查变量替换逻辑强制入参白名单上线新版提示后效果明显变差没有跑回归测试集先回滚到上一版本恢复业务再离线评估新版多模块语气明显不一致公共语气片段被各模块复制内容出现偏差把语气统一回公共模块删除各模块内私有拷贝模型偶尔返回 JSON 残缺格式约束放在提示末尾被较长上下文冲淡把格式示例前移到模板中段增加格式校验与重试线上日志无法复盘输入和输出只记录了其中一个补齐输入输出成对日志保留 trace_id 串联链路更换新模型后全线表现漂移模型版本变化导致旧提示不再适配用原测试集做基线对比按差异逐条重写关键提示我特别想分享的一个排查经验是当某条提示在线上表现波动时不要急着改词而是先复现。复现的意思是拿到同一条模板、同一个版本、同样的入参在可控环境里跑三次以上看波动率是多少。很多看似是提示质量问题的情况实际上是网络超时导致重试内容不一致或者是上游数据字段出现了意外变化。可观测日志到位之后这类问题基本一眼就能定位。如果日志缺失再聪明的人也只能靠猜而靠猜排障是最消耗团队信任的方式。7. 最后想交代的几件事我在多次迭代之后最深的感受是提示体系设计本质上是在管理不确定性。模型输出带有随机性业务需求持续变化模型本身也可能升级换代。体系的价值不是消除这些不确定性而是让每一次变化都有路径、有记录、有回退空间。如果你准备从零开始搭一套提示体系我的建议很朴素不要追求一步到位的完整平台先把手里的三到五条提示按单一职责拆开加上版本管理和一份最小化的测试集。把这一步做完你已经比大多数靠手写文档维护提示的团队前进了一大步。最后分享一个我的日常小习惯每周五下午固定拿出半小时把一周内的所有提示变更记录过一遍同时跑一遍核心测试集。这件事花的时间不多但能让我在下周一开工时对自己的提示体系是否在按预期演进有一个清晰的判断。提示工程不靠灵感靠的是稳定、可重复、可观测的迭代工程。
阅读完成 · 觉得有帮助？
