{/* TRANSLATED — 已翻译为中文 */} > ## 文档索引 > 在此获取完整文档索引：https://code.claude.com/docs/llms.txt > 使用此文件发现所有可用页面，然后再进一步探索。 # 推荐人工具包 > 工程师在内部推广 Claude Code 的行动手册：分享什么、如何回答问题、如何在团队中推动采用。 本页面面向已经在使用 Claude Code 并希望帮助团队采用它的工程师。它涵盖了分享什么、如何回答您将收到的问题、三十天行动计划以及对常见顾虑的回应。 开发工具的采用很少因为推出通知而发生。它发生是因为团队中的某人开始很好地使用该工具，公开谈论它，并使其他人容易跟进。您作为推荐人所做的工作具有不成比例的影响：您分享的每个示例都缩短了后来工程师的学习曲线，您公开回答的每个问题都将一个人的经验转化为整个团队可以利用的东西。您是团队的倍增器，而不是帮助台，本指南的结构旨在使该角色在这些条款上保持可持续。 ## 推荐人角色 该角色由三种相互强化的行为组成。 | 行为 | 实践中的表现 | 重要性 | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 分享您的发现 | 在您的团队已经阅读的地方（如工程频道、站会线程或拉取请求描述）发布来自您自己工作的提示、截图和小胜利。 | 来自您自己代码库的示例比任何外部文档都更有说服力，因为同事可以确切看到工具如何应用于他们与您共享的问题。 | | 成为人们询问的人 | 当同事问您如何完成某事时，回应您实际使用的提示，以便他们可以直接应用到自己的任务中。 | 具体的、可运行的示例消除了好奇心和首次成功使用之间的差距，这是大多数采用工作停滞的地方。 | | 扩大圈子 | 建立少量轻量级的、重复的习惯，如专用频道或每周线程，以便即使您的注意力在别处时势头也能继续。 | 依赖于一个人的采用是脆弱的。由共享习惯承载的采用会自行持续增长。 | 这些大部分都自然地融入您已经在做的工作中。区别在于对您的发现发布在哪里以及您的答案如何传播有少量额外的意图。 ### 这应该花费您多少 对自己和您的主管设定期望。以下活动旨在适应正常的工作周，该角色应该仍然是您现有工作的倍增器，而不是额外的支持责任。 | 活动 | 每周时间 | 指导 | | --------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------ | | 发布胜利和提示 | 约 15 分钟 | 在当下用截图和一两句话捕捉这些；避免将它们变成正式的书面报告。 | | 在共享频道回答问题 | 约 20 分钟 | 公开回答一次，然后在问题再次出现时链接回该答案。 | | 主持每周展示和讲述线程 | 约 5 分钟 | 您发布开场提示；团队提供内容。 | | 可选的配对或演练 | 0 到 30 分钟 | 为真正受阻的同事保留此选项，并在安排时间之前提供[快速入门](/en/quickstart)链接。 | ## 分享您的发现 您自己的经验是您的同事将遇到的最有说服力的材料，因为它特定于您所有人都共享的代码库、工作流和问题。文档告诉人们什么是可能的；您的帖子向他们展示在您的环境中实际有效的内容。 ### 什么值得分享 最有用的帖子描述同事明天可以重用的技术，而不是已经完成的结果。技术随着在团队中传播而复合；状态更新不会。 可重用技术的示例： * "我了解到 @-mentioning 目录有效。将其指向 `@src/components/` 并询问哪些缺少测试，发现了两个我忽略的。" * "计划模式 (`Shift+Tab`) 在进行任何编辑之前准确显示将触及哪些文件，这就是为什么我放心在共享代码上使用它。" * "我配置了一个 Stop 钩子，以便在长时间任务完成时收到桌面通知。配置在线程中。" * "运行 `/init` 从仓库生成 `CLAUDE.md`，这样助手就不再重复询问我们的约定。" ### 在哪里分享 在您的团队已经阅读的任何地方发布。目标是将示例放在正常工作的路径中，而不是创建目的地。 | 位置 | 最适合 | 推荐格式 | | ----------------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | `#claude-code` 或通用工程频道 | 发现、提示和"今天我学到的"时刻 | 配有一两句话上下文的截图 | | 拉取请求描述 | 在审查者已经在阅读的真实代码上演示方法 | 一行话，如 "Claude 和我做了这个重构；很高兴讲解方法。" | | 站会或每周书面更新 | 与主管和跨级管理者规范使用 | 描述一个具体结果的一句话 | | 团队 wiki 或内部文档 | 持久模式、自定义技能和 `CLAUDE.md` 示例 | 一个短页面，从频道主题链接以便可发现 | ### 有效的格式 配有一行上下文的截图，或简短的前后描述，通常是正确的详细程度。保持每个帖子足够短，以便滚动经过的人仍然能吸收要点。长篇书面报告倾向于被保存稍后阅读然后遗忘，而配有截图的短帖子倾向于被复制和尝试。 下面的示例帖子说明了语气和长度；请改编而不是逐字复制。 ```text theme={null} 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. ``` ```text theme={null} 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. ``` ```text theme={null} 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. ``` ## 成为人们询问的人 一旦您分享了一些示例，问题就会随之而来。这是推荐人角色具有最大杠杆作用的地方，因为对一个人的好答案经常解除正在观看同一频道的其他几个人的阻塞。 ### 用提示而不是解释来回答 当同事问您如何完成某事时，最有用的回应是您实际使用的提示。他们通过在自己的问题上运行该提示学到的比您能写的任何描述都多，并且它给了他们可以立即行动的东西。 ```text theme={null} 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` 直到看到它"这样的回应在当下比文档链接更有用。如果该人稍后需要更多深度，他们会自己找到；现在他们需要解除阻塞的那个东西。 ### 您可能会听到的问题 | 问题 | 建议回应 | 后续资源 | | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | | "我应该先在什么上试？" | 推荐一个真实但有界的任务，最好是这个人因为繁琐而不是困难而一直推迟的 bug 或杂务。 | [常见工作流](/en/common-workflows) | | "我怎么信任它处理我的代码？" | 介绍计划模式：按 `Shift+Tab` 循环进入，Claude 准确提议它打算更改什么，在用户批准之前不会修改任何内容。 | [权限](/en/permissions) | | "设置值得花功夫吗？" | 安装大约需要两分钟，在终端中运行，不需要 IDE 扩展。运行一次 `/init` 即可开始工作。 | [快速入门](/en/quickstart) | | "它产生了不正确的结果。" | 鼓励他们将失败反馈给 Claude。粘贴错误消息或失败的测试比重新表述原始请求更有效。 | [常见工作流](/en/common-workflows) | | "它不理解我们的代码库约定。" | 建议运行 `/init` 生成 `CLAUDE.md` 文件，然后添加团队的约定、测试命令和任何应避免的目录。 | [记忆](/en/memory) | | "这只是自动补全吗？" | 提供一个简短的演示，其中 Claude 解释一个不熟悉的文件、跨服务追踪 bug 或起草迁移计划。这些任务需要跨仓库推理而不是补全单行。 | 两分钟的现场演示 | | "安全和数据处理呢？" | 将此问题转给您的管理员。您组织的部署和数据处理策略已经配置好，推荐人不应该即兴回答。 | [安全](/en/security) · [数据使用](/en/data-usage) | ## 扩大圈子 目标不是建立一个项目或拥有一个推出。而是建立少量轻量级的习惯，使势头在您停止积极推动后能够继续。当频道中的问题正在由您以外的人回答时，该角色就完成了它的工作。 ### 倾向有效的模式 | 模式 | 如何运行 | 所需精力 | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | | 专用频道 | 创建一个 `#claude-code` 频道（或现有频道中的重复线程），置顶[快速入门](/en/quickstart)链接和一个强示例，并公开回答问题以便每个答案惠及所有观看者。 | 设置约五分钟，然后日常维护 | | 每周展示和讲述线程 | 每周五，发布"Claude 本周帮您做了什么？"不需要准备、幻灯片或会议；截图和简短描述就足够了。 | 每周约两分钟 | | 分享自定义技能 | 发布您最有用的 `.claude/skills//SKILL.md` 文件，例如在提交前运行测试和 lint 的 `/ship` 技能，并附上一行描述。因为技能是纯 Markdown，同事可以立即采用。 | 每个技能约五分钟 | | 从您的使用生成入门指南 | 在您花过真实时间的项目中运行 `/team-onboarding`。Claude 扫描您最近的会话、命令和 MCP 服务器，然后生成一个指南，新队友可以粘贴作为他们的第一条消息来重放您的设置。将其置顶在频道中。 | 约两分钟 | | 在第一个任务上配对 | 为任何刚入门的人提供一次十五分钟的配对会话。在他们自己的代码上取得一次成功的结果比任何演示都更有说服力。 | 每人约十五分钟 | | 识别下一个推荐人 | 问您最多问题的同事通常已经准备好承担这个角色。将此页面转发给他们并将频道责任在你们之间分配。 | 可忽略 | ### 三十天行动计划 如果一个宽松的计划有帮助，下面的序列反映了在大多数团队中有效的方法。根据您的上下文自由调整。 创建频道，置顶[快速入门](/en/quickstart)，并发布两三个您自己的示例，附带提示。 **有效的信号：**几个同事做出反应或回复，频道中至少有一个问题被提出。 启动每周展示和讲述线程，公开回答每个问题，并分享一个自定义技能或 `CLAUDE.md` 片段。 **有效的信号：**除了您之外的人发布了他们自己的示例。 提供两三个简短的配对会话，并将最常见的问题和答案整合到置顶的 FAQ 消息中。 **有效的信号：**您看到重复使用，相同的同事返回而不是尝试一次就停止。 识别第二个推荐人，并与您的主管或管理员分享简要总结什么有效、什么无效。 **有效的信号：**频道中的问题正在由您以外的人回答。 ### 当有人想要深入时 您是热情的介绍而不是入门计划。当同事从"我应该试试这个"转向"我如何变得有效"时，请将他们指向[快速入门](/en/quickstart)和[常见工作流](/en/common-workflows)页面。它们包含涵盖真正有用但难以自行发现的功能的简短部分。 ## 回应常见顾虑 健康的怀疑态度是预期的；工程师应该对涉及其代码的工具持谨慎态度。最有效的回应很少是争论一般情况。相反，承认顾虑，提供简短的重新定义，并提议在该人自己的代码上进行一次具体的演示。大多数顾虑通过一次成功的经验就能解决。 | 顾虑 | 建议回应 | 提供的证据 | | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | | "没有它我更快。" | 对于该人例行编写的代码，这可能是真的。建议在他们倾向于避免的工作上尝试：遗留文件、不熟悉的服务或测试脚手架，那里杠杆最高。 | 两种方式计时一个繁琐的任务并比较。 | | "我不信任 AI 触碰生产代码。" | 同意没有更改应该未经阅读就落地。计划模式加上正常的差异审查意味着工程师没有检查过的内容不会被应用，与任何拉取请求的标准相同。 | 在真实文件上演示计划模式。 | | "它会让初级工程师变弱。" | 使用得当，它是一个有效的解释者。鼓励初级工程师在要求更改任何内容之前让 Claude 解释文件及其调用点。 | 一起运行"解释 @file 以及它在哪里被调用"。 | | "我试过一次它产生了幻觉。" | 这通常是上下文问题而不是模型问题。@-mentioning 相关文件、运行 `/init` 和提供实际错误输出通常可以解决。 | 用适当的 `@` 上下文重新运行他们的原始提示。 | | "我们没有时间学习另一个工具。" | Claude Code 是终端命令而不是平台。如果在第一次会话中没有返回价值，搁置它是合理的。 | 两分钟安装后跟一个真实 bug。 | ## 快速参考表 以下技术是最可靠地将某人从首次试用带到日常使用的技术。将此表置顶在频道中或单独分享。 | 技术 | 如何应用 | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 提供正确的上下文 | 使用 `@file` 或 `@directory/` 引用，或直接粘贴错误或日志输出。提供相关上下文比精心设计的提示更有效。 | | 编辑前审查计划 | 按 `Shift+Tab` 进入计划模式。Claude 将在执行之前描述预期的更改供您审批。 | | 教它您的仓库 | 运行 `/init` 生成 `CLAUDE.md` 文件，然后添加您的约定、测试命令和任何不应修改的目录。请参阅[记忆](/en/memory)。 | | 重用工作流 | 在 `.claude/skills//` 中保存 `SKILL.md` 文件以创建整个团队可以使用的 `/name` 技能。请参阅[技能](/en/skills)。 | | 在长任务期间保持知情 | 配置 Stop 钩子以在长时间运行的任务完成时接收桌面通知。请参阅[钩子](/en/hooks-guide)。 | | 从不正确的结果恢复 | 不要重新表述请求，而是将失败的测试或堆栈跟踪粘贴回 Claude 并要求它解决该特定失败。 | | 保持编辑精确 | 要求差异，或指定"只更改 X"。当范围被说明时 Claude 会尊重范围。 | Claude Code 更新频繁。在内部分发此材料之前，请对照[文档主页](/en/overview)验证版本特定的详细信息。