起因：一个让我焦虑的数字
前段时间看到一个数据，Google Cloud 的报告说，大厂里超过 41% 的代码现在是 AI 生成的。2023 年这个数字还不到 5%。
再看看 YC 的 W25 批次，四分之一的创业公司，95% 的代码来自 AI。
我当时的第一反应不是兴奋，而是焦虑——如果我还在用 2023 年的方式写代码，是不是已经落后了？
于是我花了两个月时间，从零开始系统学习 Vibe Coding。中间踩了不少坑，也逐渐摸索出了一套可靠的方法。这篇文章就是我的完整复盘。
先搞清楚 Vibe Coding 到底是什么
"Vibe Coding"这个词是 Andrej Karpathy 在 2025 年初提出的。Collins 词典把它选为 2025 年度词汇，这说明它已经不是技术圈的小众概念了。
用最简单的话解释：你告诉 AI 你想要什么，AI 帮你写代码。 你的角色从"一行一行写代码"变成了"引导 AI 写出你想要的代码"。
听起来很美好对吧？但我在实际使用中发现，大部分人对它的理解都有偏差。
第一个偏差：以为完全不用懂代码。 不用懂也能做个原型出来，但凡是要上线给真人用的东西，你必须能读懂 AI 写的代码，知道哪里可能有问题。我后面会讲到一个创业公司因为没做代码审查，上线三天就被攻破关停的故事。
第二个偏差：以为一句话就能搞定一切。 这是 2024 年的幻想。到了 2026 年，业界已经有了共识——"mega prompt 的时代结束了，战略分解的时代来了。"你需要把一个大目标拆成很多小步骤，一步步引导 AI，而不是丢一句"帮我做一个电商网站"就指望出奇迹。
第三个偏差：以为它会取代程序员。 不会取代，但会改变程序员的角色。以前你是翻译者——把产品需求翻译成代码语法。现在你是导演——指挥 AI 按你的意图把代码演出来。导演当然也需要懂镜头语言和剪辑，不然只能拍烂片。
搞清楚这些之后，我开始认真选工具。
工具选择：我走了不少弯路
一开始我犯了一个错误——花太多时间纠结"哪个工具最好"。
后来我发现，2026 年的 AI 编码工具已经分化成了三个完全不同的物种，它们解决的不是同一个问题，没法直接比较。
第一类是 AI 原生 IDE，给有编码经验的人用的。 代表是 Cursor 和 Windsurf。它们本质上是加了 AI 超能力的代码编辑器。Cursor 基于 VS Code 改造，对代码库的理解力是最深的，它的 Composer/Agent 模式可以一次性改多个文件。Windsurf 便宜一点（20/月），它的 Cascade Agent 更主动——不用你一步步指挥，它会自己去找相关上下文然后执行。
第二类是终端 Agent，给重度开发者用的。 代表是 Claude Code。它没有图形界面，完全在终端里运行。第一次用的时候我觉得很别扭——你都看不到代码编辑器，怎么编程？但用了几天之后我理解了它的逻辑：它不是帮你写代码片段，而是作为一个自主软件工程师在工作。你说"给这个应用加上用户认证"，它会自己读你的代码库，找到要改的文件，生成实现，写测试，提交代码。200K 的上下文窗口意味着它能同时理解一整个中型项目。
第三类是浏览器端构建器，给非开发者用的。 代表是 Bolt.new 和 Lovable。你在浏览器里描述你想要什么，它直接给你生成一个可以运行的应用。Bolt 最直观，上手最快。Lovable 生成的 UI 最漂亮——默认就带很好的设计感，而 Bolt 和 Replit 的默认输出看起来就比较"程序员审美"。
我最终的结论是：不要只用一个工具。 我现在的组合是这样的——Lovable 做快速原型验证想法，Cursor 做日常开发和迭代，Claude Code 做架构级的重构或者要改几十个文件的大活。不同工具擅长不同的事，硬要用一个工具打天下只会让自己难受。
但说实话，用什么工具真的没那么重要。我后来意识到一件事，这件事彻底改变了我的效率——
最关键的技能不是选工具，是写提示
这句话在我实际使用几周之后才真正理解：一个好提示在平庸工具中的产出，胜过一个差提示在最强工具中的产出。
一开始我的提示是这样写的：
帮我做一个任务管理应用
你猜 AI 给我什么？一堆泛泛的、教科书式的代码，数据库设计不合理，UI 丑，功能也不是我想要的。垃圾进，垃圾出。
后来我学会了把同一个需求这样写：
我要做一个看板式的任务管理应用。具体要求：
- 三列看板：待办、进行中、已完成
- 用户可以创建项目，每个项目下有多个任务
- 任务有标题、截止日期、优先级（高/中/低）
- 可以拖拽任务在列之间移动
- 技术栈用 Next.js 14 + Tailwind CSS + Supabase
- 暗色主题
但请先不要写代码。先给我：
1. 数据库表设计
2. 页面路由结构
3. 核心组件列表
同样的工具，输出质量天差地别。
在反复实验之后，我总结出了几条提示原则。这些原则不是我自己发明的，而是在社区、文献和实战中反复验证过的。
第一条：给目标，不给实现路径。 AI 经常能找到比你预想更好的方案。与其说"用 useState 管理列表状态"，不如说"我需要一种方式让用户实时过滤这个列表，体验要像 Algolia 一样即时"。让 AI 去想怎么实现。
第二条：复杂任务先让 AI 规划。 这是我最大的教训之一。以前我直接说"把这个页面迁移到 Server Components"，AI 就一顿改，改完到处是 bug。后来我学会了这样写：
我想把这个页面迁移到 Server Components。
第一步：分析当前依赖关系，列出哪些组件用了客户端特性。
第二步：提出迁移计划，哪些先迁哪些后迁。
第三步：获得我确认后，执行第一步迁移。
先规划再执行，AI 的输出质量会上一个台阶。
第三条：一次只做一件事。 不要把整个应用塞进一个提示。"帮我做认证+数据库+看板+拖拽+暗色主题"——这种提示 AI 一定会遗漏关键细节。拆成五个独立的步骤，每做完一步，测试通过后再做下一步。
第四条：设定角色和约束。 "作为一个痴迷性能优化的 Senior React 工程师，重构这个组件。要求：不使用 any 类型，所有 API 请求必须有超时和重试机制。"角色 + 约束，比泛泛的"帮我写好一点"有用太多。
第五条：让 AI 审查自己。 这个技巧是我在一篇安全研究论文里学到的，效果出奇地好。你让 AI 先实现功能，然后在下一条提示里让它切换角色：
现在切换为安全工程师角色。
审查你刚才写的代码，检查路径遍历、SQL 注入、
敏感信息暴露的风险。
如果发现问题，重写加固版本。
2025 年的研究数据显示，这种"自我反思"模式是目前最有效的质量提升手段。
Rules 文件：大多数人不知道的秘密武器
学会写好提示之后，我遇到了一个新问题：每次开新对话，AI 就忘了我项目的所有约定。
我不得不反复告诉它"用 TypeScript strict 模式""组件用命名导出不用默认导出""API 路由放在 app/api/ 下面"……这太烦了。
然后我发现了 Rules 文件，它彻底改变了我的体验。
Rules 文件本质上是一份"项目员工手册"，存在你的代码仓库里，AI 在每次生成代码时都会自动参考。不同工具叫法不一样——Cursor 用 .cursor/rules/ 目录下的 .mdc 文件，Claude Code 用项目根目录的 CLAUDE.md，还有一种新兴的通用格式叫 AGENTS.md。
我现在每个项目第一件事就是写 Rules 文件。内容大概包括这几部分：
项目上下文：告诉 AI 这是什么项目、用什么技术栈、关键的架构决策是什么。
编码规范：命名约定、文件组织方式、状态管理方案、错误处理模式。越具体越好。
安全红线：绝对不能做的事——不能硬编码 API 密钥、不能用 eval()、用户输入必须服务端验证。这些写成 Rules 之后，AI 在生成代码时就会自动遵守，不用你每次都提醒。
通用策略：比如"当你不确定时，思考三种方案，选最佳的并解释理由"。这条规则让 AI 的输出从"随机选一种实现"变成了"有理有据地选最佳实现"。
一个小提醒：网上有很多共享的 Rules 模板（cursor.directory 上有一千多个），但 Cloud Security Alliance 警告过，恶意的 Rules 文件可能会让 AI 在你不知情的情况下生成带后门的代码。所以从外部拿来的模板一定要自己审查。
安全：这是整篇文章最重要的部分
我要讲一个真实故事。
2025 年，一个叫 Enrichlead 的创业公司用 Cursor 写了每一行代码。产品是做销售线索的，界面很漂亮，功能也能跑。他们很快上线了。
上线 72 小时后，用户发现了一个漏洞——在浏览器控制台改一个值，就能免费使用所有付费功能。
为什么？因为 AI 把所有安全逻辑放在了客户端。浏览器里的 JavaScript，用户想改就改。
创始人面对 15000 行他自己看不太懂的代码，完全无力审计和修复。项目直接关停。
这不是孤例。2026 年的研究数据显示，大约 24.7% 的 AI 生成代码存在安全漏洞。快是真的快，但出事也是真的出事。
这段经历让我建立了几条铁律：
认证和支付永远不要 Vibe Code。 用成熟方案——Supabase Auth、NextAuth、Clerk、Auth0。这些东西有专门的安全团队维护，比 AI 随手生成的靠谱一百倍。
AI 输出 = 不受信任的代码。 这是 2026 年的行业共识。不管 AI 写的代码看起来多干净、多优雅，都要过一遍安全审查。至少要跑 Snyk 或 Semgrep 这样的自动化扫描工具。
在基础设施层做兜底。 用 Cloudflare Zero Trust 或 NGINX 在入口做安全控制。这样即使代码层有漏洞，基础设施层还能拦住。
每次 AI 写完安全相关代码，让它自我审查一遍。 前面讲的"角色切换"技巧，在安全场景下尤其重要。
我知道很多人觉得"我就做个小项目，不至于"。但养成好习惯是不需要理由的。等你做大项目的时候，这些习惯会救你的命。
我的真实工作流：从想法到上线
讲了这么多原则，来看看我现在做一个项目的实际流程。
第一步：在纸上想清楚，不碰任何工具。 用户是谁？核心功能是什么？MVP 最少需要哪几个页面？数据怎么流转？我通常花半小时到一小时做这件事。有时候画个简单的线框图，有时候就在笔记本上列要点。
第二步：写 Rules 文件。 打开编辑器，先不写功能代码，而是创建 .cursor/rules/ 目录或 CLAUDE.md，把技术栈、编码规范、安全红线都写进去。这一步大概花 15 分钟，但会让后续所有 AI 生成的代码质量都更高。
第三步：让 AI 先出架构方案。 把需求描述扔给 AI，但明确说"先不要写代码，给我数据库设计、路由结构、组件列表"。看它的方案，提出修改意见，确认后再往下走。
第四步：分模块实现，每完成一个就测试一次。 比如先做数据库和认证，测试通过。再做核心业务逻辑，测试通过。再做 UI，测试通过。每次 commit，保持 Git 历史干净。这是我吃过亏才学会的——如果一口气做完再测试，出问题了根本不知道是哪一步引入的 bug。
第五步：安全审查。 所有功能完成后，让 AI 以安全工程师角色做一次全面审查。然后自己再过一遍认证、数据处理和 API 暴露相关的代码。跑一次 Snyk 扫描。
第六步：部署。 用 Vercel 或者 Cloud Run 一键部署。Vibe Coding 的好处之一是"Vibe Deploying"——部署也变得极简了。
这个流程从想法到上线，一个中等复杂度的 MVP 大概一到两天。以前同样的事情要一到两周。
新手到专家：我建议的学习路径
如果你还没开始，不要试图一步到位。我的建议是分四个阶段来。
第一阶段（前两周）：跑通循环，建立直觉。 用 Bolt.new（它最友好），做一个你不在乎的一次性小项目。目标不是做出好东西，而是体验"提示→生成→迭代"的循环。故意用不同的措辞提示同一个需求，观察输出有什么差异。这个阶段你学到的最重要的东西是：AI 的能力边界在哪里。
第二阶段（第三到四周）：学会结构化。 切换到 Cursor 或 Windsurf。学会配置 Rules 文件，学会用"先规划再执行"的工作流，学会用 @file、@codebase 这些上下文引用。养成每次改动后 commit 的习惯。目标：能在一天内做出一个有认证、有数据库、有 CRUD 的全栈 MVP。
第三阶段（第二到三个月）：驾驭复杂项目。 引入 Claude Code 处理架构级任务。学会组合多个工具。掌握 Agent 模式。在已有的项目上用 Vibe Coding 加速——不只是从零开始，也要能在现有代码库里高效工作。开始关注 AI 的"幻觉代码"和"过度工程"——AI 很喜欢把简单问题复杂化，你得学会识别并纠正。
第四阶段（持续精进）：成为架构编排者。 到了这个阶段，你不再是"用 AI 写代码的人"，而是"指挥 AI 工作的架构师"。你定义系统边界和集成模式，建立安全框架，审查 AI 输出就像审查 junior 工程师的 PR。最关键的能力是：在 AI 解决不了问题的时候，你能用传统方法接手。
一些坦诚的思考
写到最后，我想分享几个在两个月实践中逐渐形成的认识。
Vibe Coding 的甜蜜区非常明确。 原型、内部工具、个人项目、一次性脚本——这些场景下它的效率提升是惊人的。但生产环境的核心系统——认证、支付、合规相关的代码——我仍然选择传统方式。不是因为 AI 不能写，而是因为出错的成本太高。
最大的风险不是代码质量，是技能退化。 我注意到一个现象：连续用 Vibe Coding 两三周后，当我需要手动调试一个 AI 无法解决的 bug 时，我的调试速度明显变慢了。因为那段时间我一直在"描述问题"而不是"理解代码"。所以我现在刻意保持一定比例的手动编码，保持对底层的手感。
这项技能的门槛低但天花板高。 用 Bolt.new 做一个简单应用，半小时就能学会。但要达到能稳定产出生产级代码的水平，需要几个月的刻意练习——而且这个"练习"的核心不是学工具操作，而是提升你对"什么是好架构、好安全实践、好代码组织"的判断力。换句话说，Vibe Coding 放大的是你已有的工程素养，而不是替代它。
这就是我目前的全部心得。Vibe Coding 不是银弹，但它确实是过去几年软件开发领域发生的最大范式转移。无论你决定深度拥抱还是谨慎观望，至少了解它是怎么回事、边界在哪里，这对任何技术人来说都是值得的。
如果你已经在实践了，评论区聊聊你的工作流？特别想知道你们在安全方面有没有发现比"AI 自我审查"更好的方案。
附录：我日常参考的资源
- 社区：r/vibecoding（Reddit，87K+ 成员）——看别人的踩坑记录学得最快
- Rules 模板：cursor.directory（1000+ 项目模板，但一定要自己审查）
- 工具评测：vibecoding.app——提示库、工作流指南、工具横评都有
- 安全专题：CSA 的 Secure Vibe Coding 系列——把 Rules 文件和安全框架讲得最透
- 深度对比：DEV Community 上搜 "Cursor vs Windsurf vs Claude Code"——有很多基于真实项目的实测
