vibe coding 第一个项目怎么做?从选题到跑通手把手
新手第一次 vibe coding,真正卡住你的从来不是工具,是两件没人教的事:不知道第一个项目做什么,不会把需求说清楚。这篇就专治这两个卡点——给你 5 个现成选题、一份可直接照抄的中文需求模板、一个从头跑到尾的完整示范,再加一份跑错了怎么办的急救清单。
vibe coding 火遍全球,但中文世界很少有人讲清楚它到底是什么、能不能真用。这篇不做第 N 篇「一文讲透」,而是带你真跑一遍:从定义、四代编程谱系,到一次完整的真实演示,再到它到底能做什么、不能做什么、谁适合谁该谨慎,附新手翻车急救和国内工具中文用法。
⏱️ 预计阅读 18 分钟 | 🎯 目标:不做第 N 篇"一文讲透",而是带你真跑一遍,把 vibe coding 是什么、能不能用、适合谁,讲到你能自己下判断。
网上关于 vibe coding 的文章已经够多了,但绝大多数都长一个样:起源故事、定义、工具盘点,看完你还是不知道"这玩意儿我到底能不能用、值不值得学"。这篇换个路子,少讲概念,多带你看它真实跑起来是什么样。
一句话定义:vibe coding(氛围编程)就是你用大白话说要什么,AI 来写代码,你靠"跑起来对不对"验收,而不是自己逐行敲。
它适不适合你,对号入座:
| 你的情况 | vibe coding 对你 | 一句话结论 |
|---|---|---|
| 有想法、不会写代码 | 把"不会编程"这堵墙拆了 | 最该试,从一个小工具起步 |
| 会一点、写得慢 | 效率倍增器 | 值得用,你的判断力是优势 |
| 资深工程师 | 重构/测试/样板的加速器 | 用在成块任务,关键代码自己把关 |
| 要做涉及钱/数据/安全的正式系统 | 能用但不能一把梭 | 谨慎,必须人工审查 |
最该破除的误解:vibe coding 不是"不用懂技术、随便说说就能做出靠谱软件的魔法"。它拆掉的是"写代码"的门槛,但"判断结果好不好"的责任仍然在你身上。这一条贯穿全文。
下面不绕弯子,从"它到底是什么"开始。
先给权威出处,免得你以为是哪个营销号造的词。
vibe coding 由 Andrej Karpathy 在 2025 年初提出。他是 OpenAI 的联合创始人之一、前特斯拉 AI 负责人,深度学习领域公认的权威。他对这种状态的原话是:「完全交给感觉、拥抱指数级进步、甚至忘记代码本身的存在」(fully give in to the vibes, embrace exponentials, and forget that the code even exists)。
翻译成大白话:你不再逐行读写代码,而是用自然语言告诉 AI 你想要什么,AI 来生成、修改、调试,你主要靠"跑起来对不对、感觉对不对"来判断和给反馈。
💡 通俗讲
传统编程像你自己下厨:买菜、切菜、掌勺,每步都得会。vibe coding 像你请了个会做菜的机器人厨师,你说"来碗不太辣的番茄牛腩面",它做,端上来你尝一口说"再咸点、牛腩炖烂点",它再调。你负责说清楚要什么、尝出来对不对,它负责动手。
它为什么 2025 年突然火?因为 AI 模型的能力跨过了一个临界点:从"补全你写到一半的代码"进化到"听懂一句大白话需求,自己读项目、写代码、跑起来验证、按反馈改"。这个能力成熟,第一次让"不会写代码"不再是"做不出软件"的前提,这才是它真正的分量所在。

