提示词在企业项目里怎么管：版本、测试与交接

提示词决定了模型在这个系统里的行为，改一个词可能让输出格式整个变掉。但在很多项目里，它被存在某个配置界面上，谁都能改，改了没有记录，出问题后无法回滚 —— 这是把核心逻辑放在了版本管理之外。

当作代码对待

• 进代码仓库，改动走正常的评审流程，而不是在后台直接编辑生效；
• 每次改动记录原因，因为半年后没人记得为什么加了某句约束；
• 能回滚到上一版，这在改坏了的时候是唯一的退路；
• 与模型版本一起记录 —— 同一段提示词在不同模型上的表现可能完全不同。

回归测试集是必需品

准备二三十组输入与期望输出，每次改提示词后全部跑一遍。目的是发现「修好了 A 却弄坏了 B」—— 这在提示词调整里非常常见，因为一段约束往往同时影响多种情况。

期望输出不必逐字匹配，可以用结构检查（字段是否齐全、格式是否合法）加上人工抽查。完全自动化的评判本身也会出错，但有一套固定的检查总比每次凭印象判断可靠。

写法上的几条

第一，明确输出格式并给出例子。要求返回结构化数据时，给一个完整的样例比用文字描述格式有效得多。

第二，把边界情况写进去。遇到材料不足怎么办、遇到多个候选答案怎么办、遇到无法判断怎么办 —— 不写，模型就会自行发挥。

第三，约束写成肯定句。「只输出 JSON」比「不要输出多余的解释」更可靠，因为后者需要模型理解什么算多余。

第四，不要把业务规则全部塞进提示词。能用代码判断的条件就用代码判断，提示词负责语言层面的任务。把审批阈值、价格计算这类确定性逻辑交给模型，既不可靠也无法审计。

交接时要留下什么

提示词本身、对应的模型与参数、回归测试集、以及一份说明：每段约束是为了解决什么问题。最后一项最容易缺失，而缺了它，接手的人要么不敢动，要么删掉一句看似多余的约束然后引发一堆回归。

这几项应当作为交付物写进验收清单，相关做法见AI 智能体解决方案与合作流程。