1. 从“能跑就行”到“感觉对了”：vibe coding 到底在说什么

第一次听到“vibe coding”这个词，我脑子里蹦出来的画面是：一个人戴着耳机，手指在键盘上有一搭没一搭地敲，屏幕上代码像流水一样滚出来，他本人却像在听歌一样放松。后来我自己用 AI 辅助编程的时长累积到几百个小时之后，才慢慢理解这个词真正描述的是什么状态——它不是“让 AI 替我写代码”，而是“我和 AI 之间形成了一种默契的节奏”。

传统编程的节奏是：想清楚逻辑，查文档，写代码，调试，再查文档，再调试。整个过程像在一条窄路上开车，你得时刻盯着路面。而 vibe coding 的节奏更像是在跟一个反应很快的搭档对话：你抛出一个模糊的想法，对方给你一个能跑的版本，你看一眼，说“这里不对，应该是那样”，对方立刻改，你再调整方向。代码在对话中逐渐成形，而不是在你脑子里完全设计好之后才被“翻译”成代码。

这种工作方式的核心变化在于：你的注意力从“语法和 API 细节”转移到了“意图和结构”上。以前你可能会花二十分钟纠结一个日期格式化函数的参数顺序，现在你只需要说“把这个时间戳转成人类能读的格式”，AI 给你三四种写法，你挑一个顺眼的。省下来的精力，你可以用来想更重要的事：这个模块的边界在哪里，数据流怎么走，异常情况怎么处理。

但这里有一个很多人会踩的坑：以为 vibe coding 就是“随便说说，AI 全包”。我见过不少新手上来就丢一句“帮我写一个电商网站”，然后对着生成的几百行代码发呆，不知道从哪里改起，也不知道哪里可能有问题。这不是 vibe coding，这是把 AI 当许愿池。真正的 vibe coding 需要你具备足够的判断力，能在 AI 给出的方案里快速识别出“这个方向对”还是“这个方向偏了”。你的经验越丰富，这种判断越快，整个节奏就越流畅。

所以这篇文章我想聊的，不是“哪个 AI 编程工具最强”这种榜单式的内容，而是我在这几百个小时里摸索出来的一套工作节奏：怎么跟 AI 配合，怎么在它给的方案里做取舍，怎么避免被它带偏，以及怎么把这种工作方式变成一种可持续的习惯。适合已经有基本编程概念、但还没找到跟 AI 协作节奏的开发者，也适合那些用 AI 写了一段时间代码、但总觉得“哪里不对劲”的人。

2. 我的 vibe coding 工作流：从一句话到能跑的代码

2.1 起手式：用“意图描述”代替“需求文档”

很多人跟 AI 编程助手交互的方式是写一段类似需求文档的东西：“请实现一个函数，输入是用户 ID，输出是用户信息，要求支持缓存，缓存过期时间 300 秒，使用 Redis。”这种写法没有错，但它把 AI 当成了一个执行器，而不是一个协作者。在 vibe coding 的节奏里，我更倾向于用“意图描述”开头，把上下文和约束条件用自然语言带出来。

比如上面那个需求，我会这样说：“我在做一个用户中心的服务，现在需要根据用户 ID 拿用户信息。数据库查询有点慢，我想加一层缓存，用 Redis 就行，过期时间先设 5 分钟。你帮我写一个拿用户信息的函数，注意缓存穿透的情况。”这段话里包含了几个关键信息：业务场景（用户中心）、性能痛点（数据库慢）、技术选型（Redis）、参数（5 分钟）、以及一个隐含的边界条件（缓存穿透）。AI 拿到这些信息之后，给出的代码通常会比“纯需求文档”式的提问更贴合实际场景。

为什么这样做更有效？因为 AI 在生成代码时，会依据你提供的上下文来推断很多细节。你给的信息越接近真实场景，它推断出来的细节就越靠谱。你只说“写一个缓存函数”，它可能给你一个最简版本，没有空值处理，没有异常捕获。你说了“注意缓存穿透”，它就会主动加上空值缓存或者布隆过滤器的逻辑。这不是 AI 变聪明了，而是你给它的“锚点”更多了。

提示：意图描述不需要很长，但最好包含三个要素——业务场景、技术约束、你担心的边界情况。这三样东西能帮 AI 把代码写到点子上。

2.2 第一轮生成：不要急着改，先跑一遍

