程式碼庫稽核
稽核的價值在於排名與證據，而非篇幅長度。一項沒有檔案路徑、查詢結果、PR 編號或行數的發現，就是一個假說——請將其標示為假說。
將稽核根植於程式碼與生產環境，而非文件
專案筆記、計畫與狀態文件是檢查點，而非權威來源。從它們開始學習宣稱的內容，然後對照現實進行驗證：即時提交狀態、資料庫狀態、PR 檢查結果、分支 head。
當文件與程式碼不一致時，這個不一致本身就是一項發現——通常是稽核中最有價值的一項。
對生產環境的主張需要透過對生產環境的查詢來驗證。請將此技能與驗證閘門技能搭配使用來執行實際操作。
結構
# <範圍> 稽核 (YYYY-MM-DD)
## 摘要
<最重要的三件事，以及你會優先採取的行動。>
## 第一部分 — 你沒看到的東西（盲點，依序排名）
## 第二部分 — 缺失的功能（依序排名，每個附上粗略的工時估算）
## 第三部分 — 需要改進的現有功能（依序排名）
## 第四部分 — 架構變更（依序排名，使用白話文）
## 第五部分 — 如果我來主導接下來30天
## 可驗證清單（稽核期間發現的不一致事項）
所有項目都必須排名。 一份未經排名的40項發現清單，就是一份無法採取行動的40項清單。
在估算前檢查是否存在閒置的框架
為每個缺口附上粗略的工時估算，並說明其成本高低的原因。
單一最有價值的稽核發現通常如下：大部分高價值的「缺口」只需要數天的工作量，而非數週，因為倉庫中已存在框架，但沒有任何呼叫者。 一個已完成了80%的功能，其決策性質與一個完全未開發的功能截然不同。
在宣告某個東西缺失之前，先搜尋看看。函式沒有呼叫者是典型情況——程式碼存在，但沒有任何東西叫用它，而所有狀態文件都描述該功能為不存在。
可驗證清單
每次稽核都以無法解決的不一致事項作結。每個項目需說明：
- 宣稱的內容
- 觀察到的內容
- 哪個查詢或檢查可以釐清此事
這是下一個工作階段實際會使用的章節。 即使內容很短，也請務必撰寫。
明確標示為不值得做的事項
列出你檢查過並刻意拒絕的項目，並附上理由。
只會增加待辦事項的稽核，會讓待辦事項清單變得無用。你審視過並排除的發現，其價值遠高於從未提及的發現，因為它能防止下一次稽核再次提出相同的問題。
已擱置項目不是缺口
任何已標示為刻意延遲、或待明確人為決策的項目，都是刻意被擱置。請勿將其列為缺口。
將刻意擱置的項目重新作為發現提出，可能會導致擱置的決策被意外執行。
輸出
將稽核報告寫在專案存放這些報告的地方。如果它取代了先前的稽核，請說明哪一份報告被取代，以及什麼改變了——稽核資料夾應保持可依時間順序閱讀的連貫性，而不是一堆雜亂的文件。