异构

一

这两年跟不同的人聊 AI 转型，越聊越有一个感觉：难，不是难在技术，是难在组织。

技术上其实没那么玄。模型摆在那里，工具摆在那里，文档也都能查得到。真正把人拖住的，是组织怎么消化这件事——领导想要的是什么、中层能推什么、基层用什么、成果怎么被看见。这几层之间，最近这一年多，我看到的是明显的脱节。

上层焦虑，很急，恨不得两三周就看到成果，不希望团队再花六个月憋一个大活。中层拿到指令，去拆解、去分组、去找方法论，试图组织一场自上而下的推广。到了下层，一线的人一边维护着自己那个又大又重要的老项目，一边被要求"用 AI 转型"，但转成什么样、怎么算成功、别人在做什么，其实心里都不太清楚。

结果就是，会开了很多、方向也定了不少、群里公告也发了，但真正的动能，往往并不在这些自上而下的动作里，而是在几个自己就先动起来的一线工程师那里。有意思的是，事后回头看，那些真正做出点意思的项目，几乎都不是方法论推出来的，是"某个人自己憋出来的"。

我一开始以为这只是执行的问题——是不是方法不对、是不是抽象层次没找准、是不是中层不够强。想了一段时间之后，我倾向于觉得，这不是执行问题，是范式问题。

二

我是学计算机出身，脑子里第一反应还是拿体系结构来比。

在很长一段时间里，计算机是"同构"的。往简单了说，就是一台机器里，所有的核长得都一样，跑同一套指令，遵守同一套规则。你要让机器更快，思路很清晰：把这颗核做得更快，或者多摆几颗一样的核。程序员不用太操心底下是哪一颗在跑，编译器和操作系统会替你安排好。

同构世界里的成功路径是很清爽的：找到一套最好的做法，把它推广到所有地方，越统一越高效。

后来这条路走到头了。原因很多，物理上、功耗上、workload 本身的分化上都有。总之，行业慢慢意识到，一颗"什么都能干"的核，越来越干不过一堆"各自只擅长一件事"的核。图形有图形的加速器，AI 有 AI 的加速器，信号处理有信号处理的，加密有加密的。一台机器里，同时躺着七八种完全不一样的计算单元，这就是"异构"。

异构一开始是很痛的。编程模型分裂，写一段代码不知道该跑在哪；调度变复杂，谁该干什么活得有人协调；抽象层难做，做薄了不好用，做厚了性能就飞了。曾经也有人幻想过银弹——搞一个统一的框架，把异构的差异全部藏起来，让程序员像以前一样写代码就行。这个梦做了很多年，也确实做出过一些东西，但整体上，行业最终接受了一个事实：差异是本质的，不是可以抽象掉的。

真正让异构跑起来的，不是消灭差异，是学会跟差异共处。共享一些接口，共享一些数据通路，共享一些工具链，但允许每种核有自己的运行时、自己的编译器、自己的最佳实践。中间层不再是"统一指挥"，更像是"负责撮合"——让不同的核能互相调用、能交换数据、能在需要的时候拼在一起干活。

回头看，这个转变很关键。它不是一个技术选择，是一个世界观的更新。

三

我越来越觉得，今天的组织，正好卡在同一个位置上。

经典时代的组织，也是同构的。业务模型定下来之后，大家的工作方式其实差别不大：都用同一套流程，都遵循同一套规范，都被同一套指标考核。领导层的工作，就是找到那套"最优做法"，然后借组织的力量把它推下去。你可以把这个想成 CPU 时代——一套指令集，全员对齐，谁不对齐谁掉队。

在那个时代，这套思路是真的 work 的。这不是嘲讽，也不是过时，是当时的最优解。过去很多年的赢家，肌肉记忆全长在这上面：定方法、推方法、评估方法、迭代方法。

AI 的到来，让这套肌肉第一次不太好使了。

