最近身边不少朋友都在聊“Vibe Coding”这个词有些是做前端的有些是做后端的还有些是做产品的。大家的困惑很一致这到底是一种编程新潮流还是又一个被AI炒出来的玄学刚好我在跑“AIPDK”系列笔记第二节的主题就是Vibe Coding概念与AI辅助开发范式今天就把我实际折腾下来的一些理解、踩坑和可复用的方法写出来。这篇文章不是理论科普也不是工具软文而是基于我实际在项目里使用AI辅助开发的一段记录。我会把Vibe Coding到底是什么、为什么值得关注、它和传统开发模式的关键区别以及一套能直接落地的AIPDK工作流讲清楚。无论你是刚接触AI编程的初级开发者还是已经在用Cursor、Copilot、Trae这类工具的“老手”这篇文章应该都能带来一些新角度。1. Vibe Coding到底是什么一场从“手写代码”到“描述意图”的范式转移1.1 名词来源与核心定义Vibe Coding这个词最早是Andrej Karpathy在2025年初的一次分享里提出来的。他当时的原话大意是你不再是一个逐行敲键盘的程序员而更像一个“沉浸在与AI协作的氛围”里的导演你描述想要什么AI负责把代码写出来你要做的是审阅、体验、纠偏和迭代。这个“Vibe”翻译成“氛围”或“状态”都行核心意思是你在跟AI协作时要保持一种“清楚知道自己要什么”的状态然后大量使用自然语言去描述需求。你不需要care每一个分号、每一个括号但你需要非常清楚地表达“这个函数应该接收什么参数”“这个组件的边界条件是什么”“这个接口失败的时候应该怎么处理”。我这里给出一个实操层面的定义Vibe Coding是基于大模型代码生成能力以自然语言为主要描述载体以“人的意图AI的编码能力”为核心协作方式通过短周期、高频次的生成-审查-修正循环来完成软件开发的范式。1.2 为什么现在才火起来三年前也有人喊“AI要取代程序员”但当时的大模型连代码补全都经常出错更不用说理解项目级上下文了。Vibe Coding能火起来依赖几个基础条件的成熟。第一个是代码生成能力的质变。现在的模型在主流编程语言上的代码生成质量已经达到“可用”级别尤其是Python、TypeScript、Java、Go这类高频语言。它们不仅能生成单个函数还能根据项目上下文生成跨文件的调用链这在两年前是不敢想的。第二个是长上下文能力的提升。Vibe Coding非常依赖AI对项目上下文的理解。早期的模型上下文窗口只有几千token读一个项目的目录结构都费劲。现在的大模型动辄几十万token上下文能够把项目的核心文件、配置信息、依赖关系装进去AI才能真正“懂”你的项目。第三个是Agent智能体能力的出现。以前AI只能“你说一句它写一段”现在的AI Agent可以自己规划任务、搜索代码库、运行测试、根据报错信息修复问题。比如你告诉它“实现用户注册接口包含邮箱验证、密码强度校验、防重复提交”它会自己去找到路由配置文件、数据库模型文件、校验函数然后把相关代码都改好。这些条件合在一起才让“用自然语言写代码”从噱头变成了可落地的工作方式。1.3 与传统编程和低代码平台的区别很多人会问Vibe Coding是不是就是低代码还真不是。低代码平台是让你用拖拽组件、配置属性的方式搭应用本质上还是在平台给的框架里拼积木。Vibe Coding不同代码是由大模型生成的通用代码放在你自己的项目里受你自己的架构约束完全受你控制。传统编程里人负责把需求翻译成精确的实现细节定义变量、写循环、处理异常、组织函数。低代码里人负责在固定框架里做配置。Vibe Coding里人负责描述意图、定义边界、验收结果代码实现的“中间过程”交给模型但最终代码的所有权和维护责任仍然在人手里。这句话我建议所有想尝试Vibe Coding的人先记住Vibe Coding不是把写代码这件事外包给AI而是把写代码这个动作从“手写”变成“委托审查”你的编程能力依然重要只是用在了更高层级的抽象上。2. AIPDK给大模型配一套“开发套件”2.1 为什么需要PDK这里就要聊到标题里的PDK了。在半导体行业PDK全称是Process Design Kit叫工艺设计套件是芯片设计里连接工艺厂和设计工具的标准接口。简单理解它就是一套标准化的文件集合里面定义了晶体管参数、版图规则、器件模型、仿真模型等等设计师不需要知道工艺厂内部的所有细节只要按PDK的规则来就能保证设计在指定工艺下能制造、能工作。我在“AIPDK”系列里做了一次类比迁移AI时代的开发者也需要一套自己的PDK——Prompt Development Kit提示词开发套件。为什么原因很直接没有这套“套件”的时候你跟AI协作完全靠“临场发挥”。项目背景靠临时粘贴代码风格靠口头交代技术约束靠现场打字测试要求经常忘记告诉它。结果就是AI生成的代码风格飘忽、架构混乱、复用性差甚至在你没注意的时候引入了一堆不易发现的逻辑问题。这和芯片设计里不用PDK硬画版图的结局是一样的眼前看着能用一到流片就翻车。所以我在团队里和写这个系列笔记时都坚持一个观点想把AI辅助开发从“偶尔用用”变成“日常生产力”必须先把你的PDK建起来。2.2 AIPDK的核心组成一套可落地的AIPDK我认为应该包含以下五块内容全局规则文件定义项目技术栈、目录结构约定、命名规范、代码风格、禁用依赖、安全红线。任务模板把常见开发任务的描述结构固化下来比如新功能开发、Bug修复、代码重构、测试补充、SQL编写每种任务用一套统一的描述格式。项目上下文库项目核心模块的说明文档、架构决策记录、接口变更历史还有第三方依赖的使用约定。相当于给AI的“项目知识手册”。验证脚本集AI生成代码后谁来验收不能只靠肉眼需要一组跑得了的测试脚本、静态检查命令、构建命令让AI生成完代码后自测一遍。迭代审计记录记录每次AI交互中出现的典型问题和修正方案。这是坑位地图踩过一次的坑不要让AI再踩第二次。这个结构参考的就是半导体PDK的思路把“成功所需的标准要素”前置、固化、标准化让任何一次新的项目都站在之前积累的经验之上而不是每次从零开始。2.3 没有PDK时的典型混乱现场我举个例子大家看看眼不眼熟。项目里有一段老代码某天需要加一个新接口。你没有PDK直接跟AI说“帮我加一个获取用户信息的接口。”AI很可能就会按自己“理解”的常见风格写新建一个Service类、用另一种依赖注入方式、返回结构跟你项目里其他接口不一样、异常处理写法也完全不同。代码本身可能能跑但整个功能的气质跟项目割裂严重接手的维护者内心是崩溃的。有PDK之后同样是这个需求你的描述会变成“按照全局规则里Service层的分层规范在user模块新增一个查询接口接口路径遵循restful命名返回结构使用统一Result包装校验逻辑放在controller层异常使用业务异常码。”AI拿到这些约束和示例后生成的代码基本就是“长在项目里”的代码而不是“外来的野代码”。差距就是这么明显。3. 实操从零搭建一套可复用的Vibe Coding工作流3.1 环境选型我为什么一直用Trae Code这类IDE要跑Vibe Coding工具链是绕不开的。目前主流的选择有GitHub Copilot、Cursor、Trae、Codeium、通义灵码等各有各的长处。我在系列讨论里比较常推荐的是Trae Code原因是它有几个点比较适合国内开发者的使用节奏。Trae Code本质上是一个AI原生的IDE它把对话、代码编辑、终端、文件上下文融合在一个界面里。你在IDE里直接跟AI对话AI能读取当前打开的文件夹、自动识别项目语言、根据你的指令直接修改文件。相比传统的“复制代码到网页里生成再粘回编辑器”这种一体化体验确实让Vibe Coding的“循环速度”快了很多倍。当然我用Trae不意味着其他工具不行。Cursoe也很好Agent能力更强Copilot胜在跟GitHub生态无缝衔接。我的建议是工具选一款顺手的但方法论必须跑通——如果方法论没跑通换什么工具都是花架子。这里给一个简单选型对照表工具特点适合人群Trae CodeAI原生IDE中文友好上手快适合国内网络环境刚接触AI辅助开发的初级/中级开发者CursorAgent能力强多文件编辑和重构方便已经有项目经验想做深度重构的开发者GitHub Copilot代码补全响应快跟GitHub生态深度绑定常年在GitHub上协作的团队Codeium免费额度大轻量预算有限的学生和独立开发者3.2 关键一步用全局MD文档把“矿规”定下来Vibe Coding实操里最容易被忽略、也是最重要的一步是写全局上下文文档。很多人用AI写代码是打开对话框就开干“帮我写个登录接口。”AI写出来的东西能不能用全凭运气。因为AI对你的项目一无所知它只能根据通用经验生成一份约等于“demo”的代码。要让AI生成真正能落地的代码你得先让它“懂”你的项目。怎么懂给它一份结构化的项目说明。这份说明我一般放在项目根目录下的一个全局MD文档里比如AGENTS.md或PROJECT_RULES.md内容涵盖项目简介和技术栈这个项目是干什么的用了什么框架、什么版本、什么包管理器。目录结构每个目录放什么类型的代码现有模块有哪些。命名规范变量、函数、类、文件、组件、接口路由的命名规则。架构约束分层规则、依赖方向、是否允许跨层调用、状态管理方案。代码风格缩进、引号、分号、注释规范和ESLint/Prettier等工具要求对齐。认证与安全要求接口鉴权方式、数据校验规范、敏感信息处理方式。测试要求哪些代码必须配单元测试测试文件放哪里用什么测试框架。写这份文档是有技巧的。不要写成一个几百行的“长篇大论”AI的上下文窗口虽然大但塞太多废话反而会稀释重点。我会控制在100到150行以内用最简洁的语言把高频约束写清楚。关键是让AI在生成代码时大概率遵守你最重要的那几条规则。写完这份文档后在IDE的规则设置里把它关联上。Trae里一般在项目设置或模型设置里指定要加载的规则文件这样每次对话AI都会自动读到这份“矿规”。3.3 任务拆解把“一大坨需求”变成“一串小指令”如果说规则文件是地基任务拆解就是Vibe Coding工作流的承重墙。很多人用AI辅助开发习惯把需求一次性丢给它“帮我做一个完整的博客系统包含用户注册、登录、文章CRUD、评论、标签、搜索、后台管理。”然后期望AI一次性吐出所有代码。我试过结果基本是崩溃的AI生成到一半上下文就乱了或者生成出来的模块之间风格不一致后期调试改到怀疑人生。这里要用一个原则小步快跑单点突破。一次对话只让AI做一个足够小、边界足够清楚的任务。比如说“博客系统”这个需求可以拆成初始化项目结构和路由配置实现用户注册接口含参数校验和密码加密实现用户登录接口含JWT签发实现文章模型定义和数据表迁移实现文章创建接口含登录状态校验实现文章列表接口含分页和标签过滤实现文章详情接口含浏览数自增实现评论的增删查接口每个任务独立触发一次对话生成完、验证完、合入后再进入下一个任务。这样做的原因有两点一是单个任务描述可以写得更精确AI的生成质量会高很多二是出问题时排查范围小不会出现“这个Bug到底是哪次生成引入的”这种玄学问题。3.4 写Prompt的三层结构角色、背景、验收讲完拆解再说说每次任务里Prompt怎么写。我用了一套“三层结构”差不多能覆盖90%的常见场景。第一层是角色设定告诉AI你是谁。不需要花哨简单直接“你是一个熟悉Python/Flask的后端工程师请遵循项目AGENTS.md中的规范。”第二层是背景信息把当前要改动的模块、涉及到的文件、关键约束交代清楚。比如“项目是用户中心服务技术栈是FlaskPostgreSQL。现有用户模型在models/user.py认证逻辑在services/auth.py路由在routers/user.py。新功能是给用户增加更新手机号的能力需要校验旧手机号验证码。”第三层是验收标准明确告诉AI什么样的输出是合格的。比如“请修改routers/user.py新增POST /api/user/update_phone接口请求参数包含old_phone、old_code、new_phone、new_code校验通过后更新用户手机号返回统一格式result中datatrue同时附带单元测试。不要修改数据库表结构手机号唯一性校验放在service层。”这套三层结构看起来简单但真正做到位的人不多。大部分人的Prompt只写了第一层或者只写了需求本身背景和验收完全缺失AI就只能靠猜。我自己的经验是写Prompt花的时间跟以前写详细设计文档差不多但回报非常明显。以前一个接口从想到跑通可能要四十分钟现在合理描述需求后AI十分钟内生成我再花十分钟审查和修正总时长反而缩短了。3.5 实际案例用自然语言让AI生成一个带校验的用户表单这里放一个完整的实操记录大家感受一下完整链路。任务在后台管理系统中新增一个“新增用户”表单页面包含用户名、邮箱、手机号、角色选择前端用Vue3ElementPlus提交前要做表单校验提交后调用已有的POST /api/admin/users接口。我的Prompt是这样写的你是一名熟悉Vue3和ElementPlus的前端工程师请遵循项目AGENTS.md中的前端规范。背景admin-web是后台管理系统的前端项目基于Vue3TypeScriptViteElementPlus。用户管理页面在src/views/system/user/index.vue该页面目前只有列表和删除功能没有新增用户功能。接口定义在src/api/system/user.ts中已经有createUser方法接收参数为{username, email, phone, roleId}。需求请在用户管理页面新增一个“新增用户”的弹窗表单包含用户名、邮箱、手机号、角色四个字段。角色用下拉选择选项从已加载的角色列表获取。表单校验规则参考项目里其他新增表单的写法。验收弹窗通过按钮“新增用户”触发打开时表单清空。用户名和手机号必填邮箱格式校验手机号按国内手机号规则校验。提交成功后调用createUser接口关闭弹窗并刷新列表。提交中按钮置loading防止重复提交。请只修改src/views/system/user/index.vue这一个文件如需修改类型定义给出说明。AI生成的代码我简单检查了一下表单结构、校验规则、接口调用基本符合预期。有两处小问题一是角色下拉数据源引用错了变量名二是提交后的钩子函数名跟项目里的实际定义不一致。我直接手动改了这两处整个功能从需求描述到完成测试大概花了二十分钟。如果纯手写这套页面一个小时内能写完就算快的。3.6 从生成到合入审查这一关不能省AI生成完代码后还有很多人直接看一眼就合入了。这是大忌。AI生成的代码语法是对的逻辑可能是通的但“能跑”和“合格”之间还有一大段距离。我自己每次都会做三遍检查第一遍跑一遍静态检查和测试确保不报错第二遍通读代码重点看有没有隐藏的副作用、边界条件处理是否完整、错误处理是否符合项目约定第三遍考虑可维护性命名是否清晰、逻辑是否有冗余、是否值得抽成公共函数。还有一个容易被忽视的点让AI生成完代码后让它自己跑一遍项目已有的测试或者告诉它“生成完代码后运行pnpm test pnpm lint”。这一步能挡掉很多低级错误。现在的Agent工具已经支持执行终端命令别浪费这个能力。4. 我踩过的坑Vibe Coding常见问题与排查实录4.1 修了A功能破坏了B功能这是AI辅助开发里最典型的翻车场景。有一次我让AI优化一个数据导出功能的性能AI识别到部分逻辑可以复用就顺手重构了另一个模块里的公共函数结果导出功能是快了但另一个报表模块的数据统计对不上了。排查方式很简单每次AI修改完代码第一时间用git diff检查改动范围确认AI有没有动“跟本次需求无关”的文件。如果动了必须问清楚原因或者直接还原。我给团队定的规矩是一次任务只允许改指定文件超出范围必须先说明。4.2 幻觉API生成了项目里根本不存在的方法有一次AI生成一个文件上传功能代码里用了一个叫uploadFileWithProgress的方法看起来很合理但实际上项目里根本没有这个方法是AI“编”出来的。这是大模型的通病它见多了类似项目就会按“统计概率”补全它认为可能存在的方法名。解决办法有两个。一是事前约束在任务背景里明确写出可用的方法名和文件路径不给AI自由发挥的空间。二是事后验证让AI在生成完后做一次“是否存在引用”的自检或者在跑测试时让报错来暴露问题。我在PDK里建了一个“项目常用API速查”文档把项目里核心服务的导出函数、常用配置项都列出来AI引用时翻一下这个文档幻觉概率会大幅下降。4.3 提示词太模糊返工成本翻倍“帮我把这个页面优化一下”——这种Prompt是返工重灾区。“优化”到底指什么性能优化、UI美化、代码可读性优化、减少重复请求还是移动端适配AI不知道它就按自己的理解执行结果大概率不是你要的。我的建议是提示词里尽量少用“优化”“完善”“改进”这类抽象动词换成具体的指令比如“把列表渲染从v-for遍历改为虚拟滚动固定行高为50px”“把接口请求从串行改为并发失败时重试2次”“把这个页面拆成三个子组件props按下方类型定义传参”。如果AI理解出现偏差就顺着它的输出一步步修正而不是反复推倒重来。推倒重来是效率黑洞跟AI协作的节奏应该是“微调式迭代”不是“推翻式重写”。4.4 上下文丢失聊着聊着AI“失忆”了长对话里AI会逐渐遗忘早期的约束这是所有大模型都存在的问题。最典型的场景是我们聊了一个复杂的重构任务到第七八轮的时候我给它一个修改指令它给出的代码里已经忘掉了最早定下的“不允许使用any类型”的约束。对付这个问题有两个办法。一是像前面说的把核心约束放在全局规则文件里AI每次读取上下文时都能看到而不依赖对话记忆。二是及时开新对话当一个任务聊了超过十轮或者发现AI开始丢三落四了就把当前已完成的部分保存开一个新对话把需要继续的内容和全局规则重新喂一遍。4.5 效率陷阱频繁重新生成 vs 手动修代码还有一个很隐秘的坑很多人习惯对AI的输出不满意就让它重新生成一次不行两次两次不行五次。这种“抽卡式开发”效率极低而且生成结果之间可能完全不连续修复一个旧问题又引入一个新问题。我现在的习惯是AI第一次生成的代码如果整体方向是对的就基于它做局部修改——自己动手改几行或者给AI一个非常明确的修补指令比如“把第42行的判断条件改成正则校验手机号格式其他逻辑不要动”。如果第一次生成的方向就歪了说明Prompt里的关键信息没给够这时候不要急着重新生成应该先补充背景再重启一轮对话。4.6 合规和安全问题不能忘AI生成的代码里可能存在安全隐患这是很多人刚接触时完全没意识到的。我遇到过AI生成的SQL查询直接拼接了字符串参数、AI生成的下载接口没有校验文件路径导致目录穿越风险、AI生成的前端代码把后端错误信息直接弹给用户泄露内部细节等情况。处理办法是把“安全红线”写进PDK的规则文件里像“禁止字符串拼接SQL”“所有外部输入必须经过参数校验后再使用”“错误日志里不得包含敏感字段”“生成的代码不得包含硬编码密钥”这些全部白纸黑字写下来。AI遵守规则文件的效果远比每次对话时临时叮嘱要好。5. 经验总结Vibe Coding不是“不用写代码”而是“写代码的方式变了”5.1 什么样的人最适合进入Vibe Coding状态从我的实践看有三类人最容易从Vibe Coding中获益。第一类是有一定项目经验的开发者。你对业务和架构有自己的判断力能分辨AI生成代码的好坏知道哪些地方要改、哪些能用。对这类人来说AI是效率放大器。第二类是全栈开发者和独立开发者。一个人的精力有限Vibe Coding能帮你快速把前后端、脚本、测试这些“全都要写”的场景铺开把以前需要外包或加班的工作压缩到几个小时内完成。第三类是技术背景的产品经理或项目经理。他们不需要成为资深程序员但需要快速验证想法。用自然语言描述一个原型AI生成可运行的代码这比用Axure画原型有说服力得多。至于纯零基础的新手我不建议一上来就依赖AI生成代码。因为你缺少判断力AI生成了错误代码你也不知道错在哪。先用传统方式打好编程基础再来玩Vibe Coding体验会完全不同。5.2 我的个人体会主动权永远在人的手里最后聊点我自己的感受。接触Vibe Coding这段时间我最大的体会是它没有让程序员“失业”反而让程序员对架构、业务和代码质量的理解变得更值钱了。因为AI能很快把“能跑的代码”写出来但“什么是好的代码”“为什么这里要做一层抽象”“这个接口的边界条件有哪些”“这个改动会不会影响现有用户”——这些判断仍然需要人来完成。Vibe Coding的终点不是让AI替你做决定而是让你把精力从重复性的编码劳动中解放出来去做真正需要人做判断的事情。我现在的编码日常已经变成了写规则、拆任务、审代码、调细节。相比以前整天泡在语法和Bug里这个工作方式的体感确实好了很多。如果你也想尝试我建议先从一个小项目或一个小模块开始把自己的PDK搭起来写一份规则文件拆一个简单任务跑通一次“提示词-生成-审查-合入”的完整循环。跑通之后你会发现这套方式不是替代你的编程能力而是把你从地板托到了更高的位置。祝各位写码顺利。