第1887篇：团队AI素养建设的半年实录——从抗拒到主动使用的过程
第1887篇：团队AI素养建设的半年实录——从抗拒到主动使用的过程
这篇文章记录的不是技术，是人。
半年前，我们团队里有人明确说"AI工具对我没用"，有人私下说"用AI写的代码我不放心"，还有一个同事因为不想用AI Copilot，差点跟我闹翻。
半年后，同样这些人，会在早会上主动分享"我昨天用AI发现了一个以前没注意到的优化点"。
这个转变不是靠强制要求发生的，而是靠一系列刻意设计的机制和一些没想到会起作用的时机。我把整个过程记录下来，给有类似困惑的朋友做参考。
第一个月：摸底和理解阻力
在做任何推动之前，我先做了一件事：搞清楚阻力从哪里来。
我跟团队里10个成员一对一聊了一次，问了同样几个问题：
- 你现在用AI工具做什么？
- 有没有用过之后感觉没帮上的情况？
- 如果让你每天必须用AI工具，最担心什么？
我归纳出了三类阻力：
一、技能焦虑型（3人）
这类同事担心的不是AI，而是自己的价值。他们的深层恐惧是"如果AI能做我的工作，我还有什么价值？"。表现形式是对AI能力的刻意贬低，比如"AI写的代码全是玩具级别的"。
二、质量担忧型（4人）
这类同事真的不信任AI的输出质量。他们不是情绪性地排斥，而是有过几次用AI生成代码后出现bug的经历，进而对AI持审慎态度。这种担忧是理性的，也是最容易解决的。
三、习惯惰性型（3人）
这类同事没有强烈的反对，但就是没有形成习惯。他们用不用AI无所谓，但懒得改变现有的工作方式。
了解了阻力的来源，才能有针对性地应对。对三类人用同一套方法是不对的。
第二个月：从"展示"开始，而不是从"要求"开始
最常见的AI素养推广错误是：先出台规定（比如"代码提交前必须用AI检查一遍"），然后期待大家自觉执行。
这几乎不会有好效果。规定会催生应付行为，而不是真正的习惯改变。
我们的策略是先展示，让大家自己看到AI工具的价值，主动产生"我也想用"的念头。
"AI时刻"：早会里的固定环节
我在每周一的早会里加了一个5分钟的"AI时刻"：随机请一个人分享上周用AI工具做了什么有意思的事，不管结果好不好都可以讲。
最开始的两周，只有两三个人有东西可分享。但这两三个人讲的事情，让其他人开始觉得"原来可以这么用"。
有一次，一个做后端的同事分享了他用Claude分析一个生产环境OOM问题的过程：他把堆栈信息和相关代码贴给AI，AI不仅分析出了直接原因，还顺带指出了一个他之前没注意到的内存泄漏风险。
分享完之后，旁边坐的一个之前表示"AI对我没用"的同事，下午就开始把自己手头的一个排查问题发给AI试了试。
展示比说教有效得多。
实战工作坊：用真实问题，不用编造场景
第六周，我们做了一次2小时的工作坊。
核心设计原则是：用每个人手头真实的工作内容，不用任何例子题目。
在工作坊开始前，我提前让每个人带来他们当前最头疼的一个技术问题——代码、文档、架构决策都行。
然后我们两两搭档，互相帮对方用AI工具尝试解决那个问题。
这个设计的好处是：成功解决了的问题，当事人立刻感受到了价值；没成功解决的问题，也让大家理解了AI的边界在哪里。
工作坊结束后，有个同事跟我说："原来AI可以帮我做SQL调优分析，我以前都是靠猜的。"他之前是那个差点跟我闹翻的人——一个十年的Oracle DBA，认为自己对数据库的了解远超任何工具。
工作坊那天，他把一个执行计划很差的SQL发给AI，AI给出的优化建议里有两条他自己以前没想到过。从那以后，他变成了团队里最积极分享AI使用技巧的人。
第三个月：建立"AI辅助工作流"，而不是"额外工具"
度过了展示阶段，下一步是让AI使用融入日常工作流，而不是作为可选的附加选项。
我们做了几件事：
把AI检查加入代码Review标准
我们在代码Review的标准里加了一条软性建议：提交PR前，建议用AI对关键代码做一次自审，把AI的反馈和你的处理方式写在PR描述里。
注意：是"建议"，不是"要求"，而且只要求写出"处理方式"，不要求必须接受AI的建议。
这个设计很聪明（不是我想的，是团队讨论出来的）：它让AI使用变得可见，同时给了开发者充分的自主权。写"AI建议改X，我觉得没必要，因为Y"是完全合理的。
/**
* PR描述模板（建议填写）
*
* ## 改动说明
* [描述这次改动做了什么]
*
* ## AI辅助自查
* - 使用工具：[Claude / Copilot / 其他]
* - 主要反馈：[AI提出了什么问题]
* - 处理方式：[接受了哪些建议 / 为什么拒绝某些建议]
*
* 如果没有使用AI辅助，请简述原因
*/几周后，大部分PR描述里都开始出现AI辅助自查的内容。有意思的是，有几次AI提出的建议被开发者拒绝了，但在Code Review时被Reviewer重新提出，引发了一次很好的技术讨论。
建立Prompt共享库
我们在内部Wiki上建了一个"Prompt宝库"，鼓励大家把自己用得顺手的Prompt记录下来。
这个共享库解决了一个很实际的问题：新手不知道怎么问AI。很多人第一次用AI效果不好，不是因为AI不行，而是因为Prompt写得太模糊。
我们按场景分类整理了常用Prompt：
## 代码调试
**场景：分析异常堆栈**
提示词模板：以下是生产环境的Java异常堆栈，请分析可能的根因，并给出排查步骤：
[粘贴堆栈]
背景信息：
- Java版本：[版本]
- 这段代码的业务逻辑：[简述]
- 最近做过的相关变更：[描述]
**场景：SQL性能优化**
提示词模板：以下是一个执行很慢的SQL，请分析性能问题并给出优化建议：
[粘贴SQL]
数据量情况：[描述主要表的数据量] 现有索引：[描述相关字段的索引情况] 执行计划：[粘贴explain结果]
## 文档撰写
**场景：技术方案评审文档**
...Prompt共享库上线后的两个月里，被查看了将近600次，有20多个成员贡献了Prompt。
第四个月：处理深层阻力——技能焦虑
表层的阻力（习惯惰性、质量担忧）在前三个月基本化解了。第四个月，我开始正视那个更深层的问题：技能焦虑。
有一次团队聚餐，一个工作了8年的资深同事喝了点酒，说了一句话："你们说AI提效，提效之后用不了这么多人了，提的是谁的效？"
这句话说出了很多人心里的真实担忧。
我没有回避这个问题，在下次全员会上直接讲了我的看法：
AI会替代一部分工作，但会同时扩大另一部分工作的需求。 写CRUD代码的工作量会减少，但设计系统、做架构决策、理解业务需求的工作量不会减少——事实上，因为AI让实现变得容易，我们可以承接更多的业务需求，对理解业务和做决策的人的需求反而会增加。
然后我说了一件具体的事：我们有几个位置，专门留给愿意把一部分工作重心从"写代码"转向"AI辅助架构设计和技术决策"的同事。不是因为要裁员，而是因为我们真的需要有人做这件事。
这次对话的效果是，那个有焦虑的同事，后来主动找我聊了一次，讨论如何在自己负责的领域引入更多AI工具。他的焦虑没有完全消失，但变成了行动力。
第五个月：量化效果，让数据说话
到了第五个月，我们开始尝试量化AI使用对团队效率的实际影响。
我设计了一个简单的追踪机制：每个Sprint结束时，每个成员填一份简短的自评表，记录本Sprint里有哪些任务用了AI辅助，主观估计节省了多少时间。
数据不精确，但可以看出趋势。
五个月的汇总数据（团队10人）：
| 任务类型 | 使用AI的比例 | 主观估计节时 |
|---|---|---|
| 代码编写（新功能） | 85% | 平均节省30% |
| Bug排查 | 70% | 平均节省40% |
| 技术文档撰写 | 90% | 平均节省50% |
| 代码Review | 60% | 平均节省20% |
| 架构方案讨论 | 45% | 平均节省15% |
这些数据在第五个月的全员会上公布了。看到数字的时候，几个本来使用率偏低的成员问了一个问题："代码Review用AI辅助怎么做？"——他们被数字激励了，开始主动学习其他人的做法。
第六个月：建立"AI工程师"这个角色认知
最后一个月，我做了一件很多人觉得"有点虚"的事：我们专门组织了一次讨论，讨论"在我们团队，AI工程师意味着什么"。
不是在讨论职位要求，而是在讨论一种工作方式和价值观：一个AI工程师，应该能判断什么时候用AI比不用AI效果更好，知道AI的边界在哪里，并且能设计出让AI持续发挥价值的工程体系。
这个讨论对技能焦虑的同事有一个很微妙的作用：它把"会用AI"重新定义为了一种需要经验和判断力的高级技能，而不是"谁都会的傻瓜操作"。
一个有8年经验的工程师，他在判断"这个场景适不适合用AI"和"这个AI输出有没有坑"上的能力，远强于一个2年经验的新人。AI工具让经验的价值更突出，而不是更弱。
这个认知上的重新定位，是整个半年里最难做到、也是最重要的一步。
回头看：什么起了作用，什么没起作用
起作用的事：
- 从展示开始，而不是从要求开始
- 用真实工作问题，而不是例子题目
- 把AI使用融入现有工作流（PR描述、code review），而不是单独的工具
- 直面技能焦虑，而不是回避它
- Prompt共享库——降低了上手成本，让技巧可以传播
没起作用的事：
- 一次性的培训课（大家听了就忘了）
- 硬性要求"必须用AI"（只会催生应付行为）
- 用别人的成功案例来激励（"别的团队这样用很好"，大家会说"我们团队不一样"）
如果让我提炼一句话：AI素养建设本质上是一个习惯养成问题，不是知识传授问题。改变习惯需要动机、环境和正向反馈三要素同时到位。