如果AI接管了80%的编程工作,那剩下的20%究竟是什么?

一：代码从来不是目的，只是我们搞错了70年！

编程正在变成人人都能做的事。

这句话如果让你觉得兴奋，你大概不是程序员。如果让你觉得不安，你大概是。但不管是兴奋还是不安，你可能都漏掉了这句话真正重要的含义——它不在于“人人都能编程”，而在于它暗示了一个我们回避了七十年的事实：

编程从来都不是最重要的那件事。

2025年初，Andrej Karpathy——前特斯拉AI总监、OpenAI创始成员——发了一条推文，描述自己用AI写代码的体验。他说自己“完全沉浸在氛围中，拥抱指数级增长，忘记代码的存在”。他给这种状态起了个名字：Vibe Coding。

这个词迅速出圈了。但大多数讨论停留在表面：又一个AI工具来了，程序员是不是要失业了，未来怎么学编程。

这里指向来一个更尖锐的问题——

你以为你在“编程”，但编程的哪个部分才是真正有价值的那个部分？当AI接管了你80%的日常工作后，剩下的20%里装的是什么？

二：代码的本质是什么？

软件开发的历史，表面上看是语言和工具的迭代史——从汇编到C，从C到Java，从Java到Python，从Python到“嘿Cursor帮我写个API”。但如果你退后三步，只看结构，你会发现一条极其清晰的主线：

每一代进化，都是在把人从“怎么做”推向“做什么”。

汇编时代，你得告诉机器把这个数从这个寄存器搬到那个寄存器。高级语言时代，你可以说“把这两个数加起来”，让编译器操心寄存器的事。框架时代，你可以说“给我一个用户登录页面”，让框架操心HTTP请求的事。

每一次演进都在重复：把一层实现细节压到地板下面，让人在更高的层面上思考要做什么。

Vibe Coding把这个运动推到了一个临界点。它把最后一层实现细节——用特定语法编写代码——也压下去了。人只需要说想做什么，甚至只需要说“我大概想要什么感觉”。

到这里，一个长期被遮蔽的真相就暴露了：代码从来不是目的。它是在技术不够好的年代里，人类不得不承担的一种翻译工作。

你脑子里有一个想法——比如“我需要一个工具来追踪实验数据的异常值”。这个想法是模糊的、充满上下文的、自然语言态的。但机器不懂自然语言。所以你必须当翻译，把想法翻译成机器能执行的形式——也就是代码。

七十年来，这种翻译工作被抬到了不恰当的高度。我们把它叫做“技术能力”，围绕它建立了整套教育体系、招聘标准、职业阶梯和身份认同。一个程序员介绍自己时说“我写Java的”，就像一个翻译说“我做中译英的”——把手段当成了身份。

这不是贬低编程。翻译是一项了不起的技艺。好的翻译需要同时深刻理解两种语言，需要对微妙的语义差异有精确的感知。好的编程同样如此。但是——

但是，当机器翻译达到了足够好的水平时，翻译的价值结构就变了。值钱的不再是翻译能力，而是你有没有值得翻译的内容。

三：代码不重要，但写代码的过程很重要？

如果前面让你觉得“程序员的价值就消失了”，先等一下。事情没有这么简单。

代码不仅仅是翻译的产物。这是我需要自我修正的地方——上面的类比虽然好用，但它遮蔽了一个关键的事实。

写代码的过程，会逼着你把事情想清楚。

什么意思？你有没有这种体验：一个想法在脑子里感觉很清楚，但一旦试着写下来，就发现到处是漏洞？写作的人都知道这个——动笔之前你觉得自己想明白了，动笔之后才发现远远没有。

编程是同样的过程，只是更加严酷。编译器不会给你留面子。当你试图把一个“挺清楚的”想法变成代码，每一个if语句都在问你：这个条件的边界是什么？每一个函数签名都在问你：这个模块到底负责什么？每一个异常处理都在问你：如果这一步失败了怎么办？你的答案不够精确？编译器直接给你一个红色错误。

