Jev Review
使用 jev_review 作為輕量級、可重複執行的資深工程師審查循環。主要編碼代理負責實作、驗證與最終判斷；Jev Review 僅評估提供的變更，但絕不編輯檔案。
審查節奏
對於非瑣碎的任務，傾向往工作中期進行多次聚焦審查，而非在最後進行一次大型審查：
- 在每個足以判斷的合理實作片段完成後呼叫，例如完成一個行為、模組、API 邊界、遷移步驟或測試策略。
- 在出現新的控制流程、狀態處理、依賴項、公開合約或安全性敏感行為時呼叫。
- 在根據合理的回饋進行改進後再次呼叫，並將先前的結果作為
previousEvaluation傳入，以便 Jev 識別改善與回歸。 - 在最終移交之前，確保最新的審查涵蓋了最終實作。
中間審查不需要等待完整的測試套件。在可行時執行快速、相關的檢查，並將其狀態包含在 repositoryContext 中；在最終審查前執行儲存庫的正常驗證。不要重複完全相同的呼叫，不要審查僅有格式變更的雜訊，也不要在沒有合理實作狀態時呼叫。頻繁的聚焦審查很有用；但空泛的審查則無用。
工作流程
- 理解使用者實際的需求與限制。
- 檢查儲存庫、其慣例以及受影響的行為。
- 實作請求變更的一個合理片段。
- 在可行時執行快速、相關的測試、型別檢查、linter 或其他驗證。
- 僅使用評估當前片段所需的上下文來呼叫
jev_review。 - 檢查低信心結果、弱維度、優先問題以及任何回歸。
- 決定哪些回饋有程式碼和使用者任務支援。將評估視為證據，而非最佳化每個數字的指令。
- 在回饋識別出真正價值的地方改進實作，優先考慮正確性、認知複雜度、可變性、耦合度、模組化、抽象品質、測試和安全性。
- 針對下一個合理片段重複實作、驗證和審查循環。
- 在審查驅動或其他重大變更後，再次呼叫
jev_review並將先前的結構化評估作為previousEvaluation傳入。 - 在最終移交前執行儲存庫的正常驗證，然後審查最終狀態（如果最新的評估已不再涵蓋它）。
- 當重要風險已解決，且進一步的更改只會增加很少實際價值時停止。
選擇上下文
傾向於使用如下所示的聚焦呼叫：
{
"task": "使用者請求的行為及相關的驗收限制",
"diff": "實作差異",
"files": [
{
"path": "src/example.ts",
"content": "僅在需要周圍程式碼來理解 diff 時提供"
}
],
"repositoryContext": "相關的架構、慣例、測試結果或不變量",
"previousEvaluation": {}
}
如果 Jev 報告其輸入限制已超過，請減少不相關的檔案內容，或將實作拆分為合理的審查片段。不要盲目截斷程式碼，以免移除正確判斷變更所需的合約、呼叫者或測試。
在大多數審查中使用 task 和 diff。僅當 diff 缺乏必要的周圍行為時才新增完整檔案。使用 repositoryContext 提供評估者無法推斷的簡明事實，例如已建立的模式或驗證結果。
預設情況下不要傳送整個儲存庫。排除不相關的檔案、生成的輸出、供應商代碼、機密、憑證、私鑰、環境檔案以及有雜訊的鎖定檔案變更，除非它們與審查直接相關。
解讀結果
- 正確性和使用者的需求優先於所有分數。
- 低信心分數是檢查上下文的提示，而非重寫程式碼的理由。
- 標記為
applicable: false的條件指標無需採取任何行動。 - 使用
priorities尋找最重要的弱維度，然後在更改程式碼之前檢查實際程式碼。 - 在比較評估時，調查有意義的回歸以及仍未解決的弱指標。不要追逐微小的分數變化。
- 繼續依賴測試、型別檢查、linter、安全工具和人類判斷。Jev Review 是它們的補充，而非替代。
不要玩弄分數
更高的分數絕不能證明以下行為合理：不必要的抽象、投機性架構、範圍擴張、破壞現有行為、重寫可正常運作的程式碼、沒有證據的非常規架構、無意義的測試、不必要的註解，或僅僅為了縮小檔案而拆分內聚的程式碼。
不要假定短函數、小檔案、單一用途類別、零重複、更多抽象、更多測試或更多註解就一定是更好的。根據此儲存庫和此任務的具體情況評估後果。