Vibe Coding 实战：我用AI写了一个完整项目，聊聊真实体验和踩过的坑

前言

说实话，半年前听到 “Vibe Coding” 这个词的时候，我第一反应是又一个概念炒作。不就是用 ChatGPT 写代码嘛，换个名字就成新范式了？

但真正上手用了一个月之后，我被真香打脸了。

事情是这样的：我有个外包朋友，接了个内部管理系统的需求。工期紧，预算低，前端后端数据库全要自己搞。按以前的节奏，这种项目少说也得干两个月。结果他三周交付了，还带单元测试。我问他怎么做到的，他说：“我现在写代码，基本上就是跟 AI 对话。”

这句话让我认真了。我决定亲自试试，用 Vibe Coding 的方式从零做一个真实项目，看看这东西到底是噱头还是真家伙。

什么是 Vibe Coding？

先给不了解的朋友科普一下。Vibe Coding 这个概念最早是 Andrej Karpathy（前特斯拉 AI 总监、OpenAI 联合创始人）在 2025 年初提出来的。他的原话大概意思是：

你不再需要完全理解每一行代码。你描述你想要什么，AI 生成代码，你看一眼大概对，就直接用。出了问题再把错误信息丢给 AI 修。整个过程就是一种 “vibe”，跟着感觉走。

说白了，就是把编程从"手写"变成了"对话"。你不再是码农，更像是产品经理兼技术总监——负责描述需求、审核方案、把关质量。

但这里有个误区：Vibe Coding 不是不写代码，是换了一种方式写代码。 你依然需要理解架构、懂基本原理、能判断代码质量。只不过，你不再从零敲每一行了。

我的实战项目：团队任务管理工具

我选的项目是一个团队任务管理工具，核心功能包括：

• 用户注册登录（JWT 认证）
• 项目和任务的 CRUD
• 任务状态流转（待办 → 进行中 → 已完成）
• 团队成员管理
• 数据看板（图表统计）

技术栈选的是：前端 React + Ant Design，后端 Node.js + Express，数据库 PostgreSQL。选这套纯粹是因为生态成熟，AI 训练数据多，生成质量相对靠谱。

第一天：搭脚手架

我打开 Cursor（一个基于 VS Code 的 AI 编程 IDE），新建了一个空文件夹，然后直接在 AI 对话框里输入：

帮我创建一个 React + Node.js 的全栈项目，前端用 Vite + Ant Design，后端用 Express + PostgreSQL，要有 JWT 认证，目录结构要清晰，把 package.json 和基础配置都搞好。

大概 30 秒后，AI 给我生成了一整套项目结构。我扫了一眼，目录组织还算合理，依赖版本也比较新。直接 npm install 跑起来，居然一次成功。

这里我学到了第一个经验：描述越具体，AI 给的结果越好。 如果你只说"帮我建个网站"，它可能给你整出个 jQuery 时代的玩意儿。但如果你明确技术栈、框架版本、功能要求，它给的东西质量会高很多。

第二到第三天：核心功能开发

这两天是我体验最爽的阶段。基本上就是不停地跟 AI 对话：

“帮我写一个用户注册登录的接口，密码用 bcrypt 加密，返回 JWT token。”

“在前端写一个登录页面，用 Ant Design 的 Form 组件，提交后把 token 存到 localStorage。”

“写一个任务列表页面，支持按状态筛选，用 Table 组件，要有分页。”

每个需求大概 1-2 分钟就能得到完整实现。我做的事情主要是：

1. 读代码，理解 AI 写了什么
2. 检查有没有明显问题（安全漏洞、逻辑错误）
3. 复制粘贴，跑起来试试
4. 有问题就把报错信息丢回去让 AI 修

但到了第三天晚上，我踩了第一个大坑。

踩坑实录

坑一：数据库设计不一致

我在不同对话窗口里分别让 AI 设计了用户表、项目表和任务表。结果到了联调的时候发现，任务表里的 assignee_id 字段类型是 VARCHAR，而用户表的 id 是 UUID。外键约束直接报错。

这事儿怪我。AI 在不同对话上下文里不知道彼此的设计决策。教训是：涉及数据库设计，一定要在同一个对话里完成，或者把现有的 schema 作为上下文喂给 AI。

坑二：AI 会"自信地犯错"

有次我让 AI 写一个 PostgreSQL 的分页查询，它给我生成了：

SELECT * FROM tasks ORDER BY created_at LIMIT 20 OFFSET 0;

看起来没问题对吧？但当数据量到了 10 万条之后，OFFSET 分页的性能急剧下降。每次翻页，数据库都要扫描前面所有行。这个问题在小数据量的时候完全暴露不出来。

后来我自己改成了基于游标的分页：

SELECT * FROM tasks WHERE created_at < $cursor ORDER BY created_at DESC LIMIT 20;

