最近圈子里最热的词一个是 vibe coding一个是 AI 辅助编程。我重度用了差不多三个月最大的感受是写代码这件事已经从我亲手敲键盘变成了我和 AI 轮流敲键盘而且后者往往更快、更省心。如果你还没找到节奏这篇就是我在真实项目里摸出来的那套方法、踩过的坑和最后的判断标准。适合所有想用 AI 提效的程序员也适合那些会描述需求但不太会写代码的产品、运营和独立开发者。1. 从复制粘贴到vibe coding我心态上的三个转变vibe coding 这个词最早流行起来的时候很多人以为它指的是随便哼两句就让 AI 把整个项目写完。我实际用下来发现它的内核其实是一种分工关系的重构程序员从每一行代码的执行者变成方向的制定者和质量的守门人。不是不写代码了而是写的代码从亲手实现变成了描述、验收、纠偏。1.1 第一个转变从手写代码到审阅代码以前我写一个功能脑子里先过一遍数据流再想 API再想边界条件最后才动手。vibe coding 之后我的工作顺序完全反过来了先让 AI 出一版我对着需求文档逐行审。刚开始我很不习惯总觉得 AI 写的代码不是我的代码后来我意识到审阅代码本身就是一种深度理解——你反而要更清楚地知道每一段在干什么、有没有隐患因为你得为它负责。举个最简单的例子。我要给一个 CSV 文件做清洗以前我会打开编辑器回忆 pandas 的用法写个循环跑一下报错再调。现在我会直接告诉 AI我有 10 万行销售数据列有日期、金额、区域帮我去重、把日期标准化、金额列里有元字要去掉并转成浮点数。它几秒钟给我一版我检查的反而只有三件事逻辑对不对、有没有处理缺失值、性能能不能跑完 10 万行。1.2 第二个转变从背 API 到描述意图以前写 Python 要记住strftime的格式码、groupby的用法、正则表达式的各种转义。现在这些细节我从脑子里卸载了换成了更接近自然语言的描述能力。我能用一句把字符串里所有形如 2024-01-01 的日期统一成 2024年1月1日 这种格式来替代一长串正则。这个转变最容易被误解的地方在于不懂语法的人确实能写出能跑的代码但写不出好的代码。AI 可以替你记住语法但它不会替你做架构决策更不会替你理解业务。如果你本身没有这段代码会在什么场景下崩掉的直觉AI 给你的代码你连怎么验收都不知道。所以我的结论是vibe coding 降低了编程的门槛但没有降低编程的认知要求。1.3 第三个转变把报错当成对话的一部分以前看到报错我的第一反应是紧张然后是漫长的 Stack Overflow 搜索。现在我看到报错心态平和得多——因为报错本身就是一次新的输入。我会把报错信息原样丢回给 AI跟一句哪里出了问题怎么改然后看着它自我修正。这个转变带来的副产品是我处理问题的耐心变好了。以前一个 bug 卡三个小时我会烦躁现在我知道只要把上下文喂够、把报错贴全大部分问题都能在两三轮对话内解决。真正麻烦的从来不是报错本身而是上下文缺失——AI 看不见你整个项目的状态你也没告诉它你改了哪里它当然只能瞎猜。2. 一套我反复打磨的 vibe coding 工作流光有心态不够工具和流程才是让 vibe coding 稳定输出的关键。我前后试过很多方案最后沉淀下来的工作流可以概括成六个字小仓库、大上下文、分步走。2.1 工具选型我用过的几个 AI 编程工具横向对比市面上能用来 vibe coding 的工具分三类IDE 插件型、独立代理型、命令行型。我把实际用过的几款放在一起做了个对比括号里是我个人的真实感受工具类型擅长场景我遇到的主要短板CursorIDE 插件型在既有项目里做局部修改、补功能大文件看不过来容易改坏上下文Claude Code命令行代理型独立脚本、多文件重构、全栈小项目需要你习惯终端交互有学习成本Codex CLI命令行代理型批量任务、Git 工作流整合对复杂业务上下文的理解不如对话式工具GitHub CopilotIDE 插件型补全、小函数、模板代码对整个需求的把握能力较弱我的建议是别贪多固定用一到两个。我现在的主力是命令行代理型工具搭配 IDE 插件前者帮我写整块逻辑、做多文件改动后者在我手动微调时提供补全。两者分工明确基本不会互相打架。2.2 项目结构为什么小仓库反而更高效很多人让 AI 写项目喜欢从一开始就把目录搭得特别宏大——models、services、utils、config 一应俱全。结果 AI 在生成代码的时候会把大量上下文浪费在猜这些目录是什么关系上。我的做法是一个 ≤5000 行的独立脚本或一个小工具就单独占一个仓库不要塞进大项目里。小仓库意味着你可以把整个仓库的代码都丢给 AI 当上下文。我一般会在项目根目录放一个README.md里面写清楚这个工具是干什么的、输入输出是什么、运行命令是什么。这个 README 就是 AI 的第一份上下文比它自己去翻代码高效得多。2.3 提示词框架我每次必写的四项结构提示词不是越长越好而是结构化越好。我写的绝大多数任务提示词都包含四块角色与背景告诉 AI 它在什么项目里、用什么技术栈。任务目标一句话说清楚要做什么输入是什么、输出是什么。硬性约束明确不许做什么比如不要引入额外依赖、不要改数据库结构、兼容旧版本。验收示例给一个输入和期望输出的例子比十句描述都管用。举个例子我让 AI 写一个批量重命名文件的脚本你是一个熟悉 Python 的自动化脚本工程师。 任务写一个命令行脚本把当前目录下所有形如 IMG_20240101_123456.jpg 的图片 重命名为 2024-01-01_123456.jpg日期格式替换成 YYYY-MM-DD。 约束只允许用标准库 os、re、datetime不要引入任何第三方依赖。 验收输入 IMG_20240101_123456.jpg输出应成为 2024-01-01_123456.jpg。加上验收示例之后AI 的理解准确率肉眼可见地提升。很多人抱怨 AI 写代码跑不通八成原因是提示词里只有任务描述没有验收标准。2.4 上下文管理喂给它最新版本而不是全部历史AI 对话窗口有上下文上限用得多了它就会忘记前面的要求开始答非所问。我踩过这个坑之后总结出来的经验是每一轮对话尽量把当前最新的文件内容重新贴一遍而不是依赖它记得。具体操作很简单AI 改完一个文件我立刻把改完的版本粘回去跟一句基于这个最新版本继续做下一步。这个动作看起来笨但能省掉后面大量的你怎么忘了的纠错对话。还有一个常用技巧就是把长文件拆成小文件比如把配置、主逻辑、工具函数分开。每个文件都被完整喂进上下文AI 的推理质量会高很多。3. 实战回放两个让我彻底上头的项目说再多方法论都不如看两个真实项目是怎么从一句话长成一个完整工具的。下面这两个项目我都跑出了可用的成果第一个偏工具第二个偏带界面的小应用。3.1 实战一把十年散乱的 Markdown 笔记整理成知识库我的笔记库有几千个文件有些带 frontmatter有些不带有些标题写的是未命名内文却全是干货。这个整理需求我拖了很久就是因为手动做太烦写脚本又懒得搜一堆解析库的用法。有了 vibe coding 之后我把它当成了第一个练手项目。第一轮对话我只提了一个概述写一个 Python 脚本扫描 notes 目录下所有 .md 文件补充 YAML frontmatter包含 title、tags、datedate 从文件系统修改时间读取tags 根据文件内容里的关键词自动打标。AI 第一版很快就出了跑起来也确实能跑但有两处不符合我的需求一是它对关键词自动打标的实现非常粗暴只是硬编码了几个词的映射二是有一些已经带 frontmatter 的文件被重复处理了。我把这两个问题直接回给 AI跳过已有 frontmatter 的文件打标逻辑改成从文件名和正文前 300 字里提取关键词并去重。它改完之后整个脚本稳定跑完几百个文件全部规整。这个项目的启发是第一版永远只是半成品但你只需要会指出哪里不对就能把它推向你想要的方向。这在以前是不可想象的——以前每一步都得自己来。3.2 实战二给家里的水电燃气做了个小账本第二个项目稍复杂我想要一个本地网页小工具能录入每月水电燃气读数自动算环比并生成简单的消费趋势图。放在以前这个需求涉及前端页面、数据存储、图表渲染我一个人得折腾好几天。流程是这样的我先让它定技术方案。我跟 AI 说做一个本地运行的单页应用不需要后端数据存 localStorage用 ECharts 画趋势图尽量少的依赖。它选用了原生 HTML JavaScript ECharts 的方案文件就三个非常轻。然后我按模块推进先让它把数据录入和存储部分写出来我在浏览器里手动录入几组数据测试再让它画趋势图最后让它加环比计算和颜色标注上涨红色、下跌绿色。每一步我都是按第 2 节里的四项结构给提示词每一步的产出都是可验收的。从头到尾我只手写了不到二十行代码剩下的全是评审和微调。现在这个账本我用了两个月真实数据跑得挺稳。它让我彻底相信了一件事vibe coding 特别适合为自己解决问题的中小型项目因为这种项目不需要多大并发、不需要多强安全只要逻辑正确、符合使用习惯就行。4. 翻车实录AI 代码的崩溃现场与排查链路vibe coding 不是不会翻车而是翻车的方式和以前不太一样。以前翻车多半是我的逻辑漏洞现在翻车往往集中在 AI 的自信幻觉上。下面三个事故我印象最深每一个都让我心疼地浪费过时间。4.1 事故一AI 给我编了一个不存在的 API有一次我让 AI 用某个第三方库处理 PDF它给我写了一版代码里头用的函数名长得完全合理比如extract_pages()、rotate_page()。一运行直接报AttributeError。我一开始以为是版本问题来回折腾了好几个版本最后去查官方文档才发现那个 API 从来没有存在过是 AI 根据函数命名习惯脑补出来的。这次事故让我彻底养成了一个习惯AI 引用第三方库时必须让它先给我库的官方文档链接或者我主动把文档片段贴给它。别指望 AI 对每个库的每个版本都了如指掌它的训练数据有截止时间而且它经常会用逻辑补全事实。4.2 事故二上下文一长前面的约束全忘了第二个事故发生在一个稍大的项目里。项目跑到第十几轮对话我明显感觉 AI 的行为开始漂移我前面说过不要改数据库字段名它改着改着就给我加了新字段我说所有输入都要校验空值它后来生成的代码里完全没有校验。最典型的一次是它忘了我最初定的零第三方依赖约束在某个小工具里悄悄引了一个厚重框架。我用了一个相对笨但有效的排查办法重新整理一份当前项目的全貌文档把之前散落在对话里的所有关键决策汇总成清单然后把它作为新一轮对话的开场导入。这相当于给 AI 做了次记忆清理之后它的行为立刻回到正轨。自那以后我的每个项目都有了一个DECISIONS.md文件专门记录所有已经拍板的约束和原因。4.3 事故三改 UI 改出了僵尸循环还有一个事故特别有意思。我让 AI 调整一个网页的按钮样式它为了确保所有状态都覆盖在 JavaScript 里加了一个持续监听 DOM 变化的循环。结果页面加载后无限触发重绘浏览器直接卡死。这个 bug 特别难发现因为报错没有明确指向页面就是肉眼可见地变慢。排查链路是这样的先开开发者工具看性能面板发现主线程占用率接近 100%再看调用栈发现反复执行同一个函数接着看代码发现MutationObserver回调里无限修改自身触发的属性。整个定位过程大概花了半小时最后我让 AI 删掉那个观察器换成一个只在按钮点击时执行一次的简单函数。这次事故教会我一件事AI 生成的前端交互代码你得特别警惕自动触发和监听类的逻辑它们一旦形成循环表现往往不是报错而是极难察觉的性能问题。5. 让它别乱写约束 AI 的三板斧翻车多了我总结出一套约束 AI的方法核心就一句话别让它自由发挥给它一套可验收的笼子。这套方法我称之为三板斧规格先行、增量交付、测试兜底。5.1 规格先行先写 README再让 AI 写代码传统的开发是先有代码后有文档vibe coding 恰恰相反。我现在的习惯是在动手写代码之前先把这个项目的 README 写好。README 里包含三部分这个工具解决什么问题、输入输出格式、运行和验收方式。写完之后我把 README 和照着实现四个字一起丢给 AI。它能基于这份规格生成相当靠谱的第一版。原理很简单README 就是一份无歧义的需求说明书AI 的推理空间被收窄幻觉自然少很多。如果你连 README 都懒得写那你至少要有我到底要什么的自信不然 AI 会替你定义需求后果通常不太妙。5.2 增量交付每轮只做一件可验证的小事我最开始让 AI 干活喜欢一口气说帮我做一个博客系统要文章管理、标签、搜索、评论结果它生成了一大堆文件每个文件都不完整Chat 一多上下文就爆炸。后来我改成一次只推进一个模块比如先做文章列表页数据从硬编码数组读取暂不接接口跑通了再接下一步。这样做有三个看得见的好处一是每一轮对话都能验证有了错误立刻定位二是上下文始终保持精简AI 不容易精分;三是我的工作量从审查一大堆变成审查一小块质量明显提升。增量交付的本质是把大项目拆成一系列小型的 vibe coding 任务每轮对话都是一次独立的需求-产出-验收闭环。5.3 测试兜底让 AI 自己写测试并跑给你看很多人觉得测试是完事之后才补的东西但 vibe coding 里测试反而是约束 AI 的最佳工具。我的做法是让 AI 写实现的同时立刻写一个最小测试脚本把关键路径跑一遍。测试脚本不需要多专业能覆盖核心逻辑就行。举一个例子我让它写一个函数把日期字符串从YYYY/MM/DD转成YYYY-MM-DD。它就同时给我生成了一组用例包括正常输入、空值、格式不合法三种情况然后跑给我看。这个跑给你看的动作特别关键——它逼着 AI 自己检查一遍逻辑而不是交一版看着对但其实没跑过的代码。注意别完全信任 AI 自测的结果。它写的测试往往只覆盖它自己认为对的路径你仍要把业务里最担心的边界场景单独提出来让它补测。有一次我让它处理一个文件名为空的极端情况它一开始完全没考虑我补了之后它才加了判断。6. 什么项目适合 vibe coding什么项目千万别碰说句实在话vibe coding 不是万能药它的边界比很多人想象中更清晰。用对了它是放大器用错了它就是个会生成花哨 bug 的加速器。我给自己定了一张该不该用的判断表供你参考。场景建议原因一次性脚本、数据清洗、文件批处理放心用结果可立即验证错了重来成本低自己的工具 / 个人小项目放心用维护者和使用者都是你改起来容易原型验证、产品 Demo放心用快速试错比工程质量更重要团队核心业务代码谨慎用长期维护需要可读性和一致性AI 的随机风格是隐患涉及支付、权限、敏感数据的模块别用安全漏洞是 AI 幻觉的重灾区必须人工逐行审高并发、高性能的系统别用AI 生成代码的性能和资源管理普遍偏弱与严重过时技术栈的接口谨慎用AI 对旧版本知识容易过拟合或幻觉我自己的经验法则可以浓缩成一句大白话错了也能改、丢了也不怕的东西尽管 vibe coding错了要出大事、要长期养的东西回到传统开发模式。那些介于两者之间的就用混合模式——关键模块手写、外围胶水代码交给 AI然后再把 AI 生成的代码整体重写一遍重要的部分。最后再分享一个我最近悟到的小技巧vibe coding 的真正分水岭不是会不会让 AI 写代码而是有没有能力告诉 AI 什么不能写。越早学会给 AI 画边界你的项目就越少翻车。我现在每启动一个新项目第一句对话永远是让 AI 复述我的约束条件确认它懂了再开工——这一步省下的时间远超你想象。