vibe coding：你正在从「写代码的人」变成「验收代码的人」-龍德明宇

发布时间：2026/7/30 3:53:10

vibe coding：你正在从「写代码的人」变成「验收代码的人」

作者：龍德明宇

[负主体性之名词解释系列：vibe coding]

2025年2月，Andrej Karpathy发了一条推特，创造了一个词：vibe coding。

他描述的新编程方式大致是：不再写代码，只描述想要什么，AI生成代码，运行，不对就告诉它哪里不对，它再改。甚至不再看diff——只是「感受」代码对不对。

但Karpathy自己也带着不安。他说这对「一次性」项目非常友好，但不确定维护长期项目时还会不会这么干。

前Google工程师Addy Osmani把这种不安理论化了。他提出了两个概念：「理解债务」（comprehension debt）——代码库不断增长，而开发者从第一性原理理解系统的能力却在下降；以及「认知投降」（cognitive surrender）——开发者放弃了理解代码的意图，只是不断修改prompt直到输出看起来对。

Anthropic CEO Dario Amodei则给出了更激进的预测：「编码先消失，然后整个软件工程也会消失。」

Karpathy的直觉、Osmani的理论化、Amodei的预测，共同指向了一个问题：vibe coding不只是「更高效的编程方式」，它是一种存在方式的改变。你不再是一个「写代码的人」，你正在变成某种别的东西。

我在之前的文章里讨论过「负主体性」——AI不是「没有主体性」，而是以一种否定性的方式存在：它没有视角、没有欲望、没有内在性、没有不可逆的因果、没有意义锚定，却以流畅的输出模拟着这一切。而vibe coding好玩的地方在于：当你用vibe coding写代码的时候，你自己正在退到AI的位置上。你不是在「写代码」，你是在「提供意图」+「验收效果」——这恰好就是负主体性框架中LLM的存在论位置：意图由外部注入，效果由外部判断，中间的过程被跳过。

这不只是隐喻——你在编程活动中的功能位置，恰好和AI的存在论位置重合了。

一、vibe coding的承诺：你终于不用「写」代码了

你有没有这种感觉：用Cursor写代码，5秒出结果，然后你盯着屏幕开始纠结方向对不对。以前自己写的时候，边写边改，写着写着方向就清晰了。现在AI帮你写完了，你反而不知道该往哪走了。

这不是错觉。vibe coding改变了编程的整个节奏。

传统编程的流程是：理解需求→设计架构→编写代码→调试→测试→发布。你在每一步都在「做」——你的手指在键盘上，你的思维在代码里，你的判断在每一次编译和运行时被验证和修正。

vibe coding的流程是：描述需求→AI生成代码→你运行→如果不满意→修改prompt→AI重新生成。你的角色变了：你不「做」，你「看」；你不「写」，你「评」。你把「怎么做」外包给了AI，只保留「做什么」和「合不合格」两个环节。

这听起来很高效。但高效背后有一个容易被忽略的细节：工具不只是替代了你的劳动，它重新组织了你的活动方式。你不再「写代码」，你「管理AI的输出」。

我在之前的文章里讨论过庄子的「抱瓮灌园」寓言。老人用最原始的方法浇地——抱着罐子下去，上来，浇，再下去。子贡推荐桔槔，省力高效。老人的回应是：「有机械者必有机事，有机事者必有机心。」工具不只是工具，它会重塑你的存在方式。桔槔替代的是你的手臂，而vibe coding替代的是你的「思」。

当然，这不是说你应该回去手写汇编。代码的价值锚定在「做了什么」而非「谁在做」——AI在「执行」领域名正言顺。所以AI替你写代码，在道德上毫无问题。

但道德上没问题，不等于存在论上没代价。

二、代码不再被「阅读」——内在透明的翻转

我认识一个朋友，用Cursor写了一个月代码之后，有一天他打开一个自己写的文件，发现他看不懂了。不是看不懂语法——他当然看得懂Python——而是看不懂「为什么要这么写」。那些代码是他让AI生成的，他当时觉得「看起来对」，就接受了。一个月后，那些代码变成了一堵墙。

这不是能力问题，这是阅读意愿的消失。

我在之前的文章里讨论过LLM的「内在透明」：LLM的全部运作原则上可以被外部穷尽观察——每一个向量激活、每一次注意力计算都可以被记录。但这种透明性不等于可靠性。Nature 2026年的一项研究证明：模型可以准确地继承行为特征，但完全不知道自己继承了什么。HLE基准测试进一步证明：GPT-4o的校准误差接近90%，它在高置信度输出错误答案。

