Vibe Coding 中文入门：从需求到项目实践

Vibe Coding 是一种以自然语言驱动开发的协作方式：你负责说明目标、边界和验收标准，AI 负责阅读项目、生成或修改代码，再由你审查结果并决定下一步。

Vibe Coding 这一说法由 Andrej Karpathy 在 2025 年提出，随后迅速进入开发者的日常讨论。它最有价值的地方并不是让人完全离开代码，而是把时间从重复输入转移到需求判断、方案取舍和结果验证上。

Vibe Coding 到底改变了什么

传统开发通常从语法、API 和文件实现开始。Vibe Coding 则先从结果开始：用户要完成什么动作，项目应当怎样运行，什么情况才算完成。

开发者的工作重点随之发生变化：

把模糊想法整理成可执行任务
给 AI 提供项目上下文和技术约束
审查代码差异，而不是只看最终页面
运行测试并检查异常、权限和安全边界
把有效决策记录下来，供下一次任务复用

因此，Vibe Coding 不是“随便说一句，让 AI 包办一切”。越接近真实项目，人的判断和验收越重要。

为什么现在更容易实践

近年的编码模型已经可以理解多个文件之间的关系，AI 编辑器和终端代理也能搜索代码、修改文件并运行命令。三项能力结合后，一次对话可以覆盖从阅读项目到验证结果的完整过程。

常见工具大致分为三类：

AI 编辑器：适合边查看代码边对话，例如 Cursor、Windsurf
终端编码代理：适合直接在项目目录执行任务，例如 Codex、Claude Code
在线应用生成工具：适合快速制作页面或原型，例如 v0、Bolt、Lovable

第一次尝试不必同时安装很多工具。选择一个能查看文件改动、运行命令并让你确认操作的工具，完成一个小项目后再比较差异。

用 Codex 完成第一个小项目

下面不照搬“生成一个页面”的常见演示，而是做一个更接近真实需求的小任务：创建一个本地任务看板。它足够简单，又能检查交互、数据和异常状态。

先创建一个空目录，在终端进入该目录并启动 Codex。然后发送下面的需求：

请创建一个本地任务看板，使用原生 HTML、CSS 和 JavaScript。

目标用户：需要记录当天任务的个人开发者。
核心功能：新增任务、标记完成、删除任务，并显示未完成数量。
数据要求：使用 localStorage 保存，刷新页面后数据仍然存在。
界面要求：桌面和手机都能使用，空列表时显示明确状态。
约束：不使用外部框架，不加载第三方 CDN，只创建必要文件。
验收：启动本地服务后可以完整操作，控制台没有报错。

开始前先说明准备创建哪些文件；完成后运行检查并汇报结果。

这个描述包含了用户、功能、数据、界面、技术约束和验收方式。它没有指定每一个函数如何写，给 AI 留出了实现空间，但最终结果可以明确判断。

不要急着接受第一次结果

AI 完成后，先查看文件列表和代码差异，再打开页面实际操作。至少检查这些路径：

没有任务时，页面是否自然且可理解
输入空白内容时，是否阻止创建
新增和删除后，未完成数量是否正确
刷新页面后，数据是否仍然存在
手机宽度下，按钮和文字是否重叠
浏览器控制台是否出现错误

如果发现问题，不要只说“效果不好”。把现象、期望和验证方式一起反馈。例如：

在 390px 宽度下，删除按钮挤压了任务标题。
请保持现有视觉风格，把每条任务调整为可换行布局，
确保长标题不会覆盖操作按钮。修改后重新检查移动端宽度。

这样的反馈比单纯要求“优化一下”更容易得到稳定结果。

一套可重复的四步工作流

描述

先说明要解决的问题，再列出必要功能、限制条件和完成标准。对于已有项目，还要告诉 AI 应先阅读哪些文件，以及哪些目录不允许改动。

审查

查看 AI 改了哪些文件，重点理解数据如何进入、处理和保存。遇到看不懂的代码，直接让 AI 逐段解释，不要在不理解的情况下合并。

验证

运行项目已有的语法检查和测试，再手动走一遍关键流程。没有测试的项目，也应该列出最小验收清单，而不是只凭页面“看起来能用”。

交付

确认结果后再提交代码，并记录本次任务的目标、重要决策和验证命令。下一次出现相似需求时，这些记录会成为比临时提示词更有价值的上下文。

提示词不必长，但要完整

一个实用的任务描述通常包含四类信息：

目标：最终要解决什么问题
上下文：现有技术栈、相关文件和当前行为
约束：不能改什么，必须兼容什么
验收：用什么命令或操作判断完成

例如“帮我做登录功能”很难验收。更清楚的写法是：

在现有 PHP 项目中增加管理员登录。
复用 PDO 数据库连接和当前页面样式，不引入新框架。
密码使用 password_hash 和 password_verify，登录后重新生成会话 ID。
连续失败需要限制频率，后台页面对未登录用户不可访问。
完成后运行 PHP 语法检查，并列出手动验证步骤。

具体不等于堆砌术语。只写与结果有关的信息，通常比一段很长但没有验收条件的提示更有效。

审查 AI 代码时看什么

即使项目运行成功，也要快速检查关键风险：

输入是否经过服务端验证和转义
数据库查询是否使用预处理语句
权限检查是否只存在于前端界面
API 密钥和密码是否被写进代码或日志
错误状态是否会泄露敏感信息
新改动是否破坏已有页面和移动端布局
是否产生没有必要的依赖、文件或重复代码

支付、认证、隐私数据和生产数据库操作不适合作为无人审查的自动任务。这些场景可以让 AI 辅助实现，但最终必须由具备相关经验的人确认。

初学者最容易踩的坑

一次要求生成整个产品

需求越多，隐藏依赖越多，定位错误也越困难。先完成一个可以独立验证的功能，再逐步添加数据、后台和部署。

只看结果，不看改动

页面能打开不代表数据处理、安全和错误分支正确。养成查看 Diff 的习惯，至少理解关键函数和数据流。

把敏感信息发给工具

不要把真实 API 密钥、数据库密码或用户数据直接写进提示。使用环境变量和示例占位值，并确认敏感文件不会提交到版本库。

失败后不断重复同一句话

把完整报错、触发步骤、预期行为和已经尝试的方法提供给 AI。可复现的信息越完整，排查越有效。

哪些任务更适合 Vibe Coding

它尤其适合结果容易验证、模式比较明确的工作：

原型和 MVP
管理后台与常规 CRUD
前端页面和可复用组件
数据处理脚本与日常自动化
测试补充、文档整理和代码解释

复杂算法、底层性能优化以及高安全要求系统也可以使用 AI 辅助，但需要更严格的基准测试、代码审查和专业判断。

从一个小闭环开始

学习 Vibe Coding 最有效的方法不是收集更多工具名单，而是完成一次完整闭环：写清需求，让 AI 修改，查看 Diff，运行验证，再根据结果迭代。

当你能稳定说清楚目标、控制改动范围并验证交付结果时，AI 才真正从代码生成器变成可靠的开发协作者。