亚马逊CTO劝企业别急着上AI：先想清楚要解决什么

恐惧是一种糟糕的决策方式。亚马逊CTO Werner Vogels提醒，企业担心错过AI窗口时，越着急越要先想清楚：究竟要解决什么问题，AI能帮什么忙。他表示，企业不会因为此刻没用上AI就立即倒闭，决策前应让工程师和管理者充分学习技术能力。

Werner以2004年亚马逊数据库故障为例：圣诞购物季共享磁盘故障持续12小时，损失数百万美元。供应商却称“你们应该做好测试”。团队随后调查发现，约70%的关系型数据库场景只需键值访问，于是构建了Dynamo，即DynamoDB前身。他借此提醒，当年大家拿关系型数据库当大锤，如今大模型也容易成为顺手的锤子。企业应先看任务本身，图像识别、语音处理、预测等领域早有有效方法，未必要追榜单第一名。基准测试与真实业务有距离，若模型已够用，为更高排名付钱需重新掂量。

Werner看重云计算带来的经济模式改变：过去企业软件常需签五到十年合同，像进餐厅先放一千美元不退款；云计算把资源使用量与付费联系，让“缩容”有意义，成本进入架构讨论。AI时代这笔账又有新项目：智能体若每次工作前扫描全部知识，开销很大；编程工具重启后重复加载项目内容，用户等于为准备工作重复付费。Kiro的跨会话记忆正是为减少重复劳动。他还提到，有些客户经实验发现更小模型已满足需求，成本低得多，开放权重模型如DeepSeek、通义千问、Kimi值得关注。

Agent代表用户行动，模型出错会变成真实后果。Werner愿意让Agent改签车票，但要求系统知道如何操作、记住偏好并受约束。他举例，用户可规定Agent每天花费不超过100美元，超出需人参与决策。亚马逊为Agent设计规则执行机制，检查其访问工具、运行脚本等操作，限制在客户授权范围内。面对约束是否拖累效率，他先谈责任：“你构建它，你就对它负责。”开发者必须能控制Agent，系统行动是否越界最终需人负责。他把AI信任放回分布式系统经验：工程师从不假定组件永远可靠，才对单组件保持警惕，进而信任整个系统。

Lambda早期为隔离客户使用虚拟机，对函数任务太大、成本高，后通过Firecracker做成更轻的微虚拟机提高利用率；冷启动则用SnapStart保存已初始化环境快照减少准备开销。Werner称这些为“看不见的工程创新”。Agent进入业务同样需要明确权限限制、异常处理和任务委托范围。

谈到初级工程师，Werner称亚马逊招聘数量与过去一样。新人加入S3团队可能面对二十年前代码，学校难提前教会。他看重好奇心、学习能力和开源经历。AI可帮新人解释团队规则，Kiro强调规格说明驱动，开发者先交代需求、架构和规则再让系统工作。但AI生成代码速度上来后，团队理解检查速度未必跟得上。他提到“验证债”：AI生成代码中有些部分未经验证，团队需按风险安排检查。界面偏几毫米与可能泄露客户信息的代码后果相差甚远。团队容易增加代码产量，但能否理解并承担后果需另外衡量，否则今天省下的时间会在排查返工中花掉。这也是他坚持让初级工程师阅读代码、与资深工程师一起审查讨论的原因。经验没有压缩算法。