> ## 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 分鐘 | 為真正被卡住的同事保留此項，並在安排時間之前提供 [Quickstart](/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` 或一般工程頻道 | 發現、提示和"今天我學到"的時刻            | 一個截圖伴隨一兩句上下文                     |
| 拉取請求描述                 | 在審查者已經閱讀的真實代碼上演示該方法         | 一行，例如"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 中的測試不穩定，找出原因，"
它追蹤了調度程序中的兩個未加入的承諾。在你的測試上嘗試相同的措辭。
```

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

"嘗試 plan mode，按 `Shift+Tab` 直到你看到它"這樣的回應在當時比文檔連結更有用。如果該人稍後需要更多深度，他們會自己找到；現在他們需要解除困境的單一事物。

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

| 問題              | 建議回應                                                                    | 後續資源                                                          |
| --------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------- |
| "我應該首先在什麼上嘗試它？" | 推薦一個真實但有限的任務，理想情況下是一個你一直推遲的錯誤或雜務，因為它很繁瑣而不是困難。                           | [Common workflows](/docs/zh-TW/common-workflows)                   |
| "我如何相信它處理我的代碼？" | 介紹 plan mode：按 `Shift+Tab` 循環進入它，Claude 精確提議它打算更改什麼，在用戶批准之前不修改任何內容。     | [Permissions](/docs/zh-TW/permissions)                             |
| "設置值得付出努力嗎？"    | 安裝大約需要兩分鐘，在終端中運行，不需要 IDE 擴展。運行一次 `/init` 足以開始工作。                        | [Quickstart](/docs/zh-TW/quickstart)                               |
| "它產生了不正確的結果。"   | 鼓勵他們將失敗提供回 Claude。粘貼錯誤消息或失敗的測試遠比重新表述原始請求更有效。                            | [Common workflows](/docs/zh-TW/common-workflows)                   |
| "它不理解我們的代碼庫約定。" | 建議運行 `/init` 生成 `CLAUDE.md` 文件，然後添加團隊的約定、測試命令和任何應避免的目錄。                 | [Memory](/docs/zh-TW/memory)                                       |
| "這只是自動完成嗎？"     | 提供一個簡短的演示，其中 Claude 解釋一個不熟悉的文件、跨服務追蹤錯誤或起草遷移計劃。這些任務需要在存儲庫中進行推理，而不是完成單一行。 | 一個兩分鐘的現場演示                                                    |
| "安全和數據處理呢？"     | 將此問題轉介給你的管理員。你的組織的部署和數據處理政策已經配置，倡導者不應該即興回答此問題。                          | [Security](/docs/zh-TW/security) · [Data usage](/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 結合正常的 diff 審查意味著沒有應用工程師未檢查的內容，與任何拉取請求相同的標準。 | 在真實文件上演示 plan mode。      |
| "它會使初級工程師變弱。"     | 使用得當，它是一個有效的解釋者。鼓勵初級工程師在要求它更改任何內容之前要求 Claude 解釋一個文件及其調用站點。               | 一起運行"解釋 @file 及其被調用的位置"。 |
| "我嘗試過一次，它產生了幻覺。"  | 這通常是上下文問題而不是模型問題。@-提及相關文件、運行 `/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` 技能。見 [Skills](/docs/zh-TW/skills)。 |
| 在長任務期間保持知情 | 配置一個 Stop hook 以在長時間運行的任務完成時收到桌面通知。見 [Hooks](/docs/zh-TW/hooks-guide)。                              |
| 從不正確的結果恢復  | 與其重新表述請求，不如將失敗的測試或堆棧跟蹤粘貼回 Claude，並要求它解決該特定失敗。                                                  |
| 保持編輯精確     | 要求一個 diff，或指定「只更改 X」。Claude 在陳述範圍時尊重範圍。                                                        |

<Tip>
  Claude Code 經常更新。在內部分發此材料之前，根據 [documentation home page](/docs/zh-TW/overview) 驗證版本特定的詳細信息。
</Tip>