历史总是惊人的相似：70 年前，我们也不相信机器能写好程序

01 · AI 会写代码，但我们真的敢用吗？

最近程序员社区出现一种很矛盾的景象：大家一边疯狂使用 AI 写代码，一边又在抱怨越来越多没有被认真理解和验证的 AI 代码。

Rust、LLVM、Godot 等开源社区都开始讨论类似问题，“AI Slop” 也因此成为一个常见说法。

所以今天真正的争议已经不是 AI 会不会写代码，而是：

AI 写出来的东西，到底敢不敢真的用？

现在越来越多人的态度是：AI 可以写，但必须有人看得懂、审得过、验证得了，并最终为结果负责。

有意思的是，差不多 70 年前，程序员面对 Compiler——编译器时，也经历过非常相似的信任问题。

02 · 70 年前，真正昂贵的是"人工翻译"

上世纪 50 年代，写程序和今天完全不是一回事。

假设我们只想做一件简单的事：

把 A 和 B 相加，如果结果大于 100，就继续执行下一步。

今天，很容易写成：

C = A + B

if C > 100:
    do_something()

但在早期计算机上，程序员面对的更接近：

CLA A
ADD B
STO C
SUB HUNDRED
TPL NEXT

程序员不仅要表达逻辑，还必须知道数据放在哪里、机器有哪些指令、每条指令怎么使用。换一种计算机，很多东西还要重新学习、重新编写。

所以那个时代，程序员大量时间并不是花在"我要解决什么问题"上，而是在：

把人的想法，翻译成某一台具体机器能够执行的动作。

这也是 FORTRAN 出现的重要经济背景。John Backus 后来回忆，当时一个计算中心的程序员成本通常已经不低于计算机本身，而计算机还有四分之一到一半的时间耗在调试程序上。

计算机越来越快，但人开始成为瓶颈。

03 · 为什么不能让机器自己翻译？

真正的转折，来自一个今天看起来很自然、当时却非常大胆的问题：

既然程序员每天都在做翻译，为什么不能让计算机自己完成这层翻译？

1954 年前后，John Backus 和 IBM 团队开始推进 FORTRAN。

前面那一串底层操作，程序员开始可以写成更接近自己思考方式的表达：

C = A + B

IF (C .GT. 100) GO TO 20

程序员只需要表达自己想算什么。

至于机器指令怎么生成、数据怎么读取、程序怎么跳转，交给 Compiler 完成。

人与机器之间的分工因此改变：

人负责表达想做什么，机器负责把它翻译成机器能够执行的代码。

04 · 当年的程序员，也不相信机器

专业程序员一开始并不相信这件事。

这种怀疑其实很合理。

早期自动编程系统生成的程序往往不够快。对于当时极其昂贵的计算机来说，如果机器生成的程序明显比专业程序员手写的慢，这项技术就没有实际价值。

所以 FORTRAN 团队真正要解决的问题不是"能不能自动生成代码"，而是：

机器生成的代码，能不能好到让专业程序员愿意信任它？

最终，他们做到了。

FORTRAN I 生成代码的优化水平非常高，已经能够和优秀程序员手写的程序竞争。

今天我们面对 AI，其实也在问类似的问题：

AI 可以写，但它写出来的东西能不能被理解、被验证、被长期维护，并最终有人愿意为它负责？

70 年前，我们在建立对 Compiler 的信任。

今天，我们正在建立对 AI 的信任。

05 · 当技术证明价值，组织变革就会发生

真正改变这件事的，不只是 Compiler 技术成熟，而是它开始证明自己的经济价值。

1957 年，第一版 FORTRAN Compiler 正式投入使用。

实际数据显示，FORTRAN 把编程和调试成本降低到了大约原来的四分之一。

这意味着企业看到的不再只是一项新技术，而是一种更高效的生产方式。

1958 年 4 月，对 26 个 IBM 704 站点的调查发现：

超过一半的站点，已经使用 FORTRAN 处理超过一半的问题；其中很多站点的 FORTRAN 使用比例已经达到 80% 以上。

从 1954 年开始尝试，到 1957 年真正可用，再到 1958 年快速普及，前后不过几年。

这里真正值得注意的是：推动变化的已经不只是程序员个人的选择，而是成本和效率开始进入管理决策。

当一项技术从"好不好用"，变成"用不用会影响成本和竞争力"，组织变革就会迅速发生。

汇编没有消失，但越来越少的人需要亲手去写它。

机器接过了原本必须由人完成的翻译工作。

06 · 当写代码变得容易，真正稀缺的是工程能力

FORTRAN 之后的历史，其实已经给过我们一次答案。

当写程序变得越来越容易，软件反而变得越来越大、越来越复杂。真正困难的问题开始从"怎么把代码写出来"，转向怎么设计系统、怎么组织协作、怎么保证质量、怎么长期维护。

到了 1968 年，Software Engineering——软件工程，开始被作为一个独立的工程问题认真讨论。

而自动化带来的很多新问题，后来也继续靠自动化解决：编译器需要优化，于是有了自动优化；程序越来越复杂，于是有了静态分析、自动测试和各种验证工具。

打败魔法的，往往还是魔法本身。

今天可能也是一样。

AI 让代码生产越来越快，质量、测试、验证这些新的瓶颈，也不会永远依赖人去逐行检查，它们本身同样会被进一步自动化。

所以未来真正稀缺的，也许不是写代码，甚至不只是检查代码，而是：

定义问题、理解业务、设计系统、制定标准、判断结果，并最终为结果负责。

当一种能力被技术快速普及，真正的机会，往往会出现在它之后暴露出来的新问题里。