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 应用数据库用的是 PostgreSQLORM 用的是 SQLAlchemy。现在我要写订单模块。”这几句话能让 AI 快速进入状态不需要我反复解释。注意开新对话之前把上一个对话里已经跑通的代码保存好。AI 不会记得上一个对话的内容你需要自己维护代码的连续性。4. 那些 AI 不会告诉你的坑我踩过的五个典型问题4.1 幻觉 API它编了一个不存在的函数这是最常见的问题。AI 在生成代码时有时会“发明”一些不存在的函数或参数。比如它可能给你一个requests.get(url, timeout5, retry3)但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 编程助手根据意图描述生成代码草稿代码审查静态分析工具检查语法错误、未使用变量、潜在 bug测试测试框架 AIAI 写测试用例框架跑测试版本管理Git每跑通一个功能就提交一次这个组合里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我的建议是从一个小项目开始从一个小功能开始先感受一下这种节奏。不要一上来就追求“全自动”而是把它当成一个需要磨合的搭档。磨合期过了之后你会发现自己的开发节奏变得不一样了——更流畅更专注也更有趣。