核心概念

第二章：核心概念与开发模型

点击这里👇🏻获取：100万QPS短链系统、复杂的商城微服务系统、智能翻译助手AI Agent、SaaS点餐系统、刷题吧小程序、商城系统、秒杀系统、AI项目、代码生成神器、苏三demo项目、智能天气播报AI Agent、智能代码审查AI Agent等 10 个项目的：项目源代码、开发教程和技术答疑

DashScope调用链路

2.1 先建立一个“可长期维护”的心智模型

很多团队把“大模型接入”当成一次性 SDK 调用：拼一个长 prompt，拿到字符串就结束。这样短期能跑，但长期一定会遇到这几类问题：

需求变复杂：要多轮对话、要结构化输出、要调用业务工具、要流式输出
线上不稳定：429、超时、解析失败，难定位也难治理
模型可替换性差：换模型就要大改代码

Spring AI（以及 Spring AI Alibaba）提供的价值就是：把模型调用从“散落的 HTTP”提升为统一的应用层抽象，让你把 AI 能力像数据库、缓存一样工程化治理。

2.2 ChatClient：你日常最常用的入口

最常见的使用方式就是：

String content = chatClient.prompt()
        .system("你是一个严谨的Java助手")
        .user("请解释一下什么是依赖注入")
        .call()
        .content();

你可以把它理解为：

system(...)：给模型的“角色与规则”
user(...)：当前用户输入
call()：发起一次请求（同步）
content()：取出最终文本

2.3 Prompt 与 Messages：不要只会拼字符串

当你开始做多轮对话、工具调用、结构化输出时，消息结构会越来越重要。一个实用的做法是把 Prompt 分成三层：

系统规则（稳定）：团队规范、输出风格、工具使用规则
业务上下文（变化）：用户身份、权限、场景、检索到的资料
用户输入（每次不同）：当前问题

这能让你在后期做治理时有抓手，例如：把“规则层”固化到 ChatClient 的默认 system；把“上下文层”变成可控的拼装逻辑；把“用户输入”保持干净。

2.4 Options：把“可调参数”从代码移到配置

常见可调参数包括：

model：不同任务用不同模型（对话、推理、成本）
temperature：越低越稳定，越高越发散
maxTokens：控制输出长度（也影响成本）

推荐优先用 application.yml 做默认值，例如：

spring:
  ai:
    dashscope:
      chat:
        options:
          model: ${DASHSCOPE_CHAT_MODEL:qwen-plus}
          temperature: 0.2
          max-tokens: 1024

然后在少数“特殊场景”按需覆盖，比如为某个接口设置更低的 temperature：

String answer = chatClient.prompt()
        .system("你是一个只输出结论的助手")
        .user(message)
        .call()
        .content();

2.5 一套代码兼容多模型：先把“依赖方向”设计对

在企业项目里，“模型供应商”应该是可替换的。推荐遵循这条原则：

业务代码依赖 Spring AI 抽象（ChatClient、EmbeddingModel、VectorStore）
供应商适配只出现在 starter 依赖与配置 中

这样你后续如果需要：

同一套代码从 DashScope 切到 OpenAI 兼容接口
或者按任务路由到 DeepSeek / OpenAI / Qwen

业务层大概率不用改，最多调整配置与依赖。

2.6 一个小练习：把“系统规则”固化成默认值

你可以创建一个 ChatClient Bean，把团队默认规则放进去，避免每次都写 system(...)：

package com.example.saa.config;

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class AiClientConfig {

    @Bean
    public ChatClient chatClient(ChatClient.Builder builder) {
        return builder
                .defaultSystem("""
                        你是企业级Java助手。
                        1) 不要编造信息；不确定就说明不确定。
                        2) 回答尽量结构化，先结论再解释。
                        3) 涉及安全与权限时，先提示风险与边界。
                        """)
                .build();
    }
}

2.7 本章小结

这一章的目标不是堆 API，而是建立长期可维护的开发模型：

用 ChatClient 统一模型调用入口
用 Prompt 分层管理上下文
用配置管理 Options，把可变因素从代码移出去
把供应商依赖收敛到 starter 与配置，给未来的“换模型/多模型路由”留空间

下一章我们会进入实战：用 DashScope（Qwen）写一个更完整的对话接口，并开始处理多轮对话的上下文组织问题。点击这里👇🏻获取：100万QPS短链系统、复杂的商城微服务系统、智能翻译助手AI Agent、SaaS点餐系统、刷题吧小程序、商城系统、秒杀系统、AI项目、代码生成神器、苏三demo项目、智能天气播报AI Agent、智能代码审查AI Agent等 10 个项目的：项目源代码、开发教程和技术答疑