在每个工程团队里，几乎都存在这样一个人——他们最先上手了 AI 编程工具，然后以肉眼可见的速度将其他人甩在身后。随着一两个人率先达到完全不同的产出规模，管理层自然会注意到，并试图弄清楚：这些人究竟有什么特别之处，能否将这种特质复制给全团队？
但问题来了——这些突然"碾压"全场的工程师，未必具备某种可持续、可识别的特殊禀赋。对于工程管理者和公司高层而言，"找出特殊的人并推广他们的做法"并不是推动 AI 采用和提升团队生产力的最佳路径，甚至不是唯一路径。
不是角色分配，而是一条连续谱
Snowflake 工程高级副总裁 Vivek Raghunathan 在近期一期 Leaders of Code 节目中借用了强化学习中的一个经典划分：探索者（explorer） 与 利用者（exploiter）。
据其估算，工程团队中大约 5% 是无畏的"探索者"：他们迫不及待地想要实验、想要将 AI 工具推进到无人要求过的边界。这类人会闯进你的办公室，只为展示他们刚刚折腾出的新东西。剩余 95% 是"利用者"：他们对自主探索没有太大兴趣，只想要一条现成的、被铺好的路。Raghunathan 特别强调，这个词并非贬义——它只是描述一种真实且有用的偏好。
组织犯的错误，是将探索者/利用者之分当作非此即彼的二元划分，而非一条连续光谱上的不同位置。 目标不是将人简单归类为"特殊"与"不够特殊"，而是推动人在这条光谱上持续移动。Raghunathan 强调，管理层的真正目标应该是：让更多工程师在光谱的中游向上迁移，而非到公司外部去搜寻和招聘已经站在顶端的人。
为什么那些"显而易见"的做法行不通
你无法提前识别探索者。 那些晒出 100 倍效率提升的人，未必是引入 AI 工具之前最资深或最优秀的工程师。Raghunathan 指出，AI 正在放大的特质是好奇心、适应性和学习意愿，而非此前的资历或声誉。任何旨在识别最优秀工程师并让他们优先获得 AI 培训的方案，从一开始就瞄错了人群。
只为利用者设计方案，会封住天花板。 如果整个 AI 战略就是给所有人一条现成的路然后收工，确实能抬高底线（这本身也很有价值），但你永远不会知道自家公司的"前沿"究竟是什么样子——因为没有人被给予空间去探索。
只为探索者设计方案，无法规模化。 相反的失败同样常见：管理层为少数做出惊人成果的人感到振奋，将整个 AI 叙事围绕他们构建，而团队中其余 95% 的人只是以略微提速的方式继续做着原来的工作。几个亮眼的案例故事无法真正提升组织的整体产出。
将问题归咎于招聘而非内部推动。 如果你的想法是"干脆去招聘更多 5% 的那类人"，Raghunathan 直言：你从外部识别人才的能力并不比内部更强。真正的杠杆是推动现有员工在这条光谱上持续前进。
真正需要做的事
让探索者自我浮现，并认真对待他们的发现。 Raghunathan 描述这类工程师很容易识别：他们会不请自来，坚称某件事很紧急，急切地想要演示他们周末折腾出来的东西。管理者的正确做法是将探索者的发现视为值得提炼和推广的原材料，而非仅仅表扬一番就翻篇。
建立缩小差距的机制，而不只是观察差距本身。 一旦你能说出探索者究竟在做些什么不同的事，工作就变成了：缩短信道中段与顶端之间的距离。具体手段包括：结构化的学习时间、建立围绕 AI 工具的实践社区、以及直接的师徒指导。指望人们通过"熏陶"自学是不现实的。
衡量人在光谱上的移动，而非只盯着异常值。 少数几个 100 倍的故事是好故事，但不是好指标。更有效的问题是：本季度有多少人向前移动了一个有意义的等级？有多少人还停留在六个月前的起点上？
给予利用者真正应得的认可。 95% 不是需要被解决的问题，他们是正确地将完成实际工作置于探索性折腾之上的大多数人。目标不是把他们变成探索者，而是确保他们依赖的那条"铺好的路"持续变得更好、更快——因为有人在替他们做探索。
值得管理层深思的问题
回到最初那一两个突然达到完全不同产出规模工程师的话题。诱惑是：将这些有潜力的样本放到显微镜下，分析和复制让他们特殊的品质。但这个策略是一条死路，因为很难预测哪些工程师会最终成为探索者。
真正的课题是构建一套系统，能够持续发现下一个探索者，将他们的发现转化为可传授的知识，并将团队整体向上推进——而不是坐等奇迹再次发生。
评论