2025年这轮AI编程浪潮Vibe Coding确实从一个圈内黑话变成了很多人天天在用的开发方式。我自己做了七八年全栈开发前两年对AI写代码一直保留态度觉得无非是个高级补全工具。直到最近半年我把一个带后台的内容管理项目用Vibe Coding的方式从空目录一路推到可部署状态过程中还顺手协助了嵌入式方向的C语言开发才意识到这套协作模式已经把全栈开发的效率天花板抬高了不止一截。如果你也想把这种“用大白话驱动代码生成”的开发方式落到真实项目里这篇文章可以给你一套从认知到落地的完整参考。先给个结论Vibe Coding不是什么神秘魔法它就是开发者和AI之间的一种协作模式。你不必再把注意力锁死在每个函数的语法上而是像带一个能力很强但缺乏业务理解的新人一样把自己的意图、约束条件和验收标准讲清楚由AI去生成实现你来把控方向、审查质量。全栈开发恰好是这种模式收益最大的场景之一因为技术栈多、流程长传统开发里人肉切换前端后端数据库的成本很高而AI能在这些环节之间快速游走跨栈成本几乎被降到了零。这篇内容会围绕一个真实的小项目展开一个带用户系统和管理后台的内容发布工具。我会从工具选型、需求拆解、Prompt编写、前后端联调到调试重构和常见坑位完整走一遍Vibe Coding全栈开发的实操流程。无论你是刚入行的前端新人还是想提效的资深全栈都能在里面找到可以直接拿去用的部分。1. 先搞懂Vibe Coding它到底改变了什么1.1 什么是Vibe Coding为什么突然就出圈了Vibe Coding这个词广泛传播也就是2025年这几个月的事。最早它被用来形容“顺着感觉写代码”的状态后来逐渐延展成一条完整的工作流开发者用自然语言描述需求、场景和约束AI模型负责生成代码实现开发者更像一个定义目标和审查结果的人。为什么偏偏是这时候火起来我自己的体感有三个直接原因。第一模型的上下文窗口变大了AI不再只看得到当前打开的那个文件而是能同时感知项目的目录结构、依赖配置和已有代码风格这让“项目级代码生成”第一次变得可靠。第二代码生成质量整体跨过了一条实用线常见的增删改查、表单页面、接口封装已经能接近“零修改跑通”的水平无需人从头到尾盯一遍。第三开发工具本身深度集成了AI能力编辑器、命令行、调试面板全部变成了对话入口生成代码和修改代码的成本都在肉眼可见地下降。拿我做全栈的经验类比一下2023年的AI辅助更像一个翻译器你给出单个函数它帮你换个写法到了2025年Vibe Coding则更像一个结对编程的队友你说需求它出方案敲代码你看完review意见后再让它改。这个变化听起来不大实际上整个开发节奏都被重置了。1.2 什么样的全栈项目最适合Vibe Coding这是我最想先讲清楚的一点Vibe Coding不是万能的用对地方效率翻倍用错地方会把自己耗死在排查问题的泥潭里。最适合它的是那些“结构清晰、逻辑直白”的项目。比如MVP产品原型你想快速验证一个想法能不能跑通内部管理系统大量CRUD页面加权限控制页面多但模式高度接近工具型网站用户上传、服务端处理、结果展示是常态形态还有教学演示项目需要端到端可执行但不需要超高并发或极致性能。反过来不太适合的场景也有几个。性能极敏感的底层中间件比如消息队列、实时流处理引擎AI生成的实现往往在极端边界条件下有隐患安全等级高的支付风控、权限审计核心逻辑不能接受黑盒代码算法密集的模块例如推荐排序、高维向量计算有大量数学推导需要人工深度把关。你硬要用Vibe Coding去写这类东西最终的调试成本很可能超过手写的时间这是我在实践中反复确认过的。1.3 用Vibe Coding做全栈需要先攒哪些底子我必须拨一句冷水Vibe Coding不是“不用学编程也能开发软件”的捷径。AI能帮你生成代码但它不会替你去理解需求的业务含义更不会替你看懂报错信息。全栈开发涉及前后端通信、数据库设计、权限管理、部署运维任何一环出问题整个项目都可能停摆。如果完全不懂基础概念AI生成出来的东西即便能跑你也判断不了它到底跑得对不对。所以我的建议是上手之前至少要有这样几块底子熟悉一门后端语言Node.js、Python或Go都行的基础语法理解RESTful接口是怎么工作的前端不用精通框架源码但要清楚组件、路由、状态管理这些概念数据库至少能写简单的SQL知道表连接和索引大致是干什么的。这个门槛认真学的话一两个月就能到。有了这些基础再配合Vibe Coding你会发现自己真正要干的事情从“写代码”变成了“定义需求、审查结果、修正方向”效率提升确实是倍数级的。这不是玄学也不是因为AI替你偷懒了而是你把人最擅长的事留给了人把机器擅长的体力活留给了机器。2. 工具链选型我的实际搭配方案2.1 主流Vibe Coding工具横向对比谈Vibe Coding工具选型是第一道绕不开的坎。我在不同项目里来回折腾了很多轮目前的判断是没有绝对最好的工具只有当前阶段最适合你的工具。工具模型基础适合人群核心优势主要短板CursorClaude/GPT 系列混合调度深度全栈开发者编辑器体验强能感知整个项目结构多文件修改顺手商业版价格偏高新手上手参数略多GitHub CopilotGPT 系列 Claude重度使用 VSCode 的开发者和 GitHub 生态无缝集成PR 代码审查辅助实用面对大型重构时上下文理解不够深Claude 对话版Claude 系列对话式开发爱好者长上下文理解极强适合架构讨论和复杂 bug 定位编辑器与命令行链路需要自己搭通义灵码通义千问系列国内网络环境使用者中文理解好安装简单与阿里云生态联动多项目级多文件重构能力仍在追赶豆包 MarsCode豆包大模型国内轻量需求上手快界面友好长项目上下文记忆能力中等这张表里我只列了自己真正用过的工具。还有一些新出的工具我也测试过但稳定性还不适合放上生产链路。表格只是参考真正选哪个取决于你日常的开发环境、网络条件以及项目本身的复杂度。2.2 我推荐的组合方案与理由想一套工具吃遍所有场景至少在我这里是行不通的。“快速加功能”和“多文件复杂重构”这两件事对工具能力的要求截然不同。我目前的组合是日常代码生成以Cursor为主力它的项目上下文感知能力确实顶尖在已有代码基础上加一个功能模块非常顺手架构方案的讨论、疑难bug的分析我会开一个Claude对话窗口把项目背景完整描述一遍让它给出经过权衡的整体方案GitHub Copilot则作为兜底补全当我不想切窗口时直接在IDE里完成小段落代码。这个“双AI并行”的组合我用了几个月最大的体会是各取所长。Cursor在快速迭代时很高效但面对“帮我把三个页面里的重复逻辑抽成通用组件”这类重构需求它给的方案经常不够彻底Claude对话则更适合把整个项目的背景一次性灌进去让它站在全局角度思考。两个工具互相补充基本覆盖了全栈开发的主线流程。不过有一点要提醒工具并不是装得越多越好。我见过不少同行桌面上同时开五六个AI工具每个生成的效果都半斤八两反而因为风格不统一浪费了大量时间。更好的做法是先选一个主力用顺手至少完成一两个完整项目再根据自己的痛点补充第二个工具。工具切换是有记忆成本的它会打断你对某个工具“脾气”的熟悉度而这恰恰是效率的重要来源。2.3 从空目录到可运行骨架一次完整的技术栈热身用Vibe Coding启动项目核心目标是先把一个可运行的骨架立起来。这一步的意义在于让AI和你共享同一个明确的项目上下文后续所有功能开发都在这个骨架上生长。以我们那个内容发布工具为例。我打开Cursor输入了这么一段初始Prompt我要新建一个全栈项目 - 前端React Vite TypeScript - 后端Node.js Express TypeScript - 数据库SQLite通过 Prisma 管理 - 功能用户注册登录、文章发布和列表展示、管理员后台管理用户和文章 请帮我搭建项目目录结构初始化前后端 package.json配置好前后端连接 最终给出一个首页可访问、后端健康检查接口能调通的完整骨架。AI返回的结果通常包括一个目录树、若干初始化命令和几个关键文件。我一般要求它“逐步执行”每完成一步就把目录结构和启动命令同步给我我会立刻在终端里验证。这个阶段的核心不是看AI生成得有多快而是拿到骨架后立刻做三件事检查目录结构是否合理、启动脚本是否齐全、前端是否成功调通了后端的健康检查接口。这三关过了说明项目的地基打稳了后面加功能会顺畅得多。这个过程我实测下来一般十几分钟就能让前后端两个服务跑起来。节奏感很重要每加一个模块就立刻启动验证而不是让AI一口气生成一大堆代码再统一排查。Vibe Coding的效率和“小步快跑”的验证节奏是强绑定的。3. 需求转Prompt让AI真正听懂你的想法3.1 写好Vibe Coding Prompt的底层逻辑很多刚开始用Vibe Coding的人都会遇到一个尴尬AI生成的代码要么跑不起来要么根本不是自己想要的东西。问题通常不出在AI身上而是你的Prompt写得像一团浆糊。我的经验是好的代码生成Prompt应该包含三层信息角色定位、业务场景、验收标准。角色定位是告诉AI它现在是一名资深全栈工程师项目背景是什么业务场景是把用户故事描述清楚谁在什么场景下做什么事验收标准则是用可验证的语句定义“完成”比如“用户输入邮箱密码后能注册成功注册成功跳转到引导页错误时显示中文提示”。这背后的逻辑其实和人协作一模一样。你带一个能力很强的实习生但如果连需求都说不清楚他做出来的东西也很难贴合你的预期。模型同理它对你的领域和项目背景一无所知Prompt里多一行上下文结果的质量就会上一个台阶。3.2 从一句话需求到结构化任务书很多人写Prompt时习惯只给一句话“帮我做一个文章发布功能。”这句话的信息量太低了AI不知道文章有哪些字段、谁可以发、发完要不要审核、列表怎么排序。我建议花几分钟把一句话扩展成结构化任务书在Prompt里包含功能清单、数据字段、交互逻辑、约束条件四个部分。一个我在实际项目中用过的完整Prompt长这样需求内容管理后台的文章发布模块 功能清单 - 登录后的用户可以在编辑器里创建文章 - 文章包含标题、摘要、正文Markdown格式、封面图URL - 创建后文章状态为“草稿”可提交审核 - 管理员审核通过后文章状态变为“已发布” 数据要求 - Article 表包含 id, title, summary, content, cover_url, status, author_id, created_at, updated_at - status 枚举draft, pending, published, rejected 交互逻辑 - 编辑器页面左侧填写表单右侧实时预览 Markdown - 提交后跳转到文章列表状态栏展示不同颜色标签 约束条件 - 前端请求通过 axios 发送统一带 token - 后端接口返回统一格式{ code, data, message } - 数据库操作全部通过 Prisma这种Prompt看起来长但AI的回报非常直接。它生成的东西基本就是你脑子里的方案不需要再反复打磨修改。我习惯把常用的任务书格式存成模板每次做新模块改一改就能用等于把“需求表达”这件最该花时间的事标准化了。3.3 用“小步快跑”拆解全栈功能模块拿到一个完整的全栈项目需求别试图让AI一口气生成所有东西。上下文一旦拉长模型的注意力就会分散后生成的部分细节质量明显下降。我常用的方法是把项目拆成“数据层—接口层—页面层—联调层”四个递进阶段每个阶段单独对话推进。数据层只定义数据库表和Prisma模型接口层让AI根据模型生成RESTful接口和路由页面层聚焦前端页面和组件联调层才把前后端串起来跑通。每个阶段结束前我都会让AI总结一份“已完成与待办清单”确认上下文没有丢失。举个例子做那个内容发布工具的时候我第一步只让AI设计数据库表明确文章、用户、评论之间的关系。这个对话结束确认表结构OK后我再开新对话让AI基于这套表结构生成后端接口。这样做的好处是每一个阶段都有明确验收点出了问题能立刻定位是在模型层、接口层还是页面层而不是被一个大项目的复杂上下文拖入泥潭。4. 全栈核心模块Vibe Coding实战4.1 数据模型设计让AI先画清楚表之间怎么连全栈项目里最不能含糊的就是数据模型。表结构定错了后面所有接口和页面都会跟着返工。我在Vibe Coding流程里通常会让AI先给出完整的数据模型方案把表和表之间的关联关系讲清楚再动手生成Prisma代码。内容发布工具的数据模型很简单就是User、Article、Comment三张表。但即便是这么简单的模型也有几个关键设计要提前想清楚用户表和文章表是一对多关系文章和评论是一对多关系文章的状态字段是用字符串还是枚举。这些细节如果不定义清楚AI生成接口时就会无所适从。我会这样跟AI沟通请用 Prisma Schema 定义 User、Article、Comment 三张表。 要求 - User 包含 id, email, passwordHash, role, createdAt, updatedAt - Article 包含 id, title, summary, content, coverUrl, status, authorId, createdAt, updatedAt - Comment 包含 id, content, articleId, authorId, createdAt - 用户和文章是一对多文章和评论是一对多 - 在 prisma schema 里使用 relation 建立外键 - 帮我生成迁移命令AI给出的Schema通常可以直接用。我会重点检查外键关系是否正确、字段命名是否统一、有没有遗漏索引。这个环节人工把关的价值远大于让AI自由发挥因为数据库设计决定了项目能走多远。4.2 后端接口与业务逻辑让AI先生成边界再补细节数据模型就位后下一步是后端接口。我习惯让AI按RESTful风格生成一套完整的接口代码包括路由、控制器、验证逻辑和统一返回格式。还是那句话先给边界再让AI补细节。我给AI的定义是所有API前缀是 /api返回格式统一用户身份通过JWT验证admin角色才能访问管理接口。连示例返回结构都一起给它请基于 Prisma Schema 生成 Express 后端接口 - POST /api/auth/register 用户注册 - POST /api/auth/login 用户登录 - GET /api/articles 分页获取已发布文章 - POST /api/articles 创建文章登录用户 - PUT /api/articles/:id 修改文章作者本人或管理员 - PUT /api/articles/:id/review 审核文章管理员 - GET /api/articles/:id 文章详情包含评论列表 约束 - 所有接口返回 { code: 0, data, message }code 非 0 表示错误 - JWT 从 Authorization: Bearer token 读取 - 权限验证写中间件不要散落在路由里 - Prisma 操作全部 await并用 try-catch 包住后端代码生成完毕后我不会急着测页面而是先用curl把关键接口跑一遍。注册一个用户、登录拿token、创建文章、列表查询这四步通了后端就可信了。顺便说一句让AI生成接口时明确要求它“先写中间件再写路由”这个顺序能避免一堆权限验证的问题。4.3 前端页面与交互用组件化的思路指挥AI前端是Vibe Coding最能出效果的地方但也最容易翻车。因为前端设计主观性很强同一个需求AI可能给你一个看起来挺美但交互细节糟糕的页面。我的做法是把前端抽象成组件树。让AI先生成页面级组件再细化到子组件每个组件职责单一。比如文章列表页我要求AI拆成ArticleList、ArticleCard、StatusTag三个组件而不是把一个页面写成上千行的大杂烩。组件化的思路对AI同样有效它一次只需要理解和维护一个组件生成的代码可读性和可复用性都会好不少。另一个关键点是交互状态管理。前端页面最麻烦的不是渲染而是loading、成功、失败、空数据这些状态。我会明确要求AI处理这些状态并给它示例。比如请求列表时显示骨架屏请求失败时显示错误提示和重试按钮空数据时显示空白页引导。这些细节如果不写进PromptAI默认只会给你一个最简单的列表渲染交互体验会非常粗糙。4.4 前后端联调与上下文记忆让AI保持同一个世界观前后端联调是Vibe Coding项目里最容易翻车的环节。AI生成前端时不知道后端接口长什么样生成后端时又不知道前端组件怎么消费数据两边各写各的联调必出问题。我解决这个问题的办法是在每个对话的开头显式注入一份“项目上下文文件”。这份文件里记录了技术栈、目录结构、已有接口的定义、数据模型、命名规范。每次新开对话让AI改前端时先把这部分上下文贴给它。看起来有点繁琐但可以避免大量“接口对不上”的返工。另外要善用AI的长期记忆能力。Claude和Cursor都支持把整个项目目录作为上下文AI会自动读取已有的代码。我会在项目根目录维护一个ARCHITECTURE.md文件里面记录关键设计决策和接口约定。当AI对话开始出现“前后端不一致”信号时我就让AI先读这个文件再动手效果立竿见影。5. 调试与重构Vibe Coding真正的考验5.1 AI生成代码最常见的三种错误模式Vibe Coding让人头疼的从来不是生成速度而是调试。AI生成的代码跑不起来是常态但错误源往往集中在几个固定模式上。第一种是类型不匹配。前端传的是字符串后端期望数字数据库存的是Date对象前端拿到的是字符串。这种错误在TypeScript项目里尤其常见AI在生成跨端代码时容易忽略类型系统的一致性。第二种是异步处理不当。AI经常会生成没有await的异步调用或者在循环里直接使用异步结果。这类bug通常只在运行时偶发排查起来格外费时。第三种是上下文依赖遗漏。AI生成某个功能时没有及时查看项目里已有的工具函数、组件或环境变量导致它“重新发明轮子”。比如项目里明明封装好了request工具AI却直接用了原生axios还忘了带token。识别出这三类模式后我在让AI生成代码时会对症下药明确要求它“先看项目已有的utils和services目录再动手”检查代码时优先看类型定义和异步调用一旦出现循环里跑异步直接让AI重写。5.2 让AI自己修Bug给错误也给现场让AI修bug只贴一行报错信息是远远不够的。AI需要的是“错误现场”。我会把完整报错堆栈、相关代码片段、复现步骤、我尝试过的排查方向四样东西一起交给AI。我平时用的bug修复Prompt格式是这样运行时报错TypeError: Cannot read properties of undefined (reading name) 复现步骤 1. 登录用户后点击文章列表第二页 2. 页面顶部抛出上述错误 相关代码 ...这里贴ArticleList组件和接口定义... 我已经排查过 - 确认接口返回数据list 字段有值 - 但分页切页后 currentPage 为 undefined 请帮我定位问题并给出修复方案。这种带“现场信息”的提问方式AI的修复成功率会大幅提升。它不用靠猜而是能基于你给的信息精准定位。另一个技巧是要让AI给出不止一个方案并说明每个方案的影响范围。很多时候修复一个bug会带动另一个bugAI如果能提前告诉你“这个改法会影响分页组件的复用”你就能提前规避。5.3 哪些代码区域必须保持人工审查Vibe Coding不是把代码生产完全交给AI人还是要做“守门员”。我给自己定了一条规矩涉及权限、支付、数据完整性、外部输入的代码必须人工逐行审查。尤其是用户输入的验证与清理AI生成的代码往往缺少对异常输入的防御容易产生注入或越权风险。另外工具函数和通用组件我也建议人工重写或深度改造。因为这类代码会被项目里的多个模块复用AI生成的版本可能只满足当前场景一旦换了复用场景就出问题。我会让AI生成初稿然后自己用半小时重构一遍确保边界处理完整。还有一个经常被忽略的审查点是环境变量和配置。AI生成代码时喜欢把数据库连接串、密钥、API地址硬编码进文件里这在项目早期也许无伤大雅一旦要部署上线就是灾难。所以每轮对话结束我都会额外检查一遍有没有敏感信息裸奔。6. 嵌入式方向的前瞻Vibe Coding的下一站6.1 为什么嵌入式也能用Vibe Coding最近“嵌入式vibe coding”这个词开始出现在一些技术社区里。很多人下意识觉得嵌入式开发和AI写代码不搭界其实恰恰相反。嵌入式开发有大量样板代码比如寄存器配置、外设初始化、通信协议解析这些内容高度标准化AI生成起来非常顺手。我协助过的一个小项目目标是让一块MCU开发板通过串口读取传感器数据解析后显示在OLED屏幕上。传统写法需要查芯片手册、写寄存器、调时序对不熟悉硬件的人来说门槛很高。用Vibe Coding的思路我只需要告诉AI芯片型号、外设引脚、通信协议它会生成一份初始化代码和读取逻辑我再对着手册核对引脚号和寄存器地址比自己从零查手册快很多。但嵌入式和纯软件有个关键差异代码能不能跑最终要靠硬件来验证。AI生成的代码可能出现引脚配置错误、时钟频率不对、时序不匹配之类的问题这些在纯软件项目里根本不存在。所以嵌入式Vibe Coding更适合“生成参考实现人工核对硬件细节”的组合。6.2 嵌入式Vibe Coding与全栈开发的差异在我体验下来两者至少有四个明显差异。第一工具链不同。全栈开发用Cursor、Copilot这类IDE集成工具很舒服但嵌入式开发往往要操作串口工具、交叉编译器、调试器AI对这些工具的集成还不够深。我更多是让AI生成C代码再手动把代码放进交叉编译环境里验证。第二验证周期完全不同。全栈项目改完代码浏览器一刷新就能看到效果验证成本极低嵌入式则要经过编译、烧录、硬件上电、观察现象一次迭代可能好几十分钟。这个差异决定了嵌入式Vibe Coding不能“小步快跑”更要把AI生成的代码当作一次性高质量交付来对待。第三上下文来源不一样。全栈项目的上下文是代码和文档AI很容易读到嵌入式项目的上下文有很大一部分在芯片数据手册和硬件原理图里AI未必能访问。你需要把芯片型号、引脚定义、参考手册的关键参数手动贴给它Prompt会变得更长。第四失败的代价不同。后端代码崩了重启一下就行嵌入式代码如果配置错了寄存器轻则功能异常重则损坏外设甚至整块开发板。所以在嵌入式场景里引入AI生成的代码人工审查的层级要比全栈项目高一个等级。这个方向目前还在比较早期的阶段但我认为它的价值和全栈一样大。嵌入式开发的痛点是硬件知识壁垒高、文档枯燥、样板代码多而Vibe Coding恰好擅长把样板化的部分快速生成出来让人把精力集中在需要深入思考的硬件设计上。7. 常见问题与避坑实战记录7.1 常见问题排查速查表Vibe Coding做全栈项目我整理了一份高频问题的排查清单遇到同类问题时直接对照处理。问题现象常见原因快速排查思路前端调后端接口报 CORS 错误后端未开启跨域检查 Express 是否配置 cors 中间件是否允许了前端的 origin登录后刷新页面就退出token 只存在内存里改成 localStorage/sessionStorage 持久化或使用 cookie 方案AI 生成的页面样式错乱组件类名冲突或全局样式污染确认是否使用了 CSS Modules 或 styled-components统一样式方案接口返回数据前端渲染不出来字段命名不一致检查后端序列化后的字段名与前端 TypeScript 类型定义是否完全一致类型报错但代码逻辑没问题AI 生成时忽略了类型定义让 AI 读取 types 目录后重新生成或手动补 interface数据库查询卡死或超时缺少索引或 N1 查询检查 Prisma 生成的 SQL确认外键字段有索引关联查询是否过度每次对话后上下文越来越混乱对话过长导致注意力分散新开对话贴架构文档和当前任务书让 AI 基于全局重新开工这张表我一直在持续更新每踩一个新坑就补一行。它也变成了我和AI协作时的共同语言出现问题我不需要废话直接把对应行的排查方案丢给AI它会沿着正确的方向去定位。7.2 Vibe Coding全流程的几条铁律最后聊几条我摸索出的铁律每一条都是真金白银换来的教训。第一永远保留AI对话的可回滚版本。我会给每轮重要对话打tag标注“这是文章模块设计定稿”或“这是重构前的版本”。AI对话虽然能持续但你没法保证自己不会把代码改坏保留关键版本就是给自己留后路。第二不要让AI同一轮对话里既做大重构又加新功能。重构和新功能是两个完全不同的任务硬混在一起会让AI的注意力分散两边都做不好。我会按“先重构到满意再开新对话加功能”的顺序推进。第三重要业务逻辑不要用AI生成后直接进主干。我会让AI先写单元测试或Mock数据验证通过再合并。这个习惯可以拦截大量低级but致命的bug尤其在权限和状态流转这类逻辑上。第四AI给出的解决方案不一定是最优解但一定是最常见的解。这在很多场景够用但一旦项目规模变大你会发现常见解在扩展性上跟不上了。这时候别犹豫花时间人工设计一次架构再用AI来执行落地。架构的事人不该偷懒。坦白说用了半年多Vibe Coding我对AI编程的态度已经彻底转变。它没有取代我作为工程师的判断力反而把我从重复代码中解放出来让我有更多精力去思考系统设计、业务边界和性能优化这些真正有价值的问题。工具会继续演进但这种人机协作的底层逻辑我觉得会是未来很长一段时间里开发者的核心工作方式。如果你还没试过找个内部小项目认真跑一遍这篇文章里的流程你可能会对“写代码”这件事产生完全不同的感受。 Vibe Coding全栈开发实战：AI驱动从需求到落地的完整指南
2025年这轮AI编程浪潮Vibe Coding确实从一个圈内黑话变成了很多人天天在用的开发方式。我自己做了七八年全栈开发前两年对AI写代码一直保留态度觉得无非是个高级补全工具。直到最近半年我把一个带后台的内容管理项目用Vibe Coding的方式从空目录一路推到可部署状态过程中还顺手协助了嵌入式方向的C语言开发才意识到这套协作模式已经把全栈开发的效率天花板抬高了不止一截。如果你也想把这种“用大白话驱动代码生成”的开发方式落到真实项目里这篇文章可以给你一套从认知到落地的完整参考。先给个结论Vibe Coding不是什么神秘魔法它就是开发者和AI之间的一种协作模式。你不必再把注意力锁死在每个函数的语法上而是像带一个能力很强但缺乏业务理解的新人一样把自己的意图、约束条件和验收标准讲清楚由AI去生成实现你来把控方向、审查质量。全栈开发恰好是这种模式收益最大的场景之一因为技术栈多、流程长传统开发里人肉切换前端后端数据库的成本很高而AI能在这些环节之间快速游走跨栈成本几乎被降到了零。这篇内容会围绕一个真实的小项目展开一个带用户系统和管理后台的内容发布工具。我会从工具选型、需求拆解、Prompt编写、前后端联调到调试重构和常见坑位完整走一遍Vibe Coding全栈开发的实操流程。无论你是刚入行的前端新人还是想提效的资深全栈都能在里面找到可以直接拿去用的部分。1. 先搞懂Vibe Coding它到底改变了什么1.1 什么是Vibe Coding为什么突然就出圈了Vibe Coding这个词广泛传播也就是2025年这几个月的事。最早它被用来形容“顺着感觉写代码”的状态后来逐渐延展成一条完整的工作流开发者用自然语言描述需求、场景和约束AI模型负责生成代码实现开发者更像一个定义目标和审查结果的人。为什么偏偏是这时候火起来我自己的体感有三个直接原因。第一模型的上下文窗口变大了AI不再只看得到当前打开的那个文件而是能同时感知项目的目录结构、依赖配置和已有代码风格这让“项目级代码生成”第一次变得可靠。第二代码生成质量整体跨过了一条实用线常见的增删改查、表单页面、接口封装已经能接近“零修改跑通”的水平无需人从头到尾盯一遍。第三开发工具本身深度集成了AI能力编辑器、命令行、调试面板全部变成了对话入口生成代码和修改代码的成本都在肉眼可见地下降。拿我做全栈的经验类比一下2023年的AI辅助更像一个翻译器你给出单个函数它帮你换个写法到了2025年Vibe Coding则更像一个结对编程的队友你说需求它出方案敲代码你看完review意见后再让它改。这个变化听起来不大实际上整个开发节奏都被重置了。1.2 什么样的全栈项目最适合Vibe Coding这是我最想先讲清楚的一点Vibe Coding不是万能的用对地方效率翻倍用错地方会把自己耗死在排查问题的泥潭里。最适合它的是那些“结构清晰、逻辑直白”的项目。比如MVP产品原型你想快速验证一个想法能不能跑通内部管理系统大量CRUD页面加权限控制页面多但模式高度接近工具型网站用户上传、服务端处理、结果展示是常态形态还有教学演示项目需要端到端可执行但不需要超高并发或极致性能。反过来不太适合的场景也有几个。性能极敏感的底层中间件比如消息队列、实时流处理引擎AI生成的实现往往在极端边界条件下有隐患安全等级高的支付风控、权限审计核心逻辑不能接受黑盒代码算法密集的模块例如推荐排序、高维向量计算有大量数学推导需要人工深度把关。你硬要用Vibe Coding去写这类东西最终的调试成本很可能超过手写的时间这是我在实践中反复确认过的。1.3 用Vibe Coding做全栈需要先攒哪些底子我必须拨一句冷水Vibe Coding不是“不用学编程也能开发软件”的捷径。AI能帮你生成代码但它不会替你去理解需求的业务含义更不会替你看懂报错信息。全栈开发涉及前后端通信、数据库设计、权限管理、部署运维任何一环出问题整个项目都可能停摆。如果完全不懂基础概念AI生成出来的东西即便能跑你也判断不了它到底跑得对不对。所以我的建议是上手之前至少要有这样几块底子熟悉一门后端语言Node.js、Python或Go都行的基础语法理解RESTful接口是怎么工作的前端不用精通框架源码但要清楚组件、路由、状态管理这些概念数据库至少能写简单的SQL知道表连接和索引大致是干什么的。这个门槛认真学的话一两个月就能到。有了这些基础再配合Vibe Coding你会发现自己真正要干的事情从“写代码”变成了“定义需求、审查结果、修正方向”效率提升确实是倍数级的。这不是玄学也不是因为AI替你偷懒了而是你把人最擅长的事留给了人把机器擅长的体力活留给了机器。2. 工具链选型我的实际搭配方案2.1 主流Vibe Coding工具横向对比谈Vibe Coding工具选型是第一道绕不开的坎。我在不同项目里来回折腾了很多轮目前的判断是没有绝对最好的工具只有当前阶段最适合你的工具。工具模型基础适合人群核心优势主要短板CursorClaude/GPT 系列混合调度深度全栈开发者编辑器体验强能感知整个项目结构多文件修改顺手商业版价格偏高新手上手参数略多GitHub CopilotGPT 系列 Claude重度使用 VSCode 的开发者和 GitHub 生态无缝集成PR 代码审查辅助实用面对大型重构时上下文理解不够深Claude 对话版Claude 系列对话式开发爱好者长上下文理解极强适合架构讨论和复杂 bug 定位编辑器与命令行链路需要自己搭通义灵码通义千问系列国内网络环境使用者中文理解好安装简单与阿里云生态联动多项目级多文件重构能力仍在追赶豆包 MarsCode豆包大模型国内轻量需求上手快界面友好长项目上下文记忆能力中等这张表里我只列了自己真正用过的工具。还有一些新出的工具我也测试过但稳定性还不适合放上生产链路。表格只是参考真正选哪个取决于你日常的开发环境、网络条件以及项目本身的复杂度。2.2 我推荐的组合方案与理由想一套工具吃遍所有场景至少在我这里是行不通的。“快速加功能”和“多文件复杂重构”这两件事对工具能力的要求截然不同。我目前的组合是日常代码生成以Cursor为主力它的项目上下文感知能力确实顶尖在已有代码基础上加一个功能模块非常顺手架构方案的讨论、疑难bug的分析我会开一个Claude对话窗口把项目背景完整描述一遍让它给出经过权衡的整体方案GitHub Copilot则作为兜底补全当我不想切窗口时直接在IDE里完成小段落代码。这个“双AI并行”的组合我用了几个月最大的体会是各取所长。Cursor在快速迭代时很高效但面对“帮我把三个页面里的重复逻辑抽成通用组件”这类重构需求它给的方案经常不够彻底Claude对话则更适合把整个项目的背景一次性灌进去让它站在全局角度思考。两个工具互相补充基本覆盖了全栈开发的主线流程。不过有一点要提醒工具并不是装得越多越好。我见过不少同行桌面上同时开五六个AI工具每个生成的效果都半斤八两反而因为风格不统一浪费了大量时间。更好的做法是先选一个主力用顺手至少完成一两个完整项目再根据自己的痛点补充第二个工具。工具切换是有记忆成本的它会打断你对某个工具“脾气”的熟悉度而这恰恰是效率的重要来源。2.3 从空目录到可运行骨架一次完整的技术栈热身用Vibe Coding启动项目核心目标是先把一个可运行的骨架立起来。这一步的意义在于让AI和你共享同一个明确的项目上下文后续所有功能开发都在这个骨架上生长。以我们那个内容发布工具为例。我打开Cursor输入了这么一段初始Prompt我要新建一个全栈项目 - 前端React Vite TypeScript - 后端Node.js Express TypeScript - 数据库SQLite通过 Prisma 管理 - 功能用户注册登录、文章发布和列表展示、管理员后台管理用户和文章 请帮我搭建项目目录结构初始化前后端 package.json配置好前后端连接 最终给出一个首页可访问、后端健康检查接口能调通的完整骨架。AI返回的结果通常包括一个目录树、若干初始化命令和几个关键文件。我一般要求它“逐步执行”每完成一步就把目录结构和启动命令同步给我我会立刻在终端里验证。这个阶段的核心不是看AI生成得有多快而是拿到骨架后立刻做三件事检查目录结构是否合理、启动脚本是否齐全、前端是否成功调通了后端的健康检查接口。这三关过了说明项目的地基打稳了后面加功能会顺畅得多。这个过程我实测下来一般十几分钟就能让前后端两个服务跑起来。节奏感很重要每加一个模块就立刻启动验证而不是让AI一口气生成一大堆代码再统一排查。Vibe Coding的效率和“小步快跑”的验证节奏是强绑定的。3. 需求转Prompt让AI真正听懂你的想法3.1 写好Vibe Coding Prompt的底层逻辑很多刚开始用Vibe Coding的人都会遇到一个尴尬AI生成的代码要么跑不起来要么根本不是自己想要的东西。问题通常不出在AI身上而是你的Prompt写得像一团浆糊。我的经验是好的代码生成Prompt应该包含三层信息角色定位、业务场景、验收标准。角色定位是告诉AI它现在是一名资深全栈工程师项目背景是什么业务场景是把用户故事描述清楚谁在什么场景下做什么事验收标准则是用可验证的语句定义“完成”比如“用户输入邮箱密码后能注册成功注册成功跳转到引导页错误时显示中文提示”。这背后的逻辑其实和人协作一模一样。你带一个能力很强的实习生但如果连需求都说不清楚他做出来的东西也很难贴合你的预期。模型同理它对你的领域和项目背景一无所知Prompt里多一行上下文结果的质量就会上一个台阶。3.2 从一句话需求到结构化任务书很多人写Prompt时习惯只给一句话“帮我做一个文章发布功能。”这句话的信息量太低了AI不知道文章有哪些字段、谁可以发、发完要不要审核、列表怎么排序。我建议花几分钟把一句话扩展成结构化任务书在Prompt里包含功能清单、数据字段、交互逻辑、约束条件四个部分。一个我在实际项目中用过的完整Prompt长这样需求内容管理后台的文章发布模块 功能清单 - 登录后的用户可以在编辑器里创建文章 - 文章包含标题、摘要、正文Markdown格式、封面图URL - 创建后文章状态为“草稿”可提交审核 - 管理员审核通过后文章状态变为“已发布” 数据要求 - Article 表包含 id, title, summary, content, cover_url, status, author_id, created_at, updated_at - status 枚举draft, pending, published, rejected 交互逻辑 - 编辑器页面左侧填写表单右侧实时预览 Markdown - 提交后跳转到文章列表状态栏展示不同颜色标签 约束条件 - 前端请求通过 axios 发送统一带 token - 后端接口返回统一格式{ code, data, message } - 数据库操作全部通过 Prisma这种Prompt看起来长但AI的回报非常直接。它生成的东西基本就是你脑子里的方案不需要再反复打磨修改。我习惯把常用的任务书格式存成模板每次做新模块改一改就能用等于把“需求表达”这件最该花时间的事标准化了。3.3 用“小步快跑”拆解全栈功能模块拿到一个完整的全栈项目需求别试图让AI一口气生成所有东西。上下文一旦拉长模型的注意力就会分散后生成的部分细节质量明显下降。我常用的方法是把项目拆成“数据层—接口层—页面层—联调层”四个递进阶段每个阶段单独对话推进。数据层只定义数据库表和Prisma模型接口层让AI根据模型生成RESTful接口和路由页面层聚焦前端页面和组件联调层才把前后端串起来跑通。每个阶段结束前我都会让AI总结一份“已完成与待办清单”确认上下文没有丢失。举个例子做那个内容发布工具的时候我第一步只让AI设计数据库表明确文章、用户、评论之间的关系。这个对话结束确认表结构OK后我再开新对话让AI基于这套表结构生成后端接口。这样做的好处是每一个阶段都有明确验收点出了问题能立刻定位是在模型层、接口层还是页面层而不是被一个大项目的复杂上下文拖入泥潭。4. 全栈核心模块Vibe Coding实战4.1 数据模型设计让AI先画清楚表之间怎么连全栈项目里最不能含糊的就是数据模型。表结构定错了后面所有接口和页面都会跟着返工。我在Vibe Coding流程里通常会让AI先给出完整的数据模型方案把表和表之间的关联关系讲清楚再动手生成Prisma代码。内容发布工具的数据模型很简单就是User、Article、Comment三张表。但即便是这么简单的模型也有几个关键设计要提前想清楚用户表和文章表是一对多关系文章和评论是一对多关系文章的状态字段是用字符串还是枚举。这些细节如果不定义清楚AI生成接口时就会无所适从。我会这样跟AI沟通请用 Prisma Schema 定义 User、Article、Comment 三张表。 要求 - User 包含 id, email, passwordHash, role, createdAt, updatedAt - Article 包含 id, title, summary, content, coverUrl, status, authorId, createdAt, updatedAt - Comment 包含 id, content, articleId, authorId, createdAt - 用户和文章是一对多文章和评论是一对多 - 在 prisma schema 里使用 relation 建立外键 - 帮我生成迁移命令AI给出的Schema通常可以直接用。我会重点检查外键关系是否正确、字段命名是否统一、有没有遗漏索引。这个环节人工把关的价值远大于让AI自由发挥因为数据库设计决定了项目能走多远。4.2 后端接口与业务逻辑让AI先生成边界再补细节数据模型就位后下一步是后端接口。我习惯让AI按RESTful风格生成一套完整的接口代码包括路由、控制器、验证逻辑和统一返回格式。还是那句话先给边界再让AI补细节。我给AI的定义是所有API前缀是 /api返回格式统一用户身份通过JWT验证admin角色才能访问管理接口。连示例返回结构都一起给它请基于 Prisma Schema 生成 Express 后端接口 - POST /api/auth/register 用户注册 - POST /api/auth/login 用户登录 - GET /api/articles 分页获取已发布文章 - POST /api/articles 创建文章登录用户 - PUT /api/articles/:id 修改文章作者本人或管理员 - PUT /api/articles/:id/review 审核文章管理员 - GET /api/articles/:id 文章详情包含评论列表 约束 - 所有接口返回 { code: 0, data, message }code 非 0 表示错误 - JWT 从 Authorization: Bearer token 读取 - 权限验证写中间件不要散落在路由里 - Prisma 操作全部 await并用 try-catch 包住后端代码生成完毕后我不会急着测页面而是先用curl把关键接口跑一遍。注册一个用户、登录拿token、创建文章、列表查询这四步通了后端就可信了。顺便说一句让AI生成接口时明确要求它“先写中间件再写路由”这个顺序能避免一堆权限验证的问题。4.3 前端页面与交互用组件化的思路指挥AI前端是Vibe Coding最能出效果的地方但也最容易翻车。因为前端设计主观性很强同一个需求AI可能给你一个看起来挺美但交互细节糟糕的页面。我的做法是把前端抽象成组件树。让AI先生成页面级组件再细化到子组件每个组件职责单一。比如文章列表页我要求AI拆成ArticleList、ArticleCard、StatusTag三个组件而不是把一个页面写成上千行的大杂烩。组件化的思路对AI同样有效它一次只需要理解和维护一个组件生成的代码可读性和可复用性都会好不少。另一个关键点是交互状态管理。前端页面最麻烦的不是渲染而是loading、成功、失败、空数据这些状态。我会明确要求AI处理这些状态并给它示例。比如请求列表时显示骨架屏请求失败时显示错误提示和重试按钮空数据时显示空白页引导。这些细节如果不写进PromptAI默认只会给你一个最简单的列表渲染交互体验会非常粗糙。4.4 前后端联调与上下文记忆让AI保持同一个世界观前后端联调是Vibe Coding项目里最容易翻车的环节。AI生成前端时不知道后端接口长什么样生成后端时又不知道前端组件怎么消费数据两边各写各的联调必出问题。我解决这个问题的办法是在每个对话的开头显式注入一份“项目上下文文件”。这份文件里记录了技术栈、目录结构、已有接口的定义、数据模型、命名规范。每次新开对话让AI改前端时先把这部分上下文贴给它。看起来有点繁琐但可以避免大量“接口对不上”的返工。另外要善用AI的长期记忆能力。Claude和Cursor都支持把整个项目目录作为上下文AI会自动读取已有的代码。我会在项目根目录维护一个ARCHITECTURE.md文件里面记录关键设计决策和接口约定。当AI对话开始出现“前后端不一致”信号时我就让AI先读这个文件再动手效果立竿见影。5. 调试与重构Vibe Coding真正的考验5.1 AI生成代码最常见的三种错误模式Vibe Coding让人头疼的从来不是生成速度而是调试。AI生成的代码跑不起来是常态但错误源往往集中在几个固定模式上。第一种是类型不匹配。前端传的是字符串后端期望数字数据库存的是Date对象前端拿到的是字符串。这种错误在TypeScript项目里尤其常见AI在生成跨端代码时容易忽略类型系统的一致性。第二种是异步处理不当。AI经常会生成没有await的异步调用或者在循环里直接使用异步结果。这类bug通常只在运行时偶发排查起来格外费时。第三种是上下文依赖遗漏。AI生成某个功能时没有及时查看项目里已有的工具函数、组件或环境变量导致它“重新发明轮子”。比如项目里明明封装好了request工具AI却直接用了原生axios还忘了带token。识别出这三类模式后我在让AI生成代码时会对症下药明确要求它“先看项目已有的utils和services目录再动手”检查代码时优先看类型定义和异步调用一旦出现循环里跑异步直接让AI重写。5.2 让AI自己修Bug给错误也给现场让AI修bug只贴一行报错信息是远远不够的。AI需要的是“错误现场”。我会把完整报错堆栈、相关代码片段、复现步骤、我尝试过的排查方向四样东西一起交给AI。我平时用的bug修复Prompt格式是这样运行时报错TypeError: Cannot read properties of undefined (reading name) 复现步骤 1. 登录用户后点击文章列表第二页 2. 页面顶部抛出上述错误 相关代码 ...这里贴ArticleList组件和接口定义... 我已经排查过 - 确认接口返回数据list 字段有值 - 但分页切页后 currentPage 为 undefined 请帮我定位问题并给出修复方案。这种带“现场信息”的提问方式AI的修复成功率会大幅提升。它不用靠猜而是能基于你给的信息精准定位。另一个技巧是要让AI给出不止一个方案并说明每个方案的影响范围。很多时候修复一个bug会带动另一个bugAI如果能提前告诉你“这个改法会影响分页组件的复用”你就能提前规避。5.3 哪些代码区域必须保持人工审查Vibe Coding不是把代码生产完全交给AI人还是要做“守门员”。我给自己定了一条规矩涉及权限、支付、数据完整性、外部输入的代码必须人工逐行审查。尤其是用户输入的验证与清理AI生成的代码往往缺少对异常输入的防御容易产生注入或越权风险。另外工具函数和通用组件我也建议人工重写或深度改造。因为这类代码会被项目里的多个模块复用AI生成的版本可能只满足当前场景一旦换了复用场景就出问题。我会让AI生成初稿然后自己用半小时重构一遍确保边界处理完整。还有一个经常被忽略的审查点是环境变量和配置。AI生成代码时喜欢把数据库连接串、密钥、API地址硬编码进文件里这在项目早期也许无伤大雅一旦要部署上线就是灾难。所以每轮对话结束我都会额外检查一遍有没有敏感信息裸奔。6. 嵌入式方向的前瞻Vibe Coding的下一站6.1 为什么嵌入式也能用Vibe Coding最近“嵌入式vibe coding”这个词开始出现在一些技术社区里。很多人下意识觉得嵌入式开发和AI写代码不搭界其实恰恰相反。嵌入式开发有大量样板代码比如寄存器配置、外设初始化、通信协议解析这些内容高度标准化AI生成起来非常顺手。我协助过的一个小项目目标是让一块MCU开发板通过串口读取传感器数据解析后显示在OLED屏幕上。传统写法需要查芯片手册、写寄存器、调时序对不熟悉硬件的人来说门槛很高。用Vibe Coding的思路我只需要告诉AI芯片型号、外设引脚、通信协议它会生成一份初始化代码和读取逻辑我再对着手册核对引脚号和寄存器地址比自己从零查手册快很多。但嵌入式和纯软件有个关键差异代码能不能跑最终要靠硬件来验证。AI生成的代码可能出现引脚配置错误、时钟频率不对、时序不匹配之类的问题这些在纯软件项目里根本不存在。所以嵌入式Vibe Coding更适合“生成参考实现人工核对硬件细节”的组合。6.2 嵌入式Vibe Coding与全栈开发的差异在我体验下来两者至少有四个明显差异。第一工具链不同。全栈开发用Cursor、Copilot这类IDE集成工具很舒服但嵌入式开发往往要操作串口工具、交叉编译器、调试器AI对这些工具的集成还不够深。我更多是让AI生成C代码再手动把代码放进交叉编译环境里验证。第二验证周期完全不同。全栈项目改完代码浏览器一刷新就能看到效果验证成本极低嵌入式则要经过编译、烧录、硬件上电、观察现象一次迭代可能好几十分钟。这个差异决定了嵌入式Vibe Coding不能“小步快跑”更要把AI生成的代码当作一次性高质量交付来对待。第三上下文来源不一样。全栈项目的上下文是代码和文档AI很容易读到嵌入式项目的上下文有很大一部分在芯片数据手册和硬件原理图里AI未必能访问。你需要把芯片型号、引脚定义、参考手册的关键参数手动贴给它Prompt会变得更长。第四失败的代价不同。后端代码崩了重启一下就行嵌入式代码如果配置错了寄存器轻则功能异常重则损坏外设甚至整块开发板。所以在嵌入式场景里引入AI生成的代码人工审查的层级要比全栈项目高一个等级。这个方向目前还在比较早期的阶段但我认为它的价值和全栈一样大。嵌入式开发的痛点是硬件知识壁垒高、文档枯燥、样板代码多而Vibe Coding恰好擅长把样板化的部分快速生成出来让人把精力集中在需要深入思考的硬件设计上。7. 常见问题与避坑实战记录7.1 常见问题排查速查表Vibe Coding做全栈项目我整理了一份高频问题的排查清单遇到同类问题时直接对照处理。问题现象常见原因快速排查思路前端调后端接口报 CORS 错误后端未开启跨域检查 Express 是否配置 cors 中间件是否允许了前端的 origin登录后刷新页面就退出token 只存在内存里改成 localStorage/sessionStorage 持久化或使用 cookie 方案AI 生成的页面样式错乱组件类名冲突或全局样式污染确认是否使用了 CSS Modules 或 styled-components统一样式方案接口返回数据前端渲染不出来字段命名不一致检查后端序列化后的字段名与前端 TypeScript 类型定义是否完全一致类型报错但代码逻辑没问题AI 生成时忽略了类型定义让 AI 读取 types 目录后重新生成或手动补 interface数据库查询卡死或超时缺少索引或 N1 查询检查 Prisma 生成的 SQL确认外键字段有索引关联查询是否过度每次对话后上下文越来越混乱对话过长导致注意力分散新开对话贴架构文档和当前任务书让 AI 基于全局重新开工这张表我一直在持续更新每踩一个新坑就补一行。它也变成了我和AI协作时的共同语言出现问题我不需要废话直接把对应行的排查方案丢给AI它会沿着正确的方向去定位。7.2 Vibe Coding全流程的几条铁律最后聊几条我摸索出的铁律每一条都是真金白银换来的教训。第一永远保留AI对话的可回滚版本。我会给每轮重要对话打tag标注“这是文章模块设计定稿”或“这是重构前的版本”。AI对话虽然能持续但你没法保证自己不会把代码改坏保留关键版本就是给自己留后路。第二不要让AI同一轮对话里既做大重构又加新功能。重构和新功能是两个完全不同的任务硬混在一起会让AI的注意力分散两边都做不好。我会按“先重构到满意再开新对话加功能”的顺序推进。第三重要业务逻辑不要用AI生成后直接进主干。我会让AI先写单元测试或Mock数据验证通过再合并。这个习惯可以拦截大量低级but致命的bug尤其在权限和状态流转这类逻辑上。第四AI给出的解决方案不一定是最优解但一定是最常见的解。这在很多场景够用但一旦项目规模变大你会发现常见解在扩展性上跟不上了。这时候别犹豫花时间人工设计一次架构再用AI来执行落地。架构的事人不该偷懒。坦白说用了半年多Vibe Coding我对AI编程的态度已经彻底转变。它没有取代我作为工程师的判断力反而把我从重复代码中解放出来让我有更多精力去思考系统设计、业务边界和性能优化这些真正有价值的问题。工具会继续演进但这种人机协作的底层逻辑我觉得会是未来很长一段时间里开发者的核心工作方式。如果你还没试过找个内部小项目认真跑一遍这篇文章里的流程你可能会对“写代码”这件事产生完全不同的感受。