你们公司里，多半也有这么两拨人：一拨恨不得把所有活都甩给 AI，一拨一提 AI 就皱眉头，觉得早晚要出事。这两拨人到底各自在怕什么，怎么不靠「让其中一边闭嘴」来收场，是件值得想清楚的事。

很多人把这种分歧看成观念之争，说一个激进一个保守，一个爱赶时髦一个守旧。我以前也这么看。后来读到 Charity Majors 的一个角度，才觉得这么理解太浅了。

Charity Majors 是软件可观测性（observability，简单说就是让工程师能看清线上系统到底在出什么状况）公司 Honeycomb 的联合创始人兼 CTO，常年跟「系统会不会崩、为什么崩」打交道。她写了一篇，被资深开发者 Simon Willison 在6月初转出来，标题挺有意思：AI 乐观派在跟时间赛跑，AI 怀疑派在跟「熵」赛跑。熵这词听着玄，说人话就是系统会自己慢慢烂掉、越来越乱。

她的意思是，挺 AI 那拨人，真正怕的不是落伍，是被甩开。他们看到的是能力一截一截往上跳，觉得这回不是平常那种「等技术成熟了再上车」的周期。等你慢悠悠看清楚，公司可能没熬到尘埃落定那天就先出局了。这种怕，是真的。

而怀疑那拨人，怕的根本不是同一件事。他们怕的是系统烂掉、最后没人兜得住。

这里 Majors 有个比喻我觉得特别准。当出活的速度快过工程师能读懂代码的速度，你其实是在从一个攒了好几年的「信任账户」里取钱。一开始账户厚，随便取，看着没事，跑得还飞快。可你取的是什么呢？是可靠性，是「这套系统当初为什么这么设计」的那点家底。等哪天线上炸了，半夜被叫起来救火的人翻遍代码，发现没人真懂这套东西是怎么长成现在这样的。账户早空了。

所以你看，这压根不是谁对谁错。两边都没错，Majors 自己也是这么说的，乐观派没错，怀疑派也没错。他们只是各自死死盯着一个真实的风险，而这两个风险不是一个。一个盯着「太慢会死」，一个盯着「太快会烂」。

真正的麻烦在更深一层：两拨人之间，没有一条天然的线把他们连起来。

Majors 点出的那个关键，我反复想了好几遍。好处和代价，落在了不同人头上。出活快的人拿到的是「快」的好处，被看见、被夸、绩效漂亮；收拾烂摊子的人扛的是「乱」的代价，半夜爬起来救火，还落不着什么功劳。爽的是一拨人，疼的是另一拨人。

这就是为什么两边都觉得自己受了委屈、声音没人听。快的人觉得「我明明在救公司，你们老拖后腿」，兜底的人觉得「我明明在防着塌方，你们看不见」。Simon 把这事往前推了一句，说它其实是个挺迷人的「组织设计问题」，缺的那条反馈回路，是可以被设计出来的，不是靠谁让步、谁认输。

这话我信。因为这不是态度问题，是结构问题。光劝大家「多理解理解对方」没用，疼和爽分在两本账上对不平，理解就是空话。

那能做什么？Majors 给了几个挺实在的动作，核心就一条：让两拨人能互相看见对方的代价。

一是讲事别只讲一半。报喜的时候，把代价一起摆出来，主动问一句「我这么干，给你们那边留下了什么麻烦」。尤其两边有权力差的时候，比如资深对新人、被老板力推 AI 的团队对默默兜底的团队，越是处下风的那方越不敢开口，越得主动去请他们说。二是别把它吵成「该不该用 AI」的立场辩论，那个吵不出结果，换成一个工程问题：要让这事既快又不塌，到底需要什么。三是所有争论都摁在真实的东西上，真实的线上数据、真实的事故、真实的代码，而不是各凭感觉对喷。

我不敢说这套框架能套上所有团队，每家的人、活、节奏都不一样，硬套大概率水土不服。但它至少把吵架的题目换了，从「你错我对」换成「这笔账怎么对平」，火气能下去不少。

顺便说，大家觉不觉得这位分享的大佬很像赛博朋克？

#马力的AI知识分享#
#马力在记录AI领域500位大佬的分享#