Claude Code 生态与安全

推广大使工具包

1 分钟阅读

推广大使工具包

面向在组织内部推广 Claude Code 的工程师的一份行动指南：应该分享什么、如何回答问题，以及如何推动团队采用。

本页面面向已经在使用 Claude Code，并希望帮助团队采用它的个人工程师。内容包括应该分享什么、如何回答随之而来的问题、一份 30 天行动方案，以及对常见顾虑的回应。

开发者工具很少会因为一则推广公告而得到采用。真正推动采用的，通常是团队中有人开始熟练使用工具、公开交流使用心得，并让其他人能轻松跟进。你作为推广大使所做的工作会产生远超投入的影响：你分享的每个示例，都会缩短后来工程师的学习曲线；你公开回答的每个问题，都会把一个人的经验转化为整个团队可以共同利用的知识。你的角色是放大团队效能，而不是充当服务台。本指南据此安排内容，帮助你以可持续的方式承担这一角色。

推广大使的角色

这一角色包含三种相互促进的行为。

行为	实际做法	重要性
分享你的发现	在团队日常关注的地方发布自己工作中的 Prompt、截图和小成果，例如工程频道、站会讨论串或拉取请求说明。	来自自身代码库的示例比任何外部文档都更有说服力，因为同事能直观看到该工具如何应用于你们共同面对的问题。
成为大家愿意请教的人	同事询问你如何完成某项工作时，直接回复你实际使用的 Prompt，让对方可以立即将其用于自己的任务。	具体且可以直接运行的示例，消除了从产生兴趣到首次成功使用之间的障碍，而大多数推广工作正是停滞在这里。
扩大参与范围	建立少量轻量且定期重复的习惯，例如设立专门频道或每周讨论串，让推广势头在你的注意力转向其他工作时仍能延续。	依赖某一个人的采用方式十分脆弱；由共同习惯推动的采用则会自行持续积累。

其中大部分活动都可以自然融入你正在进行的工作。你只需多花一点心思，考虑把发现发布在哪里，以及如何让自己的回答传播给更多人。

应该投入多少时间

先与自己和负责人对投入形成明确预期。以下活动旨在融入正常工作周；这一角色应该放大你现有工作的影响，而不应成为额外的支持职责。

活动	每周时间	建议
发布成果和 Prompt	约 15 分钟	当场用一张截图和一两句话记录下来，不要把它们写成正式长文。
在公共频道回答问题	约 20 分钟	公开回答一次；同一问题再次出现时，直接链接到已有回答。
主持每周展示分享讨论串	约 5 分钟	你只负责发布开场问题，内容由团队提供。
可选的结对协作或操作演示	0 到 30 分钟	仅留给确实受阻的同事；在约时间之前，先提供快速入门链接。

分享你的发现

你的亲身经验是同事能接触到的最有说服力的材料，因为它与大家共同使用的代码库、工作流和面对的问题密切相关。文档告诉人们“可以做到什么”，而你的分享会展示在当前环境中“什么确实有效”。

哪些内容值得分享

最有用的帖子会介绍同事明天就能复用的方法，而不只是汇报一个已经完成的结果。方法在团队中传播后会不断产生复利，状态更新则不会。

可复用方法示例：

“我发现可以用 @ 提及目录。让它检查 @src/components/ 中哪些组件缺少测试，结果找出了两个我漏掉的组件。”
“计划模式 (Shift+Tab) 会在编辑前明确列出将要改动的文件，所以我可以放心地在共享代码上使用它。”
“我配置了 Stop Hook，长任务完成时会收到桌面通知。配置方式放在讨论串里了。”
“运行 /init 会根据仓库生成 CLAUDE.md，这样助手就不会反复询问我们的约定。”

在哪里分享

在团队本来就会关注的地方发布。目标是让示例出现在日常工作路径中，而不是再创建一个需要大家专门前往的地方。

位置	最适合的内容	建议形式
`#claude-code` 或通用工程频道	新发现、Prompt 和“今天学到了”时刻	一张截图，配一两句话交代上下文
拉取请求说明	在评审者已经阅读的真实代码中演示使用方式	一句话，例如“这次重构是 Claude 和我一起完成的，乐意介绍具体做法。”
站会或每周书面更新	让负责人和跨级主管逐渐习惯看到这项工具的使用	用一句话说明一项具体成果
团队 Wiki 或内部文档	可长期复用的模式、自定义 Skill 和 `CLAUDE.md` 示例	一篇短页面，并从频道主题链接过去，方便日后找到

行之有效的形式

