上週五晚上,我盯著螢幕上剛生成的 350 行代碼,陷入了沉思。
這是 Antigravity 在 30 秒內幫我寫出來的「使用者儀表板」模組。我只是在對話框裡打了一句:「幫我做一個 React Dashboard,要能顯示三種圖表,可以切換時間區間。」然後按下 Enter。螢幕開始滾動,Code 像水龍頭的水一樣流出來,Component、Hook、API 串接,一氣呵成。我的第一個反應不是興奮,而是焦慮。
「這些代碼...我該怎麼 Review?」我習慣性地想要逐行檢查,但當我看到第 50 行的時候,已經忘記前面 10 行在幹嘛了。更糟的是,Cursor 在旁邊又提示我:「要不要也順便加上測試?」我點了同意,又是 200 行測試代碼瞬間出現。
這就是所謂的 Vibe Coding。你給 AI 一個「感覺」(Vibe),它給你一整包實作。速度快到讓你來不及思考,卻又不得不停下來問自己:「這些 Code 真的對嗎?我該相信它嗎?」
最近幾週,我一直在用 Antigravity 這類 Agentic Tool 開發,那種「我只要說說話,Code 就跑出來」的感覺確實很爽。但隨之而來的一個大問題是:當 Code 產生的速度比我閱讀的速度還快時,Code Review 該怎麼做?
為什麼傳統 Code Review 已經不夠用了？
以前我們做 Code Review，很大一部分精力花在檢查語法錯誤、變數命名、縮排格式這些細節上。但在 Vibe Coding 的時代，這些工作其實 AI 已經做得比大部分人類都好了。
現在的問題變成了：
- 產量爆炸：AI 一次噴出 300 行代碼，你真的有力氣一行一行看完嗎？
- 邏輯黑箱：AI 寫出來的代碼可能「剛好能跑」，但背後的邏輯是否健壯？有沒有藏著奇怪的 Bug？
- 依賴性：如果這段代碼以後壞了，我們看得懂嗎？還是得依靠 AI 再重新生成一次？
Vibe Coding 時代的新 Review 策略
經過這段時間的摸索，我覺得 Code Review 的重心需要從「檢查語法」轉移到「檢查意圖」和「驗證行為」。以下是我整理的幾個新方向：
1. Review 你的 Prompt，而不是 Code
這聽起來很違反直覺，但在 Vibe Coding 中，Prompt 其實就是源代碼（Source Code），而生成的代碼只是編譯後的產物。
如果生成的代碼有問題，很多時候是因為我們的 Prompt 下得不夠精確。Review 的時候，不妨問問自己：
- 這個 Prompt 是否清楚描述了邊界情況（Edge Cases）？
- 我有沒有告訴 AI 這裡需要考慮效能？
- 如果下次還要修改這個功能，我還能用同樣的邏輯描述嗎？
2. 從「看代碼」轉向「驗證行為」 (Behavior-Driven Review)
與其花 30 分鐘去讀懂 AI 寫的複雜正則表達式，不如花 10 分鐘寫幾個測試案例去測它。
現在我的 Workflow (特別是在 Antigravity 的 Agent 模式下) 是這樣的：
- 讓 AI 寫功能代碼。
- 讓 AI 寫這個功能的單元測試（Unit Test）。
- 我 Review 測試的邏輯：測試案例是否覆蓋了足夠多的場景？是否包含了錯誤輸入？
- 跑測試，如果綠燈，我就對這段 Vibe Code 有信心了。
測試代碼比實作代碼更容易閱讀，也更能反映出我們對功能的預期。
3. 人類是最後的「安全濾網」
AI 很聽話，但它沒有「常識」。它可能會為了滿足你的要求，寫出 SQL Injection 的漏洞，或是把 API Key 直接寫死在代碼裡。
這時候，人類 Reviewer 的價值就體現出來了。我們不需要糾結縮排，但我們必須檢查：
- 安全性：有沒有顯顯的安全漏洞？
- 隱私：有沒有不小心把個資送給了第三方？
- 幻覺：AI 有沒有引用了不存在的 Library 或函數？
就像是自動駕駛，AI 負責開車，但我們的手永遠不能離開方向盤，隨時準備在它可能會撞車的時候接手。
4. 可維護性檢查：這段 Code 我們養得起嗎？
這是我覺得最重要的一點。AI 生成的代碼有時候會過度複雜化（Over-engineering）。
Review 的時候，請試著讀一段最核心的邏輯。如果你發現你需要花很多力氣才能看懂它在幹嘛，那這段代碼就是不合格的——即使它能跑。
因為 Code 是要給人維護的（至少在 AI 能夠全自動維護之前）。如果你現在看不懂，三個月後出 Bug 了，你絕對會想殺了現在的自己。讓 AI 重寫，要求它「Simplify this logic」或「Add comments explaining why」，直到你覺得「這段代碼長得像人寫的」為止。
用「流程設計」來減少人工 Review
如果你覺得每一次都要人工檢查還是太累，那我們可以試著「設計流程」，讓錯誤在進到你眼睛之前就被擋下來。這也是目前很多團隊正在嘗試的 "Process-Driven Correctness"。
TDD for AI：讓測試成為規格書
與其讓 AI 直接「寫 Code」，不如先讓它（或你自己）「寫測試」。 當測試代碼（Test Code）先被確立下來，它就變成了一份「可執行的規格書」。
流程會變成這樣：
- 定義規格：告訴 AI「我要一個 function，輸入 A 會得到 B，輸入 C 會報錯」。
- 生成測試：讓 AI 寫出 failing tests（紅色）。
- 生成實作：讓 AI 寫出 implementation code 來讓測試通過（綠色）。
在這個流程中，如果測試通過了，理論上代碼的行為就是正確的。你的 Review 重點只需要放在「測試寫得對不對」上，而不需要去糾結實作的每一行。這能大幅減少大腦的負擔。
Agentic Review：讓 AI 來 Review AI
現在已經有一些工具（或是像 Antigravity 這樣內建 Agent 的環境），可以讓另一個 LLM 扮演「嚴格的 Reviewer」。
你可以設定一個 Prompt，專門用來找碴：
"你是一個資深的資安工程師，請檢查這段代碼有沒有 SQL Injection 或 XSS 的風險。如果有，請指出具體行數並給出修正建議。"
在你自己開始讀 Code 之前，先讓這個 "Critic Agent" 跑一遍。它通常能幫你抓出 80% 的低級錯誤，你只需要處理剩下那 20% 真正需要人類智慧的設計問題。
總結
Vibe Coding 絕對會改變我們開發的節奏，但它不會讓工程師失業，反而會讓我們的角色升級。
我們從「搬磚工人」（寫 Boilerplate Code）變成了「建築師」和「質檢員」。我們不需要再親自砌每一塊磚，但我們必須確保整棟樓不會倒。
下一次當你在 Review AI 寫的 Code 時，試著退後一步，不要盯著那行 for loop 看，而是問問自己：這段代碼的靈魂（Vibe）對了嗎？
這是我目前的一些想法，如果你也有在用 AI寫 Code，歡迎分享你的 Code Review 心得！
