这个工具包帮助已有 Claude Code 使用经验的工程师在公司内部推动团队采纳。核心工作包括：在团队频道分享自己的使用技巧和 prompt、用可直接运行的 prompt 而非抽象解释来回答问题、建立每周展示线程或专用频道等轻量习惯，让采纳持续自发。文中包含 30 天行动计划和针对常见顾虑（如“我手写更快”“不信任 AI 改生产代码”）的回应方案。

Claude Code 内部推广指南：倡导者工具包

一份供工程师在组织内部推广 Claude Code 的实战手册：该分享什么、怎么回答问题、如何帮助团队逐步采纳。

本页面面向已经使用 Claude Code 并希望帮助团队上手的个人工程师。内容包括：该分享什么、怎么回答你将会遇到的问题、一个 30 天行动计划，以及常见担忧的回应方案。

开发工具的采纳很少因为一次官宣就发生。它往往始于团队里有一个人用得顺手、公开谈论它、并为其他人铺平道路。作为推广者，你的工作会产生远超你投入时间的杠杆效应：你分享的每个示例都会缩短后来者的学习曲线，你在公开场合回答的每个问题都会把一个人的经验变成团队可重复利用的资产。你在为团队充当放大器，而非帮助台，本指南的目标就是让你可持续地扮演这一角色。

推广者的职责

推广者的角色由三个相互强化的行为组成。

行为	实际表现	为什么重要
分享你的发现	在团队日常关注的渠道（如工程频道、站会消息、PR 描述）里发布你自己的工作 prompt、截图和小成果。	来自你们自己代码库的例子比任何外部文档都更有说服力，因为同事能直观看到工具如何应用到他们和你共有的问题上。
成为被问的人	当同事问你如何完成某件事时，用你实际使用的 prompt 来回应，让他们能直接应用到自己的任务里。	一个具体、可马上运行的示例能消除“好奇”和“第一次成功”之间的鸿沟，而大多数推广努力恰恰卡在这个地方。
扩大圈子	建立少量轻量、可重复的习惯（如一个专用频道或每周线程），让你即使无法持续关注，动力也能自己持续。	依赖单个人的采纳是脆弱的；靠共同习惯承载的采纳会自己不断增长。

这些行为大部分可以自然融入你已有的工作流程，差别只在于多了一点有意识的选择：你把发现贴在哪里、你如何让答案传播。

你需要付出多少精力

对自己和主管设好预期。下面的活动旨在融入正常的工作周，这个角色应该是你现有工作的放大器，而非额外的支持责任。

活动	每周时间	指导建议
发布成果和 prompt	约 15 分钟	随手截图加一两句话记录即可，不要写成正式文章。
在共享频道回答问题	约 20 分钟	公开回答一次，之后重问时直接链回到那次回答。
主持一个每周展示和讨论线程	约 5 分钟	你发出开场提示，团队贡献内容。
可选：结对或指导	0 到 30 分钟	仅当你同事确实卡住时使用，建议先发 Quickstart 链接，再约时间。

分享你的发现

你自身的经验是同事能看到的最有说服力的材料，因为它针对你们共用的代码库、工作流和问题。文档告诉人们什么功能可能做到；你的帖子让他们看到哪些功能在你们的环境中真正有效。

什么值得分享

最有用的帖子描述一个同事明天就能复用的技术，而不是一个已经完成的结果。技术会随着团队传播而叠加；状态更新则不会。

可复用的技术例子：

• “我学到 @ 引用一个目录也是可行的。把 @src/components/ 给它并问哪些文件缺少测试，它找出了两个我漏掉的文件。”
• “计划模式（Shift+Tab）在修改之前会精确展示即将涉及的文件，这就是为什么我放心在共享代码上用它。”
• “我配置了一个 Stop 钩子，在长任务完成时收到桌面通知。配置细节放在线程里了。”
• “运行 /init 会根据仓库生成一个 CLAUDE.md，助手就不会反复询问我们的编码惯例了。”

在哪儿分享

发到团队日常浏览的地方。目标是让示例出现在正常工作的路径上，而不是专门建立一个独立的阅读地点。

位置	最适合的内容	推荐格式
#claude-code 频道或通用的工程频道	发现、prompt 和“今天学到”的瞬间	截图 + 一两句话背景
PR 描述	展示在评审者正在看的真实代码中的用法	一句如 “我和 Claude 一起做了这个重构，欢迎讨论具体思路。”
站会或每周书面更新	让主管或上层管理者知道你们在正常使用	一句话描述一个具体成果
团队 Wiki 或内部文档	需要长期保留的模式、自定义技能和 CLAUDE.md 例子	一个简短页面，在频道主题中置顶以保持可发现性

有效的格式

