提示词最容易以一种很随意的方式变坏。有人发现模型在一个问题上答得不够好，就往系统提示里加两句要求；另一个人发现 JSON 偶尔解析失败，又补一段格式约束。几轮之后，提示词越来越长，某个坏例修好了，原本稳定的十几个场景开始变差。
如果一个提示词已经影响线上用户，它就不再是临时文案，而是系统行为的一部分。系统行为需要版本，需要评测，也需要回滚。
提示词改动要能说清目的
每次改提示词前，最好能回答一个简单问题：这次改动是为了解决哪类失败？是格式不稳定，还是事实依据不足？是语气不合适，还是拒答边界不清？如果目的说不清，提示词就会变成一团愿望清单。
比较可维护的做法，是把提示词拆成几个稳定部分：角色边界、任务说明、输出格式、证据要求、拒答条件、示例。改动时尽量只动相关部分，并记录原因。不是为了形式化，而是为了后面能知道哪次改动影响了什么。
坏例比灵感更可靠
提示词优化不能靠“我感觉这样写更好”。真正有价值的是坏例：哪些问题答偏了，偏在哪里，期望行为是什么，改完以后是否真的改善。没有坏例，提示词改动就像在黑箱上贴补丁。
坏例集也不能只放一种失败。结构化输出要有缺字段、字段类型错、夹杂解释文本的样本；知识问答要有资料不足、资料冲突、引用不匹配的样本；客服类任务要有敏感问题、边界问题、用户表达含糊的问题。提示词每次发布前，都要跑这些样本。
示例不是越多越好
少量高质量示例能帮助模型稳定格式和风格，但示例太多会挤占上下文，也可能把模型带向某些固定表达。尤其是业务规则经常变化时，把大量规则写进提示词，会让维护成本越来越高。
有些信息应该进知识库，有些规则应该进后端校验，有些格式要求应该由结构化解析和校验兜底。提示词适合引导模型行为，但不适合承担所有业务规则。把所有问题都塞进提示词，短期省事，长期会让系统很难解释。
结构化输出要有后端兜底
提示词里写“必须输出 JSON”不等于线上一定能拿到合法 JSON。模型可能多输出一句解释，可能漏字段，可能把数字写成字符串，也可能在异常场景下返回自然语言。
所以结构化输出要配合 schema 校验、解析失败重试、默认值策略和人工可读错误。提示词负责尽量让模型按格式生成，后端负责判断结果能不能被系统接收。这个边界讲清楚，面试时会比单纯说“我写了很强的 prompt”可信很多。
发布提示词也要留回滚口
提示词版本可以很轻量：版本号、改动原因、关联坏例、评测结果、上线时间。更复杂的系统可以按场景灰度，让一小部分流量使用新版本，观察解析失败率、用户反馈、人工接管率和成本变化。
如果新版本让某些关键问题变差，要能快速切回旧版本。不要把提示词直接写死在代码里，更不要让线上配置被多人随手改却没有记录。提示词越像线上逻辑，就越需要工程化管理。
一个更稳的表达方式
被问到 Prompt 工程时，可以这样说：我不会把提示词当成一次性文案。线上提示词会有版本，每次改动都对应具体坏例和目标；发布前跑评测集，覆盖格式、拒答、知识依据和边界问题；结构化输出由后端校验兜底；上线后观察失败率和用户反馈，必要时回滚。
这类回答不会显得追热点。它传达的是一个更重要的判断：大模型应用的可维护性，不只在模型本身，也在提示词、评测、校验和发布流程里。