做到前面幾篇之後，我的 Tina-Sales-Page-Generator 已經從一張單純的銷售頁，慢慢變成一套比較完整的工作流程。

• 產品資料有 Product Input。
• 品牌有 Brand DNA。
• 頁面有 Page Plan。
• 多版本有 Strategy、Hero、Component、Variant。
• 圖片也有自己的 input/images、assets 與使用規則。
• 最後甚至可以直接打包 ZIP，上傳到 cPanel 上線。

照理說，做到這裡應該很開心。

但我腦袋馬上又冒出下一個問題：「那如果今天換一個產品呢？」

例如 Dosha 現在先做的是靚白防曬精華乳 SPF50。
如果下一支換成：海洋甦活美容液、全能極萃前導精華、雙效洗卸淨顏水、皙白淨顏慕絲，難道整套生成器都要重新做一次？

更進一步，如果今天不做保養品了，直接換成：現代心靈占星課程。

那原本 Dosha 的 Brand DNA 還能不能用？Page Plan 要不要全部換？圖片規則要不要換？Strategy 還能不能沿用？

這些問題，其實就是我做到這裡之後，最想搞懂的事情。

後來我才發現，真正的答案不是：「要不要全部重做？」

而是：「到底是哪一層變了？」

先講結論：換產品，不等於整套系統重做

如果一套生成器真的每換一個產品就要全部重建，那它其實就不太算生成器。

它只是：每次換產品，就重新做一個專案。

真正比較理想的狀態，應該是：哪些東西屬於整個品牌，就繼續沿用。哪些東西屬於這一支產品，就換掉。哪些東西只是這一版頁面的銷售策略，就另外調整。

也就是說，一個成熟的系統，應該是分層的。而不是所有東西全部綁在一起。

我現在會把銷售頁生成器拆成五層

為了讓自己比較好懂，我現在會把整套系統拆成五層。

層級	負責什麼	換產品時是否一定要改
Brand DNA	品牌個性、語氣、視覺與原則	同品牌通常不用全部改
Product DNA	這一類產品的核心特性與銷售邏輯	換產品類型時需要檢查
Product Input	這一支商品的真實資料	換商品就要換
Page Plan / Strategy	這一頁準備怎麼說	每個版本都可以改
Components / Layout	用哪些區塊呈現	依策略調整

這樣一拆開之後，問題就簡單很多。

Brand DNA：如果品牌沒變，很多東西其實可以沿用

先從最上層的 Brand DNA 開始。

上一篇以前我們已經談過，Brand DNA 負責的是：這個品牌是誰？它怎麼說話？它看起來應該像什麼？

例如 Dosha 的 Brand DNA，可能會包含：

• • 文案不要過度刺激
  • 避免恐嚇式語氣
  • 不要自行放大未提供的功效
  • 整體偏乾淨、有質感、日常保養感
  • CTA 不需要每一區都很強烈
  • 產品事實與品牌感要平衡

如果我今天只是從 Dosha 防曬換成 Dosha 海洋甦活美容液，這些東西其實大部分都還成立。

因為：品牌沒有換！所以 Brand DNA 不需要整份砍掉重做。

同一品牌換商品，Brand DNA 應該是「沿用為主，微調為輔」

例如：Dosha 防曬和 Dosha 美容液，在產品重點上一定不同。但品牌應該還是同一個人說話。

不能今天防曬很有質感，明天化妝水突然變成：「超狂補水！一擦爆水感！」這就跑掉了。

所以 Brand DNA 比較像：品牌共用的底層作業系統。

商品不同，但作業系統還是同一套。

那 Product DNA 又是什麼？

這個詞我一開始其實也容易跟 Product Input 混在一起。

後來我覺得可以這樣分。

Product Input 是這一支商品的具體資料。Product DNA 則比較像這一類產品本身的核心銷售邏輯。

例如防曬類產品，常見核心問題會圍繞：日常使用、SPF、清爽感、通勤與戶外情境、補擦、使用順序。

