软件工程已死。这是科技 Twitter 上那些声音最大的家伙们想让你相信的。他们分享 AI 工具通过一段简单的提示词就能生成完整应用程序的录屏，并质问为什么还要花钱雇人写代码。这种恐慌是可以理解的，但它完全没抓到重点。

AI 不是来取代工程师的。它是来取代那些误将打字速度当成技术判断力的人的。编码（coding）与工程（engineering）之间存在着巨大的鸿沟，而这个鸿沟正是整个职业存在的意义。

在你喝完一杯咖啡之前，AI 助手就能为你提供五种实现某个功能的不同方案。瓶颈已经转移了。我们不再盯着空白文件发愁如何开始，而是盯着五个看似合理的方案，思考哪一个在真实流量涌入时不会崩溃。这种决策过程才是工程。除此之外的一切都只是语法。

Demo 不等于产品

观看任何 AI 编程演示，你都会看到一个精美的界面在几分钟内成型。但你不会看到数据库连接池在负载下耗尽。你不会看到 API 端点缺失速率限制（rate limits）、缺乏审计日志，或者因为 AI 觉得把所有用户交互都存入对象存储桶（object bucket）很方便，而导致存储成本激增。

生产系统要求可扩展性、安全性、性能和成本控制。这些品质在冲刺评审（sprint review）中是看不见的。只有当真实用户带着他们不可预测的行为、边缘情况（edge cases），以及不按你预想顺序点击按钮的习惯出现时，它们才会显露出来。我见过太多 AI 辅助的项目，在 QA 阶段看起来一切正常，结果上线一周后就变成了昂贵的教训。

能运行的代码已经变得廉价，但优秀的工程实践并非如此。

现在什么才重要

在这场变革中蓬勃发展的工程师，并不是那些打字最快的人。而是那些在生成第一行代码之前，就知道该问什么问题的人。

  • 他们能清晰地定义问题。 如果你放任不管，AI 模型会很乐意去解决错误的问题。它会为一个仅供六名内部分析师使用的读密集型仪表盘构建复杂的缓存层。它不会停下来询问真正的核心问题是缺少数据库索引，还是数据模型本身存在根本性缺陷。优秀的工程师会不断重新定义问题，直到解决方案变得显而易见——无论这个方案是否涉及编写代码。

  • 他们能将大型系统拆解为微小的部分。 AI 擅长处理局部上下文。它可以编写单个函数、单个组件或单个测试。但它很难在脑海中构建起整个分布式架构。那些能够解构单体架构（monolith）、划定服务边界并定义团队间契约（contracts）的工程师，才是能将生成的代码片段转化为可持续系统的人。

  • 他们会质疑 AI 的建议。 模型的自信只是一种幻觉。它可能会提出忽略网络延迟的架构，推荐已经弃用多年的库，或者去解决需求中根本不存在的功能。