Vibe Coding 是什麼？AI 程式設計入門與架站

相信不少人也曾經這樣想過：我腦裡有一個清楚的網站畫面，畫面裡有配色、有版面、有一段我想對客戶說的話，可是我打開電腦，看著那些密密麻麻的程式碼，整個人就僵住了。這個畫面，卡在腦裡好幾年。

Vibe Coding 是透過自然語言與 AI 工具描述需求、生成程式，再依執行結果反覆修正的開發方式。Andrej Karpathy 在 2025 年 2 月用這個詞形容一種幾乎不細讀程式碼、以對話和結果推進的個人開發狀態。如今這個詞也常被用來泛指 AI 輔助開發；它能降低原型門檻，但正式上線仍須檢查功能、資安、資料處理與維護。

這篇會從一個不寫程式的行銷顧問視角，為你拆解 Vibe Coding：它是什麼、跟你以為的架站工具有什麼不一樣、第一次上手要怎麼走、實務上會踩到哪些坑、還有最關鍵的，用這種方式架出來的網站，SEO 到底能不能顧。如果你對生成式 AI 的底層邏輯還不熟，可以先看過這篇 生成式 AI 基礎指南，回頭會更好理解。

Vibe Coding 是什麼？把這個詞拆開來看

Karpathy 的原始貼文重點是用自然語言持續引導 AI，依執行結果決定下一步；他描述的是個人使用方式，不是所有 AI 輔助開發的正式定義。本文採較廣義的用法來說明原型、測試與上線流程，重要功能仍要能由人檢查與驗收。

這跟你過去認識的「寫程式」是兩個物種。傳統寫程式，腦袋裡要有完整的邏輯骨架，然後用嚴格的語法把骨架翻譯成機器看得懂的文字，一個括號錯了、一個分號漏了，整頁就壞掉。Vibe Coding 反過來，你腦袋裡要有的是畫面和意圖，翻譯的工作交給 AI。你的工作從「打字員」升級成「導演」。

換句話說，Vibe Coding 的本質是三件事的組合：

• 意圖表達：你用人話描述你想要的結果，而不是用程式語言描述過程。
• AI 生成：大型語言模型把你的人話翻譯成可執行的程式碼，一次給你一整段。
• 迭代修正：你看結果、給回饋、AI 再改，這個循環可以跑十幾輪直到你滿意。

這三件事讓不熟程式的人也有機會先做出可預覽的網站原型，部分簡單頁面也可發布。所需時間與可用程度取決於需求、工具與驗收；表單、帳號、付款或資料庫投入正式使用前，仍要測試失敗情境與資料安全。

但得先幫你建立一個正確的心態，免得你抱著不切實際的期待進場，結果摔得很慘。Vibe Coding 不是魔杖，它不會你隨便講兩句就吐出一個完美的成品。它更像是一個非常聽話、非常耐操、但需要你把話講清楚的助手。你講得越清楚，它做得越準；你講得越含糊，它就僅能瞎猜。所以真正決定你 Vibe Coding 成敗的，不是你會不會寫程式，而是你會不會把腦裡的畫面翻譯成清楚的文字。這個能力，行銷人其實比工程師更有優勢，因為行銷人本來就在做「把抽象的價值講成消費者聽得懂的話」這件事。Vibe Coding 僅是把同一個能力，換了一個對象：你現在要把需求講給 AI 聽。

為什麼現在，不會寫程式的人突然能架站了

你心裡一定有個疑問：自然語言跟 AI 對話這件事，ChatGPT 2022 年就有了，為什麼到 2025、2026 才突然變成「人人能架站」？

因為中間補上了三塊關鍵拼圖。第一塊是模型寫程式的能力跨過了實用門檻。早期的大型語言模型會寫程式，但寫出來的東西常常是「看起來對、跑起來錯」，你拿沒辦法。新一代的模型不僅會寫片段，還能理解一整個專案的結構，能讀懂你現有的檔案、能自己開檔案、能跑測試、看到錯誤訊息會自己改。

