前面幾篇筆記，我已經一路做到產品銷售頁生成器、Product Input、Brand DNA、Page Plan，甚至開始替同一支產品規劃 V01～V10 不同策略的銷售頁。

做到這裡，我原本以為接下來應該就是：把產品圖放進去，然後讓 Codex 自己完成。

結果真正開始操作之後，我才發現：圖片這件事情，比我原本想像得麻煩很多。

因為「我已經把圖片放進專案」和「Codex 知道這張圖片要用在哪裡」，其實是兩件完全不同的事情。

甚至一開始，我明明已經有產品圖片，最後產出的網頁裡面還是全部出現：IMAGE PLACEHOLDER / 待提供：真實產品照或質地圖

我當時第一個反應就是：「奇怪，我不是已經有圖了嗎？」

後來一路查資料夾、看輸出檔案、重新整理專案，才慢慢搞懂：圖片不是丟進去就好，而是要讓整個專案知道它在哪裡、叫什麼名字、可以用在哪裡。

這一篇就來整理我自己實際操作後，終於搞懂的圖片流程。

第一個觀念：Codex 不會因為你「有圖片」，就自動知道怎麼用

這是我一開始最大的誤會。

我們平常使用 ChatGPT 或一些 AI 工具時，很習慣把圖片上傳之後直接說：「就用這張。」

可是做一個真正的網站專案時，邏輯完全不同。

因為 Codex 不是只需要「看見圖片」。

它還要知道：

• • 圖片存在專案的哪一個資料夾？
  • 檔案名稱是什麼？
  • 哪一張是產品主圖？
  • 哪一張是情境圖？
  • 哪一張是質地圖？
  • HTML 最後應該用什麼路徑呼叫？
  • 這個位置真的允許使用真實產品圖嗎？

所以我後來才明白：「上傳圖片」只是把素材交進來；「建立圖片規則」才是告訴 Codex 怎麼使用。

我這次的圖片，是放在 input/images

在 Tina-Sales-Page-Generator 專案裡，我後來自己建立了一個資料夾：input/images

一開始我的專案裡根本沒有這個 images 資料夾。

也是做到要放真實產品照時，我才發現：「咦？我要把圖片放去哪裡？」

所以後來才手動建立。

整個概念可以先簡化成這樣：

Tina-Sales-Page-Generator/
│
├── input/
│   ├── product/
│   ├── brand/
│   └── images/
│       ├── product-main.jpg
│       ├── product-side.jpg
│       ├── texture.jpg
│       └── lifestyle.jpg
│
├── output/
├── assets/
└── index.html

實際每個人的專案結構不一定完全一樣，但我這次最重要的概念就是：原始素材和最後輸出的網站素材，最好分開。

`input/images` 比較像：「我交給 Codex 的原始圖片庫。」

而最後產出的 `assets`，則比較像：「網站真正拿來顯示的圖片素材。」

input/images 到底是做什麼的？

我現在會把 `input/images` 理解成專案的：圖片入口。

也就是我把這次允許 Codex 使用的圖片，先集中整理到這裡。

這裡可以放：

• • 真實產品正面照
  • 產品側面照
  • 包裝照
  • 質地圖
  • 使用情境圖
  • 品牌素材圖
  • 必要的背景圖

但是我後來覺得，這裡有一個非常重要的習慣：不要把一堆完全不知道用途的圖片全部丟進去。

因為如果圖片越來越多，檔名又全部像：

• • `IMG_001.jpg`
  • `IMG_002.jpg`
  • `DSC00988.jpg`
  • `final2-new-new.jpg`

過一陣子不要說 Codex，我自己都搞不清楚哪張是哪張。

圖片檔名要讓「人」和「Codex」都看得懂

我以前整理圖片時，有時候真的會很隨性。反正我自己看縮圖知道是什麼就好。

但是做 AI 專案之後，我越來越覺得：檔名其實也是 Prompt 的一部分。

例如，同樣是四張圖片：如果叫：01.jpg、02.jpg、03.jpg、04.jpg 幾乎沒有任何資訊。

但如果改成：

• • dosha-sunscreen-main.jpg

  • dosha-sunscreen-packaging.jpg

  • dosha-sunscreen-texture.jpg

  • dosha-sunscreen-lifestyle-commute.jpg


光看檔名，就知道每一張圖大概應該用在哪裡。

我現在會建議檔名至少包含兩個資訊：產品＋用途。

用途	建議命名
產品主圖	dosha-sunscreen-main.jpg
包裝圖	dosha-sunscreen-packaging.jpg
質地圖	dosha-sunscreen-texture.jpg
通勤情境	dosha-sunscreen-commute.jpg
戶外情境	dosha-sunscreen-outdoor.jpg

這樣做的好處不只是給 Codex 看。

之後自己要找圖片、改 HTML、檢查 ZIP，也會快很多。

那 IMAGE PLACEHOLDER 到底是什麼？

