vibe coding 是这两年 AI 辅助编程里被反复提及的一种工作方式。它不是让开发者躺平而是把“怎么写代码”这个环节部分交给 AI把精力留给“做什么、怎么验证、怎么修”。实际体验过的人会明显感受到从只有一个想法到屏幕上出现可交互页面整个过程被压缩到几分钟。这种即时反馈就是 vibe coding 最让人上瘾的地方。不过vibe coding 的快乐背后也有代价。如果只是不断地把报错粘贴给 AI却不知道项目结构、依赖关系、数据流向很快会陷入“生成代码—报错—再生成—再报错”的循环。这篇文章围绕一次最小 Web 项目实践讲清楚 vibe coding 的完整链路工具选型、需求描述、代码生成、运行验证、问题排查也单独讨论鸿蒙开发中应用 vibe coding 时要注意的差异。文章里所有命令和代码都来自常见工程场景落地时请以你自己的项目版本为准。1. 先理解 Vibe Coding它不是替代开发者而是改变开发节奏1.1 从自然语言到可运行程序中间发生了什么Vibe coding 的核心流程并不复杂开发者用自然语言描述功能AI 编码工具生成代码开发者运行、查看、修正然后再把新的想法抛给 AI。这个过程和传统编码的核心区别在于开发者不再逐行敲击所有代码而是把大量样板代码、组件结构、接口拼接工作交给模型完成。以最简单的 Web 页面为例传统写法需要先建项目、配依赖、写组件、写样式再处理事件。vibe coding 流程里你只需要告诉 AI“创建一个 React 页面左侧是输入框和新增按钮右侧是待办列表点击删除按钮可以移除该项。”工具会直接生成对应的组件代码。这里发生了一次职责转移模型负责语法实现开发者负责判断这段代码是否真的满足需求。但要注意职责转移不等于责任转移。AI 生成的代码仍然需要人来确认。比如待办列表是否使用了不可变的 state 更新方式输入框是否受控删除操作是否影响了正确的数组项。这些判断能力恰恰是 vibe coding 能否顺畅进行的前提。1.2 为什么这个流程会让人感到“快乐”Vibe coding 的快乐首先来自反馈速度。过去写一个页面至少需要经历“项目初始化—代码编写—编译—调试—调整样式”几个较慢的阶段。现在 AI 可以在几十秒内生成一版可运行代码开发者能立刻看到页面长什么样、交互是否成立。这种“想法到产物”的短路径会显著减少开发过程中的疲惫感。其次它降低了从空白页面开始的压力。很多人都有过这种体验面对一个空文件不知道从哪里下笔。vibe coding 让“第一版代码”变得很容易获得。哪怕这版代码不完美也比空文件更容易讨论和修改。AI 生成的代码成了草图开发者要做的是在这个草图基础上继续打磨。还有一点容易被忽略vibe coding 能把人从重复的模板代码里解放出来。表格、表单、列表、增删改查这些功能在业务系统里大量出现结构相似但又不完全相同。让 AI 先生成基础版本再按业务差异微调比手动复制粘贴旧代码更清晰也不容易把无关逻辑带进来。1.3 快乐的前提是明确边界Vibe coding 也有完全不快乐的场景项目一上来就要求 AI 生成整个系统依赖全部交给 AI 猜接口文档不看类型不检查运行报错后也不读堆栈只是把错误信息原样粘贴回对话框。这样操作前几分钟很爽后面会越来越失控。所以这里要建立第一组边界适合用 vibe coding 的场景原型验证、学习示例、页面骨架、一次性脚本、接口联调时的 mock 数据。不适合上来就用的场景涉及权限、支付、数据迁移、高并发、复杂状态管理的核心模块。必须人工把关的环节依赖版本、安全校验、敏感信息、数据库结构、部署配置。记住这个边界后面的实践才不会被“生成速度快”带偏。2. 环境准备与工具选型不同目标对应不同的 Vibe Coding 组合2.1 本地 IDE 插件路线适合需要精细调试的项目最常见的 vibe coding 工具形态是 IDE 插件。Visual Studio Code 是生态最丰富的选择可以使用支持 AI 编码的插件例如 GitHub Copilot、通义灵码等。这些插件能根据注释、函数名和上下文补全代码也可以通过对话框直接生成整段代码。本地 IDE 路线的优点是代码留在本地方便调试、打断点、看 git diff也方便连接公司内部的依赖源和代码仓库。缺点是需要自己维护环境项目创建、依赖安装、编译报错都需要开发者有一定基础。一个常见的最小组合是Visual Studio Code Node.js 18 或更高版本 npm 或 pnpm 支持 AI 编码的 IDE 插件 Git首次使用插件时需要登录账号并确认插件能访问当前工作区文件。这里的权限不是越小越好而是要能读取项目上下文。如果插件看不到当前文件类型、依赖文件、目录结构生成结果就会很泛缺少针对性。2.2 云端 AI 编码平台路线以 Vercel AI 平台为例近两年出现了不少云端 AI 编码平台它们的共同特点是把“创建项目、生成代码、预览页面、部署上线”放进同一个浏览器界面。以 Vercel AI 平台的 vibe coding 入口为例整体使用方式通常包含这几步进入平台并登录账号选择创建新的 AI 应用项目。在输入框中用自然语言描述想要的应用类型和功能。平台生成项目代码并给出一个可预览的页面地址。继续在对话中补充需求让平台修改页面结构、交互和样式。确认效果后把项目部署到托管环境或导出代码到本地仓库。不同平台的按钮名称会变化入口也可能调整但核心逻辑是一致的自然语言驱动生成可视化预览反馈对话式迭代。这类平台适合快速验证产品想法、做演示原型、不想过早接触环境配置的开发者。云端路线的短板是黑盒较多。很多平台会在生成代码里内置示例数据这些数据在你部署后仍然存在。正式上线前需要把页面里的 mock 数据替换成真实接口并把环境变量、权限配置、域名等信息重新核对一遍。平台更新很快具体菜单以官方文档为准。2.3 鸿蒙开发场景不要把 Web 经验直接照搬鸿蒙开发里的 vibe coding 是一个正在被讨论的方向。HarmonyOS 应用使用 ArkTS 开发UI 层基于 ArkUI 声明式语法工程结构、权限配置、签名机制和 Web 项目完全不同。直接在浏览器里生成的 JavaScript 代码无法运行在鸿蒙工程里。推荐的做法是使用 DevEco Studio 开发并在支持 AI 编码的插件或内置能力辅助下工作。你可以让 AI 生成一段 ArkUI 页面代码但必须在 prompt 里明确说明“使用 ArkTS使用 ArkUI 组件面向 HarmonyOS 应用”。即使这样生成结果仍然可能与当前 SDK 版本不一致需要对照官方 API 检查。这里的核心建议是先准备一个空的鸿蒙工程让 AI 基于这个工程结构补充页面而不是从零让 AI 生成整个鸿蒙项目。工程配置、签名、权限这些内容AI 不可能完全替你判断正确。场景推荐工具组合主要优势主要风险Web 原型快速验证云端 AI 编码平台上手快、可预览、可部署示例数据残留、代码不透明正式 Web 项目开发IDE AI 插件可控、可调试、可审查需要环境基础鸿蒙应用开发DevEco Studio AI 插件贴合官方工程能真机调试AI 对 ArkTS 和 API 版本理解不稳定学习编程本地 IDE AI 插件能读代码、能打断点容易只看结果不看实现3. 最小实践用自然语言生成一个 React 待办事项页面3.1 先用一句话把需求和验收标准写清楚很多 vibe coding 翻车不是 AI 能力不够而是需求描述太模糊。比如只说“写一个待办事项应用”AI 可能生成一个带后端、数据库、用户登录的全栈项目或者生成一个简单到只有静态列表的页面。为了避免这一点第一步应该把范围限定清楚。一个可用的 prompt 可以这样写请在这个项目里实现一个待办事项组件技术栈是 Vite React TypeScript。 功能要求 1. 顶部有一个输入框和一个“新增”按钮。 2. 输入内容后点击“新增”把内容添加到待办列表。 3. 每一项待办左侧是复选框点击后可以切换完成状态完成项文字加删除线。 4. 每一项右侧有一个“删除”按钮点击后移除该项。 5. 数据先保存在 useState 中不接后端。 6. 不引入 UI 组件库样式使用简单 CSS 即可。 请给出完整的组件代码并说明如何接入 App.tsx。这段描述包含了技术栈、功能列表、数据存储方式、样式约束和交付形式。 AI 生成时会有明确依据后续检查也有验收标准没有输入框不行点击新增不更新列表不行删除按钮不生效不行。3.2 让 AI 生成项目骨架在本地 IDE 里可以先手动创建一个 Vite 项目骨架再让 AI 在项目内补充代码。原因是项目创建命令相对固定由 AI 生成反而可能引入额外文件。npm create vitelatest todo-app -- --template react-ts cd todo-app npm install项目创建完成后把上面的 prompt 粘贴给 AI 插件。AI 生成代码后通常会在当前文件或者新文件中返回结果。你需要检查它是否修改了src/App.tsx是否生成了新的组件文件是否添加了样式文件。一个典型的生成结果可能包含这些文件src/ App.tsx App.css components/ TodoInput.tsx TodoList.tsx TodoItem.tsx如果 AI 只输出了一段代码而没有说明文件位置你可以继续追问“这段代码应该放在哪个文件里请给出完整的目录结构。”不要自己猜文件名避免文件路径和导入语句对不上。3.3 在云端平台用同样的思路完成生成与部署在 Vercel AI 这类云端平台里操作路径会稍微不同。你不需要先在本地创建项目而是直接打开平台的新建项目页面在对话框里输入同样的需求描述。平台生成第一版之后先看预览页面的基础效果输入框是否显示。点击新增后列表是否增加。复选框是否能切换状态。删除按钮是否生效。这些是功能验收不是 UI 审美验收。先确认交互逻辑成立再通过新的 prompt 调整样式。例如可以说“把输入框和按钮放在一行列表项之间增加分割线完成项的字体颜色改为灰色。” 云端平台会基于之前的代码继续修改。确认没有明显问题后再点击部署。部署完成后记得在线上地址重新跑一遍功能。本地预览正常不代表线上正常线上可能出现接口跨域、静态资源路径、环境变量未配置等问题。3.4 运行与验证功能、交互、异常分支在本地运行项目npm run devVite 默认会启动一个本地开发服务器终端会输出访问地址通常是http://localhost:5173。打开页面后按下面的表格逐项验证验证项操作预期结果初始页面刷新页面输入框为空列表为空或显示占位文案新增功能输入“写代码”并点击新增列表出现“写代码”输入框被清空空值处理输入框为空时点击新增不添加空项或给出提示完成状态点击复选框文字出现删除线复选框被选中删除功能点击删除按钮对应项从列表消失计数统计如果生成了剩余数量完成状态切换后数字变化测试时不要只测正常路径。空输入、重复内容、快速连续点击新增这些情况最能暴露状态管理和事件处理的问题。如果 AI 生成的代码里没有空值判断后续需要补上。4. Prompt 设计把需求描述清楚AI 才能少跑偏4.1 一段高质量需求描述包含的七个要素Vibe coding 的输出质量很大程度上由输入决定。同一个功能描述方式不同生成结果差异会非常大。一个高质量 prompt 通常包含七类信息要素说明示例技术栈使用什么语言、框架、构建工具React TypeScript Vite功能范围完成哪些功能不包含哪些功能只做前端展示不做登录交互细节用户操作后页面如何变化点击新增后清空输入框数据来源数据来自接口、状态、文件还是数据库先用 useState 存本地数据样式约束是否使用组件库风格偏好不使用 UI 组件库样式简洁边界条件空值、超长文本、重复提交如何处理输入为空时不允许新增交付形式返回完整组件、修改某段代码还是补充说明给出完整 TodoItem 组件把这些信息写全AI 不需要做太多假设生成结果就更可控。反之如果只写“帮我写个登录页面”AI 就会自己决定要不要验证码、要不要记住密码、要不要调接口。这些假设很可能不符合你的需求。4.2 小步生成而不是一次生成整个系统一次生成一个完整系统很诱人但风险极大。文件一多AI 内部的上下文可能前后不一致。比如一个文件里定义了TodoItem组件另一个文件却导入成TodoCard这类命名不一致在生成时刻很难发现。推荐的做法是从小到大分步生成先让 AI 生成页面静态布局。再补充状态管理和交互逻辑。然后处理边界条件和样式优化。最后接入接口或持久化。每一步都能运行、能观察、能确认。如果某一步出问题可以直接回退到上一个稳定版本而不是在一大堆新文件里找 bug。这也是 vibe coding 和传统编码最相通的地方小步提交持续集成比一次提交千行代码安全得多。4.3 生成结果不对时如何补充描述AI 生成结果不符合预期时不要急着说“不对重新写”。更好的方式是指出具体问题并说明期望行为。错误的命令示例还是不行重新生成。这种 prompt 没有提供任何有效信息AI 只能重新猜测。正确的补充描述应该包含位置、现象和期望点击“新增”按钮后列表没有变化。我已经在输入框里输入了内容。请检查 addTodo 函数是否使用了 setTodos 更新状态而不是直接修改 todos 数组。要求点击新增后新项出现在列表末尾并且输入框清空。这样的 prompt 明确告诉 AI问题在新增逻辑期望行为是更新状态并清空输入框。AI 能直接定位修复效率会高很多。5. 代码审查与调试Vibe Coding 的下半场才是关键5.1 AI 生成代码最常见的四类问题AI 生成的代码看起来完整但真正运行时会暴露不少问题。按出现频率排序通常有四类第一类是类型问题。TypeScript 项目里AI 可能跳过接口定义直接使用any或者把可选属性当作必填属性使用。这类问题在编译阶段就会报错相对容易发现。第二类是状态更新问题。React 项目里AI 可能写出直接修改 state 的代码比如使用todos.push()而不是创建新数组。这会破坏不可变性导致页面有时候更新有时候不更新。第三类是依赖版本问题。AI 会按照训练数据里的常见版本生成代码但你本地安装的依赖版本可能不同。比如生成代码使用了较新的 API本地却是旧版本或者使用了旧 API本地已经升级。第四类是样式和布局问题。AI 生成的 CSS 类名可能与 HTML 结构不匹配或者在同一个页面里混用了不同单位的尺寸。这类问题不报错但页面表现会异常需要肉眼观察。5.2 用最小复现路径定位运行时错误遇到问题后先用一个最小操作路径复现而不是在多个功能之间来回切换。比如待办事项页面点击新增后列表没有变化可以只执行这一个操作然后打开浏览器开发者工具在 Console 里看是否有报错在 Sources 里打断点在 React DevTools 里检查todos状态的值。以 React 状态更新为例AI 常见错误写法是const addTodo () { todos.push({ id: Date.now(), text: input, done: false }); setTodos(todos); };这段代码的问题在于直接修改了原来的todos数组。React 比较状态引用时可能认为状态没有变化所以页面不更新。推荐写法是创建一个新数组const addTodo () { const next [...todos, { id: Date.now(), text: input, done: false }]; setTodos(next); setInput(); };看到这类代码差异时不需要解释给 AI直接向 AI 指出“当前 addTodo 直接修改了 todos 数组请改成不可变更新方式并在新增后清空输入框。” AI 能理解这一类描述。5.3 不要让 AI 连续修复同一个 bug 超过两轮如果同一个 bug 让 AI 修了两轮还没有解决继续让 AI 猜下去不是好选择。这时应该停止对话手动打开报错相关的文件和日志自己看一遍关键逻辑。原因很简单AI 连续修复失败说明它可能没有理解当前代码的完整上下文或者在反复使用同一套错误假设。这时你再输入“还是不行再修”大概率只会得到类似的错误结果。正确做法是把相关文件完整读一遍。找到状态更新、数据传递、事件绑定这些核心点。用console.log输出关键变量确认数据到了哪一步。在报错信息里找到文件路径和行列号定位具体代码。把定位结果和你的分析一起提供给 AI让它基于新的线索修复。记住AI 是辅助不是背锅方。它生成代码你负责理解和掌控。只有当你自己也能读懂代码时vibe coding 才不会变成“盲人摸象”。6. 常见问题排查从报错信息反推修复路径6.1 依赖缺失或版本不匹配现象项目启动时报Module not found或者某段代码使用了不存在的方法。可能原因AI 生成代码时假设了某个依赖已经安装或者假设了某个 API 在当前依赖版本中存在。检查方式# 查看当前项目安装了哪些依赖及版本 npm list react # 查看某个包是否在依赖树中 npm ls vite # 查看 package.json 中的声明 cat package.json处理建议如果缺失依赖安装指定版本如果版本过高或过低先查看官方文档确认 API 兼容性。不要让 AI 直接改package.json里的版本号除非你确认新版本不会影响其他依赖。6.2 页面能打开但数据不更新现象点击新增、删除、切换按钮后页面没有响应或者刷新后才生效。可能原因直接修改了 state 对象事件没有绑定到正确组件组件没有重新渲染。排查顺序在事件处理函数里加console.log确认点击事件是否触发。打印修改前的数据确认数据内容是否符合预期。在 render 返回处打印数据确认组件是否重新执行。检查是否使用setState更新状态而不是直接赋值。如果确认事件触发了、数据也变了、但页面没更新优先检查状态更新方式是否不可变。这是 React 项目里最容易被 AI 忽略的问题。6.3 AI 幻觉 API 或过时语法现象AI 生成了一个看起来很合理的 API 调用但运行时报is not a function或undefined。可能原因模型基于训练数据生成了不存在的 API或者使用了已经被框架废除的写法。处理建议先把报错信息里的方法名复制到搜索引擎或官方文档里确认。不要直接要求 AI 换一个方法因为它可能又生成另一个不存在的 API。正确做法是在 prompt 中限定版本和来源请使用当前项目安装的 React 18 版本语法。不要使用 ReactDOM.render改用 createRoot。API 以官方文档为准。这类约束比泛泛的“保证代码正确”有效得多。报错现象常见原因检查方式处理方向Module not found依赖未安装或路径写错查看 import 路径检查 npm ls安装依赖或修正导入路径setState 后页面不更新直接修改了原数组或对象在函数中打印数据引用改为不可变更新方式API is not a function版本不匹配或 API 不存在搜索官方文档替换为当前版本正确的 API样式不生效类名或文件引用错误检查 CSS 文件和类名修正类名或调整引入方式组件导出报错默认导出和命名导出混用查看 export 语句统一导出方式7. 当 Vibe Coding 遇到鸿蒙开发ArkTS、权限与签名是关键差异7.1 先约束语言和 UI 框架别让 AI 自由发挥鸿蒙应用开发使用 ArkTS它基于 TypeScript但增加了更严格的规定例如不支持某些动态类型特性UI 层使用 ArkUI 的声明式写法。直接把 Web 项目的 React 组件生成逻辑带到鸿蒙工程里几乎必然报错。如果你要在鸿蒙项目里使用 vibe codingprompt 里必须写清楚请使用 ArkTS 语言基于 ArkUI 声明式语法开发 HarmonyOS 应用页面。不要使用 JavaScript 的 Web DOM API。组件需要符合 Stage 模型下的页面结构。即使如此AI 仍可能生成过时的 API。鸿蒙 SDK 版本迭代较快有些组件和装饰器在不同版本里有差异。遇到编译报错时优先查看当前 SDK 对应的官方文档不要盲目修改 API 名称。7.2 权限声明、签名和真机调试不能依赖 AI 自动完成Web 项目部署到服务器后浏览器会处理大部分安全边界。鸿蒙应用不同涉及权限声明、签名、真机调试等环节。AI 可以帮你生成申请权限的代码但不能替你的应用判断是否需要某个权限。例如需要访问网络时需要在module.json5中配置权限。这个配置是否正确取决于应用的实际业务场景。AI 生成的配置只能作为起点不能成为依据。发布前需要逐项检查权限列表移除不必要的权限。真机调试也一样。AI 无法知道你本机的签名证书、调试设备、应用包名。完整的鸿蒙 vibe coding 流程应该是在 DevEco Studio 中手动创建一个空工程。确认工程能编译、能安装到模拟器。再让 AI 基于这个工程补充页面和业务代码。每次编译通过后再继续下一个功能。7.3 鸿蒙场景下的推荐实践鸿蒙开发者使用 vibe coding 时不要追求“一句话生成整个应用”而应该追求“在一个能运行的工程里让 AI 帮我写具体页面”。这样既能享受 AI 生成代码的速度又能避免工程结构失去控制。推荐的实践方式是把 ArkUI 常用组件的写法整理成项目内文档例如Row、Column、Button、TextInput的简单示例。在 prompt 中引用这些文档要求 AI 遵循。每次生成新页面后在模拟器里运行验证。权限、签名、包名相关配置固定在一个说明文件里不让 AI 随便修改。这类做法本质上是给 AI 提供“项目内约束”比每次重新描述一遍要可靠得多。8. 把 Vibe Coding 变成可持续开发方式的最佳实践清单8.1 学习阶段小项目、小步快跑、多读生成代码如果你刚开始接触 vibe coding不要一上来就做完整业务系统。先选一个小功能比如一个计算器、一个待办列表、一个 Markdown 预览页完整走一遍“描述—生成—运行—修改—部署”的流程。学习阶段最重要的不是让 AI 生成更多代码而是读懂 AI 生成的代码。每拿到一段代码至少问自己三件事这段代码的数据流向是什么为什么这里用这个 API 而不是另一个如果需求变化我应该改哪里当你发现能回答这些问题时vibe coding 就不会让技术能力退化反而会成为理解框架的新入口。8.2 工程阶段代码审查、版本控制、配置外置进入正式项目后AI 生成的代码必须经过和人工写代码一样的审查流程。不要因为代码来自 AI就跳过 review。审查时重点关注是否存在硬编码的密钥、密码、地址。是否有不必要的类型断言或any。错误处理是否吞掉了异常。敏感操作是否有权限判断。是否有重复造轮子项目里已经有现成工具函数。版本控制上保持小粒度提交。AI 每完成一个清晰的改动确认能运行后再做一次 commit。这样如果后续某次生成结果破坏功能可以快速回退到上一个稳定版本。配置建议外置到环境变量或配置文件不要写死在代码里。AI 生成的代码经常会把服务地址、Token、App ID 直接写在常量中。发布前必须整理出来改成根据环境读取。8.3 沉淀阶段把 Prompt 和排查经验写进项目文档Vibe coding 用得越多越会发现一些 prompt 模板非常有效。把这些模板整理到项目文档中能让团队里其他人也获得一致的效果。例如在 [项目名] 中新增功能时请遵循以下规则 - 使用 TypeScript禁止使用 any。 - 组件使用函数式写法。 - 状态更新必须不可变。 - 不新增依赖除非需要用户确认。 - 生成代码后请附带文件路径和验证步骤。这比每次重新描述一遍更高效也能减少 AI 的自由发挥。项目里的docs/ai-prompt-guide.md就是一个很好的位置。排查经验同样值得记录。哪些报错是依赖版本问题哪些是状态更新问题哪些是平台功能变化导致。把这些经验按“现象—原因—检查方式—解决方向”的格式写下来下次遇到同类问题可以直接对照不需要再把报错贴给 AI 反复试。Vibe coding 真正的价值是压缩了从想法到代码之间的距离让开发者把精力集中在需求判断、工程质量和技术成长上。快乐来源于快速看到成果安全来源于理解每一段代码。把它当成一个需要管理的工程流程来用而不是一个生成代码的黑盒你的开发体验会稳定得多。 Vibe Coding实战：从自然语言到可运行应用的完整链路
vibe coding 是这两年 AI 辅助编程里被反复提及的一种工作方式。它不是让开发者躺平而是把“怎么写代码”这个环节部分交给 AI把精力留给“做什么、怎么验证、怎么修”。实际体验过的人会明显感受到从只有一个想法到屏幕上出现可交互页面整个过程被压缩到几分钟。这种即时反馈就是 vibe coding 最让人上瘾的地方。不过vibe coding 的快乐背后也有代价。如果只是不断地把报错粘贴给 AI却不知道项目结构、依赖关系、数据流向很快会陷入“生成代码—报错—再生成—再报错”的循环。这篇文章围绕一次最小 Web 项目实践讲清楚 vibe coding 的完整链路工具选型、需求描述、代码生成、运行验证、问题排查也单独讨论鸿蒙开发中应用 vibe coding 时要注意的差异。文章里所有命令和代码都来自常见工程场景落地时请以你自己的项目版本为准。1. 先理解 Vibe Coding它不是替代开发者而是改变开发节奏1.1 从自然语言到可运行程序中间发生了什么Vibe coding 的核心流程并不复杂开发者用自然语言描述功能AI 编码工具生成代码开发者运行、查看、修正然后再把新的想法抛给 AI。这个过程和传统编码的核心区别在于开发者不再逐行敲击所有代码而是把大量样板代码、组件结构、接口拼接工作交给模型完成。以最简单的 Web 页面为例传统写法需要先建项目、配依赖、写组件、写样式再处理事件。vibe coding 流程里你只需要告诉 AI“创建一个 React 页面左侧是输入框和新增按钮右侧是待办列表点击删除按钮可以移除该项。”工具会直接生成对应的组件代码。这里发生了一次职责转移模型负责语法实现开发者负责判断这段代码是否真的满足需求。但要注意职责转移不等于责任转移。AI 生成的代码仍然需要人来确认。比如待办列表是否使用了不可变的 state 更新方式输入框是否受控删除操作是否影响了正确的数组项。这些判断能力恰恰是 vibe coding 能否顺畅进行的前提。1.2 为什么这个流程会让人感到“快乐”Vibe coding 的快乐首先来自反馈速度。过去写一个页面至少需要经历“项目初始化—代码编写—编译—调试—调整样式”几个较慢的阶段。现在 AI 可以在几十秒内生成一版可运行代码开发者能立刻看到页面长什么样、交互是否成立。这种“想法到产物”的短路径会显著减少开发过程中的疲惫感。其次它降低了从空白页面开始的压力。很多人都有过这种体验面对一个空文件不知道从哪里下笔。vibe coding 让“第一版代码”变得很容易获得。哪怕这版代码不完美也比空文件更容易讨论和修改。AI 生成的代码成了草图开发者要做的是在这个草图基础上继续打磨。还有一点容易被忽略vibe coding 能把人从重复的模板代码里解放出来。表格、表单、列表、增删改查这些功能在业务系统里大量出现结构相似但又不完全相同。让 AI 先生成基础版本再按业务差异微调比手动复制粘贴旧代码更清晰也不容易把无关逻辑带进来。1.3 快乐的前提是明确边界Vibe coding 也有完全不快乐的场景项目一上来就要求 AI 生成整个系统依赖全部交给 AI 猜接口文档不看类型不检查运行报错后也不读堆栈只是把错误信息原样粘贴回对话框。这样操作前几分钟很爽后面会越来越失控。所以这里要建立第一组边界适合用 vibe coding 的场景原型验证、学习示例、页面骨架、一次性脚本、接口联调时的 mock 数据。不适合上来就用的场景涉及权限、支付、数据迁移、高并发、复杂状态管理的核心模块。必须人工把关的环节依赖版本、安全校验、敏感信息、数据库结构、部署配置。记住这个边界后面的实践才不会被“生成速度快”带偏。2. 环境准备与工具选型不同目标对应不同的 Vibe Coding 组合2.1 本地 IDE 插件路线适合需要精细调试的项目最常见的 vibe coding 工具形态是 IDE 插件。Visual Studio Code 是生态最丰富的选择可以使用支持 AI 编码的插件例如 GitHub Copilot、通义灵码等。这些插件能根据注释、函数名和上下文补全代码也可以通过对话框直接生成整段代码。本地 IDE 路线的优点是代码留在本地方便调试、打断点、看 git diff也方便连接公司内部的依赖源和代码仓库。缺点是需要自己维护环境项目创建、依赖安装、编译报错都需要开发者有一定基础。一个常见的最小组合是Visual Studio Code Node.js 18 或更高版本 npm 或 pnpm 支持 AI 编码的 IDE 插件 Git首次使用插件时需要登录账号并确认插件能访问当前工作区文件。这里的权限不是越小越好而是要能读取项目上下文。如果插件看不到当前文件类型、依赖文件、目录结构生成结果就会很泛缺少针对性。2.2 云端 AI 编码平台路线以 Vercel AI 平台为例近两年出现了不少云端 AI 编码平台它们的共同特点是把“创建项目、生成代码、预览页面、部署上线”放进同一个浏览器界面。以 Vercel AI 平台的 vibe coding 入口为例整体使用方式通常包含这几步进入平台并登录账号选择创建新的 AI 应用项目。在输入框中用自然语言描述想要的应用类型和功能。平台生成项目代码并给出一个可预览的页面地址。继续在对话中补充需求让平台修改页面结构、交互和样式。确认效果后把项目部署到托管环境或导出代码到本地仓库。不同平台的按钮名称会变化入口也可能调整但核心逻辑是一致的自然语言驱动生成可视化预览反馈对话式迭代。这类平台适合快速验证产品想法、做演示原型、不想过早接触环境配置的开发者。云端路线的短板是黑盒较多。很多平台会在生成代码里内置示例数据这些数据在你部署后仍然存在。正式上线前需要把页面里的 mock 数据替换成真实接口并把环境变量、权限配置、域名等信息重新核对一遍。平台更新很快具体菜单以官方文档为准。2.3 鸿蒙开发场景不要把 Web 经验直接照搬鸿蒙开发里的 vibe coding 是一个正在被讨论的方向。HarmonyOS 应用使用 ArkTS 开发UI 层基于 ArkUI 声明式语法工程结构、权限配置、签名机制和 Web 项目完全不同。直接在浏览器里生成的 JavaScript 代码无法运行在鸿蒙工程里。推荐的做法是使用 DevEco Studio 开发并在支持 AI 编码的插件或内置能力辅助下工作。你可以让 AI 生成一段 ArkUI 页面代码但必须在 prompt 里明确说明“使用 ArkTS使用 ArkUI 组件面向 HarmonyOS 应用”。即使这样生成结果仍然可能与当前 SDK 版本不一致需要对照官方 API 检查。这里的核心建议是先准备一个空的鸿蒙工程让 AI 基于这个工程结构补充页面而不是从零让 AI 生成整个鸿蒙项目。工程配置、签名、权限这些内容AI 不可能完全替你判断正确。场景推荐工具组合主要优势主要风险Web 原型快速验证云端 AI 编码平台上手快、可预览、可部署示例数据残留、代码不透明正式 Web 项目开发IDE AI 插件可控、可调试、可审查需要环境基础鸿蒙应用开发DevEco Studio AI 插件贴合官方工程能真机调试AI 对 ArkTS 和 API 版本理解不稳定学习编程本地 IDE AI 插件能读代码、能打断点容易只看结果不看实现3. 最小实践用自然语言生成一个 React 待办事项页面3.1 先用一句话把需求和验收标准写清楚很多 vibe coding 翻车不是 AI 能力不够而是需求描述太模糊。比如只说“写一个待办事项应用”AI 可能生成一个带后端、数据库、用户登录的全栈项目或者生成一个简单到只有静态列表的页面。为了避免这一点第一步应该把范围限定清楚。一个可用的 prompt 可以这样写请在这个项目里实现一个待办事项组件技术栈是 Vite React TypeScript。 功能要求 1. 顶部有一个输入框和一个“新增”按钮。 2. 输入内容后点击“新增”把内容添加到待办列表。 3. 每一项待办左侧是复选框点击后可以切换完成状态完成项文字加删除线。 4. 每一项右侧有一个“删除”按钮点击后移除该项。 5. 数据先保存在 useState 中不接后端。 6. 不引入 UI 组件库样式使用简单 CSS 即可。 请给出完整的组件代码并说明如何接入 App.tsx。这段描述包含了技术栈、功能列表、数据存储方式、样式约束和交付形式。 AI 生成时会有明确依据后续检查也有验收标准没有输入框不行点击新增不更新列表不行删除按钮不生效不行。3.2 让 AI 生成项目骨架在本地 IDE 里可以先手动创建一个 Vite 项目骨架再让 AI 在项目内补充代码。原因是项目创建命令相对固定由 AI 生成反而可能引入额外文件。npm create vitelatest todo-app -- --template react-ts cd todo-app npm install项目创建完成后把上面的 prompt 粘贴给 AI 插件。AI 生成代码后通常会在当前文件或者新文件中返回结果。你需要检查它是否修改了src/App.tsx是否生成了新的组件文件是否添加了样式文件。一个典型的生成结果可能包含这些文件src/ App.tsx App.css components/ TodoInput.tsx TodoList.tsx TodoItem.tsx如果 AI 只输出了一段代码而没有说明文件位置你可以继续追问“这段代码应该放在哪个文件里请给出完整的目录结构。”不要自己猜文件名避免文件路径和导入语句对不上。3.3 在云端平台用同样的思路完成生成与部署在 Vercel AI 这类云端平台里操作路径会稍微不同。你不需要先在本地创建项目而是直接打开平台的新建项目页面在对话框里输入同样的需求描述。平台生成第一版之后先看预览页面的基础效果输入框是否显示。点击新增后列表是否增加。复选框是否能切换状态。删除按钮是否生效。这些是功能验收不是 UI 审美验收。先确认交互逻辑成立再通过新的 prompt 调整样式。例如可以说“把输入框和按钮放在一行列表项之间增加分割线完成项的字体颜色改为灰色。” 云端平台会基于之前的代码继续修改。确认没有明显问题后再点击部署。部署完成后记得在线上地址重新跑一遍功能。本地预览正常不代表线上正常线上可能出现接口跨域、静态资源路径、环境变量未配置等问题。3.4 运行与验证功能、交互、异常分支在本地运行项目npm run devVite 默认会启动一个本地开发服务器终端会输出访问地址通常是http://localhost:5173。打开页面后按下面的表格逐项验证验证项操作预期结果初始页面刷新页面输入框为空列表为空或显示占位文案新增功能输入“写代码”并点击新增列表出现“写代码”输入框被清空空值处理输入框为空时点击新增不添加空项或给出提示完成状态点击复选框文字出现删除线复选框被选中删除功能点击删除按钮对应项从列表消失计数统计如果生成了剩余数量完成状态切换后数字变化测试时不要只测正常路径。空输入、重复内容、快速连续点击新增这些情况最能暴露状态管理和事件处理的问题。如果 AI 生成的代码里没有空值判断后续需要补上。4. Prompt 设计把需求描述清楚AI 才能少跑偏4.1 一段高质量需求描述包含的七个要素Vibe coding 的输出质量很大程度上由输入决定。同一个功能描述方式不同生成结果差异会非常大。一个高质量 prompt 通常包含七类信息要素说明示例技术栈使用什么语言、框架、构建工具React TypeScript Vite功能范围完成哪些功能不包含哪些功能只做前端展示不做登录交互细节用户操作后页面如何变化点击新增后清空输入框数据来源数据来自接口、状态、文件还是数据库先用 useState 存本地数据样式约束是否使用组件库风格偏好不使用 UI 组件库样式简洁边界条件空值、超长文本、重复提交如何处理输入为空时不允许新增交付形式返回完整组件、修改某段代码还是补充说明给出完整 TodoItem 组件把这些信息写全AI 不需要做太多假设生成结果就更可控。反之如果只写“帮我写个登录页面”AI 就会自己决定要不要验证码、要不要记住密码、要不要调接口。这些假设很可能不符合你的需求。4.2 小步生成而不是一次生成整个系统一次生成一个完整系统很诱人但风险极大。文件一多AI 内部的上下文可能前后不一致。比如一个文件里定义了TodoItem组件另一个文件却导入成TodoCard这类命名不一致在生成时刻很难发现。推荐的做法是从小到大分步生成先让 AI 生成页面静态布局。再补充状态管理和交互逻辑。然后处理边界条件和样式优化。最后接入接口或持久化。每一步都能运行、能观察、能确认。如果某一步出问题可以直接回退到上一个稳定版本而不是在一大堆新文件里找 bug。这也是 vibe coding 和传统编码最相通的地方小步提交持续集成比一次提交千行代码安全得多。4.3 生成结果不对时如何补充描述AI 生成结果不符合预期时不要急着说“不对重新写”。更好的方式是指出具体问题并说明期望行为。错误的命令示例还是不行重新生成。这种 prompt 没有提供任何有效信息AI 只能重新猜测。正确的补充描述应该包含位置、现象和期望点击“新增”按钮后列表没有变化。我已经在输入框里输入了内容。请检查 addTodo 函数是否使用了 setTodos 更新状态而不是直接修改 todos 数组。要求点击新增后新项出现在列表末尾并且输入框清空。这样的 prompt 明确告诉 AI问题在新增逻辑期望行为是更新状态并清空输入框。AI 能直接定位修复效率会高很多。5. 代码审查与调试Vibe Coding 的下半场才是关键5.1 AI 生成代码最常见的四类问题AI 生成的代码看起来完整但真正运行时会暴露不少问题。按出现频率排序通常有四类第一类是类型问题。TypeScript 项目里AI 可能跳过接口定义直接使用any或者把可选属性当作必填属性使用。这类问题在编译阶段就会报错相对容易发现。第二类是状态更新问题。React 项目里AI 可能写出直接修改 state 的代码比如使用todos.push()而不是创建新数组。这会破坏不可变性导致页面有时候更新有时候不更新。第三类是依赖版本问题。AI 会按照训练数据里的常见版本生成代码但你本地安装的依赖版本可能不同。比如生成代码使用了较新的 API本地却是旧版本或者使用了旧 API本地已经升级。第四类是样式和布局问题。AI 生成的 CSS 类名可能与 HTML 结构不匹配或者在同一个页面里混用了不同单位的尺寸。这类问题不报错但页面表现会异常需要肉眼观察。5.2 用最小复现路径定位运行时错误遇到问题后先用一个最小操作路径复现而不是在多个功能之间来回切换。比如待办事项页面点击新增后列表没有变化可以只执行这一个操作然后打开浏览器开发者工具在 Console 里看是否有报错在 Sources 里打断点在 React DevTools 里检查todos状态的值。以 React 状态更新为例AI 常见错误写法是const addTodo () { todos.push({ id: Date.now(), text: input, done: false }); setTodos(todos); };这段代码的问题在于直接修改了原来的todos数组。React 比较状态引用时可能认为状态没有变化所以页面不更新。推荐写法是创建一个新数组const addTodo () { const next [...todos, { id: Date.now(), text: input, done: false }]; setTodos(next); setInput(); };看到这类代码差异时不需要解释给 AI直接向 AI 指出“当前 addTodo 直接修改了 todos 数组请改成不可变更新方式并在新增后清空输入框。” AI 能理解这一类描述。5.3 不要让 AI 连续修复同一个 bug 超过两轮如果同一个 bug 让 AI 修了两轮还没有解决继续让 AI 猜下去不是好选择。这时应该停止对话手动打开报错相关的文件和日志自己看一遍关键逻辑。原因很简单AI 连续修复失败说明它可能没有理解当前代码的完整上下文或者在反复使用同一套错误假设。这时你再输入“还是不行再修”大概率只会得到类似的错误结果。正确做法是把相关文件完整读一遍。找到状态更新、数据传递、事件绑定这些核心点。用console.log输出关键变量确认数据到了哪一步。在报错信息里找到文件路径和行列号定位具体代码。把定位结果和你的分析一起提供给 AI让它基于新的线索修复。记住AI 是辅助不是背锅方。它生成代码你负责理解和掌控。只有当你自己也能读懂代码时vibe coding 才不会变成“盲人摸象”。6. 常见问题排查从报错信息反推修复路径6.1 依赖缺失或版本不匹配现象项目启动时报Module not found或者某段代码使用了不存在的方法。可能原因AI 生成代码时假设了某个依赖已经安装或者假设了某个 API 在当前依赖版本中存在。检查方式# 查看当前项目安装了哪些依赖及版本 npm list react # 查看某个包是否在依赖树中 npm ls vite # 查看 package.json 中的声明 cat package.json处理建议如果缺失依赖安装指定版本如果版本过高或过低先查看官方文档确认 API 兼容性。不要让 AI 直接改package.json里的版本号除非你确认新版本不会影响其他依赖。6.2 页面能打开但数据不更新现象点击新增、删除、切换按钮后页面没有响应或者刷新后才生效。可能原因直接修改了 state 对象事件没有绑定到正确组件组件没有重新渲染。排查顺序在事件处理函数里加console.log确认点击事件是否触发。打印修改前的数据确认数据内容是否符合预期。在 render 返回处打印数据确认组件是否重新执行。检查是否使用setState更新状态而不是直接赋值。如果确认事件触发了、数据也变了、但页面没更新优先检查状态更新方式是否不可变。这是 React 项目里最容易被 AI 忽略的问题。6.3 AI 幻觉 API 或过时语法现象AI 生成了一个看起来很合理的 API 调用但运行时报is not a function或undefined。可能原因模型基于训练数据生成了不存在的 API或者使用了已经被框架废除的写法。处理建议先把报错信息里的方法名复制到搜索引擎或官方文档里确认。不要直接要求 AI 换一个方法因为它可能又生成另一个不存在的 API。正确做法是在 prompt 中限定版本和来源请使用当前项目安装的 React 18 版本语法。不要使用 ReactDOM.render改用 createRoot。API 以官方文档为准。这类约束比泛泛的“保证代码正确”有效得多。报错现象常见原因检查方式处理方向Module not found依赖未安装或路径写错查看 import 路径检查 npm ls安装依赖或修正导入路径setState 后页面不更新直接修改了原数组或对象在函数中打印数据引用改为不可变更新方式API is not a function版本不匹配或 API 不存在搜索官方文档替换为当前版本正确的 API样式不生效类名或文件引用错误检查 CSS 文件和类名修正类名或调整引入方式组件导出报错默认导出和命名导出混用查看 export 语句统一导出方式7. 当 Vibe Coding 遇到鸿蒙开发ArkTS、权限与签名是关键差异7.1 先约束语言和 UI 框架别让 AI 自由发挥鸿蒙应用开发使用 ArkTS它基于 TypeScript但增加了更严格的规定例如不支持某些动态类型特性UI 层使用 ArkUI 的声明式写法。直接把 Web 项目的 React 组件生成逻辑带到鸿蒙工程里几乎必然报错。如果你要在鸿蒙项目里使用 vibe codingprompt 里必须写清楚请使用 ArkTS 语言基于 ArkUI 声明式语法开发 HarmonyOS 应用页面。不要使用 JavaScript 的 Web DOM API。组件需要符合 Stage 模型下的页面结构。即使如此AI 仍可能生成过时的 API。鸿蒙 SDK 版本迭代较快有些组件和装饰器在不同版本里有差异。遇到编译报错时优先查看当前 SDK 对应的官方文档不要盲目修改 API 名称。7.2 权限声明、签名和真机调试不能依赖 AI 自动完成Web 项目部署到服务器后浏览器会处理大部分安全边界。鸿蒙应用不同涉及权限声明、签名、真机调试等环节。AI 可以帮你生成申请权限的代码但不能替你的应用判断是否需要某个权限。例如需要访问网络时需要在module.json5中配置权限。这个配置是否正确取决于应用的实际业务场景。AI 生成的配置只能作为起点不能成为依据。发布前需要逐项检查权限列表移除不必要的权限。真机调试也一样。AI 无法知道你本机的签名证书、调试设备、应用包名。完整的鸿蒙 vibe coding 流程应该是在 DevEco Studio 中手动创建一个空工程。确认工程能编译、能安装到模拟器。再让 AI 基于这个工程补充页面和业务代码。每次编译通过后再继续下一个功能。7.3 鸿蒙场景下的推荐实践鸿蒙开发者使用 vibe coding 时不要追求“一句话生成整个应用”而应该追求“在一个能运行的工程里让 AI 帮我写具体页面”。这样既能享受 AI 生成代码的速度又能避免工程结构失去控制。推荐的实践方式是把 ArkUI 常用组件的写法整理成项目内文档例如Row、Column、Button、TextInput的简单示例。在 prompt 中引用这些文档要求 AI 遵循。每次生成新页面后在模拟器里运行验证。权限、签名、包名相关配置固定在一个说明文件里不让 AI 随便修改。这类做法本质上是给 AI 提供“项目内约束”比每次重新描述一遍要可靠得多。8. 把 Vibe Coding 变成可持续开发方式的最佳实践清单8.1 学习阶段小项目、小步快跑、多读生成代码如果你刚开始接触 vibe coding不要一上来就做完整业务系统。先选一个小功能比如一个计算器、一个待办列表、一个 Markdown 预览页完整走一遍“描述—生成—运行—修改—部署”的流程。学习阶段最重要的不是让 AI 生成更多代码而是读懂 AI 生成的代码。每拿到一段代码至少问自己三件事这段代码的数据流向是什么为什么这里用这个 API 而不是另一个如果需求变化我应该改哪里当你发现能回答这些问题时vibe coding 就不会让技术能力退化反而会成为理解框架的新入口。8.2 工程阶段代码审查、版本控制、配置外置进入正式项目后AI 生成的代码必须经过和人工写代码一样的审查流程。不要因为代码来自 AI就跳过 review。审查时重点关注是否存在硬编码的密钥、密码、地址。是否有不必要的类型断言或any。错误处理是否吞掉了异常。敏感操作是否有权限判断。是否有重复造轮子项目里已经有现成工具函数。版本控制上保持小粒度提交。AI 每完成一个清晰的改动确认能运行后再做一次 commit。这样如果后续某次生成结果破坏功能可以快速回退到上一个稳定版本。配置建议外置到环境变量或配置文件不要写死在代码里。AI 生成的代码经常会把服务地址、Token、App ID 直接写在常量中。发布前必须整理出来改成根据环境读取。8.3 沉淀阶段把 Prompt 和排查经验写进项目文档Vibe coding 用得越多越会发现一些 prompt 模板非常有效。把这些模板整理到项目文档中能让团队里其他人也获得一致的效果。例如在 [项目名] 中新增功能时请遵循以下规则 - 使用 TypeScript禁止使用 any。 - 组件使用函数式写法。 - 状态更新必须不可变。 - 不新增依赖除非需要用户确认。 - 生成代码后请附带文件路径和验证步骤。这比每次重新描述一遍更高效也能减少 AI 的自由发挥。项目里的docs/ai-prompt-guide.md就是一个很好的位置。排查经验同样值得记录。哪些报错是依赖版本问题哪些是状态更新问题哪些是平台功能变化导致。把这些经验按“现象—原因—检查方式—解决方向”的格式写下来下次遇到同类问题可以直接对照不需要再把报错贴给 AI 反复试。Vibe coding 真正的价值是压缩了从想法到代码之间的距离让开发者把精力集中在需求判断、工程质量和技术成长上。快乐来源于快速看到成果安全来源于理解每一段代码。把它当成一个需要管理的工程流程来用而不是一个生成代码的黑盒你的开发体验会稳定得多。