最近身边聊得最多的词应该就是 Vibe Coding。我第一次听到这个概念时第一反应是这不就是“让AI帮我写代码”的高级说法等真正在自己项目里完整跑完一套从0到1、再到长期维护的流程后我才意识到它真正的门槛不在“会不会用AI”而在“怎么用自然语言让一个项目的整体气质一直稳下去”。这篇文章我会用最近刚做完的一个项目当案例把完整路径拆开讲怎么选技术栈、怎么写第一份给AI看的“入职文档”、怎么用一轮轮对话把骨架立起来以及最容易被忽略的部分——当项目代码累积到几千行之后怎么继续靠 Vibe Coding 维护而不失控。适合刚开始用AI编程、想系统了解这套工作法的新手也适合已经用了一阵子、却被“AI改完代码后遗症一大堆”折磨的开发者。1. Vibe Coding 到底在编什么从手写代码到指挥代码先说说我理解的 Vibe Coding。这个词能火起来主要是因为 Andrej Karpathy 在一次分享里的说法开发者不再逐行手写代码而是用自然语言描述意图让AI生成具体实现人负责盯方向和结果。听起来很玄但落到日常就是一句话——你不再跟机器说“先建个数组循环一遍判断条件”而是说“我要一个按标签筛选的书签列表页剩下你看着办”。1.1 换个角度看“不写代码”很多人以为 Vibe Coding 等于不写代码这是最大的误解。我自己的体会是它的确把“打字”这部分稀释了但对“判断”的要求反而更高了。你要能从AI生成的一堆文件里挑出对的那部分能看出它哪里想当然还要能在它跑偏的时候用一句准确的提示词拉回来。说白了Vibe Coding 的那个“vibe”不完全是“氛围感”更接近“你对项目走向的掌控感”。AI负责把你的意图翻译成代码但那个意图是不是清晰、边界是不是合理、验收标准是不是明确这些事依然只能由人来定。这也是为什么同一个AI助手在不同人手里产出质量能差出好几倍。这里可以打个比方AI像一个执行力很强的实习生。你可以不自己写方案但你必须知道方案哪里有问题。否则实习生越努力项目越失控。1.2 工作流到底发生了什么变化传统开发里我们习惯的链路是需求分析、技术设计、编码、测试、审查、发布。Vibe Coding 把“编码”这一步外置给了AI链路变成了意图描述、候选实现、人工审查、修正提示词、测试、发布。这个变化带来的最直接收益是速度。比如我想给书签加上标签筛选传统写法要先去翻列表组件再改查询函数再跑一遍界面。现在我可以直接把上下文贴给AI让它一次把查询和UI都改了我只需要做最终的diff审查。一个原本一小时的活压缩到十几分钟。代价是代码风格的高低完全取决于你的约束质量。如果你只丢一句“优化一下”AI就会按自己的偏好改出一堆你不认识的结构。真正玩得好的人都把自己的偏好写成了项目文档让AI照着偏好走。1.3 什么项目适合什么项目别碰根据我一段时间的使用经验Vibe Coding 在下面这些场景非常顺手快速验证想法MVP、原型、Demo今天想明天就要个人项目与内部工具用户不超过几个人对健壮性容忍度高脚本和自动化数据处理、文件整理、批处理任务学习新框架让AI生成示范代码再逐行看明白。但有些场景我建议慎重涉及资金交易、权限边界、安全加密、复杂分布式一致性等系统哪怕AI写得看似专业你也要有足够能力审计每一行。因为这类问题一旦出错不是“改个bug”那么简单。AI能帮你起步但不要把底层信任完全交给它。2. 开工前先立规矩边界、技术栈与AI的“入职手册”很多人拿到AI第一件事就是让它写代码这顺序其实反了。真正高效的开局是先花半小时写清楚项目边界和技术约束。给AI一个清晰的工作环境比给它一百条花哨的提示词有用得多。2.1 技术栈选型优先选AI“语感”最好的组合选技术栈的时候很多同学只看团队熟悉度和性能但 Vibe Coding 场景下还要加一个指标AI对这个技术栈的语料覆盖度。AI训练数据里某个框架出现得越多它生成的代码就越贴近最佳实践踩坑概率也越低。开始之前先交代一下工具。我这边用的就是市面主流的AI编程助手Cursor、GitHub Copilot、Codex CLI 都试过。安装环节基本是装插件或命令行工具官方文档比我写得更清楚。真正决定项目质量的不是工具本身而是后面这些工程习惯。下面的选型表是我自己整理出来的参考组合使用场景推荐选型原因前端Web应用Next.js TypeScript Tailwind CSSAI语料极多部署简单组件范式稳定API/后端Node.js TypeScript或 Python FastAPI两种都是AI最擅长的阵营数据库开发期SQLite生产期PostgreSQLPrisma、Drizzle 等ORM对这两者支持很顺本地脚本/小工具Python 或 Node 二选一AI生成短脚本成功率高调试也方便部署能一键部署的托管平台AI熟悉这类平台配置不折腾服务器反过来我建议避开三类一是太新或太小众的框架AI经常一本正经编API二是重配置的框架容易把时间耗在环境搭建上三是完全自定义的工程规范AI没有参考样本每次都要你手把手喂。我这次做的项目叫 LinkStash一个个人书签收藏工具技术栈就是表里那套Next.js 15 TypeScript Tailwind CSS Prisma SQLite。原因很简单AI对它太熟了几乎所有常见需求都有现成范式我不用教它怎么组织代码。2.2 给AI写“入职手册”比提示词模板更重要的文件用AI写了两个月以后我最大的感悟是别把约束放在对话里要放在文件里。对话里的约束会随上下文丢失文件里的约束每次都能被读到。我在每个项目里都会放一个 CLAUDE.md相当于给AI的入职手册。文件内容不长但每一段都在解决真实问题。下面是我给 LinkStash 写的版本节选# LinkStash 项目笔记每次开发前请先读 ## 项目定位 - 个人网络书签收藏工具当前单用户MVP。 - 核心能力收藏URL、打标签、搜索、分享公开页。 ## 技术栈禁止自行更换 - Next.js 15 App Router TypeScript Tailwind CSS - Prisma SQLiteschema 在 prisma/schema.prisma ## 目录约定 - app/路由与页面 - components/React组件ui/ 放通用组件feature/ 放业务组件 - lib/纯业务逻辑不依赖React - prisma/数据模型与迁移文件 ## 拒绝事项 - 不加鉴权系统除非用户明确要求 - 不引入新的状态管理库 - 不在没有测试的情况下重构公共函数 - 不创建重复的相似组件 ## 常用命令 - npm run dev - npm run lint - npm run test - npx prisma migrate dev ## 决策记录 - 标签用 String[] 而不是关联表单用户场景不需要标签统计、不需要多对多查询。这文件的作用等价于每次开工前给AI做一次 onboarding。它不需要很长但要稳定。过两周你再开新会话第一句就让它“先读 CLAUDE.md 再干活”效果立刻不一样。2.3 明确AI的职权范围生成、重构、答疑要分开还有个容易踩的坑把三种诉求混在一条提示词里。比如“帮我把列表改一下顺便优化下样式再看看有没有bug”——AI会按它自己的想法合并任务结果哪样都没做好。我现在的习惯是严格区分生成任务给足上下文给出验收标准让AI做一件具体的事重构任务先把旧代码贴出来说清新方向严禁夹带需求答疑任务只要解释不要动手。另外有一句话我几乎每次对话都带上“只做X不要碰Y不要增加新依赖。”这句话在维护期救了我太多次。AI默认会往“完整产品”方向走你不拦它它就给你加用户体系、权限、配置中心全是当前用不上的东西。3. 从0到1实操我用自然语言把一个收藏夹做成Web应用下面这部分我用实际做 LinkStash 的过程来展示完整的0到1节奏。不是完美示范但每一步都是我实测跑过的比抽象方法论直观得多。3.1 第一步让AI搭骨架但限定它一次只干一件事第一次对话我没有让它“做个完整项目”那会把AI逼进自由发挥模式。我的第一条提示词是这样的我要做一个个人网络书签收藏工具项目名叫 LinkStash。 技术栈固定为Next.js 15 App Router TypeScript Tailwind CSS Prisma SQLite。 请先完成项目初始化安装依赖创建 app/ components/ lib/ prisma/ 目录配置好 Tailwind让首页能显示 LinkStash 标题。 先不要写任何业务功能不要加鉴权不要引入其他依赖。 完成后告诉我需要手动运行哪些命令。这段提示词的信息密度很高项目定位、命名、技术栈、本次范围、禁止事项、交付要求。AI收到以后生成的是干净的项目脚手架不会跑去建数据库表。我手动跑了 npm install 和 npm run dev首页正常显示。第一步没有惊喜但很稳。为什么刻意只让它搭骨架因为一次给太多需求AI很容易在文件结构上自创风格。我见过同事让AI“顺便加个UI组件库、再配好eslint”结果生成的目录结构每次都不一样。骨架阶段必须步步为营。3.2 第二轮对话数据模型与业务逻辑骨架跑通后我进入第二轮目标只有一个把数据模型定下来。字段结构属于架构决策我自己列好让AI落地。现在为 LinkStash 设计数据模型。 Bookmark 字段id, url, title, description, tags (String[]), createdAt, updatedAt。 请生成 Prisma schema创建并执行 migration然后在 lib/ 下写数据库操作函数 - createBookmark(data) - listBookmarks(filter?: { tag?: string; search?: string }) - getBookmarkById(id) - deleteBookmarkById(id) 先不要涉及认证、用户系统、远程同步。AI很快写出了 schema 和迁移文件还有对应的 CRUD 函数。我会重点核对两件事一是 tags 用 String[] 是否符合我预期二是 deleteBookmarkById 是硬删除还是软删除。AI默认可能写硬删除我这次就是要硬删除所以不用改。但如果不核对它可能在后续版本里默认用了软删除到时候数据会越攒越多。这个环节我自己的经验是Schema 和接口签名必须人审。它们是整个项目的骨架AI改起来快人后续返工也快。骨架期多花的十分钟能换维护期少花十小时。3.3 让UI真正能看组件生成与样式迭代数据层就绪后我开始让AI生成界面。目标是先出一个能用的列表页而不是像素级精美的产品。做一个书签列表页替换 app/page.tsx 页面包含顶部搜索框、标签筛选区、书签卡片列表。 每个书签卡片展示 favicon、标题、URL、描述和标签点击卡片打开对应链接。 新增书签表单放在页面上方字段为 url/title/description/tags提交后刷新列表。 使用 Tailwind 风格保持简洁不需要额外 UI 组件库。这是我第一次体会到 Vibe Coding 的爽点AI生成的页面已经能跑搜索和筛选都能用。不过样式就是中规中矩的默认风格。我想要一点个人项目的气质所以接着补了一句页面视觉尽量清爽一点卡片用圆角加轻微阴影标签用浅色背景空状态显示一句还没有收藏先加一个吧的提示。这类补充很关键。AI的默认审美是安全但无聊你想要什么气质就要在prompt里写出来。空状态尤其容易漏但用户第一天就会碰到值得单独提一句。3.4 联调、验收与第一版收尾功能差不多以后我进入收尾阶段。收尾不是让AI“把所有问题都改了”而是让它把项目状态整理到可以直接交付。请检查 LinkStash 的 lint 和 build 是否能通过不通过就修。 然后写一个 README说明如何启动、如何运行迁移。 最后给 lib/ 里的函数补单元测试覆盖正常创建、空列表、按标签筛不到结果的情况。AI完成后我会亲自手动跑一遍核心路径新增一个书签、列表出现、搜索关键词、按标签筛选、删除、刷新。这一步我一定自己来不依赖AI的“自测通过”。AI测的是函数而我验的是用户流程两回事。跑的过程中发现一个小问题favicon 展示用了外部API单个连接加载偶尔超时影响列表渲染。我把现象发给AI它在卡片组件上加了加载失败占位逻辑问题解决。这个修复很小但让我养成了习惯第一版结束时必须做一次真人视角的验收而不是看AI说“完成”就信。4. 让AI写的代码配得上长期维护的工程契约项目从0到1以后“能不能长期维护”才是真正考验 Vibe Coding 的地方。很多项目死在第一个月不是AI能力不行而是没有建立约束代码风格散乱到人都不想看。4.1 强制目录契约AI的自由很有破坏力Vibe Coding 场景下最典型的问题之一是AI会在不同会话里为同一类组件选择不同位置。今天它在 components/ 下生成一个 SearchBar.tsx明天又会在 components/ui/ 下生成一个 search-bar.tsx。单个看都没问题但一个月后你会得到一仓库互相重复又互相冲突的组件。我的解法就是把目录契约写死在 CLAUDE.md 里并且每次对话都提醒一次“新组件一律放 components/ui/ 或 components/feature/命名统一用 PascalCase 文件kebab-case 路由路径。” 如果AI提出要新建目录我会先问为什么而不是直接同意。我还会定期让AI输出整个目录结构人眼扫一遍。发现类似“components/button.tsx 和 components/ui/button.tsx 同时存在”这种情况就立即合并。这种清扫工作不复杂但不能省。4.2 一次只认一个Diff把维护期改动切成小块长期维护里最重要的一条可能是“一次只让AI做一个独立的小改动”。我吃过亏之后把每个需求都拆成很小的单元例如给列表按收藏时间倒序排列搜索结果高亮匹配关键词删除书签后关闭弹窗并刷新列表。每次改动只涉及一个功能点AI输出后我会只看一个diff。这个diff小到我可以逐行审查错了也容易回退。有个判断方法如果AI在回复里说“这个问题涉及多个模块我建议分三步做”这是好信号如果它说“顺手把相关代码也重构了”就要立刻喊停。重构必须走独立分支不能夹在功能改动里。4.3 让AI写测试但别让它自己批准自己Vibe Coding 能真正走向长期维护靠的不是AI写代码而是自动化测试兜底。AI生成的测试至少在两个层面帮了我一是建立回归防线二是逼着AI自己发现实现里的边界问题。我常用“测试先行”的节奏写法请先为 lib/ 里的 listBookmarks 写单元测试覆盖 按标题搜索、按标签筛选、同时搜索与筛选、空结果返回。 先写测试再根据测试调整实现。这种写法人很舒服的地方在于AI的测试经常暴露出它自己实现里的漏洞。比如它原来没有处理空字符串搜索测试一写就现形。但测试通过不等于你想的“正常”尤其涉及数据的逻辑我也会手动用真实数据点一遍。AI跑绿是必要条件不是充分条件。4.4 让AI自审一段代码最可能在什么场景崩收尾前我习惯加一个审查提示词让AI切换角色请 review 你刚才写的代码重点告诉我最可能在什么输入下崩溃 逐条列出问题并给出修复建议但先不要直接改代码。实测下来这个提示词几乎每次都能逼出几个我没注意的点空数组、URL 非法、重复提交、并发删除等。AI在“实现者”状态下不会主动想这些但一旦让它切到“审查者”它能把风险列得很全。列完以后我决定哪些当前版本修、哪些记录下来以后处理。5. 长期维护不是让AI记忆而是让项目自己有记忆我见过很多人对AI有误解以为它会记得项目的前世今生。实际是AI的每个会话相对独立上次告诉过它的约定下次大概率要重新讲。与其指望AI记性好不如让项目自己带记忆。5.1 为什么说“AI会忘事”拿 LinkStash 举例我最初明确说过标签用 String[]不要建关联表。这个决策在当时的对话里执行得很好但新开一个会话后AI看到需求“给标签加统计”时很可能直接建议“给 tags 建一张新表”因为它不知道当初为什么不用。这不是AI笨而是上下文隔离的天然限制。所以任何“你希望它长期记住”的东西都必须写进项目里让它每次开始工作前主动读。所谓项目记忆不是AI的记忆而是文件系统的记忆。5.2 项目记忆文件怎么写才有用CLAUDE.md 这类文件要避免两个极端要么啥也不写AI纯靠猜要么写成百页文档AI根本不想读。我的写法分三块现状快照技术栈、目录约定、常用命令、关键模块位置决策记录为什么选择某个方案尤其那些“反直觉”的约束变更日志每个里程碑追加一小节让后续会话知道项目进展。例如我会在变更日志里写## 变更日志 ### v0.2.0本周 - 完成标签筛选和搜索功能 - 抽象了 Favicon 展示组件统一处理加载失败 - 已知问题删除书签后搜索框内容不会清空下个版本处理 ### v0.1.0 - 项目初始化、Bookmark CRUD、基础列表页这样每次新会话第一句就是“先读 CLAUDE.md再读变更日志然后告诉我你准备怎么做”AI的稳定性和连续性会明显提升。5.3 维护期的Prompt模板背景、现象、期望、约束进入维护期我基本不用自由对话提需求而是套一个固定的四段式模板。它极大减少了AI跑偏的概率。修Bug版本【问题背景】用户在搜索后点击书签可以正常打开但删除该书签后再搜索时该记录仍出现在结果里。 【当前现象】删除成功提示已弹出但列表没有刷新。 【期望结果】删除后列表立即移除该记录并同步清空搜索状态。 【约束】只修改列表页相关组件或逻辑不要动数据库schema不要改其他页面。 请先给出你的定位判断再实施最小修复。新增功能版本【新需求】列表页增加按收藏时间排序功能默认最新在前。 【涉及模块】app/page.tsx、lib/bookmark.ts。 【约束】保持现有UI风格和工程约定不引入新依赖。 请先给实现方案我确认后再写代码。这套模板之所以有效是因为它把AI从“自由发挥”模式切换成了“解决具体问题”模式。少了背景描述AI会脑补少了约束AI会扩大改动。四要素缺一个都可能多出一堆无关改动。5.4 定期体检重构要小步走且必须走独立分支长期维护里免不了重构。但AI驱动的重构风险更高所以我会严格控制节奏每周花十几分钟让AI做一次全仓扫描重复代码、超长函数、未使用依赖让AI输出一个按收益排序的重构清单不做立即修改挑收益最高的一项放到独立分支里改测试全绿以后再合并。重构提示词请分析 lib/ 目录找出重复逻辑最多的函数给出重构方案。 要求行为不变、测试全绿、禁止增加新依赖。先出方案不要直接改。这样“重构”变成一件可控、可回退的事而不是AI即兴发挥的舞台。5.5 依赖升级与安全修补让AI帮忙但别让它拍板依赖升级是维护期最容易被忽略、也最容易翻车的一项。我的流程是让AI做信息整理我做决策请检查 package.json 中哪些依赖有新版本重点判断哪些是 breaking change。 对照它们的 release notes 给出升级步骤和风险点不要直接改 package.json。安全扫描则是定期跑一次依赖审计把输出贴给AI让它解释风险级别和修补建议。但最终是否升级、什么时候升级我会自己看官方说明和变更日志后再定。AI对“最新漏洞实际影响范围”的判断有滞后性不能全信。6. 踩坑实录那些AI看起来没问题、上线就翻车的瞬间最后这章写的全是复盘。项目做了几周踩过的坑不算少但每一个都让我对 Vibe Coding 的边界更清楚。6.1 坑一让AI修Bug它顺手重构了半个模块最典型的一次LinkStash 的删除逻辑有问题我把现象发给AI。AI分析完以后不仅改了删除流程还顺手把列表查询改成了服务端过滤理由是“这样更合理”。当时看着功能没问题第二天才发现标签筛选失效了因为筛选逻辑被它挪到了另一个函数里。教训其实很朴素提示词里没有明确“只改X不碰Y”时AI真的会主动扩大边界。从那以后我所有修复类提示词都以约束结尾“只修改列表页相关组件或逻辑不要动数据库schema不要改其他页面。”6.2 坑二AI的“过度设计”膨胀又一次我让AI给标签加个颜色属性。本来预期就是给 tag 字段加一个 color 字段在列表里显示出来。结果AI一口气生成了标签管理页面、标签颜色管理API还有一套权限判断。原因不难理解AI训练数据里相似需求大多出现在成熟产品中它默认按完整产品来做。我的对策是在 CLAUDE.md 里加了一句“不做当前需求不需要的设计”并且每个功能prompt都强调“只实现我明确的字段和页面”。如果你发现AI生成的代码里有一个你从没要求过的目录大概率就是它开始自由发挥了。6.3 坑三一个会话拖太长上下文窗口被撑爆AI开始“装作记得”有一阵子我贪图方便在同一个会话里连续加了搜索、标签筛选、导入导出三个功能。到第四个功能时AI生成的代码开始出现全新目录Toolbar组件被它建了四五个变体。它并不是故意的只是上下文太长最早的约定已经在它的“视野”外了。教训是一个会话做完一个垂直功能就提交代码、把关键决策写进 CLAUDE.md然后开新会话。别指望用一个大对话包办所有需求那是最不经济的用法。6.4 坑四错误的“自我修复循环”Debug 是维护期的高频动作也是AI最容易翻车的场景。有次我给AI贴了一个报错它改了一处代码重跑第二个报错再改第三个报错。三轮以后最初的报错还在旁边的功能已经乱了。后来我定了一条铁律AI连续两次修改都没有解决问题就跳出来。先自己看堆栈最高层、看报错行前后的代码、对比最近一次 git diff把问题定位准确以后再让AI修。让AI在“已定位”的前提下修改而不是在模糊报错里瞎猜。6.5 兜底流程我靠什么避免项目被AI改崩这一节是我目前项目的最后一道防线也给这套工作法上个保险开工前先建独立分支vibe/xxxAI改动只出现在这个分支上每次AI输出后人肉过一遍 git diff只保留需要的内容看到不该改的直接 git checkout 还原文件不和AI辩论关键文件比如 prisma/schema.prisma、lib/db.ts在 CLAUDE.md 里标注“禁止AI直接改必须经人确认”每天早上花两分钟看昨天的变更摘要有异常立刻回滚。这套流程下来LinkStash 虽然没有做到零翻车但每个翻车都被控制在了几分钟内。AI出错不可怕可怕的是错误直接落到主干上、还和别的改动混在一起。把它隔离在一个能回滚的分支里Vibe Coding 的风险就变成可接受的代价。