10 月 14 日，我在深圳参加了一场对亚马逊 CTO Werner Vogels 的媒体群访，并问了他一个关于人的问题：AI 越来越会写代码，应届生、初级工程师怎么办？
在我看来，Werner 算不上 AI 的狂热拥抱者——他一向比较审慎，也一直强调人的价值。
但企业还招不招新人，是一道更加客观的选择题。真正的理性派，会将对 AI 的判断反映在实际的招聘动作中。
“我们招聘的初级工程师数量与过去一样，并没有出现这种紧缩。”Werner 回答。他接着谈了持续开放招聘的原因。在他看来，新人进入团队后，不光是要写代码，还要学习与别人协作，理解复杂系统，以及判断哪些 AI 生成的代码需要仔细检查。
一、代码容易生成了，协作仍是基本功
Werner 用亚马逊云科技存储服务 Amazon S3，解释一个新人进入大型研发团队后会遇到什么。
这个系统已经运行二十年。新人加入后，可能需要接触二十年前的代码，在已有系统上继续开发。“没有哪所大学会专门训练学生做这件事。”他说。
这类工作需要掌握的东西，远超一个功能怎样实现。新人要理解现有设计，熟悉团队的开发规则，也要知道自己的改动会影响哪些部分。这些都需要在工作中学习，和同事一起完成。
“开发者也是协作者，你需要成为团队的一部分。”
他还说，如果一个刚毕业的人参与过开源项目，会得到额外的认可，因为这意味着他与别人共同工作过，代码也接受过其他人的审查。
Werner 对协作能力的强调超出我的想象。但在他的描述里，个人的技术能力需要通过共同工作发挥作用。写出的代码，要能被别人理解、接手和维护。
其实从 Werner 的位置看，这种判断很容易理解。
小团队从零开发一个产品，与大型团队维护长期运行的系统，是不同的工作情境。后者有大量已经存在的设计和约束，一个模块也往往与其他模块相关。工程师需要考虑自己的实现怎样进入整个系统。
大公司涉及的开发者更多。理解别人的要求、解释自己的选择、接受代码审查，都是完成任务的一部分。
AI 正在进一步放大这种能力的价值。
AI 时代，生成代码正在变得越来越容易。但代码进入团队之后，仍要经过讨论、修改和整合。它是否符合项目要求，是否影响其他模块，同事能否继续维护，都需要有人理解和处理。
我更愿意把 Werner 的回答理解为一种对新人能力的提醒：除技术基础之外，初级工程师还要学会让自己的工作成为团队可以使用的成果。
二、从实现功能，到判断什么是好的实现
此外，面对 AI 生成的代码，开发者也需要作出自己的技术判断：这段实现有没有问题，什么地方必须检查，还有没有更好的方案？那些尚未得到验证的内容，Werner 将其称之为“验证债”。它与技术债相似，都是开发过程中留下的待办事项。同时意味着，团队可能尚不清楚其中存在什么问题。
Werner 谈“验证债”时，提供了一个观察角度。
过去，开发者输入编译器的是精确的编程语言。现在，人们用自然语言提出要求，描述中难免存在模糊和遗漏，生成结果仍然需要检查。如果全部逐一检查，速度又会慢下来。
他的建议是识别风险，优先验证关键部分。涉及安全、个人身份信息的代码，需要重点审查；一些界面细节，可以通过查看实际效果来判断。
“你不一定要审查所有内容，但必须验证风险最高的部分。”
对初级工程师来说，难点在于能否识别问题。
Werner 没有在采访中开出一份基础知识清单，我个人将其理解为一种对代码的审美。
Werner 说，他审查人写的代码，经常会感叹：“哇，你怎么做到的？这是个非常有创意、很漂亮的解决方案。”在他看过的 AI 生成代码里，他还没有产生过同样的感受。
这部分透露了他欣赏什么：开发者充分理解问题，并找到了一个巧妙、优雅的解决办法，也就是很多中国工程师所熟知的“代码之美”。
对于初级工程师而言，他需要先学习判断一段代码、一个模块，尝试找到更好的解法；随着“技术阅历”的增加，开始考虑服务之间的关系，以及整个架构如何取舍。
三、未来人人都需要一个 PhD 吗？
要理解系统、识别风险，还要判断方案好坏，以及对生成式 AI 有所了解，年轻人需要学习的东西似乎越来越多。我追问 Werner：大学计算机专业已经有很多课程，未来是不是人人都需要一个 PhD，才能完成这些工作？
“希望不是，否则我就要失业了！不，绝对不是。”他回答。
他谈到，业务人员已经可以为自己的工作生成应用，普通人也能做一个管理家庭日程的小工具。这些应用的使用范围有限，对开发者的要求，与维护大型系统不同。
在专业工作中，AI 也可以承担一部分准备工作。例如，安全工程师处理工单，需要收集日志和事件信息。Agent 可以在既定权限范围内整理这些材料，再交给工程师作决定。
Werner 补充了一个很传统的路径：坐在资深工程师旁边，一起审查代码，一起看发生了什么。他强调，初级工程师要成为资深工程师，就必须真正阅读代码，理解什么是重要的。
AI 有机会让这个过程更有针对性。
他认为，Agent 可以承担部分解释工作，告诉新人团队为什么采用某种方式，以及自己的方案哪里不符合既有规则。资深工程师不必为每一个相同的问题重复讲解。
某种程度上，这比要求年轻人不断增加学历更有现实意义——其实企业已经积累了大量知识，新人成长所需要的上下文也就具备了，我们只需要将其整合进培养流程里。
四、云计算、开放模型与中国见闻
除了开发者，这场群访还谈到了云计算二十年、企业采用 AI 的成本、中国开放模型，以及 Werner 此次中国行看到的应用。
云计算二十年，他最自豪的是经济模式的改变。
Werner 回忆，过去想降低数据库成本，往往需要签订五年、十年的合同。未来需要多少资源尚不清楚，钱却要先付出去。
他用吃饭作比喻：去餐厅之前，先往桌上放一千美元，没吃完也不退钱。这样的安排让客户很难掌握自己的支出。
按实际使用量付费，让成本进入日常的架构讨论。扩展也包括缩容，夜间没有那么多需求，就可以减少资源。
他举例说，业务部门可能希望所有服务都达到“四个九”的可用性，但看到成本之后，又会重新考虑。结账和购物车，与一些辅助功能，对可靠性的要求未必相同。技术人员需要和业务部门一起决定，哪些投入值得。
谈到未来的工作，他提及多区域部署、安全，以及后量子密码技术的准备。对于需要长期保密的数据，企业还要考虑“现在收集、以后解密”的风险，迁移也需要提前规划。
另外，企业采用 AI，要注意计算完整收益。
Werner 提醒，企业希望 AI 提高效率，但系统本身也可能带来额外支出。如果成本更高，效率提升的收益可能就没有了。
他也希望企业考虑营收这一面：AI 能不能帮助开发客户需要的新产品？要回答这个问题，先要清楚自己想解决什么，以及当前的 AI 是否适合。
对于企业的紧迫感，他建议先花时间学习，不要仅仅因为担心错过就作决定。他还提醒，AI 不等于生成式 AI，图像识别、预测等领域已经有大量成熟方法，选型仍应围绕任务和成本。
他也谈到了开放模型的创新价值，以及对模型排名的审慎看法。他肯定 Kimi 的技术工作，也质疑对模型排名的过度关注。
被问及中国开放模型时，被问及中国开放模型时，Werner 谈到了开放模型在推动技术创新方面的价值。Werner 特别提到 Kimi 底层的 Mooncake 架构，称相关工作“非常令人印象深刻”。
他看重开放模型降低创新门槛的作用：“每个人都应该能创新，而不只是财力最雄厚的人。”能够获取权重，也让使用者有机会自行运行模型。
对于基准测试，他则保持怀疑：“它们是人为构造的测试，不是真实生活。有时，模型足够好就够了。你真的需要排名第一的模型吗？”
按照他的观察，一些客户从昂贵的大模型起步，经过实验，发现较小的模型已经足够完成任务，成本也低得多。他希望客户持续实验、测量和学习，而不是一次选型就停止比较。
来自中国的 AI 应用，让他感到乐观。
此次中国行，Werner 参访了“大米和小米”。按照他的介绍，这家儿童干预机构利用视频分析辅助观察孩子的进展，向治疗师提出课程和干预建议，由治疗师决定采纳哪些内容。机构还把专业知识用于支持家长的应用。
让他印象深刻的，是技术帮助治疗师减少事务性负担，把更多精力用在孩子身上。他也提到，参访时看到的猫形互动玩具，以及中国将物理 AI 融入日常生活的探索。
“语言不只是词语，里面还有文化。”在他看来，技术需要用符合当地习惯的方式与人交流，才能获得信任。
这些回答，多少给出了 Werner 评价 AI 的一些具体尺度：成本是否合理，工具是否适合任务，以及使用者能否从中受益。