这种“被迫想清楚”的过程，是写代码一个很重要的隐性价值。

维特根斯坦说过一句话：“我怎么知道我在想什么，在我说出来之前？”套在这里就是：你怎么知道你的需求是什么，在你试着把它变成代码之前？

很多时候，你不知道。需求不是一个完整地躺在大脑里的东西，等着被“表达”出来。需求是在表达过程中才逐步成型的。写代码的过程——那些令人抓狂的debug、那些反复的重构——其实是你在不断发现和修正自己想法中的漏洞。

最终写出来的代码，只是这整个思考过程的记录。它保留了你做过的决定，但丢掉了你做决定的过程——所有的犹豫、所有被否决的方案、所有“试了一下发现不行”的弯路。这也是为什么读别人的代码总是那么痛苦——你看到的是一堆结论，却看不到推理过程。

这就引出了Vibe Coding一个真正值得认真对待的问题：

答案是：不会自动发生。但可以换一种形式发生。

成熟的Vibe Coding使用者已经发现了这一点。真正的工作流不是“说一句话，拿到成品”，而是一个来回打磨的过程。

你粗糙地说出一个想法。AI给你一个东西。你看了之后意识到，“不对，我想要的不是这个……或者说，我以为我想要的是这个，但看到了才知道，我真正想要的是另一个东西”。然后你修正描述。AI再给你一版。你又发现新的偏差。如此往复。

这个过程和写代码时“编译-报错-修改-再编译”的循环，在本质上是一样的。你需要做的思考总量没有减少。只是形式变了——从“写代码时被迫想清楚”变成了“看到结果后发现没想清楚”。

区别在于门槛。写代码需要你先花几百小时学一门编程语言，才有资格进入那个“被迫想清楚”的循环。Vibe Coding把这个门槛降到了“会说话就行”。

所以更精确的说法是：Vibe Coding没有消除思考，它降低了进入思考的门槛。过去只有程序员才能通过写代码来打磨自己的想法，现在任何人都可以通过和AI的对话来做同样的事。

四：Vibe Coding的暗面：AI的创造开始超出人类的理解

现在该说一些让人不那么舒服的东西了。

前面的论述可能给人一种感觉：Vibe Coding很好啊，人人都能创造软件了，思考也没丢失，皆大欢喜。但这里有一个暗面，被热闹的"人人都是开发者"的口号遮住了。

这个暗面是：你能造出一个东西来，但你可能完全不理解它是怎么工作的。

人类文明有一条不成文的规则，古老到几乎没人意识到它的存在——创造者理解自己的创造物。铁匠知道他的刀为什么锋利。木匠知道他的榫卯为什么牢固。建筑师知道他的拱为什么不塌。作家知道她的暗喻在指向什么。

这种联系不是巧合，它是质量控制的根基。你之所以能判断自己造的东西“行不行”，是因为你理解它“为什么行”。

Vibe Coding正在切断这种联系。

一个社会学研究者用AI生成了一个网络分析工具。它能跑。结果看起来合理。但他不知道AI选择了什么算法来做社区检测，不了解该算法在稀疏网络上的已知偏差，不清楚当网络规模扩大十倍时结果是否还可信。

他造出了这个东西，但他不理解它。

你可能会说：没关系，用户不需要理解微波炉的原理也能热饭。区别在于：微波炉是经过几十年工程验证的标准化产品，而AI生成的代码是即兴的、一次性的、没有经过独立验证的，而且每次生成的结果甚至可能不一样。

“造出来的东西超出了自己的理解”这件事，在人类历史上有几次大规模发生。它们的结局都值得深思。

我不是在说Vibe Coding会导致火箭爆炸。我是在说，“造得出来但理解不了”这件事是有代价的，代价的大小取决于你造的东西有多关键。

