S22-B01 · Spring AI 入门：统一调用与流式输出

适用读者：Java 团队要接大模型、但不想被某个厂商锁死的人。本系列第一篇。
前置：S07 ✅（Spring）、S20-B01（RAG 概念）。
口径：本机未引入 Spring AI 依赖，以下代码为结构示意（API 以官方文档为准）。
覆盖旧文：654(280) 205(42) 610(183) = 505 点。
覆盖扩展：E-S22-001（ChatClient 抽象）、E-S22-007（流式输出）。
下一篇：S22-B02 · 结构化返回与 Function Call。

1. 一句话结论

Spring AI 的价值是"把模型调用变成一个 Spring 风格的 Bean"：换模型只改配置，不改业务代码。这与 S04-B01 的"依赖注入"是同一种解耦。

// 业务代码只依赖 ChatClient 抽象
String answer = chatClient.prompt()
        .user("你好")
        .call()
        .content();

层面	变化时改哪里
模型厂商/型号	配置（`spring.ai.*`）
提示词	业务代码
工具/记忆	Advisor 链（B03）

2. 三个核心抽象（E-S22-001）

抽象	作用	类比
`ChatModel`	单次调用（底层）	JDBC 驱动
`ChatClient`	流式 API（推荐）	JdbcTemplate
`Advisor`	横切增强（日志/记忆/RAG）	拦截器/切面

"为什么优先用 ChatClient"：它提供 fluent API + Advisor 链，把日志、记忆、检索这些"每处都要做的事"变成可插拔的一层——这与 S07-B03 的 AOP 思路一致。

3. 流式输出（E-S22-007）

chatClient.prompt().user(q).stream().content()
    .subscribe(chunk -> System.out.print(chunk));   // SSE/WebFlux

注意	说明
首 token 延迟（TTFT）	流式改善的是"感知延迟"，不是总时长（S21-A03）
断连处理	客户端断开要停止生成，省 token
与 RAG 结合	检索必须先完成，再流式生成

判据："用户要等很久吗？" 要 → 流式；短回答 → 一次性返回更简单。

4. 配置化换模型的边界

能只改配置	必须改代码
模型型号、温度、max_tokens	提示词模板
API key / endpoint	工具定义
部分超时/重试	结构化输出的 schema

"为什么提示词不能只改配置"：不同模型对提示词敏感度不同（S19-B03）——换模型必须重跑评估（S20-J01）。

5. 五个误区

误区	真相
"Spring AI 能屏蔽所有差异"	提示词与工具行为仍有差异
"流式 = 更快"	只改善感知延迟
"换模型只改配置就行"	要重跑评估
"Advisor 只是日志"	记忆/RAG/审计都在这里
"直接用 ChatModel 更灵活"	会丢失 Advisor 链能力

6. 自检

Spring AI 解决了什么耦合？
三个核心抽象的分工？
流式改善的是哪个指标？
换模型时哪些必须改代码？
为什么优先用 ChatClient？

7. 下一篇

S22-B02 · 结构化返回与 Function Call

入门讲完，下一篇讲"让输出变成 Java 对象"和"让模型调你的方法"。

本篇属于系列《S22 · AI 工程落地实战》。旧文来源：A-654/205/610；扩展点 E-S22-001/007。代码为结构示意（未引入依赖）。