写在前面

本文内容结合 《Vibe Coding: The Future of Programming》 一书整理，想讨论的，不是某个 AI 编程工具到底有多强，也不是一句 prompt 能不能快速生成一个页面，而是一个更值得认真回答的问题：

当 AI 已经能写出相当多的代码以后，程序员的核心价值到底还剩下什么？

这不是一个情绪化问题，而是一个非常现实的工程问题、学习问题和职业问题。

过去我们谈程序员，常常会默认把注意力放在“写代码”这件事上：谁写得快，谁框架熟，谁能更快把功能堆出来，谁似乎就更有价值。但随着大模型进入开发流程，这个判断标准正在发生明显变化。

今天越来越多开发者会发现：

• 从空白文件到一个原型，速度变快了；
• 从自然语言到一版可运行代码，门槛变低了；
• 很多重复性、模式化、样板化工作，AI 的确能承担相当大一部分；
• 但真正进入上线、维护、扩展、协作、质量保障这些环节之后，问题并没有自动消失。

也正因为如此，Vibe Coding 这个概念才值得认真理解。

在我看来，Vibe Coding 不是一句简单的“让 AI 帮我写代码”，而是软件开发重心迁移的一个信号：从“亲手逐行敲实现”逐渐转向“表达意图、生成候选方案、理解结果、验证质量并承担责任”。

所以这篇博客没有谈工具选型，也不急着谈提示词技巧，而是先把两个最关键的问题讲明白：

1. 到底什么是 Vibe Coding；
2. 为什么把“70%问题”作为当前 AI 编程最核心的命题。

把这两个问题讲清楚之后，程序员在 AI 时代真正不可替代的价值，也就会慢慢浮现出来。

一、什么是 Vibe Coding

1.1 这个词为什么会火

过去几十年，程序员写程序的典型方式是：

• 先理解需求；
• 再设计数据结构和模块；
• 然后亲手把代码一行一行写出来；
• 接着调试、测试、部署和维护。

而在大模型时代，越来越多开发者的工作方式发生了变化：

• 不再从空白文件开始；
• 而是先用自然语言描述需求；
• 让 AI 先生成一个原型或初稿；
• 然后人类再去改、审、测、补、删、重构。

这个变化的本质，不只是“写代码更快了”，而是 编程活动的重心发生了偏移。以前的重心往往是“如何把代码敲出来”；现在的重心越来越变成：

• 你到底想做什么；
• 你能不能把需求表达清楚；
• 你能不能看懂 AI 生成的东西；
• 你能不能判断它哪里对、哪里错；
• 你能不能把一个“能跑”的东西，变成一个“能用、能维护、能扩展、能上线”的系统。

这就是 Vibe Coding 背后的时代背景。所谓 Vibe Coding，可以把它理解成一种更偏“意图驱动”的编程方式：

• 你告诉 AI 你要什么；
• AI 根据已有模式快速产出；
• 人类不再只是代码输入者，而逐渐变成目标提出者、上下文提供者、架构判断者、质量把关者和责任承担者。

1.2 意图驱动编程

我建议不要直接把 Vibe 翻成“氛围编程”，很容易误解成“凭感觉编程”。

更稳妥的讲法是：

• Vibe Coding = 意图驱动编程；
• 也可以解释成 基于自然语言意图的人机协同编程。

这里的“意图”，指的是：

• 需求意图：我要做一个什么东西；
• 交互意图：用户应该怎么使用它；
• 工程意图：它要满足什么性能、安全、可靠性约束；
• 演化意图：将来我要怎么扩展它。

如果只把 Vibe Coding 理解成“把一句话丢给 AI，让它吐一堆代码”，那理解就浅了。

真正的 Vibe Coding，至少包含五个层面：

1. 表达意图：把需求说清楚；
2. 生成初稿：让 AI 给出候选方案；
3. 理解产物：看懂 AI 生成了什么；
4. 校验质量：验证功能、边界、安全、性能和维护性；
5. 承担责任：最终对系统负责的仍然是人。

这五个层面里，只有第二步主要依赖 AI，其他四步都强烈依赖人的能力。

1.3 “AI 会写代码了，人类还要会什么”

Addy Osmani 这本书提出了一个很关键的问题：当 AI 已经能写出相当多的代码以后，程序员的核心价值到底还剩下什么？

这不是一个情绪化问题，而是一个教育问题、职业问题、工程问题。

对程序员来说，这个问题会变成：

• 我还要不要学基础语法？
• 我还要不要手写排序、链表、栈、队列？
• 我还要不要强调调试和测试？
• 究竟是“AI 的操作员”，还是“能驾驭 AI 的工程师”？

本书给出的答案非常明确：

• AI 能替代一部分机械劳动；
• 但不会替代工程判断；
• 真正有价值的能力，不会消失，只会被放大。

