前面幾篇 Codex 筆記，我一路從 Codex 安裝、智能體、Skill，到自動做影片、自動剪輯，再實際做出自己的第一個短影音 Skill。

做到這裡，我原本已經覺得自己跨了很大一步。

結果接下來真正讓我開始有「Codex 好像真的可以拿來做工作系統」這種感覺的，反而是我試著讓它幫我做產品銷售頁。

而且這一次，和做影片又完全不同。

如果有人說：「妳可以自己做一個產品銷售頁生成器。」

大家的第一個反應大概會是：「這不是程式設計師才做得到的事情嗎？」

可是這次真的一路做下來，我反而慢慢發現一件很重要的事。

我不一定要會寫程式，我真正要會的，是把我要的東西整理清楚。

這也是我這次製作 Tina-Sales-Page-Generator 時，學到最重要的一件事情。

我一開始最大的誤會：以為「做銷售頁」就是「寫網頁程式」

以前想到製作銷售頁，我腦袋裡首先出現的就是一堆程式問題。

標題怎麼寫？圖片怎麼放？按鈕怎麼做？手機版怎麼調？CSS 怎麼排版？圖片路徑要放在哪裡？HTML 要怎麼組？

光想到這些事情，我就會很自然地覺得：「這個工作真的很繁瑣。」

但真正開始使用 Codex 之後，我才發現它的工作方式，可以完全不是從「我要怎麼寫程式」開始。

如果今天我的要求只是：「請幫我寫一張漂亮的 HTML 銷售頁。」Codex 當然可以做。

但這樣做出來的東西，很容易只是一張一次性的網頁。

今天做防曬，從頭講一次。

下次做化妝水，再從頭講一次。

再換成前導精華，又重新說一次。

這跟我真正想做的事情，其實差很多。

我真正想要的是一套可以反覆使用的：產品銷售頁生成器。

也就是產品換掉之後，我不必把整個系統重新做一次，只需要把該換的資料換掉，Codex 就可以重新理解這個產品，再替我產生新的銷售頁。

做到這一步，我才開始理解：做銷售頁生成器時，真正重要的不是先寫 HTML，而是先把資料與規則分層。

而這一次，我最重要的三層，就是：Product Input、Brand DNA、Page Plan。

這三個名詞我剛開始看的時候，其實也不是馬上就懂。

但真正做完第一張 Dosha 防曬銷售頁之後，我終於比較知道它們各自在做什麼了。

Product Input：先告訴 Codex「這次到底要賣什麼」

Product Input，我現在會把它理解成：這一支產品本身的真實資料。

例如我第一個拿來測試的商品，是 Dosha 靚白防曬精華乳 SPF50。

那麼 Product Input 裡面應該放的，就不是：「我要高級一點。」、「我要畫面漂亮。」、「CTA 要明顯。」這些並不是產品資料。

真正屬於 Product Input 的，是產品名稱、產品用途、產品特色、規格、實際可以使用的圖片、已知使用情境，以及我們真正確認過、可以寫進頁面的資訊。

例如這支 Dosha 防曬，我們目前確定可以使用的資訊包括：

• • Dosha 靚白防曬精華乳 SPF50
  • 日常臉部防曬
  • 防止曬傷與曬黑
  • 清透、不油膩的使用感
  • 適合日常通勤、外出等使用情境
  • 真實產品圖片
  • 已提供並確認過的產品文字

這些，才是產品本身的「事實層」。

我後來特別加了一個 Product Truth Lock

這也是這次實作過程中，我覺得非常重要的一件事。

AI 很會寫文案。

但有時候就是因為它太會寫，如果沒有把邊界設定清楚，它會很自然地把文案補得非常完整。

問題是，保養品、食品、健康商品這一類產品，不是每一件事情都可以自己補。

例如 Product Input 沒有提供 PA 值，就不能自己生出 PA。

沒有提供抗水、抗汗，就不能因為這是防曬產品，就自己推論成「防水抗汗」。

沒有提供長效時數，就不能自己寫「長效 12 小時」。

沒有確認的成分、抗老、修護、美白功效，也不能因為文案讀起來比較完整，就自己加進去。

所以後來我們把這些產品事實，做成一層很重要的限制：Product Truth Lock。