AI 给出第一版代码之后，很多人的第一反应是逐行阅读，然后开始改。我的习惯是：先跑一遍。哪怕这段代码看起来有明显的问题，只要它能跑起来，我就先跑。为什么？因为运行结果会告诉我很多静态阅读发现不了的信息：依赖是不是缺了，环境变量是不是没配，返回值格式是不是跟预期一致。

举个例子，有一次我让 AI 写一个解析日志文件的脚本，它给了一个用正则匹配的版本。我扫了一眼觉得正则写得有点复杂，但没细看，直接跑了一遍。结果发现它假设日志的每一行都以时间戳开头，而我的日志文件前几行是注释。这个信息如果我静态阅读，可能要花几分钟才能注意到，但跑一遍只需要两秒钟就暴露出来了。

跑完之后，我才会带着运行结果去跟 AI 对话：“跑了一下，报错说第 12 行索引越界，日志前几行是注释，你调整一下解析逻辑。”这种带着具体错误信息的反馈，比“你这代码有问题”有效得多。AI 能根据错误信息精准定位问题，给出的修正版本通常一次就能过。

2.3 迭代节奏：小步快跑，每次只改一个点

vibe coding 最忌讳的是“攒一波大的”——让 AI 一次性生成几百行代码，然后你花半天时间调试。这种方式的反馈周期太长，一旦方向偏了，修正成本很高。我习惯的节奏是：每次只让 AI 做一件事，做完跑通，再做下一件。

比如我要做一个数据导出功能，我不会说“帮我写一个导出模块”。我会拆成几步：第一步，让 AI 写一个从数据库读取数据的函数，跑通；第二步，让 AI 把数据转成 CSV 格式，跑通；第三步，让 AI 加上文件写入和路径处理，跑通；第四步，让 AI 加上异常处理和日志，跑通。每一步的代码量都不大，我都能快速看懂，跑通之后再进入下一步。

这种节奏的好处是，每一步的代码都在我的掌控范围内。如果某一步 AI 给的方向不对，我立刻就能发现，调整的成本很低。而且每一步跑通之后，我都有一个新的“基线”，下一步的修改是在这个基线上进行的，不会出现“改了半天发现前面就错了”的情况。

2.4 什么时候该自己写，什么时候该让 AI 写

不是所有代码都适合让 AI 生成。我的判断标准很简单：如果这段代码的“正确性”很难验证，我就自己写；如果“正确性”容易验证，我就让 AI 写。

什么叫“正确性容易验证”？比如一个排序函数、一个字符串格式化函数、一个 HTTP 请求的封装，这些代码跑一下就能看出对不对。AI 写这种代码又快又好，我省下来的时间可以用来想架构。

什么叫“正确性很难验证”？比如一段涉及复杂业务规则的逻辑，或者一段跟外部系统交互的代码，它的正确性依赖于很多外部条件，跑一次两次看不出问题。这种代码我倾向于自己写，因为写的过程中我会被迫想清楚每一个边界条件。AI 写这种代码，我反而要花更多时间去审查，得不偿失。

还有一个场景是“我知道怎么写，但懒得写”。比如一个很长的配置文件、一段重复的样板代码、一个我写过很多次的工具函数。这种时候让 AI 写，我只需要扫一眼确认没问题就行，效率提升很明显。

3. 跟 AI 对话的实操技巧：怎么问，它才给得准

3.1 把“大问题”拆成“小问题”的提问模板

我总结了一个提问模板，基本上覆盖了日常开发中大部分场景：

我在做 [业务场景]，现在需要 [具体功能]。技术栈是 [语言/框架/库]。我担心 [边界情况/性能问题/兼容性问题]。你先给我一个最简版本，跑通之后我们再优化。

这个模板的关键在于最后一句：“先给我一个最简版本”。很多 AI 编程助手默认会给你一个“完整”的版本，包含各种错误处理、日志、配置项。但这些东西在你还没跑通主流程之前，都是干扰。你要的是一个能跑的最小核心，跑通之后再逐步加东西。

举个例子，我要写一个调用外部 API 的函数。如果我只说“帮我写一个调用 XX API 的函数”，AI 可能会给我一个包含重试、超时、错误码映射、日志记录的完整版本。这个版本可能有五十行，我读一遍就要几分钟。但如果我说“先给我一个最简版本，能发请求拿到数据就行”，AI 可能只给我十行。我跑通这十行之后，再让它加超时、加重试、加日志，每一步都清晰可控。