用AI做一个个人待办工具？不理解它的内部逻辑也完全没问题。用AI做一个帮助医生判断用药方案的工具？你最好非常、非常确定你理解它在做什么。

而真正的危险在于：Vibe Coding让创造变容易了，但理解并没有跟着变容易。能造的东西越来越多，理解的能力还是那么多——这两条线正在分开。在不太重要的场景里，这不是问题。但在关键场景里，这个缺口就是系统性风险的来源。

不过事情也不至于非黑即白。成熟的实践者正在发展一种新的能力：不需要理解每一行代码，但要能判断哪些地方可能出问题。

这不是“读懂代码”，而是“识别风险”。类似于一个好的CEO不需要懂每个部门的业务细节，但必须知道哪些区域藏着可能翻船的隐患。这种经过校准的判断力——什么时候可以信任AI的输出，什么时候必须亲自核查——可能是这个时代最值得培养的能力。

五：什么才是软件人真正值钱的东西

如果你是一个有十五年以上经验的程序员，上一节可能会让你想到一件事：“嘿，识别哪里可能出问题这件事，不就是我一直在做的吗？”

对。这正是我接下来要说的。

AI的训练数据里有什么？GitHub上数十亿行开源代码。Stack Overflow上数百万个问答。技术博客、文档、教程——全是关于“正确的代码长什么样”的知识。

AI的训练数据里缺什么？失败。

具体地说，缺少的是失败的来龙去脉。那段在生产环境里跑了三个月然后在黑色星期五的流量峰值中崩溃的代码——GitHub上只有修复后的版本。那个看起来完美的微服务架构在团队扩张到五十人时变成运维噩梦的过程——没有任何训练数据记录了这个故事。那次因为时区处理的一个微妙bug导致凌晨四点给所有用户发了重复通知的事故——事后复盘文档可能存在于某个公司内网的Confluence里，但不在AI的训练集中。

AI知道什么是好代码。但AI不知道的是：什么样的好代码，在什么条件下会变成灾难。

而这恰恰是一个工作了十五年、二十年的程序员最值钱的东西。

一个资深开发者扫一眼代码就能感觉到问题在哪里：“这个连接池配置在突发流量下会被耗尽。”“这个缓存失效策略在数据一致性要求高的场景里会出事。”“这个重试逻辑没有退避机制，一旦下游服务挂掉会造成雪崩。”

他可能说不清自己是怎么看出来的。那是因为这种能力不是“推理”出来的，是被教训出来的。每一次“我感觉这里有问题”的背后，都是一个凌晨三点被报警电话叫醒、花六个小时追踪一个诡异bug的记忆。这种知识不在教科书里，不在GitHub上，也不在任何AI的训练集中。

所以这里有一个需要被大声说出来的结论：

在Vibe Coding时代，“能写代码”这件事的价值在快速下降。但“知道什么地方会出事”的价值在急速上升。因为后者恰好是AI最弱的环节，也是软件系统可靠性最关键的保障。

一个工作了二十年的后端工程师，他的Java语法知识已经不如AI了。但他见过系统在真实压力下如何一步步走向崩溃。他知道哪些所谓的“最佳实践”在特定情况下其实是陷阱。他能在一个新项目的架构评审中，五分钟内指出三个将在六个月后引发严重事故的设计问题——不是因为他比AI更懂设计模式，而是因为他亲身经历过类似的设计在现实中是怎么出事的。

这种知识不会过时。技术栈每五年换一轮，但出事的模式惊人地稳定。二十年前的分布式系统会因为网络中断丢数据，今天的分布式系统还是会。底层的物理现实——网络不可靠、硬件会坏、人会犯错、需求会变——不会因为编程语言的更新换代而改变。

给年长开发者一个具体的建议：你的新角色不是“用AI写代码的人”，而是“看AI写的代码然后判断哪里会出事的人”。 你的工作不是写代码（AI干这个更快），而是看完AI的输出然后说：“这里有问题。这个设计在数据量到达百万级时会扛不住。这个依赖库去年出过一个安全漏洞，你确定用的是修复后的版本？”