第二塊是工具的執行環境成熟了。AI 不僅是吐一段文字給你叫你自己貼去編輯器，它現在直接住在你開發環境裡，可以幫你建檔、裝套件、啟動伺服器、甚至直接預覽成果。你從頭到尾不太需要碰終端機。如果你對「CLI（命令列）」這個詞還有點怕，這篇 CLI 入門教學 可以幫你把心理障礙拆掉一半。

第三塊，也是跟行銷人最有關的一塊：部署變簡單了。以前做完一個網站，要煩惱網域、主機、FTP 上傳、資料庫設定，每一關都能把一個非技術人勸退。現在不少 Vibe Coding 工具做完直接幫你一鍵上線，給你一個公開網址，你馬上能傳給客戶看。

這三塊拼圖同時到位，才讓「用講的就把網站做出來」從好玩變成可靠。根據 主流 AI 工具的整理，光是 2025 到 2026 這一年多，鎖定「讓非技術者用 AI 做產品」的工具就爆發了一輪。這不是單一產品的運氣，是一整個品類成熟了。

還有一個容易被放過的背景：模型與工具的取得門檻降低，反覆試作比過去便宜許多，但仍要留意各工具的 token、credit 或方案限制。當試錯比過去便宜，反覆迭代就不再是捨不得用的奢侈，而是變成像喝水一樣自然的日常動作。你不用再為了「這句指令值不值得送出去」猶豫半天，你可以大方地試、大方地錯、大方地改。這種低摩擦的試錯環境，才是 Vibe Coding 真正能普及的土壤。沒有人會在一個每次嘗試都成本高昂的環境裡，培養出直覺和手感。

Vibe Coding 跟傳統開發、跟現成的架站工具，到底差在哪

這是最多人搞混的地方。很多人一聽到 Vibe Coding，第一個反應是：「這不就跟 Wix、跟 WordPress 的 Elementor 那種拖拉架站工具差不多嗎？我十年前就能不寫程式架站了啊。」

差很多。把三種路線放在一起比較，你會立刻明白界線在哪。

看出關鍵差異了嗎？拖拉式架站工具解放了你的手，你不用寫程式；Vibe Coding 解放的是你的想像力，你不用寫程式，而且不用被工具預設的版型綁死。

換個比喻：拖拉式架站工具像是在 IKEA 買現成傢俱，組合方式廠商都幫你設計好了，你僅能從選單裡挑；Vibe Coding 像是你身邊跟著一個聽得懂人話的木工師傅，你說「我想要一張靠窗、能收納、桌腳是圓弧形的書桌」，他就幫你做出來，還能改到滿意為止。這兩件事的彈性完全不在同一個層級。

與其問 Vibe Coding 會不會取代架站工具，不如先確認需求偏向快速套版還是客製開發。可用AI 網站建立工具實測比較拖拉式與對話式工具，再參考架站平台挑選指南，把價格、客製彈性與長期維護成本一起納入評估。

現在主流的 Vibe Coding 工具長怎樣

把目前市面上你比較會接觸到的工具，分成三個流派。這個分類很重要，因為不同流派適合不同的人，選錯流派你會覺得 Vibe Coding 很難用，其實僅是用錯了地方。

流派一：住在程式碼編輯器裡的 AI 助手

這一派的代表是 Cursor、Windsurf，還有 GitHub Copilot。它們的長相是一個「看起來像寫程式的編輯器」，但你在裡面可以直接跟 AI 對話，AI 會幫你改檔案、建專案。它們的能力最強、彈性最大，代價是你多少要看得懂專案結構。對完全不碰程式的行銷人，這一派進場門檻稍微高一點，但一旦跨過去，能做的事最多。

流派二：命令列形式的 AI 程式代理