而化妝水類產品，核心問題可能變成：清爽度、保濕、早晚使用、濕敷、膚質、後續保養銜接。

這時候雖然品牌沒變，但產品的：「應該從什麼問題切入」已經變了。

這一層，我現在會把它理解成 Product DNA。

Product DNA 不是產品規格，而是「這個產品類型的思考方式」

舉例來說，同樣是 Dosha，防曬的頁面，常常很適合做：通勤、夏天、戶外、日常防護。

但如果換成前導精華，可能更適合：保養順序、前導概念、後續保養銜接、膚感、早晚保養流程。

這兩者 Brand DNA 一樣，可是 Product DNA 明顯不同。

所以換產品時，真正需要重新思考的，不只是產品名稱。

還包括：「這一類產品，消費者真正需要被理解的是什麼？」

Product Input：這一層則是每換一支商品就一定要換

Product Input 就比較簡單，因為它是具體商品資料。

今天做防曬，Product Input 是防曬。明天換化妝水，就一定要整包換掉。

例如：

防曬 Product Input	美容液 Product Input
靚白防曬精華乳 SPF50	海洋甦活美容液
防止曬傷、曬黑	清爽型日常保濕
清透不油膩	水潤、好吸收
通勤、外出	早晚保養、濕敷
防曬產品圖	美容液產品圖

這一層如果不換，才真的會出大問題。

因為 Product Input 就是：AI 目前到底在賣哪一支產品。

同品牌換商品：哪些可以沿用？哪些一定要換？

如果今天從 Dosha 防曬，換成 Dosha 海洋甦活美容液，我現在會這樣處理。

項目	處理方式
Brand DNA	沿用為主
品牌語氣	沿用
品牌禁用寫法	沿用
Product DNA	重新定義
Product Input	全部換成新商品
產品圖片	換成新商品素材
Product Truth Lock	重新建立
Page Plan	可沿用框架，但要重新評估
Strategy	可重新選擇
Component Library	大部分可沿用

這張表我覺得很重要。

因為它證明：換商品，不等於整個系統砍掉。

那如果從 Dosha 換成占星呢？事情就不一樣了

這就是第二種情況。

如果我今天不是換 Dosha 的另一支產品。而是整個換成：現代心靈占星課程。

這時就不是只有 Product Input 要換，因為品牌也已經不同。

Dosha 是保養品牌，占星課程是知識型、教育型、個人成長型商品。

兩者在：語氣、信任建立方式、CTA、內容深度、視覺、使用情境，全部都不一樣。

所以這時：Brand DNA 必須換。

Dosha 的 Brand DNA，不能直接搬去占星

例如 Dosha 可能重視：乾淨、日常保養、產品質感、肌膚使用情境。

但占星課程可能比較需要：理解關係、自我探索、學習感、老師專業度、課程內容架構，學完後能看懂什麼。

如果直接沿用 Dosha Brand DNA，會發生一個很好笑的結果！頁面看起來還是很漂亮，可是整個感覺像：拿保養品的說話方式在賣占星課。

這就是典型的：品牌層級沒有切乾淨。

所以跨品牌時，我現在會做「DNA Reset」

如果今天換的是完全不同品牌，我會先做一件事情：不要急著生成新頁面。

先把原品牌的核心設定清掉或停用。

然後重新建立新品牌的：

• • Brand DNA
  • Product DNA
  • Product Input
  • Product Truth Lock
  • 圖片素材
  • CTA 邏輯
  • 視覺方向

我現在會把這一步叫：DNA Reset。

它不是把整個專案刪掉。而是：把屬於原品牌、原產品的資料層重新切換。

最重要的一件事：不要讓舊專案資料污染新專案

這是我覺得 AI 專案最容易出現的問題之一。

例如原本做 Dosha 時，系統裡面一直存在：防曬、SPF50、清爽不油膩、保養、肌膚。

結果突然說：「現在換成占星課程。」

