Vibe Coding一年半实战心得：从高效工作流到边界与坑

过去一年半里，我写代码的方式和我之前十几年的经验完全不一样了。熟练了 Vibe Coding 之后，我甚至偶尔会忘了某个函数的具体语法，因为我知道只要把自己的意图讲清楚，AI 编程助手能把代码还给我，而且通常还附带注释和测试。所谓 Vibe Coding，简单来说就是顺着氛围写代码：你负责描述“要什么”，AI 负责生成“怎么写”，你再负责验收“对不对”。它不是偷懒，反而是把精力从敲键盘转向了思考、拆解和审查。这一年半里我用它做了不少内部工具、数据清洗脚本和原型系统，踩过很多坑，也找到了一套相对稳定的工作流。这篇文章就是想把这段经历里最真实的东西写出来：哪些做法是有效的，哪些坑是新手必踩的，以及你至少得具备什么底子才能不翻车。

1. 先说结论：Vibe Coding 到底是在“划水”还是真干活

1.1 我理解的 Vibe Coding：意图优先，代码其次

很多第一次听说 Vibe Coding 的人，第一反应是“这不就是让 AI 写代码、我什么都不用管吗”。我一开始也这么以为，但实际用下来发现完全不是。Vibe Coding 的核心不是“放弃思考”，而是把思考的重心从“怎么写”转移到了“写什么、为什么写、怎么验证”。

用个不那么技术的话来说，传统编程像是你亲自下场砌墙，每一块砖都有自己的位置，你得时刻盯着砂浆和水平仪。而 Vibe Coding 更像是你当包工头，你把图纸和要求讲清楚，AI 是那个手脚麻利的施工队，你的主要任务是盯住关键节点，及时喊停或者要求返工。如果你连图纸都不想画，也不知道墙砌歪了是什么样子，那施工队造出来的房子大概率是没法住的。

所以我的结论很明确：Vibe Coding 是可以真干活的，但它对你的判断力要求其实更高了。你要能快速读懂 AI 生成的代码，判断它对不对、哪里有隐患、和现有系统能否兼容。这就像自动驾驶，虽然不用一直握着方向盘，但你依然要观察路况，随时准备接管。

1.2 一年半下来，我的工作模式变化

如果按时间线来回顾，我大概经历了三个阶段。

第一个阶段是新鲜期，大概前三个月。那时候我主要让 AI 帮我处理一些单点问题，比如写一段正则表达式、生成一条复杂的 SQL、把一坨数据从 CSV 转成 JSON。这个阶段本质上还是“高级自动补全”，AI 输出一小段代码，我看一眼就贴进去。效率提升有限，但已经能感受到 AI 对语法的熟练程度远超记忆。

第二个阶段是模块期，从第四个月到第九个月左右。我开始让 AI 承担一个相对完整的模块，比如实现一个带缓存的数据读取层、写一套完整的命令行参数解析器。这时候我才真正意识到，提示词的颗粒度有多重要。如果我说“帮我写一个数据读取层”，AI 会给我一个天马行空的抽象设计；但如果我说清楚数据结构、文件格式、缓存策略、异常处理要求，它产出的代码基本可以直接用。

第三个阶段是伙伴期，大概一年以后。我开始把 AI 当成一个真正的结对编程伙伴。我们的对话流程变成了：我给出需求，AI 先出方案，我来评审方案，AI 写测试，再写实现，然后我跑测试、review 代码、让 AI 修问题。这个流程稳定之后，我做一个中等规模小工具的整体时间大概缩短到了原来的三分之一，但这里必须说清楚：省下的是打字和查文档的时间，思考和验收的时间一点都没少。

我身边也有朋友尝试 Vibe Coding 失败了，原因高度一致：他们拿它处理完全不熟悉、也不打算理解的领域，代码能跑起来，但一出问题就完全懵了。所以我个人对 Vibe Coding 的态度是：它是高杠杆工具，但不适合零基础的人直接拿来作为唯一学习路径。

2. 开始 Vibe Coding 之前，建议先想清楚的事

2.1 什么样的项目适合 Vibe Coding

这一年半里我见过特别多“什么项目都扔给 AI”然后翻车的案例，所以我觉得有必要先给 Vibe Coding 画个圈。

非常适合的场景包括：一次性脚本、数据清洗和格式转换、内部管理工具、CRUD 接口脚手架、原型验证、自动化测试用例、文档生成、简单的爬虫。这些任务的共同特点是：逻辑相对标准、错误影响可控、有测试能兜底、出问题方便回滚。用 Vibe Coding 去处理它们，性价比极高，AI 生成的代码通常已经涵盖了大部分边界情况，你只需要补几个它想不到的场景。

