1. 写在前面
2026 年初，我给自己定了一个小目标：用半年时间，把 AI 辅助编程真正用进日常开发里。作为一个普通前端，不追新框架、不搞底层原理，就想看看 vibe coding 到底能不能帮我多交付几个项目。半年过去，我做了 4 个完整项目，踩了不少坑，也攒下一些真实感受，这篇就聊聊这段经历。
2. 什么是 vibe coding
vibe coding 简单说，就是让 AI 承担大部分代码编写工作，开发者主要负责描述需求、审查结果、修正方向。它和传统写代码最大的区别在于：你更像一个产品经理加测试，而不是逐行敲代码的工程师。
对前端来说，这个模式天然友好。因为前端需求直观、反馈快，浏览器里一跑就知道对不对，特别适合让 AI 快速出稿、人工快速验证。
3. 项目一：个人作品集站点
3.1 项目背景
第一个项目选得比较保守，是一个个人作品集站点。目的是先跑通 vibe coding 的完整流程，熟悉工具链和协作方式。
3.2 技术选型
技术栈用了 Vite 加 React，样式用 Tailwind，部署直接扔到 Vercel。选这套组合是因为生态成熟、AI 训练数据多，出错的概率相对低。
3.3 踩坑记录
第一个坑是 AI 生成的响应式布局在移动端经常错位。后来我养成了习惯：每完成一个区块，立刻用浏览器开发者工具切到手机模式看一眼，发现问题马上让 AI 修，而不是攒到最后一起处理。
第二个坑是图片懒加载。AI 给的方案在本地没问题，上线后首屏图片加载很慢。最后是我手动加了 loading 属性才解决。这件事让我意识到，AI 能写代码，但性能优化还是得靠人。
4. 项目二：团队内部工具平台
4.1 项目背景
第二个项目是给团队做的内部工具平台，用来管理日常的测试任务和结果记录。这个项目开始涉及简单的后端逻辑和数据库操作，复杂度比第一个高了不少。
4.2 技术选型
前端还是 React，后端用了 Node.js 加 Express，数据库选了 SQLite。整体架构很简单，但已经是一个完整的前后端分离项目。
4.3 踩坑记录
这个项目最大的教训是：不要让 AI 一口气生成整个页面。一开始我图省事，让 AI 一次生成一个完整的管理页面，结果样式混乱、逻辑耦合严重，改起来比从头写还费劲。
后来我改成按组件拆分，一次只让 AI 写一个表格、一个表单或者一个弹窗，写完立刻集成测试。效率反而高了很多。
另一个问题是数据校验。AI 生成的后端接口基本没有做参数校验，我花了不少时间补这块。建议大家在让 AI 写接口时，明确要求加上输入校验和错误处理。
5. 项目三：数据可视化大屏
5.1 项目背景
第三个项目是一个数据可视化大屏，用于展示业务核心指标。这个项目对视觉效果要求高，交互逻辑也比较复杂，是我半年里挑战最大的一个。
5.2 技术选型
图表库选了 ECharts，前端框架还是 React，数据通过 WebSocket 实时推送。大屏的分辨率适配是个难点，不同屏幕尺寸下都要保持布局正常。
5.3 踩坑记录
ECharts 的配置项非常多，AI 经常生成一些不存在的配置，导致图表渲染异常。我的解决办法是：让 AI 先给出图表配置的 JSON，我人工核对一遍关键字段，再让 AI 接入数据。
WebSocket 的断线重连逻辑也是 AI 容易写漏的地方。上线前我专门让 AI 补了心跳检测和自动重连，又自己手动测试了断网恢复的场景，才算放心。
大屏适配最后是用 rem 加媒体查询组合解决的。AI 一开始只用了固定像素，我让它改成相对单位后，效果好了很多。
6. 项目四：AI 对话助手前端
6.1 项目背景
第四个项目是一个 AI 对话助手的前端界面，对接团队自建的大模型服务。这个项目让我真正体会到 vibe coding 在交互复杂场景下的优势。
6.2 技术选型
前端用了 React 加 TypeScript，消息流式渲染用 Server-Sent Events 实现。状态管理用了 Zustand，比 Redux 轻量很多，AI 也更容易生成正确的代码。
6.3 踩坑记录
流式渲染是最大的坑。AI 生成的代码在消息内容包含换行和代码块时经常渲染错乱。我最后是让 AI 先实现一个简单的 markdown 解析器，再逐步加上代码高亮，分步走才稳定下来。
TypeScript 的类型定义也是重灾区。AI 生成的类型经常和实际数据结构对不上，运行时才报错。后来我要求 AI 先定义好接口类型，再写实现代码，问题少了很多。
这个项目让我意识到，vibe coding 不是完全放手，关键模块的设计和类型约束还是需要人来把关。
7. 半年复盘：我总结的 5 条经验
7.1 需求描述越具体，产出质量越高
给 AI 的需求描述越具体，生成的代码越接近预期。我后来习惯把需求写成包含交互细节的说明，比如按钮点击后的行为、空数据时的展示、加载中的状态，AI 的产出质量明显提升。
7.2 小步快跑，不要一次生成大模块
一次只让 AI 写一个组件或一个功能，写完立刻测试。攒太多一起改，排查问题的成本会成倍增加。
7.3 代码审查不能省
AI 生成的代码必须逐行审查，尤其是涉及数据安全、权限控制和性能优化的部分。我一般重点看三块：输入校验、错误处理、资源释放。
7.4 让 AI 写测试，但别全信
AI 能生成单元测试，但覆盖率和断言质量参差不齐。我会让 AI 补测试，但关键路径的用例一定自己手写。
7.5 保留人工设计的核心能力
架构设计、技术选型、性能优化这些核心能力，AI 暂时替代不了。vibe coding 提升的是编码效率，不是设计能力。
8. 对普通前端的建议
如果你也是普通前端，想尝试 vibe coding，我的建议是：从一个小工具或者个人项目开始，先跑通流程，再逐步应用到工作项目中。
不要害怕 AI 生成的代码有问题，把它当成一个需要 review 的同事，而不是一个全能的写手。保持对代码的掌控感，才能让 AI 真正成为你的生产力工具。
最后想说，vibe coding 不是银弹，但它确实让我在半年里多交付了好几个项目。工具在变，但工程师对质量的责任心不会变。
9. 结语
这半年，我从一个对 AI 编程半信半疑的普通前端，变成了一个把 AI 当成日常协作伙伴的开发者。4 个项目不算多，但每一个都让我对 vibe coding 的理解更深一层。
如果你也在观望，不妨从今天开始，用一个小项目试试水。也许半年后，你也会有自己的故事可以讲。