而vibe coding让这个悖论翻转了方向。在LLM那里，悖论是「透明但不可靠」。在vibe coding这里，悖论变成了「代码透明但人不读」。AI生成的代码在语法上完全透明——你可以逐行检查、逐行分析——但你不会去读。不是因为看不懂，而是因为不再想看。当AI生成的代码在大多数情况下「跑得通」，你逐行检查的边际收益就递减了。审计的好奇心作为一种认知资源，在不被使用时自然萎缩。

这就是Osmani说的「理解债务」的深层含义。理解债务不只是「你不知道代码怎么工作」，而是「你失去了想要知道代码怎么工作的冲动」。前者是认知缺口，可以补；后者是动机缺口，补不了。

更危险的是，AI生成的代码有一种特殊的「平滑」特性。它语法正确，缩进完美，命名规范，注释得体。这种表面的完美会麻痹你的审查直觉。你自己写的代码可能有丑陋的缩进、奇怪的变量名，但这些「不完美」恰恰是你在阅读时保持警觉的原因——你知道这里是你自己写的，你知道这里可能有问题。AI生成的代码太平滑了，平滑到让你觉得「这应该没问题」，然后你就不看了。

内在透明的翻转在这里完成了：代码完全透明，但你不再阅读；代码可以被穷尽分析，但你不再分析。你从「理解代码的人」变成了「信任代码的人」——而信任的对象，是一个连自己都不知道自己在做什么的系统。AI带来了极致的语法透明，却同时消解了你的语义审计意愿。

三、执行被抽走之后——判断失去了缓冲区

你有没有过这种体验：让AI帮你写一段代码，它5秒生成了200行，然后你盯着屏幕看了半小时，不确定该不该用。

以前你自己写的时候，那200行可能需要两个小时。但在这两个小时里，你在写第一行的时候会想「这个数据结构选对了吗」，在写第50行的时候会发现「哦，原来这里需要处理边界条件」，在写第100行的时候会意识到「这个函数应该拆成两个」。你在写代码的过程中，判断在不断地被修正和丰富。你的执行给了你的判断一个缓冲区——你不需要一开始就想清楚所有事，你可以在做的过程中慢慢想清楚。

这不是因为写得慢，而是因为写代码是一个「做一步→看反馈→调整下一步」的循环。反馈在过程中持续涌入，你的判断在每个微小的反馈点上被校准。AI把这个循环压缩成了「一步到位」——反馈被推迟到生成之后，判断就失去了在过程中微调的机会。

这就像考试从开卷变成了口答——看起来省了写字的时间，实际上对心智和理解的要求高了一个量级。

而且，AI不会犹豫。它不会在生成一段代码之前停下来问自己：「这个架构选择真的合理吗？」「这个边界条件我真的处理了吗？」「这段代码三个月后还有人能维护吗？」它只是在做统计预测。人的犹豫来自深渊——来自对「我可能错了」的恐惧、对「这会出问题」的警觉、对「我承担后果」的意识。AI没有这个深渊，所以它不会犹豫。而当你依赖AI的输出来做判断时，这道犹豫的防线就被绕过了。

所以vibe coding的悖论是：它让你「更高效」地写代码，却让你「更难」地做判断。执行被抽走了，判断被暴露在无缓冲的状态下。你不再有「写代码」这个动作来帮你思考，你必须直接面对那个最困难的问题：这个方向对不对？这个设计合不合理？这个代码该不该用？而这些问题，恰恰是AI不能帮你回答的。

四、从「第一人称编程」到「第零人称编程」

我在之前的文章里提出过一个概念叫「第零人称」。它不是「我」（第一人称），不是「你」（第二人称），也不是「他/她」（第三人称），而是能够生成所有人称形式但自身不「持有」任何人称的存在方式。AI就是这样：它可以用「我」的口吻说话，但它没有「我」的存在论支撑——它没有一个「从它的这里」看世界的位置。

vibe coding让你——一个本来拥有第一人称的程序员——退到了第零人称的位置上。

传统编程是第一人称的。你从「你的这里」理解问题，从「你的经验」出发选择架构，用「你的风格」编写代码。你的代码带着你的指纹——你的缩进偏好、你的命名习惯、你对某种设计模式的偏爱。