如果沒有做清楚切換，AI 有可能還會一直沿用舊專案裡的語氣與思考方式。

這就叫：Context Pollution，情境污染。

簡單講就是：舊資料還在影響新任務。

我現在會怎麼避免不同專案互相污染？

我目前會偏向讓不同品牌，至少有清楚獨立的資料結構。

例如：

projects/
│
├── dosha/
│   ├── brand-dna/
│   ├── products/
│   ├── images/
│   └── variants/
│
├── astrology/
│   ├── brand-dna/
│   ├── products/
│   ├── images/
│   └── variants/
│
└── other-brand/
    ├── brand-dna/
    ├── products/
    ├── images/
    └── variants/

這樣至少在邏輯上很清楚。

現在正在做 Dosha，就只讀 Dosha；換成 Astrology，就切去 Astrology。不要所有東西全部放在同一層。

如果還是在 Dosha 品牌內，可以用產品子資料夾

例如：

dosha/
├── brand-dna/
│
├── products/
│   ├── sunscreen/
│   ├── lotion/
│   ├── leading-essence/
│   ├── cleansing-water/
│   └── mousse/
│
└── components/

這樣 Brand DNA 可以共用。

但是每一支 Product Input、Product Truth Lock、產品圖片，都各自分開。

這就開始有：「一個品牌，多支商品」的感覺。

那 Page Plan 能不能共用？

可以共用「結構概念」，但不能機械式照抄。

例如我們原本有五區：故事入口、情境、Single Big Idea、產品事實、FAQ / CTA。

這個骨架其實可以拿去測不同產品，但不是每一支產品都一定適合。

例如占星課程可能更需要：問題共鳴、老師／課程定位、你會學到什麼、課程章節、適合誰、FAQ、報名 CTA。

所以 Page Plan 是：可以複用方法，但不能死守模板。

Strategy 則是最容易跨產品沿用的一層

這一點我覺得很有趣。像我們前面做的：

• • Scenario Story。
  • Education。
  • Problem Solution。
  • Premium Brand。
  • Editorial。
  • Diagnostic。

這些 Strategy 本身，其實不是 Dosha 專屬。

它們比較像：通用的銷售溝通方法。

例如占星課也可以做：Scenario Story。

先從：「為什麼每次談戀愛，我都遇到差不多的人？」進入。

也可以做 Education。先教：太陽、月亮、上升，各自在關係裡代表什麼。

也可以做 Diagnostic。讓讀者先回答幾個關係問題，再判斷自己真正想理解的是哪一塊。

所以 Strategy 庫，是很值得保留的。

Component Library 也不用每個品牌重做

像：FAQ、CTA、Hero、情境卡、比較表、流程區、課程章節卡、產品亮點卡，這些 Component，本質上很多都能共用，只要內容和視覺重新套新品牌就可以。

所以我現在會把 Strategy Library 和 Component Library 想成整個生成器裡比較「通用」的資產。

如果把整個系統比喻成換衣服，我現在會這樣理解

• • Brand DNA 是這個人的個性。
  • Product DNA 是今天這件商品的類型。
  • Product Input 是這件商品真正的資料。
  • Strategy 是今天要去哪裡、要怎麼說話。
  • Component 是衣櫃裡可以拿來搭配的單品。
  • Page Plan 是今天整套穿搭怎麼組。

換商品，不一定要換整個人。換品牌，才真的像是：換了一個人。

Dosha → Dosha：屬於「換商品」

例如：靚白防曬精華乳 → 海洋甦活美容液。

這種情況：Brand DNA 可以保留、Component Library 可以保留、Strategy Library 可以保留。

但：Product DNA、Product Input、Truth Lock、產品圖，都要更新。

Dosha → 占星：屬於「換品牌」

這時：Brand DNA 要重設、Product DNA 要重設、Product Input 要重設、圖片風格要重設、CTA 邏輯也應該重設。

但：底層生成框架、Strategy Library、Component Library，仍然可以繼續用。

