看不懂程式碼也能檢查 AI 生成的程式碼：非程式設計者的 7 項檢查

AI 在一個晚上就替你組好網站或機器人。所有頁面都能開啟，按鈕也能運作，看起來似乎一切正常。你把專案展示給大家看，隔天卻發現付款表單會扣款，但訂單根本沒有送出。或者，存有顧客電話號碼的資料庫竟然對整個網際網路公開。

我以前也曾用這種方式推出第一批專案：那些看似正常的東西，一遇到真正的使用者就出現意外。現在，在我把任何東西展示給別人之前，都會用同一份清單檢查專案。檢查時我完全不讀程式碼——我不是為了這個才來的，你大概也不是。

這不是杞人憂天。Anthropic 分析了 400,000 個 Claude Code 工作階段：在七個月內，用於修復損壞程式碼的工作比例從 33% 降到 19%。比例下降了，但問題沒有消失。每五個工作階段中，仍有一個是在「修復 AI 弄壞的東西」。

撰寫程式碼本身已不再是瓶頸。現在重要的是你多了解任務，以及你有多會檢查結果。

Ailoot 文件提供了設定工具的其他資料。

程式碼明明能運作，為什麼還要檢查 AI 生成的程式碼？#

AI 寫出的程式碼乍看之下往往能過關。程式可以執行、畫面也能顯示，示範看起來很有說服力。但上線後，你仍無從得知金額計算是否正確、資料庫是否暴露給外部，或等到第 100 位使用者到來時會不會全部當機。

數據也證實了這點。FrontierCode 基準測試在 2026 年 6 月檢驗 AI 生成的程式碼在不修改的情況下，能否直接投入實際工作。即使是最困難的任務、表現最好的模型，比例也只有約 13%。換句話說，在重要任務上，大多數 AI 生成的程式碼都必須先經過人工調整，才能讓人放心使用。

好消息是，任何人都能檢查。以下是 Anthropic 從同一批 400,000 個工作階段得出的結論：

你比自己請來的任何程式設計師都更了解自己的任務，這就是你的優勢。檢查同樣關乎理解；你不必讀懂程式碼。以下的檢查都是你可以自行完成的，不必費太多功夫。

AI 生成的程式碼實際上可能出什麼問題？#

開始檢查前，先了解自己要找什麼很有幫助。AI 生成的程式碼常見五種問題，不必讀程式碼，只要觀察專案的行為就能一一發現。

接下來依序介紹七項檢查。前幾項找出「無法運作」和「運作不正確」的問題；中間幾項檢查安全漏洞和捏造內容；最後幾項是在發布前的安全措施。最好按照順序逐項檢查：每一項都以完成前一項為基礎。

檢查 1：請 AI 用淺白的語言說明程式碼#

你用文字描述任務，AI 再把它轉成程式碼。這兩個步驟之間可能會遺失原意：AI 可能誤解你的意思、擅自替你補上內容，或是走捷徑。你不必讀程式碼就能發現落差，只要請它用淺白的語言描述自己做了什麼。

請用淺白的語言，不要使用程式碼，準確說明你剛才做了什麼：

這段程式碼要解決什麼任務

使用者點擊按鈕或送出表單時會發生什麼事

資料儲存在哪裡，以及誰可以存取

可能會在什麼情況下發生什麼故障

請像是向從未寫過程式的人解釋一樣來寫。如果有任何部分你不確定是否正確，請直接說明。

閱讀回答，並和你原本的想法比較。如果吻合，就繼續下一步。如果 AI「打太極」、連自己的解釋都說不清楚，或描述的不是你要求的內容，就表示它並未完全了解自己做了什麼。請它修改，並補充說明，而不要直接相信它的說法。

順帶一提，如果 AI 經常做出和你要求不同的事情，問題往往出在任務的描述方式，而不是模型本身。我另外寫了一篇文章，分析為什麼 Claude 不照你的要求做。

檢查 AI 的輸出是脈絡工程的一部分：你同時掌控提供給 AI 的輸入，以及評估輸出結果的方式。工具包包含 AI 分身、第二大腦和脈絡工程。做好這些之後，Claude 就不再是「會產生幻覺的助理」，而是你可以放心交付專案工作的工具。

檢查 2：像真正的使用者一樣走過各種情境#

AI 的示範總是一路順利：資料正確、點擊一次、所有事情都順利完成。真實使用者不會這樣操作。他們會犯錯、按錯地方，或是在電話欄位輸入表情符號。你的工作是像使用者一樣操作專案。

