亚马逊 CTO 十月回中国：把 Werner 三问做成中国企业 AI 诊断量表

处置建议：AI 项目立项时同步立一个「组织减法项」——每引入一个 AI 工具，必须承诺至少砍掉一个原有的审批节点、一份重复的日报、一个跨部门协调会。把「组织减法」和「AI 上线」写在同一份 kickoff 文档里，而且必须由一个业务侧的负责人签字，而不是让 IT 部门自己签。这个签字机制是关键：如果一个 AI 项目在业务侧找不到人愿意签字做减法，说明业务侧并不真的相信这个工具能替代旧流程，所谓的效率承诺是虚的。这一条对中国的大型国企央企尤其重要——过去几十年沉淀的审批与汇报链条已经很密，AI 工具最容易在这套链条外面再新增一层，而不是替换掉其中任何一层。

判断题三：范式之问——你选这条技术路径，是最优解，还是随大流？

自检问句：你正在投的这条 AI 技术路径，是因为它是这个场景的最优解，还是因为「大家都在跑这条路」？

通不过的典型表现：在给董事会做 AI 战略汇报时，全篇是「行业普遍在做 X」「头部大厂都在跑 X」「不做 X 就会掉队」；对场景本身要什么、约束在哪里、有哪些替代路径可选，没有做过认真评估。Werner 那篇 Pong 的博客其实是在提示一个非常朴素的东西：一个技术路径的选择应该被具体的约束和收益决定，而不是被舆论热度决定。中国企业里最典型的「随大流」是过去一年半在 vibe coding、Agent 平台、大模型微调、私有化部署、RAG 系统这五个热点上的反复迁移——同一家公司往往在 12 个月里换了三次技术栈，每次都是被「大家都在做」推动，而不是被自身的场景收益推动。

处置建议：在每一次 AI 战略汇报的开头强制回答三个问题：这个场景的正确性要求是什么？这个场景的成本约束是什么？我们评估过哪些非 LLM 的替代方案，为什么选了 LLM？前两个问题是场景本身的边界，第三个问题是路径合理性的对照。如果第三个问题的答案里没有出现规则引擎、传统统计、图数据库、专家系统、边缘计算这类候选，说明评估过程根本没做——真正做过评估的项目会知道每一条替代路径的价签在哪里、为什么被排除。这个 checklist 的作用不是逼你不用 LLM，而是逼你说清楚为什么用它。

用量表照一照当下的四类中国 AI 项目

把三问量表拿出来照下面四类今天在中国最常见的 AI 项目，会得到相当不同的结论。

第一类：「大模型接入」型项目。特征是把一个基础模型接进企业的某个业务系统，做一些浅层的 prompt 工程和 RAG 增强，然后作为「AI 助手」推出。三问过关情况：验证之问基本不需要——多是可撤销的低风险决策；组织之问几乎全数不过关——上线后没有任何流程被简化，反而多了一个新的对话入口；范式之问也大多不过关——因为选 LLM 是默认选项，从来没有评估过。诊断结论：这类项目短期看不出问题，但一年后大概率会被下线，因为它没有替代任何东西，只是叠加了一层新的界面。

第二类：面向企业内网的自研 Agent 平台。特征是搭一套多智能体框架，声称可以让每个部门配置自己的 Agent 处理具体任务。三问过关情况：验证之问部分不过关——大多数 Agent 直接执行动作，没有独立验证层；组织之问部分过关——如果 kickoff 时同步做了减法，可以真的替代掉一些人工流程；范式之问是最大的失分项——绝大多数项目用 LLM 是因为「Agent 就该用 LLM」，从来没有考虑过基于规则的 workflow 引擎能否更便宜地解决问题。诊断结论：这类项目值得做，但必须在立项时补上验证层和替代方案对照。

