@claude review 留一句話其實是在訂閱：託管 Code Review 的 once、always、stop 與 After every push

PR 底下有人留了一行 @claude review。在 2026 年 7 月的更新之前，這行字的意思是「這個 PR 之後每次 push，都幫我審一遍」。現在它只審一次。repo 設成 Manual 或 Once 的話，之後你再 push，不會有人理你。

文件自己就寫了這段：「Before a July 2026 update, @claude review subscribed the PR to push-triggered reviews. If you relied on that behavior, comment @claude review always instead.」習慣了舊行為的人，會以為後面的 push 還有人在看。

這篇講的是託管版的 Code Review，也就是 GitHub PR 上由 Anthropic 基礎設施跑的那個服務，Team 與 Enterprise 方案才有。本站已經寫過本機的 /code-review 教學、它的參數順序，以及自己架在 CI 裡跑的 GitHub Actions。這一篇的切角不一樣：留言那一行字到底在跟誰說話，說完之後帳單會記到哪裡。

這篇全部來自官方文件與 changelog，我沒有 Team 或 Enterprise 組織，也沒裝 GitHub App，所以下面每個行為都是文件怎麼寫我就怎麼轉述，沒有實跑驗證。文件沒給數字的地方，我也不補數字。

先把留言當成訂報紙

這組指令用訂報紙來想，最容易排順。

@claude review 是買一份零售，這一期審一次，之後的 push 不歸它管。@claude review once 文件說跟它一樣。@claude review always 是訂閱：現在審一次，往後每次 push 都再審。@claude review stop 是退訂，文件特別寫了兩件它不做的事：不會開新的審查，也不會取消已經在跑的那一次。off 和 pause 跟 stop 一樣。

@claude review          單次審查，不訂閱後續 push
@claude review once     同上
@claude review always   審一次，並讓這個 PR 往後每次 push 都觸發審查
@claude review stop     退訂，不開新審查，也不取消正在跑的
@claude review off      同 stop
@claude review pause    同 stop

來源是文件的 pull request 頁。stop 家族是 2.1.307（2026 年 10 月 21 日）才加進來的，changelog 把它寫成新增，作用是結束 always 的訂閱而不開新審查。

不過這張表只講了一半。留言決定的是「這一個 PR」有沒有訂閱，而每個 repo 本來就有一個預設，那個預設才是第一個坑。

退訂這條路，在某些 repo 是死的

Owner 在管理頁替每個 repo 選「Review runs」，三種：Once after PR creation（PR 開啟、重新開啟、或標成 ready for review 時審一次）、After every push、Manual。照設定文件，新加進來的 repo 預設是 After every push，那是跑最多審查的一種，文件自己也這樣寫。

再回頭看報紙的比喻。After every push 的 repo 不是你個人訂閱，是整個社區統一配送：每個 PR 的每次 push 都有報紙送到門口，跟你有沒有訂無關。所以退訂口令在這裡沒有對象可以退。文件的原話是「In a repository set to After every push, you can’t stop reviews with a comment, because pushes there start reviews with or without a subscription.」

文件給的出路是把那個 PR 轉成 draft，等你再標成 ready for review，審查才會再開始。另外，不管選哪一種模式，draft 與來自 fork 的 PR 都不會被自動審查。

我讀到這裡的判斷是：想靠留言管成本的團隊，第一步該去動的是 Review runs，不是在 PR 上寫 stop。如果整個組織的 PR 都是小改動、推送次數少，又已經在用量頁設了花費上限，預設的 After every push 也可以接受；任何一條不成立，我會先把 repo 調成 Manual 或 Once，再讓需要的 PR 自己留 always。

留言為什麼有時候沒反應

指令生效有幾個條件，每一條文件都明寫了，也都很容易在手滑時踩到。