這一派不用打開圖形介面，而是透過文字視窗跟 AI 互動。Claude Code 是常見工具之一，可以讀取專案結構、修改程式並執行測試；OpenAI Codex 也能承接較完整的開發任務，細節可參考〈OpenAI Codex 完整介紹〉。Claude Code 的入門操作則可參考〈Claude Code 教學〉。這類工具能主動探索程式碼，但交付前仍要檢查差異並執行必要測試。

流派三：對話即上線的網頁應用產生器

這一派對行銷人最友善，也是 2025 年聲量快速上升的一塊。你打開一個網頁，用打字描述你想要什麼樣的網站或網頁應用，工具直接給你一個可以預覽、可以一鍵發布的成果。v0、Bolt、Lovable、Replit Agent 都落在這個光譜上。你不用管專案結構、不用管檔案，你的整個世界就是那個對話框和右邊的預覽畫面。

這幾個名字的差異比想像中大。Lovable 走全套式全端平台路線，v0 深度綁定 Next.js 與 Vercel，Bolt 則把開發環境整個搬進瀏覽器，三家的計價單位也不能直接換算。AI App 生成器三強比較用一張速覽表加上五種情境的選擇框架，把「該選哪一個」拆解成可以依需求回答的判斷題，進入這個流派之前先把比較讀過，可以少走不少彎路。

對話式工具適合快速驗證單頁或小型應用，但不能概括說它們無法處理多頁、後台或深度整合。以 v0 為例，官方文件已列後端端點、資料庫、驗證與 CRUD 工作流程。需求變複雜時，應逐項測試權限、資料、部署、可移植性及維護成本，再決定沿用現有工具或轉往其他開發方式。

三個流派沒有優劣，僅有適不適合。下面用一個表幫你快速對照：

建議是：如果你是完全的初心者，從流派三切入，一個下午就有成就感；等你做過幾個成品，想往更複雜的功能走，再往流派二和流派一移動。一步一步來，不要一開始就挑最硬的。

行銷人第一次用 Vibe Coding 架站：七步流程拆解

講了這麼多觀念，來點實際的。用一個行銷人最常見的需求，把整個流程走一遍：你要做一個活動報名頁。假設你完全不會寫程式，你會怎麼用 Vibe Coding 把它做出來？

第一步，先把需求講清楚。動手前列出頁面給誰看、活動條件、報名後的流程、需要哪些欄位與成功標準。描述越具體，後續越容易判斷 AI 產出是否符合需求；但結果也受工具能力、資料品質、測試和維護影響，無法用「八成」分配成敗。

第二步，挑一個對話式工具開始。如果你是第一次，選流派三的任一個都好。不要糾結哪個最好，先做出第一個成品最重要。工具會換，但你學到的「怎麼跟 AI 描述需求」這個能力是帶著走的。

第三步，用第一段指令把骨架生出來。你的指令不用很技術，像這樣就夠了：「我要一個活動報名頁，主視覺是一張圖配一個大標題，下面有三個活動亮點的卡片，最底下是報名表單，有名字和 email 兩個欄位。風格要乾淨、留白多、主色用藍色。」你會發現 AI 在幾秒內就給你一個有模有樣的版面。這個當下，大多數人的反應是「哇，真的可以」。這個哇，就是 Vibe Coding 的魔力起點。

第四步，逐項修正，一次僅改一件事。第一版一定不完美。但訣竅是不要一次丟十個修改需求，因為 AI 容易顧此失彼，改了 A 壞了 B。你一次僅說一件事，例如「把報名按鈕的顏色改成更深的藍，然後字放大」，改好、確認了，再說下一件。這個節奏看起來慢，實際上比一次全改更快，因為你不會陷入「不知道是哪個指令弄壞了什麼」的混亂。

第五步，補上行為邏輯。骨架和外表弄好之後，你要處理「互動」。報名表單送出之後要發生什麼事？是跳一個感謝頁，還是寄一封確認信？你用一句話告訴 AI，例如「表單送出後顯示一個感謝訊息，並把報名資料存起來」。AI 會幫你把這段邏輯接上。這裡要稍微有耐心，因為互動邏輯是出錯率最高的地方，你可能要來回幾次。

