从古法编程到Vibe Coding

最近半年，软件开发领域完成了一个很精彩的范式转化，从过去那种可以称为“古法编程”的方式，转向现在大家说的 vibe coding。这个变化不是简单地从一种开发工具换成另一种开发工具，也不是从一个编辑器换到另一个编辑器，而是软件开发本身的工作方式发生了变化。过去编程主要是程序员直接面对代码，一行一行写，一层一层调试，把抽象想法翻译成具体的语法和程序结构。到了 AI 编程和 vibe coding 之后，人的位置开始发生变化。人不再只是代码的直接书写者，而越来越像是意图的提出者、结构的判断者、过程的引导者和结果的校验者。代码仍然重要，但它不再是整个开发过程唯一的中心，真正处在中心位置的，变成了需求、语义、结构、反馈和执行结果。

围绕这次变化，外面出现了很多说法。比如文科生也可以编程了，不懂编程也可以开发软件了，程序员都要下岗了，传统开发彻底废了，等等。这些说法有它们成立的地方，但它们都有前提条件。它们的问题不是完全错误，而是把某一个局部现象直接扩大成了普遍结论。

文科生可以编程，这个说法在一定意义上是成立的。因为 AI 确实大幅降低了软件开发的入口门槛。以前一个人如果不懂语法、不懂框架、不懂数据库、不懂前后端、不懂部署，基本上很难真正做出一个可以运行的软件。现在只要他能够把自己的想法表达出来，AI 就有可能帮他生成页面、接口、数据库结构、登录功能，甚至做出一个看起来还不错的原型。这个变化是真实的，而且很重要。

但是，能做出一个东西，和能做出一个真正像样的产品，并不是一回事。现在很多关于 AI 编程的讨论，最大的问题就是把这两个层次混在了一起。AI 让更多人可以进入软件创造过程，这当然是好事，但它不等于软件开发的深层难度已经消失了。一个真正的软件产品，不是一堆代码的堆积，也不是几个页面能跑起来就结束了。它要有清楚的结构，稳定的边界，合理的权限，安全的流程，可维护的架构，真实的用户场景，以及长期演化的空间。

我自己在软件行业做了几十年，接触过的工作并不是单一的写代码，而是从不同职位、不同环节、不同规模、不同组织环境里一路经历过来。国内的项目做过，国外的项目也做过；企业系统参与过，政府项目也参与过；中小型软件、手机软件、大型平台，很多不同类型的系统我都开发过或者参与开发过。所以从我自己的经验来看，程序开发或者软件开发，从来都不是一个简单的“写代码”的工作。

软件开发里面有很多层次。最下面当然是代码编写、调试、数据库、接口、页面、部署这些具体工作。但再往上，就涉及需求理解、业务建模、系统设计、架构判断、项目组织、团队协作、用户行为、人机交互、系统科学，甚至还会涉及更深一层的哲学问题。比如什么叫做需求，什么叫做秩序，什么叫做一个系统真正能够运行起来，什么叫做目标，什么叫做执行，什么叫做一个开放的想法最后被收束成一个可以交付的结果。

所以在人工智能自动编程带来的这次范式转换中，我总体上并不认为它只是一个“文科生替代理科生”或者“不会编程的人替代程序员”的简单变化。这个说法太表面，也太容易把问题说偏。真正发生的事情，是软件开发的很多底层操作被 AI 承担之后，人的位置开始发生上移。过去很多人必须先掌握语法、框架和工具，才能进入软件开发这个过程；现在自然语言和 AI 让更多人可以从想法、需求和原型开始进入。但进入这个过程，并不等于掌握了整个软件开发。

门槛降低的只是入口，而不是整个系统的复杂性被取消了。我更愿意把这件事理解为一种逐级提升的过程。最底层的代码劳动会被大量自动化，重复性的实现工作会越来越多地交给 AI；中间层的开发者需要转向更强的结构判断、任务拆解、代码审查和系统整合；更高层的开发者则要理解产品、组织、用户、流程和长期演化。也就是说，AI 并不是简单地把程序员消灭掉，而是把软件开发中的角色层级重新排列了一遍。原来很多人停留在代码执行层，现在他们必须向设计层、架构层、产品层和系统层移动。

这个变化可以用飞机驾驶来理解。一个人如果第一次走进飞机驾驶舱，会看到上下左右、前后四周全是各种仪表、操控按钮、指示灯、显示屏，整个空间看起来极其复杂。但真正飞行的时候，飞行员在几个小时甚至十几个小时的航程中，实际手动操作的部分可能并不多。很多时候飞机处在自动驾驶状态，系统自己保持高度、航向、速度和飞行路径。甚至在长途飞行中，飞行员看起来并没有做太多动作。

