Vibe Coding时代，程序员不会被断代，但能力栈正在重排

Vibe Coding 这个词是最近一年被反复提起的。源头是 Andrej Karpathy 在一次分享里说，自己写代码已经从“逐行控制”变成了“给 AI 描述一个 vibe，让它把代码生成出来”。我当时看到这句话心里就一动：这不就是我过去几个月每天都在干的事吗。有人把 Vibe Coding 翻译成“氛围编程”，我觉得特别贴切——代码真的正在从一种需要精雕细琢的“手工艺品”，变成一种“背景氛围”：它在那里，它跑起来了，但几乎没人逐行去读它。

紧接着的问题就是：如果代码本身不再是核心竞争力，那程序员这个职业会不会被“断代”？

先说我的结论：会，但断掉的不是程序员这个群体，而是“只靠手写代码换饭吃”的那部分能力。更准确地说，AI 正在重新排列程序员的技能栈——有些技能会下沉成“氛围”，有些技能会被逼着浮出水面。这篇文章想聊的就是：哪些能力正在下沉，哪些能力正在上升，以及作为一个在一线写代码写了十几年的人，我给自己规划了一套什么样的实操方法去应对这件事。

1. 先搞清楚：Vibe Coding 到底在改变什么

1.1 从“敲代码”到“提需求”，工作模式发生了本质位移

以前我们写一个功能，脑子里先想数据结构，再想接口，再想边界条件，最后才落到语法上。现在我大量使用 AI 编程工具之后，流程变成了这样：我先想清楚“这个功能要解决什么问题”，然后把约束条件、输入输出、异常场景写清楚，丢给 AI 生成代码，接着我 review、改、跑测试。

这个位移太关键了。过去“写代码”这个动作是创造力的核心载体，现在它变成了“描述问题 + 验证结果”。有朋友问我，这样是不是代码质量下降了？我的回答是：描述能力的质量，直接决定了 AI 产出的质量。这就像你带了一个特别能干的实习生，他能写一手好代码，但如果你连需求都讲不清楚，他也只能给你交出你觉得“不太对但说不出哪里不对”的东西。

我自己的习惯是：凡是要交给 AI 的任务，必须写成一份“可以被人验收”的需求说明。里面要有前置条件、期望输出、必须处理的边界场景，还要有验收标准。写这份说明花的时间，比我以前调代码的时间短得多，但它换回来的稳定性和可控性，是以前没有 AI 时很难想象的。

1.2 代码从“作品”变成“氛围”，是效率提升也是价值重估

Karpathy 讲的那个例子特别有意思：他让 AI 写一个 3D 贪吃蛇游戏，写完以后他自己都看不太懂那段代码，但游戏跑起来很流畅，玩起来很有意思。这就是“代码下沉为氛围”的典型场景——代码变成了游戏可玩性的背景，而不是一个需要被反复欣赏的文本。

换个角度想，互联网刚普及时，会做网页的人被当成“技术大牛”。后来建站工具流行，做网页的门槛骤降，网页本身也从“作品”变成了“氛围”。今天的 Vibe Coding 在做同一件事：它把“写代码”从“作品创作”变成了“产品实现过程中的一个环节”。代码当然重要，但它的地位更像是建筑里的钢筋——你不能没有它，但用户住进房子时不会去摸钢筋。

有人会焦虑：代码都不重要了，那我学了十年的算法、数据结构、设计模式，是不是白学了？我的看法恰恰相反。这些知识不是让你“手写代码”用的，而是让你“判断 AI 写的代码对不对”用的。正因为代码变成了氛围，能穿透氛围、直接评估代码质量的人，才变得更稀缺。这就像摄影术普及后，人人都会按快门，但知道什么时候该按下快门、怎么构图、怎么用光的人，依然是职业摄影师。

2. 程序员为什么集体拥抱 AI——对比音乐人的“抵触”

2.1 两拨人面对 AI 的态度为何截然不同

最近网上有个话题很火：程序员大多是 AI 的拥趸，而音乐人却普遍对抗 AI 音乐。这个对比特别能说明问题。