第六步，預覽並修正手機版。桌機上看起來完美，不代表手機上正常。你一定要切到手機預覽，檢查字會不會超出、按鈕好不好按、圖片有沒有變形。手機已是多數人上網的主要載具，活動頁的轉換如果手機體驗糟糕，前面做得再漂亮都白費。

第七步，發布並追蹤。確認沒問題，一鍵發布。發布之後你的工作還沒結束，你要把連結傳給幾個人實測，看他們在哪一步卡住、哪裡點不下去。這些回饋是你下一輪修正的依據。一個好的報名頁從來不是一次做好的，是改出來的。

完整可複製的專案級指令範例

第三步給你的指令是精簡版，目的是讓你看懂結構。真正要開工時，建議把第一段指令升級成「專案級」的完整開場：一次就把整個頁面的規格講完，不要擠牙膏式的一句一句補。擠牙膏的給法，AI 每一輪都在猜你還沒說出口的部分；一次給齊，它生第一版就有足夠的上下文，你來回修正的次數會少很多。這份範例延續活動報名頁的例子，【】裡的內容換成你自己的，整段複製貼進支援網頁預覽與發布的對話式工具（v0、Bolt、Lovable、Replit Agent 這類）就能開始：

【專案】我要一個活動報名頁，單頁式，手機瀏覽為主。
【對象】來報名的是中小企業的行銷與業務主管，他們最在乎
講者背景、議程內容，以及報名後能不能開統一發票。
【頁面內容，從上到下】
1. 主視覺區：一張活動圖（我自己上傳），左邊大標【活動名稱】，
   右邊副標【一句話說明這場活動的賣點】。
2. 三張亮點卡片：「講者陣容」「議程重點」「歷屆成果」，
   每張一個 icon 加一段 40 字內的說明。
3. 議程表：四個時段，欄位是時間、主題、講者。
4. 報名表單：姓名、email、公司名稱、是否需要統一發票
   （勾選後才出現統一編號欄位）。
5. 頁尾：主辦單位名稱與聯絡 email。
【風格】乾淨、留白多，主色深藍 #1a365d，輔色淺灰，
不要動畫、不要彈出式視窗。
【行為】送出前驗證姓名與 email 必填、email 格式正確；
送出成功後在同一頁顯示感謝訊息，不跳轉，並將報名資料
（姓名、email、公司名稱、發票需求與送出時間）存進
可匯出的報名清單。
【限制】我僅有一張主視覺圖，其他區塊用配色和文字撐；
先做手機版，再做桌機版。

這份範例做對三件事：講結果不講技術（描述頁面長什麼樣、動起來怎樣，不指定框架）、給了對象與情境（誰在看這個頁面、他們在乎什麼）、把限制先講白（僅有一張圖、不要彈窗）。這三件事對應到後面「把需求講清楚」那一節的檢查點，你可以先用範例建立手感，再回頭看原理。先畫清楚一條界線：這份範本適合原型驗證，正式對外收個資上線前，表單後端、資料保存與匯出權限須經工程師與合規確認，這條線跟後面第四個坑談的安全底線是同一條。等你的專案做到第二個、第三個頁面，這段開場指令就值得留下來重用：若工具支援專案指示檔（如 AGENTS.md），可以存成讓 AI 每次自動讀取的指示檔，做法參考〈AGENTS.md 入門〉；工具不支援的話，存成一份自己的筆記、每次開新對話手動貼上也行。

截圖與報錯直接丟回去：除錯工作流

第五步提過，互動邏輯是出錯率最高的地方。真的卡住時，多數人敗在同一件事：把錯誤描述得太客氣。「按鈕好像壞掉了」這種用自己的話轉述的描述，AI 僅能跟著猜。除錯的正確姿勢，是讓 AI 看到跟你看到的同一份東西。三種輸入，照效力排給你：

