Amy青梅说实话，我第一次听到 vibe coding 这个词的时候，第一反应是：这不就是把“偷懒写代码”包装成了时髦说法吗？直到我自己花一个晚上，用这种方式把一个原本要磨两天的内部小工具从零推到能跑，才开始意识到之前的判断太草率了。vibe coding 最近在 ai 编程圈子里讨论度很高，它不是你随便说两句话、AI 就变魔术一样交出整个项目的魔法，而是一种全新的开发协作方式：你在旁边掌控大局、观察输出、判断方向，代码本身变成了你和 AI 对话的副产品。
这篇心得我本来只想写给自己当复盘，后来想了想还是整理出来，分享给同样在折腾 AI 编程的朋友。我准备用最直白的大白话聊聊：vibe coding 到底是怎么一回事，工具怎么选，提示词怎么问才不浪费 token，真实项目里会踩到哪些坑，以及它和 spec-driven 到底有什么区别。无论你是有十年经验的老手，还是刚接触编程的小白，只要你打算让 AI 帮你写代码，这篇文章应该都能给你一点参考。
1. 先把“vibe coding”这个词掰开揉碎：它到底是什么，不是什么
1.1 这个词怎么来的
vibe coding 的说法，最出圈的一次是一位做 AI 的技术人公开分享的。原话大意是说，自己写代码已经从“仔细思考、逐行调试”变成了“顺着 vibe 走，看 AI 的建议，接受它，遇到 bug 就整段贴回去，代码本身反而不太去细读”。这个词迅速成了 AI 编程圈子的口号，后来又出现了大量学习资源、技巧贴和争论帖。
但中文互联网上的很多讨论，把它简化成了“用嘴写代码”“躺着赚钱写软件”，这是最大的误解。我见过不少人抱着这种预期来问我要推荐工具，实际用起来发现 AI 生成的代码根本跑不通，转头就骂“都是营销吹出来的”。这种心态从一开始就跑偏了。vibe coding 的 vibe，不是“随意乱来”，而是“把节奏感交给 AI 主导，但方向盘始终在自己手里”。
1.2 与传统编程比，变的到底是什么
先说我的结论：vibe coding 真正改变的不是“写代码”这个动作，而是“把需求变成可用软件”的路径。传统编程的核心动作是“实现”，你要自己设计函数、考虑边界、写测试、打断点调试。vibe coding 里这些工作并没有消失，只是转移成了另外三件事：定义、评审、纠偏。
你把目标描述清楚，AI 负责把骨架填上；你拿到结果后快速判断哪些对、哪些错、方向有没有偏，再把它推回去继续改。我做技术分享时常打一个比方：传统编程像自己开手动挡，发动机转速、离合时机全靠脚感；vibe coding 更像坐在副驾指导一个驾驶水平忽高忽低的司机。你告诉他目的地，提醒他该减速了，让他开错了别硬闯，但真正踩油门的人是他。你的角色从“司机”变成了“领航员”。
这也是为什么同一个工具、同一个模型，在不同人手里效果天差地别。领航员的质量，取决于你的判断力、表达力和对最终结果的掌控力。
1.3 适合做什么，不适合做什么
这种模式非常高效，但高效是有边界的。我自己的经验是：vibe coding 最适合原型验证、内部工具、自动化脚本、数据处理、胶水代码、个人网站这一类任务。这类任务的共同特点是“跑起来就有价值，错了损失可控”，你完全可以让 AI 快速出活，再人工收尾。
它不适合对稳定性、安全性、合规性要求极高的系统，比如支付、银行核心、医疗设备控制。不是说 AI 写不出来，而是出了问题，你不敢让一个“领航员”背锅。所以我的第一盆冷水必须是：vibe coding 用得好的人，往往是本来就懂代码的人。小白拿它入门完全可行，但一定要额外补基础——比如能看懂报错、能分清文件结构、知道哪些操作是危险的。否则你只会把 AI 当成一台高级“抽卡机”，偶尔抽到好东西，大部分时间看运气。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 工具不是万能的，但工具选错一定翻车：从 Cursor 到国产方案的实测对比
2.1 主流工具一张表
先给结论：工具本身不是魔法，真正决定产出质量的是三样东西——模型能力、上下文长度、Agent 的自主程度。市面上主流方案我基本都试过，整理成一张表，都是个人体感，供选型参考：
| 工具 | 一句话点评 | 最适合谁 |
|---|---|---|
| Cursor | Agent 能力全，生态成熟，教程多 | 愿意深入研究 AI 编程、想把它当主力的人 |
| GitHub Copilot | 老牌稳妥，IDE 集成好，补全很顺 | 已经在用 VS Code / JetBrains 生态的团队 |
| Trae | 国内团队做的，中文交互自然，对话式 Builder 模式很契合 vibe coding 节奏 | 刚接触 AI 编程、想要中文原生体验的人 |
| 通义灵码 | 阿里系，开发者后台集成度高 | 本身就在阿里云体系内做开发的人 |
| 文心快码 | 百度系，企业场景适配多 | 企业合规选型时倾向本土方案的团队 |
| MarsCode | 字节系，IDE 插件轻快 | 喜欢轻量、不想迁移全家桶的开发者 |
| CodeGeeX | 智谱出品，对模型理解门槛低 | 对比学习、日常尝鲜的用户 |
特别说明：工具的更新速度非常快，功能可能一个月就大变样，这张表更像“参考出发点”而不是“标准答案”。我建议你选两三个真正上手跑一遍，比看一百篇测评都强。
2.2 我的选型标准
我选主力工具，一般只看四件事。第一，是否支持 Agent 模式，也就是 AI 能不能自己去读文件、跑命令、改多个文件，而不是只在一个对话框里回答问题。第二，上下文长度和记忆质量，对话一长容不容易丢前面的约束。第三，IDE 兼容性和使用习惯，换个工具如果还得换个编辑器，学习成本是很高的。第四，稳定性和成本。
热词里有人反复问“编程 AI 哪个好用”，我统一的回答是：没有最好，只有最适合。我自己用 Cursor 当主力，因为它的 Agent 流程和我的工作方式最匹配；但我有个同事，日常只写脚本和 SQL，他反而觉得轻量插件更顺手。工具决定工作流，而不是越贵越好。
2.3 工具之外：模型、上下文与 Agent 模式的真实差异
同一个工具里可以切换不同模型，最终产出质量差别很大。我实测下来的体感是：长上下文能力强的模型，适合连续改一个大项目；而响应快、指令理解好但细节容易错的模型，适合短任务，比如补全、改注释、做简单重构。
vibe coding 的精髓恰恰是把“长任务”拆成“短轮次”。别指望一个模型连续干活几小时还能保持高质量。一旦发现它开始绕圈，就果断开新会话，把关键信息重新喂一遍，这比硬聊到底效率高得多。热词里反复出现的“AI Skills”，我会在后面专门讲，这里先记住一个原则：模型再强，也要靠人会问、会收、会验证。
3. “提问即编程”：我把 vibe coding 提示词拆成了五条核心技巧
先声明一下：我不太推荐网上那种动辄几百字、层层叠叠的“万能提示词模板”，因为那往往是给 AI 看的表演，不是给你用的。真正好用的提问方式，是有脑子的对话节奏。
3.1 先要方案，再要代码
很多新手一上来就是“帮我写个脚本”，AI 随手给一份通用脚本，结果跟自己的环境完全对不上，于是抱怨 AI 不行。我的习惯是：第一轮只问方案。
“我要做一件事，目标是……，约束是……，你觉得怎么实现？给我两个方案，分别说说优缺点。”让 AI 先把思路讲清楚，你判断方向对不对，再让它动笔。这样做有两个好处：一是避免它一上来就跑偏方向，二是让你对代码结构有基本预期，后面 Review 心里才有底。尤其在 vibe 状态下，方向感很容易丢，先要方案，等于给自己把住了方向盘。
3.2 描述结果，别描述函数
普通问法是这样的：“写一个 Python 函数，输入图片路径，输出压缩后的图片。”这种问法把中间层的实现也完全丢给 AI 去猜了。更好的问法是这样：“把 ./images 目录下的所有 JPG 压缩到 200KB 以下，保持宽高比，输出到 ./compressed，处理完打印每张图片压缩前后的大小。”
你会发现，直接描述业务结果时，AI 会自己决定用哪几个库、怎么处理异常。背后的原理很简单：AI 是基于目标倒推实现的，你给它太多“实现细节”反而容易把方向带偏。你负责 What（要什么结果），它负责 How（具体怎么编码）。反过来说，如果你明确知道某个技术栈更优，也可以直接指定：“用 Go 写一个命令行工具，不要用框架。”这时候它就是你的执行者。
3.3 报错要整段贴回来
这是我最想强调的一条，也是很多人最容易偷懒的一条。有人遇到报错只把最后一行错误粘给 AI，甚至只丢一句“它报错了”。但很多时候，debug 的线索分散在完整堆栈里，前几行才是根因。正确做法是：从出错命令开始，到完整报错结束，全部原样贴回去。如果有上下文，再把相关代码片段附上。
我一般还会加一句：“不要急着给解决方案，先帮我判断这个报错是环境问题、依赖问题还是代码逻辑问题。”这一步能让 AI 收敛答案，而不是在错误的排查方向上胡诌。
3.4 拆小步、勤开新会话
vibe coding 天然倾向于“一次性让 AI 干很多事”，但我踩过几次坑之后发现，任务拆得越小，产出越稳定。一个功能一个会话，一个 bug 一轮对话。如果你跟 AI 连续聊了二十几轮，你会发现它的“记忆”开始漂移，开头说的约束它已经忘了，开始自由发挥。
这时候不要恋战，新建会话，把当前代码路径、目标、已经做完的事、新问题粘进去，让它基于现状继续。我每次收工前会主动让 AI 输出一句“当前项目状态总结”，下次开新会话直接拿这段当开场白，省时省力。
3.5 十个“低级问法 vs 高级问法”对照
为了方便大家直观感受，我做了一个表，都是我自己踩过或用过的真实场景。对比看会非常有体感：
| 场景 | 低级问法（结果容易翻车） | 高级问法（结果可靠很多） |
|---|---|---|
| 转换数据 | 用 Python 把 CSV 转成 JSON | 读取 data/raw.csv，前两行是注释，从第三行开始才是表头；转成数组对象，字段名保留中文，输出到 data/processed.json |
| 写采集脚本 | 写个爬虫抓某网站 | 抓某公开网页的列表页，每页 20 条，翻 5 页，只提取标题、日期、链接字段，输出 CSV，遵守 robots.txt，不模拟登录 |
| 修 bug | 这段代码出错了 | 贴完整报错，说清楚输入是什么、期望输出是什么、实际输出是什么 |
| 加功能 | 给网站加个登录 | 现有验证方式不换，在 user 表加一个 enabled 字段，登录时判断 enabled=1 才放行，不修改已有接口参数 |
| 写测试 | 给项目写点测试 | 给 src/utils.ts 里的 format 函数补 Jest 测试，覆盖空字符串、超长输入、非数字字符三种情况，跑 npm test 并给出结果 |
| 重构 | 把代码优化下 | 保持接口不变，把 utils.ts 里超过 100 行的函数拆小，抽公共方法，改完列出所有改动点 |
看到区别没有？低级问法只是“话题”，高级问法是“需求说明书”。vibe coding 最核心的功夫，就藏在这层翻译能力里。
4. 完整复盘：我用 vibe coding 做照片归档工具的一次真实迭代
4.1 第一轮：一句话需求生成的初版
为了写这篇文章，我重新把家里几千张照片做了一次归档，正好可以当一个完整案例。需求是：把 ./photos 下的 JPG/HEIC 按拍摄时间重命名，格式想要“20240101_153024.jpg”这种，再按 YYYY-MM 分到不同目录，最后生成一个能按月份翻照片的 HTML 相册页。
我把需求描述清楚，AI 在十几秒内给出一个 Python 脚本，用了 PIL 和 exifread 读 EXIF，os 处理文件路径，还自己搭了个 html 模板。第一版结构意外完整：有时间解析、有预览目录、有日志输出。但我没有直接运行完整版本，而是先让它进入“模拟模式”：只打印“将要重命名到 xxx”，不真的改文件。这一步非常关键，后面你会看到为什么。
4.2 第二轮：真实文件里的 EXIF 缺失
模拟运行果然暴露了问题。家里有一批老照片，拍摄时间明明是 2006 年，但 EXIF 读取结果为空，脚本直接抛 KeyError 崩溃。我把完整报错贴给 AI，几秒钟后它给了一个合理策略：EXIF 缺失时回退到文件修改时间，并加一条 warning 提示用户“这些文件的时间不可靠”。
改完再跑，又发现个别 HEIC 文件里的拍摄时间时区不对，导致日期偏移。继续让 AI 补上本地时区处理。这个过程技术含量不高，但它是 vibe coding 最有代表性的循环：跑一下，发现新错误，把上下文喂回去，验证修复，继续跑。熟悉之后你会发现，AI 编程的大部分时间不是“写”代码，而是“驱动”这个循环转起来。
4.3 第三轮：非法字符、中文乱码与“表面完成”
继续往下跑，连续出现三个很典型的“vibe 事故”。
第一，某个文件名里有 Windows 不允许的非法字符，AI 一开始只做了简单替换，导致十几个文件重命名失败。第二，生成 HTML 时没有声明字符集，浏览器打开中文直接乱码。第三，AI 在某个环节自作主张加了一个“智能去重”，把两张相似的照片当成重复文件，差点给我删了。幸好我先让它跑了模拟模式，所有“删除”操作都被拦在预览阶段。
看完这几轮你应该能理解我为什么反复强调：先模拟、先备份、再执行。AI 不会故意害你，但它会在你不注意的地方“自由发挥”，而自由发挥的代价，往往由你来承担。
4.4 收尾：让 AI 给自己补文档和测试
项目跑通后，我让 AI 做了四件事：补 README，写明依赖安装命令和不同系统的注意事项；加一个 --dry-run 参数作为默认行为；给核心的时间解析函数补 3 个边界测试；输出一份“已知问题和限制”清单，比如 HEIC 预览在部分浏览器不支持。
整个过程从零手算，如果手工写大概要一天，我实际用了三个晚上的碎片时间，加上人工复核，大概四五个小时。速度确实快，但这里面每一步都有人在兜底。这件事也直接回应了“从 vibe coding 到 spec-driven”的话题：如果你想长期维护这个工具，光靠一次 vibe 过程是不够的，要把需求、约束、测试固化成文档，那就是 spec 化的开始。
5. 算法很聪明，但代码会骗人：我踩过的四个典型坑
5.1 幻影依赖与不存在的 API
AI 最经典的问题就是“一本正经地胡说八道”，尤其是在依赖和 API 使用上。它可能推荐一个真实存在但已经两年没维护的库，也可能直接生成一个包名写错的 import。我遇到最离谱的一次，它让我安装一个名字听起来很像、实际上并不存在的库，代码里 import 出来的函数半天跟文档对不上，最后查了才知道是模型把记忆里的包名和函数名拼错了。
应对办法很简单：拿到它推荐的第三方库，先自己确认存在性、最新版本是什么、有没有更主流的替代品；代码里不要盲目复用它给的 API，先跑起来再说。越是冷门的库，越要警惕。
5.2 “看起来对但一跑就炸”
概率生成模型的通病是：代码语法全对，逻辑听起来也对，但一跑就炸。炸的位置往往集中在边界条件：空列表、除零、文件不存在、编码错误。这是 vibe coding 与传统开发最大的区别，你真的要把它当新人写的代码来 Review，不能因为“AI 写的”就放松警惕。
我的原则是：AI 写的每段代码第一次运行前，先过一遍关键逻辑；涉及文件删除、写数据库、发网络请求的操作，一律加沙盒或者确认步骤。热词里有人问“AI 编程常见问题”，其实绝大多数都出在这条：太信任输出，不验证边界。
5.3 上下文漂移：聊到后面它忘了开头
上下文漂移是所有长对话 AI 的软肋。项目改了很多轮之后，你在同一个会话里问它“这个项目的技术栈是什么”，它可能给出和开头完全不同的答案。
解决方法是把关键信息外置。项目根目录放一个 CLAUDE.md 或者 AGENTS.md 之类的说明文件，写上项目目标、目录结构、常用命令、核心约束。每次开新会话时让 AI 先读这个文件，比在对话里反复强调强得多。这也是从 vibe 走向工程化的第一小步。
5.4 安全红线：AI 给的命令不要无脑执行
这一点我必须单独说。AI 在环境安装、修复报错时，经常给出形如 curl ... | sh 这类高危命令，或者“直接改权限为 777”这种粗暴方案。
我的建议是：所有 AI 建议的终端命令，先逐词看懂再执行；遇到把下载和执行连在一起的管道命令，一律拒绝，改成先下载后审查。另外，它写的脚本里如果出现硬编码的密钥、外发的网络地址，要特别警惕。vibe coding 不是放弃判断，而是判断的对象变了——从判断“怎么写”变成了判断“该不该这么干”。
6. vibe coding 和 spec-driven 不是选择题，是两条腿
6.1 两者到底差在哪：一张表说清楚
vibe coding 和 spec-driven（规格驱动开发）都是自然语言驱动 AI 干活，但气质完全不同。很多人问我“这俩到底哪个好”，我统一回答：这不是立场问题，是阶段问题。
| 维度 | vibe coding | spec-driven |
|---|---|---|
| 需求来源 | 对话中逐步明确，边聊边长 | 先写成清晰规格，再交给 AI 执行 |
| 迭代方式 | 试错式、演化式，快速验证 | 按规格逐条实现，验收明确 |
| 结果确定性 | 低，适合探索 | 高，适合交付 |
| 代码可维护性 | 看运气，靠人审 | 有规格兜底，更容易长期维护 |
| 适用阶段 | 原型、个人工具、想法验证 | 团队项目、外部交付、生产系统 |
| 典型产出 | 一个能跑的 Demo | 一份需求规格 + 符合规格的代码 |
6.2 我的分阶段策略：先 vibe 探路，再 spec 固化
我在实际项目里喜欢这样组合：接到一个新想法，先用 vibe coding 在几天内把粗糙原型跑出来，验证业务价值和用户体验。一旦确认要做成正式产品，我会花时间把原型的核心逻辑写成规格说明，把技术栈、数据流、接口契约、验收标准固化成文档，然后让 AI 基于规格重新实现或重构。
这个过程看起来是多了一步，但往往能省掉后面几个月的维护成本。说白了：vibe 负责“发现好东西”，spec 负责“把好东西做成可靠的东西”。两者哪条短了都跑不稳。
6.3 spec 化可以从小处做起
很多人听到 spec-driven 就觉得负担重，觉得要先写一厚本文档。我自己不做那么重，只做四件小事：第一，把 vibe 过程中反复确认的关键决策记下来，比如技术栈选型原因、第三方库选择、目录结构约定；第二，用“用户故事 + 验收标准”的格式写需求，而不是写冗长的背景描述；第三，把容易出问题的边界条件单列一节，比如超时、网络失败、并发冲突；第四，让 AI 在开发完成后，对照 spec 做一次自查清单。
这样即便只有三四页纸，也比没有强得多。重要的是“把飘在对话里的假设，落成白纸黑字的契约”。
7. 从“随缘写”到“harness 化”：把 AI Skills 沉淀成可复用资产
7.1 harness 是给 AI 的缰绳
热词里有个短语我很喜欢：从 vibe coding 到 harness × SDD 全栈开发实战。Harness 直译是“挽具”，在 AI 编程语境里，指的是围绕 AI 的外围工程骨架：项目说明文件、提示词模板、Skill 定义、测试脚本、CI 流程、权限限制。
个人 vibe coding 可以靠感觉，但要让 AI 稳定地产出，就必须给这匹“高智商马”套上缰绳。我不建议一开始就上重工程，但至少要有两样东西：一个是项目根目录的说明文件，让 AI 每次开工前知道上下文；另一个是让 AI 每次产出后自检的清单，比如“是否跑过测试”“是否处理了空数组”“是否删除了调试代码”。
7.2 第一个可落地的 Skill：代码审查模板
我理解的“AI Skills”，就是把常用的高质量提示词固化成可复用的技能包。现在不少工具和平台开始支持这类自定义技能，把一段 Markdown 指令作为 Skill 文件，AI 按里面定义的步骤执行。我最早沉淀的 Skill 是代码审查，结构很简单：
markdown复制# Code Review Skill
## 触发条件
用户提供 git diff 或一段待审查代码。
## 执行步骤
1. 先阅读改动的上下文，判断改动意图。
2. 依次检查：安全、性能、异常边界、命名、测试覆盖。
3. 如果发现风险，给出具体行号和可复现的操作。
## 输出格式
- 审查摘要
- 严重问题（阻塞合并）
- 建议改进（不阻塞，按优先级排列）
## 禁止事项
- 不要给泛泛的空话，每条问题必须能落地。
- 不要一次性做大范围重构建议，避免影响原改动。
有了这个 Skill，每次让 AI 做代码审查，产出质量比我随手提问稳定太多。这背后的道理是：把经验从“人的脑子里”搬到了“AI 的执行流程里”。qorder 这类平台做的“编程好用的 AI skills”，本质也是这个思路，只是把常见技能做成了可下载、可分享的包。我建议从自己的高频场景开始积累，不要贪多，先做一个真正顺手的，比囤十个泛泛的要强。
7.3 团队级的 SDD 轻量实践
当个人 Skill 多了以后，自然会产生一个想法：团队一起用。我们团队目前的轻量做法是：每个项目根目录放一个 REQUIREMENTS.md 存放规格和验收标准，再放一个 AGENTS.md 说明项目结构和约定；在 CI 里加一步，让 AI 基于规格做一次差异检查。这样团队里的新人也能用 vibe coding 的方式快速上手老项目，因为 AI 已经把项目上下文读明白了。
这条路走到深处，就是“harness × SDD 全栈开发实践”：以规格为锚点，以 harness 为骨架，以 AI Skill 为执行单元。听起来很高级，实际上就是给 AI 搭一个靠谱的工作环境，然后让它干靠谱的活。
最后分享一个我自己用来衡量 vibe coding 项目成不成的标准吧。每次做完一个东西，我都会问自己三个问题：第一，如果 AI 突然消失了，我能不能基于目前的代码和文档继续维护？第二，代码里有没有我完全看不懂、不敢碰的部分？第三，我有没有重复问 AI 同一个问题三次以上？如果三个答案都是肯定的，说明这个 vibe 还不够成熟，得停下来补工程化功课。vibe coding 很短，短到一句话就可以开始；但想用好它，得把心态放长，把自己从一个“写代码的人”，变成一个“对交付负责的人”。能负责，才能真正享受这种开发方式带来的自由。