文档索引

在此获取完整文档索引：https://code.claude.com/docs/llms.txt 使用此文件发现所有可用页面，然后再进一步探索。

推荐人工具包

工程师在内部推广 Claude Code 的行动手册：分享什么、如何回答问题、如何在团队中推动采用。

本页面面向已经在使用 Claude Code 并希望帮助团队采用它的工程师。它涵盖了分享什么、如何回答您将收到的问题、三十天行动计划以及对常见顾虑的回应。

开发工具的采用很少因为推出通知而发生。它发生是因为团队中的某人开始很好地使用该工具，公开谈论它，并使其他人容易跟进。您作为推荐人所做的工作具有不成比例的影响：您分享的每个示例都缩短了后来工程师的学习曲线，您公开回答的每个问题都将一个人的经验转化为整个团队可以利用的东西。您是团队的倍增器，而不是帮助台，本指南的结构旨在使该角色在这些条款上保持可持续。

推荐人角色

该角色由三种相互强化的行为组成。

这些大部分都自然地融入您已经在做的工作中。区别在于对您的发现发布在哪里以及您的答案如何传播有少量额外的意图。

这应该花费您多少

对自己和您的主管设定期望。以下活动旨在适应正常的工作周，该角色应该仍然是您现有工作的倍增器，而不是额外的支持责任。

分享您的发现

您自己的经验是您的同事将遇到的最有说服力的材料，因为它特定于您所有人都共享的代码库、工作流和问题。文档告诉人们什么是可能的；您的帖子向他们展示在您的环境中实际有效的内容。

什么值得分享

最有用的帖子描述同事明天可以重用的技术，而不是已经完成的结果。技术随着在团队中传播而复合；状态更新不会。

可重用技术的示例：

• "我了解到 @-mentioning 目录有效。将其指向 @src/components/ 并询问哪些缺少测试，发现了两个我忽略的。"
• "计划模式 (Shift+Tab) 在进行任何编辑之前准确显示将触及哪些文件，这就是为什么我放心在共享代码上使用它。"
• "我配置了一个 Stop 钩子，以便在长时间任务完成时收到桌面通知。配置在线程中。"
• "运行 /init 从仓库生成 CLAUDE.md，这样助手就不再重复询问我们的约定。"

在哪里分享

在您的团队已经阅读的任何地方发布。目标是将示例放在正常工作的路径中，而不是创建目的地。

有效的格式

配有一行上下文的截图，或简短的前后描述，通常是正确的详细程度。保持每个帖子足够短，以便滚动经过的人仍然能吸收要点。长篇书面报告倾向于被保存稍后阅读然后遗忘，而配有截图的短帖子倾向于被复制和尝试。

下面的示例帖子说明了语气和长度；请改编而不是逐字复制。

Learned today that @-mentioning a directory works. I pointed it at
@src/components/ and asked which components were missing tests, and it
surfaced two I had forgotten about.

I configured a Stop hook so I receive a desktop notification when a long
task completes. I started a refactor, stepped away, and was notified when
it finished. Configuration is in the thread.

Plan mode is the reason I am comfortable using this on code that matters.
Press Shift+Tab until you see "plan"; it lays out exactly which files it
intends to touch before changing anything.

成为人们询问的人

一旦您分享了一些示例，问题就会随之而来。这是推荐人角色具有最大杠杆作用的地方，因为对一个人的好答案经常解除正在观看同一频道的其他几个人的阻塞。

用提示而不是解释来回答

当同事问您如何完成某事时，最有用的回应是您实际使用的提示。他们通过在自己的问题上运行该提示学到的比您能写的任何描述都多，并且它给了他们可以立即行动的东西。

Colleague: How did you get it to find that race condition?

Champion: I asked, "The test in @tests/scheduler.test.ts is flaky, figure
out why," and it traced two unjoined promises in the scheduler. Try the
same phrasing on your test.

指向功能而不是文档

像"试试计划模式，按 Shift+Tab 直到看到它"这样的回应在当下比文档链接更有用。如果该人稍后需要更多深度，他们会自己找到；现在他们需要解除阻塞的那个东西。

您可能会听到的问题

扩大圈子

目标不是建立一个项目或拥有一个推出。而是建立少量轻量级的习惯，使势头在您停止积极推动后能够继续。当频道中的问题正在由您以外的人回答时，该角色就完成了它的工作。

倾向有效的模式

三十天行动计划

如果一个宽松的计划有帮助，下面的序列反映了在大多数团队中有效的方法。根据您的上下文自由调整。

1. 第 1 周：播种频道

   创建频道，置顶快速入门，并发布两三个您自己的示例，附带提示。

   **有效的信号：**几个同事做出反应或回复，频道中至少有一个问题被提出。

2. 第 2 周：建立节奏

   启动每周展示和讲述线程，公开回答每个问题，并分享一个自定义技能或 CLAUDE.md 片段。

   **有效的信号：**除了您之外的人发布了他们自己的示例。

3. 第 3 周：配对和巩固

   提供两三个简短的配对会话，并将最常见的问题和答案整合到置顶的 FAQ 消息中。

   **有效的信号：**您看到重复使用，相同的同事返回而不是尝试一次就停止。

4. 第 4 周：移交

   识别第二个推荐人，并与您的主管或管理员分享简要总结什么有效、什么无效。

   **有效的信号：**频道中的问题正在由您以外的人回答。

当有人想要深入时

您是热情的介绍而不是入门计划。当同事从"我应该试试这个"转向"我如何变得有效"时，请将他们指向快速入门和常见工作流页面。它们包含涵盖真正有用但难以自行发现的功能的简短部分。

回应常见顾虑

健康的怀疑态度是预期的；工程师应该对涉及其代码的工具持谨慎态度。最有效的回应很少是争论一般情况。相反，承认顾虑，提供简短的重新定义，并提议在该人自己的代码上进行一次具体的演示。大多数顾虑通过一次成功的经验就能解决。

快速参考表

以下技术是最可靠地将某人从首次试用带到日常使用的技术。将此表置顶在频道中或单独分享。