• 報錯訊息原封不動貼上。終端機視窗或瀏覽器開發者工具（在頁面按右鍵選「檢查」，切到 Console 頁籤）出現的紅字，整段複製進對話，不要翻成中文、不要節錄。訊息裡的檔名、行號、錯誤代碼是 AI 定位問題的錨點，你刪掉哪一段，它就少一條線索。Claude Code 官方文件的除錯建議（2026 年 10 月查）也是同一套：告訴 AI 重現問題的指令、出錯前做了哪些操作、這個錯是每次都出現還是偶爾出現，三項給齊，等於提供更完整的線索，提高 AI 定位問題的機會。
• 畫面不對，用截圖講。「按鈕跑到奇怪的位置」你形容十分鐘，不如一張截圖。v0 的官方常見問題明寫輸入可以是文字描述、截圖或設計稿；Claude Code 也支援把圖片直接貼進對話，官方文件的示範句就是「這是報錯畫面的截圖，原因是什麼」。截圖前在圖上標註預期的位置，畫個箭頭、圈起來都好，AI 對「預期與實際」的落差會抓得更快。
• 補上預期與實際的三句話。我做了什麼、預期發生什麼、實際發生什麼。這三句的作用，是把 AI 的注意力從「修掉報錯」拉到「修對行為」，因為有些問題不會報錯，畫面就是安安靜靜地不對。

卡住的時候不用一邊想措辭一邊丟訊息，直接套下面的範本，填完送出：

【我做了什麼】在手機版預覽按下「送出報名」。
【預期】畫面出現感謝訊息，報名資料存進清單。
【實際】畫面沒有反應，console 出現紅字。
【報錯原文】（完整錯誤訊息貼這裡，不要節錄）
【截圖】（附手機版畫面截圖，標註預期的位置）
請先說明你判斷的原因，再做最小幅度的修改，
其他已經正常的功能不要動。

範本最後那句「先說明原因、最小幅度修改」是刻意加的。要 AI 先講出判斷，你就有機會在它動手前發現理解錯誤；限定最小幅度，是避免它順手重寫一大片，把本來正常的功能改壞。這個紀律搭配一次僅修一個問題，卡關時比較容易看清問題出在哪。真的連修幾輪都救不回來，就退回上一個確認正常的版本，把失敗的修改過程整段貼給 AI，請它重新診斷，通常比繼續疊加修改快。

完成七步後，至少能得到可供實際測試的第一版。是否達到可交付品質，要檢查表單資料是否送達、手機與鍵盤操作、錯誤處理、權限及日後維護；不能單靠步驟數推論它與專業開發成果相當。

把需求講清楚，是 Vibe Coding 真正的核心能力

很多人以為 Vibe Coding 的關鍵是「選對工具」，實務操作下來的看法完全不一樣。工具的差距沒有你想的那麼大，真正決定成品好壞的，是你把需求描述出來的能力。同一個工具，給兩個人用，一個做出粗糙的半成品，一個做出精緻的成品，差別幾乎都在那句指令怎麼寫。

為什麼？因為 AI 沒有讀心術。你腦裡那些「反正就是那個感覺」「你應該懂吧」的潛台詞，AI 一個字都收不到。它僅看得到你打出去的字。你給它的資訊越具體，它回你的東西越接近你想要的；你給得越模糊，它就僅能用機率去猜，猜歪了你就得重來。

把一個好指令該具備的東西，整理成四個檢查點。你每次送出指令前，在腦裡過一次這四個，比較能減少 AI 猜測：