程序员的核心产出是一个“能运行的系统”——代码只是实现方式。AI 帮我写代码，只要系统跑得稳、性能达标，代码是你写的还是 AI 写的，对用户来说没有区别。所以我天然愿意拥抱 AI，因为我的价值不在那几千行代码上，而在“我知道系统应该怎么搭、出了问题时我能定位到哪一层”上。

音乐人不一样。音乐的载体就是声音本身，AI 生成一首歌，听起来再像，它也模糊了“创作者”这个身份。听歌的人会追问：这首歌是真人写的还是 AI 写的？这种追问直接击穿了音乐作品的原创性和情感表达。换句话说，程序的评价标准是“好不好用”，音乐的评价标准是“谁写的、表达了什么”。评价标准不同，导致两个群体对 AI 的态度天差地别。

但我要泼一盆冷水：程序员拥抱 AI，背后藏着一个隐患——如果你把自己的价值定义成“我能手写功能代码”，那 AI 恰好能替代你。而如果你把价值定义成“我能判断什么功能值得做、怎么做才能达到业务目标”，那 AI 只是你的加速器。这个话题下文会展开。

2.2 拥抱越深，越要警惕“能力空心化”

我见过一些年轻同事，入职几个月，代码全是 AI 生成的。功能能跑，看起来效率很高。但一到线上出问题，他们就慌了：日志打出来了，看不懂；监控告警亮了，不知道从哪查。AI 生成代码时没有在他脑子里留下任何“系统心智模型”，他只是把 AI 的输出当成了终点。

这种状态我称之为“能力空心化”：产出看起来很丰满，但个人能力是被 AI 撑起来的，一旦脱离 AI，立刻塌陷。更可怕的是，这种空心化自己往往感觉不到——因为你每天都在交付东西，成就感是真实的，直到某天你被一个问题卡住，才发现自己对系统的理解薄得像一张纸。

所以我会给自己立一个规矩：凡是 AI 生成的核心路径代码，我必须亲手读懂每一行。可以借助 AI 帮我解释，但最后“懂”的那个人必须是我。这不是情怀，是生存问题——保住你理解系统的能力，你才保住了对 AI 产出的判断力。

3. 会被“断代”的从来不是职业，而是能力栈

3.1 正在下沉的手写能力与正在上升的判断能力

让我把问题说得更直白一点。“程序员被 AI 断代”这句话，我问了自己无数遍。最后我的答案是：不是程序员会被断代，而是程序员的能力栈会经历一次全面的重排。

先说哪些能力正在沉下去。首先是通用模板代码的手写能力——CRUD 接口、表单校验、基础 CSS 布局，这些 AI 已经做得又快又好；其次是“面向搜索引擎编程”的查资料能力——以前遇到底层报错要翻 Stack Overflow 翻半天，现在把报错信息直接丢给 AI，它几秒钟就能告诉你前因后果；再次是常规调参能力——AI 可以自己试多组参数，告诉你哪组最优，不需要你手动一遍遍跑实验。

但与此同时，有五种能力正在快速升值。第一种是需求拆解能力，把模糊的“我想做个某某功能”翻译成边界清晰、有验收标准的任务；第二种是方案评审能力，AI 给出一个方案，你能看出它在扩展性、性能、运维成本上的隐患；第三种是技术判断力，知道什么场景该用单体架构、什么场景该上微服务，而不是让 AI 替你拍脑袋；第四种是代码审查力，AI 生成的代码里藏着逻辑漏洞或安全风险，你一眼能看出来；第五种是领域知识沉淀，你对自己所在的行业（金融、电商、教育等）理解越深，AI 就越离不开你。

用表格看更直观：

3.2 警惕三类最容易“断代”的人

第一种是“粘贴型程序员”。他们的开发流程是：需求来了，直接把需求文字复制给 AI，AI 生成了代码，复制粘贴到项目里，跑通就算完事。他们从不追问 AI 为什么这么写、边界条件处理了没有、异常分支覆盖了没有。这类人不是被 AI 断代的，是被自己的“不思考”断代的。