這就是我開始想做「Generator」而不是「單一專案」的原因

如果每個品牌都從零開始，我永遠都只是在做一個又一個頁面。

但如果我把：品牌層、產品層、策略層、元件層、輸出層全部拆開。

那同一套系統，才真的有可能：今天做 Dosha、明天做占星、後天做另一個品牌，而不是每一次全部推倒重來。

我現在會怎麼切換新產品？

如果下一次再操作，我會用下面這個順序。

情況一：同品牌換商品

1. 1. 保留 Brand DNA
   2. 選擇新的 Product DNA
   3. 換掉 Product Input
   4. 重新建立 Product Truth Lock
   5. 更換 input/images
   6. 重新挑 Strategy
   7. 確認 Page Plan
   8. 生成新 Variant
   9. Final QA

情況二：直接換品牌

1. 1. 停止使用舊 Brand DNA
   2. 建立新的 Brand DNA
   3. 建立新的 Product DNA
   4. 建立新的 Product Input
   5. 重新建立 Truth Lock
   6. 更換圖片素材與視覺方向
   7. 從 Strategy Library 挑適合的策略
   8. 從 Component Library 挑適合元件
   9. 建立新的 Page Plan
   10. 生成與測試 Variant

這樣就不會有：「到底是不是全部重來？」這種很模糊的感覺。

哪些東西最值得做成共用資產？

做到這裡，我反而開始覺得，未來 Tina-Sales-Page-Generator 真正有價值的，不只是每一張頁面。

而是它慢慢累積出來的：

• • Strategy Library
  • Hero Library
  • Component Library
  • QA Checklist
  • Deploy Workflow
  • 圖片命名規則
  • Placeholder 規則
  • 文件分層規則

這些其實都能跨品牌使用。

品牌本身反而只是：套進這套系統的其中一層資料。

我現在最不想做的事情，就是「把舊品牌直接複製改名字」

這是我覺得很容易犯的錯。

例如把 Dosha 專案複製一份，然後把品牌名稱改成占星，看起來很快，但裡面可能還藏著：Dosha 的品牌語氣、保養品的產品思考、防曬的 Truth Lock、圖片命名、CTA、甚至某些 Internal Notes。

最後就會變成一個：表面是新品牌，骨子裡還是舊品牌。

所以我現在寧可：框架可以複製，但 DNA 要重新確認。

這也是為什麼「重置」比「全部重做」更準確

我現在不太會說：「換品牌要全部重做。」因為那聽起來像所有東西都沒用了。

其實不是。

比較正確的說法應該是：換品牌，要重置品牌層和產品層。

但是：生成器本身不需要消失，它還是可以繼續用。

Tina學姐這次最大的體會：AI 系統真正值錢的是「可替換」

以前我做網站時，做完就是一個網站。

現在做生成器之後，我反而開始在意：這一塊以後能不能換？品牌能不能換？產品能不能換？Strategy 能不能換？圖片能不能換？Hero 能不能換？

如果每一層都可以被清楚替換，那這個系統就會越做越有價值！因為未來新的商品進來，不是從零開始。

而是：把新的資料放進已經成熟的流程。

寫在最後：不是全部重做，而是換掉該換的那一層

做到第 13 篇，我覺得自己對「生成器」這三個字，開始有比較清楚的理解。

生成器不是：「我寫好一個 Prompt，以後一直複製。」也不是：「同一張頁面一直換產品名。」

真正的生成器應該是：有固定框架，也有可以替換的模組。

• • Brand DNA 可以換。
  • Product DNA 可以換。
  • Product Input 可以換。
  • Page Plan 可以換。
  • Strategy 可以換。
  • Component 可以換。

但是整套：產生 → 檢查 → 打包 → 部署 的流程，可以繼續存在。

所以換產品，真正要做的不是全部重來，而是先找出「到底是哪一層需要換」。

這個觀念一旦想清楚，我反而覺得未來不管是 Dosha、占星，甚至其他不同專案，都比較不會那麼可怕。