Vibe Coding 这个词火了之后我身边最多的问题不是怎么让 AI 写代码而是让 AI 写出来的东西怎么用。标题里这个排序——说清楚再验收——不是随口一说而是我在几个内部小工具和一个外包协作项目里踩出来的顺序。AI 写代码的速度快得离谱十分钟给你几百行代码可如果你一开始没定义清楚什么叫做好这几百行就会变成一条看不见尽头的返工隧道。这篇文章我想把 Vibe Coding 从动嘴让 AI 干活的玄学还原成一个实在的工作流先写验收标准再生成代码最后按标准逐条验收。无论你是刚听说这个词的非程序员还是写了几年代码但想用 AI 提效的老手这套流程都能直接抄。顺便说一句搜vibe coding 验收时有时会看到一些硬件设备的验收词条这其实是名称撞车但背后那个道理是通用的任何有交付物的活都得先说清验收标准。1. Vibe Coding 不是玄学但也别把它当许愿机1.1 它到底是什么从手写代码到口述验收Vibe Coding 最早是 Andrej Karpathy 提出的说法大意是你不再一行行手写代码而是用自然语言描述意图让 AI 模型完整体现你的想法最后你自己只需要看结果、做取舍。这个过程的重点不是聊得开心而是意图密度——你一句话里包含的细节越多越准AI 落在代码里的行为就越接近你要的东西。我比较喜欢的类比是你现在带了一个阅读理解能力极强、但完全不会读心术的超级实习生。你布置任务时说得越含糊他能发挥的脑洞越大最后你验收时越崩溃。你说把客厅收拾干净他可能把所有东西都塞进柜子里功能上确实干净了但你要找钥匙时会在抽屉里翻半小时。需求里的每个关键词都可能被他极端地执行甚至过度执行。所以 Vibe Coding 本质上不是随便聊聊就出软件而是用自然语言做需求文档用代码生成代替手工实现用验收清单代替测试用例的协作模式。它和传统开发的差别不在写码方式上而在你的角色变化从每行代码都自己敲变成了定标准、看结果、控边界。工具选型反而是最不重要的事真正决定成败的是你有没有把需求想清楚。1.2 为什么验收标准才是 Vibe Coding 的真正瓶颈这个判断不是拍脑袋。传统编码时代人的打字速度、语法熟练度是瓶颈一个功能写一天很正常Vibe Coding 时代生成环节几乎免费瓶颈彻底转移到判断和校验上。AI 十秒生成的功能如果需求本身是错的那返工不是十秒而是你花一小时把代码看懂、再花一小时描述清楚哪里不对、再等它产出 v2——一个简单功能可以这样耗掉一个周末。而验收恰恰是大家最容易偷懒的环节。很多教程都在教你怎么写 prompt、怎么调模型参数却很少有人告诉你代码生成之前你就该把什么算完成了写下来。这其实是敏捷开发里 acceptance criteria 的老概念在 AI 写码时代重新变得关键。原因很简单AI 不会问你说得不够清楚我能不能跟你确认一下它只会顺着你字面上的话往下做等于给你返回一个包装精美的错误方向。延迟定义标准等于把风险滚雪球越到后期修复成本越贵。我知道很多人第一次听到 Vibe Coding 时第一反应是终于可以不用学代码了。现实是代码可以少写但需求建模和验收能力反而变得更重要了。这也是我把说清楚再验收放在最前面的原因——这是整套方法的承重墙没有这面墙后面所有花里胡哨的 prompt 技巧都撑不住。2. 说清楚把一句含糊需求拆成 AI 能执行的验收清单2.1 验收标准的三个层次功能、质量、呈现写验收清单之前先搞明白要覆盖哪几类。我一般分成三层层次要回答的问题示例功能层做什么、不做什么、输入输出什么输入 PDF输出 Markdown 摘要文件质量层多快、多稳、错误怎么处理、资源占用20 页 PDF 10 秒内完成空文件退出码为 2呈现层用户看到什么、各状态是否完整加载中有进度提示失败时有重试按钮功能层解决有没有质量层解决好不好呈现层解决像不像给人用的。很多 AI 项目翻车都是因为只写了功能层帮我做个批量重命名工具结果 AI 交了个能跑但一遇到重名文件就静默覆盖的作品——你根本没给它定义过撞名时该怎么办。质量层的缺失是这类事故的根源。在动手让 AI 写代码前把这三层各列两三条就已经比大多数人的起点高一大截了。注意一点验收标准要写该怎样不要写该怎么实现。比如加载时间小于 1 秒是标准用 CDN 或者用 HTTP/2是实现方案AI 最擅长的就是把你的方案做得很好看但标准换了味道就不是你要的东西。2.2 把感觉翻译成条件坏例子与好例子这个环节最难因为我们的日常表达充满了感觉词。下面是几个我看过太多遍的对话以及它们应该被翻译成什么样子你本来会说更好的写法可测试做个好看的首页首屏 1 秒内可用按钮最小 44x44px空状态有图标和一句引导文案处理一下异常网络超时 2 秒内出现重试按钮文件为空时提示未检测到内容重复提交时按钮置灰并显示 loading让导出方便点一键导出 CSV 和 PDFCSV 用 UTF-8 编码导出超过 100 行时按日期分页速度要快单次查询接口 P95 延迟低于 300ms批量 500 条数据 5 秒内完成把每个验收项写成当...时系统应该...并且...的句式几乎立刻就能暴露需求的空洞。比如当上传的文件是空文件时系统应该提示用户并终止处理并且不生成任何输出文件。这句话同时定义了触发条件、行为、和副作用边界。当一个条件能用是/否判断时它才算真正进入了验收清单。还有个小技巧验收清单必须包含不做什么。告诉 AI这个版本不做多用户登录不做图片识别比告诉它你要厉害一点有用得多。范围是标准的一部分越早写死越安全否则 AI 会在你不管的地方自行发挥给后面埋雷。2.3 交付物不同验收粒度完全不同同样的说清楚在不同类型的交付物身上关注点完全不一样。我按场景分开说Web 页面除了主流程还要验状态覆盖——加载中、空数据、报错、断网各自长什么样以及响应式断点、浏览器兼容性。我会写明360px 宽不出现横向滚动条Chrome 和 Safari 都要正常这类句子。脚本与命令行工具验输入边界、退出码、幂等性。比如重复运行不覆盖旧文件目录不存在时报错并提示正确用法。API 服务验接口超时、错误码、鉴权、数据一致性。请求 100 次错误率低于 0.1%无权限返回 403 而不是 500。嵌入式程序验资源约束、实时性、外设协议。内存占用上限、任务周期是否满足、引脚和字节序是否符合硬件手册。拿嵌入式 vibe coding 来说这块的验收标准是最严格的因为硬件上没法随时热修复代码错了轻则重启重则可能影响整个系统。所以我不建议在嵌入式场景里让 AI自由发挥每条验收标准都得能上板实测编译通过、单元测试通过只能算基本盘最后必须拿真硬件跑一遍清单。3. 验收闭环让 AI 先自证再人工兜底3.1 把验收标准变成自动化测试验收标准和测试用例在 AI 生成的场景下几乎是同义词。最有效的方法不是让 AI 生成完代码再由你手动一条条验而是把验收标准直接投喂给它让它先把标准翻译成测试代码。测试先行的逻辑在这里特别顺非程序员做不到读懂代码但完全可以读懂这个测试在验什么而 AI 写的代码自己也未必每行都有把握测试就是它自证清白的方式。举个真实例子。我要一个从会议纪要里提取关键词的小函数验收标准里有一条输入纯文本输出出现频率最高的前 5 个词并忽略停用词。我会把这条直接写进 prompt并要求它先写 pytest 用例再实现比如def extract_keywords(text: str, top_n: int 5) - list[str]: 从文本中提取 top_n 个高频关键词忽略停用词。 def test_extract_keywords_ignores_stopwords(): text 项目 项目 项目 的 的 的 验收 验收 标准 标准 标准 标准 assert extract_keywords(text, top_n3) [标准, 项目, 验收]AI 写完测试和实现后直接在本机跑一遍红了就让它改绿了才进入人工环节。这套循环能把功能层的大部分问题消化掉你真正需要动脑子的只剩下测试覆盖不到的地方。我实测下来凡是让我先写测试的 prompt最终交付质量明显高于直接给我实现的请求前者返工次数平均会少一半以上。3.2 人工验收不能只看能跑自动化测试解决了确定性判断但能跑不是验收的全部。我用 Vibe Coding 完成过几个工具后的体会是AI 很喜欢吞错误。你会发现程序在大路线上表现得体但异常分支里全是静默失败——比如文件没权限时它直接退出而不告诉你网络请求超时它重试三次后没任何日志你查半天发现它把错误掩盖在了空的 except 块里。所以人工验收阶段我基本只做三件事看入口和退出逻辑、看数据层的读写方向、看依赖和配置。具体说入口文件要看参数校验有没有兜底数据处理要看会不会把不该删的删了、会不会把内容写成别的编码配置和依赖要看版本来路是否干净、有没有明显不该出现的权限要求。其余业务代码可以信任测试但这三类不能跳过因为它们对应的是数据安全、资源消耗、部署稳定性这些直接影响用户的东西。另一条经验验收时把日志也当作交付物来验。一个工具如果运行失败时只抛出Error那它还不算完成验收标准里可以加一条所有错误必须有可读信息并建议下一步动作。这类标准 AI 很容易满足但对日常使用体验的提升是巨大的。注意自动化测试全绿不等于业务正确。AI 可能把测试和实现写得互相配合绕过标准里真正难的部分。所以哪怕测试过了我也至少要肉眼看一遍关键逻辑尤其是删、写、改权限这类不可逆操作。3.3 小步迭代每次验收通过都留一个版本AI 写代码有一个让人哭笑不得的特点修一个 bug 可能顺带重写半个文件。所以改错地方和改对但破坏了别的功能是 Vibe Coding 项目最大的两个回归风险。我的对策很简单把大需求拆成小模块每个模块完成一轮定义标准 → 生成 → 自动测试 → 人工抽查验收通过立刻 commit甚至打一个 tag。比如我常用的版本注释方式是 git tag v0.1-accepted 这样。之后每次迭代如果 AI 越改越乱直接 checkout 回上一个 accepted 版本换一种表述重新开始成本也就是十分钟。很多 AI 对话走偏之后硬着头皮继续聊是最亏的上下文污染会让它越改越偏回到验收过的版本带着更清晰的差异化需求重新开对话反而快得多。4. 实操走查一个小项目从需求到验收的完整记录4.1 写验收清单先花半小时把标准定死为了演示我挑了一个很多人都会用到的场景把一场会议录音的转写文本变成一份带关键词的会议纪要。现场的输入是纯文本转写稿目标输出是 Markdown 文件。我先花大概三十分钟把验收清单写下来而不是直接让 AI 开工。清单大约长这样功能层读取 .txt 输入输出 .md 文件摘要部分按决议/待办/风险三类组织关键词取高频词并忽略停用词不接入任何在线服务数据处理全程本地。质量层20 页文本 10 秒内出结果空文件提示并退出码 2超长文本10 万字以上不崩溃重复运行时不会覆盖旧文件而是生成带时间戳的新文件。呈现层Markdown 有标题层级关键词用逗号分隔文件尾部附生成时间与输入文件名。注意这里我把不做什么也写进去了不接入在线服务是为了避免它顺手调一个 LLM API把纯本地工具变成有隐私顾虑的东西。范围写死边界才能立住。4.2 带着清单去写代码Prompt 里必须带验收标准我用的工具是终端里的 Claude Code不过这套写法换到 Cursor、Cline 上一样适用。初始化时我在项目目录放了一个 CLAUDE.md里面就是那份验收清单并且加了这么一句规则每次修改后必须运行项目里的测试命令并报告哪个验收项通过、哪个未通过。然后发出的初始 prompt 长这样项目会议纪要关键词提取工具。 输入一行一个文件路径。 输出同名 .md 文件。 验收标准见 CLAUDE.md请严格按照标准实现。 第一步先写 pytest 测试第二步实现第三步运行测试。 测试全部通过之后再交付不要在交付说明里解释代码设计。这段 prompt 本身平平无奇但有三点很关键验收标准放进了长期记忆文件而不是对话里要求先测试后实现禁止解释型输出。第二条可以避免 AI 给你一大段设计思路然后交一个跑不起来的代码第三条能让你把精力放在结果而不是氛围上。初版生成大概花了二十多分钟包括它自己跑测试、修了两轮小问题。第一轮测试通过后我进入人工验收环节发现了个测试没覆盖的问题输出目录不存在时程序直接崩溃而验收标准里没写这条。我当场补了一条验收标准进清单再让它修。这个动作就是说清楚再验收的现场版——验收过程中发现的新边界第一时间回流到标准本身。4.3 验收、记录、返工一次真实的迭代人工验收阶段我按清单逐条过验收记录长这样编号验收项预期结果实际结果结论1读取 txt 并输出 md生成同目录 md 文件通过通过2摘要分三类组织决议/待办/风险分节通过通过3空文件处理提示并退出码 2未通过无提示直接退出码 1返工4重复运行新文件带时间戳通过通过510 万字长文本不崩溃通过通过6输出目录不存在提示或自动创建未定义补标准后返工两处返工的修法相差不大把失败信息喂回给它附上最小化修改不要碰无关代码的约束。第二次返工只花了几分钟。整套流程下来从定义到验收完成不到三小时其中真正需要我动脑的时间大概占了三分之一剩下的都是 AI 自己在写、在测、在改。这就是有验收标准和没验收标准的差距后者可能一个周末搭进去前者三小时收工。4.4 换个场景这个流程对非程序员同样适用我不建议只有程序员用这套方法。我身边有同事完全不写代码但也用 Vibe Coding 做成了不少事批量整理网盘文件、把几十个 Excel 合并成交报表、给团队做意见收集表单的后端逻辑。他们的共同特点不是会代码而是会列完成条件。比如整理网盘这个需求普通人会说帮我整理一下文件但这位同事写下来的完成条件是按年月建文件夹、重复文件跳过并写日志、程序结束打印移动了 N 个文件跳过了 M 个重复文件。就这五句话AI 就能交出可用脚本。非程序员可能看不懂一行代码但完全可以验收每一个条件——这也正是说清楚再验收对所有人都有意义的原因。5. 常见问题与排查技巧实录5.1 AI 说做不到先学会拆我很常遇到这样的对话帮我把 PDF 里表格提取成 ExcelAI 回复需要第三方库可能比较麻烦。别急着换工具先把它说的比较麻烦拆开。麻烦通常来自三个地方PDF 扫描件需要 OCR、表格结构复杂、表格不在同一页。对应地拆成三步走先让它完成文本型 PDF 提取再单独做扫描件 OCR 模块最后才合并成一键脚本。每一步都有自己的验收标准代码量小、验证路径清晰AI 的完成率会高得多。如果拆完还不行那就是任务本身超过模型能力或者模型上下文容纳不下整个方案。这时候我会换一个更强的模型或者换一种思路实现比如绕开表格识别直接让用户把 PDF 另存为 Excel 再合并。5.2 越改越乱的死循环怎么破AI 越改越乱几乎是每个 Vibe Coding 用户必经的坎。通常的表现是改 A 功能时把 B 功能搞坏了你再让它修 B它又把 C 弄坏。这时候别继续对话对话历史越长AI 越分不清哪些是新要求、哪些是旧约束。我的做法是开一个新对话把项目背景压到最短一段话需求、验收清单、刚才改坏的现象描述。然后明确告诉它基于最近的 git 版本继续只修这一个问题不要重构其他代码。很多新手舍不得丢掉对话历史觉得重开麻烦但实测下来重开反而更快。上下文是成本不是资产。提示把验收清单和测试命令放在独立文件里如 CLAUDE.md、AGENTS.md这样换模型、开新对话时AI 都能在第一步读到约束不用反复口头叮嘱。5.3 AI 很礼貌但没解决问题要求先写测试有时你会遇到一种配合型表演AI 回复好的我已经完成了然后你跑一下发现压根没变化或者代码里有大量注释但核心逻辑粗细不精。这时候我会把 prompt 改成请先创建测试文件并跑一遍给我看再写实现让它的交付物从解释变成证据。我还会加一句改动列表里必须写清楚你改了哪几个文件、每个文件动了哪一行级别的内容。这个约束能在不增加多少成本的情况下逼着它老老实实做最小改动。如果你连这个都不想要可以直接要求用 diff 形式输出所有改动禁止大段复制粘贴。5.4 验收标准不是越细越好前面一直在强调标准要具体但具体不等于多。我见过有人把验收清单写到八十多条连按钮圆角半径、图标颜色都定死结果 AI 每改一个地方都要重新适配十几个条件进展非常缓慢。标准的关键路径可以写死但外观和实现方式应该给 AI 留自由度。我的取舍原则是功能层和质量层的风险大写死呈现层只写状态齐全、无横向滚动条、可读性达标这类底线其余让 AI 自由发挥。如果 AI 的产出太丑再单独提一轮视觉修改。约束的颗粒度应该和你对风险的容忍度成正比而不是和你对控制欲的满足感成正比。5.5 安全红线哪些东西不能交给 AI这个必须单独说。AI 生成的代码尤其是让它从零写起的项目有两类风险一是你直接把生产环境的密钥、数据库信息、内网地址贴进对话等于把敏感信息外包出去二是它生成的代码里可能带进来源不明的依赖或者默认开放了不该开放的权限。我给自己定的规矩是生产相关的东西不进 AI 对话AI 生成的依赖清单必须人工过一遍确认版本和来源涉及支付、权限、用户数据的代码无论测试多绿都强制人工 review。Vibe Coding 适合原型、内部工具、非关键链路核心业务还是要有真人在关键位置把关。这和技能无关是责任心的问题。6. 我的工具清单与使用习惯6.1 工具按场景分工别指望一个工具打天下市面上vibe coding 工具很多我常被问哪个最好。实际上工具之间差距没那么大差别主要在适用场景工具适合场景我的建议CursorIDE 内写网页、小应用边看边改新手首选所见即所得Claude Code命令行 agent脚本、后端逻辑自动化程度高适合带验收清单的批次任务Cline / Roo Code开源VSCode 内使用想看清楚 AI 每一步干了什么时用GitHub Copilot补全代码、提效不适合当 agent 使适合辅助人工写码我的习惯是小工具和脚本用 Claude Code因为可以提前把 ACCEPTANCE.md 放在项目里让它自己读页面类项目用 Cursor因为它能直接预览效果验收更快想搞清楚 AI 行为时切到 Cline看它一步步怎么操作。工具可以换工作流不要换——定义清楚 → 生成 → 自动验证 → 人工验收 → 记录版本这个闭环在哪套工具里都一样。6.2 嵌入式 Vibe Coding 的额外纪律本来想聊聊嵌入式因为这块的搜索热度也不低。嵌入式场景里 AI 写 C/C 代码没问题问题在于PC 上能跑和板子上能跑是两回事。我给这块定的纪律是四条交叉编译必须通过模拟器和单元测试只能证明逻辑不能证明时序硬件在环测试的验收项要写死 CPU 占用率、内存峰值、外设时序烧录前必须人过一遍中断处理和资源释放的代码。比如一个电机控制任务验收标准会写控制周期 1ms 内完成CPU 占用低于 30%异常断电时电机保持刹车状态。这些条件 AI 无法自行验证只能你列出来、它实现、你上板测。嵌入式 Vibe Coding 不是不能用而是验收标准必须比 Web 场景更早定、更严格地定因为硬件出错没有 CtrlC。6.3 把验收清单变成团队流程而非仪式最后说说团队协作。我带的人里有经验的工程师容易把验收清单当成给 AI 看的 prompt 模板生搬硬套没经验的人容易把它当成开工前要填的表格填完就忘。这两者都偏离了本质。验收清单是团队和 AI 之间的共同语言它存在的意义是让什么叫做好这件事可争论、可确认、可传承。所以在团队里我会把每次项目的 ACCEPTANCE.md 留下来攒成一个内部模板库。下次同类需求直接复制改不用从零开始写说清楚的部分。这个准备工作会让后面每个项目的返工成本肉眼可见地下降里面的条条框框不是流程仪式而是真实踩坑的记录。我个人在实际操作中的体会是Vibe Coding 最自由的地方不是让 AI 放开发挥而是让你的需求表达能力可以完全展开。代码里有 80% 的活可以让 AI 干但那 20% 的定义清楚必须自己来。最后再分享一个实用小习惯在项目目录里放一个 ACCEPTANCE.md每完成一个迭代就更新一次让 AI 自己读它、自己报告验收状态。试过之后你会发现说清楚再验收这四个字能帮你省下比想象中多得多的时间。