跳绳鸭
67.76M · 2026-02-04
前两天我做了一件"轻浮"的事：把 1000 行刚“写"完的代码删了。
原因单纯觉得代码不顺手、逻辑绕、读起来累。以前这种情况下，我一般会硬着头皮去重构。但这次我直接 git restore 了，然后对着 AI 让它 “重头再来”。
最让我自己印象深刻的，不是 AI 又写出了一份"能跑"的实现，而是我删掉代码那一瞬间的心理状态：我没有任何负罪感与舍不得。
仔细想想这事儿在以前很不可思议。我们过去几十年都把"源代码"当成公司资产、团队心血、个人作品。现在呢？代码不重要了，丢了不心疼。
那问题来了：如果代码不值钱了，写代码的人还值钱吗？
图灵奖得主 Leslie Lamport 有一个演讲，题目就叫 "Programming ≠ Coding"。
他讲得很直接：很多人以为自己在 Programming，其实只是 Coding。Programming 是思考问题本质、设计算法和抽象；Coding 是用具体语言把它实现出来。
如果把这个观点再往上推一层，可以得到一个三层模型：
Engineering
| 定义目标、边界、约束（What / Why）
v
Programming
| 抽象、协议、Spec、状态机（How @ 抽象层）
v
Coding
具体实现（How @ 实现层）
过去和现在，这三层的"主战场"已经不一样了：
| 过去 | AI 时代 | |
|---|---|---|
| 主要瓶颈 | 实现贵、出错率高 | 定义不清、边界模糊 |
| 人的精力焦点 | Coding：怎么写对、写快、少 bug | Programming/Engineering：怎么定义清楚 |
| Coding 的角色 | 主战场 | 执行层（类似编译器） |
Lamport 还有一句话很不错：
当 AI 把 Coding 的边际成本打下来之后，一个很自然的问题就浮出来了：那 Programming 层和 Engineering 层呢？我们应该用什么去定义它们？
这时候，一些"死去的记忆"突然攻击了我。
"死去的记忆"开始攻击我。一些过去在软件工程书籍里被提过、但在业务高速增长年代里常常被忽略的概念，重新复苏了。
比如 Design by Contract（契约式设计）——1986 年，Bertrand Meyer 在设计 Eiffel 语言时提出这个理念。它强调：软件组件之间的协作关系，应当通过可验证的接口 Spec表达出来，典型形式包括：
用更短的一句话概括就是：契约先行——先把边界写清楚，再谈实现。
这一思路甚至可以延伸到系统级设计：上节提到的 Leslie Lamport，它提出的 TLA+，就是用数学化的 Spec 描述分布式、并发等复杂场景的全局契约，提前验证 “数据一致性”“并发死锁” 这类组件级契约难以覆盖的系统级逻辑漏洞，和 DbC 本质都是 “先锁规则，再做实现”。
为什么类似的东西多年前没有成为"默认实践"？可能是因为现实约束：实现成本高、交付压力大、组织扩张快。你让大家先写 Spec、先做形式化建模——这在短期看起来是"额外投入"。
Fred Brooks 在 No Silver Bullet（1986）里区分过两类复杂性：
AI 来了之后，这个账要重新算：
| 过去 | AI 时代 | |
|---|---|---|
| 偶然复杂性 | 消耗大量工程精力 | AI 大幅压缩（写接口、补样板、修 lint） |
| 本质复杂性 | 同样存在，但常被"赶进度"掩盖 | 仍然存在，甚至更容易被 AI 的"完整实现"掩盖 |
| 核心资产 | 代码本身 | 契约层（类型 / 接口 / 测试 / Spec） |
| 代码的性质 | 资产、心血、不轻易删 | 可蒸发物、可重建的缓存 |
回到前几天我删代码的操作——我能那么果断，靠的其实不是勇气，是底气。底气来自一层"契约"已经写在那里：
只要这层东西在，代码就没那么神圣了。写得不好？实在不行调整完“契约”，代码删掉重来。某个实现绕了？换一种写法。甚至整个模块都能替换掉——前提是契约可靠。
所以我有一个稍微激进但很实用的心智模型：
我不是说实现不重要，而是说：在契约足够清晰、验证足够自动化的前提下，实现的可替换性会显著提高。
那么，未来的技术栈会如何分层呢？
[表层] 业务变化快 / 迭代快
代码可替换性强，AI 写得最多。大家基本都在这一层工作。
[中层] 通用能力沉淀：组件库 / 框架 / 中间件
变化变慢，开始强调稳定性与兼容性。出现一些未来被叫做“底层"的新基架人。
[基岩] runtime / 编译器 / OS / 协议栈
变动极少，但一动就可能是系统级影响。很多公司可能都没一个这样的人。
这其实就是历史在重演：
| 时代 | "主流”开发者在写什么 | "底层"交给谁了 |
|---|---|---|
| 1960s | 汇编 | 硬件工程师 |
| 1990s | C/C++ | 汇编 / OS 专家 |
| 2010s | 高级语言 / 框架 | 系统程序员 |
| 2030s? | Spec / 契约 / 架构设计 | AI + 少数代码专家 |
今天写业务的人不懂汇编，也不需要懂；但我们仍然需要懂汇编/懂 runtime 的人 —— 不多，但不能没有。
那么，当下是那些不懂代码的人，成为了 Spec / 契约 / 架构设计师么？
也许不是。我观察到一个有点"残酷"的现象：那些能上升到 AI x Spec Engineer 的人，往往是本身 Coding 能力就很强的人。
他们不是因为"看不起、看不懂代码"而上去的，而是因为他们真的把代码玩懂了 —— 写得够多、踩过够多坑、读过够多源码，才敢在上层随心所欲。
也就是说，借助 AI 编码，越会写代码的人，越不需要写代码了。这就引出一个困境：
Ruby on Rails 的作者 DHH 写过一篇文章《Coding should be a vibe!》，他说 AI 是很好的结对伙伴，但把键盘完全交出去，他宁可退休。他的理由很简单：写代码本身就是乐趣，是手艺。未来手动编码或许会变成类似 “养马代步” 的小众爱好，失去经济价值 ——编程应该以人为本，迎合开发者的需求，带来愉悦的体验。
但他同时还提出了一个更尖锐的问题：
他打了一个弹吉他的比方：你看再多的吉他视频，只要你没有亲手去学习，你就很难学会弹吉他。放在我们今天的语境里，这个问题可以再推一步：
这就是我说的"成长路径断裂"：过去我们靠"写得多 → 踩坑多 → 理解深"来积累能力。现在第一步被 AI 替掉了，中间会不会断层？
面对这个困难，在其他事情上也许能找到一些参考：
"懂代码"的定义可能会变：从"我能把它写出来"，变成"我能审查它、能评判它、能在关键时刻诊断它"。
这只是一些推测，现在没有答案。甚至"没有答案"本身就是答案的一部分：我们正在经历一次职业路径的巨大变化。
最近面试的时候，有候选人问：现在应该学什么？
他们的困惑很真实：过去花时间掌握的很多编码知识，AI 现在都会了；而且在日常工作里，大家也确实越来越依赖 AI 来写代码。那接下来往哪走？
同样这也是我们很多人的困惑。如果要尝试回答，可能是：
这听起来像句废话，但认真想想：过去十几年互联网高速增长的时候，大家的注意力大多在"怎么更快写出来"上。软件工程那些东西——抽象建模、系统边界、契约设计——在课上听过，在工作里落实得不多。
现在 AI 把 Coding 成本打下来了，这些"上层能力"反而变得更值钱。重新把它们捡起来，不是复古，是顺势而为。比如现在大家热议的 SDD（Spec-Driven Development）、TDD（Test-Driven Development）、PBT（Property-Based Testing）——这些概念都不是 AI 时代新创的，最早的可以追溯到二三十年前。只是现在 AI 让"先写 Spec/测试，让机器填实现"这件事变得真正可行，它们才重新翻红。
Vibe Coding 上手太简单，让大家会误以为它并没有技巧。其实不然。OpenAI 创始成员、特斯拉前 AI 总监 Andrej Karpathy 发推说自己"作为程序员从未感到如此落后"，他觉得如果能把过去一年出现的东西串起来，生产力可以提升 10 倍，但没做到就是技能问题。Steve Yegge 在近期访谈里更激进：他认为驾驭 AI 编程需要约 2000 小时的刻意练习。
不管你叫它 Vibe Coding、Vibe Engineering 还是别的什么，它本质上是一种新的协作模式——需要主动学习和刻意练习，不是天然就会的（前一篇文章也有提到：《Vibe Coding 中的 5 个选择》）。
那对于我们这些接触不深的开发者，可以如何循序渐进呢？
不要光死盯着代码了，理解业务，理解目标，理解整个事情为什么要这么做。拒绝成为 AI 人柱力。
最后留一个问题给大家，可以尽情在评论区大战：
无论答案是什么，当实现成本下降时，能够把事情"想清楚、写清楚、验证清楚"的能力，会变得更稀缺。
回到开头的问题：如果代码不值钱了，写代码的人还值钱吗？
我的回答是：写代码的人不会消失，但能"定义清楚要写什么"的人会更值钱。