3.2 用“错误信息 + 预期行为”代替“这不对”

跟 AI 反馈问题时，最无效的说法是“这不对”或者“有 bug”。AI 不知道哪里不对，只能猜。有效的反馈是：贴出错误信息，说明预期行为，指出实际行为。

比如：“跑了一下，报错KeyError: 'user_id'。我预期是从响应里拿到 user_id 字段，但实际返回的数据里这个字段叫userId。你改一下字段映射。”这种反馈信息量很大，AI 能直接定位到问题，给出的修正版本通常一次就对。

如果错误信息很长，我会截取关键部分，而不是全部贴上去。AI 处理长文本的能力虽然不错，但关键信息被淹没在大量日志里，它也可能抓不住重点。我的习惯是：贴错误类型和最后几行堆栈，加上一句“我预期是 XXX，实际是 YYY”。

3.3 让 AI 解释代码，而不是只让它写代码

AI 生成代码之后，我经常会多问一句：“这段代码里，如果输入是空值会怎样？”或者“这个循环在数据量很大的时候会不会有问题？”这种提问方式有两个好处：一是帮我快速理解 AI 的代码逻辑，二是有时候 AI 会自己发现潜在问题并给出修正。

有一次 AI 给我写了一个分页查询的函数，我看了一眼觉得没问题，但多问了一句“如果页码超出范围会怎样”。AI 想了一下，说“当前实现会返回空列表，但更好的做法是返回一个明确的错误或者最后一页的数据”。然后它主动给了一个修正版本。这个修正版本我自己可能要想一会儿才能想到，但 AI 在几秒钟内就给出了。

这种“追问”的习惯，让我从 AI 那里得到的不仅仅是代码，还有对代码的审视。时间长了，我自己写代码时也会不自觉地多问自己几句“如果这里输入是空值会怎样”“如果数据量很大呢”，这算是意外收获。

3.4 上下文管理：什么时候开新对话，什么时候继续

AI 编程助手通常有上下文长度限制，对话太长之后，早期的信息会被“遗忘”。我的经验是：当一个功能模块完成之后，就开一个新对话。不要把整个项目的所有代码都塞在一个对话里。

比如我在做一个 Web 应用，用户模块、订单模块、支付模块是分开的。我会为每个模块开一个独立的对话。这样每个对话的上下文都是干净的，AI 不需要在大量无关代码里找相关信息，给出的建议也更精准。

如果某个模块的代码量很大，我会在对话开头贴一段简短的“项目背景”：“这是一个 Flask 应用，数据库用的是 PostgreSQL，ORM 用的是 SQLAlchemy。现在我要写订单模块。”这几句话能让 AI 快速进入状态，不需要我反复解释。

注意：开新对话之前，把上一个对话里已经跑通的代码保存好。AI 不会记得上一个对话的内容，你需要自己维护代码的连续性。

4. 那些 AI 不会告诉你的坑：我踩过的五个典型问题

4.1 幻觉 API：它编了一个不存在的函数

这是最常见的问题。AI 在生成代码时，有时会“发明”一些不存在的函数或参数。比如它可能给你一个requests.get(url, timeout=5, retry=3)，但requests库的get方法根本没有retry参数。这种错误在静态阅读时很难发现，因为代码看起来完全合理。

我的应对方法是：对 AI 生成的每一行涉及外部库调用的代码，都保持警惕。第一次使用某个库的某个函数时，我会快速查一下官方文档，确认参数名和返回值。如果懒得查，就跑一遍，让运行时报错来告诉我。

还有一个更隐蔽的情况：AI 编造了一个看起来很像真实 API 的函数名。比如它可能写df.read_csv()而不是pd.read_csv()，或者写json.loads()而不是json.load()。这种错误在代码审查时容易被忽略，因为名字太像了。我的习惯是：对 AI 生成的代码，重点关注所有“点号”后面的东西——方法名、属性名、参数名，这些是最容易出错的地方。

4.2 过度设计：它给你一个你不需要的“企业级方案”

你让 AI 写一个简单的配置读取函数，它给你一个包含环境变量、配置文件、命令行参数三层优先级，还带缓存和热重载的“企业级”方案。这个方案可能有八十行，而你只需要十行。

