新开发者工具的采用很少仅因为推出公告就发生。它发生在团队中有人开始很好地使用该工具、公开谈论它，并使其他人容易跟随的时候。这个工具包旨在支持这种努力，而不会将其变成第二份工作。它为您可能已经在做的事情赋予形状，并提供您可以直接交给同事的材料。
您作为冠军所做的工作具有不成比例的影响。您分享的每个示例都缩短了后来工程师的学习曲线，您在公开场合回答的每个问题都将一个人的经验转变为整个团队可以建立的东西。您是团队的倍增器，而不是帮助台，本指南的结构是为了在这些条件下保持该角色的可持续性。
如何使用本指南
冠军角色由三种相互强化的行为组成：分享您的发现、成为人们提问的对象，以及扩大活跃用户的圈子。下面的部分依次涵盖每一个，然后是三十天的行动手册、对常见问题的回应指导，以及您可以交给任何人的快速参考表。
使用适合您团队的任何内容，并搁置不适合的内容。这里没有任何东西是您应该完成的清单；它是在许多工程组织中行之有效的一套模式。
第 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 验证版本特定的详细信息。