• 講結果，不講過程：告訴 AI 你要「長什麼樣、動起來怎樣」，不要試圖指揮它用什麼技術。你說「報名按鈕要顯眼、點下去要跳出確認框」，比你說「用 JavaScript 寫一個 onclick 事件」更有效，因為你根本不確定最好的做法是什麼，而 AI 可能知道。
• 給情境和對象：同樣一個活動頁，給企業客戶看跟給一般消費者看，是兩個世界。告訴 AI 這個頁面的讀者是誰、他們在乎什麼，它連用詞和排版都會跟著調整。「這是給中小企業主看的 B2B 研討會報名頁，語氣要專業但不冷硬」遠勝於僅說「做一個報名頁」。
• 說清楚限制：你有哪些素材、不能用什麼、風格底線在哪，這些都要講。例如「我僅能提供一張產品照，其他用配色和文字撐起來」「不要用彈出式視窗」。限制講清楚，AI 才不會給你一堆你用不了的東西。
• 一次一件事，先求小步前進：前面在流程裡已經講過這個原則，這裡再強調一次，因為它真的太重要。貪心一次改十件事，幾乎一定會亂。寧可十次指令每次改一點，也不要一次大爆炸。

你可以把這四個檢查點想成 Vibe Coding 時代的「打字速度」。以前寫程式，比的是誰打字快、誰語法熟；現在比的是誰能把一個模糊的感覺，翻譯成清楚、可執行、AI 聽得懂的需求。這個能力跟你的產業知識、跟你對使用者的理解綁在一起，是 AI 沒辦法替你練的。

還有一個小訣竅：當 AI 給你的結果不對，先別急著否定重來，試著問它「你剛剛是怎麼理解我的需求的」。你會很驚訝，它常常會把它理解到的版本講出來，而你一聽就會發現「啊，原來你以為我要的是這個」。找出理解落差的那一塊，再精準補上，比你從頭重講一次快得多。這個來回，就是 Vibe Coding 最值得練的對話技巧。

老實說，使用 Vibe Coding 會踩到這些坑

前面講得好像很美好，現在來澆點冷水。從實際操作的回饋來看，真實體驗通常是：前八成很爽，後兩成很痛。把痛的那兩成整理出來，你才不會重蹈。

第一個坑，AI 會信心滿滿地寫出看起來對、其實錯的程式。這就是大家說的 AI 幻覺。它不是在唬爛你，它真的「以為」這樣寫是對的，因為它根據機率拼出一段最像答案的程式碼。問題是，最像答案不等於是答案。你跑起來發現按鈕沒反應，翻開程式碼才發現它引用了一個根本不存在的方法。這種狀況在牽涉到串接第三方服務、或者比較新的 API 時特別容易出現。想深入了解這個現象，可以讀這篇 AI 幻覺完整解析。應對的方法是：不要全信，要驗證。跑不起來就讓 AI 看錯誤訊息，可把問題範圍縮小，再逐步修正。

第二個坑，你會很快做出一個能動的東西，然後停在一個進不去的瓶頸。Vibe Coding 的前期速度快到讓人飄，你一個下午就有一個像樣的網站。但當你想要加比較複雜的功能，比方說會員系統、金流串接、權限管理，你會發現 AI 開始東卡西卡，每一個改動都牽動一堆你根本看不懂的地方。這時候你才意識到：你做了一個你沒有能力自己維護的東西。這個落差，是 Vibe Coding 最誠實也最殘酷的一課。

第三個坑，紀錄沒留好，回不去。很多人用 Vibe Coding 的習慣是「想到什麼就改什麼」，改著改著，突然某個之前好好的功能壞了，你想退回上一版，卻發現沒有上一版可以退。因為你從頭到尾沒有在做版本控制。實務上建議的習慣是，每改一個段落、每確認一個功能正常，就存一個版本紀錄。這件事不性感，但能救你於水火。

第四個坑，安全意識幾乎是零。這點必須特別嚴肅看待。當你用 Vibe Coding 處理表單、處理使用者資料，AI 預設給你的程式碼常常沒有把資安防護做好。它不是故意的，它僅是把「讓功能跑起來」當成第一目標。但收了別人的 email、名字、甚至電話，這些就是個資，你要負責。實務上的底線是：若牽涉到收錢、收個資、接既有系統，就不該自己 Vibe Coding 硬幹，一定找工程師確認。把這條線畫清楚，你才能放心享受 Vibe Coding 的速度。

