> ## Documentation Index
> Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Champion kit

> 工程師在內部倡導 Claude Code 的行動手冊：分享什麼、如何回答問題，以及如何在團隊中推動採用。

本頁面適用於已經在使用 Claude Code 並想幫助團隊採用它的個別工程師。它涵蓋了要分享什麼、如何回答你將收到的問題、三十天行動手冊，以及對常見疑慮的回應。

開發者工具的採用很少是因為推出公告而發生的。它發生在團隊中有人開始很好地使用該工具、公開談論它，並使其他人容易跟進的時候。你作為倡導者所做的工作對團隊有不成比例的影響：你分享的每個例子都會縮短後來工程師的學習曲線，你在公開場合回答的每個問題都會將一個人的經驗轉變為整個團隊可以建立的東西。

<h2 id="the-champion-role">
  倡導者角色
</h2>

該角色包含三種相互強化的行為。

| 行為 | 實際運作情況 | 為什麼重要 |
| - | - | - |
| 分享你的發現 | 在你的團隊已經閱讀的地方發佈提示詞、螢幕截圖和小成就，例如工程頻道、站立會議討論串或拉取請求描述。 | 從你自己的程式碼庫中提取的範例比任何外部文件更具說服力，因為同事可以看到該工具如何確切地應用於他們與你共享的問題。 |
| 成為人們詢問的對象 | 當同事詢問你如何完成某項工作時，用你實際使用的提示詞回應，以便他們可以直接將其應用於自己的任務。 | 一個具體、可運行的範例消除了好奇心和首次成功使用之間的差距，這正是大多數採用工作停滯的地方。 |
| 擴大圈子 | 建立少量輕量級的定期習慣，例如專用頻道或每週討論串，以便即使你的注意力轉移到其他地方，動力也能繼續。 | 依賴單一人員的採用是脆弱的。由共享習慣推動的採用會自動持續複合增長。 |

<h3 id="what-this-should-cost-you">
  這應該花費你多少時間
</h3>

與自己和你的主管設定期望。下面的活動旨在適應正常的工作週，該角色應該是對你現有工作的乘數效應，而不是額外的支持責任。

| 活動 | 每週時間 | 指導 |
| - | - | - |
| 發佈成就和提示詞 | 約 15 分鐘 | 用螢幕截圖和一兩句話在當下捕捉這些內容；避免將其轉變為正式的寫作。 |
| 在共享頻道中回答問題 | 約 20 分鐘 | 公開回答一次，然後當問題再次出現時連結回該答案。 |
| 主持每週展示和講述討論串 | 約 5 分鐘 | 你發佈開場提示詞；團隊提供內容。 |
| 可選的配對或逐步講解 | 0 到 30 分鐘 | 將此保留給被阻擋的同事，並在安排時間之前提供 [快速入門](/docs/zh-TW/quickstart) 連結。 |

<h2 id="share-what-you-discover">
  分享你的發現
</h2>

你自己的經驗是同事會遇到的最有說服力的材料，因為它特定於你們共同使用的程式碼庫、工作流程和問題。文件告訴人們什麼是可能的；你的貼文向他們展示在你的環境中實際上什麼是有效的。

<h3 id="what-is-worth-sharing">
  什麼值得分享
</h3>

最有用的貼文描述的是同事明天就能重複使用的技術，而不是已經完成的結果。技術在團隊中傳播時會複合增長；狀態更新則不會。

可重複使用的技術範例：

* "我發現 @-提及一個目錄是有效的。我將其指向 `@src/components/`，並詢問哪些缺少測試，這暴露了我忽略的兩個。"
* "plan mode（`Shift+Tab`）會先列出建議的變更，這就是為什麼我對在共享程式碼上使用它感到放心。"
* "我配置了一個 Stop hook，以便在長任務完成時收到桌面通知。配置在執行緒中。"
* "執行 `/init` 會從儲存庫生成一個 `CLAUDE.md`，所以助手停止重複詢問我們的約定。"

<h3 id="where-to-share-it">
  在哪裡分享
</h3>

在你的團隊已經閱讀的地方發佈。目標是將範例放在正常工作的路徑中，而不是創建一個目的地。