不太适合直接交给 AI 放飞自我的场景包括：涉及到密钥管理和加密逻辑的代码、金融计算、实时控制系统、数据迁移脚本（不是不能做，而是要极其谨慎）、复杂算法优化、以及你完全不了解的历史遗留系统。这些地方不是不能用 AI，而是不能“Vibe”。意思就是你不能让 AI 在没有约束的情况下自己发挥，必须把每一步都拆得很细，甚至要求它先写设计说明再给代码。

判断一个任务适不适合 Vibe Coding，我常用一个很简单的标准：如果这段代码出错，损失大吗？能回滚吗？有测试能在上线前发现吗？如果三个答案都令人安心，那基本就可以放心交给 AI。另外还有一个信号：如果你自己已经能手工实现这个功能，只是嫌麻烦，那 Vibe Coding 会让你爽到飞起；如果你完全不会写、也看不懂，那 Vibe Coding 只会让你获得一份定时炸弹。

2.2 你需要具备的基本功底

这是我最想强调的一点。Vibe Coding 的入场门槛看起来很低——你只要有个能聊天的 AI 助手，会提需求就完事。但真实情况是：代码生成只是起点，对代码的理解才是你用得好不好的分水岭。

你需要能读懂 AI 生成的代码，至少能判断它思路的大方向对不对。你不一定知道每种标准库的每个参数，但要能看出这里明明在读取文件，为什么突然调用了网络请求。你需要熟悉基础的编程概念：变量、函数、类、条件、循环、数组、字典、文件的读写，这些是基本的“词汇量”。你还需要了解你所处平台的运行机制，比如你写的是命令行工具，那你要知道退出码是什么、标准输入输出是怎么流转的；你写的是 Web 服务，那你要知道请求和响应模型。

换句话说，Vibe Coding 像开自动挡汽车。你确实不需要像职业车手那样每一次换挡都精准，但你必须知道刹车和油门的位置，看得懂仪表盘上的油量和水温。一个完全不懂驾驶的人坐到驾驶位上，哪怕车再智能，也只会在出问题时手足无措。

2.3 该用哪种 AI 编程助手

这个问题几乎每次跟人聊都会被问到。我只能说，工具形态本身不重要，重要的是你熟悉它、并且在合适的场景用它的强项。

市面上的 AI 编程助手大致分三类。第一类是对话式大模型，你贴一段代码、描述一个问题，它给你解释或给方案。这类工具适合做方案讨论、代码解释、匿名化后的问题排查。第二类是 IDE 内嵌的聊天或补全插件，它能感知当前打开的文件，可以在你写代码时直接给出下一段内容、在你报错时给出修复建议。这类工具对日常开发效率的提升是最快的，也是我使用频率最高的。第三类是全自动代理型工具，它直接接管仓库，听你的指令去修改多个文件、运行测试、提交代码。这类工具看起来很酷，但我个人建议等你对项目结构足够了解之后再尝试。

选择标准上，我比较在意四件事：上下文长度够不够；能否导入整个仓库的结构信息；生成的代码质量是否稳定；以及能否在本地或者内网私有化部署。前两项决定了它能处理多复杂的任务，第三项决定了你返工的可能性，最后一项则关乎代码安全和合规。就目前来看，无论你选哪一款，思路都是相通的，我们接下来要聊的实操技巧也基本都能复用。

3. 核心实操：把“描述需求”变成一种手艺

3.1 怎么写提示词才能让 AI 一次到位

很多人 Vibe Coding 体验差，多半是因为提示词写得实在太随性了。“给我写个注册功能”这种需求扔给 AI，它只能靠猜，猜出来的结果大概率和你想要的不一样。这一年半下来，我形成的提示词结构是这样五段式：

角色与背景：先告诉 AI “你是熟悉 XXX 技术栈的开发者，现在在维护一个 XXX 项目”。 具体任务：明确说清楚要做什么，尽量不要用含糊动词。 输入输出示例：给出输入长什么样、期望输出长什么样，这是最高效的约束。 约束条件：说明不允许用某些依赖、必须用标准库、要兼容旧接口、要对异常做特定处理等。 自测要求：让 AI 自己列举它考虑了哪些边界情况，或者让它先生成测试用例。

举一个我最近做的小任务例子，把需求描述出来大概是这样的：

