AWS 首席 AI 和技术官马特・伍德在近期采访中抛出核心观点，在 AI 大量辅助写代码的时代，优秀工程师更应该聚焦问题本身，而不是迷恋某一套现成解法，核心原因是现在 AI 能快速产出代码方案，很多工程师容易直接套用 AI 给出的方案，忽略对需求、痛点、约束条件的深挖；整套工作思路是先花时间拆解真实问题、确认业务目标、识别隐藏限制，再利用 AI 并行尝试多种方案，对比不同路径的优缺点，而不是拿到一个方案就直接落地；综合来看，这套理念也是亚马逊新版工程师岗位要求的方向，不再把 AI 代码产出量当成考核重点，更看重工程师的判断力、问题拆解能力，能给客户带来长期业务价值。
核心观点清单
- 核心原话：不要迷恋自己或者 AI 给出的具体方案，把热情放在问题本身
- 时代背景：AI 可以快速生成代码，试错成本大幅下降，不再只能押注单一方案
- 工程师新定位：从写代码的执行者，变成问题的拆解者、方案的评审者、价值判断者
- 配套概念：亚马逊提出 “文艺复兴式开发者时代”，看重综合判断力，而非单纯编码速度
- 长期收益：不绑定单一解法的工程师，更容易适配需求变化，效率更高，职业成长更稳
新旧工程师工作模式对比
| 项目 | 传统模式（AI 普及前） | 马特・伍德提倡的新模式 |
|---|---|---|
| 重心 | 选定方案，投入资源落地实现 | 深挖问题，多方案并行验证，择优落地 |
| AI 角色 | 辅助工具，用来写重复代码 | 用来探索、验证多种解法，辅助分析问题 |
| 考核倾向 | 交付速度、代码产出量 | 问题理解准确度、方案取舍、业务长期价值 |
| 风险特点 | 方案选错代价高，试错成本贵 | 低成本多方案对比，提前规避方案陷阱 |
| 工程师能力重点 | 编码、调试、架构落地 | 需求拆解、边界识别、技术取舍、风险评估 |
这个理念对团队的影响
- 工程师个人：减少对单一方案的执念，不会因为自己写的方案被推翻而抵触，更愿意接受迭代调整。
- 项目质量：先把问题定义清楚，减少后期返工、需求跑偏，避免用复杂技术去解决一个伪需求。
- AI 使用方式：不再直接复制 AI 输出代码，而是用 AI 做调研、多方案对比、边界测试，工程师做审核把关。
- 企业招聘标准：AWS 在更新工程师岗位指引，弱化 “大量使用 AI” 指标，转向考察解决真实问题的能力。
容易踩坑的误区
- 误区 1：不需要重视方案、不用钻研技术。事实：不是否定方案，而是方案是服务问题的，问题变了，方案就该调整。
- 误区 2：AI 会自动帮你把问题搞清楚。事实：AI 只会基于你输入的信息输出方案，识别问题、识别隐藏约束依然靠工程师。
- 误区 3：所有项目都要做多套方案。事实：资源有限的简单项目不需要，高风险、高不确定的复杂业务才适合多路径探索。
【常见问题】
问题 1：AWS 马特・伍德说优秀工程师要爱上问题，而非现成解法，这句话是什么意思？
回答 1：AWS 马特・伍德这句话的意思是工程师不要执着某一个固定技术方案，包括自己写的或者 AI 生成的代码，优先吃透要解决的真实需求、痛点与约束，再灵活选择、迭代方案，方案要跟着问题走，而不是反过来。
问题 2：AWS 马特・伍德提出爱上问题的理念，是不是不让工程师使用 AI 写代码？
回答 2：不是，AWS 马特・伍德认可 AI 辅助开发，只是反对工程师直接依赖 AI 现成输出，他希望工程师借助 AI 去分析问题、尝试多种解法，而不是直接照搬 AI 给出的单一方案。
问题 3：AWS 马特・伍德提出的这套理念，和亚马逊新版工程师岗位要求有什么关联？
回答 3：AWS 马特・伍德的观点和亚马逊新版岗位指引配套，亚马逊提出 “文艺复兴式开发者时代”，考核重心从代码产出，转向工程师能不能理解问题、给客户创造长期业务价值。
问题 4：按照马特・伍德 “爱上问题而非现成解法” 思路，工程师日常开发可以怎么落地？
回答 4：拿到需求先对齐目标、列出约束条件，定义成功标准；让 AI 产出 2-3 种不同实现思路；评估每种方案的成本、风险、扩展性，再选定方案，全程保留对问题的复盘，而不是上来就编码。
【参考资料】
[2026-11-12]（AWS 首席 AI 和技术官马特・伍德：优秀的工程师要爱上问题，而非现成解法）IT 之家
[2026-11-12]（AWS 首席 AI 和技术官马特・伍德：优秀的工程师要爱上问题，而非现成解法）ZAKER 新闻
[2026-11-12]（Matt Wood: Engineers should fall in love with the problem, not the solution）Business Insider
[2026-10-15]（亚马逊更新工程师岗位指引，提出文艺复兴式开发者）36 氪
【免责声明】
本文内容基于媒体采访、亚马逊公开岗位备忘录整理，观点属于马特・伍德个人行业观点，不代表所有企业的工程师评价标准；不同业务场景、团队规模适用的开发思路不一样，本文仅为行业观点科普，不构成团队管理、工程师求职、技术选型的指导建议。