不是廠商通稿的商品描述

大多數目錄跑在幾百家店同用的供應商文案上。讀起來像規格表、轉化差，也沒給搜索引擎任何獨有的東西可收錄。

商品描述的工作停滯原因很可預測：寫好一條要二十分鐘，而目錄裏有兩千個商品。於是供應商數據源原樣導入。這同時是轉化問題和重複內容問題。Builder 和 Visibility 兩個 Agent 按商品逐個撰寫，取材於店裏已有的屬性與評價，按「依序回答購買問題」的結構組織。

取材於你已有的東西

好描述的原材料已經在你店裏——規格屬性、參數差異、顧客評價、退貨原因、客服問題。Agent 從這些出發而不是編造賣點，這正是產出準確、具體的原因。

顧客掃讀；模型抽取。同一種結構同時服務兩者——開頭一句説清這是甚麼、給誰用，然後是可掃讀的具體資訊，再是支撐細節。拖延答案的行銷文風同時傷害轉化和可檢索性。

每條描述按商品單獨撰寫，但遵循一致模式，目錄保持連貫。新商品自動繼承模式。源數據太薄、寫不出真話的商品會被標記給人，而不是用注水文字填滿。

Agent 逐個商品讀取屬性、規格、現有文案與評價。

基於真實數據逐商品生成描述，全目錄結構一致。

批准代表性樣本、調整模式，然後鋪滿目錄，新品自動繼承。

它會編造商品功能嗎？

不該，而且這是硬約束。Agent 從你的屬性數據和評價出發；源數據不足時標記給人處理，而不是生成貌似合理的規格。

商品描述該寫多長？

長到足以回答該品類的購買問題，一個字不多。數據線三行夠了，牀墊需要幾百字。固定字數目標是錯誤的直覺。

獨立文案真的有利排名嗎？

它移除的是一個具體傷害——和其他所有賣同款的零售商共享同一段文案，搜索引擎沒有理由偏愛你的頁面。它是必要條件，不是充分條件。

能寫多語言嗎？

能，而且是按 locale 撰寫而不是機器翻譯同一份原文，因為購買異議和用詞習慣因市場而異。

重建那些決定「訪問變訂單」的頁面，按承載的收入排序。

匹配買家搜索方式的標題——覆蓋官網、Google 與平台三個表面。

認真地做多語言銷售——本地化頁面、正確的 hreflang、按市場的 SEO。

把空空如也的分類網格變成能為高購買意圖詞排名的頁面。

接上店舖、分析與電郵行銷工具，設定目標，其餘交給 Agent 由頭到尾做完。免費方案可自備模型金鑰，即刻開始。