也就是：哪些是已知事實，可以使用；哪些沒有資料，就不能自行發明。

這一步做完後，我對 AI 的理解也開始有一點不同。

以前我會覺得：「AI 應該什麼都知道。」

現在我比較會提醒自己：AI 不是我的產品資料庫，它是執行者。

產品真正的事實，還是應該由我們提供。

所以 Product Input 如果一開始就是錯的，後面頁面做得再漂亮，都沒有用。

Brand DNA：不是告訴 Codex「賣什麼」，而是告訴它「我們是誰」

第一次看到 Brand DNA 這個名稱時，我其實有點搞不懂。

因為我當時心裡會想：產品資料都放進去了，不就可以開始做頁面了嗎？

後來我才慢慢發現：Product Input 解決的是「這個產品是什麼？」

但是 Brand DNA 解決的是另外一個完全不同的問題：「這個品牌應該怎麼說話？」

同樣是一瓶防曬乳，不同品牌寫出來的銷售頁，可以完全不一樣。

• • 有些品牌偏醫美。
  • 有些品牌非常年輕、活潑。
  • 有些品牌會強調科技與成分。
  • 有些品牌喜歡非常強的促銷語氣。
  • 也有些品牌希望整張頁面乾淨、舒服、有質感。

產品可能很接近，但品牌個性不同，說話方式就不同。

Brand DNA 不只是顏色

我以前很容易把「品牌」想成 LOGO、顏色和字體。

但這次做到 Brand DNA 之後，我才發現，它其實更像是一份：品牌說話與呈現方式的說明書。

裡面可以包含：

• • • 品牌個性
    • 文字語氣
    • 視覺方向
    • 希望給消費者的感受
    • 哪些文案方式適合
    • 哪些文案方式不適合
    • CTA 應該強到什麼程度
    • 哪些字眼不要使用

例如 Dosha 並不是那種一直使用：「最後一天！」、「錯過就沒有！」、「史上最強！」、「你的肌膚正在被紫外線摧毀！」這種非常強刺激型文案的品牌。

所以即使 AI 很容易寫出這種高刺激銷售文字，我們仍然可以透過 Brand DNA 告訴它：這不是 Dosha 的說話方式。

我們最後比較喜歡的，是像：「每天出門前，留一點時間給日常防曬。」

它同樣在講防曬。可是整體語氣完全不同。

所以我現在會把 Brand DNA 理解成：讓 Codex 不只是知道產品，還知道這個產品應該用誰的聲音來說。

Page Plan：知道賣什麼，也知道怎麼說之後，才決定這一頁怎麼說服人

第三個我剛開始也搞不清楚的，就是 Page Plan。

第一次看到它時，我一直覺得：Page Plan 不就是版型嗎？

後來真正做了幾次之後，我才知道不太一樣。

Page Plan 比版型更前面。

它處理的不是：

• • 背景要紫色還是白色。
  • 圖片放左邊還是右邊。
  • 按鈕是圓角還是方角。
  • 這些比較偏視覺與 Component 層。

Page Plan 真正決定的是：這張銷售頁準備怎麼說服人。

Page Plan 就像整張銷售頁的劇本

例如我們這次替 Dosha 防曬先鎖了一套五段式結構。

• • • 第一區是故事入口。
    • 第二區進入沉浸式情境。
    • 第三區提出 Single Big Idea。
    • 第四區開始說明產品事實。
    • 第五區才進 FAQ 與 CTA。

這個時候，我們其實還沒有在決定每一個按鈕長什麼樣子。

Page Plan 更像是在安排：訪客進來後，第一眼看到什麼？第二段產生什麼感覺？什麼時候開始講產品？什麼時候把主要概念講清楚？什麼時候才出現 CTA？

這跟我以前做 SEO 文章其實很像。

文章不是把一堆資料全部丟上去就叫文章。

你還是會安排：前言怎麼進。第一段講什麼。重點怎麼展開。問題什麼時候回答。商品什麼時候出現。最後怎麼收尾。

銷售頁其實也是同樣的概念。

所以我現在會把 Page Plan 理解成：整張銷售頁的劇本。

Product Input、Brand DNA、Page Plan 到底怎麼分？

做到這裡，我覺得可以用一個最簡單的方法來記。