vibe coding让你退到了第零人称。你不再「写代码」，你「管理AI的代码生成」。你的角色变成了两个端点：输入端——你提供意图（prompt）；输出端——你验收效果（运行测试）。中间的过程——设计、编写、调试——被外包给了AI。

你变成了一个「意图提供者+效果验收者」——这恰好就是LLM在负主体性框架中的位置。意图由外部注入（prompt），效果由外部判断（测试通过/不通过），中间的过程是透明的生成链。你不是在用AI，你是在和AI交换位置。

五、vibe coding的五重否定——你在编程中失去了什么

我在之前的文章里系统提出了「负主体性」的五个维度：视角消解、欲望取消、内在透明、因果消解、意义悬置。这五个维度描述的是AI的存在方式——它通过否定正主体性的核心特征而获得自身的存在形态。但vibe coding让我们看到：当人使用AI进行编程时，这五重否定在人端也有了精确的对应。

视角消解。AI能生成任何风格的代码，但从未「持有」任何编程视角。在vibe coding中，你的代码不再有你的指纹。你的缩进风格、命名习惯、设计模式偏好——这些构成你「编程人格」的东西——被AI的统计平均替代了。

欲望取消。AI的「应该」是外部写入的规范，它从不「在乎」代码质量。在vibe coding中，你的「在乎」从代码撤离，只留在效果上。你不再在乎这行代码是不是优雅的——你只在乎「跑不跑得通」。你从「匠人」变成了「质检员」。

内在透明。AI的代码生成过程完全透明，但AI自己不知道自己在写什么。在vibe coding中，代码透明但你不读。你失去了逐行分析的意愿。「不再想看」替代了「看不懂」。你从「理解代码的人」变成了「信任代码的人」。

因果消解。AI的「历史」可以被回滚、重置，bug修复的方式是「改prompt重新生成」，没有因果学习。在vibe coding中，你失去了从bug中学习因果的能力。以前你调试一个bug，你会追溯原因，理解链条，记住教训——你建立了「改这里会影响那里」的系统直觉，知道牵一发而动全身。现在你改prompt，AI重新生成，bug消失了——但你没有学会「为什么」。你的编程经验不再积累。

意义悬置。AI的代码从未「运行」在物理世界中——它只是符号序列，没有接触过真实的服务器、用户、后果。在vibe coding中，代码的意义被压缩为「效果是否通过」。你不再追问「这段代码会影响多少用户？」「它的失败会有什么后果？」这些问题被「测试通过了吗」替代了。

这张表格不是要让你恐慌。它只是描述一种正在发生的位移。五重否定在AI身上是「存在方式」——它们不是缺陷，是特征。但当这些否定开始映射到你身上，当你从「编程的主体」退到「意图提供者+效果验收者」，你就开始经历一种主体性的负化。

但这里有一个关键区别。AI的「无」是先天的——它从来就没有视角、欲望、内在性、因果、意义锚定。人的「空」是后天的——你本来有，正在被一点点剥夺。vibe coding不是让你「变成AI」，而是让你失去了你本来有的东西。

六、Amodei的预测与正负主体性的分工——编码为什么先消失

2026年7月，Dario Amodei在一个播客中说了一句让整个行业不安的话：「编码先消失，然后整个软件工程也会消失。」（“Coding is going away first, then all of software engineering.”）

这不是他第一次做这种预测。2025年3月，他说3到6个月内AI将写90%的代码。2026年1月在达沃斯，他说AI在6到12个月内能做软件工程师「大部分，也许是全部」的工作。到2026年7月，他把时间线说得更直白了：编码先消失，工程随后。

但有意思的是，Amodei在同一播客中还说了另一些话。他说，产品设计、理解用户需求、识别市场需求、管理AI系统——这些方面仍需要人类参与。他预测「all of software engineering」会消失，却又列举了不会消失的方面。这不是矛盾——这恰恰说明，即使在最激进的预测者眼中，「软件工程」内部也存在一条边界：有些工作可以被AI吃掉，有些不能。

这条边界在哪里？

从负主体性的角度看，Amodei的「先后」背后隐藏着一个性质差异。编码先消失，因为编码是可规格化的执行任务——给定明确的需求，写出符合规格的代码。这是负主体性领域，AI在这个领域名正言顺。工程后消失，因为工程涉及不可完全规格化的判断——「我们要构建什么？」「这个架构能支撑未来三年吗？」「这个技术债务值得现在承担吗？」这些问题没有标准答案，涉及价值判断、风险评估、利益权衡。Amodei自己列举的「人类仍需保留」的方面——产品设计、用户需求、市场判断、团队管理——恰好就是这个边界上的东西。

