之前有主管問過我一個很實際的問題：

「AI 寫完一個系統，上萬行程式碼，你怎麼知道它寫得有沒有問題？」

這個問題我覺得很好。
因為 Vibe Coding 的使用者，不一定每個人都有能力逐行 Code Review。
老實說，我自己也不會假裝 AI 產出一萬行程式碼，我可以每一行都看懂、每一行都判斷它到底寫得好不好。對不是專職開發的人來說，這也不是最容易做到的事情。

所以我的答案不是「看得更仔細」，而是：

我不需要每次重新看懂一萬行程式碼，我需要知道這一次到底改了什麼。

不要一次做完整個專案再驗

第一件事就是前面八個 Phase 一直在做的：不要一次做完整個專案再驗

今天只做登入，我就驗登入；今天只做分權，我就驗分權；今天只做上傳，我就驗上傳。這樣每一次要看的東西，範圍就小很多。

一次面對一萬行，很難知道問題到底藏在哪裡；但如果每次只處理一個
Phase、只看這一次的變更，範圍就小很多。

重點不是把整個專案看完，而是不要讓整個專案一次出現在你面前。

Phase 到底切多細？

前面八個 Phase
只是我的例子，不同系統、不同規模當然會有不同拆法。我自己判斷 Phase
有沒有切得夠細，主要問三個問題：

這一段做完，我能不能馬上驗收？

我能不能用一句話說清楚這次改了什麼？

如果這一段做壞了，我能不能只退掉這一段？

如果答案是不行，那這個 Phase 可能就切得太大了。

每個 Phase 做完，先停

Phase 拆好之後，不要一次全部丟給 AI，一段一段來。每一個 Phase
做完：停。

不是叫 AI 直接接下一段，是人先接手。

實際跑一次

停下來之後第一件事：實際跑一次。不是看它的說明，也不是只看它自己產生的測試報告，而是自己開瀏覽器、自己點。登入做完就登入看看，上傳做完就傳一個檔案看看，確認功能是不是自己要的。

看它有沒有「多做」

第二件事：看它有沒有做超過要求的。

AI 有時候很熱心。你叫它做登入，它可能順手做了「記住我」、「忘記密碼」、「第三方登入」。每一個聽起來都合理，但每一個都是你沒要求的，也代表多一個要確認、要測試，甚至可能多一個攻擊面。

所以我的原則很簡單：Phase
說做什麼，就先把這件事情做好。多出來的功能，不是不能做，而是不要在我不知道的情況下自己長出來。

看它有沒有為了方便繞過限制

第三件事：看它有沒有為了讓功能能動，繞過原本的限制。這是我最怕的一種情況。

AI 做到一半發現驗證擋住了，有可能為了完成任務先把驗證關掉；發現權限不夠，可能把權限放寬；發現連不到資料庫，也可能為了測試先把連線資訊寫死。最後功能真的動了，它也真的可以跟你說「功能完成」。

問題是：功能能動，跟它是不是按照原本的限制完成，是兩回事。

而且這些修改有時候還會附上一個聽起來很合理的理由：「為了讓流程更簡單。」「為了方便測試。」「這樣的設計會比較有效率。」

聽起來都很合理。但：比較方便，不代表符合需求。比較有效率，也不代表可以安全上線。

所以我每個 Phase
都會特別看這幾件事情：有沒有做超過要求的？有沒有為了方便，繞過原本的限制？有沒有把帳號、密碼、路徑、網址、金鑰或環境設定寫死？有沒有把原本應該在後端做的安全控制，只做在前端？遇到錯誤時，是安全地停下來，還是為了讓流程繼續直接放行？

Plan Mode：先看它準備怎麼做

上面講的都是做完之後看，但更好的方式是做之前就先看。

以 Claude Code 為例，它有 Plan Mode，可以先讓它把這一個 Phase
準備怎麼做列出來，例如要改哪些檔案、要裝什麼套件、要動什麼設定。人先看過，方向沒問題，再讓它開始動手。

