010. 導言｜當 AI 開始「一句話」生網站
「搞懂『網站是做給誰看的』比任何特效都重要。」— Debug Tuboshu
過去兩年，「不寫一行程式就能做出一個網站」這句話被反覆當成封面文案。它出現在推特的 demo 串、YouTube 的縮圖、新創的募資簡報。可是很少有人誠實回答下一題：做出來的是什麼等級的網站？ 是 Dribbble 截圖那種，還是真的能交付給客戶、讓人願意付錢的那種？這兩件事之間的落差，幾乎沒人拆開來看。
台灣開發者 Debug Tuboshu 的一支 8 分 34 秒影片，大概是過去半年裡我看過最誠實的一次答覆。它沒有兜售「AI 改變一切」的敘事，而是拿 Claude Code 當主力引擎一口氣做了三件事：把老網站從 1995 一路拉皮到 2018、用 shadcn/ui 這個 Skill 連做 14 個常見平台、再挑戰復刻 Awwwards 等級的動畫網站。最後，它把同一個品牌的網站拆成三種版本——合作導向、敘事導向、極簡導向——告訴觀眾「做網站」從來不是一個問題，而是三個問題，AI 只能幫你回答其中比較簡單的兩個。
這支影片的密度異常高。3,318 字的逐字稿裡幾乎沒有廢話，每一個時間戳都在推進一個判斷。它把 Claude Code 逼到了邊界——預設輸出的風格、Skill 的作用範圍、shadcn/ui 當底座的可行性、帶動畫的 Awwwards 網站在什麼地方會整包壞掉。這些邊界平常被行銷敘事蓋住，只有當一個人真的把工具從頭用到尾，才會浮出來。
這支影片值得被慢動作拆開
影片本身節奏很快，八分半要塞進五、六個議題，每一個都只帶過觀察沒展開。但這些觀察背後的邏輯，才是真正有編輯價值的地方——為什麼 AI 預設產出會停在 2014？為什麼 Skill 會改變模型的行為？為什麼復刻一個動畫網站比做十四個電商還難？為什麼同樣的內容，拆成三種設計結構後，要追蹤的指標會完全不一樣？
這不是一份工具開箱文。Debug Tuboshu 的影片結尾留了一句看似雞湯、但其實很辣的話——AI 把交付網站的門檻壓到極低之後，真正的難題從「能不能做」變成「該不該做」。當一個前端工程師一天能產出 14 個堪用骨架，這個職業的競爭線就會從「寫得出來」往上移到別的地方。接下來的章節會依序拆解：AI 為什麼把 2014 當預設值、shadcn/ui 怎麼變成量產底座、Awwwards 級別的復刻要付出什麼額外成本、以及最後那個貫穿整部片的提問——拿掉裝飾之後，品牌的價值還剩什麼。
💡 給讀者的 Takeaway
- 「不寫程式做網站」這件事不是新聞，真正值得討論的是做出來的等級；這支影片難得誠實地標出了上下邊界
- Claude Code 有預設風格偏見、Skill 有明確作用、shadcn/ui 有能與不能做的類型——這些邊界平常被行銷敘事蓋住
- 真正的問題從「AI 能不能做網站」轉到「這個網站做給誰看」；後者才是接下來所有章節的骨幹
021. 為什麼 Claude Code 預設做出 2014 年的網站？｜Skill 是風格的強迫鍵
「如果隨意下一個 prompt，會做出 2014 年以前風格的網站；要透過 Skill 的方式才能再最佳化網站的風格。」— Debug Tuboshu
影片裡有一個容易被滑過去的片段：當 Debug Tuboshu 請 Claude Code 重新設計 2010–2014 年的 Bootstrap 風網站時，輸出結果幾乎沒有改變——顏色換了一下，版面、卡片、圓角、間距，全是一樣的配方。對於看過太多「AI 驚艷 demo」的觀眾來說，這一幕反而更有訊息量。它告訴你：AI 的預設審美，有一個你可以用肉眼辨識的年代。
訓練分佈的峰值，就是模型的審美
這不是 bug。這是統計事實。
大型模型的網頁設計語感，來自訓練資料裡出現頻率最高的那些範本。而公開網路上 HTML、CSS 教學、開源 side project、部落格模板、Bootstrap 官方範例⋯⋯最厚的那一疊，恰好落在 2013–2016 左右。那是一個很特別的時間點：響應式設計剛被普及、Bootstrap 3 還是業界標準、jQuery 沒有退場、卡片式設計、圓角、陰影、藍色主調，是那個年代的集體語彙。後來的 SPA 框架、Tailwind、shadcn/ui 雖然技術上更新，但它們的範例數量相對小，在訓練語料裡占比低得多。
所以當你給 Claude Code 一個模糊的 prompt「幫我重做這個網站」，模型會做一件對它來說最安全的事：回歸眾數。它會去採樣訓練分佈裡機率最高的那個區段，產出一個像 2014 年 Bootstrap 範本會長的樣子。這不是模型「老派」，是它沒有理由冒險。
Debug Tuboshu 在影片裡把這個現象當成通識講：「我們的模型有很大一部分，學習了這個時期的資料。」這句話是輕描淡寫的結論，背後是整個機器學習訓練管線的副作用。你很難要求模型自發地「跳出」它的訓練中心，除非你給它一個明確的外力。
把時代當成一條軸：1995 到 2018
影片開頭請 Claude Code 對每個年代「拉皮」的段落，看似懷舊快閃，實際上是一次關於「預設風格能走多遠」的壓力測試。1995–2000：Table layout、frameset、閃爍圖示、訪客計數器——AI 仿得很像。2000–2005：Flash 開場動畫、iFrame、「需要 Flash Player 6.0 以上」那種提示——排版仍以 Table 為主，Flash 本身已無法執行，只能靜態模擬。2005–2010：CSS Float 取代 Table、藍色主調流行——AI 到這裡開始顯得自然，因為慢慢靠近訓練舒適圈。2010–2014：響應式革命、Bootstrap 時代——這是模型的家。2015–2018：jQuery 退位、SPA 崛起、從扁平走向半扁平——AI 走到這裡開始勉強，預設風格會把時鐘往回撥一格。
這整條軸看下來，真正值得記住的是一件事：模型的預設風格，比你以為的老。 它不會預設做出 2024 年那種用 Radix UI 堆出來的冷感設計，因為那樣的資料沒有足夠密度把它拉過去。你要它走到現代，就得動用一種「外加訊號」——也就是影片接下來演示的 Skill。
Skill 是給模型的「風格強迫鍵」
Skill 這個字在 Claude Code 的文件裡很低調，容易被當成「多一組 prompt」。但在這支影片裡它的角色清楚多了：Skill 是一組優先權比 prompt 更高的風格與行為約束，會強迫模型走離預設分佈。
影片示範了兩個 Skill。第一個叫 impeccable，功能單純：避免模型一直產出類似的樣板。當它被掛上之後，Claude Code 做出來的設計肉眼可見地「變不一樣了」——但 Debug Tuboshu 很誠實地補一句：「但好看嗎？不確定。」這句吐槽意外地揭開底牌：Skill 保證「你離開了預設」，但不保證「你到了更好的地方」。它像一個強迫鍵，把模型從熟悉的眾數推開，至於推去哪裡，要看這把 Skill 被設計得多精準。
第二個 Skill 是 shadcn/ui。它和 impeccable 完全不同，不是抽象地「拒絕重複」，而是具體指定一套現代化元件語彙——Radix UI + Tailwind CSS 底層、copy-paste 的 React 原始碼、特定的 spacing、token system、字級比例。當 Claude Code 被這個 Skill 綁住，就會繞開 Bootstrap 年代的預設路徑，走到 2023 年之後的設計語境。
為什麼 prompt 永遠不夠
如果 Skill 和 prompt 的差別只是「多一層指令」，那它不值得被單獨講。它真正的分量在於：prompt 是和訓練分佈拉鋸的短期輸入；Skill 則是優先參考、可以封裝成獨立檔案重用的長期約束。 你可以為「讓 AI 做網站」累積一組專屬於你的 Skill——把設計系統、品牌色、慣用的排版骨架、禁止的元件——全部包進去。這些東西進到 prompt 裡會散掉、進到 Skill 裡會黏住。
影片其實只花了不到一分鐘講 Skill，但那是整支片子最重要的一分鐘。它把「AI 怎麼被調教」從玄學拉回一個可操作的機制：你不是在和黑箱討價還價，你是在選擇要不要給它一組強制訊號。有，你就能離開 2014；沒有，你永遠走不出去。
💡 給讀者的 Takeaway
- AI 預設產 2014 風格不是 bug，是訓練分佈的眾數；不給額外訊號，它沒有理由冒險換語彙
- prompt 是和模型拉鋸的短期輸入，Skill 是可重用、優先權更高的長期約束——這是兩種完全不同的力量
- 真正該投資的不是「把 prompt 寫得更漂亮」，而是「把你的設計語彙封成一組 Skill」
032. shadcn/ui 一鍵起底｜14 個網站，一個底座
「要做市面上常見的網站——千萬不要從頭來，直接請 AI 起一個底是最快的方式。」— Debug Tuboshu
影片中段有一個節奏極快的段落：電商、點餐、音樂串流、旅遊規劃、醫療預約、聊天室、資料分析後台⋯⋯一個接一個，每個畫面停不到三秒。這 14 個網站全部由 Claude Code 配 shadcn/ui 產出，有些完成度高到「可以直接使用」。
這個畫面值得多看一眼。因為它示範的不是「AI 很強」，而是一件更有趣的事——這些看似不同的網站，其實是同一個架構的 14 種皮膚。
常見網站，是同一張底的不同配色
把電商、點餐、音樂串流、旅遊預訂、醫療掛號攤平來看，它們共用的骨架幾乎可以用一張圖畫完：頂部導覽、英雄區、搜尋或分類列、卡片網格、篩選側欄、詳情頁、購物車或清單、帳號後台。差異只在卡片裡放什麼——商品、餐點、歌曲、飯店、診所。骨架是同一個。
shadcn/ui 剛好是為這個骨架量身打造的。它不是傳統的 component library——不像 Material UI 那樣「引進一個 npm package、呼叫 <Button />」。它是一組可以複製貼上的 React 原始碼，建立在 Radix UI 和 Tailwind CSS 之上。你拿到的是可讀、可改、可拆的元件檔，不是封裝起來的黑盒。
這個設計決策讓它變成 AI 的理想底座。Claude Code 生成網站時最怕兩件事：元件規範不統一、要猜設計 token。shadcn/ui 把這兩件事都預先鎖好——token 是 Tailwind 的、互動是 Radix 的、檔案是原始碼級別的。AI 照著現有檔案的風格寫新元件，就自動落在同一個視覺體系裡。這也是為什麼影片裡 14 個平台看起來像「一家人」：共用同一套字級、同一組圓角半徑、同一個間距尺度。
為什麼從頭做是反模式
「要做市面上常見的網站——千萬不要從頭來，直接請 AI 起一個底是最快的方式。」反面是：從頭做就是反模式。 理由有三個。第一，常見網站的設計慣例早被用戶的肌肉記憶鎖死——電商的購物車按鈕右上角、點餐系統的類別在左欄或上方、後台側邊導覽能收起——這些不是設計選項，是基礎設施。第二，AI 從頭做會回到上一章那個老問題：預設分佈把你拉回 2014。第三，shadcn/ui 已經把無障礙、鍵盤導航、焦點管理那些關鍵細節寫進 Radix 底層，從頭做要補回這些，是一場看不見的泥沼。
常見網站的「常見」本身就是價值。你不是做一個獨特的電商，你是做一個「讓客戶五秒內知道怎麼買」的電商。AI + shadcn/ui 把「看到就知道怎麼用」的部分，壓縮到一個指令就能交付。
能做什麼、不能做什麼
但 shadcn/ui 的優勢也是它的上限。它擅長資訊型、交易型、後台型——就是那 14 個 demo 裡的類型。它不擅長表現型：用動畫說故事、用捲動觸發視覺事件、用 3D 模型呈現產品、用整頁滾動搭配 Lottie 做品牌敘事那種。
這條邊界很好理解：shadcn/ui 的美學是冷靜、克制、可讀性優先，元件庫裡沒有「炸裂的漢堡」「從書頁跳出的角色」「日夜切換的街景」這些東西。這些視覺語彙需要另一整套工具鏈，而 AI 預設做不好，需要完全不同的工作流去拆解、復刻、再重組。
所以影片把事情拆成兩條軌道：常見網站，shadcn/ui 一鍵起底；Awwwards 級別，AI 從零生成幾乎必敗，要走另一條拆解路線。 這是整支片最重要的分類法——它沒有把「AI 做網站」當成單一能力，而是兩個能力邊界，中間隔著一整套額外的工程流程。對想做出差異化的前端來說，真正的挑戰不在第一條軌道上。
💡 給讀者的 Takeaway
- 電商、點餐、後台這類「常見網站」本質上是同一個骨架的變體；shadcn/ui 把這個骨架標準化，讓 AI 可以一鍵起底
- shadcn/ui 擅長冷靜、可讀、交易導向的類型，不擅長表現型、動畫型的品牌網站——這條邊界決定了 AI 是幫手還是瓶頸
- 常見網站從頭做幾乎都是反模式：你會重新發明使用者肌肉記憶、補 Radix 早就寫好的無障礙細節、還會掉回模型的 2014 預設
043. 復刻 Awwwards 的三步｜Extract、拆解、主題替換
「直接丟給 Claude Code 很容易失敗——尤其是這種帶有動畫特效的網站。」— Debug Tuboshu，Awwwards 復刻段落
Awwwards 是業界設計師與開發者互評的網頁設計獎，也是許多人拿來當「這個設計做得出來嗎」的參照點。對 AI 做網站這件事來說，Awwwards 得獎作品是一個殘酷的測試集——不是因為它難，而是因為它幾乎沒有一個是「乾淨的 HTML + CSS」。它們通常是 Lottie、Three.js、ScrollTrigger、WebGL 的堆疊，彼此用 JSON、時間軸、滾動位置綁在一起。這種東西，你把 URL 丟給 Claude Code，它會很禮貌地回給你一個「像、但又不太像」的版本——骨骼對了，氣氛全沒了。
Debug Tuboshu 的第一個示範對象，是 Awwwards 上一個叫 Don'tBall Me 的網站。整個網站的核心效果是 Lottie 配 ScrollTrigger：使用者往下滑，卡通狗的動作隨著捲動推進。看起來是個靜態頁，實際上是一整套動畫檔、捲動錨點、CSS 圖層堆出來的。他先做了一次「天真版」復刻——把網址丟給 Claude Code，請它重建。成果是典型的 AI 失敗案例：構圖大致正確、顏色抓到了，但動畫邏輯錯位、元素堆疊順序歪掉，整個網站像被壓縮過又解壓縮回來，某種「接近原件但失去靈魂」的狀態。
Extract 不是工具，是一個方法論
關鍵的轉折發生在他決定不再把 URL 整包丟給 AI 之後。他自己寫了一個工具，叫 Extract，做的事情很樸素：把目標網站上的所有圖片、元素個別下載下來，同時抓出每一個元素的 CSS 樣式與在頁面上的定位座標。它不解釋、不推論、不做設計判斷——它只是把一個被 JavaScript 動態組裝起來的網頁，拆回「素材清單 + 位置表」這兩件東西。
這一步看起來不起眼，卻是整個復刻流程能跑通的分水嶺。直接丟 URL 等於請 AI 做兩件事：理解網站的視覺意圖、把那個意圖重新寫成程式碼。這兩件事同時做，就是失敗的起點，因為前一件事本來就沒有標準答案——同一個畫面可以有十種組法。Extract 做的事情是把「理解視覺意圖」這一層先拿掉，只留下物件與座標。AI 接到的輸入，不是「請你重建一個動畫網站」，而是「這是一堆 PNG、一份 CSS、一份位置表，請你拼回去」。後者是個明確的工程題，前者是個品味題。
這也是為什麼它不該被當成「又一個好用的下載工具」來看。這是一種工作方法——把 AI 真正不擅長的那層抽走，讓它做它能做好的那層。這個思路不只適用在網站復刻，拿來想「為什麼我的 AI Agent 總是做不對」這種更普遍的問題，也是同一個解法。
95% 相似，但那 5% 是關鍵
Extract 拆解完、Claude Code 重建完，Debug Tuboshu 給出的自評是「大概 95% 像」。這個數字值得編輯台稍微停一下看。
95% 不是一個 benchmark 意義上的好數字——在論文裡它大概算勉強及格。但在「復刻一個 Awwwards 級網站」這件事上，它是一個相當有意義的門檻。因為剩下的那 5%，正好是他強調「不能直接抄襲別人網站」的理由。95% 意味著你已經有一個幾乎可以當作自己東西用的起點，再往上走就是主題替換：把狗換成貓、把貓換成火箭、把火箭換成燈泡。動畫邏輯、捲動節奏、版面構圖都保留，但素材換成自己的主題，整體氣質就會偏移——那 5% 的差距，就從「誰復刻誰」變成「從同一個語彙長出不同的作品」。
這件事能不能稱為原創，嚴格說是個灰色地帶——但它顯然也不是抄襲。更準確的描述是從參照走到再創作的中間狀態，而這個狀態過去需要一個動畫師加一個前端工程師合作好幾週才到得了。現在一個人加一個 Extract，下午就到了。
Three.js 的神秘感，被拆成「幾何＋材質」
第二個示範是 Lottie 配 Three.js 的網站。Three.js 對大多數前端工程師來說，是那個「大家都聽過、真要我寫也寫得出來、但不會開心寫」的東西——它牽涉 WebGL、幾何運算、光影模型，學習曲線陡。而這類網站通常被視為 AI 不敢碰的領域。
Debug Tuboshu 的切入點很冷靜：3D 模型並不是一個神秘的黑盒，它就是一個幾何 ＋ 一套材質，兩者在渲染時合體。換句話說，如果幾何結構不變，只要換掉材質貼圖，同一個模型就能變成完全不同的東西。
他的做法是：先用同一套 Extract 流程把 Three.js 網站拆下來，保留原本的 3D 幾何，只請 Gemini 生成新的包裝材質貼圖，把飲料罐子的視覺換成漢堡的包裝。成果是一個幾何完全沿用、但主題截然不同的新網站。如果希望連幾何都換——比如真的要一個「漢堡的立體模型」——他用的是 Hyper3D：上傳幾張漢堡照片，讓它生成 3D 模型。這一步的品質不穩定，講者自己用的形容是「需要抽卡一下，不一定會很理想」。這句話值得記下來——它是目前多數 AI 3D 生成工具的共同體質，你可以期待它有時驚豔，但不能期待它穩定。
把這兩段合起來看，Three.js 這件事就從「AI 做不來的高難度特效」縮回「可以被拆解、可以被部分替換、可以被 AI 介入的一個技術選擇」。這不是說 Three.js 被 AI 取代了——而是前端工程師在用 AI 協作時，多了一條「我不從零開始寫 Three.js，我從 Extract + 材質替換切入」的工作路徑。
但其實，連 3D 都可能不需要
到這裡，整個 Awwwards 復刻流程已經有了明確的三步：拆解（用 Extract）、重建（丟給 Claude Code 配素材表與座標）、主題替換（換圖、換材質、換元素）。它解釋了為什麼同樣丟 URL，Debug Tuboshu 做得出 95%，多數人只做得出 60%。
但就在這套方法已經相當成熟的時候，他接著丟出一個更反直覺的問題：如果使用者根本不會去旋轉、操作那個 3D 模型——那我們到底為什麼要用 3D？
💡 給讀者的 Takeaway
- 復刻動畫特效網站，直接把 URL 丟給 Claude Code 幾乎一定失敗，因為你同時要求它「理解視覺意圖」與「重建程式碼」這兩件難度不同的事
- Extract 的價值不是下載工具本身，而是一種把 AI 不擅長的理解層抽掉、只留工程題的工作方法
- 95% 相似加上主題替換，是從「參照」到「再創作」最短的一條路，也劃出了「復刻」與「抄襲」之間的實務邊界
- Three.js 模型可以被拆解成「幾何＋材質」，只要換材質貼圖，同一個幾何就能變成另一個主題的網站
- Hyper3D 這類生成工具效果需要抽卡，能當加速器但不能當產線，這是目前 AI 3D 生成的普遍體質
054. 沒有 3D 模型也能做滾動動畫｜圖片→影片→拆幀
「其實不需要去建立 3D 模型，因為使用者並不會去真的轉動它，而是一個固定的動作方式。」— Debug Tuboshu，3D 模型段落
上一章走完了 Three.js 的拆解路徑，表面上看是一個圓滿的結尾：AI 也能協作處理 3D 了。但 Debug Tuboshu 接著往回退了一步，問了一個更素樸的問題——使用者到底會不會真的轉動那個模型？
絕大多數情況下，答案是不會。Awwwards 上那些亮眼的 3D 場景，九成以上是「固定視角的展示」：一個漢堡懸浮、一罐飲料旋轉、一台汽車從左到右掃過。使用者的互動只有往下滑。他們不會拖曳、不會縮放、不會改視角。既然如此，為什麼還要花 WebGL 的運算成本、Three.js 的維護成本、3D 模型的生成成本，去撐起一個沒人會用到的自由度？
這個提問本身就是這一章的核心技術觀點：當互動只有單一方向，你需要的不是 3D 引擎，而是一串按順序顯示的圖片。
五個工具，一條流水線
於是他示範了一套完全不用 3D 的工作流，用「漢堡炸裂」這個經典 Awwwards 式效果當範例。整條流水線五步：
第一步是首尾兩張圖。他用 Google Whisk 生成兩張：一張「完整的漢堡」、一張「炸裂的漢堡」。這一步不是要一次到位，而是要抽到兩張視覺一致、可以當首尾針的圖。
第二步是把兩張圖變成影片。他把這兩張圖丟給 Google Flow——一個支援「首尾針生影片」的服務，並且有免費小額度——把完整的漢堡設為首針、炸裂的漢堡設為尾針，加上一個「絲滑轉場」的 prompt。產出的影片就是從完整過渡到炸裂的連續畫面。如果效果不理想，他的建議很務實：請 AI 幫忙調 prompt 再生一次。這是所有生成式工作流都要接受的常態——不是一次命中，是快速重抽。
第三步是把影片拆回圖。他用 EzGIF 把影片轉成連續影格，一次性打包下載。這一步看起來最瑣碎，卻是整個流程能對接到前端的關鍵。因為網頁不懂影片的時間軸，但它懂「第 1 張、第 2 張、第 3 張」。
第四步是交給 Claude Code 套 ScrollTrigger。把整個影格資料夾丟給它，請它寫成「隨滾動切換圖片」的互動——這正是 GSAP 的 ScrollTrigger 最基本的用法，也是 Claude Code 最能勝任的那種小範圍前端題。
第五步是成品。使用者往下滾，漢堡就一幀一幀炸開；滾回去，漢堡就復原。視覺上它和一個真的 Three.js 3D 動畫幾乎無法區分——但整套東西沒有一個 3D 模型、沒有一行 WebGL。
AI 時代的新拼貼主義
這套工作流，值得被當成一個方法論來看待，而不只是一個省 3D 的小聰明。
仔細看這五步：Whisk 做它最擅長的圖像生成、Flow 做它最擅長的影片過渡、EzGIF 做它最擅長的格式轉換、Claude Code 做它最擅長的前端串接。沒有一個工具嘗試做全部的事，也沒有一個步驟期待工具「自己想清楚」。每個工具只負責自己最擅長的那一段，產出一個明確的輸出，交給下一站。
這是一種新的拼貼主義。過去十年，前端工具鏈一直朝「整合」的方向走——一個框架解決所有事、一套設計系統統一所有元件。但在生成式 AI 的語境裡，反方向反而更合理：讓每個模型或工具做它邊際成本最低的那件事，你負責把它們串起來。組合能力（composition）變成比單一工具深度更值錢的技能。
它也解釋了為什麼 Debug Tuboshu 的流程能跨主題複用。換掉首尾針，整條流水線就能產出完全不同的效果：不只是漢堡炸裂，同樣的邏輯可以做樹木從種子長到成樹、書本裡的角色從頁面跳出、投影機打出動態畫面、冰箱開啟展示食材、街景從白天漸變到黑夜。它不是一個「漢堡炸裂效果」的專用配方，而是一個「固定視角轉場動畫」的通用管道。
效能與可控性的意外好處
從工程角度看，這套做法還有兩個 Three.js 版本比不上的優勢——而且都不是靠 AI 才得到的，是直接從「不用 3D」這個選擇本身繼承來的。
第一是效能。Three.js 的 3D 場景要拉起整個 WebGL 管線、載入幾何、處理材質與光源，對手機端尤其吃資源。一組 PNG 加 ScrollTrigger，瀏覽器只是在做非常輕的影像切換，電池消耗和首次載入時間都會好看得多。
第二是可控性。生成式 3D 的結果不穩定——Hyper3D 要抽卡、Gemini 換材質有時會換出詭異效果。但當你已經把過程落地成「一組確定的 PNG」，後續的每一步都是確定性的。你可以手動修圖、可以替換其中幾張、可以讓美術把特定幀畫得更精緻——這在 3D pipeline 裡做起來是另一場戰爭，在這裡只是開 Photoshop 改一張圖而已。
把技術做簡單不是認輸，是懂得問「使用者真正需要什麼」之後的誠實選擇。
但動畫做得出來，還沒回答一件事
這一章、加上上一章，其實已經畫出了 AI 時代前端協作的一條清晰路徑：Skill 約束風格、shadcn/ui 量產套底、Extract 復刻特效、影片拆幀做動畫。技術上的障礙幾乎被逐一拆除——做得出來這件事不再是問題。
但這正是所有技術示範到這個階段都會撞到的牆：做得出來，不等於做得對。一個漢堡炸得再炫、一個 3D 場景拆得再聰明，都還沒回答更根本的那個問題——這個網站，到底是做給誰看的？
💡 給讀者的 Takeaway
- 固定視角的 3D 展示，使用者不會真的旋轉，那就沒必要花 Three.js 的成本——圖片→影片→拆幀→ScrollTrigger 五步就能做出視覺等價的效果
- 這條流水線的核心不是某個神奇工具，而是讓每個工具做自己最擅長的一段的組合思維——AI 時代的新拼貼主義
- 換掉首尾兩張圖，同樣流程可以做出樹木生長、書本角色、投影機、冰箱、日夜街景等截然不同的主題
- 非 3D 路線在效能與可控性上反而更好，因為中間產物是一組確定的 PNG，每一步都可以手動介入
- 技術障礙被一層層拆除之後，留下來的那個問題反而更尖銳——網站到底是做給誰看的
065. 同一個品牌，三種設計｜合作版、敘事版、極簡版
「如果我把這些裝飾都拿掉，那品牌的價值還剩什麼？」— Debug Tuboshu
前面四章談的都是「怎麼做」——怎麼哄 Claude Code 跳出 2014 年預設、怎麼用 shadcn/ui 快速起底、怎麼把 Awwwards 得獎網站拆到 95% 相似、怎麼用「圖片→影片→拆幀」繞開 Three.js。技術槓桿愈拉愈長，直到某一刻問題換了方向：做得出網站，不代表做得出「對的網站」。
Debug Tuboshu 在影片最後做了一件技術上最不華麗、但論述上最關鍵的示範——把同一個工作室的同一批內容，拆成三個完全不同結構的網站。沒有換文案、沒有換作品集、沒有換品牌色，動的只是資訊架構與追蹤指標。結果不是「哪一版比較好」，而是三版都對，只是各自服務不同的受眾、不同的階段、不同的商業假設。
這個動作拆穿了一個被行業長期默認的等式——網站做得漂亮 = 網站做得好。一旦內容與受眾關係被攤開來討論，視覺就從主詞變成了工具。
v1 · 合作版｜當網站要承擔業務壓力
第一版的邏輯是說服漏斗：看到 → 信任 → 理解 → 行動。B2B、接案工作室、顧問品牌用了快二十年的古典結構，它沒被取代，是因為它誠實。當網站的任務是「讓不認識你的潛在客戶願意寄出聯絡表單」，它必須在一次滑動裡，把懷疑降到決策門檻以下。
所以整個頁面被拆成可以量化的信任組件：Hero 壓住價值主張、Trust Bar 擺合作過的品牌標誌、Projects 展示代表作、Services 釐清能做什麼、Process 降低「不知道怎麼開始」的摩擦、Pricing 與 Testimonials 用數字與證言補強、最後才是 CTA。這不是排版，這是一張把陌生訪客推向決策的漏斗地圖。
這一版的 KPI 最誠實：CTA 點選率與聯絡表單完成率。兩個指標都是事件級，可被 A/B 測、可被歸因。當網站接下了「負責開案」的任務，它就不再是品牌資產，它是業務工具。適合誰？有口碑、想主動擴張客戶名單的 agency；剛升級成小型工作室、急需陌生客戶自己找上門的團隊。它不優雅，但換得回現金流。
v2 · 敘事版｜當網站要承擔立場
第二版把網站當一本雜誌寫。Hero 不賣服務，賣立場——「我們用程式說故事」。然後一頁一頁推進：Motion 展示方法輪、Craft 用資料佐證細節工藝、System 暗示長期思維（不只交付頁面，而是交付可持續的系統）、Collaboration 才放證言與 Trust Bar。收尾不是按鈕，是問句——用邀請替代推銷。
結構本身就是論點。願意用四個章節談方法、工藝、系統、合作的工作室，在潛在客戶的認知裡，已經和那些用模板接案的對手切開了。這一版不追求轉換率，它追求閱讀完成率——點進頁面的有幾個人，滑到最後的又有幾個。這是更長尾、更難被短期 A/B 證明的指標，但它量測的是「我的思考方式能不能被客戶讀完」這件更上游的事。
敘事版適合的不是要開案的當下，而是建立不對稱認知的階段。一個早期 studio，在市場還沒記住你是誰、為什麼值得相信之前，用這一版把你的方法論刻進讀者腦裡，遠比擺一個更亮的 CTA 有用。風險也誠實——內容本身沒想法，長捲動只會放大空洞。v2 不是風格選擇，是你願不願意在網站上押上自己的觀點。
v3 · 極簡版｜當網站要承擔速度
第三版是很少被公開討論、但很多成熟品牌私下在做的選擇——把裝飾全拿掉。Hero 直接壓價值主張、Trust Bar 一行標誌、三件精選作品、一張簡潔服務列表、一個 CTA。沒有動畫，只有最基本的 CSS 互動；不追求驚豔，追求速度、效能、可達性。
這一版的 KPI 最狠：Mobile Contact Conversion Rate。講者的理由直接——使用者用手機開網站，網路可能不穩定，耐心只有 5 秒。打不開、看不懂、聯絡不到人，這三件事只要中一件，流量就歸零。極簡版的設計哲學不是「少即是美」的美學姿態，而是「承擔不起讓使用者等」的商業誠實。
適合這一版的通常是兩種極端。一種是品牌已強到不需要包裝——潛在客戶是被推薦來的，進站是為了確認你還在營業、聯絡方式還有效。另一種是反過來，還沒建立品牌、但客戶多半從手機流量進來——餐廳、診所、本地服務。共通點是：網站不是表演舞台，是一條最短的路。
不是美學戰爭，是判斷
攤開這三版，很容易陷入錯誤提問：哪一版比較好？這問題本身就是陷阱。講者真正想示範的是——這不是品味戰爭，是判斷。
判斷什麼？判斷這個品牌現在這個階段、面對這個受眾、要完成這個商業任務，哪一種結構會讓網站成為資產而不是負債。一個急需開案的接案工作室用 v2 敘事版，可能被埋沒在讀者滑不到底的耐心裡；一個有口碑的 agency 用 v1 合作版擴張名單，也許正確；但同一個 agency 五年後變成標誌性品牌，要的可能是 v3 的克制。同一個品牌，在不同生命週期，要不同的網站。
前面四章談的技術槓桿——Skill、shadcn/ui、Extract、ScrollTrigger、首尾針影片——都必須被重新歸位。它們是放大器，不是答案。放大錯誤的方向，只會讓錯誤更大更亮。決定方向的那個動作——讀懂受眾、挑對結構、押對指標——不需要寫一行 code，卻是工程師在 AI 時代真正不可被取代的判斷。
當 Claude Code 可以在十分鐘內產出三版網站的那一刻起，值錢的就不再是「能不能做出來」，而是「知道為什麼要做這一版、不做那一版」——以及看得懂做完之後，數據是不是真的回到你預設的那個指標上。
💡 給讀者的 Takeaway
- v1 合作版用說服漏斗服務「要開案」的階段，KPI 是 CTA 點選率與聯絡表單 CVR；v2 敘事版用雜誌章節服務「要建立不對稱認知」的階段，KPI 是閱讀完成率；v3 極簡版服務「速度就是業務」的階段，KPI 是 Mobile Contact Conversion Rate。三版都對，只是給不同人看
- 同一個品牌在不同生命週期會需要不同的網站結構。挑版本不是美學選擇，是對「受眾 × 商業任務 × 階段」的判斷
- AI 讓三版網站都能被快速生出來的那一刻起，值錢的就不再是「能不能做出來」，而是「知道為什麼選這一版」的判斷力——這也是整條 AI 協作產線裡，最不會被自動化取代的那個環節
076. 結語｜動畫再炫，也要先問「做給誰看」
「做前端本來就是 Claude Code 的守備範圍，不過記得不要過度包裝、過度追求動畫特效，迴歸網站的本質才是更重要的。」— Debug Tuboshu（影片結尾）
回到一開始那個標題：前端工程師失業倒數？
如果把這支 8 分半的影片壓成一句話，它給的答案既不是「是」也不是「否」，而是一個更尖銳的重新提問——會失業的，不是前端本身，是不會問「做給誰看」的那一種前端。
Claude Code 確實可以在一次對話裡生出一個堪用的網站。shadcn/ui 確實可以讓電商、點餐、儀表板這類常見型網站直接套底。Awwwards 等級的動畫也確實可以被 95% 復刻。這些都不是未來式，是現在式。但當這條產線愈走愈順，另一個現實也愈來愈清楚：AI 預設生出來的東西，永遠是最大公約數。它生的網站會自動回到 2014 年，它生的文案會自動回到商業雞湯，它生的動畫會自動套上訓練資料裡最常見的那組樣式。不是模型不夠好，是中位數就是中位數。要走出中位數，永遠要有人類下判斷。
判斷什麼？判斷這個網站做給誰看、要他做什麼、成功的訊號長什麼樣子。這些問題，Claude Code 可以幫你產生十個選項，但它沒辦法替你選。選擇本身，就是技藝（craft）在 AI 時代被重新定位的地方——不再是「會不會寫 code」，是「會不會選 code」；不再是「能不能做出動畫」，是「該不該做這個動畫」；不再是「我的手有多快」，是我的判斷有多準。
這也是為什麼講者花了整整五分鐘，示範同一批內容拆成三版網站的那個段落。那段沒有任何炫技，只是把選擇這件事攤在鏡頭前——給 v1、v2、v3 各一套 KPI、各一種受眾假設。等於在說：AI 可以把每一版都做得很好，但選哪一版這件事，還是你的事。
前端工程師的角色在轉移，但不是消失。它從「寫出這個效果的人」變成「決定這個效果要不要寫、寫給誰看、該追哪個指標」的人。前者會被 AI 吃掉大半，後者反而因為 AI 變得更值錢——當做出來的成本趨近於零，做對的溢價才會浮出水面。
動畫再炫，也只是工具。shadcn/ui 再快，也只是腳手架。ScrollTrigger 的漢堡再美味，也不會代替你回答那個更上游的問題——這個網站做給誰看？
那個問題的答案，永遠不在模型的 context window 裡，只在你的判斷裡。
💡 給讀者的 Takeaway
- AI 會吃掉「把效果寫出來」這一段工作，但會放大「該不該寫、寫給誰看、成功怎麼量」這一段判斷的價值——前端的工作從執行層往上游移
- AI 預設生出來的永遠是最大公約數：2014 年的網站、商業雞湯的文案、訓練資料最常見的動畫。要走出中位數，永遠要有人類下判斷
- 技藝（craft）在 AI 時代被重新定位——不是會不會寫 code，是會不會選。做得出來的成本趨近於零之後，做得對的溢價才會浮出水面