AI產生的程式碼審查訓練：如何教導開發人員審核模型所寫的內容

一位開發人員向助手請求編寫一個函數，用於檢查使用者是否可以下載報告。程式碼編譯通過，正常流程測試也通過了，提交的拉取請求看起來也很簡潔。兩週後，一位同事發現該函數雖然檢查了用戶是否已登錄，但從未檢查報告是否屬於該用戶。

這是一個範例場景，並非已記錄的事件。它描述了人工智慧產生的程式碼審查培訓需要彌補的差距：即使產生的程式碼通過了基本檢查，仍然可能包含授權或並發缺陷，審查人員需要找出這些缺陷並說明其重要性。

本指南面向工程賦能負責人和工程經理。內容涵蓋如何描述效能問題、診斷差距、設計準備和實踐、案例分析以及評估技能是否能應用於實際評審。它著重於培訓設計。您專案中的每個缺陷、測試和評審規則都應由高級工程師和安全團隊驗證。

什麼是AI生成的程式碼審查訓練？

AI產生的代碼審查訓練教會開發者如何清楚地向助手提出問題，然後評估和審核返回的結果：代碼是否正確、是否安全、在並發負載下是否穩定、是否足夠高效？這並非針對特定工具的課程，而是培養一種即使工具變更也能保持不變的審查習慣。

要聞速覽

1. 描述效能問題

首先，任務是：審核產生的程式碼，並透過測試來驗證風險。審核是帶著懷疑的態度閱讀程式碼。驗證則是將懷疑轉化為證據，通常是透過失敗的測試或重現缺陷的實例來實現。

研究表明，這需要刻意練習。在 GitHub Copilot 的一項研究中，Pearce 及其同事針對已知的弱點類型，在 89 個場景中生成了 1,689 個程序，發現其中約 40% 存在漏洞（Pearce 及其同事，2021那是一個早期工具，針對的是一組特定的場景，所以不要將該數據視為當今助手的適用率。另一項使用者研究要求參與者在有AI助理和沒有AI助手的情況下編寫程式碼。結果顯示，使用助手的參與者編寫的程式碼安全性明顯更低，而且他們更傾向於認為自己的程式碼是安全的（Perry及其同事，2023同一項研究發現，對助手信任度較低、更積極配合助手提示的參與者表現出的脆弱性較少。

以下兩點經驗可用於訓練設計：首先​​，合理的產出需要積極的審查；其次，自信並非證據，因此練習必須要求進行測試，而不是徵求意見。

用一句話寫出性能說明，並讓工程經理檢查一下：“給定一個生成的變更，開發人員列出他們看到的安全性、並發性和效率風險，並針對每一種風險描述或編寫一個可以證明該風險的測試。”

2. 診斷學習與情境差距

在著手建立任何內容之前，請將任務與你現有課程的練習和評估方式進行比較。通常，以下三個問題可以區分訓練差距與其他問題：

1. 目前的做法是否使用了實際任務？ 如果培訓內容僅限於編寫提示程式碼，卻從不要求開發人員審查輸出結果，那麼就沒有人真正實踐過稽核。如果評估方式是針對安全編碼規則的多項選擇題，那麼它衡量的只是規則的記憶。
2. 認知需求是什麼？ 在布魯姆修訂後的分類法中，判斷程式碼是否安全以及選擇合適的測試來證明其安全性屬於分析和評估層級，而設計更好的提示或修復方案則屬於創造層級。我們的指南中介紹瞭如何將活動與這些層級相匹配。 將學習活動與布魯姆分類法相匹配.
3. 除了技能之外，還有其他因素阻礙了你嗎？ 檢查審核時間、工具和負責人。如果審核人員每個拉取請求只有五分鐘時間，那麼沒有經過訓練就無法進行審核。如果流程中沒有靜態分析或測試框架，開發人員可能會發現風險，但卻無法證實。將非培訓原因報告給能夠解決這些問題的人員。

3. 設計準備與練習

一旦你了解訓練可以彌補哪些差距，就給每個階段一個明確的任務。

準備。 透過簡短的診斷來檢查前提條件：你的測驗體系面臨的常見弱點類別、測驗的結構以及團隊使用的複習清單。自主學習適合這個階段。回顧檢查僅用於確認前提條件。

實踐。 使用基於真實生成程式碼建構的稽核練習。每個練習都預先設定少量不同類型的缺陷，例如缺少所有權檢查、兩個請求之間存在競爭條件以及低效的循環，同時添加一些正常的程式碼。開發人員審查程式碼，指出每個風險，說明其嚴重程度，並提出能夠重現該風險的測試方案。要求開發人員提供理由，而不是只是羅列程式碼行號。

反饋。 將其與決策聯繫起來，而不是與總分聯繫起來。 「你標記了循環，但沒有標記共享計數器上的競爭條件，而且你的測試不會發現它，因為它一次只運行一個請求」比「找到 3 個中的 2 個」更有用。

即時輸入還是非同步審核？ 當風險不明確時，即時回饋最有價值，開發人員可以透過聆聽資深工程師解釋為何會阻止合併來學習。非同步評審足以將開發人員的發現與專家的註釋評審進行比較。許多團隊會同時採用這兩種方式：先進行自主準備，然後再針對疑難案例進行引導式討論​​。

4. 透過一個實際例子進行分析

舉例說明。工程經理在使用前應驗證案例和答案標準。

