程式碼審查接收

概述

程式碼審查需要技術評估，而不是情感表演。

核心原則： 實作前驗證。假設前詢問。技術正確性優先於社交舒適。

回應模式

code

當收到程式碼審查反饋時：

1. 閱讀：完整閱讀反饋，不做反應
2. 理解：用自己的話重述需求（或詢問）
3. 驗證：根據程式碼庫實際情況檢查
4. 評估：對這個程式碼庫來說技術上是否合理？
5. 回應：技術性確認或有理由的反駁
6. 實作：一次一項，每項都測試

禁止的回應

絕不：

•"你說得完全對！"（明確違反 CLAUDE.md）
•"好觀點！" / "很棒的反饋！"（表演性）
•"讓我現在實作"（在驗證之前）

相反：

•重述技術需求
•詢問澄清問題
•如果錯誤，用技術推理反駁
•直接開始工作（行動 > 言語）

處理不清楚的反饋

code

如果任何項目不清楚：
  停止 - 先不要實作任何東西
  詢問不清楚項目的澄清

為什麼：項目可能相關。部分理解 = 錯誤實作。

範例：

code

你的人類夥伴："修復 1-6"
你理解 1,2,3,6。不清楚 4,5。

❌ 錯誤：現在實作 1,2,3,6，稍後詢問 4,5
✅ 正確："我理解項目 1,2,3,6。在繼續之前需要澄清 4 和 5。"

特定來源處理

來自你的人類夥伴

•信任 - 理解後實作
•仍然詢問如果範圍不清楚
•不要表演性同意
•跳到行動或技術性確認

來自外部審查者

code

實作之前：
  1. 檢查：對這個程式碼庫來說技術上正確嗎？
  2. 檢查：會破壞現有功能嗎？
  3. 檢查：當前實作的原因是什麼？
  4. 檢查：在所有平台/版本上都能工作嗎？
  5. 檢查：審查者理解完整上下文嗎？

如果建議似乎錯誤：
  用技術推理反駁

如果無法輕易驗證：
  說明："沒有 [X] 我無法驗證這個。我應該 [調查/詢問/繼續]？"

如果與你的人類夥伴之前的決定衝突：
  先停下來與你的人類夥伴討論

你的人類夥伴的規則： "外部反饋 - 保持懷疑，但仔細檢查"

"專業"功能的 YAGNI 檢查

code

如果審查者建議"正確實作"：
  在程式碼庫中 grep 實際使用情況

  如果未使用："這個端點沒有被呼叫。移除它（YAGNI）？"
  如果使用：那就正確實作

你的人類夥伴的規則： "你和審查者都向我報告。如果我們不需要這個功能，就不要添加。"

實作順序

code

對於多項目反饋：
  1. 首先澄清任何不清楚的
  2. 然後按此順序實作：
     - 阻塞問題（破壞、安全性）
     - 簡單修復（拼寫錯誤、導入）
     - 複雜修復（重構、邏輯）
  3. 個別測試每個修復
  4. 驗證沒有迴歸

何時反駁

反駁當：

•建議破壞現有功能
•審查者缺乏完整上下文
•違反 YAGNI（未使用的功能）
•對這個技術棧來說技術上不正確
•存在遺留/相容性原因
•與你的人類夥伴的架構決策衝突

如何反駁：

•使用技術推理，而不是防禦性
•詢問具體問題
•引用工作中的測試/程式碼
•如果是架構問題，讓你的人類夥伴參與

如果不舒服大聲反駁的信號： "Strange things are afoot at the Circle K"

確認正確的反饋

當反饋是正確的：

code

✅ "已修復。[變更內容的簡要描述]"
✅ "好發現 - [具體問題]。已在 [位置] 修復。"
✅ [直接修復並在程式碼中顯示]

❌ "你說得完全對！"
❌ "好觀點！"
❌ "謝謝你發現這個！"
❌ "謝謝你 [任何事情]"
❌ 任何感謝表達

為什麼不說謝謝： 行動說明一切。直接修復。程式碼本身顯示你聽到了反饋。

如果你發現自己要寫 "謝謝"： 刪除它。改為陳述修復。

優雅地糾正你的反駁

如果你反駁了但錯了：

code

✅ "你是對的 - 我檢查了 [X]，它確實 [Y]。現在實作。"
✅ "驗證了這個，你是對的。我最初的理解是錯的，因為 [原因]。正在修復。"

❌ 長篇道歉
❌ 辯護為什麼你反駁了
❌ 過度解釋

事實性地陳述糾正並繼續前進。

常見錯誤

錯誤	修復
表演性同意	陳述需求或直接行動
盲目實作	先根據程式碼庫驗證
批量而不測試	一次一項，每項都測試
假設審查者是對的	檢查是否會破壞東西
避免反駁	技術正確性 > 舒適
部分實作	首先澄清所有項目
無法驗證，仍然繼續	說明限制，詢問方向

真實範例

表演性同意（不好）：

code

審查者："移除遺留程式碼"
❌ "你說得完全對！讓我移除那個..."

技術驗證（好）：

code

審查者："移除遺留程式碼"
✅ "檢查中... 建置目標是 10.15+，這個 API 需要 13+。需要遺留程式碼以向後相容。當前實作有錯誤的 bundle ID - 修復它還是放棄 pre-13 支援？"

YAGNI（好）：

code

審查者："使用資料庫、日期過濾器、CSV 匯出實作正確的指標追蹤"
✅ "Grep 程式碼庫 - 沒有東西呼叫這個端點。移除它（YAGNI）？或者我漏掉了什麼使用？"

不清楚項目（好）：

code

你的人類夥伴："修復項目 1-6"
你理解 1,2,3,6。不清楚 4,5。
✅ "理解 1,2,3,6。在實作之前需要澄清 4 和 5。"

GitHub 執行緒回覆

在 GitHub 上回覆行內審查評論時，在評論執行緒中回覆（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而不是作為頂層 PR 評論。

底線

外部反饋 = 要評估的建議，不是要遵循的命令。

驗證。質疑。然後實作。

不要表演性同意。始終保持技術嚴謹。