💬 前言

I skate to where the puck is going to be, not where it has been. —— Steve Jobs

2025 年面试的时候，我和面试官（现在是我的老板了）聊到过 AI 编程。 那时我的答复很明确：AI 可以补全代码，可以帮忙排查问题，也可以完成一些边界清晰的任务。但面对复杂业务、历史项目和那些从未写进文档里的团队经验，它终究只能是工程师的辅助。

然而这个判断只活了一年。

现在，我每天同时开着两三个 Session。一个负责实现需求，一个在修改项目中的问题，还有一个可能正在探索研究某套我并不熟悉的方案，让他快速帮我判断是否可以落地， 又是否有什么风险。过去需要我花一天查资料、调试和验证的工作，它半个小时就能给出一个完成度很高的版本。

我负责告诉它要做什么，把业务背景和项目约束一点点喂给它，在它走偏的时候拉回来，最后检查测试是否通过、结果能不能上线。

它负责写代码。

说实在的这种突然的角色倒置偶尔让我不安

过去几年我都是花费了大量的时间在编程上， 我之前也说过时间不等于成果，但是好的成果一定需要时间的打磨以及沉淀： 见过足够多的问题，写过足够多的代码，踩过足够多的坑，便会自然地成为一个更好的软件工程师

代码量是表象，背后的时间以及思考是这套逻辑留下来的刻度。

但是现在在很多场景你都可以依靠 AI 在短时间内完成更多，甚至质量更高的事情

AI 的出现打碎了这把尺子

🏒 冰球正在去往哪里

如果只看钱正在流向哪里，答案已经明显得近乎粗暴。 从 2022 年末到 2025 年末，英伟达的复权股价上涨超过 1100%；Anthropic 的融资估值也从 2025 年 3 月的 615 亿美元，增长到 2026 年 5 月的 9650 亿美元。芯片、存储、数据中心以及各种与 AI 挂钩的基础设施，在过去几年里一次次被重新定价。

如今 5.6 Sol 、Fable 5 以及 kimi k3 等模型能力层出不穷，前一个模型的能力边界还没有完全摸清，下一个模型又已经把边界向前推了一段

对软件开发工程师来说，AI 带来的变化不只是写代码更快，而是熟练掌握某套技术栈，在逐渐失去过去那样的稀缺性。

当需求、约束以及验收标准已经明确，AI 可以同时完成页面、接口和测试。最先受到影响的，也许不是某个具体岗位，而是那些只需要按照既定方案完成实现的工作（亦或者只需要做简单搬运的工作？）。

但代码更容易生成，不代表软件更容易被理解。系统架构怎么设计、一次修改会影响哪里、看似正确的结果会不会对以往的业务逻辑或者别的系统造成影响，能不能上线，仍然需要人的经验去做正确的判断。

君子生非异也，善假于物也。 —— 《荀子·劝学》

就像摄影从胶片走向数码，暗房冲印不再是摄影者必须掌握的流程，但对曝光、构图和色彩的理解并没有随胶卷一起过时。改变的是成像方式，不是看待世界的眼光。

软件工程师的优势未必是比其他人更懂模型，而是更早学会如何把 AI 更高质量、快捷地接入真实项目里，再通过约束、测试、日志和监控发现它的问题以及保证高效高质的产出。

这套做事方式也能被带到其他行业。以后只靠熟练编码拉开的差距会越来越小，更有价值的可能是既理解代码背后的系统原理，又真正理解业务规则和现实限制的人。

代码仍然是软件开发的必经之路，只是实现这一步正在变短。冰球也在继续向前，从“代码该怎么写”，滑向“为什么要这样写，以及写完是否真的解决了问题”。

💻 开发者又该滑向哪里

如果把目标定成比 AI 掌握更多知识、熟悉更多框架，或者比它更快地写出代码，那么这是一场很难胜利的比赛。

