亚马逊 CTO 的冷水：怕错过 AI，比错过更贵

每周都有新模型发布，于是每周都有人问同一句话：我们是不是已经晚了。一个做了二十多年 CTO 的人给的答案是：不会因为你今天没用上，明天就倒闭。

一、发生了什么

据量子位报道，亚马逊 CTO Werner Vogels 近日在深圳做了一场交流。他今年 68 岁，在亚马逊担任 CTO 超过二十年。

他开场就把话说得很直：恐惧是一种非常糟糕的决策方式。企业不会因为此刻没有用上 AI 就立即倒闭，所以在做决定之前，应该先让工程师和管理者把技术学明白，知道它到底能做什么。

为了解释这种"先缓一缓"的态度，他讲了 2004 年 12 月 12 日的一次事故。那天正赶上圣诞购物季，客户数据库背后的共享磁盘出故障，用户既登不上也下不了单，中断持续十二个多小时，损失数百万美元。供应商后来的回应是"你们应该做好测试"。

亚马逊没有继续争论，而是回头查了一件事：自己到底怎么用数据库。结论是约 70% 的关系型数据库场景只需要键值访问。顺着这个发现，团队做出了 Dynamo，也就是后来 DynamoDB 的前身。

他把这段经历直接套到了今天：当年大家拿关系型数据库当万能锤子，现在大模型很容易变成新的那把锤子。

做技术决策的人：三种恐惧最常见——怕落后、怕账算不清、怕出事没人担责。Vogels 对三者的回应是一致的：先把任务拆清楚，再选工具；先算单位成本，再谈规模；先划权限边界，再放它上线。

写代码的人：他提了一个词，验证债。AI 生成的代码有一部分没被验证过，团队省下的时间，会在后面排查和返工时还回去。界面偏几毫米和可能泄露客户信息，后果完全不是一个量级，检查精力要按风险分配。

普通员工：他并不认为 AI 会先把新人挤走。按他的说法，亚马逊招初级工程师的数量和过去一样。变的是入职之后——AI 能替你解释团队规则，但读老代码、跟人讨论、积累判断，这步没人能代劳。

先写清楚要解决什么，而不是要用什么模型。 他的问法是三连：企业想解决什么问题、AI 是否适合、当前这一代 AI 是否适合。图像识别、语音、预测这些领域早有成熟方法，不必都挤到大模型上。

算一次任务的真实成本，不是算 token 单价。 他提到有些编程工具重启时会重新加载整个项目，用户昨天为这些准备工作付过钱，今天再付一遍。除了模型报价，还要算重复劳动、人工复核、失败重试。

提前划定 Agent 能做什么。 他愿意让 Agent 帮忙改签车票，但要求系统知道怎么操作、记住偏好、并且受约束。他举的例子很具体：规定每天花费不超过 100 美元，超了就必须人来决定。

「不上 AI 就会被淘汰。」 这句话最大的问题是没法验证。Vogels 的判断是，急着上马往往带来更高的返工成本。真正该焦虑的不是时间点，是有没有把问题定义清楚。

「榜单第一的模型就是最好的选择。」 他对基准测试一直有所保留，理由是人为构造的测试和真实业务之间隔着一层。如果一个模型已经够用，为更高的排名多付钱，收益要重新掂量。他也提到，一些客户实验后发现更小的开放权重模型就能满足需求，成本低得多。

「模型够强，工程就不重要了。」 反了。他讲 Lambda 时提到，客户看到的只是一次函数调用，背后是隔离、资源分配、冷启动一堆细活。Agent 进生产环境也一样，演示跑通只是开始，权限、异常、失败恢复才是工作量所在。

AI 项目的成败，多半不取决于你选了哪个模型，而取决于你有没有先回答"这事该不该由它来做"。他还有一句话可以贴在工位上：经验没有压缩算法。

功能与价格以官方公告为准。本文写于 2026 年 10 月 17 日。