Vibe Coding这个词第一次砸到我脸上的时候我正在跟一段AI生成的、看起来毫无问题的代码搏斗——它能跑能出结果但没人说得清它为什么要这么写。而比说不清更可怕的是它只在特定输入下正常参数稍微一变就崩。那一瞬间我突然意识到我们这批人已经不知不觉进入了Vibe时代但绝大多数人手里的开发流程还停留在上一代代码是写出来的、产出是可控的假设上。当代码变成AI氛围感地生成出来时你真正需要管理的已经不是代码本身而是围绕它的整套工作流。这就是我想在这篇Vibe时代生存法则第七篇里聊透的东西Workflow工作流与流程管理。它不是教你某个IDE快捷键也不是再堆一份提示词模板而是讨论一个更底层的问题——当AI承担了越来越多的编码动作我们要靠什么来保证项目依然可预测、可测试、可交付。我会把我在真实项目里用到的分层工作流、AI Workflow YAML的解析执行思路、Vibe与Spec-Driven的切换策略以及一堆踩出来的坑全部摊开来讲。1. Vibe Coding不是不写代码而是把代码交给流程先明确一个认知Vibe Coding从来就不是不写代码更不是瞎写代码。它是把编码动作从逐字符敲击变成意图表达与结果验收而AI负责把意图翻译成具体实现。这个转变看起来只是工具升级实际上把整个开发过程的控制点全挪了位置。1.1 从写代码的人到编排流程的人以前我们写代码控制点在手底下每一行都是自己敲的出问题顺藤摸瓜非常直接。Vibe时代不一样AI生成代码的节奏快、量大、风格统一但经常带着一股看起来对的错觉——变量命名合理、注释齐全、结构整齐可一旦涉及业务边界、隐式状态、异常分支它往往会选择一条最像正确答案的路径而不是最针对你这个场景的路径。所以我在团队里反复强调一句话Vibe Coding时代你的职责不再是把手放在键盘上敲出每个字符而是变成一个流程编排者。你要决定AI在哪个阶段介入、以什么上下文介入、产出物交给谁验收、验收标准是什么。这跟导演很像你不演每一个角色但你决定每个角色在什么时候、以什么状态登场。我见过太多人把Vibe Coding用成了高级版百度搜索——把需求丢给AI生成一段代码复制进项目跑一下没问题就提交了。这不是Vibe Coding这是碰运气。真正的Vibe Coding一定是带着流程意识去用让AI在约束明确的小单元里发挥而不是在最模糊的全局里自由发挥。1.2 没有Workflow的Vibe Coding就是大型事故现场没有工作流约束的Vibe Coding会以肉眼可见的速度失控而且失控的方式非常统一我总结成三个阶段第一阶段代码量暴涨。AI生成速度快团队产出量一夜之间翻了几倍代码评审的人手完全跟不上很多代码根本没人细看就合并进去了。第二阶段项目结构开始面粉化。每个AI实例都在自己的上下文窗口里做局部最优解你让AI A加了一个工具函数让AI B又加了一个功能类似的两个函数名字不同、边界略有差异没人去收敛。代码库里的一次性代码越来越多。第三阶段回归成本失控。改一个公共模块你不知道有哪些地方依赖了它的行为细节因为依赖关系是AI随手建立的代码评审也没看出来。此时任何一次重构都像拆炸弹谁都不敢动。我踩过最痛的一次是一个内部工具的鉴权逻辑被AI好心统一加到一个公共拦截器里初看很整洁但有两个外部回调接口根本不该走这个拦截器结果线上回调全部401。那个问题排查了两天最后定位到是AI根据所有接口都需要鉴权这个抽象描述自作主张做的事。代码本身没有错错的是流程里没有人给AI限定这个拦截器的作用范围。从那以后我彻底明白Vibe Coding需要的不是更强的AI而是更硬的工作流边界。2. 我如何拆解一套可落地的AI开发工作流先声明下面这套拆法不是从某本书上抄来的是我在几个真实项目里反复调整出来的大概率也不适合所有人。但它的分层思路我觉得是通用的——把AI开发工作流拆成三层需求澄清层、生成执行层、验证反馈层。每层有独立的输入、产出和准入条件。2.1 需求澄清层先让AI学会问问题这一层负责把模糊的人类想法转成AI可以执行的任务描述。很多人跳过了这一步直接丢一句帮我做个用户登录功能就完了。这句话对AI来说信息量太低了登录方式是什么手机号还是邮箱第三方登录接不接Token怎么存刷新策略记住登录状态多久错误次数限制——AI只能自己猜而猜的结果就是一系列隐形的技术债。我的做法是把需求澄清当成一个必须完成的Gate。你跟AI的第一轮对话不应该是给我写个XXX而是让AI先问你问题。你可以直接说你现在是一个资深后端工程师我正在做一个社区类产品的登录模块在你动手写代码之前请列出你需要我确认的所有关键决策点包括认证方式、会话策略、密码策略、第三方接入、异常处理边界等逐个领域地问。实测下来让AI先提问有奇效。它会在这个过程中把你的模糊需求撑开成一个决策网你看着它列出来的问题会发现自己原来有一堆细节没想过。你回答完这些问题之后把问答记录整理成一份需求基线下一步生成执行层就只依据这份基线来做。这一层的关键产出物不是代码而是一份AI可执行的需求基线。2.2 生成执行层以最小可运行单元推进需求基线有了接下来不是让AI一口气生成整个项目而是拆成最小可运行单元。所谓最小可运行单元我的定义是能够独立被验证、对整体项目有明确增量价值的一个功能切片。举个例子做登录功能我不会让AI一次性生成完整登录模块而是拆成几个推进步骤数据库表结构与实体定义注册接口含参数校验登录接口含密码哈希与Token签发当前用户信息接口含Token解析登出与Token失效处理每个单元之间有一个天然的验证点上一单元通过了才进入下一单元。这个验证点必须包含真实的测试不是AI说能跑就算数。在执行每一单元时我提供的上下文是项目根目录结构、本次单元要修改/新增的文件清单、相关文件的现有代码、需求基线中的对应片段。不要让AI自己决定改哪些文件——它的全局判断力没有你想象中那么强。2.3 验证反馈层自动化测试是vibe coding的刹车片如果说Vibe时代有什么东西绝对不能省略那就是自动化测试。我甚至愿意把话说得更极端一点没有自动化测试的项目不配用Vibe Coding。为什么因为Vibe Coding的产出速度天然快快到你无法用人肉评审来保证质量。AI可以一分钟生成一百个函数你一分钟只能审三个。人肉评审永远追不上AI生成速度唯一能跟它赛跑的就只有自动化验证。所以我的工作流里验证反馈层是刚性的每个最小可运行单元必须附带对应的单元测试测试用例覆盖正常路径和两条以上的异常路径单元通过后跑一次集成验证每次合并前全量回归必须通过。这一层不通过代码不进入下一步。我在这个环节还有一个习惯不只让AI写实现代码也让AI写测试代码但测试代码的验收条件由我亲自定。我会明确告诉AI你实现的这个注册接口需要覆盖手机号格式错误、密码过短、用户已存在、正常注册成功这四个场景的测试。这样AI去写测试人去做场景设计各司其职效率和安全都保住了。3. Workflow的载体从脚本到AI Workflow YAML聊完了分层再聊落地载体。现在AI Workflow YAML解析执行这个概念在圈子里很火我觉得它踩中了一个真实痛点当工作流变得复杂它得有一个可存储、可版本管理、可被程序解析执行的载体不能只活在对AI的连续对话里。YAML刚好适合干这个活。3.1 为什么YAML成为AI工作流的事实标准你可能第一反应是为什么不直接用Python脚本为什么要用YAML这种配置语言来描述工作流我的理解是脚本描述的是怎么做的每一步动作而工作流要描述的是什么条件下、按什么顺序、把什么输入交给什么执行者编排关系。这两者有本质区别。脚本把流程写死了一旦要调整某个环节的输入来源或切换不同的执行策略你得改代码。而工作流配置应该做到改流程不改代码。YAML的优势在于三点第一可读性好非程序员也能看懂流程结构第二天然支持嵌套和列表用来表达步骤、分支、并行关系很方便第三生态成熟Python、Node、Go都有成熟的YAML解析库几行代码就把一个工作流配置加载成内存里的结构体。我做过的实践里AI Workflow YAML描述的是这样一个流程定义每个步骤的角色prompt role、输入input、执行器executor比如是调用GPT还是调用本地脚本、输出存储路径output、下一步的跳转逻辑next/on_failure。这样工作流的每一步都是可追溯、可替换的。3.2 一个真实可用的Workflow YAML长什么样我把我常用的一套代码评审工作流配置简化后贴出来你看完大概就明白了name: ai_code_review_workflow version: 1.0 description: AI代码评审工作流负责在代码合并前自动审查变更内容 execution: - id: collect_diff executor: git_diff_loader input: base_branch: main head_branch: feature/ai-auth output: ${workspace}/diff.json - id: generate_review_report executor: llm_executor input: model: gpt-4o system_prompt: 你是一名资深代码评审工程师关注安全性、边界条件、性能隐患。 user_prompt_template: | 请审查以下代码变更输出格式要求 1. 高风险问题 2. 中风险问题 3. 低风险建议 变更内容 {{ diff_content }} output: ${workspace}/review_report.md next: on_success: notify_developer on_failure: log_to_human_queue - id: notify_developer executor: webhook_sender input: target: ${developer_webhook} payload: title: 代码评审完成 report_path: ${workspace}/review_report.md这段配置表达的流程是先把Git分支间的diff拉出来再交给LLM执行评审产出报告之后通过Webhook通知开发者。每一步的输入输出都结构化地暴露出来想替换某个环节只需要把对应executor换掉就行其他步骤不用动。3.3 解析执行的取舍要灵活性还是要确定性YAML写好之后接下来是解析执行。这套逻辑我建议你既有现成轮子就优先用现成的比如Temporal、Prefect这类工作流引擎原生就支持YAML定义流程底层帮你处理了重试、超时、并行、状态持久化这些麻烦事。如果项目很轻不想引入重依赖那就自己用PyYAML加载配置然后按拓扑序执行每个step。自己写的核心代码其实不长我做过的最简版不到两百行关键是两步第一把YAML转成一个DAG结构第二步按依赖关系调度执行器。但在设计你自己的执行器时会碰上一个非常典型的取舍要灵活性还是要确定性。灵活性的意思是让工作流在执行过程中可以动态调整——比如LLM发现当前输入信息不足可以主动追加一个信息收集步骤。确定性的意思是同样的输入永远会走同样的流程、产出同样的结果。我的建议是Vibe Coding场景里以确定性为主、灵活性为辅。因为AI本身已经是最大的不确定性来源了如果工作流框架再做动态编排你的系统行为就完全不可预测了。稳妥的做法是YAML里把主干流程定死只允许在预设的几种分支之间做选择不允许AI工作流运行时随意生成新步骤。这个约束能让你保住最后一条可测试的底线。4. 从Vibe到Spec-Driven用契约对抗失控Vibe Coding时代还有另一个绕不开的话题Spec-Driven Development规范驱动开发。我看了很多讨论总觉得大家把Vibe和Spec对立起来了好像要么就全Vibe要么就全Spec。我的实践经验是这两者不是二选一而是要在工作流的不同环节混合使用。4.1 Spec-Driven的核心逻辑与我的第一反应我第一次接触Spec-Driven的时候第一反应是这东西跟Vibe Coding的氛围感完全相克。Vibe Coding强调的是让AI自由发挥、快速试错Spec-Driven强调的是开工之前先把所有行为契约写清楚这不就是要给AI戴上紧箍咒吗但后来我发现自己理解偏了。Spec-Driven的核心不是管住AI而是把不确定性前置。它要求你在让AI写代码之前先把这些契约定下来输入输出接口、数据结构定义、业务规则、边界条件、异常行为。这些契约一旦明确AI的发挥空间变小了但出错的方式也变得可控了。我在实际项目里对Spec-Driven的用法是把契约落到三个层面接口契约函数的输入参数、返回结构、异常类型用类型标注和Schema定义数据契约数据库表结构、事件消息体、缓存Key规则用Migration和JSON Schema定义行为契约特定输入下必须产出特定输出的规则用测试用例定义4.2 Vibe与Spec的切换时机那什么时候该Vibe什么时候该Spec我现在用的是这样一套切换逻辑如果任务边界清晰、失败成本可控、可以快速验证结果用Vibe方式。典型场景写一个转化工具函数、生成一个CRUD页面、写一段数据清洗脚本。这类任务让AI自由发挥效率极高出错也容易发现。如果任务涉及多模块联动、公共接口设计、数据一致性、资金/权限/安全相关逻辑用Spec方式。典型场景设计一个系统间的API契约、实现一个支付回调、设计一套多租户权限模型。这类任务一旦让AI自由发挥你后续的成本远大于你省下的那点时间。我的经验是一个混合模式可以简单概括为两端Spec、中间Vibe前言部分用Spec把边界框死包括文件范围、接口签名、数据Schema、验收测试用例正文实现部分让AI用Vibe方式自由发挥提交之前再用Spec验收。这套模式在几个项目里验证下来成功率明显比纯Vibe高。原因也很简单AI最擅长的是在约束清晰的场景里做高质量的填空它最怕的是让它自己给自己出题。你把题出好了它填得又快又好你让它自己出题自己答它经常跑偏。4.3 我的验收式提交法在混合模式下我每次让AI改完代码不只是看一下代码就收工而是会跑一套验收追问需求基线上列出的每个点有没有对应的实现测试用例覆盖了哪些场景异常路径是否覆盖了有没有改动需求范围之外的文件公共接口的行为有没有发生非预期的变化这四问看起来简单但每次AI的提交能全部通过的情况并不多。尤其是第三问AI经常改一个Bug的时候顺手把旁边无关的代码也动了而且不告诉你原因。我印象最深的一次让AI修一个日期解析的Bug结果它把整个日期工具类的实现都重写了还顺手改了三个调用方的代码来适配新实现。测试虽然全过但代码评审的时候我人都麻了——这个改动范围跟需求完全不相干风险敞口大得离谱。从那以后改动范围必须与需求一致就成了我验收清单里最优先的一条。5. 可测试的工作流才是好工作流前面聊了这么多工作流设计最后都指向一个质检标准这套工作流本身能不能被测试如果工作流本身不可测试那它就是一个高级摆设关键时刻掉链子你都不知道去哪儿查。5.1 Workflow测试的三种粒度我理解Workflow测试分为三种粒度从低到高挨个说。第一层单步测试。测试工作流里的每个执行器本身正确不正确。比如一个执行器负责调用LLM并解析返回结果那你就给它构造不同的LLM返回内容包括正常格式、格式残缺、纯文本、空内容确认解析逻辑都做了正确兜底。第二层局部流程测试。把工作流的一部分步骤串起来测。比如从拉取diff到生成评审报告这两步联动确认diff数据能正确注入到prompt模板里LLM返回的结果能正确落盘。第三层全链路测试。模拟一次完整的流程执行真实地构造一个有已知问题的代码变更跑完整条工作流确认最后的输出里包含了我们预设进去的那个问题。这里要注意的是测试AI相关的工作流最忌讳用力往上堆用例。因为LLM的生成有随机性同样的输入可能每次都产出一段措辞不同的结果。我的做法是做结构校验不做文本完全匹配。比如校验报告里是否包含高风险问题这个章节、是否包含文件路径、是否包含可执行的行号建议而不是逐字比较整段报告。5.2 给AI工作流建立回归测试为什么要单独强调回归测试因为AI工作流的回归问题很容易被人忽略工作流步骤的顺序调整了、prompt模板微调了、底层模型从GPT-4换成了GPT-4o这些改动都可能让整个工作流的输出质量发生漂移。我自己的项目中是这么建立的每生成或修改一条prompt模板之后我会保存几个经典的金样本输入Golden Sample。所谓金样本是那些对应的表现为理想评审意见的真实代码变更。每次prompt模板变动就用这几个金样本重新跑一遍工作流人工或LLM as a Judge看新输出是否还保留理想意见的关键点。如果关键点丢了说明这次prompt调整是回归得重新改。这套做法本质上就是把prompt调整当成一次代码变更来管理有变更记录、有验收用例、有回归检查。这是我目前觉得比较有效的模型。5.3 实测中的失败案例与修复过程讲一个我在做Workflow测试时真实踩过的坑很有代表性。我们的一个AI表单生成工作流定义了一个步骤把用户填的自然语言需求传给LLMLLM返回JSON格式的表单配置。最开始跑得很顺后来某个版本里业务方要求支持多语言我把prompt模板加了一句所有label字段必须返回多语言字典。结果当天就有几个用户反馈表单标题显示成了一段原始JSON结构字符串。查了一圈发现根因LLM在极少数情况下返回的不是纯JSON而是json ...这种带Markdown代码块的内容。以前实现里有一个正则抽取JSON的步骤但在多语言模板改动时这个正则被当成冗余逻辑清理掉了。于是那段Markdown标记就直接被当成label字段的值塞进了配置里。修复很简单把JSON抽取步骤加回来但在测试上我做了两个改进第一给单步测试补了一批含Markdown代码块、含前后说明文字、含BOM头等异常格式的LLM返回用例第二全链路测试里加了一个专门检查所有配置字段都是纯JSON类型不允许出现字符串形式的JSON内容的断言。这个案例告诉我AI工作流里的每一个看起来冗余的处理步骤很可能都是之前某个线上问题补出来的兜底逻辑。删掉之前必须确认对应的兜底场景已经不需要了。6. 避坑清单与个人经验最后一部分我集中说一下我在Vibe时代管理Workflow时踩过的一些坑和个人经验。这些不一定成体系但每一条都是真金白银换来的。6.1 这些坑我替你踩过了第一个坑把prompt当一次性消耗品。很多人把prompt写在对话框里用完就没了。这是Vibe时代最普遍的坏习惯。prompt应该和代码一样进Git仓库有版本、有评审、有历史记录。我在团队里强制要求所有稍具复用价值的prompt都保存成专门的prompt文件并且在代码库里占据一个独立目录。第二个坑不做输出Schema约束。让AI返回JSON却不告诉它字段类型和必填项结果就是它偶尔给你返回一个null字符串或者未知这种脏数据。后来我在所有需要AI构造结构化输出的工作流里都强制附带一份JSON Schema并且增加一个validate步骤schema校验不过直接拦截不让脏数据流到下一个环节。第三个坑上下文塞太多。这可能是Vibe时代性价比最低的错误操作——把整个项目的代码库全塞给AI让它读完了再干活。AI的上下文窗口是有限的塞的东西越多它对关键细节的关注度越低。我的经验是给AI的上下文不是越多越好而是越精准越好。用文件清单把本次任务真正相关的代码挑出来比丢给它一整个仓库目录效果强很多。第四个坑人工倒背测试。我刚入Vibe的时候也干过这事——让AI生成完代码自己写个脚本跑一遍验证然后就把测试代码给删了。这等于一次性验证下个迭代又得重新来。Vibe Coding时代一次性脚本就是一次性机会陷阱所有验证逻辑都应该沉淀成可重复执行的自动化测试。6.2 现阶段我建议的工具与落地路径先说结论现阶段做AI Workflow方向工具链我用的是这几个的组合语言与框架Python或者TypeScript各有所长。Python在AI生态里的集成体验最好TypeScript在前后端全栈场景更顺手。做纯后端AI流程编排我选Python。工作流引擎轻量场景自己写YAML解析加拓扑排序就够了重场景建议直接用现成引擎Temporal、Prefect都是成熟方案。LLM调用层直接用官方SDK或LangChain都行但我个人倾向于把LLM调用封装成一个独立执行器方便后续切换模型或接入自建模型网关。测试与验证Pytest是基础配合LLM as a Judge做轻量级的输出质量自动评估。落地路径上我给一个很务实的建议不要一开始就设计一个全自动的复杂AI工作流那不是大多数人能一步到位的。先从一个环节开始比如让AI自动生成某类测试用例把这一环节的输入输出、生成策略、验证逻辑都跑顺再逐步扩展。我见过太多人一上来就想搞一个AI自动完成整个项目的流程结果做了两周还在调第一步的prompt。6.3 关于Vibe时代流程管理的一个反直觉结论最后我想说一个可能有点反直觉的感受Vibe Coding时代流程管理不是变得更不重要了而是变得更重要了。过去代码是稀缺资源大家小心翼翼地写、小心翼翼地审。AI让代码变得像自来水一样便宜、易得人类反而要把精力从生产代码挪到治理代码流上去。你的价值不再取决于你能敲多少行代码而取决于你搭建的工作流能把AI的产出约束在多大的风险范围内。我个人的体会是Vibe Coding最理想的状态不是我什么都不用管而是我终于有时间去管那些只有人能管的事了——业务边界、系统架构、数据安全、团队协作。这些恰恰需要一套清晰的工作流来承载。最后再分享一个小技巧我每个项目都会维护一份AI协作备忘录里面写清楚这个项目里哪些模块可以让AI自由发挥、哪些模块必须人工评审、prompt模板怎么找、验收清单是什么。新同事加入的时候看这份备忘录比看十遍项目文档都管用。Vibe时代真正能沉淀下来的从来不是某一次对话里的灵光一闪而是那套可以被反复执行、反复验证的工作流本身。