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

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你会追溯原因理解链条记住教训——你建立了「改这里会影响那里」的系统直觉知道牵一发而动全身。现在你改promptAI重新生成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软件工程不能。你知道执行可以被外包判断不能。你知道代码可以被生成理解不能。结语Osmani的「理解债务」说的不是「你欠了技术债」而是「你欠了自己一笔理解」。这笔债不还你的判断力就会破产。Amodei的预测其实在说有两种存在方式——一种是「执行」你可以外包一种是「判断」你必须自己来。编码先消失因为编码是执行。工程后消失——但Amodei自己也承认有些方面不会消失。那些不会消失的恰好就是判断。下一次你面对AI生成的代码在你按下「Accept」之前问自己一句「我真的知道这段代码在做什么吗如果它出了问题我能修吗」如果你能回答「能」那你在做软件工程。如果你不能那你只是vibe coding操作员。不是「不用AI」不是「回去手写一切」不是怀旧。是在每一次「接受」面前保留一次「自己的判断」。是在AI的流畅输出面前保留一缕「想知道」的冲动。是在统计平均的代码面前保留一点「你的指纹」。那一缕冲动那一次判断那一点指纹——就是你和AI之间最后的、不可被替代的边界。