AI 生成的程式碼正在帶來嚴重問題：安全漏洞、冗餘程式碼、膨脹的 Pull Request。多份研究報告顯示，AI 程式碼的安全測試失敗率高達 45%，每個 PR 的問題數量是人工程式碼的 1.7 倍。本影片探討了 AI 程式碼的品質隱憂、開發者常犯的錯誤、Code Review 為何比以往更重要，並實際演示了如何使用 CodeRabbit 進行自動化程式碼審查來建立防護網。

原影片連結：https://www.youtube.com/watch?v=nGxpctRd2OQ

影片重點

• 45% 的 AI 生成程式碼未通過安全測試，存在 OWASP Top 10 安全漏洞
• AI 生成的 PR 平均問題數量是人工程式碼的 1.7 倍
• AI 擅長寫程式碼，但缺乏領域知識、架構理解和專案整體規劃能力
• AI 生成的 Pull Request 平均比人工大 18%，增加審查負擔
• 應將 AI 視為「能力很強的初級工程師」，絕不能跳過人工審查
• AI Code Review 工具應作為「第一道過濾」而非最終審查
• CodeRabbit CLI 可在本地和 GitHub 兩個階段進行雙重審查
• 程式碼審查的信任基礎是：提交者必須理解自己的程式碼

詳細內容

[00:00] AI 程式碼的品質危機

AI 生成的程式碼正在造成嚴重問題——安全漏洞正威脅著真實的應用程式，程式碼品質低落，Pull Request 越來越臃腫。報告顯示，雖然 AI 幫助我們更快地寫程式碼，但同時也在降低程式碼品質，不僅產生更多 Bug，還製造了一種全新類型的問題。即使你還沒有使用 AI 寫程式碼，也應該了解這些問題，因為它們影響著每一個人。

[00:39] 資深開發者的態度轉變

從 2025 年初到下半年，AI 的發展讓人無法再忽視。年初還把 AI 嗤之以鼻、說它只是「AI 垃圾」或「花俏的自動補全」的資深開發者，到了年底紛紛開始擁抱它。一份雲端服務商的報告調查了 791 名擁有 10 年以上經驗的資深開發者，其中 32% 表示他們已經交付過 AI 生成的程式碼。不管你認為這是好是壞，這已經是事實——許多決策者正在買單，這就是我們前進的方向。

[01:40] 報告揭露的安全隱患

Veracode 的報告發現，45% 的 AI 生成程式碼未通過安全測試，並且引入了 OWASP Top 10 的安全漏洞。OWASP 是全球公認的軟體安全組織，定期發布應用程式面臨的十大安全漏洞（約每 3-4 年更新一次），包括跨站腳本攻擊（XSS）、SQL 注入、存取控制配置錯誤等。這些都不是小問題，更令人擔憂的是，即使模型大幅改進，這些結果基本沒有改善。

CodeRabbit 的另一份報告審查了 470 個開源 GitHub Pull Request，得到了類似的發現。AI 生成的 PR 平均每個有 10.83 個問題，而人工程式碼只有 6.45 個——AI 程式碼的問題數量是人工的 1.7 倍。按嚴重程度分析：關鍵問題高 1.4 倍，重大問題高 1.7 倍，輕微問題幾乎翻倍。

[03:17] 四大問題類別深入分析

報告將問題分為四大類別：

邏輯與正確性：最突出的是錯誤的依賴關係和配置問題。使用較新的函式庫或套件時，AI 常常無法判斷最新版本的 API，導致使用舊版本的 import 或過時的文件。AI 很難區分什麼是現代的做法、什麼應該被使用。

程式碼品質與可維護性：問題包括可讀性差、命名不清晰、格式錯誤、冗餘程式碼。其中冗餘程式碼最為常見。人類開發者會考慮元件復用，遵循 DRY（Don’t Repeat Yourself）原則。但 AI 傾向找最快路徑，會在同一頁面中重複生成 UI 元件，而不會考慮其他頁面是否需要共用。這種冗餘程式碼會累積大量技術債。

安全漏洞：與 Veracode 報告一致，包括不當的密碼處理、跨站腳本攻擊、不安全的反序列化等 OWASP Top 10 漏洞。

效能問題：AI 生成的程式碼在效能方面也表現不佳。

[05:04] 開發者常犯的兩大錯誤

第一：高估 AI 的能力。 開發者對 AI 能做什麼和不能做什麼缺乏理解，給它太多期望。AI 已經很擅長寫實際的程式碼，但它缺乏領域專業知識、對整體架構的理解、專案需求的掌握，以及各部分如何協作的認知。如果讓 AI 替我們思考，它會失控並做出大量假設，隨著應用程式增長，效能會不斷下降。

第二：Pull Request 膨脹與審查不足。 AI 讓產出程式碼變得更容易，我們傾向寫更多程式碼、建立更大的 PR，而這些 PR 更難審查。報告顯示 AI 生成的 PR 平均比人工大 18%。AI 看似給了我們速度的幻覺——寫程式碼更快了，但在確保品質時卻要付出代價。

