AI Listing Creator

先說我為什麼要做這個

在 Amazon 上架商品要寫一份「Listing」——標題、五條賣點、產品描述、一組圖片。它寫得好不好，直接決定商品能不能被搜到、被推薦、被下單。

老辦法是「抄爆款 + 堆關鍵詞」：把同類目賣得好的標題抄過來改改，再把能想到的搜索詞全塞進去。這條路正在失效，因為 Amazon 換了裁判。

Rufus — Amazon 的 AI 導購助手。買家現在可以直接問它「有沒有適合送給愛露營的爸爸的禮物」，它來決定推薦哪些商品。它讀得懂語義，關鍵詞堆砌對它不但沒用，還會被判定為低品質內容。

COSMO — Amazon 發表的意圖知識模型。核心思想：買家搜「瑜伽墊」，真正想要的可能是「在家練習不吵到樓下鄰居」。COSMO 把這種「商品 ↔ 買家真實意圖」的關聯整理成 15 種關係類型，例如 used_for_func（功能用途）、used_by（誰在用）、used_in_loc（在哪用）。

看懂這個轉變之後，我的問題就具體了，一共三個：

不知道買家為什麼買——我能列出產品有什麼功能，但說不出它覆蓋了哪些真實意圖。憑感覺寫，寫完心裡沒底
賣點寫完就散了——這次想出的好句子，下個產品又從零開始想，沒有地方沉澱
圖片沒有拍攝指令——Listing 要配 8 張圖（主圖、場景圖、A+ 圖），每張拍什麼、什麼構圖，全靠臨場發揮

類比

老辦法像把菜單上所有菜名喊一遍，希望客人聽到想吃的；新的做法是先弄清楚客人是誰、為什麼進店（意圖），再告訴他「你要的那道菜我有」。這個工具做的就是後者。

💡 一句話總結：Amazon 的搜索已經從「關鍵詞匹配」轉向「意圖理解」，寫 Listing 的方法必須跟著換。

它長什麼樣

以下是實際運行畫面。歷史記錄裡是真實生成過的兩份 Listing。

首頁：上傳產品圖與工作流程 — 首頁 — 拖一張產品圖進來，右側是六步工作流程說明

生成結果：標題與五點賣點 — 生成結果 · Listing 文案 — 277 字符標題 + 五點賣點 + 描述，右側是 Vision 提取的產品分析

COSMO 意圖覆蓋分析：彩色意圖卡 — COSMO 意圖覆蓋分析 — 每張卡一條買家意圖，顏色即關係類型：綠 = 功能、黃 = 場景、紫 = 人群。文案動筆之前，先把這張圖填滿

八張圖片拍攝 Prompt — 圖片 Prompt — 8 張圖各自的場景、比例、中文說明與英文生成指令，複製即可餵給生圖模型

歷史記錄：帶產品縮圖的卡片 — 歷史記錄 — 每張卡片帶當時上傳的產品圖，生成過的隨時找得回

💡 一句話總結：一張產品圖進去，一整套能直接上架的 Listing 素材出來，而且存得住、找得回。

它是怎麼運作的

五步一條鏈，中間那步是靈魂。

STEP 01

上傳產品圖

拖一張產品照進來。系統存檔並記下路徑——之後歷史記錄靠它認出「這是哪個產品」。

STEP 02

AI 看圖提取特徵

Gemini Vision 判讀圖片：這是什麼產品、什麼品類、有哪些看得見的特徵（三攝、磨砂黑、金屬邊框…）。

為什麼從圖開始而不是讓人填表？因為賣家最不缺的就是產品圖，最缺的是耐心填十個欄位。輸入門檻越低，工具越會被真的用起來。

STEP 03

推導 COSMO 意圖 ★

根據產品特徵，推導買家的真實意圖，並標上 15 種關係類型——「專業攝影能力」對應 used_for_func，「送給科技愛好者」對應 xWant。一個產品通常能推出 20 個以上。

這步是整個工具的差異點：不是「圖 → 文案」一步到位，而是先立一層「買家為什麼買」的中間層。下一節細講為什麼。

STEP 04

生成 Listing + 圖片指令

基於意圖清單產出：標題、五點賣點、描述、後台關鍵詞，外加 8 張圖的拍攝 Prompt（主圖 / A+ 圖 / 場景圖，各帶比例與構圖說明）。可選貼入競品資料做差異化。

賣點不是憑空寫的——每一條都要能對應回某幾個意圖。這讓「寫得好不好」第一次變成可檢查的事：拿意圖清單當驗收表。

STEP 05

落庫，隨時回看

整套結果連同產品圖路徑存進資料庫，歷史列表帶縮圖，點進去完整回看。也支援一鍵回寫飛書多維表格。

這步是後補的——最早的版本生成完就找不回來了。教訓見「踩坑」一節。

💡 一句話總結：圖 → 特徵 → 意圖 → 文案 → 落庫，中間多立一層，後面每一步都有了依據。

