如果你最近刷到过 vibe coding 这个词大概已经看到两种极端说法一边说它让编程门槛归零一边说它是“代码灾难制造机”。我的态度更偏中间Vibe coding 能不能用、好不好用不取决于 AI 模型多聪明而取决于你有没有把“意图”真正握在手里。这篇指南是我过去半年一边用 Cursor、Claude Code 这类工具写真实项目一边从“跟 AI 瞎聊”转型到“给 AI 下需求文档”的完整复盘包括工具安装、提示词设计、一个完整的待办工具从翻车到跑通的过程以及一堆只有踩过坑才知道的细节。适合两类人看一是刚接触 AI 编程、想系统上手的开发者二是已经在用但经常被“AI 乱改代码”搞得头疼的人。1. 先搞清楚你是在“写代码”还是在“吃 AI 的盲盒”1.1 Vibe Coding 到底是个啥Vibe coding 这个词最早来自 Andrej Karpathy 的一次直播意思是你不再逐行手写代码而是用自然语言描述需求AI 生成代码、跑起来、报错后你再把错误丢回去让它修形成一个人机协作的“反馈飞轮”。它并不是“AI 一键生成整个项目”那么偷懒的事本质上是一种把“写代码”变成“描述需求验收结果”的编程范式。这玩意为啥 2025 年突然爆发因为工具链成熟了。以前你只能让 AI 补全一小段函数现在 Cursor、Claude Code、GitHub Copilot 这些工具能在整个项目上下文里工作你让它改一个接口它知道去查调用方、改测试、更新文档。效率提升非常明显我实测一个 2000 行的内部系统让 AI 做“给订单模块加一个导出 Excel 的功能”从需求到跑通只花了 40 分钟换以前手写至少一个下午。但危险也随之而来。由于你不再逐行阅读代码你对代码的“手感”和“掌控感”会快速退化。很多初学者把 vibe coding 理解成“我说一句话AI 给我一个能跑的东西”结果就是不断替 AI 收拾烂摊子。真正能长期用 vibe coding 干活的人都做了同一件事把“盲目对话”升级成“意图掌控”。1.2 盲目对话的三个典型症状我把“盲目对话”总结成三个特征你对照一下自己有没有提示词极度抽象。比如直接说“帮我做个博客系统”“写个商城页面”没有任何技术栈、数据模型、交互边界的要求。AI 只能凭概率猜猜出来的东西大概率是“最平庸的模板”而且十有八九用了你用不上的重型框架。不看生成代码只看运行效果。只要浏览器里点两下没问题就认为任务完成了。可代码里那些隐藏的异常处理、SQL 注入点、内存泄漏浏览器根本不会告诉你。没有版本回退意识。AI 改坏了一个文件你不会说“回退”只会说“帮我把那个功能修回来”于是 AI 又叠了一层补丁代码越来越烂直到某个时刻彻底失控。说难听点这种用法跟“抽卡”没区别生成出来的代码是随机品质欧的时候能用非的时候直接把你整个项目带崩。1.3 意图掌控的三个内核跟盲目对话相反的是“意图掌控”。我自己的实践总结下来只要抓牢三个内核AI 就能从“随机队友”变成“稳定协作者”把口头的想法翻译成可验证的需求描述。你不是在聊天而是在写需求文档。一个需求至少包含输入、处理、输出、约束、验收标准这五部分。AI 不会读心你描述得越精确它生成的东西越接近你要的东西。让每个中间态都是可运行状态。不要让 AI 一次性写 800 行代码然后告诉你“写完了”而是拆成多个小步骤每步都能运行、能测试、能回滚。这样做的好处是出了问题你知道甩锅给哪一块。用反馈闭环而不是重新生成来迭代。当 AI 写错了你的第一反应不是“全部重写”而是告诉它“哪个文件、哪个函数、哪个行为不对、应该怎么改”。这种精确反馈是让 AI 输出质量持续上升的关键。这三件事其实就是传统软件工程里的需求分析、增量交付和变更管理只不过执行者从“你指挥程序员”变成了“你指挥 AI”。工具变了方法论反而更古老了。2. 工具与上手别急着安装先搞懂这些很多人搜“vibe coding 安装”其实是卡在最前面的工具选择上。我不准备把所有工具都列一遍只说我实际用过的、且社区里口碑比较稳的三条路线Cue 这类图形化 AI 编辑器、Claude Code 这类终端级 AI 工具、以及 GitHub Copilot 这类老牌补全插件。2.1 主流工具怎么选、怎么装路线一Cursor适合大多数人上手Cursor 是目前 vibe coding 最主流的入口本质上是一个深度改造过的 VS Code把 AI 对话、代码生成、diff 修改、多文件编辑全部揉进了编辑器里。安装没什么玄学去官网下载对应系统的安装包双击装完登录账号在设置里选好你要用的模型即可。第一次启动如果提示配置模型我建议选择 Claude 系列或 GPT 系列别用太弱的开源小模型写长上下文容易崩。装完之后不要急着开大项目先在编辑器右下角或右侧打开 AI Chat 面板给一个最简单的指令试水比如“用 Python 写一个函数读取 CSV 文件并打印每行数据”确认它能生成然后正确运行这套链路就算通了。路线二Claude Code适合习惯命令行的老手Claude Code 是 Anthropic 出的终端工具你直接跑claude命令在终端里跟 AI 对话它能直接读你当前目录的项目文件、执行命令、改代码、跑测试。安装只需要三步# 1. 确认 Node.js 18 已安装最好用 LTS 版本 node -v # 2. 全局安装 Claude Code npm install -g anthropic-ai/claude-code # 3. 进入项目目录并启动 cd your-project claude首次运行会要求登录授权跟着提示在浏览器里确认一下就行。使用中我个人很推荐一个习惯给项目根目录放一个CLAUDE.md文件把项目的技术栈、目录结构、代码风格、常用命令写进去Claude Code 每次对话开始时都会自动读它。这个文件就是你的“项目宪法”能极大减少 AI“失忆”的概率。路线三GitHub Copilot适合不想离开 VS Code 的人Copilot 大家比较熟装 VS Code 扩展、登录 GitHub 账号、开启 Copilot 功能就行。不过说实话现在的 Copilot 更适合做“行级补全”和“小范围问答”真要做五分钟以上的复杂多文件重构还是 Cursor 或 Claude Code 更顺手。2.2 为什么先做“最小化跑通”而不是一上来接大项目我见过太多人装完工具第一件事就是把公司那个 10 年老项目丢给 AI然后问“帮我重构”。结果当然是被 AI 的胡言乱语气到砸键盘。这不是 AI 不行是认知错位AI 编程工具的强项是“在限定范围内快速产出”不是“在一个巨大混乱的系统里自主决策”。正确做法是先在本地建一个空目录做最小化跑通。这个“最小化”有多小我建议是 50~200 行代码以内的小脚本读文件、处理数据、生成报表。原因有三建立信任感。你亲眼看到 AI 能跑通一个完整小任务后面才敢让它碰真实项目。熟悉工具交互。不同工具对“修改代码”的交互方式差别很大Cursor 的 diff 面板、Claude Code 的补丁执行都要亲自动过才能形成肌肉记忆。形成自己的提示词风格。用最小项目试错成本极低你可以在这里反复测试什么样的描述AI能懂、什么样的它会误解。我自己的习惯是每个新工具到手一定会先在临时目录里让它写一个“输入一个数字 n输出 Fibonacci 前 n 项”的脚本再用三句话让它加上缓存再加一个命令行参数。十几分钟跑完工具的性格摸得一清二楚。3. 掌控意图的核心动作把提示词当“需求文档”不是聊天记录3.1 写清楚“输入、处理、输出”三段式我见过的最差 prompt 是“帮我搞个爬虫”。这种模糊指令能触发的只有 AI 的“猜谜模式”你会得到一堆带有 requests 和 BeautifulSoup 的模板代码但完全不知道爬哪个网站、存到哪里、字段是什么、遇到反爬怎么办。好用的提示词我建议强制自己按这个模板写角色你是一名熟悉 [语言/框架] 的工程师 输入程序启动时需要什么参数或数据文件 处理需要完成哪些逻辑步骤尤其是边界情况和错误处理 输出程序最终输出什么、以什么格式、打印还是写入文件 约束必须用哪些库 / 不能用哪些库 / 代码放哪个文件 / 参数名要求 验收一个具体的例子比如“当输入是 xxx 时输出应该包含 yyy”举个例子我最近让 AI 写一个日志分析脚本实际 prompt 是这么给的你是熟悉 Python 3.11 的工程师。程序从命令行接收一个日志文件路径 读取每一行统计不同 HTTP 状态码200、404、500的出现次数。 输出要求在终端打印按次数从高到低排序每行格式是“状态码 次数”。 约束只能用 Python 标准库不能依赖第三方库文件读写要处理文件不存在的情况 主逻辑写在 main() 里if __name__ __main__ 调用。 验收假设日志里有两行 200、一行 404程序的输出中 200 必须在第一行计数为 2。这种写法信息密度很高AI 很少跑偏。你可能会问写这么啰嗦不比写代码轻松多少啊对vibe coding 的真相就在这里——省的是“手写代码实现细节”的时间省不了“思考需求”的时间。你越是把需求想清楚AI 越能给得准你越懒得想AI 越敢瞎编。3.2 拆任务永远优于“一个 prompt 写完所有”刚入门的人特别喜欢干一件事让 AI“把这个商城系统的用户登录、商品列表、购物车、订单、支付都写出来”。不是我泼冷水这种需求给任何模型都做不好原因有两个上下文窗口有限。几千行代码塞进去生成到后面模型早就忘了前面定义的表结构、变量名和风格约定。错误定位困难。五个模块一起交付只要第一个模块有 bug后面全都要返工。正确做法是像切蛋糕一样拆任务。我的拆法有四个原则按数据流拆从数据模型 → 数据访问 → 业务逻辑 → 接口 → 界面逐层推进。每个任务可独立验证比如“建表脚本跑完后能查出一条测试数据”就算一次验收。每个任务限制产物体量一次新增的代码量建议在 100~300 行多于这个就继续拆。先约定接口再填充实现让 AI 先把函数的签名、参数、返回值列出来你确认没问题后再让它写函数体。用这四条AI 的“翻车率”能下降一个数量级。以前我让 AI 直接写“一个完整商品管理模块”十次有八次要返工现在先让它定义Product类有哪些字段、ProductRepository有哪些方法我再回一句“按这个结构实现”基本一次过。3.3 用“伪代码 输入输出示例”锁死预期有时候你用文字描述逻辑AI 还是会理解偏尤其是“排序”“过滤”“去重”这类业务规则。这时候最有效的武器是伪代码和输入输出示例。举个例子我要让 AI 写一个把“订单列表按地区汇总金额”的函数。如果只说“按地区汇总”AI 可能返回一个 list也可能返回 dict字段名也可能是total_amount也可能是amount_sum。但只要我写清楚输入: [ {region: 华东, amount: 100}, {region: 华南, amount: 200}, {region: 华东, amount: 300} ] 输出: [(华东, 400), (华南, 200)]AI 就不会再猜连排序方式都能准确理解。这个习惯我强烈建议每个人养成凡是涉及数据结构、计算规则、返回值格式一律附上一个最小示例。成本极低带来的确定性极高。另一个小技巧是让 AI“先写思路再写代码”。尤其遇到复杂功能我会加一句“先列出实现方案我确认后再写代码”。这句话能拦住 AI 50% 以上的自作主张因为很多模型在“边写边想”时容易把不成熟的设计直接落成代码。3.4 一次只改一个点让 AI 在“手术”而不是“换头”跟 AI 协作最危险的时刻不是让它“新建一个文件”而是让它“改一个现有文件”。模型经常为了一个小需求把原本好好的代码整体重排最后你 diff 一看改动范围是原来的十倍还无形中引入新 bug。我的规矩是提示词里必须写明“只改哪个文件、哪个函数、哪个行为”。只修改 src/order.py 里的 create_order() 函数 不要改动其他函数和 import 区域。 新增逻辑如果订单金额超过 1000需要把 order.level 字段置为 vip。 现有返回值结构保持不变。这种约束句式配合底层模型对 diff 格式的偏好基本能保证 AI 做“手术式修改”。如果模型非要调整别的地方我会在生成后看 diff把无关改动全部回滚。注意这里说的“回滚”不是重新让 AI“撤回”而是使用编辑器自带的 diff 面板直接手动还原。4. 实操复盘一个“待办 备忘”小工具的完整跑通过程理论说太多容易飘我拿自己最近做的一个内部小工具当案例完整展示从“盲目对话”到“意图掌控”的差别。需求很简单做一个本地 Web 小应用用来记待办事项和随手备忘支持标签筛选。4.1 第一次尝试纯“盲聊”直接翻车我一开始偷懒直接给 Cursor 打了一句话“帮我做一个待办事项和备忘的小工具”。结果它给我生成了一整个 React Express MongoDB 的项目装了十几个 npm 包前端页面花里胡哨打开之后是好看但是我本地根本没装 MongoDB连npm install都跑了好几分钟数据库一连接就报错。我让 AI 修它又告诉我“需要先启动 MongoDB 服务”我哪来的 MongoDB这次翻车的根子不在 AI在于我的 prompt 里缺了三样东西技术栈偏好、使用场景、部署边界。我就是典型的“盲目对话”把 AI 当成了全能架构师而它只会按概率给一个“最像样的方案”。4.2 重新定义意图把需求文档拆成四步第二次我冷静下来重新写了一份需求说明然后决定分四步让 AI 实现。技术选型我用 Python 3.11 Flask 2.3 SQLite原因是依赖少、不用额外起数据库服务、单文件就能跑符合“内部小工具”的定位。四步拆分建数据库三个表todos、notes、tags以及多对多关联表。写后端 API支持待办的增删改查、标签筛选、备忘的增删改查。写前端页面一个朴素但能用的单页 HTML。联调测试跑通“添加待办 → 打标签 → 按标签筛选”的完整链路。每一步我都要求 AI 先给我实现方案我再决定是否落地。比如第一步我的 prompt 是这么写的你是熟悉 Python 和 SQLite 的工程师。 请设计 4 张表的建表语句 todos(id, title, status, created_at)、notes(id, content, created_at)、 tags(id, name)、todo_tags(todo_id, tag_id)。 要求字段类型合理加上必要的索引。 只用 sqlite3 标准库不要用 ORM。 先列出每张表的字段说明然后给我 db.py 的完整代码代码里包含 create_tables() 函数。这一步 AI 输出得很准建表语句、字段注释、主键外键都符合预期。我把db.py保存下来跑了一下没有报错然后让它进入第二步。4.3 增量迭代每跑通一段才允许 AI 写下一段第二步写 API 时我加了更多“约束条件”基于现有的 db.py 继续开发不要重建数据库。 新建一个 app.py实现以下接口 POST /api/todos 创建待办接收 JSON {title: xxx, tags: [工作]} GET /api/todos?tag工作 获取待办列表支持按标签筛选 PATCH /api/todos/id 更新待办状态 DELETE /api/todos/id 删除待办 同样只用 Flask 和 sqlite3。每个接口都返回 JSON。 注意必填参数缺失时返回 400 和中文错误提示。这次它的产出明显比第一次“听话”接口路径、请求方式、返回结构都按我写的来。我逐条用curl测了接口有一个问题筛选标签时它用了子查询逻辑虽然对但参数拼接有一个地方用了 f-string存在注入风险。我在反馈里明确了问题app.py 里 GET /api/todos 的 tag 参数使用了字符串拼接改成参数化查询。 只改这一处其他接口不要动。AI 很快修掉了。整个过程里我没有让它重写任何文件都是“指哪打哪”所以代码始终在我的理解范围内。4.4 前端联调用“验收例子”而不是“给几张页面”到第三步写前端我不擅长设计所以我只给了功能验收点写一个 index.html使用原生 HTML/CSS/JavaScript不要用前端框架。 页面包含 - 输入框“待办标题”和“标签”点击“添加”后调用 POST /api/todos - 待办列表展示 title、status、tags每个待办有“完成”和“删除”按钮 - 列表上方有标签筛选框点击某个标签后只显示对应待办 验收例子添加“写周报 #工作”再添加“买咖啡 #生活” 点击“工作”标签页面上只显示“写周报”。给验收例子比说一万句“要有好的交互体验”都管用。AI 唯一没做好的地方是它把自己的fetch请求 URL 写成了http://localhost:5000/api/todos虽然本地能跑但我在反馈里告诉它“改成相对路径 /api/todos这样换端口不用改代码”它一次就改对。最后跑联调测试我用了一个笨但有效的方法手动按验收例子走一遍然后在浏览器控制台看network请求。全部通过后我让 AI 补了一个README.md把启动命令、依赖安装、默认端口写清楚。整个项目最终结构只有四个文件my-todo-app/ ├── db.py # 数据库建表和连接 ├── app.py # Flask 后端与 API ├── index.html # 前端单页 └── README.md # 使用说明这个项目的完整耗时大概是三个小时其中一半时间花在我想需求和写验收例子上真正跟 AI 来回改代码的时间并不多。跟我第一次“盲聊”的时间差不多但这次我有把握说每一行代码我都能解释它为什么存在。5. 常见翻车现场与排查技巧实录不管你是新手还是老手用 vibe coding 一定会遇到下面几类典型问题。这里我把踩过坑后的解题思路按场景列出来希望能帮你少走弯路。5.1 AI 反复报同一个错误像卡在死循环这是一个非常经典的场景你让 AI 修 bug它改完一跑报错跟之前一模一样于是你再让它修它又改一遍还是同样报错。如果重复三轮以上还在原地转圈说明问题不在代码而在你和 AI 的沟通方式。我的解法是“截断循环降低上下文干扰”。先不要再让它继续改了而是让它解释当前报错的根源并且给出两个以上可选方案。你可能会发现AI 其实没真正看清日志它只是在根据“错误大类的概率分布”猜测。另外一个很有效的动作是删除上下文新建对话把当前代码的关键文件和报错信息贴进去重新描述一次问题。很多“循环修不好”其实是因为之前对话里积累了太多互相矛盾的指令导致模型越修越糊涂。重置上下文永远是一个被低估的灵丹妙药。5.2 大约改到一半AI 忘了项目的背景约定AI 的上下文窗口是有限的这也是为什么要写项目级说明文件。当它开始“忘事”——比如忘记了你全程使用 SQLite、忘掉了已定义的函数名、或重复定义了同名函数——大概率是上下文被填满了。我建议项目根目录放两个文件CLAUDE.md或AGENTS.md写项目技术栈、目录结构、命名规范、常用命令。Claude Code 会自动读取Cursor 也可以在上文问它之前贴进去。THOUGHT.md写当前迭代的目标、已完成事项、待办事项、最近几次变更摘要。每次阶段性完成后让 AI 帮你更新这个文件相当于给 AI 一个“项目记忆外挂”。有了这两个文件哪怕对话上下文清空了新会话也可以靠这两个文件迅速“续命”。我自己实测这样操作可以让中大型项目的 AI 协作稳定性提高非常多。5.3 幻觉 API、幻觉依赖AI 写出了不存在的函数AI 最让人头疼的问题之一就是“一本正经地胡说八道”。尤其是一些更新快的框架模型训练数据里根本没有它会根据相近框架的写法编造 API。你按它写的调用一跑就AttributeError。我的应对原则有三条只要业务允许优先标准库和稳定版本。比如文件处理、JSON 操作、SQLite全部用标准库AI 对这些库的知识非常扎实很少出错。必须用第三方库时要求 AI 给出版本并解释原理。我会在对话里加一句“你用到哪些第三方库先说明作用并在注释里写清楚安装命令”。这不是废话而是强制 AI 在说“我要用某个库”之前自己校验一遍知识。报错后别让它盲目修复让它先查“这个 API 在当前版本里的定义”。如果它还是编就让它只写“伪代码级别的实现思路”你自己看一眼再决定要不要落地。5.4 安全和数据问题AI 不会替你把关很多人会觉得“AI 都这么聪明了肯定能帮我写出安全代码”这是很危险的误解。AI 在生成“能跑”的代码和支持生成“安全”的代码之间优先性永远是前者。我常见到的几个坑位SQL 拼接导致注入、敏感配置直接写在代码里、缺少访问控制接口、直接把用户输入拼进 HTML。解决方法是建立“安全审查清单”每次 AI 完成一段代码后你至少要核对三件事所有数据库操作是否用了参数化查询有没有把密码、密钥、Token 硬编码进源码对外暴露的接口是否做了必要的输入校验和权限判断。如果你完全不具备这些判断能力我建议先把“让 AI 生成代码”的项目限定在本地工具、学习项目、无敏感数据的场景不要直接拿去做生产环境。最后我把实战中总结出的高频问题做成了一张表方便你快速自查症状可能原因解法生成代码用了没装好的依赖提示词没限制技术栈明确写“只用标准库”或“只使用 xxx 已安装版本”改一处功能牵连到其他文件缺少修改边界说明要求“只改某个文件的某个函数”并检查 diff同一个 bug 修三次都没好上下文信息混乱开新对话精简贴入相关文件和报错新功能与旧代码风格不一致项目风格说明缺失建CLAUDE.md写明变量命名、注释语言、模块结构AI 输出不存在的 API训练数据里的旧用法让它先写出“这个 API 在当前版本的文档”再去核对数据库出现脏数据缺少约束和事务处理让它补充唯一约束、外键、事务 begin/commit功能都对但性能极差没有性能验收标准给出数据量级要求“10 万行数据下 500ms 内完成”写在最后一件事让我彻底改变对 vibe coding 的认知这篇文章快要写完的时候我说一个自己记忆最深的细节。几个月前我让 AI 写了一个“批量重命名文件”的小工具需求很简单很清晰一次就写好了。我特别得意觉得自己终于驾驭了 vibe coding。结果第二天我不小心在终端里把路径参数传反了工具开始递归改名我手忙脚乱去CtrlC但已经有一批文件名被改得乱七八糟。当时我第一反应是怪自己手滑但后来才想明白AI 帮我写代码的时候我在“意图”上漏了一条最重要的验收标准——“目标路径不存在时必须中止绝不自动创建目录或递归修改”。我把它当成理所当然的常识但对 AI 来说它只是一条“你没有交代的规则”。这件事让我彻底意识到vibe coding 的本质不是“把代码交给 AI”而是“把决策权留在自己手里”。AI 能替代的是“把需求翻译成代码”的翻译工作替代不了的是“定义需求和验收标准”的思考工作。你越是清楚地知道一个程序应该“为什么这么做”“在什么条件下禁止做什么”AI 就越能成为你的放大器你越是想把思考也外包给 AI它就越会用华丽的错误代码回报你。所以我的最终建议只有一个不要追求“让 AI 一次写完整个项目”而是反复练习“把一个模糊想法拆成可验证的小需求”。这个能力一旦建立以后不管技术栈怎么变、新工具怎么出你都能快速上手且不翻车。Vibe coding 的门槛从来不是安装一个工具而是学会把自己的大脑变成一台需求分析机。