[06:15] 解決方案：嚴格的防護措施

解決方案不是「不用 AI」——那不太現實。正確做法是對 AI 建立嚴格的防護機制：把任務拆成小塊以避免失控，建立強力的流程和文件。簡單來說，把 AI 當作一個能力很強的初級工程師——它能寫程式碼，但絕不能在沒有徹底審查的情況下信任它。

[06:59] Code Review 中的信任問題

作者分享了一次令他非常不滿的經歷：審查一個 PR 時，發現程式碼有 AI 生成的特徵（例如到處都是註解）。向原作者詢問某段程式碼的邏輯時，對方回答「我不太清楚，只是想讓 AI 做到 X」。原作者完全不了解自己程式碼的運作方式。

這破壞了開發者之間的信任基礎。舉證責任在原作者身上——確保 PR 中的程式碼能正常運作是作者的責任，不是審查者的。如果你無法解釋自己的程式碼或證明它能運作，就不該請別人來批准它。

更嚴重的是，當越來越多開發者交付自己不理解的程式碼，知識傳遞機制就被破壞了。如果原作者都無法解釋程式碼如何運作，凌晨兩點服務中斷時，值班工程師要怎麼解決問題？

正如 Google 工程總監 Addy Osmani 所寫：「如果你跳過審查，你不是消除了工作，你只是推遲了它。」IBM 的培訓手冊也寫道：「電腦永遠無法被問責，那是你作為人類的職責。」

[08:46] AI Code Review 工具的正確定位

AI 能否自己審查自己的程式碼？絕對不行——至少不能作為最終審查。AI Code Review 工具（如 CodeRabbit）適合用來強化程式碼規範、確保結構一致性，以及作為第一輪審查的額外眼睛。但開發者容易走兩個極端：要麼完全不信任 AI 審查，要麼過度信任。

正確的定位是：這些工具是第一輪審查者，不是最終審查。 就像拼字檢查一樣——你不會把一份到處是紅色波浪線的文件直接丟給別人審閱，你會先修正拼字錯誤、評估建議是否合理，然後再送出去。AI Code Review 工具也該這樣使用：先讓 AI 做初步檢查，你根據建議修正後，再提交給同事做人工審查。這樣你尊重了審查者的時間，不讓他們處理那些你自己就能清理的基本問題。

一位 Reddit 使用者精準地說：「引入 AI 回饋的正確時機是在 PR 提交審查之前。讓原作者先審閱 AI 的建議並採取行動，強迫所有人同時審查程式碼和 AI 建議是浪費時間。」

[11:04] CodeRabbit 實戰演示

CodeRabbit 的審查流程分為兩個階段：

第一階段：本地開發審查。 使用 CodeRabbit CLI，在程式碼推送到 GitHub 之前就進行審查。安裝完成後，在終端機執行 coderabbit 命令，會顯示專案資訊（分支、修改的檔案數、插入和刪除等），然後按 Enter 開始審查。審查完成後可以用方向鍵瀏覽建議，並直接按 A 鍵套用修正。

另一種使用方式是與 AI Agent 結合——在 Cursor 等工具中，寫完功能後在 prompt 中加入 run coderabbit review -prompt-only，AI Agent 會自動執行 CodeRabbit 審查作為自我驗證流程。

第二階段：GitHub 審查。 程式碼推送到 GitHub 後，CodeRabbit 會進行第二輪審查，捕捉本地可能遺漏的問題。通過這兩輪檢查後，再交給人類審查者，讓他們可以專注在真正重要的事情上。

[16:42] 自訂規則與團隊規範

CodeRabbit 的亮點是高度可自訂且能學習你的程式碼庫。例如，如果團隊習慣用兩個空格縮排而有人用了四個，它會標記警告。如果團隊用 snake_case 而非 camelCase，它也會捕捉。你還可以給 CodeRabbit 設定一套規則和模式讓它在團隊中強制執行。不過最後的結論是：AI Code Review 是幫助修復 AI 程式碼問題的一個解決方案，但永遠無法取代人工審查。請謹慎使用。

我的想法

這部影片精準點出了當前 Vibe Coding 最核心的矛盾：AI 讓寫程式碼的速度變快了，但品質保證的成本並沒有降低，反而因為程式碼量增加和理解度降低而上升。「速度的幻覺」這個概念很值得深思——表面上看寫程式碼更快了，但加上除錯、審查、修復安全漏洞的時間，整體效率是否真的提升了？

影片中把 AI 比作「能力很強的初級工程師」是個非常恰當的比喻，但我認為還可以延伸：初級工程師會隨著經驗成長，但 AI 不會因為你用得多就對你的專案更了解（至少在沒有良好上下文管理的情況下）。這意味著你每次都需要提供足夠的脈絡和約束，否則 AI 會反覆犯同樣的架構錯誤。

比較務實的做法可能是：將 AI 的使用範圍限制在你完全理解的領域，而不是用它來探索你不熟悉的技術。AI 更適合加速你已知的工作流程，而不是替你做技術決策。