項目	它負責回答的問題	主要內容
Product Input	這次到底要賣什麼？	產品名稱、規格、特色、圖片、用途、可使用事實
Brand DNA	這個品牌應該怎麼說話？	品牌個性、文字語氣、視覺方向、禁用方式
Page Plan	這一頁準備怎麼說服人？	Section 順序、敘事邏輯、資訊節奏、CTA 路徑

• • Product Input 是產品本身。
  • Brand DNA 是品牌個性。
  • Page Plan 是頁面劇本。

這三件事情分開之後，後面的事情就突然清楚很多。

這三個東西最怕全部混在一起

這是我一開始最容易做錯的地方。

例如我們很容易一次跟 AI 說：「這支產品是 SPF50 防曬，要做得高級一點，第一屏放大圖，文案不要太誇張，按鈕放右邊，要有義大利品牌感，圖片要漂亮，後面再放 FAQ……」

看起來好像全部都講了。

可是其實這裡已經混在一起了：

• • 產品資料
  • 品牌規則
  • 頁面策略
  • 視覺要求
  • 元件要求

今天如果只做一張網頁，也許還能用。

但是一旦要做第二張、第三張，甚至同一支商品要做十種不同銷售頁，就很容易開始失控。

因為你不知道：哪些東西應該固定？哪些東西這一次可以改？哪些屬於品牌？哪些只屬於這一張頁面？

所以我們後來才越來越重視「分層」。

Product Input 原則上不應該隨便變

今天還是同一支 Dosha 防曬，產品名稱、SPF50、用途與產品事實，基本上不應該因為換一張銷售頁就跟著改。

這一層要穩定。

Brand DNA 也是品牌層級的穩定規則

今天只要還是 Dosha，品牌語氣、視覺個性與不能亂說的事情，大方向也應該一致。

真正可以大量變化的是 Page Plan

第一張，可以從日常生活情境進場。

第二張，可以走 Premium Brand。

第三張，可以走 Education。

第四張，可以走 Problem Solution。

第五張，可以改成 Multi Scenario。

產品沒有變。品牌沒有變。但是「怎麼講這個產品」，可以完全不同。

這就是我們後來開始規劃 V01～V10 的基礎。

我實際做 Dosha 防曬銷售頁時，是怎麼分工的？

如果把我這一次的操作簡化，其實可以拆成非常清楚的四個階段。

第一步：先準備 Product Input

先把 Dosha 防曬真正已知的資料整理出來。

包括：

• • • 產品名稱
    • SPF50
    • 產品圖片
    • 已確認的主要用途
    • 已確認的產品特色
    • 適合使用的生活情境
    • 可以使用的商品文字
    • 不能自行延伸的資訊

這是所有頁面共同的產品底層。

第二步：讓專案理解 Brand DNA

接著告訴 Codex：Dosha 希望呈現什麼樣的品牌感。

例如文案不要過度刺激，不使用恐嚇式銷售，不任意添加沒有依據的功效，整體希望乾淨、有質感，維持日常保養品牌的感覺。

這樣它在生成頁面時，就不會突然跑出完全不像 Dosha 的語氣。

第三步：決定 Page Plan

接下來才決定第一個版本要怎麼講故事。

例如我們第一個版本走的是：Scenario Story ＋ Single Big Idea。

所以 Hero 不急著一開始就列出一堆功能。

它先從生活進入。

最後我們才有了這一句：每天出門前，留一點時間給日常防曬。

然後再從生活情境一路把讀者帶到產品。

第四步：Codex 才真正開始組裝頁面

當前面三層都準備好之後，才輪到 Codex 處理：

• • • HTML
    • CSS
    • 區塊結構
    • 圖片位置
    • 產品資訊
    • FAQ
    • CTA
    • assets
    • 靜態頁面輸出

所以真正的順序其實不是：我要做網頁 → 開始寫 HTML。

而是：我要賣什麼 → 品牌怎麼說 → 這一頁怎麼說服 → 最後才變成網頁。

我覺得這個差別非常大。

不會寫程式，為什麼還是可以讓 Codex 做銷售頁？

做到這裡，我自己最大的感受就是：以前我們很容易把「會寫程式」和「可以做軟體、做網站」畫上等號。

