設定 --max-findings 5 之後，系統怎麼決定哪 5 條會被留下、哪些會被捨棄？
公開說明沒有詳述具體的排序演算法，但從這個參數的設計目的（控制呈現給審查者的發現數量上限）可以合理推斷，系統內部應該是先完成完整的問題檢測，再依照某種嚴重程度或重要性的排序邏輯，只回傳排名前面的幾條——也就是說「找得少」跟「找得到但只回報最重要的」是兩回事，--max-findings 做的是後者。
如果你發現某次審查用 5 條上限時漏掉了一個你認為重要的問題,比較務實的做法是改用 all 跑一次完整列表做對照,確認是排序邏輯跟你的判斷有落差，還是這個問題原本就沒被偵測到。
如果團隊裡不同人對同一次 review 設定不同的 --max-findings 數字，會不會導致大家看到的審查結果品質不一致？
理論上會。假設系統內部的排序邏輯是固定的、不會因為設定的數字不同而改變哪些問題被判定為「最重要」，那麼設小數字的人只是看到完整清單的一個子集，而不是看到品質更差的審查結果——但實務上，如果團隊裡有人習慣設 3、有人習慣設 20，彼此在討論「這次審查有沒有抓到問題 X」時，可能會因為各自看到的清單長度不同而產生認知落差，容易誤以為是審查品質不穩定，實際上只是呈現範圍不同。
比較好的做法是團隊內部統一標準,針對不同情境（初審/終審）訂出共同遵守的預設值，而不是放任每個人依照個人習慣自由設定，這樣至少能確保大家在同一個情境下看到的是同一套標準。
--max-findings default 跟不加這個參數直接跑 /code-review，結果會一樣嗎？
從參數設計的邏輯推斷，應該是一樣的——default 這個選項存在的意義，比較像是讓你能在腳本或設定檔裡明確寫出「使用系統預設值」這個意圖，而不是省略參數、讓行為隱性地落到預設值。對互動式手動輸入指令的情境，兩者效果理論上沒有差異；但如果你是把 /code-review 包進自動化腳本，顯式寫出 --max-findings default 能讓之後讀這份腳本的人更清楚知道「這裡是刻意選擇預設行為」，而不是「忘記設定這個參數」。
對一個剛開始導入 /code-review 到團隊流程的團隊，--max-findings 應該從哪個數字開始試？
沒有放諸四海皆準的數字，但一個合理的起點是：先用 all 跑幾次完整審查，實際觀察一個典型 PR 通常會產出多少條發現、其中真正被採納修改的比例大概是多少。如果你發現一個中等規模的 PR 經常跑出 30 條以上的發現，但團隊實際會處理的往往只集中在前 5 到 8 條，那麼把日常預設值設在這個區間,會比較貼近團隊真實的審查行為模式，而不是憑空猜測一個數字。
這個校準過程本身也值得定期重做——隨著程式碼庫的品質逐漸提升，或團隊的審查標準調整，合理的預設值也可能跟著變化,不是一次設定就一勞永逸。
使用 Claude Code 的 /code-review 指令做程式碼審查時，一個常見的實務困擾是：對一個改動範圍較大的 commit 或 PR 跑 review，Claude 可能一口氣回傳數十條發現項目，從嚴重的邏輯錯誤到無關緊要的命名建議全部混在一起，審查者反而要花額外力氣先篩選「這些建議裡哪些真的值得處理」。近期版本新增的 --max-findings 參數，讓你可以直接控制這次審查回傳的發現數量上限。
/code-review --max-findings <n>|all|default 支援三種指定方式：給一個具體數字（例如 --max-findings 5），代表這次審查最多只回傳 5 條發現；填 all，代表不設上限、回傳所有找到的問題；填 default，則是沿用系統原本的預設行為。這個參數讓你在「審查範圍廣、想要全面檢查」跟「審查範圍小、只想快速看最關鍵的幾個問題」這兩種情境之間，能直接用一個參數切換，而不必每次都手動從一長串清單裡自己篩選。
Code review 工具的輸出品質，不只看「有沒有抓到問題」，也要看「呈現方式有沒有造成審查者的認知負擔」。一次丟出過多發現項目，即使每一條本身都合理，也會稀釋審查者對真正重要問題的注意力——這跟人工 code review 裡「review 意見太多，反而讓人想隨便全部接受」的現象是類似的風險。限制發現數量，等同於強迫系統對問題按嚴重程度排序，只回傳最值得優先處理的那幾條，這對於需要在有限時間內完成審查的場景特別實用。
如果你是在 PR 審查的快速初篩階段，目的是先抓出會阻擋合併的關鍵問題（例如安全漏洞、邏輯錯誤），設定一個較小的數字（例如 3 到 5）比較合適——這逼迫系統只回報它認為最嚴重的幾項，你可以優先處理這些再決定是否需要更全面的審查。如果你是在做一次性的、全面的程式碼品質盤點（例如重大重構前的健檢），用 all 讓系統回傳所有發現會更合適，因為這個情境下你真正需要的是完整的問題清單，而不是篩選過的子集。
如果你的團隊已經把 /code-review 整合進日常的 PR 審查流程，--max-findings 值得被納入團隊的標準操作流程，而不是讓每個人憑感覺決定要不要看完整清單——比較合理的做法是，針對不同審查情境（例如快速初審 vs. 合併前最終審查）訂出不同的預設值，寫進團隊的 code review 指引裡,讓審查流程的嚴謹程度跟審查的緊迫程度對齊，而不是每次都用同一套「全部列出來，自己再篩」的方式，徒增不必要的審查時間成本。