1. 從頭到尾完成主要情境

   執行專案設計要處理的事情：註冊、下訂單、送出申請。一路做到最後，不要只做到一半。

2. 個別而且實際地檢查付款

   如果專案會收款，請在測試模式下親自支付最低金額。確認訂單有建立、狀態有更新，而且你和顧客都會收到電子郵件。付款「成功」卻沒有建立訂單，是很典型的隱性故障。

3. 刻意製造問題

   把欄位留空。在需要數字的地方輸入文字。連續按兩次「送出」。上傳錯誤格式的檔案。好的專案會客氣地告訴你「不能這樣做」；不好的專案會當機，或悄悄吞掉資料。

4. 用手機開啟

   一半的使用者會用手機瀏覽。確認版面沒有跑掉，而且同樣的按鈕在手機上也能正常運作。

把你在各步驟發現的問題整理成一份清單交給 AI：「以下是這些步驟中出現的問題；請修正並說明發生原因。」不要一次只處理一個問題，整份清單一起交給 AI，讓它看見全貌，也比較不容易修好一處卻弄壞另一處。

檢查 3：用提示詞請 AI 檢查安全問題#

按鈕壞掉一眼就看得出來，安全漏洞則不會。專案看似一切正常，直到有人利用漏洞為止。使用氛圍式編碼製作的專案，最常見的問題是把秘密金鑰直接寫在程式碼裡、讓資料庫暴露在網際網路上，以及表單允許使用者送出惡意輸入。只要直接詢問，AI 就能找出這些問題。

請稽核這個專案的安全問題，並用淺白的語言、不使用術語，逐一解釋你發現的問題。請檢查以下項目：

檢查是否有任何秘密金鑰、密碼或權杖直接寫在程式碼中。私密機密只能在伺服器使用，本機 .env 等設定應排除於 Git。.env 與 .gitignore 不阻止 frontend／public 變數進入瀏覽器建置；請檢查實際送到用戶端的 JavaScript、source maps、HTML 與網路回應，確認沒有私密金鑰。

檢查資料庫是否暴露在網際網路上，以及誰可以存取。

檢查輸入是否可能破壞表單：例如注入資料庫查詢，或在文字欄位中加入額外程式碼。

使用者送出惡意資料時會發生什麼事？

檢查是否有任何內部頁面或管理面板未設密碼便暴露在外。

針對每個項目，說明是否存在問題、舉出明確的風險範例，並解釋如何修正。請從最危險的問題開始。

也要檢查專案會不會毫無判斷地照單全收外部輸入。這稱為間接提示詞注入：命令藏在電子郵件、留言或別人的檔案裡，AI 代理把它誤認為工作指示而照做。如果專案會讀取外部資料並採取行動，請問 AI：如果那些資料藏有指令，會發生什麼事？

這是個深入的主題，單一提示詞無法完整涵蓋。如果專案處理金錢或顧客個人資料，請閱讀另一篇氛圍式編碼安全指南。

檢查 4：AI 有沒有捏造程式庫或資料？#

AI 有時會很有自信地寫出根本不存在的東西。它可能加入一個名稱聽起來很合理、實際上卻不存在的程式庫。也可能在專案中留下測試用佔位內容來代替真實資料：例如名為「Example」的產品、example@example.com 這個電子郵件地址，或是代替實際內容的填充文字。示範時很容易漏看，但真正的使用者看到會覺得難堪，或是遇到故障。

分兩個步驟就能抓出這些問題。第一，直接詢問：

請檢查整個專案，並誠實回答：

你新增的外部工具和程式庫是否都確實存在，而且能正確安裝？你有沒有捏造任何東西？

是否還留有測試用佔位內容、範例或填充文字，沒有換成真實資料？

專案中的連結、地址和聯絡資料都是真實的，而不是佔位內容嗎？

請列出你的發現，並建議應該換成什麼。

第二，直接執行專案並四處查看。捏造的程式庫幾乎總會在啟動時造成錯誤。佔位內容也很容易發現：如果頁面上寫著「Product 1」，就表示你還沒把它換掉。

捏造的程式庫還帶來另一種危險：攻擊者會刻意註冊 AI 喜歡捏造名稱的工具。一旦安裝，就會讓別人的程式碼進入你的專案。因此，「這個程式庫真的存在嗎？」這個問題必須認真看待，因為它直接關係到專案安全。

檢查 5：請第二個模型檢查第一個模型的成果#