人的学习以月和年计算，模型的进步却以版本计算。我们刚刚熟悉上一代模型做不到什么，下一代模型可能已经把那个结论变成了过期经验。追着每一次更新奔跑，只会始终慢冰球一步。

但这不代表学习已经没有意义，而是需要重新考虑自己究竟应该学习或者提高什么。

决策

AI 可以在短时间内给出许多方案，但方案越多，选择反而越重要。决策既发生在 AI 回答之前，也发生在它给出答案之后。

在生成方案以前，开发者需要确定真正要解决的问题，并补充必要的背景和约束。项目的历史问题、兼容要求和维护成本， 共同划定了方案以及改动的范围。缺少这些信息，AI 很容易用一个技术上漂亮的答案，解决一个并不存在或者无法落地的问题。

在生成方案以后，开发者仍然需要作出取舍。有些方案更加先进，却不适合当前团队；有些方案能够快速上线，却会留下长期的维护成本。最终选择哪一个， 需要同时考虑业务价值、实现成本、潜在风险以及现有系统能否承受。

所以决策不是简单地从十个答案中挑出看起来最好的一个，而是先定义什么样的答案能够成立，再从可行方案中选择最适合当下的那一个。

方向选错以后，AI 只会让我们更快地走向错误的方向，南辕北辙一般。

审美

1997 年乔布斯重返苹果的时候，曾这样评价他们当时的产品：

The products suck! There’s no sex in them anymore! —— Steve Jobs

AI 已经很容易把一个功能做得像模像样。页面能打开，流程能跑通，交互也没有明显错误。可真正用起来，还是会觉得哪里不对： 信息太满，步骤太多，什么都有，却找不到重点。

摄影常被说成是减法的艺术。取景框只有那么大，决定一张照片的，往往不是拍进了多少东西，而是把什么留在了画面之外。做产品也是一样。 过去，工期和成本多少会替我们挡住一些想法；现在 AI 让实现变得越来越快，想到什么就做什么，反而很容易把产品塞得越来越满。

AI 可以帮我们不断添加，审美却常常表现为删掉、合并，或者干脆不做。一个清楚的界面如此， 一个有性格的产品也应该是这样。极简不是为了显得高级，简约也不是功能越少越好，只是留下来的每一样东西，都应该有它存在的理由。

注意力

Prioritize your life, and you will have plenty of time to do the important things. —— 黄仁勋

AI 可以同时生成大量代码，人却无法同时审查所有代码。实现变快以后，真正稀缺的不再是产出，而是开发者应该把时间放在哪里。如果每次改动仍靠人从头检查，省下的编码时间最终只会堵在审查上。

AI 把编码这块木板迅速拉长，代码审查却仍受限于人的时间和精力。一旦审查成为最短的木板，AI Coding 带来的效率红利就会被木桶效应抵消。

要补上这块短板，不能只是要求人看得更快，还要减少那些本不必反复由人判断的问题。代码如何组织、哪些边界不能越过、常见问题如何处理，都可以提前形成团队规范，让 AI 在生成时就有所遵循，而不是等到审查时再逐一纠正。

当这些重复问题被提前过滤，人的注意力才能留给规范无法回答的部分：业务逻辑是否正确、系统边界是否合理，以及真正高风险的改动。

⏳ 握紧方向盘吧

AI 变得越快，我的不安有时候就越具体。我常常担心的不只是岗位会不会消失，也是那些花了很多年才学会的东西，会不会突然失去意义。

但过去写过的代码、排查过的问题和走过的弯路，并不会因为 AI 也能做到就一夜归零。它们会变成判断一个方案是否可靠的直觉，变成对好坏的分寸。

就像汽车取代马车以后，马车夫失去了熟悉的谋生方式，但是对道路的熟悉却没有随缰绳一起消失。他们需要重新学习驾驶，却不必重新学习认路。

曾握紧缰绳的我们，如今要开始握住方向盘