當你要求 Codex 生成一張圖片時，為什麼有時它會回傳一個扁平的、像 SVG 一樣的繪圖，而不是真正的插圖？
你原本期待一張照片或插圖，但得到的卻是一堆簡單的幾何形狀。
「這就是 Codex 圖片生成能力的極限了嗎？」
我一開始也這麼想。我懷疑原因在於使用了「圖示」或「標誌」這類詞彙，導致 Codex 選擇用 SVG、HTML 或 CSS 來繪圖，而不是實際的圖片生成。
所以，我親身測試了一下，讓 Codex 實際運作看看。
我從 Claude Code 呼叫 Codex，並比較了以下「Before / After」的結果：
- Before：簡單地要求「建立一個簡單的貓咪圖示」。
- After：指定了圖片生成工具、主體、顏色、紋理、禁止事項以及儲存位置。
結果證實了我的懷疑。
簡短的請求回傳了一個扁平的貓咪圖示，實際上它是一個從 SVG 轉換過來的點陣圖，儘管副檔名是 PNG。
另一方面，明確指定了圖片生成工具和完成條件的請求，則產生了一張豐富的圖片，包含一隻拿著麥克風的貓咪、藍色圓形邊框、黃色背景，甚至還有散景效果。
簡而言之，這次驗證揭示了以下幾點：
透過不僅傳達主體，還要傳達使用圖片生成模型、避免使用 SVG 替代方案，以及顏色和紋理等細節，你可以改變 Codex 創造圖片的方式。
在這篇文章中，我將根據 OpenAI 的官方資訊以及 2026 年 7 月 13 日的實際測量結果，整理如何在 Codex 中建立你想要的圖片。
結論先行
以下是重點摘要：
- Codex 可以生成照片和插圖，但它也可以使用 SVG、HTML 和 CSS 來建立視覺元素。
- 即使副檔名是 PNG，內容也可能是從 SVG 轉換而來的圖片。
- 當你想要照片或插圖時，在提示詞中加入
$imagegen可以明確地呼叫圖片生成技能。 - 品質的差異來自於「用途、主體、風格、構圖和限制條件」，而不是提示詞的長度。
- 詳細規格的價值在於讓構圖更容易根據其預期用途重現，而不僅僅是讓它看起來很花俏。
- 不要期望一次就完美，透過指定要修改的內容和要保留的內容，逐一修正各個元素。
如果你想立即嘗試，請在你的請求開頭加入以下這段話：
──────── 可直接複製貼上 ────────
使用 $imagegen 並利用圖片生成模型生成一張點陣圖。不要使用 SVG、HTML、CSS 或 Canvas 來替代。
──────────────────────
然而，並不是只有這一句話就夠了。透過傳達「這張圖片的用途是什麼」以及「什麼樣的標準才算合格」，Codex 才能最終按照與你相同的標準來檢查圖片。
為什麼它會輸出 SVG 而不是圖片？
Codex 並非一個專門的圖片生成服務。它會編寫程式碼、讀取現有檔案、修復網站，並在需要時處理 SVG、HTML、CSS 和 Canvas。這是一個很大的優勢。
例如，如果一個網站有現有的 SVG 圖示集，而你想新增一個具有相同線寬、顏色和大小的圖示，那麼編輯現有的 SVG 會比使用圖片生成模型建立 PNG 更準確。
另一方面，文章標題圖、照片風格的視覺元素、有紋理的角色以及廣告橫幅，則更適合使用圖片生成而非程式碼。
Codex 目前的 imagegen 技能也能區分這兩種情況：
- 它會使用圖片生成來處理適合點陣圖像的任務，例如照片、插圖、紋理、精靈圖和原型圖。
- 對於編輯現有 SVG、向量或程式碼素材更好的任務，它會優先處理。
關鍵在於，這並非僅由「圖示」或「標誌」這類詞彙機械式地決定。
即使是同一個圖示，也有兩種不同的使用方式：
- 在 UI 中使用的可縮放向量元件。
- 在社群媒體上使用的、具有紋理和陰影的裝飾性單張圖片。
如果請求不明確，Codex 會根據專案中的現有檔案或周圍的上下文來猜測你想要哪一種。當這個猜測偏離了你的意圖時，你就會遇到「想要照片卻得到類似 SVG 的東西」這種情況。
因此，問題的本質不在於「禁止使用『圖示』這個詞」。而是 「你期望的輸出格式沒有傳達給 Codex。」
從官方資訊可以確認的事項
在 Codex 圖片生成中，會出現三個相似的名稱，但它們的含義不同：
$imagegen：明確呼叫 Codex 圖片生成技能的名稱。image_gen：Codex 內建的圖片生成工具的名稱。gpt-image-2：當透過 API 或備用 CLI 直接指定模型時的模型 ID。- 「Image 2.0」或「GPT Image 2 equivalent」：用來傳達高品質圖片的術語，而非執行時的正式模型 ID。
對於一般的圖片生成，基本方法是使用 $imagegen 呼叫技能，然後使用內建的 image_gen 工具。在這個路徑中，你不需要單獨的 OPENAI_API_KEY。
直接將 gpt-image-2 指定為模型 ID，是當你明確使用 API 或備用 CLI 時的情況。這個路徑需要一個 OPENAI_API_KEY。
此外，有效的圖片提示詞遵循以下原則：
- 具體傳達用途、主體、背景、構圖、風格和限制條件。
- 寫出具體的細節，例如光線方向和位置，而不是使用「美麗」或「時尚」這類抽象詞彙。
- 修正時，一次改變一個元素，並重複你想要維持的條件。
- 將圖片中的文字用引號括起來，並指定字型、顏色、大小和位置。
我們從中學到的是，$imagegen 是官方提供的、呼叫該技能的明確方式。這並不表示「沒有它你就絕對無法建立圖片」。然而，在我們的「Before」案例中，選擇了建立 SVG 而非圖片生成的路徑。它的作用是 讓使用圖片生成的意圖變得明確，而不是交由自動判斷來決定。
實際的 Before / After 比較
以下是實際的測量結果。我從 Claude Code 呼叫 Codex。使用的 Codex CLI 版本是 0.144.1，透過登入一個 ChatGPT 帳戶來執行，沒有新增 API 金鑰。
需要明確說明的是，這並非一個嚴格到只改變一個條件的對比實驗。在「Before」中，我只簡短地說明了我想製作什麼。在「After」中，我指定了生成工具、儲存格式、主體、顏色、構圖、禁止事項和品質。
換句話說，這是在經歷失敗後，當你指定了請求時，結果會有多大變化的 Before / After 比較。
Before：只要求一個「簡單的貓咪」
最初發送給 Claude Code 的請求就只有這樣：
──────── 可直接複製貼上 ────────
建立一個簡單的貓咪圖示
──────────────────────
我沒有指定圖片生成模型、PNG、SVG、顏色、紋理、背景或儲存位置。
而以下是回傳的結果：
檢查檔案後發現以下資訊：
- 檔名：
cat-icon.png - 格式：PNG, RGBA
- 尺寸：1024x1024 像素
- 位元深度：16 位元
- 檔案大小：約 121KB
- 外觀：一個由重疊的簡單形狀構成的扁平棕色虎斑貓臉。
這是一個在淺黃色圓形背景上放置大型貓臉的構圖。表情很可愛，並且符合「簡單的貓咪圖示」這個請求。
換句話說，Codex 並沒有忽略指示。相反地，問題在於請求太簡短，無法傳達我所期望的「由圖片生成模型完成的、帶有紋理的插圖」。
在同一個資料夾中也建立了一個 cat-icon.svg 檔案。此外，PNG 的中繼資料包含 SVG 元件，例如 svg:title 為「Cute brown tabby cat face icon」和 svg:comment 為「background」、「ears」、「face」、「eyes」和「collar」。
這表示 Codex 將「簡單的圖示」解讀為對向量素材的請求，因此建立了一個 SVG，然後將其轉換為 PNG。
「Before」並非失敗，而是太過於照字面意思執行。 因為我只說了「簡單」，所以 Codex 就使用易於編輯的幾何形狀簡單地完成了它。
After：修正生成方法與最終圖片
接下來，我從 Claude Code 呼叫 Codex，並輸入了以下內容：
──────── 可直接複製貼上 ────────
mkdir -p ./images
codex exec -C "$(pwd)" -s workspace-write --skip-git-repo-check \
"使用圖片生成工具 (image_gen / gpt-image-2) 生成一張可愛的貓咪拿著麥克風的插圖，格式為 PNG，並儲存到 ./images/cat-mic.png。使用扁平可愛的上色風格、柔和的陰影與高光、藍色圓形邊框、背景色 #FDE68A 並帶有小星星和散景效果、強調色 #2563EB，貓咪的顏色為奶油色到橘色。以單張插圖的方式建立，不要使用 SVG 或 HTML/CSS 替代。不要包含文字或浮水印。品質設定為高。"
──────────────────────
這是實際使用的指令。然而，image_gen 和 gpt-image-2 並不是同一個東西的別名。如果你使用的是 Codex 的內建功能，現在推薦的寫法如下：
──────── 可直接複製貼上 ────────
mkdir -p ./images
codex exec -C "$(pwd)" -s workspace-write --skip-git-repo-check \
'使用 $imagegen 來呼叫內建的 image_gen 工具，生成一張可愛的貓咪拿著麥克風的插圖，格式為 PNG。使用扁平可愛的上色風格、柔和的陰影與高光、藍色圓形邊框、背景色 #FDE68A 並帶有小星星和散景效果、強調色 #2563EB，貓咪的顏色為奶油色到橘色。不要使用 SVG 或 HTML/CSS 替代。不要包含文字或浮水印。完成後，將生成的圖片儲存到 ./images/cat-mic.png。以高品質完成。'
──────────────────────
整個提示詞用單引號括起來的原因，是為了防止 $imagegen 中的 $ 被當作 shell 變數展開，從而將其直接傳遞給 Codex。
與「Before」的差異不僅在於文字變長了：
- 明確指出圖片生成工具
- 儲存為 PNG 格式
- 不使用 SVG 或 HTML/CSS 替代
- 主體是拿著麥克風的貓咪
- 扁平可愛的上色風格，帶有柔和陰影與高光
- 包含藍色圓形邊框
- 背景色設定為 #FDE68A
- 包含星星和散景效果
- 強調色設定為 #2563EB
- 貓咪顏色設定為奶油色 / 橘色
- 沒有文字或浮水印
- 品質設定為高
- 儲存位置固定為
./images/cat-mic.png
以下是生成的圖片：
實際的檔案資訊如下：
- 檔名：
cat-mic.png - 生成路徑：Codex 內建圖片生成工具
- 格式：PNG, RGB
- 尺寸：1254x1254 像素
- 位元深度：8 位元
- 檔案大小：約 1.74MB
圖片反映了奶油色到橘色的貓咪拿著麥克風、藍色圓形邊框、黃色背景、藍色星星和散景效果。毛髮和麥克風上有柔和的陰影與高光，作為一張完成的插圖，提供了比「Before」版本豐富得多的資訊。沒有出現文字或浮水印。
比較兩個結果學到的事
即使有相同的 PNG 副檔名，內容卻完全不同。
Before 和 After 的檔案都有 .png 副檔名。然而，Before 是一個從 SVG 轉換為 PNG 的圖片，而 After 則是由圖片生成工具直接建立的點陣圖像。你不能僅憑它以「PNG 格式交付」就判斷它是否使用了預期的生成方法。
Before 的結果對於其提示詞來說是正確的。
我在 Before 中要求的是「一個簡單的貓咪圖示」。回傳的結果確實是一個簡單的貓咪圖示。這並非 Codex 的能力不足，而是我的話語沒有對最終圖片的生成方式加以限制。
After 則指示了生成路徑。
在 After 中發揮作用的，並非「讓它更漂亮」這類模糊的請求。而是指定了使用圖片生成工具、不使用 SVG 替代、顏色、主體、背景、紋理和儲存位置。
品質的差異不能完全歸因於 image_gen。
在 After 中，我同時改變了主體、配色方案、陰影、背景和品質，以及生成工具。因此，視覺上的改善不能孤立地歸因於 image_gen 這個詞的效果。不過，它至少明確了意圖，即避開「SVG 轉 PNG 的路徑」，並轉向圖片生成模型。
不僅要傳達你想要什麼，還要傳達你希望它如何被製作。 這是從這次 Before / After 比較中學到的最重要的一課。
加入 $imagegen 的目的是什麼？
看到這些結果，你可能會想：「如果沒有它也能產生 PNG，那 $imagegen 是不是就不需要了？」
的確，如果請求明確是關於照片或插圖，Codex 可能會自動選擇圖片生成。然而，有幾個理由讓你應該明確指定：
- 減少路徑混淆：在一個有許多現有 SVG 或 UI 素材的專案中，Codex 可能會判斷編輯程式碼是更合適的做法。如果你需要的是單張圖片，明確指定圖片生成可以減少意圖的偏差。
- 標準化團隊內的請求：如果「圖片」、「圖示」和「橫幅」這些詞彙的定義因人而異，那麼輸出的結果也會有所不同。透過將
$imagegen和用途作為共同的規則，即使提出請求的人改變了，也更容易選擇相同的路徑。
- 更容易隔離失敗原因：如果你明確指定了圖片生成，但結果不佳，接下來要檢查的就是構圖、風格和限制條件。如果生成路徑不明確，你就無法知道是「圖片生成模型不好」、「它是用 SVG 製作的」還是「提示詞不明確」。
將 $imagegen 視為一個 用來固定執行方法的開關，而不是一個提升圖片品質的魔法咒語。
最短可用的提示詞
首先，請複製並貼上這個格式：
──────── 可直接複製貼上 ────────
使用 $imagegen 並利用圖片生成模型建立以下圖片。不要使用 SVG、HTML、CSS 或 Canvas 替代；將其生成為單張點陣圖像。
用途：X 個人資料圖片
主體：拿著麥克風的貓咪
風格：友善、具有深度感的 3D 插圖
構圖：正方形、置中，即使裁切成圓形主體也能保持完整
限制條件：無文字、標誌或浮水印
──────────────────────
你不需要把所有細節都寫出來。OpenAI 的官方指南也說明，對於圖片提示詞，1-3 句清晰易懂的句子通常就足夠了。重要的不是長度，而是包含那些決定成功與否的條件。
穩定圖片品質的 5 個項目
如果你對提示詞不太確定，只需寫下這五項：
- 用途：寫下這張圖片將被使用在哪裡。例如：X 貼文、個人資料圖片、部落格標題、LP 主視覺、產品介紹。當你寫下用途時，Codex 可以更容易地判斷所需的構圖和邊距。
- 主體：寫下要畫什麼以及處於什麼狀態。例如：一隻拿著麥克風的棕色虎斑貓、一位正在使用筆記型電腦的女士、放在桌上的咖啡。
- 風格：指定所需的質感，例如照片、插圖或 3D。例如：具有自然光的寫實照片、雜誌風格的編輯插圖、柔和的水彩、具有深度感的 3D。
- 構圖：寫下長寬比、主體的位置和所需的邊距。例如：橫向、人物在左側、右側保留寬邊距以放置標題。在我們的 After 範例中，「藍色圓形邊框」的指示導致了貓咪和麥克風被包含在圓形內的構圖。
- 限制條件：寫下你不想包含的內容以及必須遵守的條件。例如：無文字、無標誌、無浮水印、不要讓背景太複雜。
有了這五項，Codex 不僅能「製作一張圖片」，還能檢查它「是否符合用途」。
按用途分類的複製貼上範例
文章標題圖片
──────── 可直接複製貼上 ────────
使用 $imagegen 為一篇部落格文章生成一張橫向的標題圖片。製作成一張寫實照片，畫面是放在木頭桌上的筆記型電腦和咖啡，在柔和的自然晨光中拍攝。將主體靠左對齊，並在右側保留寬邊距以放置標題。不要包含文字、標誌或浮水印。不要使用 SVG、HTML 或 CSS 替代。
──────────────────────
X 貼文正方形圖片
──────── 可直接複製貼上 ────────
使用 $imagegen 為一則 X 貼文生成一張正方形的插圖。用友善的編輯插圖風格來表現「AI 和人類在同一張桌子上協作提出一個計劃」的場景。將人物和 AI 裝置放在畫面中央，採用即使在智慧型手機的時間軸上觀看，主體也很清晰的構圖。使用藍色和橘色作為基底色，不要包含文字、標誌或浮水印。
──────────────────────
LP 主視覺圖片
──────── 可直接複製貼上 ────────
使用 $imagegen 為一個線上商業工具的 LP 生成一張主視覺圖片。製作成一張自然的照片，畫面是一個小型團隊在明亮的辦公室裡，邊看著大螢幕邊討論。採用橫向構圖，人物靠右對齊，在左側保留邊距以放置標題和按鈕。不要使用過度未來感的表现、文字、公司標誌或浮水印。
──────────────────────
含有日文文字的圖片
──────── 可直接複製貼上 ────────
使用 $imagegen 為一則 X 貼文生成一張正方形圖片。僅在畫面正上方中央放置文字「AIで仕事が変わる」（AI 改變工作），使用大型、粗體、白色的哥德體字型。文字應為單行、置中對齊。不要新增任何其他文字、標誌或浮水印。背景應為從深藍色到紫色的漸層，營造適合商業用途的沉穩設計。
──────────────────────
在圖片中放入文字時，請遵循以下三點：
- 將要顯示的文字用引號括起來。
- 指定字型、顏色、大小和位置。
- 告訴它不要新增任何其他字元。生成後，在發布前檢查每一個字元。
修正時，寫下「要改變什麼」和「要保留什麼」
當第一張圖片已經接近你的要求時，你不需要從頭重寫整個提示詞。事實上，一次改變太多反而會改變你喜歡的部分。請一次只修正一個元素。
- 保持構圖不變，但讓背景更亮一些。
- 保留人物和桌子，但將馬克杯換成一盆室內植物。
- 維持顏色和光線，但將右側的邊距加寬。
- 保留貓咪的表情和毛色，但讓麥克風稍微小一點。
OpenAI 的官方指南也建議在編輯時明確說明「要改變什麼」和「要維持什麼」。以下是一個可用的格式：
──────── 可直接複製貼上 ────────
請編輯所附的圖片。只改變背景。 將背景改為淺灰色。維持人物、服裝、表情、構圖、光線和色調完全與現在相同。 不要新增文字或標誌。
──────────────────────
透過寫下「只改變這個。不要動其他任何東西」，你可以減少整體圖片的偏移。
如果每次都寫很麻煩，就固定規則
當從 Claude Code 呼叫 Codex 時，每次都輸入相同的備註是很麻煩的。在這種操作中，建議先將圖片生成規則放在專案的 CLAUDE.md 中。由於 Claude Code 會讀取 CLAUDE.md，你可以在此處固定「當被要求生成圖片時，應如何向 Codex 提出請求」的規則。
如果是一個你直接使用 Codex 的專案，則將相同的想法放在 AGENTS.md 中。AGENTS.md 是 Codex 端會讀取的專案規則。
──────── 可直接複製貼上 ────────
圖片生成規則
- 在建立照片、插圖、橫幅、主視覺圖片或社群媒體貼文圖片時，使用
$imagegen。 - 如果要求的是點陣圖像，不要使用 SVG、HTML、CSS 或 Canvas 替代。
- 在生成之前，先整理好用途、主體、風格、構圖和限制條件。
- 僅在為現有的 SVG 圖示集新增圖示時，才編輯 SVG 以符合現有格式。
- 將完成的圖片儲存在專案內，並報告儲存位置。
──────────────────────
這個規則的目的不是要永遠禁止使用 SVG。而是要根據用途來選擇：UI 元件使用 SVG，完成的單張圖片則使用圖片生成。
有必要將其做成一個技能嗎？
你不需要為了生成圖片而建立一個新的技能。Codex 已經有了一個 imagegen 技能。當你想要標準化跨多個專案的流程時，建立自訂技能才變得有價值，例如：
- 每次套用品牌顏色或藝術風格。
- 根據用途自動選擇構圖，例如用於 X、文章或 LP。
- 在生成後檢查文字、邊距、大小和禁止事項。
- 統一檔案名稱和儲存位置。
- 如果失敗，根據相同的標準套用修正。
判斷方式很簡單：
- 在單一專案中使用的規則：
CLAUDE.md - 給 Codex 直接遵循的專案規則：
AGENTS.md - 一個可以跨多個專案重複使用「生成 -> 確認 -> 儲存」的機制：自訂技能
你不需要一開始就建立一個技能。從 CLAUDE.md 開始，當你發現自己重複同樣的步驟三次以上時，再考慮將其做成一個技能。
SVG 是正確答案的情況
雖然我已經說明了如何呼叫圖片生成，但 SVG 本身並沒有不好。SVG 更適合以下用途：
- 為現有的 UI 圖示集新增一個新圖示。
- 即使在縮放時也能保持線條清晰。
- 可以使用 CSS 改變顏色。
- 可以用數值精確管理形狀和線寬。
- 可以將差異作為程式碼來審查。
相反地，圖片生成適合：
- 照片風格的視覺元素。
- 需要毛髮、布料或金屬等紋理的插圖。
- 廣告或文章的吸睛元素。
- 帶有角色或故事性的單張圖片。
- 傳達氛圍或情感的視覺元素。
判斷的標準不是「SVG 或 PNG」。而是 「它是需要被確定性管理的元件，還是優先追求表現力的單張圖片？」 在向 Codex 提出請求之前決定這一點，將會減少路徑上的偏差。
這次驗證中修正的 3 個常見誤解
最後，這是我因為實際嘗試而得以修正的幾個要點。
誤解 1：如果是 PNG，就是用圖片生成模型做的。
這次的初始圖片是 PNG，但其中繼資料包含了 SVG 的標題和元件。其外觀也是簡單形狀的組合，因此判斷它是一張從 SVG 轉換為 PNG 的圖片。你應該檢查的不僅僅是副檔名，還要看它是透過什麼路徑建立的，以及其實際的外觀。
誤解 2：加入 `$imagegen` 會提升圖片品質。
這次的「After」版本在外觀上比「Before」版本豐富得多。然而，我同時指定了麥克風、配色方案、陰影、背景、構圖和品質。明確指出圖片生成工具會固定生成路徑，但僅憑這一點並不能保證最終結果符合你的喜好。你還需要那些決定外觀的條件，以及用來判斷是否符合用途的合格標準。
誤解 3：提示詞越長越好。
「After」之所以變得更好，並不是因為字數增加了。而是因為它包含了會決定結果的條件：圖片生成工具、禁止使用 SVG、主體、配色方案、背景、紋理和儲存位置。寫下判斷所需的條件，而不是長度。
總結
當 Codex 回傳一張簡單的圖片時，首先要懷疑的不是圖片生成模型的效能。請檢查你的意圖是否已傳達清楚：你想要的是一個用於程式碼的向量元件，還是一張作為照片或插圖的、完成的單張圖片。
如果你想要的是單張圖片，首先加入這句話：
──────── 可直接複製貼上 ────────
使用 $imagegen 並利用圖片生成模型生成一張點陣圖。不要使用 SVG、HTML、CSS 或 Canvas 來替代。
──────────────────────
除此之外，再寫下用途、主體、風格、構圖和限制條件。
在此次實際測量中，當我只要求 Claude Code 製作一個「簡單的貓咪圖示」時，Codex 將其解讀為需要向量素材，並產生了從 SVG 衍生而來的平面 PNG。另一方面，透過使用 $imagegen 呼叫圖像生成技能，利用內建的 image_gen 工具，不採用 SVG 替代方案，並指定主題、配色、紋理、背景與品質，就更容易產出符合這些規格的成品插圖。
決定圖像品質的關鍵並非提示詞的長度。而是你是否不僅說明了要製作什麼，還說明了它的用途，以及什麼樣的狀態才算合格。 當你傳達了這些資訊，Codex 就不再只是個圖像生成器，而是一個能根據目的來創作與檢查圖像的生產夥伴。
先從在你平常的圖像請求中，加入一個「用途」與一個「合格條件」開始。光是這樣，就能讓你從碰運氣的圖像生成，變為能重現預期結果的圖像生產。
參考資料：
