本课目标

  • 理解三种消息角色的分工
  • 掌握 PromptTemplate 及其参数化
  • 建立提示词的工程化管理方式

上一讲模型说了第一句话。这一讲要解决一个更实际的问题：你不可能每次都手写 Prompt。一个面向真实用户的 AI 应用，提示词是资产——要版本管理、要回归测试、要团队协作。把 Prompt 当代码管，是本讲的核心主张。

核心内容

三种消息角色：一场戏三个演员

每次 API 调用不是发一句话，是发一组消息。每条消息有角色：

  • System（导演）：设定行为边界和回答风格。对整个对话全局生效。比如"你是一个严谨的 Java 代码审查员，只关注逻辑错误和性能问题，不评论代码风格"。
  • User（主角）：用户的输入。这是每次对话变化的那个变量。
  • Assistant（配角）：模型之前的回答，或你给的少样本示例。用来维持对话上下文。

System message 是全局的，但效果有上限。System 里写"你必须拒绝回答政治敏感话题"是必要的；写"你是一个有着 30 年 Java 经验的架构师，名字叫老张，喜欢喝咖啡时写代码"——后半句基本是浪费 Token，模型不会真的变成老张。

PromptTemplate：用变量替代硬编码

别在代码里拼字符串。Spring AI 的 PromptTemplate 支持 {参数名} 占位符，传入 Map 填充。模板是资源文件，参数是运行时数据。

工程上，模板作为 versioned resource 文件管理，配上回归测试：改一个模板 → 批量跑 50 条历史对话 → 看有没有退化。如果你只在脑子觉得"好像改好了"，那你其实不知道改没改好。

提示词管理的三个层次

  • 入门：代码里硬编码字符串（项目初期可以，超过 3 个 Prompt 就失控）
  • 进阶：模板文件 + 参数注入（本讲的推荐做法）
  • 专家：模板文件 + 版本管理 + 回归测试集 + A/B 对比（上生产的最低标准）

一个 Prompt 改了，是变好了还是变坏了？没有测试集的判断 = 抛硬币。