| 位置 | 最適合用於 | 建議格式 |
| - | - | - |
| `#claude-code` 或一般工程頻道 | 發現、提示和「今天我學到」的時刻 | 一張螢幕截圖，附帶一或兩句背景說明 |
| Pull Request 描述 | 在審查者已經閱讀的真實程式碼上演示該方法 | 單一行，例如「Claude 和我進行了這個重構；很樂意講解該方法。」 |
| 站會或每週書面更新 | 與主管和跳級經理規範化使用 | 一句話描述一個具體的結果 |
| 團隊 wiki 或內部文件 | 持久的模式、自訂技能和 `CLAUDE.md` 範例 | 一個簡短的頁面，從頻道主題連結，以便保持可發現性 |

<h3 id="the-format-that-works">
  有效的格式
</h3>

一張螢幕截圖附帶單一行背景說明，或簡短的前後對比描述，通常是正確的細節層級。保持每個貼文簡短，使得瀏覽過的人仍然能吸收要點。冗長的文章往往會被保存以供稍後閱讀並被遺忘，而帶有螢幕截圖的簡短貼文往往會被複製和嘗試。

下面的範例貼文說明了語氣和長度；改編它們而不是逐字複製。

```text theme={null}
今天學到 @-提及一個目錄是有效的。我將其指向 @src/components/，並詢問哪些
元件缺少測試，它暴露了我忘記的兩個。
```

```text theme={null}
我配置了一個 Stop hook，以便在長任務完成時收到桌面通知。我開始了一個重構，
走開了，當它完成時我收到了通知。配置在執行緒中。
```

```text theme={null}
plan mode 是我對在重要程式碼上使用它感到放心的原因。按 Shift+Tab 直到您看到
「plan」；它會列出它建議的變更，而不會編輯您的原始碼。
```

<h2 id="be-the-person-people-ask">
  成為人們會請教的人
</h2>

一旦你分享了幾個例子，問題就會隨之而來。這正是冠軍發揮最大作用的地方，因為對一個人的好答案通常也能解開其他在同一頻道觀看的人的困惑。

<h3 id="answer-with-a-prompt-rather-than-an-explanation">
  用提示詞而不是解釋來回答
</h3>

當同事問你是如何完成某件事時，最有用的回應是你實際使用的提示詞。他們從對自己的問題執行該提示詞中學到的東西，會比你寫的任何描述都要多，而且這給了他們可以立即採取行動的東西。

```text theme={null}
同事：你是怎麼讓它找到那個競態條件的？

冠軍：我問了，「@tests/scheduler.test.ts 中的測試不穩定，找出原因」，它追蹤到了排程器中兩個未連接的 Promise。試試在你的測試上用同樣的措辭。
```

<h3 id="point-at-the-feature-rather-than-the-documentation">
  指向功能而不是文件
</h3>

像「試試 plan mode，按 `Shift+Tab` 直到你看到它」這樣的回應，在當下比文件的連結更有用。如果這個人稍後需要更深入的內容，他們會自己找到；現在他們需要的是解除他們困惑的那一件事。

<h3 id="questions-you-are-likely-to-hear">
  你可能會聽到的問題
</h3>

| 問題 | 建議的回應 | 後續資源 |
| - | - | - |
| 「我應該先在什麼上試試？」 | 推薦一個真實但範圍有限的任務，最好是這個人一直在推遲的錯誤或雜務，因為它很繁瑣而不是困難。 | [常見工作流程](/docs/zh-TW/common-workflows) |
| 「我怎樣才能相信它處理我的程式碼？」 | 介紹 plan mode：按 `Shift+Tab` 可以循環進入它，Claude 會進行研究並提出變更，而不會編輯您的原始碼。 | [權限](/docs/zh-TW/permissions) |
| 「設定值得付出努力嗎？」 | 安裝大約需要兩分鐘，在終端機中執行，不需要 IDE 擴充功能。執行一次 `/init` 就足以開始工作。 | [快速開始](/docs/zh-TW/quickstart) |
| 「它產生了不正確的結果。」 | 鼓勵他們將失敗反饋給 Claude。貼上錯誤訊息或失敗的測試遠比重新表述原始請求更有效。 | [常見工作流程](/docs/zh-TW/common-workflows) |
| 「它不理解我們的程式碼庫慣例。」 | 建議執行 `/init` 來生成 `CLAUDE.md` 檔案，然後添加團隊的慣例、測試命令和任何應該避免的目錄。 | [記憶](/docs/zh-TW/memory) |
| 「這只是自動完成嗎？」 | 提供一個簡短的演示，其中 Claude 解釋一個陌生的檔案、追蹤跨服務的錯誤，或草擬遷移計畫。這些任務需要在整個儲存庫中進行推理，而不是完成單一行。 | 一個兩分鐘的現場演示 |
| 「安全性和資料處理呢？」 | 將此問題轉介給你的管理員。你的組織的部署和資料處理政策已經配置好了，冠軍不應該即興回答這個問題。 | [安全性](/docs/zh-TW/security) · [資料使用](/docs/zh-TW/data-usage) |