你的手速在贬值。你的判断力在升值。

但——这里有一个真正令人不安的问题——

航空业面对过同样的问题。现代飞行员绝大多数时间在监控自动驾驶——手动飞行的技能在萎缩。2009年法航447航班失事的调查揭示了一个令人寒心的事实：当自动系统在大西洋上空突然失效时，飞行员在关键的几分钟内做出了错误的操纵判断。他们的训练时数不少。但几乎全是在自动系统正常工作的条件下累积的。

软件行业也许该开始想想自己会不会走上同样的路了。

这里面有一个很实在的矛盾：要想有效地使用Vibe Coding，你需要具备一种只有在不使用Vibe Coding的环境中才能练出来的判断力。

这不是一个能靠“加强培训”解决的问题。它可能需要我们重新设计整个技术教育的路径——在让新一代享受AI加速的同时，刻意保留某些“手动操作”的训练环节。不是因为手动操作是常态，而是因为当自动系统出问题的时候，那是唯一的退路。

六：AI写代码不难了！但难的究竟是什么？

前几章讨论Vibe Coding对“做软件的人”意味着什么。这一章想讨论一个不太有人关注但可能更深远的问题：

Vibe Coding会改变软件本身的形态吗？

我认为会。而且变化可能比大多数人预期的更根本。

过去几十年，软件以“产品”的形态存在。Windows是一个产品。Photoshop是一个产品。你买回来（或者订阅），学习它的界面，适应它的逻辑，在它划定的框架内完成你的工作。如果你需要的功能它没有——你等着，或者换一个产品。

这个模式有一个经济上的原因：开发软件非常贵（一个团队几个月到几年的工作），复制分发几乎不花钱。所以软件必须是通用的——一个产品服务一百万人，才能收回成本。用户的个性化需求？对不起，请适应我们的设计。

当创造软件的成本趋近于零时，这个逻辑就站不住了。

想一下这意味着什么。一个生态学研究者需要分析一批特殊格式的野外观测数据——这个需求太小众了，不会有任何商业软件专门做这件事。过去她的选择是：学Python自己写脚本，或者求人帮忙。现在她可以用十分钟让AI生成一个专门处理她这批数据的工具，用完就扔。

“用完就扔”——这四个字背后是一次很大的转变。

软件从“资产”变成了“消耗品”。从一个你购买、学习、长期使用的东西，变成一个为特定任务临时生成、用完就丢弃的东西。不是“一个软件”，而是“做了一次软件”。

这不是小事。整个软件行业的商业逻辑都建立在“软件是资产”的假设上——SaaS的订阅模式、企业软件的采购流程、开源社区的维护文化、技术债务的管理方法。当软件变成消耗品，这些东西全部需要重新想过。

一次性的软件没有技术债务——这听起来是好事，但也意味着你失去了一种重要的学习机会。维护一个长期项目的过程中，你会不断发现当初设计的毛病，这些发现是你提升设计能力的重要来源。用完就扔的软件不给你这个机会。你可能会反复犯同样的错，因为你从来没有活到看到后果的那一天。

更大胆地往前推一步：如果软件可以随时按需生成，那“软件”和“对话”的界限在哪里？

你对AI说：“分析一下这个数据集，重点看季节性趋势，用折线图展示。”AI生成了一段代码，执行了它，把图表呈现给你。请问，在这个过程中，“软件”存在过吗？还是说它只是一次对话中间冒出来的一个临时产物？

也许未来的软件会像电一样——你不关心发电厂在哪里、电是怎么传输过来的。你只关心灯亮了、手机充上了。软件可能会变成同样透明的东西：你只关心你的问题被解决了，至于背后有没有一段代码被生成、执行、然后被丢弃——你根本不需要知道。