一张截图配一行背景，或一个简短的 before-after 描述，通常就够了。保持每个帖子短到你直接划过去也能抓住重点。长篇大论往往会被保存“稍后阅读”然后就忘了，而短帖子加截图经常被复制并尝试。

下面是示例帖子的风格和长度，请根据自己的情况调整，不要照抄。

今天学到 @ 引用一个目录也可以。我把它指向 @src/components/ 并问了哪些文件
缺少测试，它找出了两个我漏掉的文件。

我配置了一个 Stop 钩子，长任务完成后收到桌面通知。我开了一个重构，走开，
然后收到了完成通知。配置见线程。

计划模式是我放心在重要代码上用它的原因。按 Shift+Tab 直到看到 “plan”，
它会在修改任何东西之前列出它打算触碰的文件。

成为被问的人

等你分享了一些例子之后，问题就会来。这是推广者最具杠杆效应的时刻，因为一个好的答案常常会连锁解除其他在同一个频道里观看的人的疑虑。

用 prompt 回答，而不是解释

当同事问你是如何完成某件事的时，最有用的是你实际使用的 prompt。他们从把那个 prompt 应用到自己问题中获得的信息，比任何你能写的描述都多，而且你给了一个他们能立即行动的东西。

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

推广者：我问了 “@tests/scheduler.test.ts 中的测试不稳定，找出原因”，
它追踪到调度器里两个没有 join 的 promise。用同样的措辞试试你的测试。

指向功能，而不是文档

一句 “试试计划模式，按 Shift+Tab 直到出现” 在当时比一个文档链接更有用。如果那个人需要更多深度，他们之后自己会去找；此刻他们只需要那个能让他们动起来的东西。

你可能会听到的问题

问题	建议回答	后续资源
“我应该先在什么东西上试试？”	推荐一个真实但范围可控的任务，最好是那种因为单调而非困难而被一拖再拖的 bug 或杂事。	常见工作流
“我怎么放心让它碰我的代码？”	介绍计划模式：按 Shift+Tab 进入，Claude 会提议将要修改的内容，用户批准后才真正执行。	权限模式
“配置起来值吗？”	安装大约两分钟，在终端里运行，不需要 IDE 插件。运行 /init 一次就够了。	快速入门
“它产生了错误的结果。”	鼓励他把失败反馈给 Claude。粘贴错误信息或失败的测试比重新措辞原始请求有效得多。	常见工作流
“它不理解我们代码库的惯例。”	建议运行 /init 生成 CLAUDE.md 文件，然后把团队的惯例、测试命令和应避免的目录加进去。	记忆
“这不就是个自动补全吗？”	简短演示 Claude 解释一个不熟悉的文件、跨服务追踪 bug 或草拟迁移计划。这些任务需要对整个仓库进行推理，而不仅仅是完成一行。	两分钟的现场演示
“安全和数据处理怎么办？”	把这个问题转给你的管理员。你们组织的数据处理和部署策略已经配置好了，推广者不应该即兴回答。	安全 · 数据使用

扩大圈子

目标不是建立一个正式的项目或负责整个推广。而是建立少量轻量习惯，让即使你停止主动推动后，势头也能自行持续。当频道里回答问题的人不止你一个时，角色就完成了。

行之有效的模式

模式	如何执行	所需精力
专用频道	创建 #claude-code 频道（或在现有频道里创建一个重复线程），置顶 Quickstart 链接和一个强案例，公开回答问题以便每个观看者受益。	约 5 分钟设置，之后自然运行
每周展示与讨论线程	每周五发 “本周 Claude 帮了你什么？” 不需要准备、幻灯片或会议；截图和简短描述就够了。	每周约 2 分钟
分享一个自定义技能	把你最有用的 .claude/skills/<name>/SKILL.md 文件发出来（比如一个 /ship 技能，提交前跑测试和 lint），带一行描述。因为技能是纯 Markdown，同事可以直接采用。	每个技能约 5 分钟
通过自己的使用生成一个设置指南	在一个你已经花了时间投入的项目里运行 /team-onboarding。Claude 会扫描你最近的会话、命令和 MCP 服务器，生成一份新队友可以直接粘贴作为第一条消息来复现你的设置的指南。在频道里置顶。	约 2 分钟
在第一个任务上结对	为每个刚开始的人提供一次 15 分钟的结对会话。在他们的代码上成功一次比任何演示都有说服力。	每人约 15 分钟
找到下一位推广者	那个问你最多问题的同事通常已经准备好接过这个角色了。把这页发给他，然后你们俩分担频道职责。	几乎零成本

30 天行动清单

如果你希望有个大致计划，下面的序列反映了大多数团队的有效做法。自由调整以适应你的上下文。

第 1 周

• 创建频道，置顶 Quickstart，并发布你自己的两三个示例（附上 prompt）。
• 判断生效的信号：有几个同事回应或评论，频道里至少有人问了一个问题。

