最近一段时间，我几乎把所有能接触到的 AI IDE、AI 编程工具，都放进了真实的软件开发流程里。
不是尝鲜，也不是体验，而是真的让它们参与到业务开发、系统重构和性能优化中。
一开始，我并没有抱太高的期待。 毕竟写了十多年代码，见过太多“看起来很美”的工具，最后都败给了真实业务。
但用得越久，我心里越清楚一件事：
❝AI 编程，已经不是“未来趋势”，而是已经发生的现实。
而且，它发生得比很多人想象中更彻底。
一、一个必须正视的事实：AI 已经稳定超过“中级程序员”
如果只是写几个工具方法、补几行代码，很难感受到真正的变化。
真正让我警觉的，是当我开始让 AI 参与这些事情：
拆解一个并不完整的业务需求
设计一个相对完整的业务模块
给出分层、结构和工程化建议
在既有系统约束下做重构方案
我发现，它给出的结果，已经不是“能不能用”，而是：
❝“如果这是一个中级程序员交付的成果，我会不会认可？”
而大多数时候，答案是肯定的。
它懂主流技术栈，理解常见业务模型，知道为什么要做缓存、为什么要加幂等、为什么日志不能乱打。 在编码规范和工程意识上，甚至比不少真实开发者更“标准”。
说得直白一点：
中级程序员所代表的那一整块能力区间，正在被快速抹平。
二、但越用 AI，我越不敢“直接上线”
有意思的事情也正是在这里发生的。
当 AI 写的代码越来越多，我却发现自己并没有因此变得更轻松，反而多了一种微妙的谨慎。
不是因为代码写得差，恰恰相反——正是因为它写得“太像对的了”。
你会忍不住多看一遍，多想一层，然后在心里问自己一句：
这样做，真的合适吗？
这种不安，几乎总是出现在同一个地方。
❝最后一公里。
三、最后一公里，并不是“补 bug”那么简单
很多人以为，最后一公里是：
少写了一个 if
少考虑一个边界
性能还能再优化一点
但这些，其实都只是表面。
真正的最后一公里，往往是这些问题：
这个方案，真的符合我们当前的业务语境吗？
这个设计，在需求变化时会不会迅速失控？
这个实现，对团队来说是不是隐性成本过高？
一旦出问题，我们有没有兜底能力？
这些问题，AI 很少主动帮你思考。
不是它不聪明，而是它不需要为系统的长期结果负责。
四、AI 理解需求，但不理解“历史包袱”
在真实系统中，我们都见过一些代码：
不优雅
不标准
甚至有点“丑”
但它们之所以存在，往往是因为：
一次线上事故后的止血方案
一次业务博弈后的妥协结果
一条已经无法回退的演进路径
这些东西，不会完整地写在需求文档里，更不会体现在代码注释中。
但你作为长期维护者，是知道的。
而 AI，并不真正生活在这个系统里。
五、AI 擅长“当前正确”，但不擅长“长期负责”
这是我认为最关键的一点。
AI 给出的方案，往往在当下是成立的，逻辑清晰、结构完整、看起来也很“专业”。
但软件工程真正困难的地方，从来不在现在，而在未来：
数据量翻十倍之后怎么办？
业务边界扩散之后还能不能兜住？
组织变化后权限模型是否仍然成立？
这些问题，本质上不是技术问题，而是对变化的预判能力。
而这种能力，来自经验、踩坑，以及对风险的敬畏。
六、技术方案，永远绕不开“现实成本”
还有一个 AI 天生不敏感的维度：真实工程成本。
一个技术方案，真正的成本包括：
学习成本
运维成本
协作成本
出问题时的排错成本
AI 往往会告诉你“可以这样做”， 但它不会替你承担后果。
而“最后一公里”，往往就是你站出来，说一句：
❝技术上没问题，但我们不这么做。
七、AI 正在重塑程序员真正的价值分布
当 AI 可以承担 70%—80% 的实现工作时，程序员的价值自然会发生迁移。
未来真正拉开差距的，不再是：
谁写代码更快
谁框架更熟
而是：
谁能定义问题
谁敢做取舍
谁愿意为系统负责
从这个角度看，AI 并没有削弱程序员，而是逼着程序员回到更本质的位置。
八、为什么“资深工程师 + AI”反而更强
如果你停留在中级能力区间，AI 的出现确实会带来挤压感。
但如果你已经开始关注：
系统整体演进
技术与业务的边界
团队与工程的协作成本
你会发现，AI 更像是一个放大器。
它放大了你的判断力，也放大了你的责任。
写在最后：最后一公里，恰恰是人的位置
如果有一天，90% 的代码都可以由 AI 写完，那么人还剩下什么？
也许正是这些：
判断
取舍
对复杂现实的理解
对长期结果的负责
最后一公里，并不优雅，也不炫技。 但它真实、沉重，而且不可外包。
而这，恰恰是人类工程师，仍然站在场上的原因。
