使用 Codex 進行程式碼審查時，有些意見會一再出現。例如保留舊版 API 契約、不讓客戶資料寫入日誌，或避免因重新命名而導致其他服務故障。這些檢查很重要，但如果只有少數審查者掌握相關背景，就很容易遺漏。
Codex 程式碼審查現在可以使用 AGENTS.md 中的自訂程式碼庫規則，找出這些問題，並向作者指出審查意見所依據的指引。如果你已經使用 AGENTS.md 指導程式碼編寫任務，同一份檔案也能用來指導審查。當貢獻者或程式碼編寫智慧體正在處理程式碼庫中不熟悉的部分、尚未了解其歷史背景時，這尤其有用。本文將說明程式碼庫規則的用途、如何寫出有效的規則，以及我們在測試過程中學到的經驗。
交付更多程式碼
程式碼編寫智慧體能承擔更大規模的變更，並持續執行更長時間的任務，協助團隊將更多構想化為程式碼。在 OpenAI，自第四季以來，每週 PR 數量已超過原本的兩倍，我們也在許多客戶身上看到類似趨勢。更多程式碼是件好事：團隊能推出新功能，解決更多問題。但這也代表有更多 Pull Request 等待熟悉檢查重點的人來審查，程式碼審查很快就可能成為瓶頸。
多項變更同時送來時，審查就更困難了。差異內容看起來可能完全合理，卻仍可能導致舊版用戶端故障，或越過作者不知道的界線。必須有人記得這些背景，並在作者還來得及調整時提供相關資訊。
審查的瓶頸
送來的 Pull Request 越多，審查者在提供意見前，能用來了解每項變更的目的和蒐集相關背景的時間就越少。一旦作者轉去處理其他事情，即使只是小幅修訂，也可能花上更長時間。及時的回饋能讓團隊充分發揮開發加速的效益，避免人力成為瓶頸。
有些問題也很難只從差異內容看出來。重新命名回應欄位可能看似例行整理，卻可能導致仍依賴現有契約的用戶端故障。資深審查者可能記得為什麼必須保留這個欄位；新加入的貢獻者或首次處理這項服務的智慧體，多半不會知道。
以規則作為介面
那麼，該如何讓程式碼編寫智慧體掌握團隊平時逐漸累積的背景知識？新的程式碼庫規則介面讓你能在 AGENTS.md 中寫下簡潔、適用範圍明確的審查指引。Codex 程式碼審查可以套用與變更相關的規則，並在指出問題時引用這些規則。你不必在每個 Pull Request 中重複同樣的說明，只要把指引放在適用的程式碼附近即可。
隨著程式碼編寫模型越來越能依照指示行事，一段簡短、適用範圍明確的指示，就能協助模型在冗長的審查中聚焦於團隊真正關心的事項。Codex 自己的程式碼庫也將程式碼審查規則放在 AGENTS.md 中，涵蓋模型可見的上下文、不相容變更等注意事項。
以下是一個真實案例：
Codex app-server 會發出名為 rawResponseItem/completed 的內部通知。雖然這項通知標示為實驗性功能，Codex 雲端卻已經在使用它。程式碼庫的不相容變更審查規則明確指出，rawResponseItem/* 是供其他服務整合使用的介面，即使仍處於實驗階段，審查者也應確保它維持相容。
現有的通訊名稱定義在 app-server 協定中。假設一次程式碼整理改動了其中一行：
-RawResponseItemCompleted => "rawResponseItem/completed"
+RawResponseItemCompleted => "rawResponseItem/done"這項變更可以通過編譯，但監聽現有通知的用戶端將無法再收到通知。相關的程式碼庫規則節錄很簡短：
## Code Review Rules
### Breaking changes
Search for breaking changes in external integration surfaces:
- raw response item events (`rawResponseItem/*`), even while experimental針對上述示範用的差異內容，程式碼審查可能會提出這樣的意見：
保留現有的
rawResponseItem/completed通知。 Codex 雲端中使用此通知的程式會監聽這個通訊名稱，因此即使這個事件仍屬實驗性功能，重新命名也會導致這些程式故障。請依照AGENTS.md的說明，保留現有名稱，或新增向後相容的事件。
Codex 團隊加入這條規則，就是為了保護 Codex 雲端中使用此通知的程式。請將適用於整個程式碼庫的規則放在根目錄，針對特定服務的規則則放在相關目錄。審查時，Codex 可以套用涵蓋變更檔案的指引，並向作者指出相關規則；與 app-server 無關的變更，就不需要它的背景資訊。
規則可以與團隊原本倚賴的工具搭配使用。對於能用明確邏輯判定的檢查，測試和 Lint 工具很有效；程式碼庫規則則能記錄較難寫成程式碼的判斷準則。相容性要求和資料使用界線都是很好的起點。作者不必先了解每一次過往事件或每個局部慣例，才能進行變更；相關指引已經放在那裡了。
寫出經得起考驗的規則
我們使用包含已知違規案例和安全反例的評估套件，測試程式碼審查運用程式碼庫指引的能力。在主要評估套件中，使用規則引導的各個版本找出了 98% 預期應由自訂規則偵測的問題，相較之下，基準對照組為 58.3%。
找出違反規則的問題只是工作的一部分。我們也想知道，當多條規則都需要關注，或 Pull Request 本身已有大量變更時，會發生什麼情況。我們既測試了影響重大的違規案例，也測試了不應被挑出問題的變更，並依照四個問題整理結果：
我們評估的面向
涵蓋能力
當差異內容繁多、多條規則都需要關注時，Codex 能否找出預期應偵測到的違規問題？
適度克制
對於沒有問題的變更和合理的例外，能否避免提出不必要的審查意見？
既有能力的維持
程式碼審查是否仍能找出程式碼庫規則未涵蓋的一般錯誤？
意見的可執行性
每一項審查意見是否都指出相關指引、位置和優先順序？
我們也嘗試了各種常見的指引寫法，從簡短的項目清單，到由特定團隊負責的章節都有。
在內部程式碼庫使用規則時，我們也觀察到相同的情況。Codex 能找出並引用預設審查可能遺漏的局部指引，但過於籠統的指示很容易產生干擾。數量精簡、範圍明確，並清楚說明安全做法的規則，能幫助 Codex 聚焦於最有用的事項，避免把同一條規則套用到附近的每一項變更。
從影響重大、卻不易察覺的不變條件著手。 將審查者反覆解釋的檢查事項寫成規則，例如相容性要求或資料使用界線。如果移除某條規則不會改變審查結果，就不必保留。
將規則的適用範圍限定在它所規範的程式碼。 適用於整個程式碼庫的指引放在根目錄，針對特定服務的指引則放在子目錄的 AGENTS.md 中。縮小範圍能避免無關指示分散注意力，也能明確界定由誰負責。
說明必須維持的不變條件和安全做法。 rawResponseItem/* 規則指出了相容性風險，而「保留現有名稱，或新增向後相容的事件」則為作者提供了明確的替代做法。
讓規則長期適用，並持續更新。 描述應達成的結果，而不是可能變動的函式名稱。審查規則的更新內容，並縮小一再產生干擾的指引範圍，或將其移除。
格式和其他機械式檢查仍交由 CI 處理。把程式碼庫規則留給那些若沒有指引，審查者就得再問一次的問題。
開始使用
如果你的程式碼庫已啟用 Codex 程式碼審查，請在適用的 AGENTS.md 檔案中加入兩到三條規則，並建立一個具代表性的 Pull Request。如果你剛開始使用程式碼審查，程式碼審查快速入門會說明如何為 GitHub 程式碼庫啟用這項功能。你也可以直接使用 @codex review 要求審查。
先從審查者反覆解釋的事項著手，或選擇程式碼庫中特有、且漏掉後會造成重大影響的錯誤。試試三種變更：一項應觸發規則的變更、一個安全反例，以及一項無關的變更。確認第一項會產生有用的審查意見，而另外兩項不會產生干擾，再根據觀察結果調整指引。
Codex 程式碼審查仍是額外的審查者；測試、分支保護和必要的核准程序，依然負責強制把關。
如果你發現自己花在審查變更上的時間比編寫變更還多，就從團隊反覆進行的一項檢查開始。把它加入 AGENTS.md，並在下一個 Pull Request 上試用 Codex 程式碼審查。