第 2 周

• 开始每周展示线程，公开回答每个问题，分享一个自定义技能或 CLAUDE.md 片段。
• 判断生效的信号：有不是你的人发布了自己的例子。

第 3 周

• 提供两三次简短结对会话，把最常见的问题和答案整理成一个置顶的 FAQ 消息。
• 判断生效的信号：看到重复使用，同一个同事回来再用（而不是试一次就停）。

第 4 周

• 确定另一位推广者，向你的主管或管理员简要总结哪些有效、哪些无效。
• 判断生效的信号：频道里的问题由不是你的人在回答。

当有人想深入了解时

你是“温暖的引荐”而非“入职培训”。当同事从“我该不该试试”进入“我怎么用好它”时，把他们指向 Quickstart 和 常见工作流 页面。这些页面包含简短的章节，涵盖那些真正有用但靠自己不容易发现的功能。

回应常见担忧

健康的质疑是正常的；工程师应该对触碰自己代码的工具保持谨慎。最有效的回应通常不是论证普遍情况。相反，先承认问题，提供一个简短的重新框架，然后提议在对方自己的代码上做一个具体演示。大多数担忧会在一次成功的体验后消失。

担忧	建议回应	可以提供的证据
“我不用它反而更快。”	在你常规写的代码上可能是对的。建议试试那些通常回避的工作：遗留文件、不熟悉的服务或测试脚手架，那里的杠杆效应最大。	计时一次单调任务两边做法，对比时间。
“我不相信 AI 能碰生产代码。”	同意任何改动都不应该未经阅读就落地。计划模式配合正常的 diff 审查意味着工程师看不到的改动不会被应用，和任何 PR 标准一致。	在真实文件上演示计划模式。
“它会让初级工程师变弱。”	用好的话，它是一个有效的解释器。鼓励初级工程师在让 Claude 改动任何东西之前，先让 Claude 解释一个文件以及它的调用点。	一起运行 “解释 @文件以及它在哪儿被调用”。
“我试过一次，它产生了幻觉。”	这通常是上下文问题而非模型问题。用 @ 引用相关文件、运行 /init 并提供实际错误输出通常能解决。	用正确的 @ 上下文重新运行他最初的 prompt。
“我们没时间再学一个新工具了。”	Claude Code 是一个终端命令，而非一个平台。如果第一个会话没有带来价值，放弃它也合理。	两分钟安装 + 一个真实 bug 的演示。

快速参考表

下面的技巧是那些最可靠地把一个人从第一次试用推向日常使用的。把这张表置顶到频道里，或单独分享。

技巧	怎么用
提供正确的上下文	使用 @file 或 @directory/ 引用，或直接粘贴错误输出或日志。提供相关上下文比重写长篇 prompt 更有效。
在修改前审查计划	按 Shift+Tab 进入计划模式。Claude 会在执行前描述意图改动让你批准。
教会它你的仓库	运行 /init 生成 CLAUDE.md 文件，然后添加你们的惯例、测试命令以及不应该被改动的目录。参见记忆。
复用工作流	在 .claude/skills/<name>/ 下保存一个 SKILL.md 文件，创造一个 /name 技能，整个团队都能用。参见技能。
长任务期间保持知情	配置一个 Stop 钩子，在长时间运行的任务完成时收到桌面通知。参见钩子。
从错误结果恢复	不要重新措辞请求，而是把失败的测试或堆栈跟踪粘贴回 Claude，让它专门处理那个失败。
保持编辑精确	要求一个 diff，或指明 “只修改 X”。当范围明确时，Claude 会遵守。

Claude Code 频繁更新。在内部传播本材料前，请对照文档首页确认版本对应的具体细节。

常见问题

如何开始在公司内部推广 Claude Code？

先建立渠道，比如在团队聊天工具中创建一个 #claude-code 频道。置顶 Quickstart 链接，然后发布你自己使用中的 2-3 个实际例子（附上 prompt）。每周五发一个展示线程（如 “本周 Claude 帮了你什么？”），公开回答每个问题。30 天计划见本页对应章节。

同事担心 AI 生成的代码质量，怎么回应？

先承认担忧是合理的。然后建议他用计划模式（Shift+Tab）预览改动，与正常的代码审查标准一致。如果发生幻觉，通常是因为上下文不足：帮他补上 @ 引用相关文件、运行 /init 生成 CLAUDE.md 并提供错误信息。最好在对方的代码上做一次真实任务的演示。

推广 Claude Code 需要投入多少时间？

作为推广者，建议每周大约花 35-40 分钟：15 分钟发布发现、20 分钟回答问题（公开一次后链回相同回答）、5 分钟主持线程。可选结对根据情况最多 30 分钟。这个角色应融入正常工作，不要变成额外的支持责任。