Claude Code 在团队里推广——我在公司内推了 3 个月的真实体验
Claude Code 在团队里推广——我在公司内推了 3 个月的真实体验
适读人群：想在团队里推广 AI 工具的工程师或技术主管 | 阅读时长：约14分钟 | 核心价值：不是方法论，是 3 个月里真实遇到的抵制、误解和成功案例的第一手记录
三个月前，我在周会上提了一句：我们团队应该用起来 Claude Code。
当时没想到这句话会带来什么，我以为同事们会感兴趣，毕竟 AI 编程工具这两年这么火。
结果周会结束之后，老王私信我："老张，这东西靠谱吗？我试了下 ChatGPT，写出来的代码要改一半。"小李说："我看了下，要用美元付费，公司能报销吗？"还有一个人直接没回应，我后来知道他当时就在心里默默否定了，觉得这是折腾。
那一刻我才意识到：推广一个工具，和自己用一个工具，是两件完全不同的事。
这篇文章写的就是这三个月里发生的真实事情。
第一个月：我犯的错误
我最开始的策略是错误的。
我整理了一批"Claude Code 能做什么"的资料，发到了团队群里，附上了一个安装教程。我以为这样就够了——把工具推到大家面前，聪明人自然会用起来。
一周之后，群消息的阅读数停在了 8，回复 0。
我去问了几个人。老王说："我看了，挺复杂的，等我有时间了再研究。"小李说："需要配 API Key？我不太会搞这个。"还有人说："我现在手头的事做不完，这个先放着。"
问题很清楚：我给的是信息，不是帮助。
对于大多数人来说，"有时间再研究"等于"永远不会研究"。我应该给他们一个理由在现在就用，而不是等他们自己有了动力。
这个判断是我后来推广策略改变的核心。
第一个真正的突破口
转折点出现在一次 code review。
小李在 review 一个新同事的代码，找了很久一个 bug。我坐在旁边，直接打开 Claude Code，把那段代码粘进去，问："这段代码有没有潜在的问题？"
30 秒之内，Claude 找到了问题：一个没处理 null 的地方，在特定入参下会 NPE。
小李看了看屏幕，没说话，然后说："等等，让我也试一下。"
他装了 Claude Code，把他自己在 review 的另一段代码丢进去。Claude 找到了两个他没注意到的问题，其中一个他后来确认是真实的隐患。
那天之后，小李变成了团队里最积极用 Claude Code 的人。
这件事给了我一个很重要的认识：推广工具最有效的方式，不是告诉别人它能做什么，是在他眼前帮他解决了一个真实的问题。
一次现场演示，胜过十篇介绍文章。
不同人的接受速度差异巨大
用了一个月之后，我发现团队里的人分成了几类：
立刻接受的（约20%）
这类人通常是：对新工具本来就很好奇，或者在某个任务上被帮到了。小李是典型。他们装了之后，不需要人教，自己就会摸索出用法，然后会主动分享给别人。
需要看到效果才接受的（约50%）
这类人不反对，但需要被说服。他们接受的方式通常是：自己遇到了一个问题，来问我，我用 Claude Code 帮他当场解决了，他才真正开始用。
这类人是推广的主力目标。我花了大量时间在这里，不是发资料，是陪着他们解决真实问题。
有顾虑但不说的（约20%）
这类人包括老王和另外一两个人。他们不反对，偶尔会用一下，但不深入。
后来我和老王聊了一次，才知道他的真实顾虑：他担心用 AI 写出来的代码，出了问题他看不懂，不知道怎么修。他怕"用了之后对 AI 产生依赖，自己的能力反而退步"。
这个顾虑很真实，不是无理取闹。我没有试图说服他这个顾虑是错的，而是告诉他我怎么用：我让 Claude 解释它做的每一个决策，我不接受我看不懂的代码。他之后试了一下，慢慢接受了一些。
有明确抵制心理的（约10%）
有一个人，用了两次之后说："太慢了，不如我自己想快。"然后就不用了。
我后来想了想，他说的不完全是借口。他是团队里经验最丰富的人，他的技术直觉确实很强，很多问题他自己能很快解决。Claude Code 给他带来的价值确实比给新人小。
我接受了这个现实。不是每个人都需要同样的工具。强迫他用，可能反而影响关系。
什么样的使用方式最有说服力
在所有我演示过的场景里，有几个场景的"说服力"明显高于其他的。
调 bug
这个场景对所有人都有说服力，因为 bug 是痛点，任何人遇到 bug 都想尽快解决。Claude Code 在分析 bug 上的表现稳定，不像生成代码那样质量不稳定。
只要有一次帮人快速找到了一个他找了很久的 bug，他就会记住"Claude Code 可以用来调 bug"。
看陌生代码
遇到一段别人写的、自己看不懂的代码，让 Claude Code 解释。这个场景的价值对新人特别明显，他们看老代码经常看不懂，Claude Code 成了他们的"老代码翻译器"。
写测试用例
写测试是大多数工程师不爱做的事，但知道自己应该做。Claude Code 帮你写测试，心理阻力小很多，因为这本来就不是你喜欢的工作。
这三个场景是我在内部推广时，实际效果最好的。不是"帮你写功能代码"，因为那个场景里，大家对 AI 生成代码的质量是有疑虑的，需要花时间验证。
组织文化层面的观察
推广这三个月，我看到了一些不只是"工具接受度"的东西。
年龄和经验与接受速度没有直接关系
我以为年轻人会接受得更快，年长的工程师会更保守。实际上不是这样。接受得最快的小李，工作了 6 年，不是最年轻的。抵制得最彻底的那位，是工作了 3 年的。
接受速度和年龄关系不大，和这个人对"不确定性"的容忍度关系更大。能接受"用了可能有坑，边用边调整"的人，很快就上手了。
团队里有没有一个"先行者"非常重要
小李接受之后，他开始主动帮其他人解决 Claude Code 的使用问题，成了团队里的"Claude Code 答疑员"。这件事大大降低了其他人的学习成本，也降低了心理门槛。
如果没有这样一个先行者，推广速度会慢很多。
工具效果要能被量化感知
说"用了之后效率提高了"，没人信。但"这个 bug 我找了两个小时，Claude Code 30 秒找到了"，所有人都信。
具体的、可感知的效果比抽象的效率提升更有说服力。我学会了收集这种"具体案例"，在团队里分享，而不是讲抽象的"AI 可以提高开发效率"。
三个月后的实际状态
三个月过去了，我们团队现在的 Claude Code 使用情况大概是这样的：
- 8 个人里有 5 个人在定期使用（每周至少几次）
- 2 个人偶尔用（遇到特定问题才想起来）
- 1 个人基本不用
我对这个结果满意。我不打算追 100% 的使用率，那不现实，也没必要。
更重要的变化是：团队里的人开始把 Claude Code 当成一个"可以用的工具"，而不是一个"需要研究的东西"。这个心理状态的改变，比使用率数字更重要。
给想在团队里推广的人
三个月下来，我的真实建议是：
找到一个真实的痛点，在现场解决它。 不要讲功能，不要发资料。等有人遇到问题，当面用 Claude Code 帮他解决，这是最有效的推广方式。
找到那个最容易被说服的人，把他变成盟友。 一个内部的"Claude Code 用户"比你自己作为推广者更有说服力。
不要试图说服抵制者。 他们的顾虑有时候是有道理的。尊重他们的选择，等他们自己准备好了再说。
给自己设一个 3 个月的目标，不是 100% 使用率。 工具推广是一个长期过程，短期急于求成往往反效果。