新开发者工具的采用很少仅因为推出公告就发生。它发生在团队中有人开始很好地使用该工具、公开谈论它，并使他人容易跟随的时候。这个工具包旨在支持这种努力，而不会让它变成第二份工作。它为你可能已经在做的事情赋予形状，并提供你可以直接交给同事的材料。
你作为冠军所做的工作具有不成比例的影响。你分享的每个例子都缩短了后来工程师的学习曲线，你在公开场合回答的每个问题都将一个人的经验转化为整个团队可以建立的东西。你是团队的倍增器，而不是帮助台，这份指南的结构是为了在这些条件下保持角色的可持续性。
如何使用本指南
冠军角色由三种相互强化的行为组成：分享你的发现、成为人们提问的对象，以及扩大活跃用户的圈子。下面的部分依次涵盖每一个，然后是一个三十天的行动计划、对常见问题的回应指导，以及一个快速参考表，你可以交给任何人。
使用适合你团队的任何东西，放弃不适合的。这里没有什么是你应该完成的清单；它是一套在许多工程组织中行之有效的模式。
第 1 阶段：冠军角色
冠军做什么
行为 | 在实践中的样子 | 为什么重要 |
分享你的发现 | 在你的团队已经阅读的地方发布提示、截图和小胜利，例如工程频道、站立线程或拉取请求描述。 | 从你自己的代码库中提取的例子比任何外部文档都更有说服力，因为同事可以看到该工具如何准确地适用于你们共享的问题。 |
成为人们提问的对象 | 当同事问你如何完成某事时，用你使用的实际提示来回应，这样他们就可以直接将其应用到自己的任务中。 | 一个具体的、可运行的例子消除了好奇心和第一次成功使用之间的差距，这是大多数采用努力停滞的地方。 |
扩大圈子 | 建立少量轻量级的、定期的习惯——例如专用频道或每周线程——这样即使你的注意力在别处，势头也会继续。 | 依赖单个人的采用是脆弱的。由共享习惯进行的采用会继续自行复合。 |
大部分内容自然地适应你已经在做的工作。区别在于对你的发现发布位置和你的答案如何传播的少量额外意图。
为什么这很重要
当受信任的人证明工具值得付出努力时，工具就会在组织内传播。文档可以描述什么是可能的，但来自同事的例子——来自相同的代码库、相同的工作流程和相同的约束——才是让人们从好奇心转向第一次尝试的原因。通过使你自己的经验可见，你消除了采用停滞的最常见原因：不知道从哪里开始。
这应该花费你多少
值得与自己和你的主管设定期望。下面的活动旨在适应正常的工作周，该角色应该保持为现有工作的倍增器，而不是额外的支持责任。
活动 | 每周时间 | 指导 |
发布胜利和提示 | 大约 15 分钟 | 用截图和一两句话在当时捕捉这些；避免将它们变成正式的写作。 |
在共享频道中回答问题 | 大约 20 分钟 | 公开回答一次，然后当问题再次出现时链接回该答案。 |
主持每周展示和讲述线程 | 大约 5 分钟 | 你发布开场提示；团队提供内容。 |
可选配对或演练 | 0–30 分钟 | 将此保留给真正被阻止的同事，并在安排时间之前提供 快速入门 链接。 |
第 2 阶段：分享你的发现
你自己的经验是你的同事会遇到的最有说服力的材料，因为它特定于你们都共享的代码库、工作流程和问题。文档告诉人们什么是可能的；你的帖子向他们展示在你的环境中实际有效的东西。
值得分享的内容
最有用的帖子描述了同事明天可以重用的技术，而不是已经完成的结果。技术在团队中传播时会复合；状态更新不会。
值得分享（同事可以重用的技术） | 不太有用（状态更新） |
我了解到 @-提及目录有效——将其指向 | 我用 Claude 迁移了支付服务。 |
计划模式（Shift+Tab）准确显示在进行任何编辑之前将触及哪些文件，这就是为什么我对在共享代码上使用它感到满意。 | Claude 在这个冲刺中为我节省了很多时间。 |
我配置了一个 Stop 钩子，以便在长任务完成时收到桌面通知；配置在线程中。 | 我这周关闭了八张工单。 |
运行 | Claude 真的很不错；你应该试试。 |
在哪里分享
在你的团队已经阅读的地方发布。目标是在日常工作中放置示例，而不是创建新的目的地。
位置 | 最适合 | 推荐格式 |
一个 | 发现、提示和"今日所学"时刻 | 一张截图加上一两句背景说明 |
拉取请求描述 | 在审阅者已经阅读的真实代码上演示该方法 | 一句话，例如"Claude 和我做了这个重构；很乐意讲解这个方法。" |
站会或每周书面更新 | 与主管和跳级经理规范化使用 | 一句话描述一个具体的成果 |
团队 wiki 或内部文档 | 持久的模式、自定义技能和 | 一个简短的页面，从频道主题链接，以便保持可发现性 |
有效的格式
一张截图加上一行背景说明，或简短的前后对比描述，通常是恰当的细节级别。保持每篇文章足够简短，以便浏览的人仍能理解要点。冗长的文章往往被保存以供稍后阅读而被遗忘，而带有截图的简短文章往往被复制和尝试。
示例文章
以下是语气和长度的说明，而不是逐字复制的模板。
今天了解到 @-提及目录有效。我将其指向 @src/components/ 并询问哪些组件缺少测试，它找出了两个我遗忘的。
我配置了一个 Stop 钩子，以便在长任务完成时收到桌面通知。我开始了一个重构，走开了，任务完成时收到了通知。配置在线程中。
Plan 模式是我能够放心在重要代码上使用它的原因。按 Shift+Tab 直到看到"plan"；它准确列出了它打算修改的文件，然后才进行任何更改。
第 3 阶段：成为人们会请教的人
一旦你分享了几个示例，问题就会随之而来。这是冠军角色杠杆作用最大的地方，因为对一个人的好答案经常会为其他在同一频道观看的人解除阻碍。
用提示而不是解释来回答
当同事问你是如何完成某事时，最有用的回应是你实际使用的提示。他们从针对自己的问题运行该提示中学到的东西比你能写的任何描述都多，这给了他们可以立即采取行动的东西。
同事： 你是怎样找到那个竞态条件的？
冠军： 我问道，"@tests/scheduler.test.ts 中的测试不稳定——找出原因，"它追踪了调度程序中两个未联接的 promise。在你的测试上尝试相同的措辞。
指向功能而不是文档
诸如"尝试 plan 模式——按 Shift+Tab 直到看到它"这样的回应在当下比文档链接更有用。如果此人稍后需要更深入的内容，他们会自己找到；现在他们需要解除阻碍的单一事物。
你可能会听到的问题
下表涵盖了冠军最常被问到的问题，以及建议的回应和当此人准备好更深入内容时提供的资源。
你可能会听到的问题 | 建议的回应 | 后续资源 |
我应该首先在什么上尝试？ | 推荐一个真实但有限的任务——最好是一个人一直在推迟的错误或琐事，因为它很繁琐而不是困难。 | |
我如何相信它处理我的代码？ | 介绍 plan 模式：按 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 验证版本特定的详细信息。