Vibe Coding 架站適合你嗎？五個問題選對路線

會議室裡，主管把手機推到桌子中間，螢幕上是競品那個會動的品牌頁：產品在轉、光在流、標誌隨著滾動變色。用一個假設的情境來說：你手上是三週時程、一張小預算，團隊裡沒有人碰過 3D 程式，而上網查到的說法一面倒，不懂程式也做得出來，而且幾乎不必花錢就能上線。

難關其實已經搬家了。把一個 3D 頁面做出來，是這幾年變得最容易的一步；真正的難題換了位置：該不該由你做、做到哪裡停、誰說了算可以上線。即時渲染的 3D 頁面，本質上是一台每秒重畫數十次的機器，表現力是借來的，向三種有限資源借：讀者的注意力、裝置的運算、網路的頻寬；把動態預先做成影片再嵌入，可以少付一部分運算帳，代價換成影片體積與播放解碼。Vibe coding 壓低的是取得這些表現力的價格，沒有改變背後的物理。

動工前該做的不是挑工具，是先過五個問題：網站要被記住還是被使用、觀眾用什麼裝置看、網站要活多久、成本由誰支付、做完誰來驗收。五關全過，展示型的 3D 網站用 vibe coding 走，多半是最省時程的一條路；任何一關沒過，下面各段會直接給出口，不勸你把原型硬當成品。過關之後的執行要點與交棒時機，後段一併整理；排名與流量不做任何保證，只給完整的判斷工具。

快速重點：vibe coding 適合做展示型 3D 網站原型，品牌頁、作品集、活動頁過五問再動工；Firebase Studio 已停收新工作區，將於 2027 年 3 月終止服務，新專案改用仍受支援的環境；牽涉金流、權限或要長期經營，先換路線。

先別急著打開 AI：五個問題比工具挑選更重要

有個現象值得先看：生成變便宜之後，翻車的頁面反而變多。工具的門檻降低了，判斷的門檻沒有跟著降低，於是「做得出來」的頁面大量出現，其中不少華麗卻留不住人。難關從做不出來搬到了守得住，這正是五個問題存在的理由：它們不問 AI 夠不夠強，只問你的處境允許做到哪裡。這不是 AI 的錯；工具把可能性開得越大，選擇的責任就越是回到人身上，五個問題就是把責任撿回來的工具。

五個問題排成一張決策表，每一關都有過關條件，也有未過關時的去處。答不出來的關卡，比答錯更值得停下來。

↔ 左右捲動檢視完整表格

關卡	核心問題	過關條件	未過關的出口
需求本質	網站要被記住，還是被使用？	展示型需求，視覺權重高、互動單純	功能型需求先做完整的架站方式評估
觀眾裝置	多數訪客的手機跑得動嗎？	行動流量為主時，視覺重量壓得下來	退回 CSS 3D 或平面動態，放下完整場景
網站壽命	活三週，還是活三年？	短期頁可大膽；長期站要有版本控制與遷移計畫	長期經營改走可維護的架構
成本支付	帳單由誰出、出多久？	用量、時間與維護都在可負擔範圍	縮小範圍，或分階段做
驗收能力	做完誰認定可以上線？	有人能用實機與指標判斷品質	先補驗收清單，或改走有人能驗的路線

名詞先講清楚。Vibe coding 指用自然語言反覆迭代、讓 AI 產出可執行網站專案的開發方式：你描述畫面與行為，它生成程式碼，你看結果、再描述、它再改。做法不綁任何特定產品，換模型、換環境都成立；工具名字只在需要舉證時出現，不當推銷詞。

五關的用法建議紙筆化：把每一關的答案寫下來，隔一天再讀一次。書面答案會自己吵架，昨天寫「展示型」，今天發現報名流程其實要自己蓋，這種矛盾在腦中容易被忽略，在紙上藏不住。五個答案都站得住腳，再往下走。

還有一個觀念先立在前面：未過關不是失敗。五個問題的價值，本來就包括擋下不該做的專案；擋下一個三週後會變負債的頁面，跟做出一個好頁面一樣是成功。想把 vibe coding 的來龍去脈先補齊，vibe coding 的基礎觀念與演進有完整的入門整理，讀完再回來過關也不遲。

