头条新闻不断告诉我们，AI 将使软件开发人员变得多余。我不相信。真正的风险不是机器将接管工程，而是工程师将不再愿意进行艰苦的思考。

软件开发从来不仅仅是输入语法。它始终关乎在脑中掌控复杂性、理解失效模式，并在没有完美选项的情况下进行权衡。AI 改变了我们编写代码的速度，但它并没有改变为什么我们需要“人在回路”中。如果说有什么变化的话，那就是它让清晰的思考变得更加宝贵，也更加稀缺。

初稿并不等同于工程

我观察到越来越多的初级开发人员将 ChatGPT 或 Claude 视为坐在旁边的一位高级工程师。他们粘贴工单描述，复制回复内容，运行测试，然后提交。只要代码能编译通过，任务就算完成了。这个闭环极快、毫无阻力，却也极其危险。

使用 AI 本身并不是问题。我也在用。我认识的大多数高效工程师都在用。问题在于，当 AI 成为房间里唯一的工程师时，麻烦就来了。仅仅因为一个方案可行就接受它，这不叫工程。这是将判断力外包给了一个既不了解你的用户、也不了解你的业务约束，更不知道你的技术栈上次在凌晨两点崩溃是什么情况的模型。

大语言模型即使在完全错误的情况下，也会以一种令人不安的自信给出答案。一位工程师曾要求 AI 设计一个可扩展的架构。模型返回了一份详尽且权威的提案，但该提案完全是围绕一个实际产品中并不存在的功能构建的。它看起来很正确，内部逻辑也自洽，但它毫无用处。危险不仅在于 AI 会产生“幻觉”，更在于现在有太多人开始信任这些幻觉，因为他们已经失去了识别谎言的上下文背景。

你在摩擦中学习

当我回想自己是如何从一名初级开发人员成长为能够掌控整个系统的人时，我记不起我背过的语法。我记得的是系统停机。我记得那些必须手动追踪的慢查询，那些只在生产负载下才会出现的竞态条件，以及因为本地环境与真实世界完全不同而导致部署失败的经历。

调试正是学习发生的地方。当你手动单步执行代码时，你会看到系统究竟是如何失效的。你会发现瓶颈出现在哪里。你会学习当架构从只有十个用户的演示环境转向处理一万个并发请求的生产系统时，它的表现会如何。你会从骨子里吸收生产环境与精心编写的演示环境之间的差异。

这些知识都不是通过接受一个生成的答案获得的。它们来自于与问题的搏斗。如果 AI 消除了所有的挣扎，如果它编写代码、修复 Bug 并解释失败的原因，那么下一代开发人员究竟该如何赢得他们的资深地位？经验不是可以下载的证书，而是在生产事故和部署失败中磨炼出的“疤痕组织”。剥离了摩擦，也就剥离了成长。

判断力胜过生成力

有一段时间，业界将提示工程（Prompt Engineering）视为简历上最热门的新技能。这完全误解了重点。在 AI 饱和的环境中，最有价值的能力不是生成选项，而是知道该拒绝哪些建议。

我合作过的最优秀的工程师并不写最多的提示词。他们提出最难的问题。他们知道重构何时会引入隐藏的依赖。他们能识别出生成的测试是否只覆盖了“快乐路径”（happy path），而忽略了可能损坏客户数据的边缘情况。他们可以看着一段完全合法的代码说：“这段代码是正确的，但架构是错误的。”

最后这句话是两种截然不同的文化之间的分水岭。AI 辅助工程意味着你利用机器来搭建脚手架、探索模式或自动化样板代码，而由你的大脑来处理决策。而 AI 依赖型工程意味着你信任机器来驾驶。许多组织正在悄然滑向“依赖”，因为短期内这感觉更快。但“快”并不等同于“正确”。

仍然属于人类的工作

AI 可以加速开发生命周期的几乎每一个环节，但仍有一些核心实践应当牢牢掌握在人类手中。系统设计需要平衡各种相互冲突的约束条件：成本、延迟、可靠性和未来的可维护性。架构评审依赖于组织记忆以及预测二阶效应的能力。导师制需要有人真正经历过他们正在向你警告的那些故障模式。对产品的深刻理解源于与用户交谈以及观察他们在实际场景中的行为，而非仅仅阅读训练数据。

工程判断力是这些经验的总和。它是一种低声的提醒，告诉你即使代码审查已通过，在周五下午进行迁移也风险太大。它是一种直觉，预感到现在的性能优化可能会在以后留下安全漏洞。LLM 没有直觉。它只有模式。模式很有用，但它们不等同于判断力。

现在的招聘企业需要停止针对那些仅仅擅长使用 AI 工具的人进行优化。应该雇佣那些能够挑战 AI 的人。寻找那些会停下来、仔细阅读生成结果，并能解释为什么不同意该结果的候选人。当生成的代码遇到复杂的生产环境现实时，正是这些工程师能让你的系统保持健康。

没有指南针的加速

将 AI 视为油门。在一部配备了...的汽车中