也就是说，这本书不是“唱衰程序员”，恰恰相反，它是在提醒大家：低水平重复劳动的价值在下降，高水平工程判断的价值在上升。

Vibe Coding 不是“凭感觉编程”；也不是“把一句话丢给 AI 等答案”；它更像是一种以意图为起点、以 AI 为加速器、但仍然由人类负责理解、判断、验证和收口的开发方式。

二、著名的“70%问题”

2.1 为什么用 70% 这个数字

所谓的 70% Problem。这个数字并不是一个严谨统计学意义上的全球常数，而更像一个非常形象的经验判断。作者观察到，很多 AI 编程工具在以下事情上表现很强：

• 生成样板代码；
• 生成基础页面；
• 生成 CRUD 接口；
• 生成简单测试；
• 生成常见框架下的标准结构；
• 快速拼出一个可运行的原型。

于是很多人会产生一种强烈体验：“太神了，几分钟就出来了。”,“我以前要写一天的东西，现在半小时就有雏形。”,“它已经帮我做完大部分工作了。”

但真正的问题在后面。

当项目从“能跑”走向“能用”，从“演示”走向“上线”，从“单人试玩”走向“真实用户”，开发者就会撞上一面墙：

• 这个接口异常没处理；
• 这个输入边界一错就崩；
• 这个状态切换不一致；
• 这个性能在真实数据量下不行；
• 这个依赖版本不兼容；
• 这个安全校验漏了；
• 这个代码越改越乱；
• 这个功能修好了，另一个功能又坏了。

于是大家就会发现：前 70% 非常顺，后 30% 非常痛苦。

作者用 70% 这个说法，想表达的不是一个精确数字，而是一种普遍现象：

AI 对“模式化、重复性、资料丰富、路径成熟”的问题特别擅长；
对“模糊、冲突、复杂、需要判断、需要取舍、需要负责”的问题就明显乏力。

2.2 70% 不是“做了七成代码”，而是“做了七成容易的部分”

很多人会误以为：“AI 已经写了 70% 的代码，那剩下只是小修小补。”

其实恰恰相反。

• AI 很可能写完了 70% 的代码量；
• 但这 70% 往往对应的是 相对容易、相对标准、相对可复用 的那部分工作；
• 剩下那 30%，往往不是“少量尾活”，而是 最难、最贵、最需要经验 的部分。

这就像盖房子：

• 平地、搬砖、搭脚手架、砌墙体，可能都很快；
• 但结构安全、排水、防火、电路、承重、后期维护，这些才是真正决定房子能不能住的关键。

软件也是一样。前 70% 常常解决的是：

• 页面先画出来；
• 接口先通起来；
• 流程先跑一遍；
• 示例数据先展示出来。

后 30% 才真正涉及：

• 用户输错了怎么办；
• 网络抖动了怎么办；
• 并发冲突怎么办；
• 数据脏了怎么办；
• 权限越界怎么办；
• 将来改需求怎么办；
• 多人协作怎么办；
• 上线出了事故谁来兜底。

这就是为什么作者会反复提醒：AI 擅长制造“看起来像完成了”的感觉，但不等于真的完成了。

2.3 70%问题背后的工程学解释

从软件工程角度看，这个问题可以分成三层。

第一层：模式匹配层

大模型最擅长的，是在海量已有代码和文本模式中找相似结构，然后拼接出一个高概率合理的答案。所以它面对下面这些任务时往往很强：

• 搭一个 React 页面的骨架；
• 写一个 Python 数据清洗脚本；
• 生成一个登录表单；
• 写一个 REST API 的基本增删改查；
• 给一个函数补单元测试。

因为这些问题都比较“像以前见过的题”。

第二层：语义理解层

一旦问题进入真实业务语境，难度就上升。比如“用户删除订单”看上去很简单，但真实业务会涉及：

• 已支付订单能不能删；
• 已发货订单能不能删；
• 删除是逻辑删除还是物理删除；
• 财务对账怎么办；
• 审计记录保留多久；
• 是否影响库存回滚；
• 是否要通知客服系统。

这些问题不是代码模板能自动推出来的，它依赖领域知识、制度规则和组织上下文。

第三层：责任承担层

AI 不承担责任，这是本书的一个底层判断。AI 可以给你一个看似漂亮的实现，但它不会真的为下面这些后果负责：

• 线上宕机；
• 数据泄露；
• 用户投诉；
• 法律合规问题；
• 团队维护成本暴涨；
• 重构代价失控。

所以只要软件开发还是一个需要承担后果的职业，人类工程师就不会因为 AI 会写代码而失业，只会因为 只会写代码、不会判断的人 更容易被边缘化。

三、从 Vibe Coding 到 70%问题：程序员的核心价值并没有消失，只是被重新照亮