要是新的、頂層的 PR 留言。行內留言、review 本文都不算，改舊留言也不算。
整個指令要寫在留言開頭的同一行。always 或 stop 拼錯，或寫到第二行，Claude 會把整則留言當成一般的 @claude review，直接開一次單次審查。大小寫不拘。
你要有該 repo 的 write、maintain 或 admin 權限，機器人留的言不會觸發。PR 也必須是 open。

第二條最值得記。你想退訂，結果 stop 打成 stpo，換來的是多一次審查，而這個服務沒有固定單價，多一次就多一筆 token 費用。

還有一個容易誤判的訊號：Claude 可能會對你的留言加一個 👀 反應，但文件明說那個反應可能在沒有任何審查啟動的情況下出現，要看的是 check run。

錢記在誰頭上

這段我最想講清楚，它直接決定前面那些模式要不要在意。

照費用文件：Code Review 沒有固定每次審查的價格，按 token 用量計費，走 usage credits，跟方案內含的額度分開計。帳單記在組織，不記在開 PR 的人，也不記在按下審查的人。所以在 Manual 或 Once 模式下，有寫入權的任何人留一句 @claude review always，都等於替整個組織開了一條「每次 push 多付一次」的水管，文件也把這件事列為額外成本的來源。

上限設在 claude.ai/admin-settings/usage，針對 Claude Code Review 這個服務單獨設，套用到整個組織。預算花完時，PR 上會出現開頭是「⚠️ Code review skipped」的留言，疑難排解頁列了三種措辭，其中一種是 has reached its monthly code review spending cap。預算恢復之後，要在 PR 上再留一次 @claude review 才會補審。

審查等級也是花費的旋鈕。2.1.304（2026 年 10 月 19 日）加進 Quick、Standard、Deep 三級：Quick 最快、成本最低，Standard 是預設，Deep 最徹底、最慢也最貴。Owner 先選組織預設，再給個別 repo 覆寫，文件舉的例子是例行的 codebase 用 Quick，關鍵的用 Deep。新等級只對改完之後才開始的審查生效。至於各級實際要多久、多少錢，文件只有相對描述，沒有數字，所以這裡我也沒有。

審查結果的幾個細節

check run 的結論是 neutral，或在某些沒改檔案的 push 之後是 skipped，文件說它從不以 failure 收尾，所以審完不會害你的 required check 變紅。審查本身也不會 approve 或擋住 PR，要不要合還是人決定。

發現分三個標記：🔴 Important 是合併前該修的 bug，🟡 Nit 是小問題，🟣 Pre-existing 是本來就在 codebase 裡、不是這個 PR 引入的 bug。

push 之後如果標題是「Code review skipped — no new changes」，文件的意思是先前沒有還開著的 Important 發現，不必再審。標題是「Code review not repeated — earlier findings still open」，就是前一輪的 Important 還沒處理完：先推修正，或把那條討論串標成 resolved 再 push。

自動啟動的後續審查，例如 push 之後那一輪，重心放在上次之後的變動，nit 與 pre-existing 會報得比較少。想要什麼都不漏的一份，留 @claude review，它會把整個 PR 再審一遍。always 換來的後續審查屬於前一種，要完整的一輪就自己留單次的。

還有兩條會撞到的線

REVIEW.md 只有這個服務會讀。文件說服務同時讀 CLAUDE.md 與 REVIEW.md，而本機的 /code-review 讀 CLAUDE.md、不讀 REVIEW.md。同一份審查規矩寫在 REVIEW.md，本機跑出來的結果就不會套用它。服務讀的是 PR base branch 或預設分支上的版本，從不讀 PR 自己帶的改動，所以不能靠改 REVIEW.md 讓自己的 PR 過關。

另一個是跟 GitHub Action 並存。如果 repo 同時跑著 Claude Code GitHub Action 的 interactive 模式、用預設的 @claude 觸發詞，一則 @claude review 留言會把兩邊都叫起來。文件的建議是把 Action 的 trigger_phrase 設成別的詞。