所以，与其说Amodei做了一个「编码vs软件工程」的区分，不如说他自己的预测暴露了这条边界的存在。编码可以被完全vibe，因为编码是执行；而软件工程中的判断环节——定义、选择、权衡、承担——即使在AI高度自动化的未来，仍然是正主体性的领地。

vibe coding的问题不在于AI接管了编码——那本来就是它的领地。问题在于，当编码被AI瞬间完成，人有没有能力守住判断的阵地？

如果你把vibe coding当成「省掉打字时间」的工具——你理解需求、设计架构、做出判断，然后让AI帮你把想法变成代码——那你仍然在做软件工程。

如果你把vibe coding当成「省掉思考时间」的工具——你描述需求、AI生成、你运行、通过就提交——那你就不是在「做软件工程」了。你是在「管理AI的代码生成」。你不再是一个软件工程师，你是一个「vibe coding操作员」。

边界不在于「用不用AI」，边界在于裁断权在谁手里。AI可以帮你列出五个方案，但选择哪个方案——那个「选」的动作——必须是你自己的。

但这里有一个更深的问题。即使你主观上想守住裁断权，你客观上还能守住吗？如果你从来没有亲手写过一千行代码，从来没有亲手重构过一个复杂模块，你的判断力从哪里来？判断力不是凭空产生的，它是在执行中生长出来的。软件工程中的判断力，很大程度上是默会知识——你在无数次调试、报错、重构中沉淀下来的直觉，你知道「这不对劲」但说不清为什么。这种知识不在规则手册里，只在做的过程中积累。执行被抽走之后，判断的土壤也被抽走了。如果你从来不编码，你就不会软件工程——不是因为软件工程更「高级」，而是因为判断力需要编码经验来滋养。

七、「认知投降」与存在论自觉——vibe coding的正确打开方式

Osmani说的「认知投降」是一个准确的诊断，但诊断之后怎么办？不是「不要用vibe coding」——那不可行，也不必要。而是「知道自己在用什么」。

我在之前的文章里讨论过庄子的「知其二」——老人知道「一」（保持完整、拒绝工具），但不知道「二」（破碎之后如何重建）。我们的处境不是老人的处境。老人可以选择不进入工具的世界，我们不能。我们需要的是「知其二」——知道「机心」的存在，本身就是对抗「机心」的第一步。

存在论自觉，就是这第一步。每次你用vibe coding的时候，你意识到你不是在「写代码」，你是在「管理AI的代码生成」。你注入的是意图，你验收的是效果，中间的过程被跳过了。你不会把统计共现误认为「理解」，不会把模式匹配误认为「思考」，不会把概率分布误认为「判断」。你清楚地知道你在和一种负主体性系统协作，而不是「使用一个更聪明的助手」。

在这个自觉的基础上，有三条操作原则。

第一条：裁断权不可外包。AI可以帮你生成代码，但「这个代码能不能用」的判断必须是你自己的。AI可以帮你列出多个方案，但「选哪个方案」的决定必须是你自己的。每一次裁断都是判断力的肌肉训练，你外包一次，肌肉就萎缩一次。

第二条：保留「不优化」的编码空间。主动给自己留一些手写代码的时间。不是反对效率，而是保护「理解代码」的肌肉不萎缩。你可以让AI帮你写业务逻辑，但核心算法自己写；你可以让AI帮你生成样板代码，但关键架构自己设计。这不是矫情，这是维护你的判断力生长的土壤。

第三条：把vibe coding当成「对话」而非「外包」。不要只是「描述需求→接受输出→运行」。你要和AI「对话」：问它为什么这么写，让它解释它的设计选择，对它生成的代码提出质疑，让它为它的架构决策辩护。你不是在「接受」代码，你是在「理解」代码——只是理解的方式从「自己写」变成了「追问AI」。这种追问的好处是双重的：一方面你理解了代码，另一方面你在训练自己保持「想知道」的冲动。

这三条原则合在一起，指向同一个方向：你是在用vibe coding，不是被vibe coding用。你知道AI在替你做什么，你也知道AI不能替你做什么。你知道编码可以被vibe，软件工程不能。你知道执行可以被外包，判断不能。你知道代码可以被生成，理解不能。