這次我做銷售頁時，一開始圖片位置並沒有直接放假圖。

我們反而明確要求它：IMAGE PLACEHOLDER / 待提供：真實產品照或質地圖

我後來覺得這個設定其實很好。

因為如果沒有真實圖片，AI 最危險的做法不是空著。

而是：自己幫我「想一張」看起來像真的產品照。

這對一般插圖可能沒有關係。但是產品銷售頁就不同。

因為 AI 生出來的瓶身、包裝、LOGO、文字，很容易和真正商品不一樣。

最後消費者看到的可能根本不是實際商品。

所以我們乾脆規定：沒有真實素材，就老老實實標 Placeholder。

Placeholder 不是失敗，而是一個安全機制

我一開始看到整張頁面都是 Placeholder 時，其實會覺得：「這不是沒做好嗎？」

後來換個角度想，反而不是。它代表 Codex 有遵守規則。

因為它知道：這裡需要產品圖。

但目前沒有明確授權或可辨識的真實圖片。所以它沒有自己亂生。這對品牌頁面來說，其實是一件好事。

哪些地方一定要優先放真實產品圖？

這是我做了幾版之後開始很在意的問題。因為不是每一張圖片都一定要真實。

情境背景、抽象插圖、裝飾性素材，有時候可以用 AI 圖。

但是只要牽涉到「產品長什麼樣子」，我會優先使用真實圖。

尤其是以下幾個位置。

1. Hero 主產品圖

如果第一屏就要讓消費者看到產品，那最好就是實際產品照。

因為 Hero 是第一印象。

產品瓶身如果在第一屏就長錯了，後面再漂亮都沒有用。

2. 產品事實區

例如規格、容量、包裝、產品特色旁邊的圖片。

這種區域本來就是在建立信任。

使用真實商品圖會比 AI 想像圖更合理。

3. CTA 附近

如果已經走到「了解產品」、「立即購買」附近，消費者最好再次看到實際商品。

不然前面看的是一種商品，按購買前突然又看到完全不同的瓶子，信任感會掉很多。

4. 包裝與容量相關區域

例如 30ml、50ml、旅行組、禮盒這些。

只要是在幫助消費者理解「實際收到什麼」，真實圖片優先。

哪些圖片可以先用 AI 情境圖？

那是不是整張頁面都一定要拍實物？我覺得也不用。

像以下這些地方，我反而覺得 AI 圖很好用：

• • 上班通勤情境
  • 旅行情境
  • 戶外陽光
  • 桌面生活感
  • 保養氛圍圖
  • 抽象品牌氣氛圖
  • 教育型示意圖

例如我要表達：「每天早上出門前的防曬習慣。」

這時候畫面可以是一位女生準備出門、陽光從窗邊進來。

這張圖本身不需要出現 Dosha 真實瓶身。

甚至我反而會建議：AI 情境圖就不要硬塞一個假產品。

情境圖負責「氣氛」。真實產品圖負責「產品」。兩者分工反而比較自然。

我後來理解：圖片其實也要分層

這個概念跟上一篇的 Product Input、Brand DNA 很像。

圖片也可以分層。

圖片類型	用途	建議來源
產品事實圖	瓶身、包裝、容量、質地	真實產品照
生活情境圖	通勤、旅行、戶外、居家	AI 或實拍皆可
品牌氛圍圖	建立視覺情緒與質感	AI、攝影素材皆可
教育示意圖	步驟、概念、比較	AI 插圖或資訊圖

這樣我在規劃頁面時，就不會每一個圖片位置都問：「到底要不要用產品圖？」，而是先看這個 Section 在做什麼。

圖片放進 input/images 之後，Codex 還是不一定會自動使用

這也是我實際碰到的第二個坑。

我原本以為：「好，我已經把圖片放進 images 資料夾了。」，那下一次生成應該就會自己套進去。

結果不一定。

因為 Codex 還需要知道：這個資料夾裡真的有可以使用的圖片，而且這些圖片應該取代原本的 Placeholder。

所以如果原來的規則寫的是：「本區使用 IMAGE PLACEHOLDER。」

那你光把圖片放進去，原本的規則可能還是會繼續生 Placeholder。

所以真正要做的是：把任務講清楚。

例如：

請檢查 input/images 內的真實產品圖片。
若有可用的 Dosha 防曬產品主圖，
請優先使用真實圖片取代對應 IMAGE PLACEHOLDER。
不得重新生成或修改產品瓶身。

這樣才是「圖片素材＋使用規則」一起交給它。

真正上線時，圖片不能一直指向 input/images

這個也是我做到 ZIP、上傳 cPanel 時才比較清楚。

`input/images` 是工作區。

可是網站真正上線時，HTML 通常不應該還一直依賴這個 input 資料夾。

最終比較合理的結構會像：

dist/
│
├── index.html
├── styles.css
└── assets/
    ├── dosha-sunscreen-main.jpg
    ├── dosha-sunscreen-lifestyle.jpg
    └── dosha-sunscreen-texture.jpg

