引言：一场静悄悄的工业革命
让我们从一个场景开始。
你打开终端旁边的 AI 对话框，输入了一段话：
“@code 帮我写一个xx的网站，要用xx+xx技术栈，使用 docker compose 部署，要有xx功能，使用xx样式，记得用 Tailwind CSS，要考虑中国大陆地区访问性。”
然后你靠在椅背上，看着屏幕上的光标开始跳动。
“正在思考… 正在创建文件 main.rs… 正在创建 next.config.js… 正在创建 page.tsx… 正在创建 Dockerfile…”
十五分钟后，AI 为你生成了八千多行代码，外加一条 docker compose up -d --build 的单行命令。你把这行命令复制粘贴到终端里，按下回车。容器拉起，端口映射完成，浏览器里刷出了一个崭新的、带有完整前后端和数据库的网站。一个最小可行产品，就这样诞生了。
整个过程中，你没有手写哪怕一行代码。
如果你是一位经历过互联网技术变迁全程的从业者，此刻你或许会感到一种似曾相识的、裹挟着兴奋与不安的复杂情绪。这种感觉，与十五世纪中叶美因茨城里的抄写员，在第一次看到古腾堡印刷机以惊人的速度”复制”出一页《圣经》时所感受到的，或许并没有本质的不同。一项新技术，以一种近乎粗暴的方式，将某种曾经需要高度专业技能和大量时间投入的工作，压缩到了一个令人瞠目结舌的时间尺度之内。
这股浪潮，如今有了一个专属的名字——Vibe Coding。
“Vibe Coding”这个词，最初由 Andrej Karpathy 在 2025 年初提出，其核心含义极其直白：你不再”编写”代码，你只是向 AI “描述”你想要的东西——你传达的是一种”感觉”（Vibe），然后由 AI 来将这种感觉物质化为可以运行的程序。这个概念一经提出便席卷了整个技术社区，它精准地捕捉到了一种正在发生的、深层次的范式迁移：软件开发的核心瓶颈，正在从”代码的生产”向”意图的表达”和”产物的治理”转移。
然而，围绕着这场范式迁移，互联网上迅速形成了两个对立的阵营，我姑且将它们称为”速胜派”与”速败派”。速胜派是狂热的技术乐观主义者，他们宣告”程序员已死”，认为 AI 将在短期内彻底取代人类开发者。有趣的是，ChatGPT 从三年前就开始被人用来预言”它将取代人类的工作”，结果到了 2026 年，被取代的似乎是 ChatGPT 自己在某些场景下的地位——Claude、Gemini、DeepSeek 等后来者纷纷崛起，在编程辅助领域各领风骚——而程序员们，依然坐在他们的工位上。
速败派则走向了另一个极端，他们是顽固的保守主义者，将 AI 视为不过是一个花哨的”高级自动补全”玩具，坚信”真正的好代码还得靠人一行一行写出来”。他们有意或无意地忽视了一个越来越难以忽视的事实：AI 生成基础代码的速度已经快到足以改变游戏规则，并且在定义明确的小型、模块化任务上，其完成率和代码质量已经超过了相当比例的人类初中级程序员。
这两个阵营，一个高估了颠覆的速度，一个低估了颠覆的深度。他们各自抓住了真相的一个碎片，却都未能拼出完整的图景。
正如我在先前的文章《AI 纪元下，教育模式的新大陆》中论述过的：AI 时代，单纯考察基础知识记忆力的价值已经趋近于零。当一个 AI 花三秒钟就能完整、准确地召回你需要费劲背诵半天才能磕磕巴巴说出来的 HTTP 状态码全表时，对这张表的记忆能力本身就不再构成任何竞争优势。这类”人肉数据库”式的工作，无需、也不应再由人类来承担。AI 是有史以来最强大的知识检索和基础技能代偿工具。承认这一点，是我们讨论一切后续问题的逻辑起点。
那么，在 Vibe Coding 甚嚣尘上的今天，到底什么才是真正重要的技能？ 当代码的”生产”本身不再是核心壁垒时，人类开发者——以及更广泛地说，所有希望利用软件来解决问题的人——应该将自己的技能树点在哪里？
本文试图对这个问题给出一个系统性的回答。我将论述三项在 Vibe Coding 时代变得至关重要的核心能力：精确表达能力、需求洞察能力，以及审查与治理能力。这三项能力并非彼此割裂，而是构成了一条从”意图的产生”到”意图的传达”再到”产物的质量保障”的完整价值链。理解这条价值链，就是理解人类在 AI 时代的不可替代性之所在。
1. 精确表达能力：从”说人话”到”说对话”
1.1 一条 Prompt 的解剖学
现在，让我们回到文章开头的那条 Prompt，但这一次，我们不再把它当作一句随意的吩咐来看，而是用一把手术刀，对它进行一次精细的解剖。
“@code 帮我写一个xx的网站，要用xx+xx技术栈，使用docker compose 部署，要有xx功能，使用xx样式，记得用Tailwind CSS，要考虑中国大陆地区访问性。”
这短短一句话中，每一个被一笔带过的短语，背后都凝结着一个人类必须做出的判断和决策。
当你写下”要用 xx+xx 技术栈”的时候，你做出的是一个技术选型决策。为什么是 Rust 后端加 Next.js 前端，而不是 Go 加 Vue，或者 Python Flask 加纯 HTML？这个决策背后是你对项目性能需求、团队（或者你自己）的技术储备、生态系统成熟度、以及长期可维护性的综合评估。AI 可以在你选定之后，用任何一种技术栈帮你生成代码，但它无法替你做出”选哪一种最适合这个特定项目”的决策，因为这个决策依赖于大量 AI 并不了解的、关于你、你的团队和你的业务的语境信息。
当你写下”使用 docker compose 部署”的时候，你做出的是一个运维架构决策。你排除了裸机部署、Kubernetes、Serverless 等其他选项。这个判断基于你对项目规模的预期——一个小型项目用 Kubernetes 就像用航空母舰去池塘钓鱼——以及对部署环境的了解和对运维复杂度的容忍度。
当你写下”要有 xx 功能”的时候，你进行的是一次需求提炼。在现实世界中，这些功能需求往往不是凭空冒出来的，它们来自客户的嘴里，来自市场调研的报告里，来自竞品分析的表格里。而客户的原始需求，几乎从来都不是以”功能列表”的形式呈现的。它们是模糊的、矛盾的、甚至连客户自己都没想清楚的。从那团混沌中提取出”xx功能”这几个字，本身就是一项高价值的人类智力活动。
当你写下”使用 xx 样式”的时候，你进行的是一次审美判断与视觉表达。你脑海中有一幅关于这个网站”应该长什么样”的图景，你需要把这幅图景翻译成文字。这要求你不仅拥有审美能力——知道”什么是美”——更要求你拥有描述审美的语言能力——能够精确地告诉别人（或 AI）”美在哪里”。”我想要那种感觉”对人类同事来说已经够模糊了，对 AI 来说则是完全无法执行的指令。
当你写下”记得用 Tailwind CSS”的时候，你做出的是另一个层面的具体技术栈选型。这意味着你了解 CSS 工具的生态格局，知道 Tailwind 的 utility-first 哲学与 Bootstrap 的组件化哲学之间的差异，并且判断 Tailwind 更适合本项目的开发模式和审美需求。
当你写下”要考虑中国大陆地区访问性”的时候，你表达的是一个特定用户群体的约束条件。这短短几个字，背后隐含着一整套技术决策：CDN 的选择（国内 CDN 还是有中国节点的海外 CDN？）、字体文件的加载策略（Google Fonts 在大陆的可访问性问题）、第三方服务的可用性（reCAPTCHA 替换为国内验证方案、Google Analytics 替换为友盟或百度统计）、甚至 ICP 备案的合规需求。如果你不写这一句，AI 会按照全球通用的、默认以北美或西欧用户为中心的惯例来执行——而这对你的中国大陆用户来说，可能意味着一个首屏加载需要十几秒、一半资源被防火墙拦截的灾难性体验。
Prompt——那条自然语言指令——是人类决策层和 AI 执行层之间唯一的接口。它的质量，直接决定了 AI 输出的质量。而这条 Prompt 的质量，完全取决于人类的精确表达能力。
1.2 为什么跟 AI 说话不能像跟人说话一样
此时，一个看似合理的反驳可能会出现：AI 不是越来越”聪明”了吗？它不是越来越能”理解”自然语言了吗？为什么我不能像跟人说话一样跟 AI 说话呢？
这个反驳的问题在于，它混淆了两种截然不同的沟通机制。当你跟一个人类同事说话的时候，你们之间存在着大量的共享语境。你们在同一个公司工作，了解同一个项目的背景，参加过同一个会议，甚至分享着同一个行业的”常识”和”默认规则”。当你对人类同事说”把这里这样一下”的时候，你的同事可以基于你们共享的语境，去推断你的意图——虽然这种推断也经常出错，但至少它有一个基础。
而你和 AI 之间，除了你在当前对话中输入的文字之外，几乎不存在任何共享语境。AI 不知道你的项目处于什么阶段，不知道你的公司文化偏好什么风格，不知道你的老板昨天在会议上拍板了哪些决定，不知道你上周五和客户的那通电话里讨论了什么隐含需求。它拥有的全部信息，就是你输入的那些文字。这意味着，你给 AI 的指令中，每一个未被明确说出的信息，AI 只能根据其训练数据中的统计分布去”猜测”——而这种猜测，就是按照最常见的惯例、最通用的做法去执行。如果你的需求恰好符合这些惯例，那你很幸运；如果不符合——而真实项目中的需求，往往充满了各种偏离惯例的特殊要求——那你得到的就会是一个”差不多”但”不对味”的产物。
让我们来看看现实世界中那些”跟人说话”的经典场景，然后想象一下如果这些话被输入到 AI 的对话框中会发生什么：
“把这里这样一下。” ——”这里”是哪里？”这样”是哪样？对人类同事来说，如果你们俩正看着同一个屏幕，你的手指指着某个地方，同事或许能猜到。对 AI 来说，这句话的信息量为零。
“你没有我要的那种感觉。” ——什么感觉？”高级感”？”科技感”？”温暖感”？”日系小清新感”？每一种”感觉”都对应着截然不同的配色方案、字体选择、间距设计和动效节奏。如果你不能把”感觉”翻译成这些具体的视觉参数——至少是更具象的描述性语言——AI 只能一遍又一遍地给你随机生成不同的方案，变成一个低效的”猜数字”游戏。
“我觉得你这里应该要实现什么什么。” ——”什么什么”究竟是什么？一个模糊的手势？一段欲言又止的停顿？人类同事可能会追问：”你的意思是不是……？”AI 也会追问，但它的追问是基于概率模型的推断，如果你的”什么什么”本身就是一团模糊的意识，AI 的追问只会把你们俩一起带进更深的模糊之中。
这些场景，如果发生在产品经理的微信聊天框中，至少还有一个人类在对面，这个人类可以根据自己的经验、对项目的理解、甚至对你这个人的了解，去主动补全你表达中缺失的信息。但如果这些话被输入到 GitHub Copilot 的 Agent 模式对话框中呢？只会是灾难性的。
AI 是一个执行力惊人但零共享语境的合作者。跟它协作的质量上限，完全由你的表达精度决定。
1.3 知识的诅咒
“拥有合格的表达能力，让别人能搞懂你想要什么”——听起来就像在饭馆里点菜一样简单，是一项人类的基础技能。但现实是，真正拥有这项能力的人，比大多数人想象中的要少得多。
这背后有一个深刻的认知学原因，心理学上称之为”知识的诅咒”。这个概念描述的是一种普遍的认知偏差：当一个人已经知道了某件事情之后，他就极其难以想象自己不知道这件事情时的认知状态。一个深谙项目来龙去脉的技术负责人，在向 AI（或新同事）描述需求时，会不自觉地省略掉大量他认为”显而易见”的背景信息，因为在他的认知世界里，这些信息确实是显而易见的。但对于一个对此一无所知的接收者——无论它是人还是 AI——这些被省略的信息恰恰是理解整个需求的关键拼图。
真正优秀的表达能力，要求你具备一种”认知降维”的能力——你需要跳出自己的知识框架，站在一个对你正在谈论的事情完全不了解的接收者的角度去审视你的表达。你需要问自己一系列问题：一个不在我脑子里的人，能从我说的这些话中获取到足够的信息吗？对方最有可能在哪里产生困惑？对方最有可能提出什么问题？以及——这是最致命的一点——这个项目中有哪些跳出常规的、反直觉的需求，如果我不主动说出来，对方会直接按照惯例或者常识去执行？
在沟通中，成功的沟通依赖于双方的”共识语境”——即双方都已知的、不需要额外解释的共享知识库。而沟通失败的根源，往往在于沟通者未能识别出双方之间的”非共识语境”——即那些只存在于一方认知中、而另一方并不知晓的信息。精确表达的核心技能，归根结底，就是识别并主动弥合非共识语境的能力。
让我们用一个具体的例子来说明。假设你要让 AI 为你搭建一个博客系统。如果你只说”帮我做一个博客”，AI 会按照最通用的博客模板来做：一个文章列表页、一个文章详情页、一个 Markdown 渲染器，可能再加一个评论区。这是”惯例”。但你心里可能有一系列完全跳出惯例的特殊需求：你希望文章按”系列”而非”分类”来组织；你需要支持 LaTeX 数学公式渲染；你的评论系统必须是基于 GitHub Issues 的（比如 utterances），因为你不想维护一个数据库；你的部署目标是 Cloudflare Pages 而非传统 VPS；你甚至希望每篇文章的 URL 结构是 /文章/文章标题 这种中文路径，而不是 /posts/article-title。这些需求中的每一个，如果你不主动、明确地说出来，AI 就会按照它训练数据中最常见的做法——也就是”惯例”——去执行。你最终得到的，将是一个”标准的”但”不是你想要的”博客。
这就是精确表达能力的核心：不仅要说出你”想要什么”，更要说出你”不要什么”，说出那些”如果你不说，对方会默认替你选择”的东西。
1.4 Vibe Coding 的民主化
精确表达能力的重要性，还有另一个含义——它将重新定义”谁可以创造软件”。
在传统的软件开发范式中，从一个想法到一个可运行的软件产品，中间横亘着一道名为”编程能力”的巨大壁垒。你可能有一个绝妙的想法，但如果你不会写代码，你要么得花钱雇程序员，要么得花时间学编程，要么——最常见的情况——你的想法就停留在了想法阶段，永远不会变成现实。
Vibe Coding 正在拆除这道壁垒。
当一个拥有合格表达能力的人可以在 15 分钟内通过与 AI 的对话来生成并上线一个功能完备的网站或应用时，一个巨大的新市场将被释放出来。即”原本不会被做成软件的软件”的市场。
想想看：在 Vibe Coding 之前，有多少需求因为”做成软件太麻烦”而被人们用 Excel 表格、Word 文档、甚至微信群聊来凑合解决？一个小型硬件公司的定制化售前报价系统——销售人员一直在用一个嵌套了无数 IF 公式的 Excel 表格来做报价，每次产品线更新都得手动修改公式，偶尔还会出错；一个实验室的定制化仪器监控面板——研究生们用一个 Python 脚本把数据打印到终端里，然后用肉眼盯着看；一个小学教师为一堂公开课制作的互动课件——她花了一整个周末在 PowerPoint 里用自选图形和超链接模拟一个”点击答题”的效果，费力且效果粗糙；一个社区志愿者组织的活动报名和签到系统——他们一直在用共享的在线文档，经常出现信息被误删、报名人数统计混乱的问题。
这些需求，在传统范式下，每一个都需要找到一个程序员（或者一个会编程的人），花费数天到数周的时间来开发。这个成本对于上述场景来说，往往是不合理的、不经济的。所以人们选择了凑合。
但在 Vibe Coding 时代，这些需求的实现成本被压缩到了接近零。只要你能清楚地描述你要什么——那个小型硬件公司的销售经理，如果他能说清楚”我需要一个网页，左边选产品型号和配件，右边实时显示报价，报价规则是这样这样这样的”——AI 就能在几分钟到几十分钟内帮他生成一个可用的应用。
在这个新的世界里，软件的生产者将不再仅仅是程序员。他们将是那些最接近真实需求、同时又拥有合格表达能力的人：教师、销售、科研人员、设计师、运营人员……他们可能永远不需要理解递归是什么，不需要知道红黑树怎么旋转，但他们需要能够把自己的需求——那些只有他们自己才真正理解的、深嵌在他们日常工作场景中的需求——清晰、完整、精确地表达出来。
这不是程序员的末日。这是软件民主化的黎明。而精确表达能力，就是这场民主化运动中的”选票”——你不需要懂得如何建造投票站（编写代码），但你需要清楚地知道你要投给谁（你想让 AI 做什么），并且能够准确无误地在选票上标记出来。
2. 需求洞察能力：”产品经理的微信聊天框”
2.1 基础编程
在讨论第二项能力之前，我们需要先面对一个让很多人——尤其是以”手艺人”身份自居的程序员——感到不舒服的现实。
基础编程能力——也就是那些曾经构成程序员日常工作的核心内容：写一个函数、实现一个算法、补全一段逻辑、写一个页面、封装一个类——在 Vibe Coding 时代，正在以肉眼可见的速度被 AI 商品化。所谓”商品化”，是指一种能力从稀缺的、有差异化价值的资源，变成了廉价的、同质化的、随手可得的基础设施。就像电力从一百多年前的高科技奢侈品，变成了今天你按下开关就理所当然拥有的东西。
如果你在 2026 年的 Vibe Coding 环境中，面对一个可以用 AI 在 30 秒内生成的函数，仍然坚持打开编辑器，手动敲入每一个字符，花 15 分钟把它写出来——然后把这称为”工匠精神”——我没有办法认可你。那不是工匠精神，那是愚蠢。 就像在古腾堡印刷机已经普及的时代，还有抄写员坚持用鹅毛笔一笔一划地抄写书籍，声称自己的手写字体更有”灵魂”。他的字可能确实更美，但他也确实是在以一种不可持续的方式与历史的洪流对抗。他是——让我们直说——被 Vibe Coding 时代的大船所抛弃的人。
请注意，我这里说的是”基础编程”，是那些 AI 已经能够高质量、高效率完成的、定义明确的编码任务。我绝不是说”所有编程”都被取代了。恰恰相反，当基础编码这个”体力活”被外包给 AI 之后，程序员需要聚焦的”脑力活”变得更加清晰和纯粹。而这个”脑力活”的核心，就是我们接下来要讨论的需求洞察能力。
2.2 程序员的新身份
在上一章中，我们讨论了精确表达能力，论证了”跟 AI 说话需要用精确的、技术性的语言”。但一个紧接而来的问题是：在现实世界的软件工程中，谁来承担这个”精确表达”的角色？
在传统的软件开发流程中，存在一个关键角色——产品经理。产品经理的核心职责，用一句话概括，就是将客户模糊的、甚至自相矛盾的原始需求，翻译成清晰的、可执行的技术需求文档。他们是客户的嘴巴和开发团队的耳朵之间的桥梁。他们需要听懂客户那些絮絮叨叨的、充满了行业黑话和个人偏好的”废话”，从中提取出真正有价值的需求信号；他们需要识别出客户”说了但没说清楚”的部分，主动追问和确认；他们更需要敏锐地发现客户”没说但实际上需要”的部分——那些客户自己都没有意识到的隐含需求——并将其补充进去。
现在，请闭上眼睛想象一下 Vibe Coding 时代的软件开发流程。每个人——无论他是程序员、设计师、产品经理还是完全没有技术背景的业务人员——都可以直接和 AI 对话来生成软件。在这个场景中，每个人都有了一个能力顶尖但不怎么听人话的”程序员”可以随时调用。那么，此时真正的瓶颈在哪里？
瓶颈不在于”谁来写代码”，而在于”谁来决定写什么代码”。
而”决定写什么代码”这件事，恰恰就是传统产品经理一直在做的事情。只不过，传统产品经理把翻译后的需求交给人类开发团队去执行，而 Vibe Coding 时代的”新产品经理”把翻译后的需求以 Prompt 的形式交给 AI 去执行。执行者变了，翻译者的角色不仅没有消失，反而变得更加重要。
这就是我说的，在 Vibe Coding 时代，程序员在某种程度上需要转型成产品经理。或者更准确地说，程序员需要将自己的核心价值从”代码的书写者”重新定位为”需求的洞察者”——站在客户的微信聊天框和 AI 的对话框之间，成为连接人类模糊意图与 AI 精确执行之间的那座桥梁。
Vibe Coding 时代并没有消除”需求翻译”这个环节，它只是把”代码实现”这个环节压缩成了近乎瞬时的 AI 执行。而由于执行速度的极大提升，”翻译”环节的质量和效率就成为了整个流程中最大的瓶颈和最高的杠杆点。一条精准的 Prompt 可以在 15 分钟内生成一个完美匹配需求的产品；一条模糊的 Prompt 则会导致你花 3 个小时反复修改、反复推倒重来，最终得到一个仍然让你不满意的东西。这 3 个小时的浪费，不是 AI 的执行力问题，是你的需求洞察力问题。
2.3 需求洞察能力的三个维度
那么，”需求洞察能力”究竟包含些什么？我将其拆解为三个相互关联的维度。
第一是”听懂话外音”的能力——从客户说的话中提取他没说的需求。 这是需求洞察最基础也最微妙的一层。客户说”我想要一个用户注册功能”，表面上看需求很清晰——做一个注册页面，有用户名和密码输入框，存到数据库里。但一个有需求洞察力的人会追问：需要邮箱验证吗？需要手机号注册吗？需要支持第三方登录吗？注册后需要自动登录还是跳转到登录页？密码的强度策略是什么？有没有防机器人注册的需求？需要记录用户注册来源以便后续做渠道分析吗？这些问题，客户在说”我想要一个注册功能”的时候，大概率完全没有想过。但如果你不问、不想，直接把”做一个注册功能”扔给 AI，你得到的就会是一个最简版的、缺胳膊少腿的注册页面，然后客户看了会说”不对，我以为你会自动加上手机验证的”。
第二是”识别矛盾”的能力——在客户的需求中发现逻辑上或技术上的冲突，并做出权衡。 客户经常会提出互相矛盾的需求而不自知。”我想要一个加载速度极快的网站，同时首页要有一个全屏的、自动播放的高清视频背景。”——这两个需求在很大程度上是矛盾的。一个有需求洞察力的人不会把这个矛盾原封不动地转交给 AI（AI 可能会生成一个”既放了视频又试图优化加载速度”的奇怪折中方案），而是会主动向客户指出这个矛盾，讨论优先级，提出替代方案（比如视频懒加载、或者用动态生成的 CSS 动画代替视频），然后带着一个经过权衡的、内部一致的需求去和 AI 对话。
第三是”预见未来”的能力——不仅理解客户现在要什么，更能预判他将来会要什么。 这是最高层次的需求洞察，也是将”普通产品经理”和”卓越产品经理”区分开的关键。客户说”我现在只需要支持中文”。一个缺乏远见的人会让 AI 把所有文本硬编码成中文字符串。一个有需求洞察力的人会想：这个产品有没有可能在未来拓展到海外市场？如果有这个可能性——哪怕可能性不大——那么在架构层面做好国际化（i18n）的准备，其边际成本在项目初期几乎为零，但如果等到将来需要时再改，成本将是巨大的。他会在 Prompt 中加上一句”请使用 i18n 框架处理所有文本，初始语言为中文”——这一句话的增量成本几乎可以忽略，但它为未来的扩展保留了一个优雅的通道。
这三个维度——提取隐含需求、识别需求矛盾、预见未来变化——共同构成了需求洞察能力的完整图景。它们的本质，是一种对人类需求的深度理解和前瞻性思考。这种能力，AI 在目前和可预见的未来都无法具备，因为它植根于对人类社会、商业逻辑和现实世界的复杂理解之中——这些都远远超出了”在训练数据中找到最可能的下一个 token”所能触及的范畴。
3. 审查与治理能力：谁来”坐牢”
3.1 OpenClaw 事件
如果前两项能力——精确表达和需求洞察——解决的是”如何让 AI 生成你想要的代码”的问题，那么第三项能力要解决的，就是一个更加严峻和根本性的问题：AI 生成的代码，你敢信吗？
为了回答这个问题，让我们来审视一个真实的、在过去几个月里搅动了整个技术社区的项目——OpenClaw 。
OpenClaw 是 2026 年爆火的一个开源项目。它本身就是一个 AI Agent——一个如果加以配置，能够自主阅读邮件，查天气，写文档，操作你的文件的 AI 程序。这个项目因”飞书里的赛博同事”的气质而迅速走红，成为了 Vibe Coding 时代精神的某种象征。它引来了海量的关注和流量。
而正是这海量的流量，点燃了一根导火索。
既然 OpenClaw 本身就是一个 AI Agent，一个显而易见的、极具流量吸引力的想法在无数人的脑海中同时闪过：”如果我用 OpenClaw 自己来给 OpenClaw 提一个 PR，并且成功被合并了呢？” “用龙虾修改自己”，”AI 为自己打补丁”——这些标题简直是为社交媒体量身定做的病毒式传播内容。于是，大量的人——其中很多人对代码质量和项目维护毫无概念——开始用各种 AI Agent 向 OpenClaw 的代码仓库疯狂地提交 Issues 和 Pull Requests，目的不是为了改进项目，而仅仅是为了蹭流量和社会影响力。
结果是灾难性的。OpenClaw 的代码仓库在短时间内涌入了海量的、由 AI 生成的、未经人类认真审查的代码变更。项目的代码量以远超任何人类维护者所能审查的速度膨胀。代码之间的冲突、逻辑矛盾、以及更危险的——安全漏洞——开始像杂草一样在代码库中疯长。很快，多个权威安全研究机构和安全研究人员发布了针对 OpenClaw 代码库的漏洞报告和安全警告。一个曾经充满前沿探索精神的项目，在 Vibe Coding 狂热和流量驱动的双重催化下，迅速演变成了一个安全隐患的重灾区和一个大型的反面教材。
OpenClaw 事件并非孤例，但它以一种极其戏剧化的方式，将 Vibe Coding 的一个根本性缺陷暴露在了聚光灯下。
3.2 局部最优陷阱
为什么 AI 生成的代码会出问题？它不是比大多数人写得更好吗？
这个问题的答案，需要我们深入理解 AI 代码生成的底层工作模式。
AI，无论是 Claude、Gemini、GPT 还是 DeepSeek，在生成代码时，其核心运作机制可以被概括为：在当前会话的有限上下文窗口中，针对用户此刻提出的这个特定需求，寻找一个最优（或接近最优）的解决方案。 关键词有两个：”有限上下文”和”此刻的特定需求”。
让我们仔细思考这意味着什么。
“有限上下文”意味着 AI 只能”看到”你在当前会话中提供给它的信息，以及它通过工具调用读取到的、有限数量的文件。对于一个大型项目——可能有数十万甚至数百万行代码，分布在成百上千个文件中——AI 在任何一个时间点上只能理解其中的一小部分。它无法像一个在这个项目上工作了三年的资深工程师那样，对整个代码库的架构、各个模块之间的依赖关系、历史上踩过的坑和做出的设计妥协，拥有一种全局性的、直觉性的理解。AI 看到的是”一棵树”或者”一小片林子”，而不是”整个森林”。
“此刻的特定需求”意味着 AI 的优化目标是完成你眼前的这个任务。它不会——也没有能力——主动去思考：这个改动对项目三个月后的可维护性有什么影响？这个改动是否符合项目团队一直遵循的编码规范和架构约定？这个改动是否会与另一个正在并行开发的功能产生冲突？这个改动是否引入了一个在特定边缘条件下才会触发的安全漏洞？
这两个特性叠加在一起，产生了一个“局部最优陷阱”的问题：AI 总是倾向于在它所能看到的有限范围内，为眼前的任务找到一个”最好”的解决方案。但这个”局部最优”的解决方案，放在项目的全局视角下审视，很可能是次优的、有害的、甚至是危险的。
让我举一个具体的例子来让这个概念更加形象。假设你有一个 Web 应用，其中有一个用户认证模块，已经使用 JWT实现了一套完整的认证流程。现在你让 AI 新增一个”管理员后台”功能。AI 在分析你给它的上下文——可能是当前的路由文件和几个相关的页面组件——之后，可能会判断”最快完成这个任务”的方式是为管理员后台实现一个独立的、基于 session-cookie 的认证机制。从”完成管理员后台的认证”这个局部任务来看，这个方案完全可行，代码也写得很漂亮。但从项目全局来看，这意味着你的应用现在同时存在两套完全不同的认证机制——JWT 和 session-cookie——这不仅增加了维护的复杂度，也扩大了安全攻击面，还违反了项目架构中”所有认证走 JWT 中间件”的约定。这就是一个典型的”局部最优，全局有害”的案例。
更危险的是，这种”局部最优”的问题具有累积效应。如果你连续进行 100 次这样的 Vibe Coding 迭代，每一次 AI 都做出了一个”局部最优”的决策，这 100 个局部最优决策累积起来的结果，很可能是一个架构混乱、风格不一致、充满隐患的、全局最差的代码库。这就像一群蚂蚁，每只蚂蚁都在做对自己当前最优的事情，但如果没有一个整体性的协调机制，蚂蚁群可能会走出一条荒谬的螺旋路径。
这就是为什么，如果不具备 Debug 和审查能力，Vibe Coding 的使用者注定只能快速高效地生成一些小型项目。对于小型项目——代码量不大，逻辑不复杂，没有太多模块间的交互——”局部最优陷阱”的危害是有限的，因为项目小到”局部”和”全局”之间的差距不大。但一旦项目的规模开始扩大，功能开始增多，需求开始变更——也就是说，一旦进入真实世界的软件工程场景——这个陷阱就会迅速吞噬掉 Vibe Coding 带来的所有效率红利。你和 AI 会一起陷入一个”改一个 bug 冒出三个新 bug”的泥潭，最终的结局要么是利用 Vibe Coding 的极高效率直接推倒重写整个项目——这在小项目上是可行的，但在大项目上就是一场灾难——要么就是项目彻底报废。
3.3 从信任危机到”出版商”的诞生
现在，让我们暂时把目光从代码和 AI 上移开，回到一个更古老的故事上——因为历史，常常是理解未来最好的透镜。
十五世纪中叶，古腾堡的活字印刷术在欧洲普及。这项技术带来的最直接影响，正如我们在前文中类比过的，是抄写员的大规模失业。在此之前，书籍的复制完全依赖于修道院中抄写员的手工劳动——缓慢、昂贵、但每一份抄本都经过了训练有素的人眼的检视（尽管抄写错误仍然存在）。印刷术的到来，让文本的批量复制变得前所未有地廉价和快速。
然后呢？紧随失业潮之后，我们看到的第二波效应是：由于批量复制文本变得如此廉价和容易，市面上开始充斥着大量劣质的印刷品。错误百出的圣经译本、胡编乱造的医学手册、立场极端的政治宣传册——任何人，只要有一台印刷机（或者能租到一台），就可以把任何内容印刷成看起来颇为”正式”的书籍，投放到市场上。印刷品的外观赋予了内容一种虚假的权威感，读者很难仅凭外观来区分一本经过严谨编辑的学术著作和一本粗制滥造的伪科学读物。
于是，一场信任危机降临了。人们开始对印刷品——这种新的、高效的信息载体——产生了深深的不信任。
而正是这场信任危机，催生了一种在抄写员时代在概念上就不存在的全新角色和机构——出版商。出版商做了什么？他们并不自己写书，也不自己操作印刷机。他们做的事情是：用自己的信誉背书，只出版那些经过自己的编辑团队严格审查的文稿。 出版商的出现，在保留了印刷机的高效率和低成本的同时，重新建立了读者对印刷品的信任。当你看到一本书上印着某个声誉卓著的出版社的标志时，你就知道这本书的内容至少经过了一层专业的过滤和把关。出版商的价值，不在于”生产”，而在于“审查”和”背书”。
这个历史故事，与 Vibe Coding 时代正在发生的事情之间的平行关系，近乎令人不安地精确。
“出版商”，就是 Vibe Coding 时代正在等待被填充的生态位。OpenClaw 的安全丑闻，可以被视为 Vibe Coding 版的”劣质印刷品泛滥”事件——它标志着我们最初的 Vibe Coding 狂热正在开始消退，随之而来的，是一场对 AI 生成代码的安全性和可靠性的信任危机。
3.4 代码的”出版商”
那么，Vibe Coding 时代的”出版商”是什么？他们长什么样？
我认为，我们正处于这种新职能形成的极早期阶段——它还没有一个被广泛接受的名称，也没有形成成熟的行业标准和认证体系。但它的轮廓已经开始显现。让我试着描绘一下。
想象一种未来的机构——或者可以是某种形态的软件公司、咨询机构、乃至独立的第三方服务。这种机构的独特之处在于：他们可能没有传统意义上的”程序员”——也就是那些从头开始编写代码的人——但他们拥有一批读得懂程序、精通安全审计、深谙软件架构原则的专业人员。 他们的核心业务是接收 AI 生成的代码（无论是他们的客户自己用 Vibe Coding 生成的，还是外部 AI Agent 生成的），然后对这些代码进行全方位的审查——安全漏洞扫描、架构一致性检查、性能瓶颈分析、编码规范合规性审计、业务逻辑正确性验证——然后在必要时修改代码以修复发现的问题，最后也是最重要的，为最终通过审查的代码加上自己的机构背书。
这种模式，本质上就是印刷时代的”出版商”模式在软件工程领域的重现。他们的价值不在于”写”代码，而在于”读”代码、”审”代码、以及为代码的质量”担保”。
这听起来像是传统软件工程中的QA和QC部门的升级版。但我认为，Vibe Coding 时代的这种”代码出版商”角色，与传统 QA/QC 之间存在一些根本性的差异。传统 QA/QC 主要关注的是”产品是否按照规格说明书正确实现了”——它是在”需求已经确定、代码已经由人类编写完成”之后才介入的一个末端环节。而 Vibe Coding 时代的”代码出版商”需要关注的范围要广得多：他们不仅要验证功能正确性，还要对 AI 生成代码中那些人类不会犯但 AI 会犯的特有错误模式保持警惕——比如倾向于使用已被弃用的 API、引入冗余的依赖库、忽略特定框架的安全最佳实践、或者在看似正确的代码中嵌入微妙的逻辑漏洞。
3.5 “AI没法坐牢”
最后，让我们来到审查与治理能力这条论述线的终点——也是整条线最现实的落脚点。
在所有关于 AI 生成代码的信任问题中，有一个最根本的、任何技术手段都无法解决的问题：责任归属。
当一个 AI 生成的程序出了严重问题——比如一个 AI 编写的金融交易系统因为代码缺陷导致了巨额资金损失，或者一个 AI 生成的医疗信息系统因为逻辑错误给出了危险的误导性建议——谁来承担责任？
AI 不能被起诉。AI 不能被罚款。AI 不能被追究刑事责任。或者用一个在技术社区广为流传的、带着黑色幽默的地狱笑话来说：
AI 什么都好，就是有一个致命的缺陷——它没法坐牢。
这不是一个技术问题。这是一个法律问题、伦理问题、商业信任问题。而这个问题的存在，恰恰是”代码出版商”这种新职能的终极价值所在。
对于绝大多数 B 端客户——也就是那些花真金白银采购定制软件系统的企业甲方——来说，他们在签署采购合同时，最关心的条款之一，甚至可以说最重要的条款之一，就是责任界定。出了问题，谁赔？出了事故，谁负责？出了合规漏洞，谁来承担法律后果？如果你告诉一个银行的 CTO：”这个核心交易系统是我们用 AI 生成的，如果出了问题……嗯，AI 说它很有信心这段代码是正确的”——你不会拿到这笔合同的。
企业甲方需要的是一个有法律实体、可以签合同、可以承担违约赔偿责任、在极端情况下可以被追究法律责任的”人”或”机构”来为这些代码负责。这就是”代码出版商”的终极角色：他们不仅是技术审查者，更是法律和商业意义上的责任主体。他们接收 AI 生成的代码，经过自己的专业审查，然后在最终交付物上盖上自己的章——这个”盖章”的行为，同时也是一个承担责任的行为。他们向客户承诺：”这段代码经过了我们的审查，我们为其质量和安全性负责。如果出了问题，找我们。”
这种”可问责性”，是 AI 永远无法提供的。而在一个 AI 能够以近乎零成本批量生成代码的时代，可问责性将成为软件产品中最稀缺、最昂贵、也最有价值的属性之一。
回到个人层面，这意味着什么？这意味着在 Vibe Coding 时代，”能够阅读、理解、评估和修正 AI 生成的代码”的能力——也就是我们一直在说的审查与治理能力——将成为一项极其高价值的技能。这项技能不同于传统的”编写代码”能力。编写代码更像是一个”从零到一”的创造过程；审查代码则是一个”从一到可信”的质量保障过程。后者要求的不仅仅是编程知识，更需要安全意识、架构思维、对业务逻辑的深刻理解、以及——在更宏观的层面上——对”什么可能出错”的思考能力。
一个有趣的、也许是讽刺性的推论是：在 Vibe Coding 时代，最值钱的程序员可能不是那些写代码最快的人，而是那些读代码最好的人。
4. Vibe Coding 时代的能力需求
如果我们更进一步地抽象，会发现这三项能力有一个共同的深层本质：它们都是某种形式的“判断力”。
精确表达能力的本质是关于沟通的判断力——判断什么信息需要被说出来、什么可以省略、什么必须用技术语言精确描述、什么可以用类比来辅助理解。
需求洞察能力的本质是关于价值的判断力——判断什么是客户真正需要的、什么是可有可无的、什么是现在不需要但将来会需要的、什么需求之间存在冲突需要权衡取舍。
审查与治理能力的本质是关于质量与风险的判断力——判断一段代码是否安全、是否符合架构原则、是否在可接受的质量水平之上、以及一旦出问题其后果是否在可承受的范围之内。
而”判断力”这个东西，恰恰是当前 AI 技术最难以自动化的能力。AI 擅长的是在给定约束条件下寻找最优解——这是一种优化能力。而判断力要求的是在不完整的信息、模糊的目标、相互冲突的价值观之间，做出一个”虽然不是数学意义上最优、但在综合考虑所有因素后最为合理”的决策——这是一种智慧，它植根于经验、直觉、对人性的理解、以及对不确定性的驾驭能力。
结语：在浪潮中锚定自己
我们用了一整篇文章的篇幅来探讨 Vibe Coding 时代的核心能力。现在，让我们把所有的线索汇聚起来，做一个最终的综合。
Vibe Coding 不是程序员的末日，也不是一个可以被忽视的玩具。它是软件工程领域一次深层次的迁移——代码生产的边际成本趋近于零。这个变化的意义，堪比印刷术将文本复制的边际成本趋近于零。
在这场范式迁移中，三种传统上被低估或被视为”软技能”的能力，正在急速升值。
精确表达能力之所以重要，是因为在 Vibe Coding 时代，Prompt 就是新的”代码”。你写给 AI 的那段自然语言指令的质量，直接决定了 AI 输出的质量。而写出一条高质量的 Prompt，要求你能够克服”知识的诅咒”，识别你和 AI 之间的”非共识语境”，用精确的、技术性的语言表达你的完整意图。这项能力不是程序员的专属——它属于所有想要利用 AI 创造软件的人。它的普及，将催生一个巨大的”原本不会被做成软件的软件”市场，推动软件生产的真正民主化。
需求洞察能力之所以重要，是因为当”写代码”不再是瓶颈时，”决定写什么代码”就成了最大的杠杆点。这项能力要求你能够从客户模糊的、矛盾的、不完整的原始需求中，提炼出清晰的、一致的、具有前瞻性的技术需求。它本质上是传统产品经理角色在 Vibe Coding 时代的延伸和强化。在某种意义上，Vibe Coding 时代的程序员，就是拥有技术背景的产品经理——他们站在人类客户和 AI 执行者之间，充当双向的翻译官。
审查与治理能力之所以重要，是因为 AI 生成的代码天然具有”局部最优陷阱”的系统性缺陷，而 AI 本身永远无法承担代码出错的法律和商业责任。OpenClaw 事件以一种戏剧化的方式向我们展示了，不经人类审查的 AI 生成代码在规模化之后会导致什么样的灾难。正如印刷术的普及催生了”出版商”这种以审查和信誉背书为核心价值的新角色，Vibe Coding 的普及也将催生某种”代码出版商”式的新职能——他们的价值不在于写代码，而在于读代码、审代码、以及最重要的，为代码的质量”坐牢”。
回望历史，每一次重大技术变革——印刷术、工业革命、互联网——都遵循着一个相似的模式：一种旧的、高成本的生产方式被一种新的、低成本的方式所取代；大量依附于旧生产方式的从业者面临转型或淘汰；与此同时，新的、在旧范式中甚至无法被想象的角色和职业开始涌现。印刷术淘汰了抄写员，催生了出版商和编辑。工业革命淘汰了手工匠人，催生了工程师和质检员。互联网淘汰了一批传统信息中介，催生了搜索引擎优化师、数据分析师和内容运营者。
Vibe Coding 正在淘汰的，是”以手工编写基础代码为核心竞争力”的旧式程序员。正在催生的，是一种新型的技术工作者——他们不一定能从头手写一个操作系统内核，但他们能精确地表达一个操作系统内核应该做什么；他们能敏锐地洞察到用户真正需要的是什么样的内核特性；他们能在 AI 生成了内核代码之后，以专家的眼光审查每一个关键路径，确保它不会在生产环境中崩溃。
这三种能力——表达、洞察、审查——构成了 Vibe Coding 时代人类技术工作者的新”铁三角”。
掌握它们的人，不会被浪潮吞没。
他们会成为驾驭浪潮的人。