但这绝不意味着一个没有受过训练的人也可以驾驶飞机。恰恰相反，飞行员操作少，并不是因为驾驶飞机变简单了，而是因为大量复杂操作已经被自动化系统接管了。真正困难的部分变成了系统理解、状态判断、异常处理和关键时刻的决策。一个按钮什么时候能按，什么时候不能按；一个警报意味着什么；一个仪表读数是否正常；遇到天气、故障、通信、燃油、导航问题时应该如何处理，这些不是靠看几眼驾驶舱就能明白的，而是要经过长期训练和大量飞行小时才能掌握。

AI 编程也是一样。现在 AI 可以自动生成很多代码，就像飞机可以自动保持航线一样。人的手工操作变少了，但这并不等于人的专业能力不重要了。相反，人的专业能力从“具体操作”转移到了“判断自动化系统是否在正确运行”。以前程序员的很多时间花在手写代码上，现在这部分可以交给 AI；但架构是否合理，需求是否清楚，权限是否安全，数据是否一致，错误是否被正确处理，系统是否能够长期维护，这些问题仍然需要人来判断。

所以，人工操作少，不等于任何人都可以开飞机；代码手写少，也不等于任何人都可以开发真正的软件产品。AI 编程降低的是操作层面的负担，而不是取消了专业判断。一个没有软件经验的人可以通过 AI 做出一个小工具，这一点我完全承认。但如果要做一个真正可靠、可发布、可维护、可扩展、能够面对真实用户的软件产品，仍然需要长期积累出来的系统感和工程判断。

我自己最近的经历，正好可以说明这个问题。前几个月 OpenClaw 这一类产品很火，我第一时间下载试了一下，很快就把它删掉了。不是因为它完全没有价值，而是因为我实在不太喜欢这种东西。我当时的直觉是，这类产品把很多 AI agent、工具调用、会话、技能和任务都放在一起，看起来很热闹，但在我看来，它还缺少一个更清晰、更稳定的组织结构。也就是说，它有智能的能力，但这种能力还没有被足够好地压进一个可控制、可判断、可收敛的工作框架当中。

后来我就想，能不能开发一个更好的产品。大概花了四十天时间，我做出了一个原生运行在 macOS 桌面上的智能体工作平台。技术细节这里先不展开，基本思路就是把 OpenClaw 这类产品中的很多能力，压缩进一个结构化设计的组织框架当中。这样做的目的不是为了增加复杂性，而是为了让智能的使用变得更加清晰、准确和可控。

这个系统的高层思路和架构，是我自己独立思考出来的。为了说明这种结构为什么可能有效，我还专门做过一个理论探讨，甚至写出了一个定理，试图证明这种抽象结构下的目标导向智能，在限定条件下具有某种收敛性。后来实际运行的效果也基本符合这个判断。一个自然语言命令输入之后，系统可以在多角色、多任务、自动协调、智能推进的过程中，逐步逼近并完成预定结果。用我自己的理解来说，这其实是一个限定条件下的负熵过程。自然语言本身是开放的、发散的、不稳定的，但当它被放进一个有角色、有任务、有边界、有反馈、有确认机制的结构中，它就可以逐步收束成一个可以执行、可以检查、可以完成的工作结果。

在这个开发过程中，大约百分之九十五的代码都是由 AI 自动完成的。但这并不意味着这个软件是 AI 自己做出来的。这个说法如果不加说明，就很容易误导人。AI 确实写了大量代码，甚至完成了很多过去需要程序员手工实现的细节，但整个产品的方向、结构、架构、边界、风险判断、功能取舍和开发节奏，并不是 AI 自己产生的。这些部分主要来自我的判断和引导。

特别是自然语言的引导，在这个过程中起到了画龙点睛的作用。很多时候我不是在一行一行写代码，而是在不断定义系统应该成为什么，不应该成为什么，哪里需要收束，哪里需要放开，哪里需要安全边界，哪里需要产品上的压缩。AI 能够生成代码，但它不会自动知道一个产品为什么应该这样组织，也不会自动知道某个功能虽然能做，但做进去之后会破坏整个系统结构。它更不会自动知道，一个智能体平台在真实桌面环境中运行时，权限、自动化、用户控制、任务边界和安全风险之间应该怎样平衡。

一开始我做的是一个自主管理的软件，并没有马上准备上架。原因也很现实。智能体软件对机器操作权限的要求比较高，比如自动操作桌面、控制浏览器、类似幽灵鼠标这样的能力，这些功能本身非常敏感。我当时担心苹果应用商店对这类软件的审核会很严格，不太容易通过，所以一开始没有按照上架版本去准备。后来我做了一个稍微压缩一点的版本，减少一些敏感能力，把它提交到苹果应用商店审核。经过大约十天的审核，中间有两次小的反馈和修改，昨天终于正式上架了。当然，由于众所周知的原因，国外 AI 产品目前不能直接在中国区苹果应用商店上架，所以国内用户暂时还不能直接使用。