你的網站要被記住，還是要被使用？

第一關問需求本質。品牌形象、作品集、活動頁、產品展示這類展示型網站，目標是讓訪客記住一個印象，過關；需要會員系統、金流、多角色權限，或受法規與資安要求約束的功能型網站，不過關，出口是先把架站方式整體評估一輪，再回來談視覺。

兩種本質能容忍的冒險不同。展示型可以實驗、可以賭視覺，壞了損失一版畫面；功能型要的是可靠、可稽核、可交接，任何一項都不能拿去換炫。這份容忍度，決定後面幾關的寬嚴。

↔ 左右捲動檢視完整表格

需求本質	容忍的冒險	不能妥協的事
展示型	實驗性視覺、特殊互動、快速上線	核心資訊與行動入口必須清楚
功能型	介面樸素、步調放慢	安全、權限、資料正確與法規遵循

「被記住」也要有判準，不然會漂成各說各話。一個務實的檢驗是：訪客離開一週後，腦中還留下哪一個畫面？展示型網站的成功定義通常就落在這一格，名單與訂單留給後面的轉換層去傷腦筋。印象先站起來，轉換才有東西可轉；順序顛倒，多半兩頭空。把成功定義先寫下來，其他關卡的判斷才有共同的地基。

邊界情況也常見：活動頁要報名，作品集要接洽表單，算哪一種？判斷方法是把功能面交給專門的服務，表單、金流、預約都外掛成熟的第三方，頁面本體維持展示型的單純。功能一旦決定自己蓋，性質就變了，五關的標準也跟著換。

用一個標示為假設的情境看展示型怎麼過關：一個手工皂品牌要做期間限定的活動頁，活動結束就下架，頁面只有一個任務，讓訪客記得皂的質地與活動日期，報名走外部表單。壽命短、互動單純、沒有金流，五關裡最硬的壽命與驗收都自動變寬，大膽讓 AI 生成是合理選擇。

需求若不是展示型，別勉強。先回頭做架站方式的整體比較，把正式開發、套裝系統、無程式碼平台放進同一張評估表；3D 可以晚點再回來，順序反了，代價會放大。

手機才是裁判：3D 的重量由觀眾裝置決定

第二關看裝置。答案不在市場統計裡，在你自己的後台：打開網站分析，看行動裝置的流量比例、看訪客用的機型分布，再決定畫面可以做多重。自家資料比任何通用數字值得信。

背後的機制值得弄懂，它解釋了「桌機順、手機卡」這個常見抱怨。3D 動畫的成本等於每幀成本乘上重畫次數，而一般螢幕每秒重畫數十次，等於這台機器每秒都在付帳。手機的繪圖晶片、記憶體與散熱條件都比桌機緊，同一份場景的每幀成本在手機上會暴增；連續跑幾分鐘，熱節流還會再壓一層。所以說 3D 頁面向三種有限資源借表現力：注意力、運算、頻寬。這一關先處理運算與頻寬；注意力這筆帳，留給緊接在後的紀律檢查。

頻寬是另一本帳。3D 模型、貼圖與場景檔案常常比整個文字版面還重，行動網路的速度又隨地點浮動；第一屏還沒亮起來，訪客已經離開。控制手段不神祕：壓縮格式、降低貼圖解析度、非首屏資產延後載入，每一項都能寫進規格，交給 AI 一併處理。

升級有順序。CSS 3D 做得出的翻轉與視差，就不上完整 WebGL；嵌入現成 3D 資產能滿足需求，就不必重寫渲染迴圈；真的需要粒子、模型與完整場景，才動用 Three.js 這類函式庫，而且同步要求手機降級。每次往重的一端走之前，先問自己有沒有證據證明必要。

順序感可以靠一個動作建立起來：先做最輕的版本，給真人看過、確認訊息傳到了，再考慮往上一級。多數專案走到這裡就會停下來，因為輕版本已經把任務完成；會讓人想繼續加重的，通常是作者的滿足感，不是訪客的需要。

這不是說桌機不重要，而是順序問題：行動裝置先過關，桌機的體驗多半自動成立；反過來先照顧高階桌機，手機端通常變成災難現場。約束寬的端點先滿足，約束緊的端點才有活路。

