在大模型应用的原型阶段，提示词往往直接写在代码里，谁觉得效果不好就改几句，改完看几个例子觉得不错就上线了。但当应用进入生产环境、服务真实用户时，这种做法会带来严重的问题：一次看似无害的修改，可能让某类请求的效果大幅下降；出了问题不知道是哪次修改导致的；多人同时修改相互覆盖。 提示词需要像代码一样被工程化管理。

为什么提示词需要工程化

  • 提示词决定产品行为：它对输出质量的影响，往往不亚于代码逻辑；
  • 修改的影响难以预测：调整一句话，可能改善了一类问题，却恶化了另一类；
  • 模型更新会改变效果：同一个提示词在新版本模型上的表现可能不同；
  • 多人协作需要规范：产品经理、工程师、领域专家都可能参与提示词的编写和修改。

实践一：版本管理

纳入版本控制

把提示词存放在独立的文件中，与代码一起纳入版本控制系统。每次修改都有提交记录，说明修改了什么、为什么修改。

明确版本标识

每个提示词版本有唯一标识，并在调用日志中记录使用的版本。这样当发现问题时，可以准确定位是哪个版本导致的。

记录关联信息

记录提示词版本与模型版本、参数设置的对应关系，因为同一个提示词在不同模型和参数下效果可能不同，参数调节见采样参数实用指南。

实践二：与代码解耦

使用模板

把提示词中固定的部分和动态的部分分开，用模板变量表示需要填充的内容，例如用户输入、检索结果、当前日期。

集中管理

把散落在代码各处的提示词集中到统一的目录或管理平台，便于查找、审阅和复用。

支持独立更新

对于需要频繁调整的提示词，可以考虑通过配置或管理平台更新，而不必每次都重新部署代码。但要确保这种更新同样经过测试和审批。

实践三：评测驱动的修改流程

这是提示词工程化最关键的一环。

建立评测集

为每个重要的提示词准备评测集，包括典型输入、边界情况和历史上出过问题的案例，并定义评判标准，方法见如何构建评测集。

修改前后对比

每次修改提示词，都在评测集上运行新旧两个版本，比较效果差异。不仅看整体分数，还要检查哪些案例变好了、哪些变差了。

自动化运行

把评测集成到持续集成流程中，提示词修改提交后自动运行评测，效果下降超过阈值时阻止合并。对于开放式输出，可以使用大模型辅助评分，参见 LLM-as-a-Judge。

积累回归案例

线上发现的问题案例，修复后加入评测集，防止同样的问题再次出现。

实践四：灰度发布与回滚

  • 灰度发布：新版本提示词先对一小部分流量生效，观察线上指标，确认没有问题后再逐步扩大范围；
  • A/B 测试：对于效果难以通过离线评测判断的修改，通过线上 A/B 测试比较用户反馈和业务指标，参见大模型应用的 A/B 测试；
  • 快速回滚：发现问题时能够迅速切换回上一个稳定版本。

实践五：团队协作

明确分工

  • 领域专家：定义什么是好的输出，提供示例和评判标准；
  • 产品经理：确定提示词要实现的产品目标和行为边界；
  • 工程师：负责提示词的工程实现、测试和部署。

评审机制

重要提示词的修改需要经过评审，评审时同时查看修改内容和评测结果。

文档化

为每个提示词记录：用途、设计思路、关键约束的原因、已知的局限和历史上的重要修改。避免后来者因为不理解某句话的作用而删掉它。

编写规范

制定团队的提示词编写规范，保持结构和风格一致，参见结构化提示词写法。

小结

提示词是大模型应用的核心资产，需要像代码一样工程化管理：纳入版本控制并记录版本，与代码解耦并集中管理，以评测驱动每一次修改，通过灰度发布和快速回滚控制风险，并建立清晰的团队分工和评审机制。这些实践能让提示词的迭代从凭感觉变成有据可依。