你是一位熟悉 Python 标准库的开发者，正在帮我写一个命令行小工具。请实现一个函数 parse_time，输入是用户传来的日期字符串，格式可能是"2025-06-01" 或 "20250601"，也可能是"今天"、"昨天"。输出统一为标准库 datetime 对象。如果格式无法解析，请抛出说明清晰的异常，不要在函数内部打印内容。请先写 3 条测试用例，再给实现代码。

这种描述方式，AI 给出的代码几乎不用改就能用。关键就在于“输入输出示例”和“约束条件”这两段，它们把 AI 的自由发挥空间压缩到了合理范围，又不妨碍它发挥代码技巧。

3.2 用“小步快跑”方式拆分需求

我见过最多翻车现场，就是把整个项目一次性丢给 AI，“帮我做一个博客系统”。AI 很配合，会给你生成一坨能跑的项目骨架，但里面充满了它拍脑袋做的假设：数据库用什么、登录怎么做、页面长什么样。等你试图把它往你的真实需求上靠的时候，改造成本比从零手写还高。

正确做法是把需求拆成可以独立验证的小块。以博客系统为例，你可以先做“文章数据模型与存储层”，验证数据能写入、能查询；再做“文章列表接口”，用命令行方式直接调用，不急着做 Web 页面；然后做“单篇文章详情页”，再逐步加上“标签过滤”“搜索”“管理后台”。

每一步之间，我都要求 AI 先生成测试，或者我人工跑完上一轮验证，再进入下一步。这样做的好处至少有两点：第一，出错范围被控制在一个小区域内，排查成本低；第二，AI 在上一轮生成的代码会成为下一轮的上下文，它对自己刚才写的内容记忆更准确，质量也随之提升。

我自己的经验是，单个任务让 AI 生成的代码量最好控制在 200 到 400 行之间。太小了体现不出效率，太大了它容易在中间开始“自由发挥”，引入你没要求的设计。

3.3 让 AI 先生成测试，再生成业务代码

这个习惯是我从 TDD（测试驱动开发）里迁移过来的。传统 TDD 是“先写失败测试，再写实现让测试通过”，在 Vibe Coding 里，这个顺序同样有效，而且我认为更重要，因为 AI 如果没有明确的验收标准，它写出来的代码很可能有“自我感觉良好”的问题。

具体操作是：把需求描述完之后，先让 AI 列出你认为需要覆盖的测试用例，而不是直接让它写实现。比如你要做一个“每周习惯打卡统计”，AI 列出的测试可能包括：每日重复打卡要提示、缺失日期不报错、跨周的情况从周一开始算、数据文件被清空时能生成空白报告。你看到这个列表之后，可以轻轻松松补掉它漏掉的场景，比如“年份切换时最后一天算入哪一周”。

当测试用例子集稳定了，再让 AI 写实现，然后我直接跑测试。这样一圈下来，AI 生成的代码通过率会显著提高，而且省掉了大量“我按你的要求写了，你说不对，我再改”的往返。有一次我甚至没看实现代码，直接把测试一跑，居然一次就全绿，那种感觉就像你带的实习生突然靠谱了一次，非常治愈。

3.4 上下文管理：如何防止 AI“健忘”

AI 的上下文窗口再大也是有限的，而且越往后对话，它对早期细节的记忆就越模糊。我试过在一段很长的对话里让 AI 修改一个函数名，结果它把所有调用处都改了，唯独漏掉了最开始定义的那个位置。那一次我意识到，上下文管理不是进阶技巧，而是应该从一开始就认真对待的基础功。

我现在的基本盘是：项目里维护两个文档，一个是 README，用来写项目是干嘛的、怎么跑；另一个是 ARCHITECTURE.md，用来写当前代码结构、模块职责、关键约定。每次新开一个 AI 会话，我先不管任务是什么，先把这两个文档的关键段落粘进去，然后让 AI 用自己的话复述一遍它对我的项目的理解。如果它复述得不对，我就先把文档改对，再让它干活。

会话本身也要控制生命周期。一个会话最好只完成一个任务。任务做完了、测试也过了，就果断新开会话，把最新的结构和约定重新喂进去。不要试图在一个会话里从“拆解需求”聊到“部署上线”，越往后，上下文里塞满冗余信息，AI 的回复质量会肉眼可见地下降。

4. 完整实操记录：做一个“某习惯打卡小工具”

4.1 需求描述

我不太喜欢讲空理论，所以这一章用我最近做的一个真实小项目来走一遍完整流程。这个项目是给个人用的“习惯打卡小工具”，目标是每天用命令行记录有没有喝水、健身、阅读、早睡，然后按周生成一个简单报告。