自己怎麼測？用家裡最舊的那支手機，連一般行動網路，實際開一次；再把網址傳給兩三位目標對象，請他們在路上開開看。這個動作不需要任何工具預算，卻比讀十篇評測更接近真相，因為你測的是你的頁面、你的觀眾。

素材端同樣有帳要算。嵌入現成 3D 資產前，逐一檢查授權條款、檔案大小與商用限制，現成 3D 素材的來源與授權整理可以省下逐站查證的時間；視覺起點若是手邊照片而非模型，先讓照片帶上深度感、做成會動的素材再整合，照片轉 3D 動態素材的做法是其中一條路。素材若是影片，進頁面前先轉檔壓縮、把體積控制住，這是素材管理的基本功，跟用哪套工具無關。

畫面全部在動，等於全部沒在動

這一段是第二關的延伸檢查，問的是紀律：你的 3D 野心，有沒有配得上它的節制。視覺要成立，先挑一個會動的主角，其他元素全部退後；互動強度也一樣，從滾動驅動、游標跟隨到自由探索一級一級放寬，能停在輕的那級就停。

機制又是預算。讀者的注意力是有限額度，畫面上每一個在動的元素都在花它：背景在漂、標題在浮、按鈕在縮放、圖片滑過就傾斜，訪客的視線沒有落點，找不到該點哪裡，再華麗也只是被關掉的理由。

動效要成立，靠的是節制：畫面上每個東西都在動，觀眾的眼睛反而失去落點，等於什麼都沒在動。挑一個主角讓它動，其他元素壓低存在感，安靜地退到背景。主角之所以被看見，不是因為它動得多賣力，而是留白與對比在它周圍讓出了一個位置；畫面越安靜，唯一在動的東西越有分量。

想看公開的參考，可以自己打開蘋果（Apple）任何一季的產品頁滾一遍：動態通常只圍繞一個主角，一支手機、一顆晶片，隨著滾動翻轉述說，其餘版面安靜得接近印刷品。單主角紀律值不值得信，這是最容易自己驗證的公開例子；這類頁面給人穩定流暢的印象，節制也常被點名是原因之一。

挑主角的方法很樸素：問哪一個物件跟這次的承諾最有關，產品本體、製程畫面、還是那個儀式性的瞬間，選一個，只選一個。主角定了，其他元素的任務就跟著清楚：當安靜的背景，把視線讓出去。

主角的突出也不全靠動。顏色、明暗、尺寸的對比都能讓它被看見，動只是其中一種手段，而且是最貴的一種；先用靜態的對比把層次拉開，再把動留給真正需要的那一下，畫面更有說服力，帳單也更輕。

動的主角還要扛得起敘事。它轉動、翻面或組合的過程，最好就是在講你想講的那件事：結構怎麼來、細節怎麼做、用起來是什麼感覺。動與訊息脫鉤時，動效只是裝飾；動與訊息綁在一起時，它就是內容本身。

互動強度三級這樣判斷：滾動驅動把動畫掛在訪客本來就會做的行為上，最安全；游標跟隨適合小面積點綴，回饋要輕；自由探索最迷人也最危險，訪客一旦不知道可以拖、拖了回不來，加分項立刻變扣分項。能用滾動與點擊取得的資訊，不要設計成探索遊戲，強迫互動等於把訪客往外推。

假設的誤診案例：一位接案攝影師把聯絡方式與報價邏輯藏進 3D 場景，訪客得自己轉對角度才看得到。作品集或許撐得住這種設計，商業資訊撐不住；訪客的耐心以秒計，多走兩步才拿到的資訊，多半直接換一家。

這個網站要活多久，決定 AI 可以幫你寫多少

第三關問壽命，它決定 AI 可以幫你寫多少程式碼。活三週的活動頁，大膽生成，壞了重來成本低；要活三年的官網，每一分生成的程式碼都要有版本控制與遷移計畫，因為平台會退場，而且退場不會等你準備好。

真實案例就在眼前：Google 的 Firebase Studio 已於 2026 年 6 月 22 日停止建立新工作區與新使用者註冊，App Prototyping 工作區同日起不再開放建立，整個服務將於 2027 年 3 月 22 日終止。依官方文件，既有工作區在終止前可繼續使用，已部署的應用不受影響，專案建議遷往 Google AI Studio 或 Google Antigravity；停收細節見 App Prototyping 的官方說明，Firebase Studio 官方文件有完整的日落與遷移指引。

