1. 从“写代码”到“描述意图”Vibe Coding 到底改变了什么“Vibe Coding”这个词第一次出现在我视野里的时候我正带着一个五人的后端小组做一套内部工单系统。当时团队里有个刚毕业一年的小伙子他没有像其他人那样先画 ER 图、再搭脚手架而是直接打开一个 AI 编程工具用自然语言把“我要一个能按优先级排序、支持标签过滤、带操作日志的工单列表接口”描述了一遍然后让工具生成骨架、补全逻辑、跑通测试。整个过程他只手动改了不到三十行代码。那天晚上我盯着他提交的 PR 看了很久心里冒出来的不是“这代码写得真好”而是“我们招人的标准可能要变了”。Vibe Coding直译过来是“氛围编程”或者“感觉编程”但它真正的内核不是“凭感觉乱写”而是开发者把注意力从语法细节和样板代码上抽离出来转向对意图、约束和系统行为的描述与校验。你不再需要记住某个框架的初始化顺序也不需要为了一个边界条件翻半小时文档你只需要把“我想要什么”“在什么条件下”“不能出现什么结果”讲清楚剩下的交给 AI 编程工具和 agent 框架去执行。这个转变听起来像是工具升级实际上它动的是软件开发岗位的能力模型。我之所以对这个话题有切身体会是因为过去大半年我一直在做两件事一是把团队里的重复性编码任务逐步交给 AI 编程工具处理二是重新梳理我们招人时的考察维度。前者让我看清了哪些环节真的能被替代后者让我意识到很多传统面试题——比如“手写一个快排”“解释一下闭包”——在 Vibe Coding 的工作流里权重正在快速下降。取而代之的是你能不能把一个模糊需求拆成可执行的 SPEC能不能写出稳定复现的提示词能不能判断 agent 框架给出的方案是不是在“胡说八道”。这篇文章想聊的就是软件开发岗位在这个新范式下到底多了哪些要求。我会从工作流的重构讲起拆解提示词工程和 SPEC 编写这两个核心能力再谈 agent 框架的选型与编排最后落到招聘和团队协作的实际变化上。如果你是一线开发者、技术负责人或者正在准备面试的工程师这些内容应该能帮你少走一些我踩过的弯路。2. 工作流重构Vibe Coding 下的开发闭环长什么样2.1 传统开发闭环与 Vibe Coding 闭环的对照传统开发闭环大家都很熟需求评审 → 技术方案设计 → 编码 → 自测 → 联调 → 提测 → 上线。这个链条里编码环节占据了开发者 60% 以上的时间而且大部分时间花在“知道怎么做但写起来繁琐”的事情上——比如写 DTO、写 CRUD、写单元测试的 mock。Vibe Coding 的闭环变成了意图描述 → SPEC 固化 → AI 生成初版 → 人工校验与修正 → 回归验证。注意编码环节没有消失但它从“从零构建”变成了“审查与纠偏”。我实测下来一个中等复杂度的接口开发传统方式大概需要 2 到 3 小时Vibe Coding 方式可以压缩到 40 分钟以内但前提是你得把前面两步做扎实。这里有个关键认知Vibe Coding 省掉的是敲键盘的时间不是思考的时间。很多人误以为用了 AI 编程工具就可以“躺平”结果生成的代码跑不起来排查问题花的时间比手写还长。我见过最夸张的案例一个同事让 AI 生成一个带事务的批量插入逻辑AI 给了一个看起来没问题的实现结果在并发场景下出现了死锁。他花了整整一个下午才定位到问题而如果一开始就把“并发安全”“事务隔离级别”写进 SPEC这个坑完全可以避免。2.2 为什么 SPEC 成了新的“源代码”在 Vibe Coding 的工作流里SPEC规格说明的地位被提到了前所未有的高度。以前 SPEC 是给人和文档看的现在它是给 AI 编程工具和 agent 框架看的同时也是给人做校验用的。一份好的 SPEC本质上就是一份可执行的意图说明书。我自己的做法是把 SPEC 分成四层目标层这个功能要解决什么问题输入是什么输出是什么成功标准是什么。约束层性能要求、安全要求、兼容性要求、不能使用的库或模式。边界层异常输入怎么处理空值怎么处理超时怎么处理并发怎么处理。验收层用什么测试用例来验证预期结果是什么。这四层写清楚之后AI 生成的代码质量会有质的提升。我做过对比实验同一个需求只给一句话描述AI 生成的代码一次通过率大概 40%给完整四层 SPEC一次通过率能到 75% 以上。剩下的 25% 也不是全错通常是边界条件处理得不够细致人工补几行就行。提示SPEC 不是写得越长越好。我见过有人写了三千字的 SPEC结果 AI 反而抓不住重点。核心是“约束明确、边界清晰”而不是“面面俱到”。2.3 提示词工程在开发场景中的真实作用提示词工程这个词被炒得很热但在开发场景里它的作用其实很具体把 SPEC 翻译成 AI 能稳定理解并执行的指令。这跟写产品需求文档不一样产品文档可以模糊提示词必须精确。我总结了几条在实际开发中特别管用的提示词原则第一角色和上下文要前置。比如“你是一个熟悉 Spring Boot 3.x 和 MyBatis-Plus 的后端工程师当前项目使用 Java 17数据库是 MySQL 8.0”这句话能让 AI 生成的代码风格和版本兼容性大幅提升。我试过不加这句AI 给我生成了基于 Spring Boot 2.x 的配置跑起来直接报错。第二输出格式要指定。如果你要的是一个完整的类文件就说“输出完整的 Java 类包含 import”如果你只要一个方法片段就说“只输出方法体不要解释”。不指定的话AI 有时候给你一段伪代码有时候给你一段带省略号的代码你还得手动补全。第三约束条件要显式列出。比如“不要使用 Lombok”“所有数据库操作必须走 Mapper 层”“异常必须统一抛出自定义 BusinessException”。这些约束如果不写AI 会按它自己的“习惯”来而它的习惯往往跟你的项目规范不一致。第四要求 AI 自检。我经常在提示词末尾加一句“生成后请检查是否存在空指针风险、SQL 注入风险和事务失效场景”。实测下来这句话能让 AI 主动修正一部分问题虽然不能完全依赖但确实能减少人工 review 的负担。3. 核心能力拆解Vibe Coding 要求开发者会什么3.1 从“语法记忆”到“意图表达”的能力迁移传统开发岗位面试我过去常问“HashMap 和 Hashtable 的区别”“synchronized 和 ReentrantLock 怎么选”。这些问题考察的是知识储备和语法记忆。但在 Vibe Coding 模式下这些知识 AI 比你记得更准真正稀缺的是把业务意图翻译成技术约束的能力。举个例子产品经理说“用户下单后要尽快收到通知”。传统开发者可能会直接想“用消息队列”。但 Vibe Coding 要求你进一步拆解多快算“尽快”是同步还是异步通知失败要不要重试重试几次幂等怎么保证这些问题的答案才是 SPEC 的核心也是 AI 生成代码的依据。我现在的面试题会换成这样“有一个日均百万级的订单系统产品要求下单后 3 秒内推送通知允许极端情况下延迟到 10 秒但绝对不能丢消息。请你写一份给 AI 编程工具用的 SPEC。”这道题能同时考察业务理解、技术选型、边界思考和表达能力比问八股文有效得多。3.2 提示词工程不是“会聊天”而是“会下指令”很多人觉得提示词工程就是“会跟 AI 聊天”这是个误解。开发场景下的提示词工程更像是在编写一份精确的接口契约。你的指令越像契约AI 的输出越稳定。我整理了一份开发场景常用的提示词结构模板实测下来比随意描述的效果好很多[角色] 你是一名资深 [技术栈] 工程师。 [上下文] 当前项目使用 [框架版本]、[数据库]、[构建工具]代码规范要求 [规范要点]。 [任务] 请实现 [具体功能]输入是 [输入描述]输出是 [输出描述]。 [约束] 必须满足 [约束1]、[约束2]禁止使用 [禁止项]。 [边界] 当 [异常场景] 时应该 [处理方式]。 [输出格式] 请输出 [格式要求]不要包含 [不需要的内容]。 [自检] 生成后请检查 [检查项]。这个模板不是死的但它的逻辑是通用的先定角色和上下文再定任务和约束最后定输出和自检。我团队里新来的同学用这个模板第一周就能把 AI 生成代码的可用率提到 70% 以上。还有一个容易被忽略的点提示词要版本化管理。我们团队现在把常用的提示词模板放在 Git 仓库里跟代码一起维护。为什么因为项目在演进框架版本在升级约束条件在变化提示词如果不跟着更新AI 生成的代码就会慢慢“脱节”。我见过一个项目从 Spring Boot 2.7 升级到 3.2 之后提示词里还写着“使用 javax.servlet”结果生成的代码全部编译不过。3.3 SPEC 编写把“我觉得”变成“必须满足”SPEC 编写能力是 Vibe Coding 时代最被低估的技能。我甚至认为未来开发岗位的核心竞争力就是写 SPEC 的能力。因为代码可以由 AI 生成但 SPEC 必须由人来定它承载的是业务判断和技术决策。一份合格的开发 SPEC我要求包含以下要素要素说明常见错误功能目标一句话说清做什么写成产品宣传语没有技术信息输入输出字段、类型、格式、示例只写字段名不写类型和边界约束条件性能、安全、兼容性遗漏并发和事务要求异常处理每种异常对应的行为只写“要处理异常”不写怎么处理验收标准可执行的测试用例写成“功能正常”这种无法验证的话我踩过最大的坑是“异常处理”这一栏。早期我写 SPEC 时习惯性略过异常场景结果 AI 生成的代码在遇到空值时直接抛 NPE在生产环境炸了一次。后来我强制自己在 SPEC 里列出至少五种异常场景参数为空、参数格式错误、数据库连接失败、并发冲突、超时。这五种覆盖了 90% 的线上问题。3.4 代码审查能力从“找 bug”到“找意图偏差”AI 生成的代码语法错误很少逻辑错误也不多但意图偏差很常见。什么叫意图偏差就是代码能跑结果也对但它实现的方式不是你想要的或者在某些你没考虑到的场景下会出问题。比如我让 AI 生成一个“查询用户订单列表”的接口它给我返回了全量数据没有分页。从功能上说它“实现”了查询但从意图上说我要求的是“列表接口”默认应该分页。这种偏差不会报错但会在数据量上来之后变成性能问题。所以 Vibe Coding 下的代码审查重点不再是逐行找语法 bug而是对照 SPEC 检查意图是否被准确实现。我现在的 review 流程是先看 AI 生成的代码有没有偏离 SPEC 的约束层和边界层再看有没有引入新的依赖或模式最后才看具体实现细节。这个顺序很重要因为前两层的问题往往影响更大。4. Agent 框架与编排让 AI 从“写一段”到“做一件事”4.1 主流 agent 框架的选型逻辑Agent 框架是 Vibe Coding 从“单次生成”走向“多步执行”的关键。简单说AI 编程工具帮你写一段代码agent 框架帮你完成一个任务链——比如“读取需求文档 → 生成接口代码 → 写单元测试 → 跑测试 → 根据失败结果修正 → 提交 PR”。目前主流的 agent 框架各有侧重我按实际使用体验做个对比框架类型特点适合场景注意事项单 agent 框架结构简单上手快单一任务自动化复杂任务容易迷失多 agent 协作框架支持角色分工和消息传递多步骤、多角色任务编排复杂度高调试困难工作流编排框架以流程为中心步骤可控标准化流水线灵活性相对受限上下文变量框架强调状态管理和变量传递需要跨步骤保持上下文变量设计不当会污染上下文我自己的选型原则是任务越标准化越偏向工作流编排任务越需要判断越偏向多 agent 协作。比如“批量生成 CRUD 接口”这种高度标准化的任务用工作流编排最稳“排查一个线上问题并给出修复方案”这种需要多轮判断的任务多 agent 协作更合适。4.2 Agent 编排中的上下文管理Agent 编排最容易出问题的地方是上下文管理。一个 agent 执行到第三步的时候可能已经忘了第一步的约束条件。这在开发场景里是致命的——比如第一步要求“不能用某個库”第三步 agent 就给你引入了这个库。我的做法是把关键约束做成上下文变量在每个步骤显式传递。比如定义一个constraints变量里面存着“禁止使用的库”“必须遵守的规范”“性能阈值”每个 agent 在执行前都读取这个变量。这样即使 agent 的对话历史被截断约束也不会丢。还有一个技巧是给每个 agent 设定明确的“职责边界”。我见过一个多 agent 系统三个 agent 都在尝试修改同一个文件结果互相覆盖。后来我给每个 agent 分配了明确的文件范围问题就解决了。编排的本质不是让 agent 更聪明而是让它们不互相干扰。4.3 嵌入式场景下的 Vibe Coding 特殊考量嵌入式开发用 Vibe Coding跟纯软件有很大不同。我去年参与过一个嵌入式项目用 AI 辅助生成驱动代码踩了不少坑。最大的坑是资源约束。纯软件场景下AI 生成的代码多占几 MB 内存无所谓嵌入式场景下多占几 KB 都可能导致系统跑不起来。所以嵌入式场景的 SPEC 里必须明确写出内存限制、栈大小、中断响应时间这些硬指标。我当时的 SPEC 里写了“中断服务函数执行时间不超过 50 微秒”AI 生成的代码里有一个循环查表操作实测下来超了 3 倍后来改成查表加缓存才达标。另一个坑是硬件相关的代码 AI 容易“想当然”。比如寄存器地址、时序要求、外设初始化顺序AI 会按通用模式生成但具体芯片可能不一样。我的经验是硬件相关的代码AI 生成后必须逐行对照芯片手册校验不能直接烧录。这个环节省不得省了就是给自己埋雷。5. 招聘与团队协作的实际变化5.1 面试考察维度的调整过去半年我参与了十几场面试明显感觉到传统八股文的区分度在下降。一个候选人能把 JVM 内存模型背得滚瓜烂熟但让他写一份给 AI 用的 SPEC他写不出来。反过来有些候选人框架源码读得不多但能把业务需求拆得清清楚楚提示词写得精准AI 生成的代码质量很高。我现在面试会重点考察三个维度第一需求拆解能力。给一个模糊需求看候选人能不能拆成可执行的 SPEC。这个能力比背八股文难多了因为它需要业务理解、技术判断和表达能力的综合。第二提示词编写能力。让候选人现场写一段提示词然后我用 AI 工具跑一遍看生成结果的质量。这个环节很能看出候选人的实际水平因为提示词写得好不好结果骗不了人。第三代码审查能力。给一段 AI 生成的代码让候选人找出意图偏差和潜在风险。这个比找语法 bug 难因为需要理解 SPEC 和代码之间的映射关系。5.2 团队协作流程的适配Vibe Coding 对团队协作流程的影响比我想象的要大。以前代码 review 是“人对人”现在变成了“人对 AI 生成物”。这带来一个新问题review 的标准怎么统一我们的做法是把 SPEC 作为 review 的第一依据。review 的时候先对照 SPEC 看意图是否实现再看代码本身的质量。这样即使不同的人 review标准也是一致的。另外我们把常用的提示词模板和 SPEC 模板都放进了团队知识库新人来了直接套用减少了个体差异。还有一个变化是文档的重要性上升了。以前代码即文档看代码就知道逻辑。现在 AI 生成的代码可能一周后就没人记得当初为什么这么写了所以 SPEC 和提示词必须存档。我们现在的规矩是没有 SPEC 的 AI 生成代码不允许合并。这条规矩一开始有人抵触觉得麻烦但后来线上问题少了大家也就接受了。5.3 常见问题与排查技巧实录在实际推行 Vibe Coding 的过程中我整理了一份常见问题速查表基本都是踩过的坑问题现象可能原因排查思路解决方法AI 生成代码编译不过框架版本不匹配检查提示词里的版本信息在提示词中显式指定版本代码能跑但结果不对SPEC 边界条件缺失对照 SPEC 检查异常场景补充边界条件后重新生成生成的代码风格不一致缺少代码规范约束检查提示词是否包含规范要求把团队规范写入提示词模板Agent 执行到一半卡住上下文丢失或冲突检查上下文变量传递显式传递关键约束变量多 agent 互相覆盖职责边界不清检查各 agent 的文件范围明确划分职责和文件范围嵌入式代码资源超标SPEC 缺少资源约束检查内存和时序指标在 SPEC 中写明硬性指标注意AI 生成的代码在涉及安全、资金、硬件控制的场景下必须经过人工逐行审查不能直接上线。我见过因为 AI 生成的 SQL 没有参数化导致注入风险的案例这个责任最终是开发者承担的。6. 我个人的一些实操体会最后分享几个我在实际工作中总结的小技巧都是踩坑之后才想明白的。第一个技巧把大任务拆成小任务再交给 AI。我早期喜欢让 AI 一次性生成一个完整模块结果经常是前面几段没问题后面越写越偏。后来改成“先生成接口定义 → 确认无误 → 再生成实现 → 再生成测试”每一步都校验整体成功率反而更高。这跟人写代码是一样的道理一口气写一千行bug 肯定比写一百行多。第二个技巧给 AI 的提示词里加上“反例”。比如“不要生成类似SELECT * FROM这种全表查询”“不要使用System.out.println做日志”。反例比正例更能约束 AI 的行为因为它明确告诉 AI“什么不能做”。我实测下来加了反例之后AI 生成代码的返工率下降了大概三成。第三个技巧保留人工修改的记录。AI 生成的代码你手动改了哪几行最好用注释标出来或者单独记一笔。为什么因为下次 AI 重新生成这个文件的时候会覆盖你的修改。我吃过这个亏手动补的边界处理被 AI 重新生成时冲掉了线上又炸了一次。后来我养成了习惯AI 生成的文件人工修改部分单独抽成方法或配置不直接改在生成代码里。第四个技巧定期更新提示词模板。项目在变框架在升级提示词不更新就会慢慢失效。我们团队现在每个月 review 一次提示词模板把过时的约束删掉把新踩的坑加进去。这个习惯坚持了半年AI 生成代码的可用率从最初的 50% 左右稳定到了 80% 以上。Vibe Coding 不是让开发者变懒而是让开发者的价值从“写代码”转移到“定义问题”和“校验结果”上。这个转变对有些人来说是挑战对有些人来说是机会。我的判断是未来三年内不会用 AI 编程工具、不会写 SPEC、不会做 agent 编排的开发者竞争力会明显下降。但反过来那些能把业务意图翻译成精确指令、能判断 AI 输出质量、能设计自动化流程的开发者价值会比现在更高。这个趋势已经很明显了早适应早受益。
