求职派：深入拆解 Spring AI 提示词机制，从 Prompt、Message、PromptTemplate 到求职派 LlmCaller 封装

之前我们跑通了第一个 Spring AI 工程，大模型能正常回话了。

但把用户文本原封不动丢给模型，输出往往并不可靠。提示词是解决这些问题的关键钥匙，也是整个 Agent 系统的根基。

本篇内容第一版的作者：星球嘉宾灰灰。二哥做了二期的优化和迭代。

Spring AI 2.0 把提示词抽象成了 Prompt、Message、PromptTemplate 三层结构。包括身份注入处理、上下文管理、多模态消息、模型自动切换等。

这篇内容将从基础概念出发，逐步串联到求职派的真实源码，让大家搞清楚提示词是如何从 API 概念到生产落地。

01、Prompt 不只是一段文本

很多教程把提示词等同于“一段文本”。

在大模型的 HTTP API 层面，请求体里确实有个 messages 数组。但 Spring AI 把它抽象成了一个更丰富的对象，包含消息列表和调用参数。

public class Prompt implements ModelRequest> {
    private final List messages;
    private ChatOptions chatOptions;
}

messages 是一个消息列表，每条消息绑定一个角色。chatOptions 控制模型调用的行为参数，比如温度、模型名称。

这个设计和 OpenAI API 的 messages 数组直接对应，Spring AI 用 Java 的 class 对象把 JSON 结构封装了一层。

创建 Prompt 最简单的方式是 new Prompt("给我讲个笑话")，Spring AI 自动把文本包装成一条用户消息。

但真实项目里几乎不会这么用，因为缺少系统指令，大模型不知道自己该扮演什么角色，输出质量全靠运气。如果想指定调用参数，就要传入第二个参数 ChatOptions。

Prompt prompt = new Prompt(message,
    ZhiPuAiChatOptions.builder()
        .model("glm-5.2").temperature(0.7).build());

model 指定调用哪个模型，temperature 控制输出的随机性。

这两个参数几乎在每次调用时都会用到。搞清楚了 Prompt 的结构，下一个问题自然就来了，消息列表里的每条消息，角色是怎么分工的。

02、四种消息角色的分工

每条消息都有一个类型字段，和大模型定义的角色一一映射。

• system 负责系统指令，告诉大模型“该扮演什么角色、遵守什么规则”。
• user 承载用户输入，文本和图片都绑定到 user
• assistant 标记模型生成的内容，由框架自动管理
• tool 对应函数调...