<h2 id="grow-the-circle">
  擴大圈子
</h2>

目標是建立少量輕量級習慣，以便即使你停止主動推動它，動力也能繼續。你不需要建立一個程式或擁有推出。當頻道中的問題被除你之外的人回答時，該角色已經完成了它的工作。

<h3 id="patterns-that-tend-to-work">
  傾向於有效的模式
</h3>

| 模式 | 如何運行它 | 所需努力 |
| - | - | - |
| 專用頻道 | 創建一個 `#claude-code` 頻道（或現有頻道中的定期討論串），釘選 [Quickstart](/docs/zh-TW/quickstart) 連結和一個強大的例子，並公開回答問題，以便每個答案都使觀看的每個人受益。 | 大約五分鐘設置，然後環境 |
| 每週展示和講述討論串 | 每個星期五，發佈「Claude 本週幫助你做了什麼？」不需要準備、幻燈片或會議；截圖和簡短描述就足夠了。 | 每週約兩分鐘 |
| 分享自訂技能 | 發佈你最有用的 `.claude/skills/<name>/SKILL.md` 檔案，例如一個 `/ship` 技能，在提交前運行測試和 lint，帶有一行描述。因為技能是純 Markdown，同事可以立即採用它們。 | 每個技能約五分鐘 |
| 從你自己的使用生成設定指南 | 在你花費真實時間的專案中運行 `/team-onboarding`。Claude 掃描你最近的工作階段、命令和 MCP 伺服器，然後生成一個新隊友可以貼上為他們的第一條訊息以重放你的設定的指南。在頻道中釘選它。 | 約兩分鐘 |
| 配對第一個任務 | 為任何開始的人提供一個十五分鐘的配對工作階段。他們自己程式碼上的一個成功結果比任何簡報都更有說服力。 | 每人約十五分鐘 |
| 識別下一個倡導者 | 問你最多問題的同事通常已經準備好承擔這個角色。轉發他們這個頁面並在你之間分配頻道責任。 | 可忽略不計 |

<h3 id="thirty-day-playbook">
  三十天行動手冊
</h3>

如果一個寬鬆的計劃有幫助，下面的序列反映了在大多數團隊中傾向於有效的東西。自由調整以適應你的背景。

<Steps>
  <Step title="第 1 週：播種頻道">
    創建頻道，釘選 [Quickstart](/docs/zh-TW/quickstart)，並發佈兩三個你自己的例子，包括提示。

    **表明它有效的信號：** 幾個同事做出反應或回覆，至少在頻道中提出一個問題。
  </Step>

  <Step title="第 2 週：開始節奏">
    開始每週展示和講述討論串，公開回答每個問題，並分享一個自訂技能或 `CLAUDE.md` 片段。

    **表明它有效的信號：** 除你之外的人發佈他們自己的例子。
  </Step>

  <Step title="第 3 週：配對和整合">
    提供兩三個短配對工作階段，並將最常見的問題和答案整合到一個釘選的常見問題訊息中。

    **表明它有效的信號：** 你看到重複使用，同樣的同事返回而不是嘗試一次然後停止。
  </Step>

  <Step title="第 4 週：交接">
    識別第二個倡導者，並與你的主管或管理員分享什麼有效和什麼無效的簡要總結。

    **表明它有效的信號：** 頻道中的問題由除你之外的人回答。
  </Step>
</Steps>