Vibe Coding 让软件开发的起点变了，70%问题又进一步说明：AI 确实能完成大量代码生成工作，但它擅长的主要还是那些模式化、重复性强、路径成熟的部分。一旦问题进入复杂需求、真实业务、边界条件、长期维护和责任承担，真正决定结果质量的，仍然是人。

也就是说，AI 并没有把程序员的价值抹掉，而是在倒逼我们重新看清：程序员真正值钱的，从来不只是“写代码”本身。

3.1 程序员的价值，正在从“实现能力”转向“工程判断能力”

如果把 AI 时代的变化说得更直接一些，可以概括成一句话：

• 代码生成的门槛在下降；
• 工程判断的价值在上升。

过去很多时候，程序员的大量时间会消耗在样板代码、基础页面、标准接口、重复逻辑和常规结构上。现在这些内容越来越容易由 AI 起草，甚至一次性给出一个看上去已经像模像样的版本。

但问题是，真正难的地方往往不在“先写出来”，而在：

• 这个需求到底有没有被理解对；
• 这段实现有没有隐藏副作用；
• 边界条件是否考虑完整；
• 架构是否还能支撑后续演化；
• 上线之后出了问题谁来兜底；
• 多人协作时这个实现是否足够清楚、稳定、可维护。

这些能力，才是 AI 时代越来越重要的程序员核心价值。

3.2 程序员至少还握着四类关键价值

程序员的核心价值至少体现在下面四个方面。

第一，定义问题的能力

AI 很擅长回答问题，但前提是问题本身已经被定义得足够清楚。而真实软件开发里，最难的地方恰恰经常不是“怎么写”，而是：

• 到底要解决什么问题；
• 哪些约束必须满足；
• 哪些边界必须处理；
• 哪些需求是表象，哪些才是真实目标。

这一步如果没想明白，AI 只会更高效率地放大含糊。

第二，理解系统与设计边界的能力

AI 可以生成局部代码，但系统不是局部代码的简单堆叠。程序员真正重要的价值，在于把一个系统组织清楚：

• 模块怎么划分；
• 数据怎么流动；
• 接口怎么约定；
• 状态怎么管理；
• 哪些复杂性该被压在什么位置。

这类工作高度依赖系统视角，而不是单点生成能力。

第三，验证与证伪的能力

70%问题最值得警惕的一点，就是 AI 很容易制造“差不多做完了”的幻觉。这时候真正有价值的人，不是那个最先接受结果的人，而是那个会继续追问的人：

• 真的满足需求了吗；
• 极端输入测试过吗；
• 修复一个问题会不会破坏别的流程；
• 这段实现只是能跑，还是也足够可靠。

所以在 AI 时代，测试、调试、审查和验证，不是附属能力，而会越来越接近核心能力。

第四，承担责任的能力

AI 可以生成代码，但不会真正承担后果。

它不会为线上故障值班，不会为数据泄露负责，也不会为长期维护成本失控承担组织责任。只要软件仍然会影响真实用户、真实业务和真实风险，最终就一定需要有人来判断、签收、背书和负责。

而这，正是程序员这个角色最本质的底色之一。

3.3 程序员真正剩下的，不是边角工作，而是最本质的部分

所以，本文标题里那个问题，其实可以这样回答：

当 AI 已经能写出相当多的代码以后，程序员剩下的，不是“最后一点还没被自动化的零碎工作”，而是软件开发中最本质、最关键、也最不能轻易外包的部分。

它包括：

• 对问题的澄清；
• 对系统的抽象；
• 对边界的敏感；
• 对质量的验证；
• 对风险的判断；
• 对长期维护的考虑；
• 对团队协作的推动；
• 对最终结果的负责。

换句话说，AI 让“写出代码”这件事越来越容易，而程序员的核心价值，越来越集中在：决定什么值得写、怎样写得更对、如何证明它可靠，以及谁来为它负责。

写在最后

如果只是把 Vibe Coding 理解成“让 AI 帮我更快生成代码”，那这个概念其实只理解了一半。

更完整的理解应该是：

• AI 的确让开发提速了；
• 但它也更早暴露了软件工程真正难的部分；
• 它压缩了低水平重复劳动的价值；
• 同时放大了高水平工程判断的价值。

从这个角度看，Vibe Coding 不是程序员价值的终点，反而更像一次重新校准：

• 什么能力只是机械劳动；
• 什么能力才是真正的工程能力；
• 什么部分可以放心交给 AI；
• 什么部分必须牢牢握在人手里。

它没有把注意力停留在“AI 很强”这种表层结论上，而是在提醒我们，真正值得关注的，从来都是 AI 之后，人还必须会什么。

博文部分内容参考

© 文中涉及参考链接内容版权归原作者所有，如有侵权请告知 😃

<《Vibe Coding: The Future of Programming》>