教训：AI 给的代码能跑，但不一定是最优解。 你需要有判断力，知道哪些场景需要特别注意性能。

坑三：安全意识需要自己把关

我检查 AI 生成的后端代码时，发现了两个安全问题：

1. SQL 注入风险：某个查询接口直接拼接了用户输入到 SQL 语句里。虽然大部分时候 AI 会用参数化查询，但偶尔会偷懒。
2. CORS 配置过于宽松：直接设置成了 Access-Control-Allow-Origin: * ，在生产环境这是个大忌。

这两个问题如果上线了，后果不堪设想。AI 不会主动帮你做安全审计，这个责任永远在你身上。

那些让我惊喜的瞬间

虽然踩了不少坑，但 Vibe Coding 给我带来的效率提升是实打实的。

惊喜一：单元测试不再痛苦

以前写单元测试是我最头疼的事情，总是能拖就拖。但现在，我只需要对 AI 说：“帮我给这个接口写单元测试，要覆盖正常情况和边界情况。” 它就能生成一套还算完整的测试用例。虽然不是 100% 覆盖，但比我自己写的测试强多了。

惊喜二：调试效率飞升

以前遇到 bug，我得自己看日志、打断点、一步一步排查。现在我把错误信息直接丢给 AI，它能快速定位问题原因，甚至直接给出修复方案。特别是那种配置类的问题（Webpack、TypeScript 类型报错），AI 解决起来比我自己查 Stack Overflow 快 10 倍。

惊喜三：学习新技术的门槛降低了

项目里有个需求是做数据可视化图表。我以前没怎么用过 ECharts，但跟 AI 对话了 20 分钟，就搞定了一个包含折线图、饼图、柱状图的数据看板。AI 不仅给我写了代码，还解释了每个配置项的作用。这比我去看官方文档高效得多。

一个月后的项目成果

经过大约 20 个工作日（每天 3-4 小时）的开发，项目基本成型了：

• 前端：8 个主要页面，包括登录、注册、项目管理、任务看板、成员管理、数据统计等
• 后端：15 个 RESTful API 接口，完整的认证授权体系
• 数据库：5 张核心表，有索引优化
• 测试：后端接口覆盖率约 70%
• 部署：Docker Compose 一键部署

如果按传统的手写代码方式，这个工作量我估计需要 6-8 周。用 Vibe Coding 的方式，我只用了 3 周。效率提升了大约 2-3 倍。

但这个效率提升有个前提：我有 5 年以上的开发经验。 我能看懂 AI 生成的每一行代码，能判断哪些地方有问题，知道什么时候该手动干预。如果你是完全的新手，效率提升可能没这么明显，甚至可能被 AI 的错误代码带到沟里去。

几条实战建议

经过这一个月的实践，我总结了几条经验，分享给大家：

1. 先设计，再生成

不要上来就让 AI 写代码。先自己想清楚架构设计、数据模型、接口规范。把这些作为上下文给 AI，生成的代码质量会高很多。

2. 保持对话上下文的连续性

AI 的记忆力有限。涉及关联性强的功能，尽量在同一个对话里完成。如果对话太长了，就把关键信息（数据库 schema、接口定义）总结一下，在新对话里作为上下文提供。

3. 每次生成后都要 Review

不要盲目信任 AI 生成的代码。至少要过一遍，检查：

• 有没有安全问题（SQL 注入、XSS、CORS）
• 错误处理是否完善
• 性能是否有明显问题
• 代码风格是否统一

4. 善用 AI 做那些你不想做的事

单元测试、文档注释、类型定义、错误处理——这些重要但枯燥的事情，交给 AI 做最合适。把省下来的时间花在架构设计和业务逻辑上。

5. 保留自己的技术判断力

Vibe Coding 的核心不是让 AI 替代你思考，而是让你从重复劳动中解放出来。如果你连 AI 给的代码对不对都判断不了，那还是先打好基础再说。

写在最后

Vibe Coding 到底是不是编程的未来？我觉得答案是：它是编程方式的一种进化，但不是替代。

就像自动挡汽车没有让驾驶消失，Vibe Coding 也不会让编程消失。它降低的是执行层面的门槛，但设计层面的思考、架构层面的决策、安全层面的把关——这些依然需要人来完成。

如果你是有经验的开发者，我强烈建议你试试。不是为了赶时髦，而是它真的能让你把时间花在更有价值的事情上。

如果你是新手，也可以尝试，但记住：AI 是你的助手，不是你的拐杖。 先理解原理，再用 AI 提速，这个顺序不能反。

说真的，写完这个项目，我已经回不去纯手写代码的日子了。不是因为我不会写了，而是我找到了更高效的方式。这大概就是所谓的 “vibe” 吧——跟上节奏，顺势而为。