前阵子有个朋友找我吐槽，说产品经理提了个“听起来就很离谱”的需求：

“我们能不能输入一句话，就自动生成商品海报？最好风格还能切换，国潮、赛博朋克、极简风那种。”

我当时第一反应是：

这不就是“AI 画画”吗？

以前解决这类需求，大概有三条路：

设计师加班

买第三方平台接口

自建模型（然后被算力和调参折磨）

但现在不一样了。SpringAI 一出来，我心里想的是：

“这事，可能真能优雅地交给后端了。”

尤其是，当我看到 SpringAI 已经把 OpenAI 的图像模型 封装成了一个熟悉到不能再熟悉的 Client。这一刻，有点像当年第一次用 Spring RestTemplate 发 HTTP 请求。陌生的能力，被放进了熟悉的世界里。

OpenAI 图像模型是个什么东西？

先不急着上代码，我们聊清楚一件事：

OpenAI 图像模型，究竟能干嘛？

简单说，它可以做三件事：

文生图：给一句话，生成一张图片，比如：“一只穿着西装的柴犬，在办公楼里写 Java 代码”

图生图 / 编辑图片：在已有图片的基础上，让模型帮你“改一改”，比如换背景、换风格、补全缺失部分

风格理解与抽象表现：这是最有“AI 味道”的地方，同样一句话，选不同风格，出来的图完全不一样。

而 SpringAI 对我们的价值在于：

它不让你直接面对原始 HTTP、JSON、参数拼装

而是用 Java 的方式，把“生成图片”变成了一次方法调用

对后端同学来说，这真的太友好了。

添加依赖：熟悉的 Spring 味道

故事来到第二幕，我打开项目的 pom.xml，心情是非常踏实的。SpringAI 对 OpenAI 的支持是模块化的，我们只需要引入图像相关的 starter。

Maven 依赖示例：

如果你已经在项目里使用了 SpringAI 的聊天模型，那基本不用多想，图像能力就是顺带解锁。

这一步最大的感受是：

“AI 不再是一个额外系统，而是 Spring 生态的一部分。”

配置 OpenAI 凭证：别让 Key 成为事故源

接下来，是一个老生常谈但必须认真对待的事情——OpenAI Key 的配置。

1、application.yml 中的基本配置

是的，我强烈建议你用 环境变量。千万别把 Key 硬编码进配置文件，更别提交 Git。

2、顺带一提，真实项目中我一般这样做

本地开发：使用 .env 或 IDE 的环境变量配置

测试 / 生产：走 K8s Secret 或运维平台注入

AI Key，本质上和数据库密码一个级别。泄露的不是请求，是钱。

OpenAiImageOptions：真正的“控制台”

故事的高潮来了。你会发现，SpringAI 并不是“随便帮你生成一张图”，而是给了你一套非常清晰的图像配置模型 ：OpenAiImageOptions。

这个类，决定了图片的所有性格。下面我整理了一张最常用、最实战的属性表。

我第一次看到这个表的时候，内心 OS 是：

“这比前端调设计稿还细。”

但也正是因为这个粒度，你才真的能把“生成图片”这件事，做成一个稳定、可控、可复现的能力。

调用 ImageClient：像调用业务服务一样生成图片

终于，来到最“爽”的一步。SpringAI 提供了一个非常直观的接口：

ImageClient

你会发现，这一步没有任何“AI 特有的写法”。它和你调用一个普通 Spring Bean，没区别。

示例：生成一张图片

返回的 ImageResponse 中，你就能拿到图片的 URL 或 Base64 数据。那一刻，我非常清楚地意识到一件事：

AI 已经不是“试验性质”的功能，而是可以被正式纳入系统设计的能力。

一点真实的工程经验分享

写到这里，我忍不住多说几句“踩过坑后的心得”。

1、prompt，一定要当成“配置资产”管理

不要直接写死在代码里。需求一旦变了，你就会懂什么叫“AI 需求迭代比 UI 还快”。

2、图片生成要做好异步与限流

生成图片不是一个毫秒级操作，在高并发场景下，一定要：

异步化

限流

兜底图

3、不要迷信“一次生成完美”

AI 图像，本质是概率事件。真实业务里，多生成几张 + 策略选择，体验会好得多。

总结：后端的边界，真的在变

以前我们说后端是“数据 + 业务逻辑”。后来加上了搜索、推荐、风控。现在，又多了一个关键词：生成能力。

SpringAI + OpenAI 图像模型，让后端开发第一次可以这么自然地接入“创造力”。

如果你跟我一样，是个写 Java 的普通工程师，那你大概率也会有同样的感觉：

原来，后端也可以参与“创作”。

END

这就是我今天想分享的全部。

老规矩，点个赞，当给小米续杯咖啡~