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表单生成工作流，定义了一个步骤：把用户填的自然语言需求传给LLM，LLM返回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时代，真正能沉淀下来的从来不是某一次对话里的灵光一闪，而是那套可以被反复执行、反复验证的工作流本身。
