严肃的构建

最近，硅谷和社交媒体上弥漫着一种令人兴奋的气氛。人们称之为 “Vibe Coding”（氛围编程）。你打开一个聊天窗口，输入几句模糊的想法，代码就流淌出来。不需要结构，不需要计划，一切凭感觉。这看起来像是在施展魔法。

对于黑客（Hackers）来说，这确实很有趣。这就像是在速写本上随意涂鸦，或者是在爵士乐中即兴演奏。这种即时满足感是巨大的。

但这里有一个问题：涂鸦不是蓝图，即兴演奏也不是交响乐。

虽然 Vibe coding 让我们尝到了未来的甜头，但我认为，如果真的想要构建能够长期运行、可维护的软件，它不仅是错误的，甚至是一种倒退。如果你在构建一个玩具，凭感觉是可以的；但如果你在构建一个系统，你需要的不是感觉，而是自举（Bootstrapping）。

复杂度的墙

“Vibe coding” 最大的弱点在于它忽略了软件工程中那个永远无法回避的敌人：复杂度。

当你只写几十行代码时，AI 就像一个天才的结对程序员。但当代码行数膨胀到一万行、十万行时，仅仅依靠自然语言的“聊天”来维持上下文，就像试图用口述来建造一座摩天大楼。很快，你就会撞上一堵墙。AI 开始遗忘之前的设定，逻辑开始冲突，你发现自己花在修复 AI 产生的幻觉上的时间，比你自己写代码还要多。

这是因为软件本质上不是关于写代码，而是关于约束（Constraints）。

好的软件工程，实际上是不断施加约束的过程。类型系统是约束，单元测试是约束，架构文档更是最高级别的约束。Vibe coding 试图剥离这些约束，以此换取速度。这在短期内有效，但在长期是致命的。

AI 自举过程

如果不仅仅是为了探索，而是为了符合严谨的工程规范，我们需要一种不同的方法。这种方法不是让 AI 替你思考，而是你先思考，然后让 AI 替你执行。

我想象中的理想流程，更像是一个自举过程。

在计算机科学的早期，为了写出一个编译器，你必须先用汇编语言写出一个最小的核心，然后用这个核心去编译更高级的语言，直到它能编译它自己。这是一个从“硬”到“软”，从“重”到“轻”的过程。

在 AI 时代，这个过程依然存在，只是形式变了。

首先，你需要做那些“枯燥”的人类工作。你需要写文档，定义架构，编写测试集（Test Suites）。 这听起来很反直觉。大家用 AI 不就是为了逃避写文档和测试吗？但事实恰恰相反。因为 AI 不具备人类的意图（Intent），文档和测试就是你将意图这种抽象概念，固化为 AI 可以理解的逻辑边界。

这就是那个“最小的核心”。

翻转比例

一旦你建立了这个核心——这个由文档定义的真理来源（Source of Truth）和由测试定义的验收标准——奇妙的事情就发生了。

你不再是那个在那儿敲击键盘写 if/else 的人。你变成了架构师和审核员。你可以将 AI 接入这个框架。因为有了测试集作为护栏，有了文档作为地图，AI 可以开始接手具体的实现工作。

起初，这个比例可能是 90% 的人类工作（思考、设计、定规矩）和 10% 的 AI 工作（填充代码片段）。

随着系统的完善，随着测试覆盖率的提高，这个比例会发生翻转。当你拥有一个足够健壮的“脚手架”时，AI 可以接手 50%，甚至 90% 的代码编写工作。你可以对 AI 说：“嘿，按照现在的架构模式，给我加一个用户认证模块，必须通过现有的安全测试。”

这时候，AI 就不再是在“凭感觉写代码”，它是在填空。这才是可扩展的。

真正的“无代码”

这让我们想到了一个有趣的结论。

人们一直在寻找“无代码”（No-code）的圣杯。Vibe coding 的支持者认为，通过自然语言对话就是无代码的未来。但我怀疑并非如此。自然语言太模糊了，无法精确描述复杂的逻辑结构。

真正的未来可能更像是一种高阶的声明式编程。

在这个未来里，最高级的编程语言不是 Python 或 Rust，而是测试用例和架构文档。这才是人类应该专注的地方。

这种做法要求甚至比以前更高。在 Vibe coding 中，你可以偷懒，假装自己懂了。但在“自举式”开发中，你必须极其清楚自己想要什么。如果你连文档和测试都写不清楚，AI 给你的只会是一堆无法运行的垃圾。

所以，别被那种“随手写出个 App”的幻觉迷惑了。如果你想做一名严肃的黑客，先放下你的 Prompt，去把文档写好，把测试写好。

那是地基。剩下的，才是魔法。