这是中文网上几乎没人讲清楚的一点,也是新手最容易混的地方:vibe coding、AI 辅助补全、AI Agent 经常被当成一回事,其实它们是一条"AI 主导程度递增"的光谱上的不同位置。
我把它们放一张表里,你一眼看清自己在用哪一代、vibe coding 卡在哪个位置:
| 维度 | ① 传统编程 | ② AI 辅助补全 | ③ vibe coding | ④ agentic 工程 |
|---|---|---|---|---|
| 谁写代码 | 你,逐行 | 你主导,AI 补下一行 | AI 主导,你验收 | AI 自主规划+执行多步 |
| 你的角色 | 工程师 | 工程师(被加速) | 产品经理 + 验收员 | 指挥官 + 审查者 |
| 你要看代码吗 | 必须 | 必须 | 可看可不看(凭感觉) | 抽查关键处 |
| 适合的活 | 任何 | 日常逐行编写 | 原型 / 小工具 / 想法验证 | 复杂多步任务 |
| 新手门槛 | 高 | 高 | 低 | 中(要会判断) |
| 代表 | 纯编辑器 | 补全类插件 | Claude Code / Codex / Cursor | 代理的"自主模式" |
💡 通俗讲
用"开车"打比方就清楚了:传统编程是你自己开手动挡,每个动作都得会;AI 补全是有个副驾帮你提醒"该换挡了";vibe coding 是你坐后排说目的地、车自己开(你偶尔抬头看看路对不对);agentic 是车不仅自己开,还能自己规划"先加油再走高速",但你得盯着别让它开错。
为什么要分清这个? 因为很多新手一听 vibe coding 就以为是第④代那种"全自动、我啥都不管",然后发现"怎么还要我验收、还会出错",就觉得被骗了。其实 vibe coding(第③代)的精髓恰恰是**"放手让 AI 写,但你还在凭感觉把关"**:既不是你自己写(第①②代),也不是完全甩手(第④代理想态)。搞清楚这个位置,你对它的预期就对了。
那新手该停在哪一代? 答案是:直接从第③代(vibe coding)起步,别从第①代慢慢爬。 过去你想做软件,得从第①代"自己逐行写"练起,门槛高到劝退大多数人。现在 AI 把第③代的门槛降到了"会说话就能开始",你完全可以跳过"先苦学语法"的阶段,直接用 vibe coding 做出东西,再在过程中按需回头补一点第①代的基础知识。顺序反过来了:不是"学够了再做",而是"先做起来,边做边补"。 这也是为什么 vibe coding 对零基础的人是历史性的机会,它把那道最高的墙拆了。至于第④代 agentic,等你用熟了第③代、有了判断力,自然会摸到它的门,现在不用着急。

光说定义没用,看一次真实的过程你就懂了。下面用一个具体例子,把一次完整的 vibe coding 从头走到尾,包括中间会出的岔子。
需求:做一个小工具,把一个文件夹里的图片批量缩放到宽度 800 像素。
第 1 步 · 你开口(自然语言描述需求)
你打开一个 AI 编程代理,打字(注意怎么把需求说清楚):
帮我做一个小工具:我有一个文件夹全是图片(jpg 和 png),把它们都缩放到宽度 800 像素、高度按比例自动调整,输出到一个新文件夹,原图不要动。已经小于 800 的就跳过。
第 2 步 · AI 动手
AI 不会只甩给你一段代码让你自己想办法跑。它会:理解需求 → 写出代码 → 可能反问你一句"文件夹路径是什么" → 然后说"做好了,你跑一下试试"。这个过程你一行代码没写。
第 3 步 · 跑起来看结果(关键)
你拿一个测试文件夹跑一遍。这时候,很可能不是一次就完美。比如你打开新文件夹一看:图是缩小了,但原文件夹里的图也被改了,跟你说的"原图不要动"不符。
第 4 步 · 给具体反馈
你不用自己去翻代码找 bug,只要把现象说清楚:
输出文件夹的图确实缩小了,但原文件夹里的图也被改了。我要的是原图保持不动,帮我修一下。
第 5 步 · AI 修好,你再验
AI 定位问题、改代码、让你再跑。这次原图不动了。一个需求确认对了,你的小工具就成了。
第 6 步 · 想加功能?继续说就行
vibe coding 真正爽的地方就在这里:做完基础版,你想加什么,继续用大白话说:
不错。再帮我加一个功能:处理完之后,在新文件夹里生成一个清单文件,记录每张图原来多大、现在多大。
AI 会在现有基础上加,你再跑、再验。注意这里的节奏:一次加一个功能,加完就跑一下确认,再加下一个。 别一口气说"再加十个功能",那是新手翻车的典型方式(后面 § 六 会专门讲)。这种"小步快跑、每步确认"的循环,就是 vibe coding 的核心节奏,记住它比记任何工具操作都重要。
🔥 翔宇判断
很多人看 vibe coding 演示,盯着"AI 写得多牛",其实最该学的是这个一来一回的循环本身:描述 → 跑 → 看 → 反馈 → 再跑。我见过太多人栽在"省掉中间的跑和看",以为 AI 一次就对,结果错了还不知道错在哪。说句实话,vibe coding 的功夫,七分在"会验收、会反馈",三分在工具。工具谁都能装,验收的判断力才是你的护城河。
💡 通俗讲
整个过程像教一个很聪明但需要你点头的助理打扫房间:你说清楚扫哪几间、要不要拖地(说需求)→ 他去扫(生成)→ 你进去看干不干净(验证)→ "这个角落还有灰"(反馈)→ 他补扫(修)。你全程没碰扫把,但你得会说清楚、会验收。这就是 vibe coding 的真实体感,不神秘,但也不是甩手掌柜。
看明白这一遍,你已经超过了一半只看过"定义文章"的人,因为你知道它真实跑起来长什么样、中间会出岔子、出了岔子怎么办。

