ExplainThis 全端開發雙週報 #65 用 AI 協助 Code Review，怎麼做比較有效?
用 AI 協助 Code Review，怎麼做比較有效?
嗨～歡迎閱讀第 65 期 ExplainThis 全端開發雙週報！
在這週 ExplainThis 全端開發雙週報的訂閱數突破 5,000，與此同時 E+ 成長計畫的訂閱人數也超過 800，由衷感謝讀者們的支持！
在未來我們會持續努力，每兩週在雙週報聊軟體工程、前端與後端開發的內容，同時會彙整過去兩週中社群值得推薦的內容；在 E+ 也會持續寫深度進階的內容，與大家在軟體工程師的職涯路上持續成長。
以上，接著讓我們進到這期的主題文吧！
AI 協助 Code Review，怎麼做比較有效?
Code Review 是軟體工程中，非常重要的環節。Code Review 能確保程式碼庫的品質不會下降，很多時候開發者可能為了趕時間，或者因為過去沒有養成良好的撰寫程式習慣，所以會寫出品質不佳的程式碼。Code Review 可以作為一個關卡，確保品質不佳的程式碼不會被合入。
不過，即使多數團隊會同意 Code Review 的重要性，但在實務上，許多團隊仍常常會略過 Code Review。常見的原因包含團隊在趕進度所以沒時間做 Code Review，或是團隊只有單一工程師 (例如一個前端、一個後端)，所以沒有人能幫忙看程式碼。
在有了 AI 的協助後，這類問題得以緩解，我們能用 AI 來協助做 Code Review。不過，該如何讓 AI 給的回饋品質提高呢?
Code Review 時要有觀點
首先，在做 Code Review 時，從某個技術觀點切入，通常給的回饋會比較有幫助。假如要讓 AI 能夠做到這點，而不是僅僅用很通則的方式給回饋，就需要在預設的提示詞加入觀點。以 Claude Code 為例，可以在串接到 GitHub Actions 時，在 prompts 中加上提示詞。
在社群當中，有些公認特別有幫助的技術觀點。舉例來說，OpenHands 的 codereview-rosted (連結) 即是在提示詞中加入 Linux 創始人 Linus Torvalds 的角色及觀點。
提示詞中就包含一些犀利的問題，例如：
這個問題真的值得解決嗎?
有沒有更簡單的解決方式?
什麼會被這個改動影響?
當帶著這樣的犀利觀點，AI 給的回饋就不會停留於輔助檢查，而是能像資深工程師一般思考與檢視。
風格一致性
除了觀點外，風格一致性在 Code Review 也會是重點之一，當程式碼庫的整體風格一致，對於維護者來說的認知成本會比較低。推薦團隊要準備風格指南 (Style Guide) 來確保程式碼的一致性。
舉例來說，Airbnb 提供的開源 JavaScript 風格指南，在 GitHub 上獲得超過 10 萬顆星，明確規範了撰寫 JavaScript 的風格。Google 也公開了多種程式語言 (如 C++、Go、JavaScript、Java 等) 的風格指南，供開發者參考。
因此，除了上面提到的技術觀點，把風格指南放入 Claude Code GitHub Actions 的 prompt 欄位中，就會讓 Claude Code 根據風格指南分析程式碼，並提出建議，確保 PR 中的程式碼與整體程式碼庫的風格一致。
善用脈絡工程
先前我們在《讓 AI 有更精確輸出的脈絡工程 (context engineering)》一文中 (連結) 有談到，要讓 AI 模型的輸出，更貼近使用者預期的品質，精心設計的提示詞會很重要。然而，隨著 AI 代理發展逐漸成熟，業界也發現僅有提示詞，已經不足以應付 AI 代理的需求，隨之出現的是脈絡工程 (context engineering) 這個技術。
把脈絡工程運用在協助 Code Review，也將能大幅提升品質。上面提到的技術觀點、風格指南，都可以是脈絡的一部分，但除了這些外，還可以多放一些額外的東西到整體脈絡中。
假如 PR 當中的改動有用到某個套件，就會需要關於使用到的套件同一版本的文件，這樣才能夠確保針對使用該套件，給出最準確的回饋。這樣能避免 AI 的訓練資料是該套件不同版本的內容，所以給出不準確評論的狀況。具體來說，可以對接到 context7 這類 MCP 來做到。
另一個常見的做法，是提供記憶庫 (memory bank)。先前在《如何透過決策脈絡，避免 AI 失憶問題?》一文中 (連結)，我們有提到。推薦可以在每次完成 PR 的 Code Review 後，要 AI 針對哪些是最終被採納的建議、哪些是決定不採納的，都更新到這個決策紀錄 (decision log) 當中，這樣未來在做 Code Review 時，就不會再次給出不會被採納的建議。
以上，如果能做好以上三點，將能夠讓 AI 給出來的回饋，更有建設性，對於維護程式碼庫的健康來說，也會比較有幫助。
當然，即使有 AI 能協助做 Code Review，身為軟體工程師，該有的技術觀點、對於如何寫出好維護程式碼的掌握，仍是不可或缺的。如果你對於持續提升自己在軟體前端、後端的技術能力，歡迎加入 E+ 成長計畫 (連結)，透過深度內容與社群交流一起成長～
本期推薦
最近社群中知名的開發者 NaN 寫了一篇《Build Your Own Database》文章，一步步帶領讀者打造一個最簡易版本的鍵值對資料庫，整篇讀起來互動性十足，如果想更具體了解資料庫背後用的資料結構，推薦一讀 (連結)
對軟體工程師來說，社群中每天都有極大量的資訊，這週社群有一篇 《how to read research papers, in 5 minutes.》 ，雖然主要是談如何有效率地讀研究論文，但是裡面談到的點，對於讀技術文章來說也適用(連結)
這週 AWS 全球事故的官方回顧報告發佈了 (連結)，在該報告詳盡地談了事故發生的始末，這類報告蠻有助於理解雲端服務背後如何運作。另外，每當有這種重大事故發生時，還是值得再提一次「不指責人的事故檢討 blameless postmortem」的重要性 (連結)
社群中知名的工程師 Sean Goedecke 先前分享了《Everything I know about good system design》一文，談了好的系統設計，應該考量到哪些點，寫得非常精彩 (連結)
近期 ChatGPT 發表了代理驅動瀏覽器 Atlas 後，社群中有一篇討論先前 Perplexity 的代理驅動瀏覽器 Comet 資安問題的文章《Unseeable prompt injections in screenshots》 (連結)，獲得廣大轉傳，推薦想嘗試這類瀏覽器的人，務必要有相關的警覺意識。我們也針對該文章寫了中文摘要，推薦感興趣的讀者閱讀(連結)
最近看到開源程式編輯器 Zed 官方部落格的《Hired Through GitHub》 (連結)，反過來是從公司的角度，談什麼樣的開源貢獻者，會讓公司想要招募進團隊，如果你也是不喜歡刷題、喜歡實作的工程師，不妨找個你自己會用、覺得有意義的開源專案，在貢獻中邊學習，說不定也會有工作自己找上門 (中文摘要連結)。
平常大家在用 Gmail 這類服務時，不知有沒有想過，假如想自己託管一個電子郵件伺服器，可以如何實作，先前讀到《Self-Hosting Email Like It’s 1984》一文 (連結)，完整走過這個流程，從中也學到不同協定、DNS 運作等等，非常有趣
上週想要把一些檔案轉檔，本來在想要不要用 AI 快速寫一個轉換器，但在那之前搜了一下，看到 VERT 這個開源專案 (連結)，可以用來轉圖片、語音、影音等檔案，非常方便
文末彩蛋
最近在推特上看到一個關於「請用不直接說出來的方式，讓我知道你很富有」的討論。
其中看到 Notion 共同創辦人 Akshay Kothari 的回覆，覺得與我們所定義的「富有」很契合，他說「每天早上，我醒來時都笑得合不攏嘴，期待去上班。每天傍晚，我又急著回家，迫不及待和家人在一起。」
Every morning, I wake up grinning, itching to tap dance to work. Every evening, I’m racing home, giddy to be with my family.
這讓人想到近期最成功之一的創投公司 Thrive Capital 創辦人 Josh Kushner 發過的一則貼文，談他的人生目標不是自己創投的財務績效，而是「早上期待去上班，晚上也期待回家 the goal of life is to be excited to go to work and excited to go home」。
在臺灣的科技業社群媒體，或者國外的 Blind 論壇，很常看到把賺多少錢、有多少資產、是否已經 FIRE 用來定義「富有」。不過對我們來說，即使賺了很多錢，假如不享受自己做的事，或者因為工作而犧牲與家庭、重要他人的關係，反而得不償失。
反之，假如有一份自己很享受、每早都期待的工作，以及有一個溫暖且幸福、每晚都期待的家，這帶來的富足感，是遠勝過財務與物質面的。
當然，對軟體工程師來說，最幸運的地方在於假如享受所做的事，就會自然地想更深入研究技術、會不斷思考如何讓自己寫出來的軟體帶給更多人價值；當這樣的狀態持續下去，財務上的回報往往會成為順理成章的結果，而不是刻意追求的目標。