把 NanoBanana MCP 接進 Claude Code：一句話生整套 IG 圖文，重點是 workflow 被打通了
核心觀點
這篇 Threads 真正有價值的，不是「AI 生圖很方便」這種表層結論，而是：
把圖片生成能力直接接進 Claude Code，再封裝成可重複使用的 Skill。
作者原本研究 Threads 上那些漂亮的 IG 圖文怎麼做，發現主流做法大概是三種：
- Canva
- Figma
- HTML 截圖
但他走的是第四條路：
- 在 Claude Code 裡打一段話
- 透過 NanoBanana MCP 呼叫 Gemini 圖像模型
- 直接產出整套 IG 圖文
- 再把整個流程寫成 Claude Code Skill
這代表重點不只是「生圖」，而是把生圖變成工作流裡的一步。
NanoBanana MCP 在這裡扮演什麼角色
Threads 裡解釋得很清楚：
- MCP = Model Context Protocol
- 本質上是讓 AI 接外部工具的橋梁
- Claude Code 本來就會讀寫檔案、跑終端機
- 裝了 MCP server 後，就能把更多外部能力納進同一個工作流
而 NanoBanana MCP 的作用，是把 Google Gemini 圖像生成能力 接進 Claude Code。
也就是說，之後你在終端機裡不是只能：
- 寫程式
- 改檔案
- 跑指令
還能：
- 直接叫 AI 生圖
- 把圖存回本地
- 接著繼續排版、組內容、出圖文素材
為什麼這比「去網頁上生圖」重要
這篇留言區有一句回應點得很好：
真正有感的點是「不用離開終端機」。
這不是小事。
因為過去做圖常見流程會打斷專注：
- 開瀏覽器
- 登入
- 切到別的平台
- 下 prompt
- 等圖
- 下載
- 再切回原本工作流
每次切換都會打斷思考與節奏。
而當圖片生成被拉進 Claude Code 之後，整個流程就變成：
內容構思、文案、圖像、排版、輸出，都能留在同一條工作流裡。
這會讓圖片生成不再像外掛工具，而更像是開發 / 創作流程中的一個原生步驟。
真正的升級不在 MCP，而在 Skill 封裝
如果只接上 MCP，你還是得每次重講一次流程。
這篇最值得學的其實是下一步：
把整個流程封裝成 Skill。
作者做的不是「今天成功生了幾張圖」，而是：
- 先把生成流程跑順
- 再把這條流程寫成 Claude Code Skill
- 讓未來只要一句話，就能出一整套 IG 圖文
這個思路非常重要，因為它代表：
一次性的折騰，被轉成可重複執行的資產。
這類 workflow 特別適合什麼場景
這種做法最適合：
- IG carousel / 社群圖文
- 知識型貼文配圖
- 教學圖卡
- 重複格式的品牌內容
- 高頻率內容生產
原因是這些東西通常：
- 結構固定
- 風格可模板化
- prompt 可優化
- 很適合做成半自動流水線
換句話說，這不是取代設計師，而是把大量「夠好就行」的素材製作工作壓到非常低成本。
這篇對 AI workflow 的更大啟示
這篇最值得記住的一句話不是 NanoBanana，而是：
與其每次重新設定，不如把重複流程封裝成 skill，把精力留給 prompt 本身。
這其實就是 AI 時代工作流設計的核心：
- MCP 把外部能力接進來
- Skill 把流程固化下來
- 人類只保留高價值判斷與創意部分
所以這篇不只是生圖案例，而是一個很好的示範：
當工具接口標準化後，真正的競爭力會從單次操作，轉移到 workflow 封裝能力。
需要保留的現實感
當然，Threads 裡也有人直接說「圖一般」。這其實也提醒了一件事：
這套方法的重點不一定是做出世界級設計，而是：
- 快
- 可重複
- 可量產
- 與內容工作流深度整合
也就是說，它比較像是：
效率型內容產線工具
而不是單純追求單張圖極致美術品質的工具。
結論
這篇值得收，不是因為 NanoBanana 特別神，而是它示範了一條很典型、也很重要的 AI workflow 路線：
- 用 MCP 把新能力接進 Claude Code
- 把生圖納入原本工作流
- 再用 Skill 把流程封裝成資產
最終的重點不是圖，而是：
當圖片生成不再是額外步驟，而是工作流的一部分，內容生產方式就會整個改變。