昨天把分支的觀念畫清楚了。今天要實際走一次。而且不是一條，是三條。
我想替這個網站進行 UIUX 的優化，但與其只交給一個 AI、做出來再看喜不喜歡，我想這樣做：同一個設計 skill、同一段 prompt，分別交給三個不同的 AI 工具，讓它們各自在一條分支上改。
最後把三個版本放在一起比較，選一條當基礎合併回 main。
在開始之前，先來認識今天的關鍵角色：skill。
可以先把 skill 想成一份可以重複使用的 AI 工作手冊。在支援 skill 的工具裡，它通常是一個資料夾：裡面有一份主要的說明文件，有時候還會附上參考資料或小工具。
它的用途是：把某一類工作的做法，事先整理好交給 AI。 像今天要用的設計 skill，裡面就整理了各種設計風格、配色、字體搭配，以及做介面時該注意的原則。AI 讀了之後，做出來的東西就不只是「它自己覺得好看」，而是有一套參考依據。
你可能會擔心：裝了很多 skill，AI 會不會被一大堆說明塞爆？
不太會。因為 skill 的內容是分層交給 AI 的：
第一層：名稱和一句描述 → 一直都在 AI 的視野裡，很短
第二層：完整的說明文件 → AI 判斷「這次用得上」才去讀
第三層：附帶的參考資料、工具 → 真的需要其中某一部分，才會打開
平常 AI 只看得到每個 skill 的一行描述。等你提出的需求跟某個描述對上了，它才去讀完整的說明；說明裡提到某份參考資料，需要時才再打開。
這種「先給一點，需要時再展開」的做法，叫做漸進式披露。像 skill 這類設計，常會採用這種分層讀取的方式。
這對我們有兩個實際的意義：
但是據說隨著新模型的推出，社群上許多人反應 Skill 反而成為累贅，可以斟酌使用。不過 Skill 通常可以使能力比較差的模型發揮較好的效果。
skill 說到底就是一些寫好的文字檔，所以在交給 AI 使用之前，可以先請它讀一遍，告訴你裡面寫了什麼。（不一定要做，但可以先了解一下內容。），例如：
請閱讀這個 skill 的內容，用幾句話告訴我：
- 它會給你什麼樣的設計指引？
- 它會不會執行任何腳本？如果會，那些腳本做什麼？
這一步有兩個好處：
skill 不會因為叫 skill，就自動值得信任。
今天用的是 UI UX Pro Max，一個開源的設計 skill，官方列出的支援工具同時包含今天要用的三個。
我先請 AI 看完並摘要，以下是它摘要的結果：
【圖 1｜GPT 5.6 sol 對於 UI UX Pro Max 的摘要】
skill 有兩種裝法：
| 全域安裝 | 裝在專案裡 | |
|---|---|---|
| 放在哪裡 | 電腦裡，這個 AI 工具自己的資料夾 | 這個專案的資料夾裡 |
| 誰能用 | 只有這個工具，但它開任何專案都能用 | 這個專案裡，有設定到的工具都能用 |
| Git 管不管 | 不管，因為它在專案資料夾外面 | 管，可以 commit，也會跟著 push |
可能會搞混的是：「全域」指的是「對這個工具來說，所有專案都能用」，不是整台電腦的 AI 工具共用。 用 Codex 裝的全域 skill，Claude 和 Antigravity 讀不到；三個工具都想用，就得各裝一次，換一台電腦還要再裝一次。
skill 可以跟著工具裝在電腦上，也可以跟著專案放在 repo 裡。
如果都在同一台電腦、使用同一種 AI 工具開發，並且希望開發任何專案都可以使用，也可以選擇該工具的全域安裝
今天要比較三個工具，最重要的是它們拿到同一份 skill。所以我選擇裝在專案裡：同一次安裝、同一個版本，筆電和桌機 pull 下來也都有。
UI UX Pro Max 有提供一個安裝工具，可以替不同的 AI 工具建立設定。我選擇安裝案專案中，在專案資料夾裡打開終端機並執行：
npx --yes ui-ux-pro-max-cli@latest init --ai universal
npx --yes ui-ux-pro-max-cli@latest init --ai claude
兩行的原因是因為universal 會把 skill 放在一個共用的位置（.agents），給支援這種格式的工具讀取；Claude 則另外裝一份它自己認得的。
Skills 有很多安裝方法，這邊舉的只是其中一種。（這個 skills 剛好有提供專門的安裝工具）
也有一種懶人安裝法是將 Skills 的網址丟給 AI 請他安裝。大部分的 AI 工具讀取的 skill 路徑是.agents，而 Claude 讀取的路徑是.claude，所以才需要各安裝一次。（但據說 Claude 似乎即將支援讀取 .agents 以及 AGENTS.md）
裝完之後，看一下 git status，或 Cursor 左側的版本控制面板：
【圖 2｜安裝 skill 後多出來的檔案】
【圖 3｜版本控制頁面中，更動的檔案】
順帶一個判斷方法：
git status有出現新檔案，代表裝在專案裡(因為他讀的是專案資料夾)，要記得 commit；如果什麼都沒出現，代表裝在工具自己的資料夾，不歸 Git 管。
多出來的不只一個資料夾。安裝工具會替不同的 AI 工具，各自建立它們認得的設定。三個工具拿到的是同一套內容，只是入口可能不同。
接下來我的選擇是先在 main 上把這些檔案 commit，再開始開分支。
這些檔案會跟著 push 上 GitHub，但網站的程式沒有引用它們，所以通常不會被打包進網站、送到使用者的瀏覽器——它在 repo 裡，但不在網站上。
最後，開新分支之前，分別打開三個工具，各問一句：「你看得到 UI UX Pro Max skill 嗎？」三個都說看得到，再出發。比起做完才發現某個工具根本沒讀到，這一步便宜得多。
【圖 4｜確認是否讀得到 Skills】
design-codex在 Cursor 左下角確認自己在 main 上，然後開一條新分支 design-codex。
接著分兩輪交給 Codex CLI。
第一輪：分析和計畫，先不動手
請使用 UI UX Pro Max skill，先完整分析目前專案的 UI/UX 與視覺設計。
接著根據 skill 提供的原則與你對產品的理解，提出一套完整、有明確設計方向的 redesign 計畫。
我希望這次是明顯的 redesign，不只是微調 spacing、圓角或陰影。
在開始修改前，請先說明：
- 你認為目前最需要改善的是什麼
- 你打算採用什麼設計方向
- 為什麼這個方向適合這個專案
- 你預計修改哪些頁面或元件
保留既有功能、資料、routing、URL 結構與搜尋／篩選行為，不新增產品功能。
確認分析完成後，先告訴我分析的結果以及欲修改的內容，等我確認完再實作。
第二輪：照計畫實作
請依照剛才的計畫實作。並且在動手前先幫我將分析結果以及修改計劃寫入一個 .md 檔案
這兩段 prompt 有幾個刻意的設計：
改完之後，看一下效果，再 commit。然後，切回 main。
新分支會從你「現在站的位置」分出去。站在 design-codex 上開新分支，Codex 的改動就會全部跟進去，Claude 等於是在 Codex 的成果上繼續改。這樣就不是公平的比較了。
✓ 我想要的：三條都以 main 為基準去修改
main ────●
├──── design-codex
├──── design-claude
└──── design-antigravity
✗ 我不想要的：從 design-codex 開出 design-claude
main ────●──── design-codex ────●──── design-claude
↑
帶著 Codex 的所有改動
所以今天的三條分支都是同一個節奏：
開分支 → 計畫 → 實作 → commit → 切回 main
同樣的流程、同樣的兩輪 prompt，再做兩次：
design-claude，交給 Claude CLIdesign-antigravity，交給 Antigravity CLI三條都完成之後，點開 Cursor 左下角，三條分支並排在那裡：
【圖 5｜完成後 Cursor 裡的三條分支】
圖中的套件叫 gitgraph，是一個 IDE 外掛套件，可以很好的視覺化查看分支狀態。
接下來，只要切到哪一條，網站就會變成那一條的樣子。這就是 Day 13 說的：你站到哪一條，資料夾裡的檔案就變成那一條的樣子。
複習：切換分支的指令為
git switch <分支名稱>開新分支並切過去的指令為git switch -c <分支名稱>
不過，實際跑下來並不是真正的兩輪：Codex 第一版改得太保守，我多請它一次照 skill 的建議重改；Claude 則在動手前先問我要深色還是淺色，我回答深色。
文章撰寫時，使用模型的是 GPT 5.6 sol low effort、Opus 5.5 medium effort、 Gemini 3.8 flash
我特別讓三個工具在動手前都先寫了一份計畫文件。摘要起來如下：
| 它先看到的問題 | 它選的方向 | |
|---|---|---|
| Codex | 搜尋和篩選的層級不清楚、卡片長得都一樣難以掃讀、手機版太擠 | 瑞士式數位索引：冷白、墨黑、粉紅，直接採用 skill 推薦的配色和字體 |
| Claude | 專輯本身不是主角、大量小於 12px 的字、沒有鍵盤焦點樣式；還發現指定的字體其實沒有載入 | 深色展示櫃：介面退到背景，讓每張專輯的顏色當唯一的主角 |
| Antigravity | 缺少實體唱片的質感、隨機小卡的機率不夠醒目、收藏頁沒有成就感 | 前衛唱片編輯風：保留紙底和紅色，加上唱片封套、格式鋼印、小卡機率標章 |
有趣的是，三個工具都不同程度注意到同一件事：這個網站真正有價值的，是版本與內容物的差異，但原本的呈現還不夠突出。
最有意思的是 Codex。它第一版其實改得很保守，後來在計畫裡自己也承認「保留太多原本的識別，改版的距離不夠」，第二次才直接採用 skill 推薦的瑞士風格。這讓我很明顯感受到：skill 會提供方向，但「要跟多緊」仍然是工具自己的判斷。（當然你也可以實際介入）
而照單全收也有代價：BIAS SHELF 原本的紅色不見了。skill 推薦的是「這類產品適合什麼」，不是「這個品牌是誰」——後者還是要你自己決定。
（左上-右上-左下-右下分別為首頁Hero區、首頁列表區、專輯詳情、收藏頁面）
【圖 6｜Codex 更改的情況】
【圖 7｜Claude 更改的情況】
【圖 8｜Antigravity 更改的情況】
看完截圖，可以發現它們的改動主要分成兩個方向：「視覺識別」跟「版面結構」。再加上互動，差異就很清楚了：
| 視覺識別（顏色、品牌感） | 版面結構 | 互動特色 | |
|---|---|---|---|
| Codex | 換掉了：紅色變粉紅，紙底變冷白 | 最保守，格局跟原版幾乎一樣 | 與原版差不多 |
| Claude | 換最多：整站變深色 | 改最多：首頁變封面牆、卡片變四欄、收藏按鈕固定在抽屜底部 | hover 時黑膠從封面後滑出 |
| Antigravity | 接近原版：紙底、紅色、黑膠都保留 | 中等：卡片變成唱片封套、加上格式標籤 | 首頁黑膠會旋轉，hover 的物件感最強 |
哪個比較好看，其實沒有一定的標準。下面這四個是一些好的 UI/UX 設計的一些相對比較客觀一點標準：
| 標準 | 問的問題 | 小方法 |
|---|---|---|
| 資訊層級 | 一眼先看到什麼？順序對嗎？ | 瞇眼測試：瞇起眼睛看截圖，細節糊掉後還看得出的，就是最重的 |
| 群組與留白 | 相關的東西有沒有靠在一起？ | 只看間距：不讀文字，猜得出哪些是同一組嗎？ |
| 強調色 | 最顯眼的顏色，用在最重要的地方嗎？ | 灰階測試：轉成黑白後，原本靠顏色區分的重點還看得出來嗎？ |
| 核心任務 | 事情有沒有變得更好做？ | 實際做一次：例如找到某張專輯的某個版本，看要點幾下 |
我的觀察是：
如果硬要用一句話形容三版：Codex 最像索引，Claude 最像產品，Antigravity 最像品牌。
其實三個版本各有優缺點。如果是我的話，我會盡量把各個版本的優點融合在一起。
三個版本各有亮點，也各有問題，沒有一個是完全沒有缺點的。所以我的做法不是「選一個、丟兩個」，而是選一條當基礎，其他兩條留下來當參考。而我最終選擇的併入 main 的是 antigravity 的分支。
把選中的分支推上 GitHub，開一個 PR：
git switch design-antigravity
git push -u origin design-antigravity
gh pr create
【圖 9｜建立 PR】
【圖 10｜建立 PR - 2】
【圖 11｜PR 的改動清單】
打開 PR 的改動清單，看一件事：有沒有動到原本說好不改的地方？ 整站改版會動到很多檔案，調整元件結構、甚至新增元件都很合理；但如果出現了資料檔、網址結構，或跟功能邏輯有關的程式，就要點進去看它改了什麼。
你還會在清單裡看到它寫的計畫文件。合併之後，這份文件就留在專案裡，之後再改畫面，可以請 AI 照它的規則走。
合併之前，可以再實際確認幾件事：
確認沒問題，可以按下合併。然後回到電腦上：
git switch main
git pull
【圖 12｜改動清單確認沒問題可以合併】
【圖 13｜合併完回到 Cursor 可以看到分之的變動】
昨天有說過，合併完的分支可以刪掉；沒被選中的分支，確定放棄時可以用 -D 強制刪除。
但這次我先不刪。因為另外兩條分支上，有一些我覺得值得帶過來的東西，之後還可以把它們當參考來源，再請 AI 把其中某個做法帶回來。例如：
參考
design-claude分支的收藏按鈕做法，調整目前的抽屜。
至於 AI 實際怎麼去讀其他分支的內容，要看工具支援的 Git 操作方式。等融合完成，確定不需要了，再把它們刪掉。
同時做幾個版本再挑，其實是產品團隊很常見的做法。
改版前，設計師常常會先做兩三個方向的設計稿，放在一起討論，而不是一開始就只做一個。AI 讓「先產生幾個候選方向」這件事便宜了很多，但比較、驗證、最後取捨的成本還是在。
而今天 4.3 所提到的標準，也可以直接拿去看任何產品的畫面：
今天做的事，其實是 Day 13 的觀念第一次真的派上用場：把分支當成實驗空間，而不只是備份。
重點不是比較哪個 AI 最強，而是讓幾個 AI 安全地各自探索，最後由人來選擇。好不好看最後還是主觀，但有了這幾個標準，至少說得出自己為什麼喜歡——下次跟 AI 溝通時，也就不再只是「再好看一點」。
第二幕到這裡結束了。
畫面已經長得像樣了，但所有的資料，都還寫死在程式裡。想新增一張專輯，得改程式碼；想讓使用者的收藏跟著帳號走，現在根本做不到。明天，我們潛到海面之下，開始談資料庫和後端。
我們明天見。
iThome鐵人賽
看影片追技術