還有一個比較隱性的坑，叫「成就感陷阱」。Vibe Coding 前期給你的回饋太快太爽了，你打一句話，畫面立刻有變化，這種即時滿足會讓人上癮。上癮的後果是，你會一直加功能、一直改外觀，停不下來，最終做出一個什麼都有、卻沒有一樣做到位的網站。實務上值得建立的紀律是：每做完一個段落，就停下來問自己「這個功能，對來這個頁面的人真的有必要嗎」。把這個問題當成剎車，你才不會被速度帶著走，做出一個自己都說不清楚重點的東西。

什麼情況，你真的不該用 Vibe Coding 自己來

知道什麼時候用，跟知道什麼時候不用，一樣重要。把「不建議自己 Vibe Coding」的情境列出來，不是要潑你冷水，是要幫你把力氣花在對的地方。

• 牽涉金流與交易：收信用卡、串接金流服務，一步錯就是錢的問題，這不是練習場。
• 會儲存大量個資：會員資料庫、訂單資料，資安責任在你，別用 AI 預設碼硬上。
• 要接既有複雜系統：公司已有的 ERP、CRM、舊資料庫，結構通常很深，AI 猜不準。
• 需要極致效能：高流量、即時性強的應用，效能 tuning 還是得靠專業工程師。
• 長期會一直長大的產品：如果這個東西未來會變成一個持續擴張的正式產品，早一點把架構交給專業的人，比後來打掉重做更省。

那什麼時候超適合自己用 Vibe Coding 來做？

• 活動報名頁、產品介紹頁：一次性、週期性的活動頁，自己做最快，改文案也不用等工程師。
• 個人作品集、品牌官網初版：先做出一個能見人的版本上線，後續再慢慢打磨或委外升級。
• 內部工具、資料整理小工具：團隊自己用的表單、報表整理、自動化腳本，用 Vibe Coding 做很靈活。
• 驗證想法的原型：你有一個產品點子，想先做個原型給客戶看反應，Vibe Coding 是最便宜的驗證方式。

如果你最終決定這件事還是交給專業的，那也完全沒問題。Vibe Coding 不是要消滅工程師，它是給了你一個「能自己先做、做不了再找人」的選項。這個選項本身就是巨大的進步。

而且就算你最終找人做，你先用 Vibe Coding 打磨過一遍，也是有好處的。你帶著一個具體的、會動的原型去找工程師，跟他們溝通的精準度會高非常多。工程師不用再憑空想像你要什麼，他們看著你做的半成品就知道方向。這能省下大量來回確認的時間，也大幅降低「做出來不是你要的」這種最痛的浪費。換句話說，Vibe Coding 不僅能讓你自己做，還能讓你成為一個更稱職的甲方，這個價值很多人沒想到。

Vibe Coding 架出來的網站，SEO 三個基本功不能漏

講到這裡，要把話題拉回最關鍵的一件事：SEO。很多行銷人用 Vibe Coding 做出網站之後，滿心歡喜地上線，等了一個月發現 Google 搜不到、流量是零，才驚覺自己僅做了「看得見」的部分，沒做「被看見」的部分。

網站是否能被搜尋引擎發現、索引及呈現，取決於頁面可抓取與可渲染的內容、技術設定、內容品質及其他訊號；製作工具本身也可能影響這些條件。AI 生成頁面上線後，先用 Search Console 檢查索引與實際呈現，再處理標題、內容、內鏈及體驗，不能保證做完清單就取得排名。

第一，網站速度。AI 生成的程式碼可能沒有主動控制效能：圖片未壓縮、多餘程式庫或過重動畫都會增加載入負擔。Google 的排名系統會使用 Core Web Vitals 等網頁體驗訊號，但它們不是單一決勝因素；速度也會直接影響使用體驗，web.dev 的 Why does speed matter? 對此有完整說明。Vibe Coding 成品上線前要用測速工具實測並處理明顯瓶頸。想知道速度與 SEO 的關係，可參考 AI 時代 SEO 全攻略。

