意图与实现的分裂

1951 年，葛丽丝·霍珀写了第一个编译器。

在她之前，编程是用机器语言写的——人类把指令翻译成二进制，再把二进制打孔到卡片上。写程序就是写机器。代码和机器之间没有距离。

编译器改变了一切。程序员不再写机器指令——他写"x + y"。编译器把这个符号变成寄存器的加载、加法运算、结果的存储。程序员不必知道 CPU 有多少寄存器——他甚至不必知道自己跑在什么 CPU 上。

这次断裂——从机器语言到高级语言——是软件工程作为一门独立学科的诞生时刻。在此之前，"软件"不是一门学科——它是硬件的附属品。在此之后，"软件工程师"可以一辈子不读芯片手册——他工作在抽象层上——而编译器负责向下桥接。

现在，第二次断裂开始了。

这一次，被抽象掉的不是机器——是实现本身。

你不是在写 x + y。你是在说——"把这个列表排序"——然后 AI 生成排序的实现。你不是在调 fetch()——你是在说——"从这个 API 拿数据，如果失败了就重试三次，如果三次都失败就把错误记录到日志然后返回一个默认的空列表"——然后 AI 生成完整的异步错误处理逻辑。

第一次断裂——你需要懂算法——但你不需要懂寄存器分配。第二次断裂——你需要懂"你想要什么"——但你不需要懂如何在代码中表达它。

这个变化不是"编程变简单了"。它是软件工程的核心环节——"实现"——的稀缺性正在消失。

稀缺性消失——意味着什么？

在经济学中——当某种资源从稀缺变为充裕——它的价格崩塌，围绕它建立的整个产业结构开始重组。

软件工程五十年的核心——"用代码实现需求"——就是这种正在变得充裕的资源。实现能力——写代码、改代码、重构代码的能力——从一个你需要付高薪购买的稀缺技能——变成了一个你可以几乎免费获得的算力搭配。

这不是说"程序员失业了"。这是说——"实现"不再是工程的核心瓶颈。

1980 年代的瓶颈是硬件——CPU 太慢了、内存太小了。1990 年代的瓶颈是操作系统和网络——怎么让不同的机器说话。2000 年代的瓶颈是规模化——怎么让一百万人同时用你的服务。2010 年代的瓶颈是数据——怎么存储、处理、学习海量信息。每一个时代的瓶颈——定义了那个时代的工程。

2020 年代以后——瓶颈在"意图"。不是"你能不能实现"——而是"你想要什么"——以及"你怎么知道你想要的跟实际实现的是同一个东西"。

当实现被抽象掉——什么不被抽象掉？

第一个是需求。你仍然需要知道"你想要什么"。AI 可以帮你精炼需求——但它不能替你决定方向。你必须在模糊的、有时矛盾的想法中——抽出那条真正重要的主线。

第二个是规约。你的需求——在变成 prompt 的过程中——必须被翻译成"可验证的期望"。不是"把搜索做好"——而是"当用户输入拼音首字母时——返回全名匹配并排序——最可能的在前——数量不超过五个"。在 AI 时代——prompt 是规约的一种退化形式——它不够精确——但它已经是规约——因为它定义了一个边界：AI 的输出必须在这个边界内、不在此边界外。

第三个是验证。当代码不是人写的——"评审"的对象变了。你不再评审"思路是否合理"——你评审"行为是否符合期望"。测试——尤其是自动测试——从"安全网"升级为"唯一的锚"——在概率的海洋里——测试是通过或失败的唯一确定性。评审从"读代码"变成了"读行为"。

规约——在 AI 时代——会变成什么形态？

传统规约有三种形式：自然语言需求文档（模糊、完整）；形式化证明（精确、极慢、不适用于大部分系统）；测试（不完整——但在它能覆盖的范围里——绝对精确）。

AI 给这三种形式分别加了一个维度。

自然语言 prompt——模糊但可以快速迭代。你今天写一个 prompt——AI 给你输出——你读了之后发现"不是这个"——你修改 prompt——再试——这是一个"规约的梯度下降"——你不需要一次写对——你可以通过反馈循环收敛到对的规约。

形式化——在 AI 辅助下——可能第一次变得可实用。不是写一个完整的 Coq 证明——而是让 AI 在你描述的行为约束中——自动生成"这个函数必须满足的不变量"——然后自动检查。形式化验证的成本——曾经是 prohibitive 的——正在被 AI 压到可以接受的范围。

测试——从验证实现变成了定义意图。以前——你先写代码——再写测试验证代码。现在——你可以先写测试——然后让 AI 生成满足测试的代码。测试不再仅仅是"检查"——它是"目标"。它是你给 AI 的规约的最精确形式——"你生成的东西必须能通过这组测试"。这个转变——测试从"验证"升格为"定义"——可能是 AI 时代最重要的工程方法论变化之一。

那么——软件工程师在 AI 时代的核心能力是什么？

第一个能力——判断 AI 生成的东西能不能用。不是看——是判断。读 AI 输出的代码——不是你写的——你能不能在几秒内判断出"这是对的还是错的"？这个能力——看似基础——但对初级工程师来说——可能是最难的一步——因为他们从未独立验证过"自己没写的代码"。

第二个能力——拆解。你有一个模糊的需求——你把它拆成"哪些可以让 AI 做——哪些必须自己做"。架构决策——目前——不要让 AI 做。因为架构的代价不是"写错了"——是"改不动"。一个错误的架构——即使代码全部由 AI 写——仍然会让你在三个月后无法添加新功能。

第三个能力——表达。把模糊意图转化为 AI 能执行的可验证规约。不是"写 prompt 的技巧"——是"把'我想要什么'变成'AI 给我什么才算对'"的翻译能力。这是新的基本功——和 1990 年代工程师必须会 C 一样基础。

第一次断裂——霍珀的编译器——把软件工程从电子工程中分离出来。软件工程师不再需要懂硬件——但他们需要懂算法、数据结构、操作系统。

第二次断裂——AI——正在把"实现"从软件工程中分离出来。新一代的软件工程师——不再需要"懂实现"——但他们需要懂"意图"——需要会拆解、会表达、会判断。

"实现"从未被真正尊重过——它是最"重"的工程环节——最耗时、最被低估、最被视为工程的核心却又最渴望被消除。第一次断裂——你还在实现——只是不是用汇编。第二次断裂——你不再亲自实现了——你在一个更高层的抽象上——定义"意图"——让 AI 去搜索和采样"实现"。

这不是软件工程的终结。这是软件工程——在 1951 年从电子工程中独立出来之后——第一次重新定义自己的学科边界。