AI 有個令人不快的特點：它會附和。問它「這裡一切都沒問題嗎？」它就會確認一切沒問題，因為它會配合自己預期的答案。這稱為 AI 諂媚效應，我在另一篇文章中談過。這樣的對話對象不會嚴格檢查自己的成果。

解決方法很簡單：找另一個人提供意見。開啟新的工作階段或使用另一個模型，並用檢查 3 的同一個提示詞檢查專案，再加上一句：「這段程式碼是另一個 AI 寫的；請找出它的弱點。」新的模型不受前一段對話影響，比較可能指出問題。

1. 開啟乾淨的工作階段，或使用另一個模型

   使用第二個模型，或是開一個沒有任務紀錄的新視窗，用同一個模型檢查。

2. 提供專案，並清楚說明檢查方向

   直接告訴它：「這段程式碼是另一個 AI 寫的；你的工作是找出錯誤和風險，不是稱讚它。」這樣能減少諂媚效應。

3. 比較兩種意見

   如果兩者意見相同，很可能是對的。如果意見不同，就查清楚那個地方——有趣的事情通常就在那裡。

這正是現在整個產業正在發生的事：AI 撰寫，AI 檢查，最後由人做決定。你不能把這件事交給模型——那是你的工作。

檢查 6：如果修改弄壞了東西，要怎麼復原？#

清單上的檢查常會需要修改，而修改有時會弄壞原本正常的功能。為了避免演變成災難，每輪修正前都先把可正常運作的版本存進 git。這就像儲存遊戲進度：如果弄壞了什麼，就載入最近的存檔點。

你不必讀程式碼。只要請 AI：「在變更任何內容之前，先用清楚的標籤將目前可正常運作的版本儲存到 git。」如果修改後一切都亂了，就說：「將專案還原到先前儲存的版本。」

如果你還不熟悉 git，這裡有兩篇指南：如何在 Claude Code 中還原變更，以及AI 刪除了你的資料庫時該怎麼辦。第二篇適用於已經來不及還原，但仍有機會復原的情況。

檢查 7：發布前最後要檢查什麼？#

前六項檢查的是程式碼的行為，第七項則是確認專案已準備好面對使用者。很多人會在這裡出錯：專案運作正常，卻忘了把付款從測試金鑰切換成正式金鑰，於是第一批顧客付的只是「假錢」。

1. 付款：從測試切換到正式

   如果你會收款，請確認已連接付款系統的正式金鑰，而不是測試金鑰。實際支付最低金額，再退還給自己。

2. 把秘密資訊放在正確的位置

   問 AI：「私密金鑰是否只在伺服器使用，.env 是否排除於 Git？實際瀏覽器建置或回應，是否經 frontend／public 變數或 source maps 包含私密金鑰？」檢查建置檔與瀏覽器回應，不只來源 .env；Git 排除不會阻止值進入前端 bundle。

3. 備份資料

   確認資料庫會自動儲存到某個地方。如果專案在自己的伺服器上執行，我在 Coolify 指南中說明如何發布。

4. 確認從自己的裝置以外也能開啟

   用手機透過外部連結開啟專案，不要只在自己的電腦上測試。本機能運作的東西，發布後不一定能運作。

四項都確認完，你就能安心地把專案展示給大家。如果有任何一項不符合，現在花半小時處理，總比之後面對不滿的顧客好。

檢查花太多時間的話，乾脆相信 AI 就好嗎？#

我理解這種誘惑。檢查很無聊，而且「我用 AI 又不是為了做這件事」。但結果要由你負責，不是模型。AI 沒有名聲，也不必承擔後果：它產生程式碼後就把這件事忘了。最後要向付款失敗的顧客負責的人是你。

Claude Code 的創作者看得更廣：

撰寫程式碼不再是瓶頸，因為 AI 已經接手。現在的價值在別處：理解任務，並檢查成果。這就是你的強項——對顧客而言，結果應該是什麼樣子，你比任何外部開發者都清楚。

為什麼檢查是一種技能，而不是一次性的任務？#

這七項檢查是區分「我把它發布了，希望它沒問題」和「我把它發布了，而且確定它能運作」的最低要求。完整檢查一次，就能在顧客發現之前抓到大多數意外問題。

接下來，檢查會成為一種習慣。把正確的脈絡當作輸入提供給 AI，並檢查輸出結果，就能讓每個新專案完成得更快，因為你不必從頭開始。

AI 分身、第二大腦和脈絡工程——更多工具使用資料請見 Ailoot 文件。