把這件事當機制看，不要當意外看。生成環境綁得越深、自動化用得越多，遷移成本就越高；反過來說，紀律只有一條：程式碼放進 Git，放在你帶得走的儲存庫裡，任何環境都只是暫時的工作檯。

三年官網的版本控制不是口號，落地面長這樣：生成的程式碼進儲存庫、每次可上線的狀態留標記、依賴套件鎖版本、建置流程可重現。做到這四件，換環境、換人接手、回滾修錯都是日常；做不到，每一次變動都在賭運氣。

遷移的具體動作不重，重的是頻率：定期把專案匯出備份，重要節點同步一份到儲存庫，環境內的自動化設定留下書面紀錄。公告退場那天才發現沒備份，與退場前一個月從容搬完，差別只在平常有沒有做這個動作。

帳單由誰支付，決定你敢實驗多久

第四關問成本的歸屬。自己品牌的事，時間與用量自己吸收，停損自己決定；客戶的專案就不同，誰付生成費用、誰承擔驗收工時、維護期多長、超出的部分怎麼計價，都要在動工前寫進往返紀錄。這一關的本質是責任，錢只是它的外形。

成本帳也要重算。vibe coding 沒有讓成本消失，只是讓帳單搬家：從工程師月薪，搬到生成用量、驗收時間與長期維護的注意力；網域、託管與素材授權照舊要付。免費額度依各家方案而定，超過之後可能是限用、要求升級或開始計費，token 的計費邏輯值得先弄懂再估預算。若你需要的是能長期版本控制、直接操作專案的能力，用命令列代理蓋網站的完整流程是另一條值得認識的路。

看不懂程式碼的人，拿什麼驗收？

第五關問驗收。不需要會寫，但要會驗：條件講在前面，證據取代感覺。這一關沒過，前面幾關全過也白搭，因為沒有人能說出「可以上線」這四個字。

先處理最常見的斷崖：桌機流暢、手機卡頓。載入與互動速度對使用者的影響，web.dev 的 Why does speed matter? 是不錯的思考起點；至於慢多少會損失多少，沒有跨網站通用的數字，用自家行動流量與真實使用者資料判讀才誠實。

把效能條件直接寫進提示詞，是最容易省下的學費：「手機載入低多邊形版本、場景離開視窗時暫停渲染、模型採壓縮格式、非首屏資產延後載入」，這些約束寫了，AI 才會把它們當需求。寫了也不等於完成：提示詞不是保證書，最終要用建置結果、效能分析和實機測試逐項驗證。驗收時可以把Core Web Vitals當守門指標，讓順不順變成可以量測的判斷。

驗收至少看四個視角，每一個都在回答「證據在哪裡」：

• 中階手機加慢速網路：找一台兩三年前的手機，用 4G 開網站，看首屏多久出現、3D 多久開始動。實機的體感，比任何桌面模擬都準。
• 減少動態偏好：在系統設定打開減少動態，確認網站乖乖降級，而不是照轉不誤。這個偏好背後是真實的人，暈眩與注意力的困擾都在其中。
• 剝掉 JavaScript 的 HTML：關掉 JavaScript 再開一次，關鍵文字與聯絡資訊還在嗎？只活在畫布裡的內容，對搜尋引擎與輔助技術等於不存在。
• 分享預覽與錯誤路徑：網址貼進發文框看預覽，再故意打錯路徑看 404 頁；這兩個地方最容易露出未打磨的邊。

證據要留下痕跡。建置日誌、效能分析的截圖、實機測試的錄影，隨手存下來，驗收就有了對照的基準；下次改版，同一組證據再拍一次，好壞不必爭論。看不懂程式碼沒有關係，看得懂證據就足以簽字。

更進一步，把檢查交給機器：能自動跑的驗證，寫進建置流程，每次生成後自動執行，報告直接附在結果旁邊。人的注意力留給機器看不出的問題，像是「這個畫面有沒有傳達出質感」；可量測的交給工具，不可量測的才交給人。

