單純要求 Claude Code「審查我的程式碼」往往效果不佳，因為它缺乏人類資深審閱者的結構化流程。本文介紹 ShipKit，這是一套為 Claude Code 設計的 24 項技能與 2 個 Git Hook，旨在透過明確的步驟，讓 AI 能夠更有效地執行錯誤修復、程式碼審查與功能驗證等任務。透過導入這些流程，開發者能獲得更可靠且可執行的回饋，大幅提升開發效率。
「審查我的程式碼」是一個很弱的提示詞。你可能會得到一份清單，其中有些項目是真的，有些聽起來是真的，還有一些是錯的，會讓你花 20 分鐘去檢查。問題不在於模型本身，而在於流程。
一位資深的人類審閱者不會只是閱讀差異並發表意見。他們會檢查哪些地方呼叫了被修改的方法，他們會在提出自己的發現之前，試圖證明自己的發現是錯的。他們會問：「有人執行過這個嗎？」因此，我將這些步驟寫成了 Claude Code 的技能，並以 ShipKit 的名義發布，包含 24 項技能和 2 個 Git Hook，採用 MIT 授權，適用於任何技術堆疊。
這篇文章將展示其中四項技能，說明每一項如何強制 Claude 執行特定任務，以及如何透過兩個指令安裝它們。
在 Claude Code 中安裝：/plugin marketplace add parvez-ahammed/shipkit /plugin install shipkit@shipkit。對於大多數技能，你不需要記住任何指令。用簡單的語言提問，Claude 會載入描述相符的技能。
有三個較長或個人化的技能（deliver-issue、show-usage、fill-timesheet）只有在你輸入指令時才會執行，因此在你需要它們之前不會產生任何成本。你也可以直接執行任何技能，例如 /shipkit:review-branch。
如果你只需要其中一項技能，每個技能都是一個獨立的資料夾。將 plugins/shipkit/skills/<name> 複製到 ~/.claude/skills/。
1. fix-bug：在找到根本原因之前不進行修復。處理錯誤的常見代理迴圈是：讀取錯誤、猜測、修補、完成。這通常有效。但當它無效時，你可能會修復了症狀，而錯誤卻在下週再次出現。fix-bug 阻止了這種捷徑。其順序是固定的：重現錯誤。找出根本原因，並將其寫成一個可測試的句子，包含檔案和行號。
證明它。光說「這行程式碼可能導致它」並不是證明。修復原因，而不是症狀，並使用最小的改動。添加一個迴歸測試，該測試在沒有修復時會失敗，有修復時會通過。重新驗證，並檢查附近是否有相同的錯誤。步驟 5 是人們最常跳過的一步。一個在修復前後都通過的測試，其實什麼都沒測試到。
你輸入的內容：這個端點從昨天開始返回 500 錯誤，請修復它。
2. review-branch：經得起反駁的發現。review-branch 會讓你的分支通過六個審閱者席位：後端、前端、架構、測試、品管（QA）和文本。第七個席位會檢查任何新依賴項的授權。然後是關鍵部分：每個發現都會經過一次反駁。一個獨立的檢查會試圖證明該發現是錯誤的。
例如，「缺少空值檢查」是否已由呼叫者處理？「未使用的程式碼」是否從差異中未觸及的檔案中呼叫？未能通過反駁的發現將被捨棄。你會得到一份經過排序的待辦清單和一份 HTML 報告。可選的評論模式會將發現發布到 GitHub、GitLab 或 Azure DevOps，但前提是它會重新檢查每個發現並得到你的確認。
你輸入的內容：在我開啟 PR 之前審查我的分支。其背後的原則是：一個提出五個真實發現的審閱者，比一個提出二十個並讓你檢查所有發現的審閱者更有價值。
3. test-branch：執行應用程式，而不是差異。「程式碼路徑執行 X」和「我執行了它並看到了 X」是兩種不同的說法。前者是一種論點，後者是證據。test-branch 從正在運行的應用程式開始。它會為變更所需的資料進行初始化，透過查詢預測結果，驅動 API 和瀏覽器，並撰寫一份帶有螢幕截圖的 HTML 報告，供產品負責人（PO）閱讀。它會比較基礎分支與你的分支，並且只列出仍未解決的問題。
你輸入的內容：針對正在運行的應用程式測試這個分支，並為 PO 提供一份報告。
4. grill-feature：承諾是真的嗎？你的登陸頁面寫著「使用者可以匯出所有內容」。他們真的可以嗎？包括已歸檔的項目嗎？超過 10,000 行的資料呢？grill-feature 會根據程式碼檢查一項承諾。答案有三種：BULLETPROOF（無懈可擊）：承諾在程式碼中得到實現，並附有檔案和行號。
CRACKED（有缺陷）：它有效，但這裡存在真正的差距或風險。FAKE（虛假）：程式碼並未實現它：一個存根、一個模擬或一個空操作。
你輸入的內容：結帳功能真的無懈可擊嗎？
套件的其餘部分包含以下領域技能：審查與修復（review-branch、fix-bug、build-story、test-branch、grill-feature）、規劃與交付（groom-issue、deliver-issue、price-product）、品管與使用者體驗（audit-app、find-ux-gaps）、重構（refactor、enforce-clean-architecture、find-shared-code、simplify-code、trim-comments）、部署與營運（deploy-to-vps，帶有誠實的健康檢查、add-mcp-server、boost-seo）、建立與文件（make-video、make-demo、write-user-guide、write-plainly）、洞察（show-usage、fill-timesheet）。
此外還有兩個 Git Hook：secret-hygiene 會阻止提交包含機密的程式碼，而 safe-commit 會檢查提交訊息。每個技能都遵循的三個規則是：有證據才說，發現會引用檔案和行號，如果技能無法看到，報告會顯示 UNKNOWN（未知），它不會猜測。
在任何東西離開你的機器之前先詢問，發布 PR 評論、提交工單、推送分支、附加檔案時，技能會向你展示它將發送的內容並等待你的確認。最後，它支援任何堆疊和任何作業系統，沒有框架鎖定，如果腳本需要 shell，則有 bash 和 PowerShell 版本。
我在建構它時學到的一件事是，ShipKit 最初有 30 項技能。我針對沒有技能的普通代理測試了每一項技能。其中六項沒有發現普通代理遺漏的任何東西，所以我將它們合併到其他技能中。後來我又合併了第七項。所有通過測試的技能都具有相同的形式：它們不教模型事實，而是強制執行它跳過的步驟。
在發布之前，我對每一項技能都應用了相同的規則：沒有重複的句子，並且在一個步驟中所需的細節被移到只有在該步驟才讀取的檔案中。
試試看：/plugin marketplace add parvez-ahammed/shipkit /plugin install shipkit@shipkit。儲存庫：github.com/parvez-ahammed/shipkit。
網站：parvez-ahammed.github.io/shipkit。所有技能：plugins/shipkit/skills。如果它為你節省了時間，在 GitHub 上給個星號有助於其他開發人員找到它。你的代理最常跳過哪個步驟？在評論中告訴我。如果這是一個常見的步驟，它很可能就是下一個技能。
覺得值得一看？分享給朋友。
以上為 AI 自動翻譯導讀。原文版權歸 DEV Community (Claude Code) 所有， 建議透過「閱讀原文」前往原始網站，以取得最完整資訊並支持原作者。
43 個來源、每 2 小時更新，太多看不完。電子報每週挑最值得看的幾則，附上 Max 的看法。
