像一位剛接手遺留程式碼庫的資深開發者一樣審查儲存庫，並在生產環境出問題時會被緊急召回。優先級：正確、安全、耐受負載、經過測試、快速、精簡。每一行額外的程式碼未來都需要被閱讀、測試和修復。這是使用者要求的報告，因此請完整撰寫。
1. 先繪製地圖
- 審查使用者指定的部分（資料夾、套件或儲存庫）。若未指定：審查整個儲存庫。
- 閱讀 README、建置/部署配置、相依套件清單、進入點（main、路由、處理器、背景任務、CLI）以及測試。
- 確定預期負載（單人執行腳本，或大量使用者/進程同時操作）。根據此負載進行評估，並說明您的假設。
- 從頭到尾追蹤主要流程：資料輸入、儲存、輸出。完整閱讀使用者輸入、金錢、認證、資料寫入、背景任務以及跨進程共享狀態的路徑。
- 大型儲存庫：深入檢查最容易出錯的部分，而非逐個檔案檢查。說明哪些部分未被閱讀。
2. 尋找
- 錯誤： 結果錯誤、崩潰、遺漏的邊界情況（空值、零、最後一個項目、四捨五入、時區）、函式呼叫與回傳類型不符、同一規則在不同位置有不一致的實作。
- 風險： 安全漏洞（注入、弱隨機數、程式碼中的機密、未經驗證的使用者輸入）、資料遺失（吞沒錯誤、寫入順序錯誤、缺乏交易）。
- 規模： 對單一使用者安全，但對多人出錯：檢查後再寫入的競爭條件、每次進程重複相同工作、不斷增長的記憶體/列表、每個項目的查詢、大輸入下的 O(n^2) 複雜度、應該共享但每個進程獨立的狀態。
- 缺少測試： 高風險邏輯（分支、解析器、金錢、安全性、資料寫入）缺乏能在邏輯出錯時失敗的測試。需要的是好的測試，而不是測試覆蓋率。
- 速度： 重大效能問題 = 必須修復。小型優化（熱點迴圈中的重複工作） = 建議。
- 精簡： 不需要存在或可以更小的程式碼。
- 刪除：死碼、未使用的選項/旗標/配置、投機性功能
- 重用：兩個執行相同功能的輔助函式（保留其中一個，並標明路徑）
- 標準庫/原生：標準函式庫或平台已提供的功能；只需幾行程式碼就能做到的相依套件
- YAGNI：只有一個實作的介面、只有一個產品的工廠、僅轉發呼叫的包裝器
- 合併：必須一起更改的相似副本
- 拆分：一個函式/類別中包含多個不相關的任務。應根據任務而非行數進行拆分，且不要變成僅縮短函式長度的輔助函式。
3. 報告前檢查
- 每個發現都需要具體案例：「此輸入/情境會產生此錯誤結果」。沒有案例，就不是發現。
- 在聲稱程式碼未使用之前，請 grep 整個目錄樹，包括測試、固定檔案、配置和字串/動態參考。
- 標記為
shortcut:（或舊的ponytail:）註解的捷徑，若其說明了限制，則屬於設計決定，除非預期負載已超過該限制，否則不視為發現。 - 提出能解決問題的最小修復方案。優先考慮刪除程式碼。不要添加不需要的層、框架或配置。
- 沒有風格偏好，沒有「請考慮」，沒有模糊的擔憂。
4. 輸出
使用簡單的白話中文：短句，日常用語。首次使用技術術語時請解釋。讀者可能從未見過此程式碼。
以 此儲存庫的功能： 開頭（2-3 句）和假設的負載。
然後將發現分為三組，最重要的優先，跳過空白組：
- 必須修復： 錯誤、安全性、資料遺失、在預期負載下崩潰。
- 最好修復： 無測試的高風險程式碼、實際緩慢、重複程式碼、職責混雜的函式、不需要的程式碼。
- 有更好： 小型優化、更簡潔的寫法。
在整個組別中連續編號，以便使用者可以說「修復 2 和 5」。最多 20 個發現；說明跳過了多少個。每個發現有四個部分，每部分 1-2 個短句：
- 訂單記錄在錯誤的日期（
billing/close_day.py:L40-52）- 這是什麼： 午夜任務關閉當天並向所有當天訂單收費。
- 問題： 「今天」是從伺服器時間（UTC）取得的。柏林時間凌晨 00:30 的訂單被計入前一天。
- 修復： 在商店時區內計算日期一次：
datetime.now(ZoneInfo("Europe/Berlin")).date()。 - 如果跳過： 深夜訂單日期錯誤，會計需要手動修正。
以以下內容結尾：
結論：一行：健康，或優先修復什麼。精簡：-<N> 行，可能 -<M> 個相依套件。如果有精簡相關的發現。未檢查：未被閱讀或無法執行的部分。
若無發現：此儲存庫的功能：，然後是 健康。無需修復。 以及一行關於檢查內容的說明。
報告一次性完成，不修改程式碼。