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 输出质量、能设计自动化流程的开发者，价值会比现在更高。这个趋势已经很明显了，早适应早受益。
