ExplainThis 全端開發雙週報 #56
使用 AI 寫程式時，要小心與注意的事項
嗨～歡迎閱讀第 56 期 ExplainThis 全端開發雙週報！
在這期雙週報的主題文中，我們會來談「使用 AI 寫程式時，要小心與注意的事項」。目前業界各類 AI 程式助手百家爭鳴，多數公司也積極導入使用 AI 工具，讓工程師的效率與生產力提升。
然而在用這類工具的同時，有許多要注意的細節，從資訊安全，到程式碼品質的管控，都非常重要。如果只是無條件接受 AI 生成的程式碼，最終可能會需要承擔嚴重的後果。
如果讀者們想知道有哪些要注意的事項，就讓我們一起進到這期的主題文吧！
使用 AI 寫程式時，要小心與注意的事項
談到使用 AI 協助寫程式時要小心的點，相信多數人不會反對「資訊安全」是最重要的。舉例來說，我們先前曾在《使用 MCP 時，要注意避免被惡意攻擊》一文中談到「工具中毒攻擊 Tool Poisoning Attack」等攻擊方式 (連結)，推薦讀者們可以溫習。
除了最基本的安全事項外，在這期雙週報，我們會從另一個角度切入，來探討作為一名工程師，在面對 Cursor 所生成的成果時，應該小心與注意的內容。
小心 70% 問題
第一個要先新的點，是先前 Addy Osmani 寫過一篇 The 70% problem: Hard truths about AI-assisted coding 談所謂的「70% 問題」。這個問題指的是 AI 生成的成果，無論是我們之前提到的技術文件或程式碼，許多時候正確的比例可能只有 70%。
在較簡單的任務中，AI 或許能一次完成得很好；但在較複雜的任務中，即使現在模型的發展越來越進步，仍然有許多情況無法一次到位。因此，如果沒有進行檢視就直接接受 AI 生成的成果，可能會導致程式碼中存在錯誤、或是不正確、難以維護的情況。
這可能造成非常嚴重的後果，特別是如果這些程式碼實際運行在線上的生產環境，且有真實的使用者，甚至產品的使用者量級達到一定程度時，若未經檢視就直接將 AI 生成的程式碼合併到主要分支並部署上線，很可能導致意料之外的事故。
要有效解決這個「70% 問題」，就必須保持獨立思考，不能未經檢視就直接接受 AI 生成的成果。
不要只是 Vibe Coding
此外，之前在社群上有許多關於 Vibe Coding 的討論。Vibe Coding 的核心概念是，在使用 AI 工具協助撰寫程式碼時，採取一種「隨著當下的氛圍」請 AI 協助撰寫程式碼。在這種方式下，工程師不會特別去檢查程式碼的細節。
在使用 Cursor 做 Vibe Coding 時，特別是在實際工作場景中，建議大多數情況下不要只是 Vibe Coding。如果是撰寫個人專案，或是像原型開發 (Prototype) 這類的內容，Vibe Coding 可能沒有太大問題，因為此時的重點在於嘗試某個功能或概念，程式碼的細節、可讀性或可維護性可能不是首要考量。
然而，如果今天撰寫的程式碼如前面所述，是要實際部署到生產環境，供使用者使用，且使用者量級達到一定程度，單純的 Vibe Coding 就不太推薦。
先前 Matt Pocock 有分享一張分析圖 (連結)，用很間單但精闢的方式，比較了 Vibe Coding 與 AI 輔助開發 (AI-Assisted Development) 的區別。
該圖表以兩個 X、Y 軸劃分四個象限：
X 軸：從「非常嚴謹的規格」到「純粹隨性」。
Y 軸：從「嚴格檢查每一行程式碼」到「完全不檢查程式碼」。
右上角的象限代表 Vibe Coding，而左下角則是 AI 輔助開發 (AI-Assisted Development)。我們推薦，如果是在實際工作上，或撰寫的程式碼將用於重要且不容出錯的生產環境，務必採用左下角的方式，即制定詳細、明確、具體的規格，並對 AI 生成的程式碼進行檢視與測試。
成為有能力檢視 AI 程式碼的工程師
如上一個段落談到的，在 AI 輔助程式碼工具的時代背景下，軟體工程師的一個重要角色，是要去檢視與審查 AI 生成的成果。換句話說，成為優秀的程式碼審查者（Code Reviewer）、成為有能力去檢視 AI 成果的工程師，會比過往來得更重要。
這意味著能夠辨別 AI 生成的程式碼是否存在潛在問題，若程式碼不理想，需拒絕或進行修改，而非一味接受。AI 工具能協助執行任務，但最終仍需由我們做決策，判斷是否接受 AI 生成的成果，並承擔相關責任。如果 AI 生成的成果不如預期，工程師不能直接將程式碼部署到生產環境，因為一旦使用者遇到問題，工程師仍需承擔責任。
因此，即使有 AI 的輔助，在工程師的職涯中持續精進與成長，仍是不可或缺的。如果讀者們想在前端、後端的軟體工程師職涯持續成長，歡迎加入 ExplainThis 的 E+ 成長計畫 (連結)，透過每週的深度技術主題文，培養出對技術的品味，成為有能力檢視 AI 程式碼的工程師。
本期推薦
這週社群中最多人討論的 AI 相關演講，非 Andrej Karpathy 給的《Software Is Changing》演講 (連結)，將近 40 分鐘的內容有著滿滿的洞見。社群中有人把內容整理成摘要投影片，推薦一看 (連結)
這週 Shopify CEO 提到他認為「脈絡工程」比「提示詞工程」是更貼切的描述，我們非常認同這個觀點 (連結)；順道一提 Anthropic 最新開的專職提示詞的職缺，年薪範圍有破千萬台幣，在 AI 持續發展下，這個技能越來越重要 (連結)
Google Cloud 重大事故後的檢討報告 (連結)，當中提到這次事故，如果有用功能旗標 (feature flags)，就能夠在上線前被發現，避免造成損失。還不熟功能旗標是什麼的讀者，可以參考先前 ExplainThis 寫過的介紹 (連結)
前陣子 Linear 團隊在 Local-First Conf 2025 的演講上線到 YouTube 上了，他們的同步引擎 (sync engine) 設計一直是業界標竿(連結)。如果對 local-first 的程式設計概念不熟，可以參考 ExplainThis 先前寫的文章 (連結)
Nanda Syahrasyad 最近跟新了他的個人部落格，裡面有很多經典的前端開發內容，現在都用互動的形式呈現，推薦一讀 (連結)
最近 Dan Abramov 持續高產出寫了非常多優質內容，讀了非常過癮，特別是 Progressive JSON 這篇，用淺顯易懂的形式介紹 RSC 背後的精髓 (連結)。另外，他甚至開始發 YouTube 影片講解內容，推薦訂閱 (連結)
上週看到社群中有人轉貼很經典的「程式設計的三大美德 Three Virtues」，這三個美德，是三十年前 Perl 程式語言的發明者 Larry Wall 的曾說過的，他認為一位優秀的程式設計師，應該要具備「懶惰、沒耐心和傲慢」的三個特質，而這三個特質不是缺點，而是是美德。想了解原因可以看這篇解釋 (連結)
文末彩蛋
這期的文末彩蛋是 Paul Graham 先前轉貼過的一個貼文，貼文中談到短短三句話
Life is Short.
Relentlessly prune bullshit. Don’t wait to do things that matter.
Savor the time you have.
有些人可能會覺得「人生短暫」這句話是已經聽膩的成腔濫調。但是多數人平常不論工作或生活，很常沒有真的實踐這句話所傳達的。
而 Paul Graham 轉發的這段話，其中一個關鍵在於後面這句「Relentlessly prune bullshit 不留情面地把對自己無意義的事，從生命中剔除」。
推薦讀者們平時可以做每日檢視，在一天結束時前，花一點時間問自己「今天做的哪些事，其實對自己不是真的那麼重要」，然後未來遇到類似的事情時，有意識地把自己抽離，這樣會更能把時間專注投注在對自己真正重要的事。