最關鍵的一個設計決定

為什麼不讓 AI 直接「看圖寫文案」，非要在中間立一層意圖？

因為直接生成的結果沒法驗收。AI 寫出來的東西通順漂亮，但你問一句「這條賣點為什麼這樣寫」，答案是「模型覺得好」——這跟憑感覺寫沒有本質區別。

做法	過程	結果
❌ 圖 → 文案一步到位	AI 看圖直接寫，理由藏在模型腦子裡	寫得通順但無法檢查；換個品類就風格漂移；本質還是高級版關鍵詞堆砌
✅ 中間立一層意圖	先產出 20+ 條帶類型標籤的買家意圖，再基於意圖寫文案	每條賣點都能回答「覆蓋了哪個意圖」；意圖清單本身可沉澱、可複用、可人工修正

類比

像蓋房子先出結構圖再砌牆。直接砌也能砌出一面牆，但你不知道它承不承重；有結構圖，每面牆都知道自己為什麼在那裡——而且下一棟房子，圖紙還能改改再用。

資料模型也是按「沉澱」設計的

六張表，不只存結果，還把過程資產分層存下來：

資料表	存什麼	白話說明
MyListing	我生成的 Listing	成品檔案：標題、賣點、描述、產品圖、版本
UserIntent	買家意圖庫	每條意圖帶 COSMO 關係類型，跨產品累積
SellingPoint	賣點話術庫	好句子按「出現位置 + 維度」分類存，下次直接調
CompetitorListing	競品拆解	對標競品的結構化檔案
ProductImage	產品圖庫	構圖分析 + 可借鑑點 + 生圖 Prompt
ReviewInsight	評論洞察	好評裡挖賣點、差評裡挖痛點

💡 一句話總結：中間層讓文案可驗收，資料分層讓經驗可複利——這兩件事才是工具的價值，生成本身反而是最便宜的一步。

它實際跑出來的東西

以下數據來自兩次真實生成（同一支手機的兩張不同產品圖）。

5 條

賣點 / 每份

20-22

COSMO 意圖 / 每份

8 張

圖片 Prompt / 每份

15 種

意圖關係類型全覆蓋

圖片 Prompt 的分工：Main（白底主圖，1:1）· Aplus（品牌故事橫幅，21:9）· Lifestyle（使用場景，16:9）——每張帶中文說明 + 英文生成指令，複製即可餵給生圖模型。

一條真實產出的意圖長這樣：

實例 · xWant

「To have a phone that captures professional-quality photos effortlessly」
（想要一支不費力就能拍出專業級照片的手機）→ 賣點第 1 條就從它長出來

💡 一句話總結：產出不只是一份文案，是「意圖清單 + 文案 + 圖片指令」三件套，每一件都能追溯到上一件。

做的時候踩過的坑

三個坑都是真踩過的，修復過程都留了痕。

坑 1 · 生成完就找不回來了

最早的版本只有「生成」，沒有「回看」——四個接口全是提交，沒有一個是讀取。生成完關掉頁面，那份 Listing 就等於丟了。

修法：補上歷史列表和詳情頁，生成結果全部落庫。

學到的：AI 應用的價值不在單次生成的那一下，在結果被存下來之後的累積。只出不進的工具，用一次就死。

坑 2 · 憑印象猜欄位名，全錯

做詳情頁時我憑印象猜資料欄位叫 prompt / position，實際定義是 prompt_en / scene——結果八張卡片全空，看起來像沒存資料，其實是沒讀對。

修法：打開類型定義檔逐字核對，一次修對。

學到的：有類型定義就讀類型定義，「看起來差不多」不算對比過。報錯位置也不一定是根因位置。

坑 3 · 圖片存了，但鏈路斷在中間

上傳的產品圖其實一直有存到硬碟，接口也把路徑回傳了——但前端拿到後沒往下傳，資料庫也沒有存它的欄位。兩頭都在，中間斷了，歷史記錄就成了「一堆認不出的產品名」。

修法：資料庫加一列、前端把路徑傳進生成流程、舊記錄按上傳時間戳回填配對。

學到的：資料鏈路要端到端驗證——「有存」和「用得上」之間，還隔著每一個傳遞環節。

💡 一句話總結：三個坑同一個主題——生成是最容易的，讓資料完整地流到該去的地方才是工程。

為什麼這頁只是展示，不是能用的網站

它是本地工具，跑在我自己的電腦上

它需要資料庫存生成記錄、硬碟存上傳的產品圖、以及必須放在伺服器端保管的 API 金鑰——這些在免費靜態託管上都跑不了。

與其部署一個點了沒反應的空殼，不如誠實說明：本頁是它的完整展示，實機可在面試中現場演示——當場上傳一張產品圖，跑完整條鏈路。

要搬上雲端需要換物件儲存、託管資料庫，為求職做這次重構不划算——知道什麼不值得做，也是工程判斷的一部分。