我把约束条件全部列清楚：用 Python 标准库实现，不引入第三方依赖；数据保存在本地 JSON 文件里；不支持用户系统，单人使用；命令格式分别是 add、list、week；打卡重复了要提示；日期默认当天，也可以传指定日期。这些约束本身并不复杂，但它们直接决定了后面 AI 生成代码的质量。

4.2 第一次提示词和结果

我按照前面说的提示词五段式，把需求发给了 AI 助手。提示词大致是这样的：

你是熟悉 Python 标准库的开发者。请帮我做一个命令行习惯打卡工具。它支持三个子命令： 1. add：接收参数 habit_name 和可选的 date，date 格式是 YYYY-MM-DD，默认今天，重复打卡要给出提示。 2. list：显示本月每一天已经打卡的习惯，未打卡的日期不显示。 3. week：显示本周各习惯打卡次数，按周一到周日统计。 数据保存在 data.json 中，结构你自己设计，但要求方便扩展。整体用 argparse 做命令行解析。 请先编写单元测试，再实现。测试要覆盖：重复打卡提示、w 数据文件不存在时初始化、日期跨年的 week 统计。

生成结果比我想象的完整。AI 给了一个 habit.py、一个 test_habit.py，以及 data.json 的初始化逻辑。代码大概三百行，结构上分成了存储加载、打卡逻辑、命令行入口三块。测试用例也确实覆盖了重复打卡、空文件初始化、跨年周统计。我几乎没有改结构，直接跑测试，前一轮就通过了，还挺意外。

不过接下来我手动试了几个真实场景，发现了一些测试没覆盖的问题。第一次执行 add 没有检查 date 参数是不是真实存在的日期，比如 2025-02-30 这种不存在的日期它也能作为 key 写进数据文件。另一个问题是，如果 data.json 所在的目录不存在，它不会自动创建，程序直接崩溃。

4.3 验证和修复

修改这类小问题，我一般不会再从头描述需求，而是直接带着错误信息去找 AI。比如我这样发：

我手动执行了 python habit.py add water --date 2025-02-30，它没有报错，而是把这个不存在的日期记进去了。我希望它在遇到这种非法日期时给出清晰错误提示，并返回非零退出码。另外，data.json 所在目录如果不存在，希望自动创建。请修改代码并补充这两个场景的测试。

AI 第一轮就给了修改方案，但它用的思路是把日期字符串先转成 datetime 对象，再校验“转过之后会不会丢精度”，这个方向是对的。第二个问题它通过引入 pathlib 的 mkdir(parents=True, exist_ok=True) 解决了，也是常规做法。

我重新跑了测试，发现原有测试没过，因为修改日期校验后，原本一只合法但格式不规范的日期输入被拒绝了。于是我让它把 parse_time 的逻辑抽出来单独处理，允许日期格式稍微灵活一点。这一轮沟通下来大概用了三四条消息，核心代码已经稳定了。整个习惯打卡工具从零到能用，总共花了我一个晚上的时间，其中大部分花在手动跑命令和读代码上，AI 生成的耗时其实很短。

4.4 效果和经验

这个项目给我的最大感受是：Vibe Coding 真正做到位，省下的不是“思考时间”，而是“打字时间”。它让我不必为了一个解析日期的函数去查文档，不必为了一个 argparse 子命令的写法去搜示例，也不必为了一个 JSON 文件不存在时如何处理而费劲写防御逻辑。但它没有替我决定的是：打卡数据要不要去重？一周从周一开始还是周日开始？跨年那一周算给去年还是今年？这些问题全都要靠我自己想清楚，然后转换成需求发给 AI。

所以我在心里给 Vibe Coding 划了一条线：凡是“我知道怎么做、但懒得写”的内容，AI 是超级加速器；凡是“我自己还没想明白”的内容，AI 只会帮我更快地做出一堆错误选择。

5. 常见坑与排查技巧实录

5.1 AI 最常见的“自信地犯错误”

AI 代码生成器最让人哭笑不得的一点是，它经常用非常流利、非常笃定的语气编造出不存在的 API。比如它会让你调用一个库里的某个函数，而这个函数在真实版本里根本不存在；或者给你一个类签名，和实际源码对不上。这种情况在对话式大模型里尤其常见，它会像一个记性很好的路痴，带你走到一条名字听起来很对的街道，但实际地图上不存在。