这是一个猜想，不是预言。但方向感觉是对的。

七：AI把软件重构成了什么样？四个反直觉的判断！

谁受益？谁受损？

直觉的回答是：不会编程的人受益（终于能做软件了），程序员受损（饭碗不保了）。但仔细想想，事情比这微妙得多。

反直觉1：最大的受益者不是程序员，是各行业的专家。

一个生物信息学家、一个计量经济学家、一个临床研究者——他们有深厚的专业知识，有明确的问题，有真实的需求，过去唯一缺的就是“把想法变成工具”的能力。他们为了一个数据处理脚本去学Python，就像为了钉一颗钉子去读木匠学校——投入和产出完全不成比例。

Vibe Coding精准地补上了这个缺口。而且这些人可能是最好的Vibe Coding用户——因为他们有真正值得解决的问题。记住前面说的：在AI能帮你翻译的时代，值钱的不是翻译能力，是你有没有值得翻译的内容。这些专业人士正是那些“有很多值得说的话”的人。

反直觉2：受冲击最大的不是刚入行的程序员，是中间水平的程序员。

刚入行的人还在学习。Vibe Coding对他们来说是一个学习加速器——他们可以通过和AI协作来更快地理解系统、更快地做出东西。他们的薪水本来就不高，公司对他们的期望主要是学习和成长，而不是产出。

高水平的程序员——我前面说过——他们的价值在于系统层面的判断力和从踩坑中积累的经验。这些不是AI短期内能替代的。

被夹在中间的是那些已经具备了“按照需求文档快速实现功能”的能力，但还没有建立起深层系统理解的程序员。这恰好是大语言模型做得最好的事——给一个明确的规格，快速准确地实现它。他们最核心的竞争力，正在被AI直接取代。

反直觉3：年长的开发者可能比年轻的适应得更好。

前提是他们愿意接受角色的转变。

年轻开发者的身份认同往往紧紧绑定在“我能写代码”上——这是他们最近几年最引以为傲的技能，也是他们进入行业的敲门砖。当这块砖突然不值钱了，身份冲击是巨大的。

年长开发者经历过的技术更替更多——从Perl到PHP到Node.js，从虚拟机到容器到Serverless。他们中的很多人早就学会了“不要把自己绑在某个特定技术上”。而且，他们最大的优势——系统理解和失败经验——在新的时代里不仅没有贬值，反而更加稀缺。

但这有一个严格的前提：你得愿意从“亲手写代码的人”变成“审查和判断代码的人”。 如果你坚持亲手写每一行代码，你是在和AI比手速，你会输。如果你转向“AI写，我看”，你就是在利用AI无法获得的经验。

反直觉4：管理者面对的难题可能比工程师还大。

当一个人加上AI就能干过去一个小团队的活时，技术管理的整套做法都得重来。怎么评估产出——看代码行数？看功能交付速度？看设计决策的质量？怎么组建团队——需要更少的人，但每个人都得有更强的判断力？怎么做技术选型——当AI可以在十分钟内拿出三个不同方案时，选择变得更容易了还是更难了？（多半是更难了——因为选项变多后，你需要更强的判断力来分辨哪个是真的好，哪个只是看起来好。）

八：Vibe Coding对未来的冲击是什么？

不思考未来的人会被未来碾过，但是对未来做单一预测几乎必然是错的。

所以我不做预测。我画三种可能的情形。水最终流向哪一条河道，取决于很多我们现在无法确定的变量——AI能力的增长速度、监管的发展、意料之外的事件。

第一种可能：人依然掌舵。

AI成为了强大但可控的工具，类似于CAD之于建筑师。建筑师用CAD画图比手绘快十倍，但设计的核心——空间感、功能性、美学——仍然在人的手中。程序员变成了“有AI加持的系统设计师”。软件质量上升，创造效率飙升，但“你得理解你造的东西”仍然是行业的基本职业操守。这种情况的前提是AI能力保持渐进式增长，留给人类足够的适应时间。

