如果你問我，什麼時候第一次真正意識到「AI 不只是寫代碼的助手，而是一個能被你指揮的創作者」？
不是在 ChatGPT 寫文章的時候，也不是在 Copilot 自動補代碼的時候。而是那天，我用 Spring AI 調了一次智譜 AI 的圖像模型。
那一刻，我的感覺特別像你本來只是個程序員，突然學會了揮畫筆。
從“畫畫”説起：我們小時候都當過畫師
小時候上美術課，老師會説一句話：
“這次畫畫，不要求寫實，重在想象。”
於是你開始構思：
- 太陽要不要畫成笑臉？
- 房子要不要歪一點？
- 小人要不要戴頂帽子？
但真正下筆的時候，你會發現一個現實問題：
我腦子裏有畫面，但我手不聽話。
後來我們學編程了。情況幾乎一模一樣：
- 腦子裏有需求
- 邏輯很清楚
- 但實現成本很高
直到 AI 出現。而 智譜 AI 的圖像模型，就像是：你只負責“描述畫面”，剩下的交給一個永遠不手抖、永遠不嫌你囉嗦的畫師。
Spring AI + 智譜 AI：像請了個“職業畫師”
在 Spring AI 裏，智譜 AI 的圖像模型，本質上扮演的是一個角色：
ImageClient 圖像生成客户端
你只需要告訴它三件事：
- 你想畫什麼（Prompt）
- 你對畫面有什麼偏好（Options）
- 你用什麼身份來請它畫（API Key）
剩下的事，它全包。我們一點一點來拆。
智譜 AI 圖像模型是什麼？
如果用一句話來形容 智譜 AI 圖像模型：
一個擅長理解中文語義、風格穩定、工程友好的 AI 畫師。
它特別適合三類場景：
- 生成插畫、封面圖、配圖
- 產品原型、概念設計
- 內容平台（公眾號、博客、海報）
在 Spring AI 體系裏，它被標準化成了統一接口，你不用關心底層 HTTP、JSON、簽名算法。你只關心一件事：
我想讓 AI 畫什麼？
添加依賴：先把“畫師”請進門
故事講到這一步，我們要做的第一件正事是：把智譜 AI 接入 Spring 項目
Maven 依賴示例
這一步，就像是：你在通訊錄裏，加了一個叫“智譜·AI畫師”的聯繫人。
配置智譜 AI 憑證：告訴它你是誰
AI 不會隨便給陌生人畫畫。所以你得拿出“身份憑證”。
application.yml 配置示例
建議你把 Key 放到環境變量裏：
這一步，就像：你走進畫室，遞上一張會員卡
老師看了一眼，説：“行，坐這兒，説吧，想畫什麼。”
智譜 AI 圖像選項：你怎麼“指揮畫師”
真正有意思的地方來了。ZhipuAiImageOptions，決定了畫出來的東西是“隨手一畫”，還是“精心創作”。
你可以把它理解成：對畫師的詳細指示單
常用選項表（ZhipuAiImageOptions）
你會發現，這張表特別像什麼？
對，像是你給設計師寫的需求文檔：
- 尺寸多少？
- 風格偏寫實還是偏二次元？
- 要不要高清？
- 要幾張備選？
調用 ImageClient：真正開始“畫畫”
鋪墊了這麼久，終於到了最爽的地方。
1. 注入 ImageClient
2. 構建圖像請求
3. 生成圖片
4. 獲取結果
這幾行代碼寫完的時候，我心裏其實只有一個想法：
原來“畫畫”這件事，也可以像調用一個 Service 一樣簡單。
從工程角度看，這套設計有多舒服？
如果你是後端出身，一定會注意到幾個點：
- 接口統一
- ImageClient 不關心你用的是智譜、OpenAI 還是別的模型
- Options 強類型
- 不用記 JSON 字段，不用怕拼錯參數
- Prompt 即需求
- 文本即設計稿，需求即代碼
- 天然適合業務集成
- 自動生成封面
- 自動生成商品圖
- 自動生成內容配圖
一句話總結：
Spring AI 把“AI 能力”，變成了“工程能力”。
總結：AI 不是取代你，是放大你
我一直不太喜歡那種説法：“AI 會不會取代程序員？”
但我很認同另一句話：會用 AI 的程序員，一定會取代不會用 AI 的程序員。
Spring AI + 智譜 AI 圖像模型，不是讓你變成畫師，而是讓你擁有一個隨叫隨到、不會抱怨、理解你中文表達的“畫師搭檔”。
你負責想象，它負責實現。而這，可能正是我們這一代程序員，最幸運的地方。
END
老規矩，點個在看，我們下篇繼續聊。
我是小米，一個喜歡分享技術的31歲程序員。如果你喜歡我的文章，歡迎關注我的微信公眾號“軟件求生”，獲取更多技術乾貨！