这一节是负责任的指南必须讲的,因为吹得太满会害了新手。
🔥 翔宇判断
关于边界,我想引一个很有说服力的事实:连提出 vibe coding 这个词的 Karpathy 本人,后来都公开说过 AI 写的代码经常"臃肿、脆弱"(bloaty、brittle),需要人来把关;另一位 AI 领域权威 Andrew Ng 也给过类似的冷静提醒。注意,这些不是 vibe coding 的反对者,恰恰是最懂它的人。 他们的态度很清楚:vibe coding 是强大的工具,但不是免责的魔法。我的判断和他们一致:放手用它提速,但永远别交出"判断结果靠不靠谱"这个责任。
一个简单的分界线:做出来给自己用、出错了代价小的东西,放手 vibe coding;做出来给别人用、出错了有代价的东西,带着审查用。
抽象的边界不好记,给你几个具体的对照:
💡 通俗讲
就像用导航开车:去自家附近熟悉的地方,导航说哪走你哪走,错了掉头就行(放手);走山路、夜路、陌生高速,你得一边用导航一边自己看路况(带审查);而真要送病人去急救,你不会只信导航、还会找最熟路的人带路(别纯靠它)。代价越大,你越要在回路里。

把"能做什么"落到"你该不该用、怎么用"。
flowchart TD
Start{你要做的东西<br/>出错了代价大吗?} -->|不大,自己用的小东西| A[放手 vibe coding<br/>建议起步场景]
Start -->|大,涉及钱/数据/安全| B[可以用 AI 生成<br/>但必须人工审查测试]
A --> C{你判断得出<br/>结果对不对吗?}
C -->|判断得出| D[直接开干]
C -->|完全判断不了| E[先补一点最基础认知<br/>再放手]
B --> F[关键代码自己把关<br/>别一把梭]
中文网上几乎没人系统讲"vibe coding 翻车了怎么办",但这恰恰是新手最需要的。这一节填这个缺口。
| 翻车现场 | 为什么会这样 | 急救做法 |
|---|---|---|
| AI 说"做好了",结果根本没跑对 | "做好了"≠"真的对了" | 每次都自己跑一遍、亲眼看结果 |
| 报错了,一堆看不懂的英文 | 正常现象,不是你笨 | 把完整报错原样复制丢回给 AI,让它解释+修 |
| AI 改了几轮越改越乱 | 上下文被绕进死胡同 | 开个新对话,把需求重新说一遍(这次更小更清楚) |
| 它要删/改你的文件,你慌了 | AI 为完成任务可能动你没料到的东西 | 让它先说"要动哪些文件",确认了再执行;先拿测试文件练手 |
| 一口气堆十个需求,全乱了 | 没有分步验证 | 一个需求 → 跑 → 确认 → 下一个 |
❗ 翔宇提醒:最高频的翻车,其实是"不验证"
在所有翻车里,最常见、也最冤的一种是:AI 说"做好了",新手就当真了,连跑都不跑、结果都不看,直接交付或使用。"AI 说做好了"和"它真的做对了"是两件事。 自己跑一遍、亲眼看结果,花不了两分钟,却能挡掉绝大多数尴尬。把"我是验收员"这个心态摆正,翻车率直接腰斩。
记住一个总原则:卡住时,第一反应是"把问题丢回给 AI",而不是"我是不是不行"。 你正在用的那个 AI,就是你 24 小时在线、不嫌你问题蠢的老师。
大多数 vibe coding 文章是照搬英文的,忽略了中文用户的真实处境。这一节专门补上。
你完全不必翻墙才能做 vibe coding。两条路:
具体哪个工具当下最好用,请以各家官方页面为准。这个领域更新很快,本文不写会过期的版本和价格,只讲不变的方法。
用中文跟 AI 沟通完全没问题,但有几个小技巧能让它更懂你:
两个中文 prompt 的好坏对照,你立刻能感觉到差距:
再来一个:
💡 通俗讲
别因为"编程都是英文的"就发憷。做 vibe coding,你和 AI 的交流语言可以全程是中文,它听得懂你的大白话需求,也能用中文跟你解释。英文好是个小加分项(能看一手官方文档),但绝不是入门门槛。把中文需求说具体,比纠结"要不要学英文"重要一百倍。
讲清概念,绕不开破除几个流传最广的误解。这三个,几乎每个新手都中过招。
真相:它拆掉的是"会写代码"这道门槛,不是"会判断"这道门槛。你不用会写,但你得能看出"结果对不对"。完全不懂、连对错都判断不了,vibe coding 就退化成"盲飞",AI 给什么你信什么,错了也不知道。所以更准确的说法是:入门不用懂,但想走远,得边做边懂一点。
真相:这是把 vibe coding(第③代)和理想中的全自动 Agent(第④代)搞混了。vibe coding 的精髓恰恰是"放手让 AI 写,但你还在回路里凭感觉把关"。你始终是那个验收、反馈、拍板的人。指望翘脚等结果的人,往往一翻车就弃坑,因为他们根本没在回路里,出了问题接不住。
真相:这话对一半。纯靠"凭感觉、不审查"做出来的东西,确实不该直接上正式生产,这点连 Karpathy 都认同。但这不代表 vibe coding 只能做玩具:很多真正有用的个人工具、内部脚本、原型,都是这么做出来的;而要把它推向"正式上台面",方法也清楚:加上人工审查、测试、必要重构。所以不是"vibe coding 做的都是玩具",而是"凭感觉做完就上线的才是玩具"。 区别在于你后面有没有补上把关那一步。
💡 通俗讲
这三个误解其实是一回事的三个面:都低估了"人"在 vibe coding 里的角色。AI 负责动手,但判断、验收、把关这条线始终是你。把这条线握住,vibe coding 是利器;把它丢掉,就成了三个误解里说的样子。
讲讲我自己的看法,不是让你照单全收,给你一个参考坐标。
我的整套工作流里有大量工具和脚本,绝大部分不是我逐行写的,而是用 vibe coding 的方式让 AI 做出来、我来审和调的。所以我对它的态度很明确:值得,而且越早建立这套"用 AI 解决问题"的手感越好。
但我对它的判断也有冷静的一面:
🔥 翔宇判断
如果你问我一句话建议:别再观望了,但也别神化它。 观望的人总在等"更成熟再学",结果错过了最该积累手感的窗口;神化的人以为不用动脑,结果一翻车就弃坑。正确姿势是:今天就去做一个小东西,亲手感受它的强大和它的边界。这篇文章读十遍,不如你自己跑通一个小工具学到的多。
读到这里,你已经知道 vibe coding 是什么、在编程谱系里的位置、真实怎么跑、能力边界在哪、适不适合你。但说一千道一万,vibe coding 是一门"手艺",不是一门"知识"。手艺只能在做的过程里长出来,看再多文章都替代不了你亲手跑通第一个东西的那半小时。所以这一节不给你更多概念,只给你一份能立刻对照、然后动手的轻量清单:
如果大部分都能打勾,下一步很清楚:选一个工具、挑一个小需求,开始动手。
vibe coding 不是"不用懂技术就能做软件的魔法",而是"把写代码的体力活交给 AI,你专注于说清楚要什么、判断结果好不好"的一种新工作方式。它真正的价值,是让有想法的人(不管会不会写代码)都能更快把想法变成能跑的东西;它真正的边界,是"判断责任始终在你"。
这两点想明白了,你就比 90% 刚听说这个词的人更懂 vibe coding 了。但最后我还是那句话:这篇读十遍,不如你自己跑通一个小工具。 概念可以记住,手感只能练出来;你今天动手做的那个小东西,哪怕只是个批量改名工具,也比你收藏一百篇"讲透 vibe coding"的文章更接近真正会用它。去做吧。
外部参考:
每周精选 AI 编程与自动化实战内容,直达你的邮箱