第二种是“接口搬运工”。他们对技术的理解停留在“调用某个接口完成某个对账任务”的层面，从不深入理解接口底层的原理。以前，底层系统的复杂性能挡住一些人，现在 AI 把这些复杂度全部屏蔽了，搬运工连最后一点门槛都感受不到了，也就彻底失去了深入的动力。

第三种是“甩手掌柜型”程序员。他们让 AI 写代码、写测试、写文档，自己只做整合转发。听起来很高效，但一旦 AI 给出了错误判断，他没有任何纠错能力。我身边已经出现这种案例：AI 生成了带内存泄漏的代码，跑了一周线上服务频繁重启，最后查下来就是没人去 review AI 写的缓存处理逻辑。

这三种人的共同问题，是把 AI 当成了“外包商”，而不是“结对伙伴”。外包商交付的东西，你只看结果；结对伙伴产出的逻辑，你会参与讨论、互相挑战。要想不被断代，你的角色感必须从“安排 AI 干活的人”转变为一个“对最终交付负全责的架构师”。

4. 免于断代：我在用的五步实操工作流

4.1 写需求时用“验收标准”代替“功能描述”

很多人让 AI 干活，描述是“请你写一个用户登录功能”。这个描述太模糊了，AI 生成的代码大概率不符合预期。我的做法是把需求描述拆成四个部分：

第一个部分是背景与目标，交代这个模块在系统里的位置、它要解决什么问题；第二个部分是输入与输出，明确入参格式、出参格式、异常输出；第三个部分是边界与约束，比如并发量、响应时间、安全要求、兼容性要求；第四个部分是验收标准，列出你能想到的所有“必须通过”的检查点。

举一个我最近的例子。我要让 AI 写一个“导出用户报表”的功能。我不会只说“写个导出接口”，而是写了这样一段描述：输入是部门 ID 和月份，输出是符合指定格式的 CSV 文件；文件需要在 5 秒钟内生成完毕；如果当月没有数据，要导出表头并附带一行“当月无数据”的备注；部门 ID 不存在时返回业务错误码；所有操作要记录审计日志。你看，当约束足够具体时，AI 生成出来的东西基本是可用的，我只需要做小范围调整。

这样的需求描述表面上看是为 AI 写的，实际上受益最大的是我自己——我被迫把业务逻辑彻底想清楚，这个思考过程本身就提升了我的判断力。所以我会对团队说：如果你连验收标准都写不出了，那问题不是 AI 不会写代码，而是你不知道自己要什么。

4.2 让 AI 出方案，你来做方案评审

以前我们做技术方案，要画架构图、列技术选型、写详细设计。现在我会先让 AI 给一版方案，然后我做评审。评审的时候我会重点看三件事。

第一看选型是否匹配业务规模。比如技术选型时，AI 可能推荐引入一个很重的大数据处理框架来解决一个只需要跑批处理的任务——杀鸡用了牛刀。这时候我会反问 AI：这个框架的维护成本对我们团队来说是不是太高了？有没有更轻量的替代方案？让它列出两到三个候选方案做对比。

第二看扩展性设计是否合理。AI 倾向于把架构设计得非常“完备”，哪怕你的系统未来三年可能就一个固定规模。过度设计带来的复杂度和运维成本是真实的，这个权衡只有你能做，AI 不知道你们的团队规模，也不了解老板的预算。

第三看风险边界是否覆盖。AI 生成的方案通常不会主动去想你最怕遇到的场景——比如数据一致性、并发冲突、网络抖动。这些经验型的“坑”需要我来补充，把我的顾虑写进 prompt，让 AI 联合生成补充方案。

方案评审这个环节，是把自己的经验注入 AI 输出过程的最好时机。我给你一个我经常用的 prompt 模板：“以下是我对方案 A 的顾虑，请结合这些顾虑重新评估，并给出调整后的推荐方案。顾虑包括：一、可运维性；二、故障恢复；三、团队上手成本。”你会发现，只要把这三条绑在 prompt 里，AI 输出的方案就会从一个“技术完美主义者”变成一个“可落地的工程方案”。

4.3 增量生成，分层审查