這時 HTML 裡面可能是：

<img src="assets/dosha-sunscreen-main.jpg"
     alt="Dosha 靚白防曬精華乳 SPF50">

也就是：input/images 是原始素材來源，assets 才是最後網站使用的檔案。

這兩個不要混在一起，我後來覺得會比較乾淨。

為什麼我特別在意「相對路徑」？

因為我的頁面最後不是放在 WordPress。

而是要打包成 ZIP，直接上傳到 cPanel 的子站。

這時如果圖片路徑寫成電腦裡的絕對位置，例如：C:\Users\Tina\Desktop\images\product.jpg


那一上傳到網站，當然全部壞掉。網站根本不知道我的 C 槽在哪裡。

所以最後一定要使用：相對路徑。

例如：assets/product.jpg


只要 `index.html` 和 `assets` 的位置固定，整個資料夾搬到 cPanel 之後，圖片還是可以正常顯示。

這也是我們後來做 Final QA 時，特別確認的一項。

我現在會怎麼整理一支新產品的圖片？

如果現在再來一次，我不會再像一開始一樣：先把圖片亂放進去，再問 Codex 為什麼沒抓到。

我會先整理。

第一步：先建立產品專屬圖片資料夾

input/images/dosha-sunscreen/

第二步：先把圖片按用途命名

dosha-sunscreen-main.jpg
dosha-sunscreen-packaging.jpg
dosha-sunscreen-texture.jpg
dosha-sunscreen-commute.jpg
dosha-sunscreen-outdoor.jpg

第三步：告訴 Codex 哪些是真實產品圖

例如：main / packaging / texture 為真實產品素材。
不得修改瓶身、Logo、標籤、顏色與包裝結構。


第四步：告訴它哪些位置可以使用 AI 情境圖

例如：

通勤、旅行、戶外、居家情境可使用非產品型情境圖。
情境圖內不要自行生成 Dosha 瓶身。

第五步：最後再要求輸出 assets

確保真正要上線的檔案，有一起被打包進最後的 dist 或 ZIP 裡。

這次我最容易犯的錯誤

回頭看，我覺得我一開始其實踩了好幾個很典型的坑。

錯誤一：以為圖片放進資料夾就完成了

其實還需要使用規則。

錯誤二：檔名沒有意義

自己現在看得懂，三個月後可能完全看不懂。

錯誤三：產品圖和情境圖混在一起

AI 不一定知道哪一張能拿來做 Hero，哪一張只能當背景。

錯誤四：看到 Placeholder 就急著刪

其實 Placeholder 很可能是在保護品牌，避免 AI 自己亂造商品。

錯誤五：只確認前台，不確認 assets

本機看得到，不代表 ZIP 上傳後一定看得到。

最後還是要檢查：圖片有沒有真的包進去、路徑是不是相對路徑、檔名大小寫有沒有一致。

我現在反而很喜歡 IMAGE PLACEHOLDER 這個做法

這件事很有趣。

我一開始最不喜歡看到的，就是：IMAGE PLACEHOLDER。

因為整張頁面做出來很漂亮，結果中間一堆 Placeholder，看起來就像半成品。

但現在我反而覺得它很好。

因為它清楚提醒我：「這裡還缺真實素材。」

而不是讓 AI 默默用一張看起來很像真的假照片混過去。

對我這種未來還要做 Dosha、占星、其他不同產品的人來說，這種規則反而比較安全。

Tina學姐這次最大的體會：圖片也是資料，不只是裝飾

以前我做網站時，圖片常常是做到後面才補。

文案寫完、版面排完、最後再找圖。

但是這次用 Codex 做銷售頁之後，我開始覺得：圖片本身也是 Product Input 的一部分。

• • 真實產品圖告訴 Codex：產品真正長什麼樣子。
  • 情境圖告訴頁面：我要讓消費者進入什麼生活。
  • 品牌圖告訴畫面：這個品牌應該有什麼感覺。

所以圖片不是最後才放進去的裝飾。它其實也是整個銷售頁系統裡的資料層。

寫在最後：把圖片整理好，後面多版本才真的有辦法自動化

做到第 10 篇，我開始越來越明白一件事情。所謂 AI 自動化，並不是什麼都不用整理。剛好相反。

前面的規則越清楚，後面才越能自動。

產品資料要整理、Brand DNA 要整理、Strategy 要整理、圖片也一樣要整理。

當圖片的：資料夾、檔名、用途、使用規則、輸出路徑

全部都整理好之後，Codex 才真的有可能在 V01、V02、V03……不同版本裡，穩定地重複使用素材。

不然每生成一版，我都還要重新找一次圖。那就不叫生成器了。只是換一種方式做人工排版而已。

所以這一次我學到的，其實不只是：「圖片要放在哪個資料夾。」

而是：想讓 AI 幫你做大量工作之前，先把素材整理成它可以理解、可以重複使用的系統。