这种情况的原因是：AI 在训练时见过大量“最佳实践”的代码，它倾向于给你一个“完整”的解决方案。但“完整”不等于“合适”。我的应对方法是：在提问时就明确说“给我最简版本，不要错误处理，不要日志，不要配置项”。如果它还是给了复杂版本，我会说“太复杂了，砍掉一半，只保留核心逻辑”。

有时候 AI 给的复杂方案里确实有一些我没想到的点，比如它加了缓存是因为它“认为”这个函数会被频繁调用。这种情况下，我会问它“为什么加缓存”，如果理由合理，我就保留；如果理由不充分，我就砍掉。关键是：你要对每一行代码的存在理由有判断，而不是照单全收。

4.3 上下文遗忘：它忘了你十分钟前说过的话

在长对话中，AI 可能会忘记你之前提到的约束条件。比如你一开始说了“这个项目用的是 Python 3.8，不能用 3.10 的语法”，但对话进行到一半，它给你一个用了match语句的代码。这不是它故意忽略你，而是上下文太长了，早期的信息被“挤出去”了。

我的应对方法是：把关键约束条件在每次提问时重复一遍。比如每次让它写代码时，我都会带上“Python 3.8，不能用 match，不能用 walrus 运算符”。虽然有点啰嗦，但能避免很多返工。

另一个方法是：把约束条件写在一个单独的文本文件里，每次开新对话时贴进去。这样你不需要每次手动输入，复制粘贴就行。我有个朋友甚至写了一个脚本，自动把项目约束和当前代码文件一起发给 AI，省去了手动整理的麻烦。

4.4 测试缺失：它不主动写测试，除非你要求

AI 编程助手默认不会给你写测试，除非你明确要求。但测试恰恰是保证代码质量的关键。我的习惯是：每完成一个功能模块，就让 AI 写对应的单元测试。

让 AI 写测试有一个额外的好处：它在写测试的过程中，有时会发现自己的实现有问题。比如它写了一个排序函数，然后写测试时发现“空列表输入会报错”，于是主动修正了实现。这种“自我发现”的概率不低，因为写测试迫使 AI 从“使用者”的角度重新审视代码。

我通常会让 AI 写三类测试：正常输入、边界输入（空值、极值、特殊字符）、异常输入（类型错误、格式错误）。这三类覆盖了大部分常见问题。如果测试跑不过，我就把失败信息贴给 AI，让它修正实现或者修正测试。

4.5 安全盲区：它不会主动考虑安全问题

AI 生成的代码在功能上通常没问题，但在安全上可能有盲区。比如它可能给你一个直接拼接 SQL 的查询，或者一个没有做输入校验的表单处理函数。这些代码跑起来没问题，但存在安全隐患。

我的应对方法是：对涉及用户输入、数据库操作、文件操作、网络请求的代码，额外多问一句“这里有没有安全问题”。AI 通常能识别出常见的安全问题，比如 SQL 注入、XSS、路径穿越等，并给出修正方案。但前提是你要主动问，它不会主动提。

还有一个容易被忽略的点是：AI 生成的代码里可能包含硬编码的密钥或密码。比如它可能写api_key = "sk-xxxxx"。这种代码如果直接提交到代码仓库，后果很严重。我的习惯是：对 AI 生成的代码做一次全局搜索，看看有没有类似key、secret、password、token这样的字符串，如果有，立刻改成从环境变量读取。

5. 把 vibe coding 变成习惯：我的日常节奏和工具搭配

5.1 我的日常工具组合

我目前的工作流里，AI 编程助手不是单独使用的，而是跟其他工具配合。大致是这样的：

这个组合里，AI 编程助手承担的是“草稿生成”和“测试生成”两个角色。静态分析工具和测试框架承担的是“验证”角色。笔记软件承担的是“意图澄清”角色。三者缺一不可。

为什么需要静态分析工具？因为 AI 生成的代码有时会有一些低级问题，比如未使用的导入、变量名拼写错误、类型不匹配。这些问题人眼扫一遍可能漏掉，但静态分析工具一跑就出来了。我通常在 AI 生成代码之后，先跑一遍静态分析，把低级问题清掉，再进入测试环节。

5.2 每天的开始：先跑通一个最小闭环

我每天开始写代码之前，会先花十分钟做一个“最小闭环”：让 AI 生成一个最简单的、能跑通的代码片段，跑一遍，确认环境没问题。这个片段可能只是一个打印语句，或者一个最简单的函数调用。目的是让自己进入“跟 AI 对话”的节奏，同时也确认开发环境是正常的。