不是 AI 本身反组织，而是 AI 让每个人的工作方式开始分化。同样一个需求，有人喜欢用 Copilot 写代码，有人愿意跟一个 agent 反复对话，有人干脆自己给自己搭了个小工作台，把常用的活儿全串进去；有人喜欢用一个大模型，有人喜欢混着几个模型用；有人写 prompt 像写诗，有人写 prompt 像写 SQL。这些做法之间，很难说哪个"对"，因为每个人手上的问题不一样、习惯不一样、审美也不一样。

放在一个团队里看，就是——每个人的 AI 架构都不一样。

这时候如果还用同构时代的思路，就会出问题。领导会习惯性地问：谁的做法最好？我们把它抽出来，推给所有人。中层就会开始张罗，找几个明星案例，抽象出一套"通用方法"，做培训、做规范、做检查。等真的推下去了，就会发现一件很尴尬的事：一抽象，就不 work 了。因为让那几个案例 work 的，恰恰是那个人的具体上下文、具体项目、具体口味。抽掉这些，剩下的东西谁都能听懂，但谁用了都不太顺手。

我甚至觉得，这就是 AI 转型这轮特别难的根本原因。不是路难走，是没有"一条路"。

四

那怎么办呢？

我最近比较相信的一个方向，还是从异构那一段历史里借来的：不追求消灭差异，追求让差异之间能连起来。

具体到组织里，我大致能想到几件事。

一件是允许多种做法长期共存。别急着评"哪种做法是团队标准"。在异构还没稳下来之前，任何评标都是过早的收敛。让不同的人用不同的方式干一段时间，先看看什么样的问题被解决了，再回过头看方法本身。这需要中层顶住"统一"的压力——上面越焦虑，越会催着你出一个"我们团队的 AI 方法论"，但硬憋出来的这一套，多半推不动。

一件是把共享放在低层，而不是高层。同构时代喜欢共享方法论，异构时代更适合共享工具和接口。举个例子：连内部系统的那些管道、拿数据的那些通道、常用的那几个查询和跳板，这些做一次大家都能用，属于典型的"值得共享的低层"。至于每个人怎么用这些管道拼出自己的工作流，就别管了，那是高层，那是每个人自己的事。

一件是给一线的探索留出向上被看见的通道。这是我觉得最容易被忽略的一件事。在自上而下的推广模式下，一线摸索出来的东西，天然缺少向上暴露的路径——它不在 OKR 上，不在汇报模板里，不在项目立项流程里。于是往往就是同一个人在自己电脑上跑了半年，别人根本不知道有这么个东西。哪怕最后被看见了，也常常是靠饭桌上的一次偶然。这个损失挺大的，因为异构世界里，真正的进展往往就是这么冒出来的：一两个人先做出点意思，别人看到之后被激发，各自回去做自己的版本。

再一件是不要指望"一个平台解决所有问题"。这是异构世界里最容易犯的错，也是我自己反复提醒自己的一件事。做一个大平台，把所有人的工具都收进来、把所有的流程都串起来、把所有的数据都打通，听上去很美。但真做起来，就会发现每收一个进来，就要迁就它一次；每串一个流程，就要牺牲一点灵活性。到最后，平台越来越大，用起来越来越不顺，谁都不爱用。相反，做一个薄一点的东西，只负责"让别人的工具能被别人找到、能被别人调用"，反而更有生命力。有点像一个内部的市集，不是一个内部的工厂。

五

写到这里，我意识到自己并没有给出一个"答案"。

这可能就是异构本身的意思。同构时代的写作，很容易在结尾抛出一套方法——三步、五招、一个框架。异构时代不太行。你越是想给出一个统一的答案，就越会背离异构本身的精神。

我更愿意把这篇当成一次自我提醒。提醒自己，看到焦虑的时候别急着找方法论，看到方法论的时候别急着推广，看到别人的做法跟自己不一样的时候别急着评价。异构不是坏事，异构是这个时代的底色。承认这一点之后，很多事情反而会松动一点。

至于路怎么走，我倾向于相信一句老话：和而不同。每个人可以有自己的路，团队之间也可以有自己的节奏，只要底下的那些接口和管道是通的，整体就还是一个整体。乱一点没关系，繁荣本身就是有点乱的。

真正让我担心的，反倒不是异构，是我们下意识地还想把它变回同构。