先讲个让我失眠好几天的事。我做开发十多年看到身边不少朋友开始用AI辅助写代码第一反应不是兴奋是恐惧——那种“我练了十几年的手艺是不是马上就要归零”的恐惧。后来我强迫自己花了一个周末用vibe coding的方式从头做了个小项目从搭环境到出成品不到三小时。那一刻我意识到真正该恐惧的不是AI会写代码而是我还在用石器时代的方式跟它对抗。vibe coding并不是“乱写代码”的借口它是对编程这件事的一次重新定义你不需要亲手敲每一行语法而是把你脑子里的想法、意图、边界讲清楚让AI IDE帮你在几秒内变成可运行的代码。你从这个过程的执行者变成了决策者和审美者。这篇文章我想用我自己的前后转变把vibe coding是什么、怎么搭环境、怎么团队协作、面试会问什么、哪些场景必须刹车一次讲透。1. 先放下恐惧vibe coding 到底是什么凭什么现在成立1.1 一个“不懂代码”的朋友给我上了一课让我真正开始接受vibe coding的契机是一个只学过一点Python基础的朋友。他用了大概一个晚上靠AI编码工具做出来一个能自动整理本地图片、按拍摄地点生成相册的小工具。放在以前这件事对他来说至少需要两个月啃完语法、框架、API最后还不一定跑得起来。他跟我描述的过程非常简单先告诉AI自己想要什么AI生成代码他复制到环境里跑报错就把错误信息原样贴回去AI改他再跑。可能整个过程他自己写的代码不超过三行。我当时嘴上没说什么心里却已经被震住了——这不只是“效率高”这是把“写程序”的门槛从“会写代码”降到了“会描述问题”。这背后是vibe coding最核心的转变编程从打字题变成了表达题。AI帮你写代码你负责告诉它你想要什么以及判断它给你的东西对不对。过去衡量一个程序员的是语法熟练度和API记忆量今天真正值钱的能力变成了需求拆解、边界描述、质量审查。1.2 vibe coding 为什么偏偏是现在火起来其实“用自然语言让机器干活”这件事很早就有雏形但之前一直不温不火。原因很简单以前的模型不够强你说一句话过去它给你的代码质量撑不起真实项目。现在这代大语言模型在代码生成、上下文理解、多文件编辑上的能力已经到了一条拐点线再加上AI原生IDE比如Trae Code、Cursor把聊天、代码编辑、运行、调试全部塞进同一个窗口vibe coding才真正有了落地的土壤。我自己用了之后总结它之所以突然这么火还有一个心理层面的原因它给你极其短的正反馈周期。以前写一个功能想架构、写接口、联调、排错可能半天过去了。现在你一句话下去代码出来跑一下有问题再修整个循环被压缩到几分钟。这种节奏会让人上瘾但也会让人忽略一个关键问题——代码是跑起来了它到底对不对、稳不稳、有没有漏洞这恰恰是下一节要重点讲的。2. 搭好这四件套你也能立刻开始vibe codingTrae Code实战2.1 第一件套选一个AI味最正的IDE我前前后后试过GitHub Copilot和Cursor最近一段时间主力用的是字节跳动的Trae Code。选它的原因很实际第一它把AI能力做成了IDE的原生部分而不是插件式的“缝合怪”新建项目、写代码、选文件、跑终端全都统一在一个界面里第二它对中文提示词的理解让我比较满意虽然我会习惯性写英文但团队里不少同事直接中文描述需求它一样能生成可用的代码这对中文团队来说非常友好。如果你也想快速体验大致流程是去Trae官网下载对应系统的客户端用账号登录然后在设置里把模型选好可以用默认的Claude系列也可以按项目需要切换别的模型再把你的项目文件夹拖进IDE它就会自动建立索引后面你提问、让它改代码它都基于这个项目上下文来回答。提示别急着让AI“全自动”干活。第一次用vibe coding的正确姿势是手动看它每一步生成的diff确认自己看懂每行代码在干嘛。这一条习惯会让你少踩无数坑。2.2 第二件套把需求说清楚的提示词基本功很多人以为vibe coding就是“把需求甩给AI”但同样是甩需求效果天差地别。我总结了一个好用的提示词公式角色 背景 目标 约束 验收标准。举个例子你别说“帮我写个登录接口”你可以这样说你是一名熟悉Spring Boot的资深后端工程师我正在做一个社区Web应用需要实现一个基于JWT的登录接口。用户通过手机号和密码登录密码需要用BCrypt校验。接口要求返回token和用户基本信息。注意处理用户不存在和密码错误两种异常情况返回统一的JSON错误格式。我把这两段提示词分别试过后者生成的代码可复用性高出至少一个量级。原因很直接AI不是读心术你给它越清晰的边界它给你的代码就越接近你想要的东西。这是我建议所有vibe coding新手最先练的基本功比学会哪个工具重要得多。2.3 第三件套跑起来是开始读diff才是关键vibe coding最容易让人翻车的环节不是生成而是审查。我在实操中给自己定了一条规矩AI生成的每一段代码必须提交前读一遍diff读不懂的地方要么让AI解释要么重写。因为AI再强它也不了解你的业务全貌、你的历史包袱、你的性能约束它只是按概率在生成“看起来对”的代码。更实际的建议是别把AI生成完的代码当终点要把它当第一版草稿。跑通功能只是第一步接下来你要检查有没有硬编码的密钥有没有把日志打到生产环境有没有对用户输入做校验有没有明显的性能浪费。每一条都是在跟AI的盲区作斗争。2.4 第四件套把报错信息当成最重要的对话素材vibe coding过程中出现报错几乎是必然的。但很多人遇到报错只会一脸茫然地贴一句话给AIAI也经常给不出准确答案。我试过更高效的方式把完整的错误堆栈、关键配置文件、出错的代码片段一起发给AI并且附上“你期望它做什么、实际发生了什么”。报错信息里最关键的其实不是最后那句红色英文而是堆栈中你自己的项目文件路径那才是定位问题的主线。如果报错是在第三方依赖里那就把依赖版本号和触发场景告诉AI。把它当同事一样协作而不是当成一个搜索框这是vibe coding进阶的第一个标志。3. 全局md文档vibe coding 团队协作的关键基础设施3.1 没有共享上下文AI就变“金鱼记忆”单独一个人vibe coding其实问题不大因为你自己脑子里有上下文。但到了团队里麻烦立刻就来了每个人用AI生成代码的最高频方式是聊天式对话而聊天记录是私有的、零散的、无法被他人复用的。结果就是A同事的AI知道项目为什么这么设计B同事的AI完全不知道两个人的代码风格和实现思路南辕北辙。我踩过一次很深的坑团队里一位同事用vibe coding快速独立开发了一个支付回调模块开发时一切都好等要跟其他人的订单模块联调时发现双方对金额字段的精度处理完全不一致线上排查了一整天才找到原因——AI各自按各自的理解生成了“看起来对”的代码。问题不在AI在于团队缺少一个让AI共享上下文的地方。3.2 一份合格的全局md文档应该长什么样后来我们团队的做法是建立一份“全局md文档”把它放在项目根目录作为所有人和所有AI工具的共识层。这份文档不是普通的README而是项目的“大脑拷贝”AI在生成代码之前先读取这份文档就知道自己处于哪个模块、遵循什么规范、依赖什么服务。下面是我现在项目里实际在用的结构模板你可以直接抄走再按需修改# 项目全局上下文 ## 1. 项目愿景 用一句话说清楚这个项目帮用户解决什么问题服务谁。 ## 2. 技术栈与版本约束 - 前端: Vue3 TypeScript Vitenode 18 - 后端: Spring Boot 3 Java 17 - 数据库: PostgreSQL 15 - 关键依赖: 说明版本原因比如某个库必须锁版本 ## 3. 目录结构与模块职责 - /frontend 存放前端代码禁止在这里放后端逻辑 - /backend 存放后端代码支付模块请见 /backend/src/main/java/com/pay - /docs 存放各类设计文档 ## 4. 编码规范与约束 - 所有金额字段一律使用分(Long)存储禁止使用浮点数 - 所有对外接口必须做参数校验并返回统一消息格式 - 日志不得打印敏感字段包括手机号、身份证号、银行卡号 - API路径一律使用小写中划线风格如 /api/user-profile ## 5. 核心业务规则 - 订单取消后库存退回不能超过二次 - 优惠券每个用户每天只能领取一次 ## 6. 架构决策记录(ADR) - ADR-001: 选择PostgreSQL而非MySQL的原因 - ADR-002: 消息队列从自研迁移到RabbitMQ的经过 ## 7. 当前任务状态 - [进行中] 支付回调幂等处理负责人: 阿明 - [待开始] 后台报表导出功能这份文档最重要的价值是它让AI的“记忆”变成团队共享资产。我在Trae Code里写提示词时第一句话通常是“先读一下项目根目录的全局md文档然后帮我…”当AI对某个设计决策产生困惑时我让它去查ADR当我离开项目一个月再回来时不再需要到处找人问“当初为什么这么写”直接读这个文档就能捡回来。3.3 全局md文档的维护节奏和协作约定文档不会自己维护所以一定要建立团队约定。我们目前的做法很轻量每个迭代开始前任务负责人把当前迭代的目标和边界更新进“当前任务状态”每次做出影响全局的架构决策时必须补一条ADR哪怕只有三句话全局md文档由技术负责人统一review防止有人往里写大段废话这套流程跑起来之后明显的变化是团队里新同学的接入成本降了至少一半因为他们的第一个动作不是翻代码而是读文档AI生成代码的“跑偏率”也远低于没有共享上下文的时候。vibe coding团队协作最大的秘密其实就是这句大白话你不能只给AI一个聊天框你要给它一本“公司规章”。4. vibe coding 面试题背后的能力模型品味、拆解与边界4.1 当“会写代码”不再是问题面试官开始问什么vibe coding火了之后一个很现实的问题跟着来了面试还考什么我在帮团队招人的时候发现传统的“手写一个快速排序”“背一下HTTP状态码”这类题目正在快速失去考察价值——因为这些AI瞬间就能写出来而且比多数人写得更好。那还要不要现场写代码要但考察的点完全变了。我们不再关心你能否凭记忆写出语法而是给你一个模糊的、有冲突的需求让你现场通过AI把想法变成可运行的方案然后我问你为什么这么设计这个方案在什么情况下会挂掉假如数据量扩大十倍瓶颈在哪里4.2 我总结的一组“vibe coding 面试题”思路有同行问我到底该怎么准备vibe coding相关的面试。我把常用的问题方向整理成了三类每一类背后对应一个核心能力面试问题类型典型问题示例考察的核心能力需求拆解类“用vibe coding做一个秒杀系统你会怎么给AI下第一轮指令”能否把模糊业务描述拆成实体、接口、约束、异常分支代码审查类“AI生成了这段涉及并发扣减库存的代码请指出哪里不安全并给出修复方案。”是否有能力识别竞态条件、事务边界、幂等等隐患边界意识类“什么样的项目功能你不会交给AI直接写为什么”是否清楚能力边界、风险边界是否有敬畏心第一类题是想看你会不会用提示词把需求讲清楚以及在动手前有没有想过异常情况这是一个“老工程师思维”和“工具人思维”的分水岭。第二类题是在模拟vibe coding最真实的场景——AI产出草稿你来当security guard。第三类题最阴险因为它没有标准答案真正有经验的人会说“涉及资金安全、用户隐私、核心算法的地方我会自己手写核心逻辑AI只用来做辅助和外围”没有经验的人则会自信地说“AI什么都能写”。4.3 怎么提升这些面试里真正值钱的能力如果你正在被这个问题困扰我给的建议很简单别去背题去做项目。真正深度地vibe coding一个完整的、带上线压力的项目哪怕是个小的线上服务比刷一百道题都有意义。在这个过程里你会被迫面对上线前发现的隐藏bug、访问量上来后的性能问题、用户反馈的各种边界场景这些经验会慢慢长成你的品味和边界感而这些都是AI替代不了的。再补充一点vibe coding时代反而更要重视基础知识。计算机网络的TCP握手、数据库索引结构、操作系统的进程模型这些底层知识决定了你能否判断AI生成的代码“能不能扛住真实场景”。AI可以帮你回忆语法细节但它不能帮你建立判断力。5. 该刹车时必须刹车vibe coding 的安全边界与兜底手段5.1 我对vibe coding绝不越界的几类场景虽然我是vibe coding的推广者但我要把丑话说在前面它远没有到“无脑可信任”的程度。在我自己的标准里下面几类场景我会主动把手工作模式调回来涉及资金安全的核心链路支付、对账、优惠券发放。这些地方逻辑上出一个小bug带来的不是线上报错而是直接的经济损失和信任崩塌。AI生成的代码我可以参考但核心逻辑我一定要自己逐行推演并补上自己写的单元测试。用户隐私数据相关任何涉及手机号、身份证号、日志脱敏、权限控制的代码。倒不是AI写不出来而是隐私合规条款更新太快AI训练数据里对这些“最新的红线”理解并不可靠。高并发与强一致性的核心系统秒杀、库存扣减、分布式锁这些场景需要开发者对并发模型有非常清楚的认识AI给出的“看起来正确”的方案经常在极端压力下才暴露问题。你完全看不懂的代码这句话是我给自己定的铁律。如果AI生成的一段代码我读都读不懂那它再“高效”我也一定不用。一个你自己都不能解释的系统意味着线上出问题时你连排查方向都没有。5.2 兜底五件套vibe coding 不能省的完整保护网很多新手在vibe coding时最容易忽略的不是写代码而是写代码之外的那一圈“保护网”。我列了一个最小集版本控制必须全部入库AI每次生成的代码都要走git提交这样你才有回滚的能力。代码审查必须存在哪怕是你个人的小项目也要养成“写完之后自己review一遍diff”的习惯团队项目则必须让另一个人过一遍。测试必须跟上AI写代码你写测试这是一个很合理的分工。如果团队有全职QA请务必让QA站在用户视角挑战AI生成的“假实现”。配置与密钥隔离禁止AI把数据库密码、云服务密钥、第三方API Key直接写进代码里这个坑我见过太多次。分阶段验收大功能拆成小阶段每完成一个阶段就跑起来验证而不是等AI一次性生成一个巨大的模块最后根本没法排错。5.3 我更推荐的工作方式让AI跑外围自己守核心说了这么多刹车场景其实最终我想表达的是一个更积极的工作方式。我现在做项目的默认流程是AI负责把项目骨架、CRUD接口、数据模型定义、单元测试初稿、文档草稿这些“外围”工作快速铺开而我这个所谓“资深开发”的时间全部集中在最核心、最复杂、最少有现成答案的地方——架构的技术选型、核心算法的设计、系统之间的边界、以及上线前后的风险把控。这件事放到vibe coding的语境下就是让AI帮你无限提速但方向盘始终在你手里。项目跑得再快方向盘掉了翻车就是一瞬间的事。这是我经历过几次线上事故之后最刻骨铭心的一个体会。最后再分享一点我的用法技巧如果你现在正处于“既想尝试vibe coding又怕被同事笑话”的纠结状态我建议你先找一个跟工作无关的小工具动手练一练——比如帮自己做一个命令行下备份文件的脚本或者给家里做个智能提醒网页。别管它多幼稚跑通一次完整的“想法-提示词-代码-运行-修复”循环你才会真正上瘾并建立起对AI产出质量的直觉。另外一个小技巧我在所有的AI IDE交互里都会在关键操作前加一句“请先检查项目中是否有相关的全局md文档或规范说明遵循其中的约定”这句话极大地提高了AI对项目的“环境感知”能力也让全局md文档真正变成了团队协作的枢纽。对我来说vibe coding最妙的地方并不是“写代码变快了”而是它让我重新发现了自己作为工程师最值钱的那部分——审美、判断、边界感以及面对不确定性的那一点点冷静。
