1. 项目缘起一个普通前端的“半年之痒”与自救去年下半年我经历了一段非常典型的前端“倦怠期”。每天的工作就是对着产品经理给的UI稿在React组件里写写业务逻辑调调CSS跟后端联调一下接口。技术栈几年没变项目也进入了维护期感觉自己就像一颗螺丝钉重复着拧紧、松开的动作。那段时间网上铺天盖地都是AI编程、Copilot、vibe coding的讨论看着别人用自然语言描述需求就能生成代码心里既焦虑又好奇。焦虑的是自己这点“手搓代码”的技能是不是快被淘汰了好奇的是这东西到底有没有用是不是真的能提升效率还是只是个噱头。于是我给自己定了个目标用半年时间以一个“普通前端”的视角实实在在地去尝试和验证vibe coding。我不想去研究那些高深的论文或者底层原理我就想弄明白一个像我这样主要技术栈是React/Next.js TypeScript会点Node.js但不算精通的开发者能不能用vibe coding做出点有意思、有价值的东西来。这半年里我断断续续做了四个小项目它们都不大但覆盖了不同的场景有纯前端的工具有需要前后端交互的应用也有尝试新框架的探索。今天这篇文章就是想把这半年的实践、踩过的坑、以及最真实的感受毫无保留地分享出来。如果你也对vibe coding感兴趣但又不知道从何下手或者担心它华而不实那我的这段经历或许能给你一些参考。2. 项目一Next.js TypeScript 组件库文档站生成器第一个项目我想解决一个实际工作中经常遇到的痛点组件库的文档维护。我们团队内部有一个小的UI组件库文档一直是用Markdown手写的每次组件更新文档同步就是个麻烦事而且展示效果也比较简陋。我的想法是能不能用vibe coding辅助快速搭建一个基于Next.js的、能自动从组件代码和注释中提取信息并生成美观文档的站点。2.1 技术选型与核心思路我选择Next.js 14App Router和TypeScript作为基础因为这是我们团队的主流技术栈我对它也最熟悉。文档生成的核心在于“解析代码”和“渲染页面”。对于解析我最初想完全依赖vibe coding去写一个复杂的AST抽象语法树解析器但很快发现这超出了当前AI辅助编程的能力边界它生成的解析代码漏洞百出。于是我调整了思路用成熟的工具做专业的事用vibe coding做粘合剂和界面开发。我选用了react-docgen-typescript来解析TSX组件文件提取props、注释等信息。这是一个非常成熟的社区工具可靠性高。而vibe coding的任务则是帮我快速搭建Next.js的项目骨架、编写页面组件、设计数据流以及处理那些繁琐但模式固定的配置代码。实操心得一明确vibe coding的边界在项目启动时最重要的一步是分清哪些任务适合交给AI哪些必须自己把控或使用专业工具。像代码解析、复杂算法、核心业务逻辑目前让AI从头生成风险很高。但像搭建项目结构、编写重复的UI组件、编写简单的工具函数、撰写基础的配置文件和文档这些是vibe coding的强项能极大提升效率。我的经验是将项目拆解成“确定性任务”和“创造性/复杂性任务”前者大胆交给AI后者亲自操刀或寻找成熟轮子。2.2 实操过程与vibe coding的助力我打开了VS Code并确保安装了GitHub Copilot或类似的AI编码助手插件。我的启动提示词prompt没有很复杂就是描述我想要什么“创建一个Next.js 14 (App Router)项目使用TypeScript和Tailwind CSS。项目目标是构建一个组件文档站。请生成初始的package.json、next.config.js、tailwind.config.js以及必要的目录结构如app/,components/,lib/。”AI几乎瞬间就给出了正确的文件和配置甚至包括了tsconfig.json的合理配置。这为我节省了至少15分钟的初始化时间。接下来是核心功能。我给了它更具体的指令“在lib/目录下创建一个generate-docs.ts文件。这个文件需要1. 使用react-docgen-typescript扫描components/ui目录下的所有.tsx文件。2. 解析每个组件的props类型和注释。3. 将结果输出为一个JSON文件到app/api/docs/data.json。”AI生成的代码骨架非常棒导入了正确的包给出了大致的函数框架。但它对react-docgen-typescript的具体API用法不熟生成的解析代码有错误。这时我没有让它继续“猜”而是自己查阅了该库的官方文档修正了参数和调用方式。修正的过程也是我学习这个工具的过程。然后我转向UI部分“在app/docs/[[...slug]]/page.tsx中创建一个动态路由页面。它需要1. 读取上面生成的data.json。2. 根据URL中的slug参数展示对应组件的文档。3. 文档页面左侧是组件列表导航右侧主区域展示组件名称、描述、一个实时预览的示例渲染该组件、以及一个格式良好的Props API表格。”对于这种有明确模式的UI构建vibe coding的表现堪称惊艳。它快速生成了基于headlessui/react的导航栏结构、用marked库渲染描述中的Markdown、以及一个用/components/ui自身组件渲染的预览区域。最让我满意的是Props表格AI根据JSON数据结构生成了一个清晰的、带类型标识和默认值的table样式通过Tailwind CSS也处理得很美观。2.3 遇到的坑与解决方案坑1类型地狱与循环依赖。在编写预览组件时AI生成的代码试图在文档站点内直接import { Button } from /components/ui/Button来渲染示例。但这导致了循环依赖文档生成器解析组件文档页面又导入组件。解决方案是采用“隔离渲染”策略我让AI编写了一个简单的、在运行时通过React.createElement动态创建组件实例的工具函数避免编译时导入。坑2热更新与数据同步。开发时我修改了组件代码希望文档能实时更新。AI最初建议我监听文件变化这很复杂。我换了个思路写了一个简单的Next.js API路由 (app/api/docs/regenerate/route.ts)手动触发重新生成文档。并在next.config.js中配置了忽略对data.json的监视避免开发服务器无限重启。这个方案简单有效。坑3AI的“想当然”。AI在生成Props表格时默认把所有props都当作必填required。但实际上TypeScript的可选属性?和默认值defaultProps或解构默认值才决定是否必填。我不得不手动教它需要检查prop.type里是否包含undefined以及是否有defaultValue属性。这个过程让我意识到对于业务规则的精确性人的判断不可或缺。完成这个项目后我不仅得到了一个可用的内部工具更重要的是建立了一套使用vibe coding的工作流由我定义架构和核心逻辑将实现细节和样板代码委托给AI并在关键节点进行代码审查和修正。整个项目耗时约3个周末其中用vibe coding生成的代码量约占60%但真正体现项目价值的核心设计数据流、架构决策100%来自我自己。3. 项目二基于Supabase的全栈小应用——灵感速记板第二个项目我想挑战一下“全栈”。作为一个前端我对后端和数据库一直有敬畏之心。Supabase的出现以其“开源Firebase”的定位和出色的PostgreSQL集成大大降低了全栈开发的门槛。这个项目我想做一个极简的“灵感速记板”用户可以快速创建、编辑、删除和标记笔记并且数据实时同步。3.1 为什么选择Supabase在技术选型上我对比了传统的自建后端Node.js Express Prisma PostgreSQL、Serverless如Vercel Edge Functions PlanetScale以及BaaS如Supabase、Firebase。对于我这个个人小项目来说自建后端成本太高需要管理服务器、数据库、API学习曲线也陡峭。Serverless架构很酷但数据库连接、实时订阅等功能需要额外集成。而Supabase提供了一个“全家桶”托管PostgreSQL数据库无需自己搭建自带管理界面。自动生成的RESTful API基于数据库表结构秒生成前端直接调用。实时订阅通过WebSocket轻松实现数据实时更新这正是“速记板”需要的。身份验证内置了用户注册登录功能。本地开发友好提供了Docker镜像可以完全在本地运行断网也不怕。最关键的是它的前端SDKsupabase/supabase-js对React/Next.js支持极好。这一切让我可以几乎完全聚焦在前端逻辑和用户体验上后端复杂性被极大抽象。这正是vibe coding发挥作用的理想场景我不需要深入理解后端细节只需要告诉AI“我要用Supabase实现用户登录和增删改查”它就能生成正确的客户端代码。3.2 从零到一的vibe coding全栈体验我在Supabase官网创建了一个项目并在本地通过Docker启动了Supabase。第一步是设计数据库表。我直接在Supabase的在线SQL编辑器中用自然语言描述给AI“请为‘灵感笔记’应用生成SQL建表语句。需要一张notes表包含字段id(uuid, 主键)created_at(时间戳)user_id(uuid, 关联auth.users)title(文本)content(文本)tags(文本数组)is_pinned(布尔值)。并设置行级安全策略RLS确保用户只能操作自己的笔记。”AI生成的SQL语句基本正确只是在RLS策略的细节上需要我根据Supabase的文档稍作调整。这比我手写SQL快多了尤其是RLS这种不常用的语法。接下来是前端部分。我创建了一个新的Next.js项目并安装了Supabase客户端库。然后我开始用vibe coding构建核心页面。“创建一个Next.js页面app/dashboard/page.tsx。这个页面需要1. 使用supabase/ssr进行服务器端会话检查未登录用户重定向到登录页。2. 使用Supabase客户端从notes表获取当前用户的所有笔记按is_pinned和created_at排序。3. 以卡片网格形式展示笔记每个卡片显示标题、部分内容、标签和操作按钮编辑、删除、置顶。4. 实现笔记的实时订阅当其他标签页或客户端修改了笔记当前页面能自动更新列表。”这个提示词包含了业务逻辑、数据获取、UI和高级功能实时性。AI生成的代码框架非常完整它正确地使用了createServerComponentClient进行服务端验证用useEffect和supabase.channel()建立了实时订阅并给出了一个基本的网格UI。但它犯了一个关键错误在React Server Component中错误地使用了客户端钩子。它把useState,useEffect和数据获取逻辑都写在了page.tsx里而这在App Router中默认是Server Component。实操心得二框架特定约定的“教学”Next.js App Router的Server/Client Component规则是特定的框架知识。vibe coding虽然“知道”这些概念但在复杂提示下容易混淆。我的做法是进行“分层提示”先让AI生成app/dashboard/notes-list.tsx文件并明确指示“这是一个React Client Component使用‘use client’指令。它接收initialNotes作为prop内部使用state管理笔记列表并实现Supabase实时订阅来更新这个state。”再让AI生成app/dashboard/page.tsx文件“这是一个React Server Component。它从Supabase服务端获取当前用户的initialNotes然后将initialNotes作为prop传递给NotesList /客户端组件。” 通过将任务拆解并明确框架约束AI生成的代码准确率大幅提高。这让我明白使用vibe coding时你自身的框架理解深度决定了你能高效利用它的上限。3.3 身份验证与部署的细节处理用户登录注册页我直接使用了Supabase官方提供的Auth UI组件 (supabase/auth-ui-react)这让开发变得极其简单。vibe coding帮我快速集成了这个组件并处理了回调路由。部署到Vercel时遇到了环境变量问题。AI提示我需要设置NEXT_PUBLIC_SUPABASE_URL和NEXT_PUBLIC_SUPABASE_ANON_KEY但它没有告诉我Supabase的anon key在本地和线上可能是不同的。我不得不在Supabase项目设置中为生产环境单独配置了重定向URL并生成了新的anon key。这个过程让我意识到vibe coding能生成代码但关于服务配置、环境隔离等运维知识仍然需要开发者自己掌握。最终这个“灵感速记板”成功上线。它虽然功能简单但让我一个前端在几乎没有写一行后端API代码的情况下完成了一个具备完整用户系统、实时数据同步的全栈应用。Supabase解决了基础设施问题而vibe coding则加速了我与这套基础设施交互的前端代码编写过程。4. 项目三探索“前端AI技能”——智能面试题生成与解析工具第三个项目我想主动接触一下“AI技能”这个前端领域的新热点。与其焦虑不如亲手试试看前端如何与AI API结合。我看到很多朋友在准备前端面试于是想做一个工具它能根据用户输入的技术关键词如“React Hooks”、“CSS BFC”调用大语言模型API生成模拟面试题和参考答案并且能对用户自己写的答案进行简要评估。4.1 架构设计在边缘运行AI函数为了避免后端服务器的复杂性我决定采用Vercel的AI SDK和Edge Functions。这个组合允许我在Vercel的全球边缘网络上运行无服务器函数直接调用OpenAI或其他兼容的API速度很快并且与Next.js无缝集成。我的应用流程设计如下前端界面一个简单的表单输入技术栈和难度点击生成。Edge Function (生成问题)表单提交后调用一个部署在Vercel Edge的Serverless Function。这个函数使用Vercel AI SDK向OpenAI的Chat Completions API发送一个精心设计的提示词Prompt请求生成面试题。前端界面展示将返回的面试题展示出来并提供一个文本框让用户输入自己的答案。Edge Function (评估答案)用户提交答案后调用另一个Edge Function将问题和用户答案一并传给AI请求进行对比评估并给出要点反馈。前端展示反馈将AI的评估反馈展示给用户。这个架构的核心优势是“轻量”和“快速”。整个后端逻辑就是两个无状态函数部署管理极其简单。4.2 提示词工程从“垃圾输入”到“优质输出”这个项目的成败几乎完全系于“提示词”Prompt的质量。我的第一次尝试非常粗糙“请生成一道关于React的前端面试题。”结果AI返回的问题要么太泛“请谈谈你对React的理解”要么太偏。我意识到必须给AI更明确的约束和上下文。经过多次迭代我总结出了一套有效的提示词结构并让vibe coding帮我将其模块化成函数对于生成问题你是一个资深前端技术面试官请生成一道高质量的面试题。 要求 1. 技术范围{用户输入的技术关键词如“React useEffect”} 2. 难度级别{用户选择的难度如“中级”} 3. 问题类型{选择题 / 简答题 / 编程题 / 场景题} 4. 输出格式请严格按照以下JSON格式输出不要有任何额外解释 { question: 问题正文, questionType: 类型, hint: 可选的解题提示, referenceAnswer: 详细的参考答案包含关键知识点和代码示例如果适用 } 请确保问题考察的是对核心概念的理解和实际应用能力而非死记硬背。对于评估答案你是一个前端面试官正在评估候选人的回答。 以下是原始面试题{question} 以下是候选人的回答{userAnswer} 以下是参考答案{referenceAnswer} 请对候选人的回答进行简要评估聚焦于 1. **准确性**核心概念描述是否准确 2. **完整性**是否覆盖了问题的主要要点 3. **深度**是否有自己的理解或延伸 4. **表达**是否清晰有条理 请以友好、建设性的口吻用不超过3个要点的形式给出反馈。直接输出反馈文本不要以“评估”开头。我让vibe coding帮我编写了一个lib/prompts.ts文件将这些模板字符串化并插入变量。同时也编写了调用Vercel AI SDKstreamText函数的Edge Function代码。在编写这部分时AI对Vercel AI SDK的API非常熟悉生成的代码几乎无需修改。4.3 成本控制与用户体验优化使用OpenAI API是会产生费用的。为了避免意外消耗我做了两件事设置使用上限在Vercel环境变量中设置了较低的每月额度并在代码中对单次请求的maxTokens做了严格限制防止生成过于冗长的内容。前端添加加载状态和流式输出为了提升用户体验我利用AI SDK的流式响应能力让问题可以一个字一个字地“打”出来而不是长时间等待后突然显示全文。vibe coding在实现这个功能时帮了大忙它生成了处理流式数据的React组件代码包括缓冲区和渲染逻辑。这个项目让我深刻体会到前端工程师的“AI技能”现阶段更多体现在“提示词工程”和“AI能力与前端体验的结合”上。我们不需要去训练模型但需要懂得如何与模型高效对话并将模型的输出流畅地整合到用户界面中管理好状态、加载、错误和成本。vibe coding在这个过程中充当了一个优秀的“实现助手”把我对交互和架构的想法快速转化为代码。5. 项目四直面“前端性能优化”——大型PDF渲染器最后一个项目我想挑战一个更具体、更棘手的现实问题前端渲染大型PDF文件速度慢、卡顿。这是我在工作中真实遇到的难题。我打算用vibe coding辅助研究并实现一个性能更好的PDF预览方案。5.1 问题分析与方案调研传统的方案是使用embed标签或iframe或者使用pdf.js这个Mozilla开源的库。embed方案简单但可控性差且超大PDF会阻塞页面。pdf.js功能强大但全量渲染一个几百页的PDF内存和CPU压力依然巨大。我的优化思路是“按需渲染”或“分片渲染”只渲染用户当前视口及附近几页的内容。这需要深入使用pdf.js的API。我首先让vibe coding帮我快速搭建一个基础的研究环境“创建一个React组件使用pdfjs-dist库和react-pdf组件库实现一个基础的PDF查看器能加载并显示本地或远程的PDF文件。”AI很快生成了代码引入了必要的依赖并配置了pdfjs-dist的worker路径。这让我在几分钟内就有了一个可用的实验台。5.2 实现虚拟化列表渲染PDF页面核心性能优化在于实现一个虚拟滚动的容器。我决定采用一个成熟的虚拟滚动库react-virtualized或tanstack/react-virtual后者更新、更轻量。我告诉AI我的需求“请改造上面的PDF查看器。使用tanstack/react-virtual创建一个虚拟滚动容器。容器高度为800px每页PDF的高度假设为1123pxA4比例。计算并只渲染可视区域内的PDF页面。为每个页面创建一个Document和Page组件但传入pageNumber参数。”这里遇到了一个关键挑战pdf.js的getDocument和getPage是异步操作且页面渲染本身耗时。如果用户在快速滚动会触发大量不必要的页面加载和卸载导致性能更差甚至崩溃。AI最初的实现是简单的在虚拟列表的renderRow函数中直接调用pdfDocument.getPage(pageNumber)。这显然不行。我需要自己设计一个缓存层和加载优先级控制。实操心得三当AI无法理解复杂状态流时对于这种涉及异步资源管理、缓存、优先级调度的复杂交互逻辑vibe coding生成的代码往往流于表面缺乏健壮性。这时我必须亲自设计核心算法页面缓存使用一个Ref或Context存储已加载的页面对象PDFPageProxy避免重复加载。加载队列与取消为每个页面请求设置一个AbortController。当某个页面滚出可视区域时如果还未加载完成则取消请求。优先级加载优先加载当前视口中心的页面然后加载上下相邻的页面预加载。 我向AI描述了这个设计并让它帮我实现具体的缓存Hook和加载管理器函数。它很好地完成了这些“零件”的编码比如一个使用Map的缓存Hook一个封装了AbortController的请求函数。然后我再将这些零件组装到虚拟滚动组件中。这个过程就像是我担任架构师和产品经理AI担任高级工程师我负责设计系统和验收代码它负责实现模块。5.3 效果对比与进一步优化实现基础虚拟化后性能已有巨大提升。一个100页的PDF从之前卡顿十几秒才能操作到现在滚动如丝般顺滑。但我还想更进一步Canvas渲染替代SVGreact-pdf默认可能用SVG渲染对于复杂页面Canvas性能更好。我让AI查找文档并修改配置切换到Canvas渲染器。缩略图导航生成所有页面的低分辨率缩略图也是一个性能瓶颈。我让AI实现了一个“懒生成”的缩略图列表只有用户打开侧边栏导航时才生成并且同样应用虚拟滚动。Web Worker将pdf.js的解析工作完全丢给Web Worker防止阻塞主线程。AI帮我编写了worker的脚本文件 (pdf.worker.js的加载逻辑) 和与主线程通信的代码。这个项目让我对vibe coding在复杂问题解决中的角色有了最终定位它是一个强大的“加速器”和“实现者”但不是“决策者”和“架构师”。它帮我快速尝试了各种方案虚拟滚动库选型、Canvas配置实现了许多样板代码和工具函数甚至帮我查阅了某些库的特定API用法。但最核心的性能问题分析、架构设计、状态管理策略必须由我主导。没有我的设计AI生成的代码只是一堆散乱的、可能无效的片段。6. 半年实践总结vibe coding改变了什么回顾这半年四个项目的实践我对vibe coding的态度从好奇、焦虑变得平和而笃定。它没有取代我但实实在在地改变了我的一部分工作方式。它最擅长的领域项目启动与样板代码初始化配置、搭建基础框架、安装依赖这些工作变得极其高效。编写重复性高的代码UI组件尤其是列表项、表格行、简单的CRUD操作函数、API路由模板。快速学习新库/API当你对某个库的用法不熟时用自然语言描述你想做什么AI生成的示例代码是一个很好的学习起点但必须结合官方文档验证。生成测试数据和模拟内容为原型或演示快速生成JSON数据、模拟文本等。代码重构与格式化将一段代码转换成另一种风格或者添加注释。它的局限与我的应对策略缺乏整体架构能力AI无法理解一个复杂系统的整体设计。策略是由人负责顶层设计将模块拆解成相对独立、描述清晰的任务再交给AI实现。对业务逻辑和领域知识理解肤浅它只会根据统计概率生成“像那么回事”的代码无法保证符合特定业务规则。策略是核心业务逻辑必须手写或经过严格审查和测试。容易产生“幻觉”会使用不存在的API或错误的参数。策略是永远保持怀疑并准备好随时查阅官方文档进行验证。代码质量参差不齐可能生成冗长、低效或有潜在bug的代码。策略是将其视为“初稿”必须进行代码审查、重构和优化。对我个人而言最大的改变是“心流”的转移。以前我大量的时间花在记忆API、查找语法错误、编写重复代码上。现在这些“体力活”被分担了我可以把更多精力集中在真正需要创造力和深度思考的事情上产品功能设计、技术方案选型、性能优化策略、用户体验细节。我不再是一个纯粹的“翻译”将需求翻译成代码而是更像一个“导演”或“工程师”指挥着AI这个强大的助手去完成执行层面的工作。所以一个普通前端的这半年不是被AI替代的半年而是借助AI工具拓展了能力边界的半年。它没有让我失业而是让我有更多时间去解决那些更复杂、更有价值的问题。如果你也在观望我的建议是不要再犹豫现在就选一个小项目亲手去试一下。从让它帮你写一个工具函数、一个组件开始。你会在这个过程中重新认识编程也重新认识你自己作为开发者的价值。未来的前端开发一定是“人机协同”的模式而尽早开始练习这种协同就是最好的准备。