短答：可以做、能跑、上得了線。但「能跑」跟「能撐住業務、過得了 SEO、未來能維護」是三件事。
如果你正考慮「AI 工具現在這麼強，自己（或叫工讀生）vibe code 一個官網就好」，先把這篇看完。三個問題答得出來再動手，比動手後出包好。
問題一：安全性誰幫你看？
AI 寫的程式碼有兩種典型問題：
- 看似正常實則有洞：AI 知道有 SQL injection 這詞，但你叫它「做一個收件人查詢功能」，它寫的 query 不一定 parameterized。
- 沒做就是沒做：rate limit、CSRF token、HTTPS-only cookie、CSP header、檔案上傳 sanitize ── 你不主動要求，AI 不會主動加。
對個人玩具沒差。對商業官網，2024 年台灣個資法修正後，個資洩漏單一個案最高罰 1500 萬。如果你的官網有：
- 表單收使用者 email / 電話
- 會員系統
- 金流
而沒有人逐行看過安全細節，這就是個風險。
怎麼判斷你（或廠商）有處理：請對方列出 OWASP Top 10 中哪幾項做了什麼防護。答得出來叫做有意識。
問題二：SEO 細節 AI 真的會嗎？
SEO 不是「網站做出來自然就會被 Google 找到」。要 Google 找得到，需要：
- 正確的 SSR / SSG：純 client-side React 在 2026 還是有 SEO 風險
- 正確的 metadata：title、description、canonical、Open Graph
- 正確的 structured data：JSON-LD schema（Organization / Article / Breadcrumb / FAQ）
- 正確的 robots.txt + sitemap.xml：不要漏頁、不要重複、不要鎖到自己進不去
- 正確的 hreflang / 多語：搞錯會被 Google 當複製內容
- 正確的 image optimization：尺寸、格式、loading
- Core Web Vitals：
LCP < 2.5s、CLS < 0.1、INP < 200ms
AI 「知道」這些字眼。但實際做出來，每一項都要驗證。Vibe coding 最常見漏掉的：canonical 寫錯、hreflang 漏、structured data 格式不合 schema.org 規範、sitemap 沒更新。
判斷方法：上線後 1 週用 Google Search Console 看有沒有索引、用 Lighthouse 跑分、用 Schema Validator 檢查。三項都過再說。
問題三：6 個月後誰能維護？
這是最容易被忽略的問題。
Vibe coding 的特性是程式碼不是給人讀的，是給 AI 看 context 用的。半年後你要改個東西：
- 你（或 AI）讀不懂自己半年前寫了什麼
- 命名混亂（有時候是
userData、有時候user_info、有時候data） - 一個 function 1000 行，business logic 跟 UI 混在一起
- 沒有測試，改一個地方斷另一個地方
- 沒有文件，沒有 commit message 說明 why
要交接給其他工程師時，常常的結論是「打掉重做比修還便宜」。
判斷方法：請任意一個工程師朋友花 30 分鐘看一下 codebase，問他「如果要新增一個功能，他評估要多久」。如果答案是「我不知道，要先花 1 週理解」，這就是高維護成本。
那 AI-assisted Coding 呢？
AI-assisted coding 和 vibe coding 是被嚴重混淆的兩個概念，差別在工程師的介入程度。Vibe coding 的定義是：你跟 AI 描述需求，AI 寫程式，工程師不逐行檢查，跑得起來就好，跑壞再叫 AI 改。AI-assisted coding 的定義是：工程師用 AI 加速開發，但每一行 diff 都看過、命名都調整、邊界條件都檢查、測試都補上去。前者適合個人工具或快速 prototype，後者完全可以用來做 production 網站。以開發速度而言，AI-assisted coding 通常比純手寫快 2-3 倍，但 code review 時間幾乎相同，因為每一行還是要看；vibe coding 看似快 5-10 倍，6 個月後維護成本卻可能是 AI-assisted 的 5 倍以上。判斷廠商走的是哪條路，最簡單的方法是看 commit history：AI-assisted 的 commit 通常較細、有清楚的 message、會包含測試；vibe coding 的 commit 通常是大塊、message 像「fix bug」「update」、沒有測試也沒有 review trace。這個訊號比廠商怎麼說自己更可靠。
- Vibe coding：你跟 AI 講話，AI 寫，你不太看，跑得起來就好
- AI-assisted coding：工程師用 AI 加速，但每行 diff 都會看、會調整、會補測試、會檢查邊界
我自己每天用 Cursor + Claude，現在開發速度大概是 2022 年的 3 倍。差別在「AI 是我的工具」，不是「我是 AI 的監工」。
如果你的廠商說「我們用 AI 加速開發」，這沒問題、甚至應該。但問清楚「誰看 code、誰測試、誰負責安全」，這三個問題的答案如果都是「AI」，這就是 vibe coding，不是 AI-assisted coding。
三大問題快速摘要
| 問題 | 快速判斷方法 | 紅旗警示 |
|---|---|---|
| 安全性誰看？ | 請廠商列出 OWASP Top 10 中有哪幾項有防護 | 廠商說「AI 會處理」 |
| SEO 細節對了嗎？ | Lighthouse SEO 90+、Schema Validator 通過 | canonical 空白、sitemap 404 |
| 6 個月後誰維護？ | 找工程師朋友 30 分鐘 review codebase | 評估說「要 1 週才懂」 |
上線前要確認哪些項目？
上線前你（或廠商）能勾的數量決定風險：
- 跑過 OWASP 基本檢查（XSS / SQL injection / CSRF）
- 表單有 rate limit + CAPTCHA / Turnstile
- 個資處理符合台灣法規（蒐集告知、最小化原則、刪除機制）
- Lighthouse SEO 分數 90 以上
- Core Web Vitals 三項都過
- structured data 通過 schema.org validator
- sitemap.xml 提交給 Google Search Console
- 有人看過所有 commit
- 有 README / 部署文件
- 有 staging 環境
勾不到 5 個，再上線之前先補。
結論
AI 工具讓「做出能跑的網站」變得容易。但商業官網要面對的不只是「能跑」── 是 SEO、安全、可交接、長期維護。
如果你已經做了一個 vibe coded 站，想知道有哪些洞要補，可以丟連結來，我提供免費快速 review。
如果你還沒做、在評估自己 DIY 還是找人，那這三個問題的答案會決定下一步。