退化要有層次：最底層給靜態預覽，中層給精簡動畫，高階裝置才放完整場景，三層保留同樣的核心資訊。不要單靠 deviceMemory 或 hardwareConcurrency 判斷裝置等級，瀏覽器供給不一致，數值也可能被遮蔽；較穩的做法是預設輕量版本，用功能偵測決定升級，留一個讓使用者自己切換的選項。畫在 canvas 裡的內容要給文字替代，把品牌標語做成 3D 文字之前，先確認同一句話也以普通文字存在於頁面。

五種常見誤診，都把做得到當成應該做

走完五關，回頭看五種常見誤診。它們的共同點不是技術不夠，是把「做得到」直接當成「應該做」；修正方向因此都在決策，不在工具。

誤診一，免費迷思。把免費額度當永久免費，把上線當終點。帳單只是搬了家，沒有消失；估法也不難，把每個月的生成用量、投入小時與維護頻率寫下來，三個月後回看，成本自然現形。

誤診二，只在自己機器上測。在那台高階筆電上看很順，就認定全世界都順。裁判從來不是開發者的機器，是訪客口袋裡那台；開發者工具的手機模擬也別太信，它改了畫面寬度，沒換掉你的晶片。用中階實機看一次，錯覺會自己消失。

誤診三，幻覺套件。AI 一臉自信地呼叫不存在的套件、用已過期的 API，3D 函式庫版本變動快，這種情況特別常見。解法很樸素：要求它標註每個套件的版本，報錯時貼完整的錯誤訊息，不要用口頭形容。AI 幻覺的成因與應對值得整篇讀完。

誤診四，改不動的程式碼。生成的專案能跑，卻沒有模組邊界，加一個功能像在纏住的線團裡找線頭。問題出在事前沒要求結構；真的走到這一步，改用能直接讀寫專案的工具路線，AI Agent 的操作觀念是那個世界的入場券。

誤診五，原型變永久門面。三週的活動頁默默活了三年，沒有人敢關、沒有人會改。解法是第一天就寫下退場日，日曆上設個提醒，比任何記憶都可靠；原型沒有退場日，遲早變成負債。

診斷結果出爐：四條路怎麼選

五關的答案組合起來，出口就是四條路。先對照，再往下看細項。

↔ 左右捲動檢視完整表格

診斷結果	行動	延伸方向
五關全過	直接動工，照三個決定下提示	AI 網頁設計的完整流程
視覺過關，長期經營未過	先做原型，同時預排交棒計畫	品牌官網設計的系統化做法
功能型需求	轉正規開發或內容管理系統	AI 生成整站初稿再細修
沒有人能驗收	先補驗收能力，或改走可維護路線	驗收清單與實機檢查

第二條路最常見，值得多說兩句：3D 保留在首屏當印象，內容層搬到可長期經營的架構，兩者不必二選一。搬的手段很多，想先用問卷生成整站初稿再細修是成本低的起手式；品牌層的整合，品牌官網的設計全流程有系統化的拆解。第一條路的人，AI 網頁設計的完整實作能補齊執行細節。

第三條路的判斷別拖：功能型需求越晚轉正規，沉沒成本越大。展示型的探索可以慢慢磨，會員、金流與權限的骨架卻要第一天就放進對的架構，這兩件事的時間感完全不同。

第四條路常被跳過，其實最務實：沒有人能驗收時，先別急著生。把驗收清單交給未來的你或團隊裡的任何人，照著前面驗收段的視角走一遍；能力補起來再開始，總比上線後才發現沒人看得懂品質來得便宜。

過關才談執行：下提示前的三個決定

五關全過，才進得了執行段。下提示前先做三個決定，每個都直接影響你與 AI 要來回幾次。

生成的天性要先知道：模型傾向給你最完整的版本，而不是最剛好的版本；提示詞裡沒寫的約束，它通常不會主動補上，即使偶爾補了，也不該列入預期。提示詞的機制是約束條件，不是願望清單，這是三個決定共同的前提。

第一個決定，互動的觸發與強度。觸發寫清楚：掛在滾動上、跟著游標走、還是開放拖曳探索；強度寫上限：回饋多明顯、影響多大面積。少了這條，模型的預設行為是到處加互動，因為那看起來更「完整」。