很多人在用 AI 时最容易犯的错，是让它一次性生成一个巨大的模块。生成的代码量大，出错概率高，而且一旦出问题，排查的成本让你根本不想去 review。我的做法是把任务拆成足够小、足够独立的单元——一个函数、一个接口、一个状态机，然后分批次让 AI 生成。

举个例子。上周我让 AI 帮我写一个支持断点续传的文件上传服务。我没有让它直接生成整个服务，而是切分成了：前端切片逻辑、后端接收接口、分片记录表设计、合并模块、异常恢复模块、进度接口，六个任务依次进行。每提交一个任务给 AI，都附带前面任务的上下文。这样一个模块一个模块地推进，出错时定位很快，而且每一块都能被单独测试，几乎不会出现“一大坨代码不知道从哪下手”的情况。

审查的时候我采用三层策略。第一层是格式和风格审查，看类型标注、命名规范、日志规范是否符合团队约定；第二层是逻辑审查，重点看边界条件、异常分支、幂等性处理；第三层是安全审查，检查参数校验、权限控制、敏感信息泄露。第三层最容易被忽略，但恰恰是 AI 最有可能翻车的地方——它常常会默认调用方已经做了校验，而实际上线上调用方根本没有校验。

4.4 逼自己读懂 AI 生成的核心代码

有人会问：AI 生成的代码我用得好好的，为什么要花时间去读？因为“读代码”是建立系统心智模型的唯一途径。你运行一个功能，如果心里没有“数据是怎么流转的、状态是怎么维护的、资源是怎么释放的”这张地图，你就无法判断它在真实负载下的行为。

我的建议是，挑出 AI 生成代码里最核心的模块，逐行读一遍。读不懂的地方，让 AI 用类比解释，再用代码注释解释，最后再用一张时序图帮助你理解。然后反向验证：把 AI 对自己的代码的解释，跟你的业务理解对照，看有没有对不上。如果对照了三次以上都没问题，说明你基本吃透了这个模块。

这个动作很花时间，但它是防止“能力空心化”最直接的手段。有一个观点我特别认同：AI 时代，你得变成“代码读者的专家”。你能读懂 AI 写的代码，甚至能解释给团队其他成员听，你就是那个团队里不可替代的人；你要是只能粘贴和运行，那就真的危险了。

4.5 把知识沉淀成团队的“AI 资产”

用得多了以后，我发现 prompt 本身是可以资产化的。我会维护一个团队内部的“prompt 知识库”，里面存了我们反复使用、验证过的高质量需求模板、审查清单、技术选型 prompt。不在数量多，而在于每个都经过实战校准。

同时我还会维护一份“AI 坑位档案”，记录 AI 生成代码时最容易犯错的地方。比如：AI 经常忘记对输入做空值校验；AI 习惯性地把所有异常打在同一行日志里，导致日志里看不出上下文；AI 会在并发场景下意识地忽略线程安全。这些高频问题我会写进团队 code review 的手册里，让每个人在用 AI 时都带着这些检查点。

更进一步，我正在尝试把 spec-driven 的思想结合进来。也就是说，不只给 AI 一个模糊的 vibe，而是把需求描述写成“规格说明 + 验收标准 + 边界约束”，让 AI 严格按规格执行，而不是自由发挥。这比纯粹的 Vibe Coding 可控得多。Vibe Coding 适合原型验证和小工具开发，spec-driven 则适合需要长期维护的生产级代码。这两者的度怎么拿捏，取决于你交付的东西是一次性 demo 还是线上核心链路。

5. 常见问题与踩坑实录

5.1 不会写代码的人能靠 Vibe Coding 做产品吗

这是最近被问爆的问题，也是我最想纠正的一个误区。我的答案是：能做 demo，扛不住生产。

我见过一个完全没有编程基础的产品经理，靠 AI 做出了一个小工具的 demo，UI 还挺精致。但真到了上线阶段，出了问题他完全不知道从哪入手——数据库连接断了不知道怎么配，用户反馈卡顿不知道是前端还是后端的问题，更别提数据安全这些他自己意识不到的点。产品能上线跟能跑是两码事。看不到问题，才是最大的问题。

