Champion kit
工程師在內部倡導 Claude Code 的行動手冊：分享什麼、如何回答問題，以及如何在團隊中推動採用。
本頁面適用於已經在使用 Claude Code 並想幫助團隊採用它的個別工程師。它涵蓋了要分享什麼、如何回答你將收到的問題、三十天行動手冊，以及對常見疑慮的回應。
開發者工具的採用很少是因為推出公告而發生的。它發生在團隊中有人開始很好地使用該工具、公開談論它，並使其他人容易跟進的時候。你作為倡導者所做的工作對團隊有不成比例的影響：你分享的每個例子都會縮短後來工程師的學習曲線，你在公開場合回答的每個問題都會將一個人的經驗轉變為整個團隊可以建立的東西。
倡導者角色
該角色包含三種相互強化的行為。
| 行為 | 實際運作情況 | 為什麼重要 |
|---|---|---|
| 分享你的發現 | 在你的團隊已經閱讀的地方發佈提示詞、螢幕截圖和小成就，例如工程頻道、站立會議討論串或拉取請求描述。 | 從你自己的程式碼庫中提取的範例比任何外部文件更具說服力，因為同事可以看到該工具如何確切地應用於他們與你共享的問題。 |
| 成為人們詢問的對象 | 當同事詢問你如何完成某項工作時，用你實際使用的提示詞回應，以便他們可以直接將其應用於自己的任務。 | 一個具體、可運行的範例消除了好奇心和首次成功使用之間的差距，這正是大多數採用工作停滯的地方。 |
| 擴大圈子 | 建立少量輕量級的定期習慣，例如專用頻道或每週討論串，以便即使你的注意力轉移到其他地方，動力也能繼續。 | 依賴單一人員的採用是脆弱的。由共享習慣推動的採用會自動持續複合增長。 |
這應該花費你多少時間
與自己和你的主管設定期望。下面的活動旨在適應正常的工作週，該角色應該是對你現有工作的乘數效應，而不是額外的支持責任。
| 活動 | 每週時間 | 指導 |
|---|---|---|
| 發佈成就和提示詞 | 約 15 分鐘 | 用螢幕截圖和一兩句話在當下捕捉這些內容；避免將其轉變為正式的寫作。 |
| 在共享頻道中回答問題 | 約 20 分鐘 | 公開回答一次，然後當問題再次出現時連結回該答案。 |
| 主持每週展示和講述討論串 | 約 5 分鐘 | 你發佈開場提示詞；團隊提供內容。 |
| 可選的配對或逐步講解 | 0 到 30 分鐘 | 將此保留給被阻擋的同事，並在安排時間之前提供 快速入門 連結。 |
分享你的發現
你自己的經驗是同事會遇到的最有說服力的材料，因為它特定於你們共同使用的程式碼庫、工作流程和問題。文件告訴人們什麼是可能的；你的貼文向他們展示在你的環境中實際上什麼是有效的。
什麼值得分享
最有用的貼文描述的是同事明天就能重複使用的技術，而不是已經完成的結果。技術在團隊中傳播時會複合增長；狀態更新則不會。
可重複使用的技術範例：
- "我發現 @-提及一個目錄是有效的。我將其指向
@src/components/，並詢問哪些缺少測試，這暴露了我忽略的兩個。" - "Plan Mode（
Shift+Tab）在進行任何編輯之前準確顯示將觸及哪些檔案，這就是為什麼我對在共享程式碼上使用它感到放心。" - "我配置了一個 Stop hook，以便在長任務完成時收到桌面通知。配置在執行緒中。"
- "執行
/init會從儲存庫生成一個CLAUDE.md，所以助手停止重複詢問我們的約定。"
在哪裡分享
在你的團隊已經閱讀的地方發佈。目標是將範例放在正常工作的路徑中，而不是創建一個目的地。
| 位置 | 最適合用於 | 建議格式 |
|---|---|---|
#claude-code 或一般工程頻道 |
發現、提示和「今天我學到」的時刻 | 一張螢幕截圖，附帶一或兩句背景說明 |
| Pull Request 描述 | 在審查者已經閱讀的真實程式碼上演示該方法 | 單一行，例如「Claude 和我進行了這個重構；很樂意講解該方法。」 |
| 站會或每週書面更新 | 與主管和跳級經理規範化使用 | 一句話描述一個具體的結果 |
| 團隊 wiki 或內部文件 | 持久的模式、自訂技能和 CLAUDE.md 範例 |
一個簡短的頁面，從頻道主題連結，以便保持可發現性 |
有效的格式
一張螢幕截圖附帶單一行背景說明，或簡短的前後對比描述，通常是正確的細節層級。保持每個貼文簡短，使得瀏覽過的人仍然能吸收要點。冗長的文章往往會被保存以供稍後閱讀並被遺忘，而帶有螢幕截圖的簡短貼文往往會被複製和嘗試。
下面的範例貼文說明了語氣和長度；改編它們而不是逐字複製。
今天學到 @-提及一個目錄是有效的。我將其指向 @src/components/，並詢問哪些
元件缺少測試，它暴露了我忘記的兩個。
我配置了一個 Stop hook，以便在長任務完成時收到桌面通知。我開始了一個重構，
走開了，當它完成時我收到了通知。配置在執行緒中。
Plan Mode 是我對在重要程式碼上使用它感到放心的原因。按 Shift+Tab 直到你看到
「plan」；它準確列出它打算觸及的檔案，然後才改變任何東西。
成為人們會請教的人
一旦你分享了幾個例子，問題就會隨之而來。這正是冠軍發揮最大作用的地方，因為對一個人的好答案通常也能解開其他在同一頻道觀看的人的困惑。
用提示詞而不是解釋來回答
當同事問你是如何完成某件事時，最有用的回應是你實際使用的提示詞。他們從對自己的問題執行該提示詞中學到的東西，會比你寫的任何描述都要多，而且這給了他們可以立即採取行動的東西。
同事：你是怎麼讓它找到那個競態條件的？
冠軍：我問了，「@tests/scheduler.test.ts 中的測試不穩定，找出原因」，它追蹤到了排程器中兩個未連接的 Promise。試試在你的測試上用同樣的措辭。
指向功能而不是文件
像「試試 plan mode，按 Shift+Tab 直到你看到它」這樣的回應，在當下比文件的連結更有用。如果這個人稍後需要更深入的內容，他們會自己找到；現在他們需要的是解除他們困惑的那一件事。
你可能會聽到的問題
| 問題 | 建議的回應 | 後續資源 |
|---|---|---|
| 「我應該先在什麼上試試？」 | 推薦一個真實但範圍有限的任務，最好是這個人一直在推遲的錯誤或雜務，因為它很繁瑣而不是困難。 | 常見工作流程 |
| 「我怎樣才能相信它處理我的程式碼？」 | 介紹 plan mode：按 Shift+Tab 可以循環進入它，Claude 會精確提出它打算進行的更改，在使用者批准之前不會修改任何內容。 |
權限 |
| 「設定值得付出努力嗎？」 | 安裝大約需要兩分鐘，在終端機中執行，不需要 IDE 擴充功能。執行一次 /init 就足以開始工作。 |
快速開始 |
| 「它產生了不正確的結果。」 | 鼓勵他們將失敗反饋給 Claude。貼上錯誤訊息或失敗的測試遠比重新表述原始請求更有效。 | 常見工作流程 |
| 「它不理解我們的程式碼庫慣例。」 | 建議執行 /init 來生成 CLAUDE.md 檔案，然後添加團隊的慣例、測試命令和任何應該避免的目錄。 |
記憶 |
| 「這只是自動完成嗎？」 | 提供一個簡短的演示，其中 Claude 解釋一個陌生的檔案、追蹤跨服務的錯誤，或草擬遷移計畫。這些任務需要在整個儲存庫中進行推理，而不是完成單一行。 | 一個兩分鐘的現場演示 |
| 「安全性和資料處理呢？」 | 將此問題轉介給你的管理員。你的組織的部署和資料處理政策已經配置好了，冠軍不應該即興回答這個問題。 | 安全性 · 資料使用 |
擴大圈子
目標是建立少量輕量級習慣，以便即使你停止主動推動它，動力也能繼續。你不需要建立一個程式或擁有推出。當頻道中的問題被除你之外的人回答時，該角色已經完成了它的工作。
傾向於有效的模式
| 模式 | 如何運行它 | 所需努力 |
|---|---|---|
| 專用頻道 | 創建一個 #claude-code 頻道（或現有頻道中的定期討論串），釘選 Quickstart 連結和一個強大的例子，並公開回答問題，以便每個答案都使觀看的每個人受益。 |
大約五分鐘設置，然後環境 |
| 每週展示和講述討論串 | 每個星期五，發佈「Claude 本週幫助你做了什麼？」不需要準備、幻燈片或會議；截圖和簡短描述就足夠了。 | 每週約兩分鐘 |
| 分享自訂技能 | 發佈你最有用的 .claude/skills/<name>/SKILL.md 檔案，例如一個 /ship 技能，在提交前運行測試和 lint，帶有一行描述。因為技能是純 Markdown，同事可以立即採用它們。 |
每個技能約五分鐘 |
| 從你自己的使用生成設定指南 | 在你花費真實時間的專案中運行 /team-onboarding。Claude 掃描你最近的工作階段、命令和 MCP 伺服器，然後生成一個新隊友可以貼上為他們的第一條訊息以重放你的設定的指南。在頻道中釘選它。 |
約兩分鐘 |
| 配對第一個任務 | 為任何開始的人提供一個十五分鐘的配對工作階段。他們自己程式碼上的一個成功結果比任何簡報都更有說服力。 | 每人約十五分鐘 |
| 識別下一個倡導者 | 問你最多問題的同事通常已經準備好承擔這個角色。轉發他們這個頁面並在你之間分配頻道責任。 | 可忽略不計 |
三十天行動手冊
如果一個寬鬆的計劃有幫助，下面的序列反映了在大多數團隊中傾向於有效的東西。自由調整以適應你的背景。
第 2 週：開始節奏
開始每週展示和講述討論串，公開回答每個問題，並分享一個自訂技能或 CLAUDE.md 片段。
表明它有效的信號： 除你之外的人發佈他們自己的例子。
第 3 週：配對和整合
提供兩三個短配對工作階段，並將最常見的問題和答案整合到一個釘選的常見問題訊息中。
表明它有效的信號： 你看到重複使用，同樣的同事返回而不是嘗試一次然後停止。
第 4 週：交接
識別第二個倡導者，並與你的主管或管理員分享什麼有效和什麼無效的簡要總結。
表明它有效的信號： 頻道中的問題由除你之外的人回答。
當有人想深入時
你是溫暖的介紹而不是入職計劃。當同事從「我應該嘗試這個嗎」進入「我如何有效地使用它」時，指向他們 Quickstart 和 Common workflows 頁面。它們包含涵蓋真正有用但難以自己發現的功能的簡短部分。
回應常見疑慮
健康的懷疑是預期的；工程師應該對觸及他們代碼的工具保持謹慎。最有效的回應很少是論證一般情況。相反，承認疑慮，提供簡短的重新框架，並在該人自己的代碼上提議一個具體的演示。大多數疑慮通過單一成功的經驗得到解決。
| 疑慮 | 建議回應 | 提供的證據 |
|---|---|---|
| "我沒有它更快。" | 這對該人日常編寫的代碼可能是真的。建議在他們傾向於避免的工作上嘗試它：遺留文件、不熟悉的服務或測試腳手架，其中它幫助最多。 | 計時一個繁瑣的任務兩種方式並比較。 |
| "我不相信 AI 觸及生產代碼。" | 同意沒有更改應該在未閱讀的情況下登陸。Plan mode 結合正常的 diff 審查意味著沒有應用工程師未檢查的內容，與任何拉取請求相同的標準。 | 在真實文件上演示 plan mode。 |
| "它會使初級工程師變弱。" | 使用得當，它是一個有效的解釋者。鼓勵初級工程師在要求它更改任何內容之前要求 Claude 解釋一個文件及其調用站點。 | 一起運行"解釋 @file 及其被調用的位置"。 |
| "我嘗試過一次，它產生了幻覺。" | 這通常是上下文問題而不是模型問題。@-提及相關文件、運行 /init 和提供實際錯誤輸出通常會解決它。 |
用適當的 @ 上下文重新運行他們的原始提示。 |
| "我們沒有時間學習另一個工具。" | Claude Code 是一個終端命令而不是平台。如果它在第一個會話中不返回價值，設置它是合理的。 | 兩分鐘安裝後跟一個真實錯誤。 |
快速參考表
下面的技巧是最能可靠地幫助使用者從首次試用轉變為日常使用的方法。將此表格釘在頻道中或單獨分享。
| 技巧 | 如何應用 |
|---|---|
| 提供正確的背景資訊 | 使用 @file 或 @directory/ 參考，或直接貼上錯誤或日誌輸出。提供相關的背景資訊比精心設計的提示更有效。 |
| 在編輯前檢查計畫 | 按 Shift+Tab 進入 Plan Mode。Claude 會在執行前描述預期的變更以供您批准。 |
| 教導它您的儲存庫 | 執行 /init 以產生 CLAUDE.md 檔案，然後新增您的慣例、測試命令和任何不應修改的目錄。請參閱 Memory。 |
| 重複使用工作流程 | 在 .claude/skills/<name>/ 中儲存 SKILL.md 檔案以建立整個團隊可以使用的 /name skill。請參閱 Skills。 |
| 在長時間任務期間保持知情 | 設定 Stop hook 以在長時間執行的任務完成時收到桌面通知。請參閱 Hooks。 |
| 從不正確的結果中恢復 | 與其重新表述請求，不如將失敗的測試或堆疊追蹤貼回給 Claude，並要求它解決該特定失敗。 |
| 保持編輯精確 | 要求差異，或指定「僅變更 X」。當明確陳述範圍時，Claude 會尊重範圍。 |