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