但現在這件事情開始改變了。

我當然還是不會自己從零寫出完整的 HTML、CSS 和各種程式邏輯。

但是我可以告訴 Codex：

• • 我要解決什麼問題
  • 我要賣什麼商品
  • 資料放在哪裡
  • 什麼可以寫
  • 什麼不能寫
  • 品牌怎麼說話
  • 頁面要怎麼安排
  • 最後要輸出什麼

剩下原本需要程式能力才能實作的那一段，它可以幫我完成。

所以我現在反而覺得，非工程背景的人使用 Codex，最重要的未必是先去學寫 Code。

而是先練三件事情：拆問題、訂規則、驗收結果。

第一個能力：拆問題

不要只說：「我要一張漂亮的銷售頁。」

要開始問：漂亮是品牌感？是頁面版型？是圖片？是排版？還是文案？

把問題拆開，Codex 才知道怎麼處理。

第二個能力：訂規則

哪些可以自由發揮？哪些一定不能動？哪些是真實產品資料？哪些只是一種頁面策略？

規則越清楚，輸出通常就越穩。

第三個能力：驗收結果

Codex 做完，不代表工作就結束。

我們仍然要自己檢查：產品有沒有講錯？品牌有沒有跑掉？頁面邏輯有沒有順？圖片是不是正確？手機版有沒有問題？檔案路徑對不對？CTA 合不合理？

因為如果自己連「什麼叫做做對」都不知道，那 AI 再厲害，也只能一直猜。

我現在不想再只叫 Codex「幫我做一張銷售頁」

做到現在，我比較想做的，其實不是一張又一張獨立網頁。

而是一套：可以持續生產銷售頁的方法。

如果今天只叫 Codex 做一張頁面，那是一個任務。

但如果 Product Input、Brand DNA、Page Plan 都拆開，就開始有「系統」的感覺。

換一支產品，只換 Product Input。

換一個品牌，再換 Brand DNA。

同一支產品要做不同版本，就調整 Page Plan、Strategy、Hero 與 Component。

這就是我這次做到後面，開始越來越有興趣的地方。

原本我只是想：「幫 Dosha 做一張防曬銷售頁。」

結果做到後來變成：「同一支產品可不可以做十張？」

再往下想：「那如果換成海洋甦活美容液呢？」、「換成前導精華呢？」、「以後換成占星課程呢？」、「換成其他完全不同的品牌呢？」

這時候就會發現：如果底層結構一開始拆得夠清楚，後面並不需要全部重做。

而是換掉該換的那一層。

我覺得這就是：「產品銷售頁生成器」和「請 AI 幫我做一張網頁」最大的差別。

Tina學姐這一次學到的重點

這一次最大的突破，其實不是我學會了 HTML。

因為老實說，我到現在還是沒有打算去背一堆 HTML 語法。

真正的突破是，我開始理解：一個可以反覆使用的 AI 工作流程，到底應該怎麼被拆開。

• • Product Input 管產品事實。
  • Brand DNA 管品牌一致性。
  • Page Plan 管這一張頁面的敘事策略。

Codex 再負責把它們真正組裝成可以執行的頁面。

以前我們使用 AI，很容易是：想到什麼，就全部一次講給它聽。

現在我開始覺得，真正可以做大的方法反而是：把資料分層、把規則分開，把「可以變」和「不能變」的事情先整理清楚。

這樣 AI 就不用每一次重新猜。而我們自己，也不用每一次從零重新解釋。

寫在最後：

從 Codex 筆記第 1 篇一路寫到現在第 8 篇，我自己其實有一種很奇妙的感覺。

一開始，我只是想搞懂 Codex 到底是什麼。

接著開始做 Skill。再來讓它幫我做影片。幫我剪影片。然後把短影音流程封裝成自己的 Skill。

現在竟然已經開始做：產品銷售頁生成器。

我只是開始慢慢學會一件事情：怎麼把我原本腦袋裡的工作方式，整理成 AI 聽得懂、做得到，而且可以重複執行的結構。

我覺得，這可能才是未來很多非工程背景的人，真正需要學習的能力。

不是每個人都要變成程式設計師。

但是我們可以開始學會：知道自己要什麼，也知道怎麼讓 AI 幫忙完成。