案子。 產生的端點會根據發票 ID 傳回客戶的發票。它會檢查呼叫者是否擁有有效的會話，使用參數化查詢，並通過基本測試。此函數也會在不加鎖的情況下遞增共享的下載計數器。

任務。 開發人員列出了他們看到的每項風險，對風險進行了排名，並描述了可以證實每項風險的測試。

第一次嘗試。 「看起來沒問題。查詢語句已參數化，測試也通過了。」 開發人員將測試通過視為萬無一失，而沒有追問測試遺漏了哪些內容。

反饋並重試。 審核人員要求開發人員說明會話檢查證明了什麼，又沒有證明什麼。重試要求他們考慮兩個不同的客戶和兩個同時發生的請求。

一次更有力的嘗試。 「會話檢查只能證明是誰在打電話，並不能證明發票是他們的。我會編寫一個測試，讓客戶 A 請求客戶 B 的發票 ID，並預期會被拒絕。計數器在沒有同步的情況下遞增，因此兩個同時請求可能會導致更新丟失。我會運行一個並發測試並比較計數。查詢本身是參數化的，所以我不會注意了這一點。

解釋每種回應的合理性或不足之處。 評判每項內容都應依據既定標準，而非評審者的個人偏好。第一次嘗試往往出於習慣，卻忽略了證據。而更有效的嘗試則應具體明確、分清輕重緩急且可驗證。

5. 評估能力並制定轉移計劃

能力證明體現在學習者完成一項先前未曾接觸過的新練習。評分標準包括品質驗證和相關缺陷的識別。一個簡單的評分細則採用0到2分的等級制，每個標準對應一個評分標準：

評分標準：0 分錶示缺失或不支持，1 分錶示部分缺失相關內容，2 分錶示完整且符合既定標準。請單獨定義關鍵錯誤，例如批准具有未保護存取路徑的程式碼，以確保總分不會掩蓋此類錯誤。本評分標準僅為建議，並非已驗證的就緒標準：請與工程經理共同調整並進行試點。請參閱我們的指南。 設計具有實用回饋的互動練習 展示如何撰寫與決策相關的回饋意見。

精心規劃代碼移交。練習結束後，讓每位開發人員與一個包含生成程式碼的真實拉取請求配對，並共同審查他們的發現，或對最近一次遺漏之處的審查進行簡短的回顧。

互動式教學有助於

互動式格式有助於確保每個人在小組會議開始前就做出承諾。在即時會議中，主持人可以展示一段產生的程式碼片段，要求每位開發人員輸入他們看到的風險以及他們將要編寫的測試，然後在討論之前公佈結果。同樣的練習也可以以自學模式進行，以便進行準備。 AhaSlides 支援互動式學習，並可在即時和自學模式之間靈活切換。它是一個演示和學習工具，而不是程式碼運行平台，因此請在您自己的環境中執行程式碼練習。請將您計劃使用的任何特定創作、回饋或報告功能與您自己的工作流程進行核對。有關選擇格式的指導，請參閱我們關於…的文章。 何時使用自適應、互動式和即時學習.

衡量發生了哪些變化

預先決定哪些指標能夠證明開發人員勝任該任務。將未見過的練習的驗證品質和缺陷識別情況與基準進行比較。明確參與人員、分母和時間節點。如果結果有所改進，在將改進歸功於培訓之前，請檢查同一時期內還有哪些其他變化，例如新的靜態分析規則、修訂的審查清單或助理的更換。

可能存在的限制

• 複習時間。 審計比粗略瀏覽花費的時間更長，而截止日期又促使人們傾向於粗略瀏覽。
• 工裝。 如果沒有測試裝置或管道掃描，風險很難證實。
• 更換工具。 助手更換很快，所以練習應該圍繞著評價習慣展開，而不是針對某個產品。
• 案件承保範圍。 一項練習展示了幾種缺陷類型。評分並不能反映開發人員的整體判斷。
• 轉讓。 研討會上的表現與繁忙的評審隊列上的表現並不相同。

儘早將這些問題告知贊助商，並制定單獨的解決方案。培訓可以提高開發人員發現和驗證問題的能力，但並不能節省時間或創造工具。

常見問題

什麼是AI生成的程式碼審查訓練？

它教導開發人員如何提示、評估和審查 AI 助理產生的程式碼，找出安全性、並發性和效率問題，並用測試來驗證每個問題。

系統產生的程式碼比人類寫的程式碼安全性更低嗎？

研究顯示存在風險，但結果取決於工具、任務和研究設計。一項使用者研究發現，有助手協助的參與者編寫的程式碼安全性較低，但卻對自己的程式碼更有信心，這說明培養程式碼審查習慣很有必要。

如何評估開發人員是否能夠審核產生的程式碼？

佈置一項新的代碼練習，並根據既定標準對代碼品質和缺陷識別進行評分。安全編碼規則測驗僅用於確認是否符合前提條件。

你們需要用於培訓的代碼沙箱嗎？

你需要一個地方來進行練習，通常是你自己的環境。在使用任何工具之前，請務必確認它能滿足你的需求。

從哪兒開始

選擇程式碼庫中一種常見的變更類型。撰寫效能說明，請工程經理驗證預設缺陷及其對應的測試案例，並擬定一個包含三個標準的評分細則（0 到 2 分制）以及一份關鍵錯誤清單。在正式推廣之前，先在一小群人中進行試點。

若要了解如何讓審計練習在您自己的團隊中即時進行，並在之後以自定進度重複使用，請探索 AhaSlides。