第三类：医疗、金融、自动驾驶三条线的高风险 AI。特征是决策直接影响人命、资产或人身安全。三问过关情况：验证之问是最大的死结——绝大多数项目缺一个独立于模型的可审计验证层；组织之问因为监管强制往往做得不错；范式之问因为场景要求苛刻反而做得最认真。诊断结论：这类项目是三问框架最能救命的地方——一个没有独立验证层的高风险 AI 项目在监管重压下上线就是在赌博，而且赌局的赔率非常不对称。

第四类：县城医院、农业大棚、社区养老院这类朴素技术项目。这是 InfoQ 那篇文章里点到但没展开的一块。特征是用非常朴素的技术（往往不是 LLM）解决一个具体的、每天都在发生的问题。三问过关情况：三问几乎全部天然过关——因为立项动机来自「问题驱动」而不是「恐惧驱动」，选型时会本能地做替代方案对照，上线后一定伴随流程简化，验证层往往是熟悉一线的从业者本人。诊断结论：这类项目在董事会 PPT 里不好看，但在 Werner 的三问框架下是最健康的一档。中国 AI 叙事里这一档常年被忽略，一部分原因是它们不出发布会。

三问框架的边界：Werner 也不是全知的

用完这份量表，还需要说清楚三问框架本身的边界，否则会滑进另一种「拿一位外国 CTO 的话当圣经」的陷阱。

边界一：三问框架系统性低估了「模型规模化本身带来的能力涌现」。Werner 那篇 Pong 博客里用 700 瓦对 20 瓦的对比来质疑大模型路线是否过于依赖规模。这个类比在能耗账上是成立的，但在能力账上有偏差——人脑打 Pong 靠的是几亿年的进化和几十年的学习积累，把这份「预训练成本」摊到「玩一次 Pong」上，能耗账并不那么好看。当下大模型路线的关键论据不是「更节能」而是「同一份权重可以解开多类问题」，Werner 的对比没有正面处理这一点。管理者用他的框架照自己项目时，要提防把这条判断当成「不要用 LLM」的普适结论。

边界二：三问框架来自一个「已经过度供给」的市场。Werner 说 AWS 让开发者不缺算力了缺时间，这个观察前提是硅谷和北美主流市场——那里的开发者确实已经跨过供给门槛。中国的情况更复杂：一线城市和大厂开发者确实过了这道门槛，但县级医院、中小工厂、非一线互联网公司的开发者面对的仍是「基础工具够不够用」的供给端问题。Werner 的框架在讨论「跨过门槛之后怎么办」时非常锋利，但在讨论「怎么帮更多人跨过门槛」时不是最合适的工具。中国管理者要清楚自己所在的层级是哪一档。

边界三：三问框架预设了「决策者有权力做减法」的组织环境。Werner 那段关于「熵在增长」的表述，隐含的假设是组织的一把手至少可以推动几层审批的精简。而在很多中国大型企业——尤其是国企、央企、上市公司——审批链条的存在本身就是合规产物，任何一层都对应着某个监管要求或历史事故的教训。想按 Werner 的建议在 AI 项目上做「组织减法」，管理者需要先识别哪些流程是可以砍的、哪些是不能碰的合规刚性。把这两类混在一起砍就是自找麻烦。

一句结尾判断

10 月 Werner 到访中国这件事本身不是新闻——一位外国 CTO 的行程从来都不该被神化。真正值得中国从业者花时间的，是他这一年公开留下的这份问题清单：验证、组织、范式。这三个问题在中国当下的 AI 叙事里被系统性地绕开——媒体在讲发布会、创业者在讲估值、大厂在讲能力涌现，几乎没有人在讲「怎么证明它是对的」「组织为此做了什么减法」「除了这条路还有别的选择吗」。把这三问做成一份可以对着项目勾选的量表，是中国 AI 项目决策今天最缺的一件事。做完之后你会发现，你手上一半的 AI 项目是恐惧驱动的、值得推倒；剩下的另一半是问题驱动的、值得加倍投入。这个鉴别过程比听 Werner 讲一场 Keynote 更值得。