一般来说，一张截图配一句背景说明，或简短介绍前后变化，详细程度就足够了。每篇帖子都应短到让快速划过的人也能领会重点。长文往往会被保存起来“以后再看”，最终遭到遗忘；而附有截图的短帖更容易被直接复制和尝试。

以下示例展示了合适的语气和篇幅；请根据实际情况改写，不要逐字复制。

今天发现可以用 @ 提及目录。我让它查看 @src/components/，
并询问哪些组件缺少测试，结果找出了两个被我漏掉的组件。

我配置了 Stop Hook，这样长任务完成时就会收到桌面通知。我启动了一次
重构后离开了一会儿，任务结束时便收到了通知。配置方式放在讨论串里了。

计划模式让我能放心地在重要代码上使用 Claude Code。按 Shift+Tab，
直到看到“plan”；它会在进行任何更改之前，明确列出打算修改的文件。

成为大家愿意请教的人

分享几个示例后，自然会有人开始提问。这正是推广大使角色最能发挥杠杆效应的地方：对一个人作出的优质回答，往往也能帮助同一频道中关注讨论的其他人摆脱阻碍。

用 Prompt 回答，而不是只作解释

同事询问你如何完成某项工作时，最有用的回答就是你实际使用的 Prompt。他们把这条 Prompt 用在自己的问题上，学到的内容会比阅读任何说明都多；而且他们可以立即着手尝试。

同事：你是怎么让它找出那个竞态条件的？

推广大使：我问它：“@tests/scheduler.test.ts 中的测试不稳定，找出
原因。”然后它在调度器中追踪到了两个未等待完成的 Promise。你可以试着
用同样的说法询问你的测试。

直接指出功能，而不是只丢一条文档链接

当下回复“试试计划模式，按 Shift+Tab 直到看到它”，比只发一条文档链接更有帮助。如果对方之后需要深入了解，自然可以继续查阅文档；眼下，他们需要的是一个能立即解除阻碍的操作。

你很可能遇到的问题

问题	建议回答	后续资源
“第一次应该拿什么任务尝试？”	推荐一个真实但范围有限的任务，最好是对方因为烦琐而一直拖延的 bug 或杂务，而不是难度很高的任务。	常见工作流
“怎样才能放心让它接触我的代码？”	介绍计划模式：按 `Shift+Tab` 可以切换到此模式；Claude 会明确提出打算进行的更改，而且在用户批准之前不会修改任何内容。	权限
“值得花时间设置吗？”	安装大约只需两分钟，在终端中运行，也不需要 IDE 扩展。首次运行一次 `/init`，就足以开始工作。	快速入门
“它给出的结果不正确。”	建议把失败信息反馈给 Claude。粘贴错误消息或失败的测试，远比重新措辞原始请求有效。	常见工作流
“它不了解我们代码库的约定。”	建议运行 `/init` 生成 `CLAUDE.md` 文件，再加入团队约定、测试命令，以及任何不应触碰的目录。	记忆
“这不就是自动补全吗？”	可以做一个简短演示，让 Claude 解释不熟悉的文件、跨服务追踪 bug 或起草迁移方案。这些任务需要对整个仓库进行推理，而不是补全一行代码。	两分钟的现场演示
“安全和数据处理怎么办？”	把这个问题交给管理员。组织的部署与数据处理策略已经配置好，推广大使不应临时编造答案。	安全 · 数据使用

扩大参与范围

目标不是建立一套项目，也不是负责整个推广部署，而是形成少量轻量习惯，让你不再主动推动后，推广势头依然可以延续。当频道里的问题开始由你以外的人回答时，这一角色就完成了使命。

通常行之有效的做法

做法	如何开展	所需投入
设立专门频道	创建 `#claude-code` 频道（或在现有频道中建立定期讨论串），置顶快速入门链接和一个有说服力的示例，并公开回答问题，让每个回答都能帮助所有关注讨论的人。	设置约需五分钟，之后融入日常工作
每周展示分享讨论串	每周五发布“Claude 本周帮你完成了什么？”无需准备材料、幻灯片或会议；截图和简短说明就足够了。	每周约两分钟
分享自定义 Skill	发布你最有用的 `.claude/skills/<name>/SKILL.md` 文件，例如提交前运行测试和 lint 的 `/ship` Skill，并附上一句说明。Skill 就是纯 Markdown 文件，因此同事可以立即采用。	每个 Skill 约五分钟
根据自己的使用方式生成设置指南	在你已经投入实际使用时间的项目中运行 `/team-onboarding`。Claude 会扫描你最近的会话、命令和 MCP 服务器，生成一份指南；新队友可以把它粘贴为第一条消息，以复现你的设置。将该指南置顶到频道中。	约两分钟
在首个任务上结对协作	为每个刚开始使用的同事提供一次 15 分钟的结对协作。在自己的代码上成功完成一次任务，比任何演示文稿都更有说服力。	每人约 15 分钟
找到下一位推广大使	经常向你提问的同事通常已经适合承担这一角色。把本页面转给他们，并和他们分担频道职责。	几乎无需额外投入