很多「多做」和「繞過」其實在計畫階段就有機會看出來。假設計畫裡突然出現「先停用某個安全檢查以便測試」，我就可以在它真正修改之前先問：為什麼要關？有沒有別的做法？

這比做完之後才發現它已經改了一大堆，再回頭拆掉簡單得多。我自己每一個
Phase 開始前，都會先走一次這個流程。

看 Diff，不是重讀整個專案

做完之後，我看的不是整個專案，而是
Diff：這一次動了哪些檔案、每個檔案改了哪些地方。

例如在 VS Code 的 Source Control
裡，就可以直接看到這一次有哪些檔案被新增、修改或刪除，再去比較修改前後的差異。如果前面的
Phase
切得夠小，這時候看到的就不應該是整個專案，而只是這一次真正發生變化的部分。

對我這種不是專職開發的人來說，我不會假裝自己可以只靠 Diff
判斷每一段程式碼「寫得漂不漂亮」。我會先找幾個我看得懂、而且風險很高的東西：多做的、繞過的、寫死的，以及安全控制被拿掉的。

例如 Diff 裡突然出現 # TODO: re-enable auth，或是冒出
password = "admin123"，這種東西就算不是資深開發人員，也比較有機會在一堆變更裡注意到。

所以 Diff 對我的價值，不是讓我瞬間變成可以逐行 Code Review
的資深工程師，而是把問題從：

「這一萬行到底寫了什麼？」

縮小成：

「AI 這一次到底動了什麼？」

每個 Phase 做完就 Commit

看完、跑完、確認沒問題：Commit。

Phase 1 做完，Commit；Phase 2 做完，Commit；Phase 3 做完，再
Commit。這樣如果後面出問題，我至少可以知道每一個階段到底改了哪些東西，也有前一個已知正常的版本可以拿來比較。

而不是整個系統做到最後才發現壞掉，然後開始回頭翻昨天跟 AI
的幾百行對話：「到底是哪一次叫它改東西的時候改壞的？」

AI 產生程式碼的速度真的很快，一天新增、刪除、修改幾百甚至幾千行，都不是什麼奇怪的事情。所以對
AI 協作開發來說：沒有版本控制，就很難說清楚每一次到底改了什麼，也很難在出問題時回到上一個已知正常的狀態。

而 Commit 的價值也不只是「可以退版」。它還回答了一個很重要的問題：

AI 這一次到底改了什麼？

做壞了，至少我有地方可以回去

Phase 做壞了怎麼辦？如果只是很小的問題，當然可以直接修；但如果 AI
已經越改越遠，甚至連自己改過什麼都開始說不清楚，我就不會繼續在上面一直疊修改。

因為前一個 Phase 已經
Commit，所以至少有一個「已知正常的版本」可以比較，必要時也可以回到那個版本，再重新讓
AI 規劃這個 Phase。這次就把上一次出錯的地方寫進限制裡，再重新做一次。

這就是為什麼我不喜歡做到最後才 Commit。

Commit 不只是存檔，而是在一路留下可以回頭的路標。

確認這一個 Phase 沒問題，才進下一個 Phase。

小結

回到主管那個問題：上萬行程式碼，你怎麼知道有沒有問題？

我的答案不是「我可以把一萬行全部看懂」，而是**我盡量不要讓自己一次面整個專案內容 **

我先看這個 Phase 準備做什麼，方向沒問題再讓 AI
開始；做完之後自己實際跑一次，再看這一次到底改了哪些東西：有沒有多做、有沒有繞過原本的限制、有沒有把敏感資訊或環境設定寫死，也看看原本要求的安全控制是不是還在。確認之後
Commit，再進下一段。

AI 寫得快，不代表人要跟著它一直往前衝。相反地，AI
越快，我越需要把變更切小，留下可以檢查、可以比較、也可以回去的節點。

我不需要每次重新看懂一萬行程式碼，我需要知道這一次到底改了什麼。

到這裡，開發這一站才算真的走完。

但「功能做完」跟「真的測過」又是兩回事。