如果你是技术管理者，我要给你另外一个建议：警惕那些用 AI 产出大量代码但从不写测试的人。代码量上去了，坏风险也上去了。AI 写的代码，本质上是一条逻辑概率的输出，你不在它外面加一层验证护栏，就别指望它是可靠的。这层护栏就是测试用例、代码评审和灰度发布机制。

5.2 AI 代码读不懂、跑不通怎么办

读不懂很正常——AI 可能选择了你没见过的设计模式、少见的语法糖，或者它的解法和你的习惯不一样。我的建议是别硬扛，分三步走：第一步，让 AI 自己解释这段代码的逻辑，生成结构化注释；第二步，把你理解到的逻辑用自然语言描述出来，让 AI 对照修正；第三步，手动把这段代码换成你觉得更可读的等价实现。三步走完后，你既理解了它的思路，又把自己的思路注入了实现，下次遇到类似问题时你会比它更高效。

跑不通的话，先把报错信息原样贴回给 AI，让它给出定位方案；如果修了三次还跑不通，立即停止无意义的循环调试。这时候通常意味着问题出在上下文之外的某个地方——比如依赖版本不兼容、环境变量缺失、外部服务没启动。你把项目环境的完整信息喂给 AI，再调试一次；还是不行的话，就果断手动介入，不要迷信“AI 一定比我聪明”。

5.3 被领导质疑“AI 能写你还有什么用”怎么回应

这个场景我觉得早晚会来。老板看到 AI 生成的代码质量不低，顺口来一句：既然 AI 能写代码，你们的岗位以后还要吗？

我的回应逻辑是：AI 能让代码被生成，但生成不等于交付。真正交付一个可持续运行、可维护、可扩展的系统，需要有人定义它的边界，需要在故障时几十秒内定位问题并止血，需要让团队所有成员的产出能彼此兼容。这一整套东西，不是一个模型能自动做到的。如果老板还是盯着“写代码”这个动作，那我会反过来提醒他：你用 AI 省下的人力，应该投到哪里去？是更快的迭代速度，还是更深的技术风险排查？这个答案本身就是技术管理者的价值所在。

5.4 Vibe Coding 避坑清单

我踩过的坑比较多，挑几个最典型的列出来。

第一个坑是密钥硬编码。AI 生成的代码经常会直接内置 API Key 或者数据库密码，我见过不止一次。每次用 AI 生成涉及外部服务的代码时，都要专门检查配置项是不是被写死了。第二个坑是忽略幂等设计。AI 生成的接口，默认调用一次是没问题的，但在重试机制下往往会重复插入数据或者重复扣款。你要主动在 prompt 里强调幂等性要求。第三个坑是日志上下文缺失。AI 生成的日志往往只有单行信息，没有 trace_id、用户 ID、参数快照。生产环境出问题，你根本串联不起来整个链路。我会在需求描述里加上一句“所有日志必须包含请求 ID 和关键参数快照”，简单但极其有效。第四个坑是测试覆盖不足。AI 在写单元测试时往往倾向覆盖“快乐路径”，对异常分支和不合法输入覆盖得不够。我会要求 AI 先生成测试清单，我再补全遗漏的边界场景。

最后说一个心态层面的建议。别把 AI 当成写作代码的终点，把它当成一个“需要你带飞的新人”。你写出清晰的需求，它就能写出更好的代码；你加入领域的约束，它就能输出具备工程水准的方案。你把自己的经验注入到 prompt 里、review 里、测试里，AI 的产出就会不断提高。而那些不肯注入经验、只想着“让 AI 替我干活”的人，才会真正成为被“断代”的那批人。

我个人现在的体会是，AI 带给我的不是威胁感，而是一种前所未有的专注感——我终于可以把精力从重复的语法拼接里抽出来，集中在真正需要判断力的事情上。每次我写出一份高质量的需求文档，看着 AI 把我脑子里的想法变成了可以运行的系统，我都觉得这才是程序员该有的状态。这套工作流还在持续迭代，但我很确定：保持对系统的理解力，保持对问题的判断力，保持对交付的掌控力，无论 AI 怎么变，你都有饭吃。