30 天行动方案

如果一份宽松的计划能有所帮助，下面的顺序总结了在大多数团队中通常有效的做法。请根据自身情况自由调整。

第 1 周：为频道播种

创建频道，置顶快速入门，并发布两三个自己的示例，其中附上使用的 Prompt。

**生效信号：**几位同事作出回应或回复，且频道中至少出现一个问题。

第 2 周：建立节奏

发起每周展示分享讨论串，公开回答每个问题，并分享一个自定义 Skill 或 CLAUDE.md 片段。

**生效信号：**你以外的人开始发布自己的示例。

第 3 周：结对并沉淀知识

提供两三次简短的结对协作，并把最常见的问答整理为置顶 FAQ 消息。

**生效信号：**你开始看到重复使用：同一批同事会持续回来使用，而不是尝试一次后便停止。

第 4 周：交接

找到第二位推广大使，并向负责人或管理员简要总结哪些做法有效、哪些无效。

**生效信号：**频道里的问题开始由你以外的人回答。

当有人希望进一步深入

你负责的是友好地引路，而不是整个引导上手项目。当同事的问题从“我应不应该试试”变成“怎样才能熟练使用”时，请引导他们阅读快速入门和常见工作流页面。这些页面用简短章节介绍了一些确实有用、但很难自行发现的功能。

回应常见顾虑

合理的质疑很正常；对于会接触自身代码的工具，工程师本就应该保持谨慎。最有效的回应通常不是泛泛争论，而是先认可顾虑，简短提供另一个视角，再提议直接在对方的代码上进行一次具体演示。大多数顾虑都可以通过一次成功体验化解。

顾虑	建议回答	可以提供的证据
“不用它我更快。”	对于当事人经常编写的代码，这很可能是事实。建议把它用于平时容易回避的工作，例如旧版文件、不熟悉的服务或测试脚手架；这些场景最能发挥杠杆效应。	分别用两种方式完成一个烦琐任务，并对比耗时。
“我不相信 AI 能安全修改生产代码。”	认同任何更改都不应在未经阅读的情况下合入。计划模式加上常规 diff 评审，意味着工程师未检查的内容不会被应用，这与任何拉取请求所遵循的标准相同。	在真实文件上演示计划模式。
“它会让初级工程师能力退化。”	如果使用得当，它是很有效的讲解工具。鼓励初级工程师先让 Claude 解释文件及其调用位置，再要求它进行任何更改。	一起运行“Explain @file and where it is called from”。
“我试过一次，它产生了幻觉。”	这通常是上下文问题，而非模型问题。用 @ 提及相关文件、运行 `/init` 并提供实际错误输出，通常可以解决。	加上正确的 `@` 上下文，重新运行对方最初的 Prompt。
“我们没时间再学一个工具。”	Claude Code 是一条终端命令，而不是一个平台。如果首次会话中就没有产生价值，暂时放下它也很合理。	两分钟安装，然后解决一个真实 bug。

快速参考表

以下方法最能稳定地帮助新用户从首次尝试过渡到日常使用。可以把这张表置顶到频道，或单独分享。

方法	如何应用
提供正确的上下文	使用 `@file` 或 `@directory/` 引用，也可以直接粘贴错误或日志输出。提供相关上下文比设计复杂的 Prompt 更有效。
编辑前先审查计划	按 `Shift+Tab` 进入计划模式。Claude 会先说明打算进行的更改，供你批准后再执行。
让它了解你的仓库	运行 `/init` 生成 `CLAUDE.md` 文件，然后加入团队约定、测试命令和任何不应修改的目录。请参阅记忆。
复用工作流	在 `.claude/skills/<name>/` 中保存 `SKILL.md` 文件，创建整个团队都可以使用的 `/name` Skill。请参阅 Skills。
在长任务期间及时掌握进展	配置 Stop Hook，在长时间运行的任务完成时接收桌面通知。请参阅 Hook。
从错误结果中恢复	不要重新措辞请求，而是把失败的测试或堆栈跟踪粘贴给 Claude，让它解决这一具体失败。
控制更改范围	要求提供 diff，或明确指定“only change X”。Claude 会遵守清楚说明的范围。

Claude Code 更新频繁。在组织内部发布本材料前，请根据文档首页核实与版本相关的详细信息。

上一页内部推广沟通资料