当 AI 能写出比中级程序员更好的代码之后，我开始重新思考“程序员的价值”

最近一段时间，我几乎把所有能接触到的 AI IDE、AI 编程工具，都放进了真实的软件开发流程里。

不是尝鲜，也不是体验，而是真的让它们参与到业务开发、系统重构和性能优化中。

一开始，我并没有抱太高的期待。 毕竟写了十多年代码，见过太多“看起来很美”的工具，最后都败给了真实业务。

但用得越久，我心里越清楚一件事：

❝ AI 编程，已经不是“未来趋势”，而是已经发生的现实。

而且，它发生得比很多人想象中更彻底。

一、一个必须正视的事实：AI 已经稳定超过“中级程序员”

如果只是写几个工具方法、补几行代码，很难感受到真正的变化。

真正让我警觉的，是当我开始让 AI 参与这些事情：

• 拆解一个并不完整的业务需求

• 设计一个相对完整的业务模块

• 给出分层、结构和工程化建议

• 在既有系统约束下做重构方案

我发现，它给出的结果，已经不是“能不能用”，而是：

❝ “如果这是一个中级程序员交付的成果，我会不会认可？”

而大多数时候，答案是肯定的。

它懂主流技术栈，理解常见业务模型，知道为什么要做缓存、为什么要加幂等、为什么日志不能乱打。 在编码规范和工程意识上，甚至比不少真实开发者更“标准”。

说得直白一点：

中级程序员所代表的那一整块能力区间，正在被快速抹平。

二、但越用 AI，我越不敢“直接上线”

有意思的事情也正是在这里发生的。

当 AI 写的代码越来越多，我却发现自己并没有因此变得更轻松，反而多了一种微妙的谨慎。

不是因为代码写得差，恰恰相反——正是因为它写得“太像对的了”。

你会忍不住多看一遍，多想一层，然后在心里问自己一句：

这样做，真的合适吗？

这种不安，几乎总是出现在同一个地方。

❝ 最后一公里。

很多人以为，最后一公里是：

但这些，其实都只是表面。

真正的最后一公里，往往是这些问题：

• 这个方案，真的符合我们当前的业务语境吗？

• 这个设计，在需求变化时会不会迅速失控？

• 这个实现，对团队来说是不是隐性成本过高？

• 一旦出问题，我们有没有兜底能力？

这些问题，AI 很少主动帮你思考。

不是它不聪明，而是它不需要为系统的长期结果负责。

四、AI 理解需求，但不理解“历史包袱”

在真实系统中，我们都见过一些代码：

但它们之所以存在，往往是因为：

• 一次线上事故后的止血方案

• 一次业务博弈后的妥协结果

• 一条已经无法回退的演进路径

这些东西，不会完整地写在需求文档里，更不会体现在代码注释中。

但你作为长期维护者，是知道的。

而 AI，并不真正生活在这个系统里。

五、AI 擅长“当前正确”，但不擅长“长期负责”

这是我认为最关键的一点。

AI 给出的方案，往往在当下是成立的，逻辑清晰、结构完整、看起来也很“专业”。

但软件工程真正困难的地方，从来不在现在，而在未来：

• 数据量翻十倍之后怎么办？

• 业务边界扩散之后还能不能兜住？

• 组织变化后权限模型是否仍然成立？

这些问题，本质上不是技术问题，而是对变化的预判能力。

而这种能力，来自经验、踩坑，以及对风险的敬畏。

六、技术方案，永远绕不开“现实成本”

还有一个 AI 天生不敏感的维度：真实工程成本。

一个技术方案，真正的成本包括：

AI 往往会告诉你“可以这样做”， 但它不会替你承担后果。

而“最后一公里”，往往就是你站出来，说一句：

❝ 技术上没问题，但我们不这么做。

当 AI 可以承担 70%—80% 的实现工作时，程序员的价值自然会发生迁移。

未来真正拉开差距的，不再是：

而是：

从这个角度看，AI 并没有削弱程序员，而是逼着程序员回到更本质的位置。

八、为什么“资深工程师 + AI”反而更强

如果你停留在中级能力区间，AI 的出现确实会带来挤压感。

但如果你已经开始关注：

你会发现，AI 更像是一个放大器。

它放大了你的判断力，也放大了你的责任。

写在最后：最后一公里，恰恰是人的位置

如果有一天，90% 的代码都可以由 AI 写完，那么人还剩下什么？

也许正是这些：

最后一公里，并不优雅，也不炫技。 但它真实、沉重，而且不可外包。

而这，恰恰是人类工程师，仍然站在场上的原因。