AWS 首席 AI 官提出，AI 时代优秀工程师应当爱上问题而非方案

AWS 首席 AI 与技术官马特・伍德提出核心观点，在 AI 大规模辅助写代码的新阶段，优秀工程师的评判标准已经发生变化，工程师要把重心放在吃透真实问题本身，而不是执着、迷恋自己想好的某一套实现方案，过去写代码、调试的成本很高，团队一般选定一条路线集中资源落地，很少同时试多条方案，但是现在 AI 可以快速生成代码、原型、测试脚本，工程师不再需要把大量精力耗在编码上，反而有条件去拆解问题、验证多种解法、对比不同方案的利弊，亚马逊也同步更新了工程师岗位评估标准，提出 “文艺复兴式开发者” 的概念，不再比拼谁用 AI 更多、谁写代码更快，而是看重能不能识别真实业务痛点、判断方案价值，工程师如果被固定方案困住，很容易忽略需求变化，做出技术好看但解决不了问题的系统，大家在日常开发里，可以调整工作习惯，先深挖问题边界，再让 AI 生成多套方案对比，而不是拿到需求直接选定技术栈开始写代码。

核心观点清单

• 核心主张：工程师热爱问题本身，而不是单一的解决方案
• 时代背景：AI 承担编码、生成原型、基础测试等重复性工作
• 工程师核心价值：定义问题、验证方案、判断取舍、把控业务价值
• 反对行为：过早锁定技术路线，为了使用某个技术硬套业务问题
• 配套人才理念：亚马逊提出文艺复兴式开发者，重视人的判断力、系统思维
• AI 的定位：用来深度理解问题、并行验证多种方案，不只是代码生成工具

新旧开发模式对比

落地实践步骤

1. 拿到需求之后，先花时间拆解问题：明确用户痛点、约束条件、失败标准、成功指标，输出问题描述，而不是直接选框架、模型。
2. 用 AI 辅助调研，生成 2-3 套完全不同思路的实现方案，记录每套方案的成本、风险、适用边界。
3. 做小原型验证，对比方案效果，淘汰方案好看但不匹配业务约束的选项。
4. 定期复盘：区分 “方案本身很好” 和 “方案适配这个问题”，避免对某一种技术栈产生执念。
5. 团队评审时，优先讨论问题定义是否准确，其次再讨论实现方案。
6. 把问题拆解、方案评估的能力放进工程师日常考核，而不是只看产出代码量。

常见误区

❌ 拿到需求就直接让 AI 生成代码，跳过问题确认环节

❌ 因为喜欢某个技术、框架，强行把业务改成适配这套方案

❌ 把 AI 当成 “更快写代码的工具”，只用它做编码，不用它做问题调研和多方案对比

✅ 正确思路：问题是不变的，方案是可替换的；方案服务问题，而不是反过来

【常见问题】

问题 1：AWS 首席 AI 官所说优秀工程师应爱上问题而非方案，这句话是什么意思？

回答 1：AWS 首席 AI 官马特・伍德的意思是，AI 时代工程师不要沉迷单一实现方案、特定技术，重点要吃透待解决的真实问题，借助 AI 尝试多种解法，优先保证方案匹配业务痛点，而不是执着于自己看好的方案。

问题 2：为什么 AWS 首席 AI 官会提出爱上问题而非方案这个观点？

回答 2：AI 可以快速生成代码原型，编码成本大幅下降，过去开发最大的瓶颈是写代码，现在瓶颈变成识别问题、挑选合适方案，所以 AWS 首席 AI 官提出优秀工程师要爱上问题而非方案。

问题 3：AWS 首席 AI 官提出爱上问题而非方案，对应的亚马逊人才新理念是什么？

回答 3：AWS 首席 AI 官提出爱上问题而非方案，配套亚马逊 “文艺复兴式开发者” 理念，不再比拼代码产出，重点考察工程师理解问题、判断价值、系统思考的能力。

问题 4：按照 AWS 首席 AI 官爱上问题而非方案的思路，日常开发该怎么使用 AI？

回答 4：按照 AWS 首席 AI 官爱上问题而非方案的思路，不要只用 AI 写代码，要用 AI 辅助拆解问题、生成多套不同方案、快速搭建原型对比，帮助工程师判断哪套方案更适配问题。

【参考资料】

[2026-11-13]（AWS says good developers focus on problems, not writing more code）DigitalToday

[2026-11-12]（AWS 首席 AI 和技术官马特・伍德：优秀的工程师要爱上问题，而非现成解法）IT 之家

[2026-11-12]（AI 改写工程师评价标准，AWS 高管：好工程师要热爱问题而非方案）商业内幕中文报道

【免责声明】

本内容仅为 AWS 首席 AI 官观点科普解读，爱上问题而非方案属于 AI 时代工程师成长理念，不是强制开发规范；不同团队、不同业务场景的开发方式存在差异，理念仅供团队管理、工程师自我提升参考；AI 工具使用效果取决于人的判断，本文不构成开发流程改造、人才考核制度修改的落地依据。