<h3 id="when-someone-wants-to-go-deeper">
  當有人想深入時
</h3>

你是溫暖的介紹而不是入職計劃。當同事從「我應該嘗試這個嗎」進入「我如何有效地使用它」時，指向他們 [Quickstart](/docs/zh-TW/quickstart) 和 [Common workflows](/docs/zh-TW/common-workflows) 頁面。它們包含涵蓋真正有用但難以自己發現的功能的簡短部分。

<h2 id="respond-to-common-concerns">
  回應常見疑慮
</h2>

抱持合理的懷疑是正常的；工程師對於會接觸其程式碼的工具理應保持謹慎。最有效的回應方式很少是泛泛地爭論整體情況。相反地，應先認同對方的疑慮，提供簡短的換個角度思考，並提議在對方自己的程式碼上進行一次具體示範。大多數疑慮只需一次成功的經驗即可化解。

| 疑慮 | 建議回應 | 可提供的證據 |
| - | - | - |
| 「不用它我反而更快。」 | 對於對方日常撰寫的程式碼而言，這很可能是事實。建議在他們傾向逃避的工作上試用：舊有檔案、不熟悉的服務或測試框架程式碼，這些正是它最能發揮作用之處。 | 以兩種方式各完成一項繁瑣任務並計時比較。 |
| 「我不信任 AI 修改正式環境的程式碼。」 | 同意任何變更都不應在未經審閱的情況下合併。建議使用 plan mode 先查看提議的變更，然後以審閱任何 pull request 的相同標準來審閱差異。 | 在真實檔案上示範 plan mode。 |
| 「它會讓初階工程師變弱。」 | 善加運用的話，它是很有效的解說工具。鼓勵初階工程師在要求 Claude 修改任何內容之前，先請它解說某個檔案及其呼叫位置。 | 一起執行「Explain @file and where it is called from」。 |
| 「我試過一次，它產生了幻覺。」 | 這通常是上下文的問題，而非模型的問題。以 @ 提及相關檔案、執行 `/init`，並提供實際的錯誤輸出，通常即可解決。 | 以適當的 `@` 上下文重新執行他們原本的提示詞。 |
| 「我們沒有時間學習另一個工具。」 | Claude Code 是一個終端機命令，而非一個平台。如果在第一個工作階段內沒有帶來價值，將它擱置一旁也是合理的。 | 兩分鐘完成安裝，接著處理一個真實的錯誤。 |

<h2 id="quick-reference-sheet">
  快速參考表
</h2>

下面的技巧是最能可靠地幫助使用者從首次試用轉變為日常使用的方法。將此表格釘在頻道中或單獨分享。

| 技巧 | 如何應用 |
| - | - |
| 提供正確的背景資訊 | 使用 `@file` 或 `@directory/` 參考，或直接貼上錯誤或日誌輸出。提供相關的背景資訊比精心設計的提示更有效。 |
| 在編輯前檢查計畫 | 按 `Shift+Tab` 進入 plan mode。Claude 會進行研究並提出變更建議，而不會編輯您的原始碼。 |
| 教導它您的儲存庫 | 執行 `/init` 以產生 `CLAUDE.md` 檔案，然後新增您的慣例、測試命令和任何不應修改的目錄。請參閱 [Memory](/docs/zh-TW/memory)。 |
| 重複使用工作流程 | 在 `.claude/skills/<name>/` 中儲存 `SKILL.md` 檔案以建立整個團隊可以使用的 `/name` skill。請參閱 [Skills](/docs/zh-TW/skills)。 |
| 在長時間任務期間保持知情 | 設定 Stop hook 以在長時間執行的任務完成時收到桌面通知。請參閱 [Hooks](/docs/zh-TW/hooks-guide)。 |
| 從不正確的結果中恢復 | 與其重新表述請求，不如將失敗的測試或堆疊追蹤貼回給 Claude，並要求它解決該特定失敗。 |
| 保持編輯精確 | 要求差異，或指定「僅變更 X」。當明確陳述範圍時，Claude 會尊重範圍。 |

<Tip>
  Claude Code 會頻繁更新。在內部分發此資料前，請根據 [文件首頁](/docs/zh-TW/overview) 驗證版本特定的詳細資訊。
</Tip>