这个习惯是从一次惨痛经历来的。有一次我花了一个小时跟 AI 讨论一个复杂功能的实现，代码写了三百多行，最后跑的时候发现是环境变量没配，整个下午都在排查环境问题。从那以后，我每天开始写代码之前，都会先跑一个最小闭环，确认环境没问题再进入正式开发。

5.3 每天的结束：让 AI 总结今天做了什么

每天结束工作之前，我会让 AI 帮我总结一下今天写的代码：“把今天对话里涉及的主要功能和修改点列一下，我要写 commit message。”AI 会给我一个结构化的总结，我稍微改一下就能当 commit message 用。

这个习惯的好处是：一是省去了写 commit message 的时间，二是通过 AI 的总结，我能快速回顾今天做了什么，有没有遗漏的地方。有时候 AI 的总结里会提到一些我已经忘记的修改点，提醒我检查一下那些地方是不是真的改好了。

5.4 周末的回顾：把重复的对话模式固化下来

每周末我会花半小时回顾这一周的对话记录，看看有没有重复出现的提问模式。比如我发现我经常问“这个函数如果输入是空值会怎样”，那我就会把这个问题固化成一个检查项，以后每次 AI 生成代码后都自动问一遍。

另一个发现是：我经常让 AI 写“从数据库读取数据并转成 JSON”的代码。这种重复性的任务，我会让 AI 写一个通用的模板，以后直接改改就能用。这样既省时间，又保证了代码风格的一致性。

5.5 什么时候不该用 AI

最后说一个反直觉的经验：有些时候，不用 AI 反而更快。比如当你对某个问题已经有清晰的思路，只是需要把代码敲出来的时候，直接写比跟 AI 描述再等它生成要快。又比如当你需要深度思考一个复杂逻辑的时候，跟 AI 对话反而会打断你的思路。

我的判断标准是：如果我能在一分钟内把问题描述清楚，就用 AI；如果描述本身就需要五分钟，就自己写。因为描述问题的时间加上 AI 生成和调试的时间，可能已经超过自己写的时间了。而且自己写的过程中，思路会更连贯，不容易被打断。

这个边界每个人可能不一样，需要自己在实践中摸索。我的经验是：随着你对 AI 的熟悉程度提高，这个边界会逐渐向“用 AI”的方向移动。一开始你可能觉得很多事情自己写更快，但用久了之后，你会发现越来越多的场景适合交给 AI。

6. 关于“感觉”这件事：vibe coding 的长期价值

回到“vibe coding”这个词本身。我觉得它描述的不仅仅是一种工作方式，更是一种心态。传统编程里，你面对的是冷冰冰的编译器和运行时，错了就是错了，没有商量余地。而 vibe coding 里，你面对的是一个能理解你意图的搭档，你可以用模糊的语言描述想法，它给你一个具体的版本，你再基于这个版本调整方向。

这种工作方式最大的价值，不是“写得快”，而是“想得清楚”。因为当你需要用自然语言向 AI 描述一个功能时，你被迫把模糊的想法变成清晰的意图。这个过程本身就是一种思考。很多时候，我在描述问题的过程中就发现了自己逻辑上的漏洞，还没等 AI 生成代码，就已经知道该怎么改了。

另一个长期价值是：你的经验会以“判断力”的形式积累下来。AI 生成的代码越来越多，你不可能每一行都仔细审查。但你的经验会帮你快速判断“这段代码大概没问题”还是“这段代码需要仔细看看”。这种判断力是 AI 无法替代的，也是你在 vibe coding 时代最核心的竞争力。

我见过一些人担心“AI 会取代程序员”。我的看法是：AI 取代的是“翻译需求为代码”这个环节，但“判断代码好不好”“决定做什么功能”“理解业务逻辑”这些环节，仍然需要人。而且随着 AI 生成代码的门槛降低，判断力的价值反而更高了——因为代码变得廉价，好的判断变得稀缺。

所以如果你还在犹豫要不要尝试 vibe coding，我的建议是：从一个小项目开始，从一个小功能开始，先感受一下这种节奏。不要一上来就追求“全自动”，而是把它当成一个需要磨合的搭档。磨合期过了之后，你会发现自己的开发节奏变得不一样了——更流畅，更专注，也更有趣。