我的排查技巧是：当 AI 给出的接口调用我感觉陌生，就一定要先问它一句“这个函数的完整定义是什么？它在哪个版本加入的？”或者要求它“给我一个最小可运行示例”。AI 如果能给出明确到版本的依据，我再信它；如果开始含糊解释，我基本就按“幻觉”处理。另外，IDE 的静态检查在这里帮了大忙，大多数不存在的函数会在输入时被标红，我根本不需要运行代码就能发现。

5.2 上下文丢失导致的“同一段代码改三遍”

长对话是 AI 健忘的重灾区。我遇到过一个很典型的场景：一次对话里，AI 删除了某个函数，后来它又在不相关的修改里重新调用了这个已经不存在的函数，导致代码直接无法运行。这类问题在短会话里几乎不会出现，一旦对话超过几十轮，旧信息就会像被橡皮擦掉一样时隐时现。

解决方式还是那句话：小步快跑，新开会话。每完成一个独立小任务，就把这次任务涉及的关键代码结构和接口定义复制到项目的 ARCHITECTURE.md 里。下一次需要 AI 改什么，直接贴这个文档，它就很难记错。你还可以培养一个习惯：每次新会话开始时，让 AI 先复述它认为的项目结构，如果它复述得不对，就说明你喂的上下文不够明确。

5.3 无限循环修 bug

最消磨耐心的情况是：AI 修一个 bug，改到第三轮，它开始拆东墙补西墙。你告诉它这里报错了，它改这里；然后那里又报错，它再改那里；改完以后，最开始的问题又回来了。这个过程极其像和一个经验不足的同事在深夜值班时互相踢皮球。

遇到这种僵局，我的办法是果断重置。把当前代码里所有未提交的改动先用 git diff 看一遍，如果 AI 已经改乱了，就 git checkout 回滚到干净状态。然后我会做一件很多人都忽略的事情：不再让 AI 在原有代码的基础上继续猜，而是给它一段非常清晰的“当前现状”描述，包括文件结构、关键函数、已知报错信息、以及我期望它采取的最小改动方案。如果过了三轮对话仍然修不好，我会选择手写那几十行关键代码，不给 AI 继续发挥的机会。

5.4 合规与数据安全

Vibe Coding 的另一个大坑不在技术层面，而在数据安全与合规。很多人顺手就把包含密钥、客户信息、未公开业务逻辑的代码粘贴到在线对话工具里，这等于把家里的门钥匙拍成照片发到社交平台。AI 服务商确实不会手工盯着你的对话看，但你的数据会进入模型的服务端，这是不能回避的事实。

我的处理原则很简单：在线工具里只放脱敏后的代码和虚构数据；任何涉及公司内部逻辑、凭据、用户隐私的内容，要么先手动打码，要么使用支持私有化部署的本地模型。给客户做的项目我还会严格遵守客户的数据边界规定，宁可少用 AI 也要保证信息不出内网。这不是劝退，而是一个从业者必须有的底线。

5.5 问题速查表

总结一下我这一年半遇到频率最高的几类问题，直接做成表格，方便你对照排查。

这个表也是我自己现在快速定位问题的工具箱。很多时候问题不在 AI 不够强，而是我的使用姿势触发了它的短板。把这些诱发条件控制住，Vibe Coding 的稳定性会好很多。

6. 最后聊一聊：Vibe Coding 的边界

聊到这儿，你大概已经看出来了，我对 Vibe Coding 的态度是“好用，但别迷信”。它能让我在很短时间内把一个粗糙想法变成一个可以运行的原型，能让我把重复劳动压缩到最小，但它的能力上限其实取决于我脑子里对问题本身理解得有多清楚。我不会把架构设计和安全关键环节完全交给 AI 去“Vibe”，那些地方我还是会自己画边界、做评审、写关键测试。

我个人在实操中最受益的一点是，我开始更习惯于先把需求拆成小份、把验收标准写出来，再动手。这个习惯以前我总觉得麻烦，但 Vibe Coding 逼着我必须这么做，因为 AI 太擅长“听不懂就硬做”了。如果你从没试过把一个功能的输入、输出、异常、边界全部写清楚，那拉着 AI 干一次活，你会发现自己对需求的把握比想象中粗糙很多。

这一年半下来，我也慢慢找到了自己的节奏：日常的重复性脚本、测试脚手架、数据整理，我放心大胆地让 AI 去打头阵；而真正难的业务重构、性能调优、上线前的安全审查，我仍然保留人工主导的权利。Vibe Coding 不是一个非黑即白的选择，它更像你工具箱里那把最锋利的刀，拿得好能事半功倍，拿不稳就容易伤到自己也砍坏桌子。希望这篇心得能帮你少走一点弯路，至少别再犯那些我已经替你犯过的错。