第二個決定，裝置分級與降級條件。哪一級裝置看哪一版、場景何時暫停、素材何時延後載入，全部寫進規格。這條把驗收關的效能檢查提前到生成之前；事後補的成本，永遠比事前寫的高。

第三個決定，素材來源。用現成資產組裝，還是從空白生成：組裝的來回少、結果可預期；空白生成自由度高，代價是更多迭代與更多驗收。技術路線也內建在規格裡，CSS 3D 能解決的不拉 WebGL，現成嵌入優先於重寫渲染迴圈，判斷基準在裝置那關已經給過。

三個決定之外補一項：完成定義。什麼叫做完成、由誰確認、幾號確認，白紙黑字。沒有完成定義的專案會在「再改一版」裡失血，這句話對人類工程師成立，對 AI 生成的專案更成立。

三個決定寫成範本，之後每次沿用。開頭固定描述專案與受眾，中段放三個決定的答案，結尾放完成定義；範本會逼你補齊空白，空白補齊了，來回猜測的面積就縮小。這也是省用量最實際的一招，比換更貴的模型實在。

迭代的紀律也順手立下：一次只改一項，改完看結果再改下一項。看不懂程式碼的人最容易掉進的陷阱，是一次描述五個願望，結果壞了不知道壞在哪一項；小步走，每一步都說得出因果，來回總數反而更少。

願望句：做一個很有質感的 3D 品牌頁，手機也要順。

規格句：首屏一個低多邊形主角隨滾動旋轉，其餘元素靜止；手機載入精簡版，場景離開視窗暫停渲染；完成定義是中階實機首屏可見、建置通過、指定的人簽核。

已經有設計稿時，還有一條捷徑：從稿直接生成前端程式碼，少掉「用文字形容畫面」這整段來回；Google 生態裡從設計稿取碼的工作流是現成的參考。來回變少，用量跟著變少，與壽命關的成本帳在同一條線上。

什麼訊號出現，就該把原型交棒

收在壓軸的問題：原型做到什麼程度該換手。訊號有三個：內容需要常態更新、多人要協作維護、搜尋成為主要流量來源；任兩個成立，就把 3D 保留為首屏體驗，內容層搬去可長期經營的架構。

第三個訊號常被誤解。JavaScript 網站不等於無法索引，但關鍵文字若只活在畫布裡、互動後才出現，或渲染失敗時沒有 HTML 後備，搜尋和可及性兩邊都會被拖累；伺服器端渲染、預先產生與語意 HTML 都能改善，不必整棟換技術棧。

交棒的執行不複雜：內容先搬，網址對應設好，新站上線後舊原型轉為備援，觀察一個週期再下架；舊網址累積的拜訪也要安排去處，別讓它們撲空。3D 首屏若要保留，把它獨立成一段可控的體驗，別讓它跟內容層的更新互相綁架。

原型是驗證想法的工具，不是終點。想法被驗證，讓它畢業；沒被驗證，讓它退場。兩種都是好結局，最糟的是卡在中間不上不下。

回頭看，五個問題其實共用一個句型：資源有限，所以選擇有後果。注意力有限，所以只讓一個主角動；運算有限，所以手機先過關；時間有限，所以程式碼要帶得走；金錢有限，所以帳單要看得見；能力有限，所以驗收要有人扛。vibe coding 改變的是每一關的價格，不是任何一關的存在。

交棒之前，把原型期間學到的東西寫成一頁：哪些提示有效、哪些素材來源可靠、驗收時在哪裡翻過車。這一頁會成為下一個專案的起點，也是團隊裡能直接傳承的資產；工具帳號會還給平台，這頁筆記是自己的。

三個約定，比任何技巧清單耐用：

1. 只讓一個主角動：注意力的額度有限，全部在動等於全部沒在動。
2. 效能條件先寫進提示詞：降級、暫停、壓縮、延後載入，講在前面，不要事後補。
3. 給原型一個明確的退場日：活動結束、驗證完成或期限一到，就交棒或下架。

工具會更新，平台會退場，這兩件事在可見的未來都會繼續發生。五個問題問的是處境，不是工具規格；處境問清楚了，路線自然浮出來。帶得走的是決策紀律，不是某一年的某一套按鈕。