提交苹果应用商店审核之后，我又花了两个小时做了一个个人数字分身系统，也是全程用 AI 编程。最初只是一个比较小的想法，但做出来之后我发现，它可以进一步扩展成一个通用的专家平台。也就是说，各路专家、知识博主、老师、顾问，甚至可以说各路名流神仙，都可以注册上来，把自己的专有知识上传到系统中，然后由系统进行智能分析。这种分析不是传统意义上的资料搜索，不只是把文档放进去，然后让用户在里面查关键词，而是要对这些资料进行结构化处理，提取出相对稳定的知识系统。在这个基础上，专家本人可以向自己的知识系统提问，专家的学生、徒弟、客户或者用户，也可以通过这个系统获得问答和解释。

这个专家平台我花了六天时间做出了预览版，而且已经上线。整个过程同样主要依靠 AI 编程完成。但我越来越清楚地意识到，这件事不能简单理解为“AI 替我写了代码，所以开发已经不需要程序员了”。事实恰恰相反。AI 可以完成很多具体实现，但它不知道为什么要做这个产品，也不知道这个产品应该面向谁，应该解决什么问题，应该怎样抽象，怎样收敛，怎样避免失控，怎样形成一个长期可演化的系统。

这也是我对所谓“文科生也可以开发软件”这种说法保持保留的原因。它不是完全错，但它缺少前提条件。如果只是做一个简单网页、小工具、小原型，AI 的确可以让很多不懂传统编程的人进入软件创造过程。但如果要做一个真正有结构、有权限、有风险、有商业场景、有长期演化空间的软件系统，事情就完全不一样了。这里面需要的不只是会不会写代码，而是要知道哪些东西必须存在，哪些东西不能随便做，哪些地方要保守，哪些地方可以激进，哪些抽象会带来长期价值，哪些功能看起来漂亮但会破坏系统结构。

所以我自己的经验反而说明，AI 自动编程并没有取消软件开发中的专业判断。它取消的是大量手工实现的劳动，把过去很多需要反复敲代码、调语法、查 API 的工作交给了机器。但它没有取消架构判断、产品判断、系统判断、风险判断和哲学层面的抽象能力。恰恰相反，AI 越强，这些高层判断越重要。因为一旦代码生成变得便宜，真正稀缺的就不再是代码本身，而是知道应该生成什么，为什么生成，生成到什么程度，以及如何把生成的东西组织成一个可靠系统。

从这个意义上说，vibe coding 并不是让所有人都变成程序员，也不是让程序员失去价值。它真正改变的是软件开发的层级结构。底层代码劳动大量自动化之后，人必须向上移动。一个人如果只是等待 AI 写代码，而不知道如何组织系统，他很快就会被 AI 生成的大量碎片淹没。相反，如果一个人有长期的软件经验，有产品判断，有系统思维，有对人和组织的理解，那么 AI 就会变成一种非常强大的放大器。

我这两个月的实际体验就是这样。代码大部分是 AI 写的，但软件不是 AI 自己创造出来的。真正关键的部分，是我把几十年软件行业经验、对组织结构的理解、对智能体系统的判断、对产品边界的取舍，以及对未来软件形态的想象，压缩成了一个可以让 AI 执行的自然语言引导过程。这个过程看起来像是在和 AI 对话，实际上是在用语言不断塑造一个系统。

所以，所谓从古法编程到 vibe coding 的转化，不能简单理解为技术人员被非技术人员替代。更准确地说，这是一次角色层级的切换。代码实现的门槛降低了，但系统创造的门槛并没有降低。低层的技能被自动化了，高层的判断被放大了。AI 写代码只是表面现象，真正的变化是软件开发正在从代码劳动，转向结构引导、智能协作和系统收敛。

这也许是这次变化最容易被误解的地方。外面看到的是，AI 可以写代码了，所以好像人人都可以开发软件。但从我的经验来看，真正重要的问题不是 AI 能不能写代码，而是人能不能知道自己到底要让 AI 写什么，为什么这样写，写出来以后怎样判断，怎样修改，怎样组织，怎样发布，怎样维护，怎样让它在真实世界中稳定运行。没有这些判断，AI 写得越快，系统反而可能越混乱。只有当人的高层判断足够清楚，AI 的代码生成能力才会真正变成一种生产力，而不是一堆看起来很厉害但无法收束的技术碎片。

AI 对当今世界的冲击远远不止软件行业，各行各业都在面对巨大的挑战。我们不能因为心理防御，或者因为依赖原来的舒适区，就否认 AI 正在改变现代社会的工作方式、知识生产和组织结构。

但另一方面，我们也不应该简单否定过去知识和经验曾经发挥的作用。AI 的出现并不意味着过去的一切都失效了，而是要求我们把原来的知识、经验和专业判断重新组织起来，让它们在新的环境中继续发挥作用。

所以真正需要的不是盲目拥抱 AI，也不是本能排斥 AI，而是用动态的、发展的眼光面对这个正在到来的未来世界。关键不只是问 AI 会不会替代我们，而是要问在 AI 已经参与进来的时代，我们怎样重新理解自己的位置，重新调整自己的能力，并把过去的积累转化成面向未来的判断力和创造力。

注：本文由我口述，经ChatGPT文字编辑生成.