第二，內容要準確、有用且能說明依據。用 AI 產生網站文案本身不違反 Google 政策；問題在於大量產出缺乏價值、未校對或為操弄排名而建立的內容。AI 可以協助建立骨架，但活動頁的具體條件、品牌差異、可驗證案例與專業判斷仍要由負責人補齊並審核，可對照 Google 對生成式 AI 內容的官方指引。

第三，檢查搜尋引擎能否抓取與索引頁面：確認重要 URL 可存取、主要內容與連結在渲染後可見、canonical 與 sitemap 符合實際網站，再檢查清楚且獨特的標題、描述、網址、內部連結及行動裝置體驗。AI 可以協助列清單或改程式，但設定完成後仍要在 Search Console 與實際頁面驗證；meta description 主要協助搜尋結果摘要，不能保證排名。

說到底，Vibe Coding 解決的是「做出網站」這一步，它沒有、也不該被期待解決「網站被看見」這一步。這兩步是不同的事，而且第二步往往比第一步更花心力、更值得投資。

把上面三個基本功進一步展開成下面的檢查表，把每個項目的「預設狀態」跟「你該補上的事」對照出來，你照著走一遍，就等於做完了最基本的 SEO 體檢：

這張表不是要嚇你，是要讓你知道：用 Vibe Coding 做完網站，僅是完成了上半場。下半場的 SEO，才是決定這個網站會不會替你帶來生意的關鍵。而下半場這件事，跟你用什麼工具架站一點關係都沒有，跟你的觀念和紀律有全部的關係。

給行銷人的三步起步清單

讀到這裡，你腦裡應該對 Vibe Coding 有清楚的圖像了。這裡不給龐大到讓人卻步的計畫，僅給你三個今天就能做的動作。

1. 挑一個最小的真實需求，動手做。不要拿「架一個完整的品牌官網」當你的第一次，那太大、太容易挫敗。挑一個本來就要做的事，例如下個月的活動報名頁、或一個產品介紹頁，用流派三的任一個工具，花一個下午把它做出來。做完，你就跨過了最大的心理門檻。
2. 邊做邊寫下你的需求描述。把你每次給 AI 的指令存下來，像寫筆記一樣。你會慢慢發現，哪些描述方式 AI 容易聽懂、哪些會讓它走偏。這個「需求描述的能力」，是 Vibe Coding 時代最值錢的新技能，而且僅有靠實作才練得起來。
3. 上線之前，跑一次 SEO 檢查。至少做三件事：測一次載入速度、把每個頁面的標題和描述補上、確認手機版體驗順暢。這三件事不花你多少時間，卻決定了你的網站是「做完了」還是「真的上線了」。

工具會一直換，今天的主流可能明年就被取代，但有些東西不會變：你把需求講清楚的能力、你對真實使用者體驗的判斷、你為真人寫內容的堅持。這些才是你帶得走的資產。

這裡用一個觀念作結。Vibe Coding 最大的價值，不在於它讓你省了多少錢、省了多少時間，而在於它把「把想法變成成品」這件事的門檻，降到了歷史最低點。過去無數個停在「我有一個點子，可是我不會做」的想法，現在第一次有了被實踐的機會。這對行銷人尤其珍貴，因為行銷人最不缺的就是想法，最缺的向來是把想法落地的能力。

當然，做出成品僅是起點。一個網站能不能替你帶來客戶、能不能在搜尋結果裡被看見，靠的還是紮實的 SEO 與內容經營，這些是沒有捷徑的慢功夫。把 Vibe Coding 當成你加速起步的引擎，把 SEO 和真實經驗當成你長期續航的燃料，兩者搭配起來，你才算真的把這個時代給你的新工具，用對了地方。

Vibe Coding 給了你一把過去僅有工程師才有的鑰匙。怎麼用這把鑰匙打開什麼樣的門，決定權現在在你手上。現在，就去開你那扇門吧。