第二种可能：理解跟不上创造。

AI能力的增长速度超过了人类的适应速度。AI生成的系统越来越复杂，能理解底层运作的人越来越少。社会分成两层：少数能理解技术的人成为新的技术精英，多数人在自己不理解的技术基础设施上工作和生活。多数时候没有问题——就像多数人不理解电网但正常用电。但当出问题的时候，问题的规模和不可预见性也是前所未有的。

第三种可能：软件这个概念本身消失。

最激进的设想。AI发展到可以实时理解和执行用户意图的程度。“软件”作为一个你能看到、能下载、能安装的独立东西——不再存在。交互变成了纯粹的对话：你说你要什么，世界就响应了。代码变成了背后一闪而过的临时产物，生成即执行，执行完就没了。“程序员”这个职业像“抄写员”一样融入历史——不是因为没人做了，而是因为人人都在做，它不再是一个需要单独存在的角色。

三种可能不互斥。更现实的情况大概是：不同重要程度的领域走向不同的结局。核电站的控制系统走第一种（绝对的人工控制），个人效率小工具走第三种（完全的AI自动化），中间大量的业务系统走第二种（不完全理解但大多数时候能用）。

但不管最后走到哪里，有些东西不会变：

把问题想清楚的能力。在矛盾中做取舍的判断力。对系统整体行为的直觉。知道什么地方会出事的经验。把不同领域的知识拧到一起的能力。以及——也许最重要的——判断什么问题值得去解决的能力。

AI可以实现你描述的任何东西。但它不会告诉你应该去做什么。

九：关于软件，三种可能的结局

我们把“写代码”和“做软件”混为一谈了七十年。Vibe Coding把它们拆开了，让我们第一次清楚地看到：做软件这件事里面，真正有价值的部分从来不是写代码。

那个有价值的部分是什么？是把一个模糊的想法变成清晰方案的能力。是在互相矛盾的需求之间做取舍的判断力。是知道什么东西看起来没问题但三个月后会炸的经验。是对“好”的直觉——不止于“能跑”，而是在正确性、可靠性、好不好用之间找到恰当的平衡。

这些能力不需要你会写代码。但它们需要你会思考。

对于在学术界工作的读者——你们有一个被低估的优势。科研的核心训练——在模糊中定义问题、在数据中分辨信号和噪声、在不确定性中做判断——和Vibe Coding需要的核心能力是相通的。你们过去缺的只是"把想法变成代码"的技术能力，现在AI帮你补上了。但请记得前面说的风险——用AI生成工具的时候，花时间搞清楚它的逻辑和局限，跟花时间生成它一样重要。

对于资深开发者——你值钱的东西变了。从“我能写出高质量代码”变成“我能看出哪里会出问题”。别和AI比手速，用你的判断力。那是二十年的坑换来的东西，短期内没有替代品。

对于年轻开发者——别跳过基础。至少在一个领域——操作系统、数据库、分布式系统——扎扎实实地积累第一手经验。你需要自己踩过足够多的坑。Vibe Coding能让你跑得更快，但你得先有东西可以加速。

最后，一种能力我必须要提：

判断什么值得去做！

AI可以用任何语言、任何框架、任何架构，实现你描述的任何东西。它在“怎么做”这件事上即将变得无所不能。但它完全不碰“该不该做”这个问题。该不该做这个产品？这个功能真的帮到了用户，还是只是在制造依赖？这个技术方案在伦理上站得住脚吗？

这些问题不是技术问题。它们是人的问题。关于价值的问题。关于我们想要生活在什么样的世界里的问题。

在一个机器能写任何代码的时代，这些问题不仅没有被自动化——它们变得比以往任何时候都更加重要。

因为创造的门槛降低了，但“为什么要创造”并没有变轻。

*原文已首发于黄大年茶思屋科技网站，点击“阅读原文”了解更多网站精彩内容。