过去这半年我身边的开发者几乎没人不在用AI编程。天天用也天天在争论到底应该怎么用有人说直接聊就行要啥给啥有人说必须先写好规划再动手不然AI多改几次就失控还有人觉得AI生成完必须做一次彻底review否则上线就是给自己埋雷。这些争论其实指向了同一件事——AI编程正在从“个人零散玩法”走向“团队工程实践”。在这个阶段社区里沉淀出了五种非常有代表性的范式Vibe、Plan、Glue、Spec、Smell。Vibe是靠对话氛围和直觉一路快速生成Plan是把规划和决策前置再让AI执行Glue是花大力气拼接AI产出的模块Spec是用规格和测试约束结果Smell是对AI代码做系统性的气味检测和重构。它们各自代表一条解决问题的路径也各自有适用场景和致命弱点。这篇文章不是要抬哪个踩哪个。我打算把这五种范式逐个拆开讲讲它们到底怎么落地、会在什么地方踩坑、又该怎么组合使用最后再分享一套我在真实项目里反复调出来的工作流。1. 五大范式一次看懂它们到底在解决什么问题1.1 从“能用”到“可控”AI编程被逼出来的进化AI编程最开始给大多数人的印象是对话框里来一段自然语言然后代码就有了。早期大家关心的是“能不能生成”后来发现生成已经不成问题真正难的是“生成之后怎么办”。我在实际项目里遇到的最典型场景是这样的让AI帮忙写一个回调解析模块第一次生成的代码确实能跑但换个状态就崩让AI改一下某个函数结果它把相邻模块的代码也顺手“优化”了更常见的是AI生成的模块单独测试都通过一旦拼到主流程里错误处理和边界条件全都没对上。这些问题的本质可以归纳成一句话AI编程的前半段也就是代码生成环节已经足够强后半段也就是验证、规划、集成、维护环节还远没有成熟。五大范式的出现恰恰是大家针对后半段给出的不同解法。Vibe解决的是速度问题Spec解决的是正确性问题Plan解决的是方向问题Glue解决的是集成问题Smell解决的是质量问题。把它们放在一起看其实已经构成了一套相对完整的AI编程工程化拼图。1.2 一张表看清五种范式这里我先放一张总览表后面每一小节再展开讲范式核心动作适合场景主要风险关键产出Vibe对话驱动靠氛围和直觉快速生成原型验证、一次性脚本、探索性任务质量不稳定、上下文漂移、无测试可运行的草稿代码Plan规划前置人工决策AI执行复杂功能、多模块项目规划过度、计划脱离实际任务计划书、里程碑Glue模块拼接构建胶水层多AI模块集成、第三方API对接胶水层膨胀、依赖混乱适配器、DTO、事件总线Spec规格驱动测试作为验收标准业务逻辑强、正确性要求高的模块规格成本高、spec化过度行为规格、测试用例SmellAI代码质量体检系统化重构所有AI生成代码进入主分支前过度重构、效率反降坏味道清单、重构记录光看表可能觉得它们是五种独立的流派但我在实践中发现它们更像是一条流水线上的不同工位。Vibe负责快出方案Spec负责把方案锁稳Plan负责规划路径Glue负责把各段连起来Smell负责在合入前守好最后一道门。真正高效的团队很少只用其中一种。1.3 选型不是单选题按阶段组合很多初次接触这些概念的人会问我到底该学哪种范式我的回答是先别急着选先看你处于项目的哪个阶段。在需求还不清晰、技术路线没有验证过的阶段用Vibe去快速探索是成本最低的。这时候你让AI生成几个不同方向的实现比如试试两种接口设计风格、对比返回结构半天就能获得足够多的判断依据。等方向确定了需求开始收敛就该切到Spec或Plan把关键行为写成规格和测试把实现路径拆成里程碑让AI在约束下干活。多模块并行开发时Glue会变得至关重要——AI生成的模块很少天然对齐接口没有一套清晰的胶水层集成时就是灾难。最后不管哪范式产出的代码合入主分支前建议都过一遍Smell。这套组合思路我在多个项目里反复验证过后面会拿一个具体例子完整串一遍。2. Vibe与Spec快与稳的两极2.1 Vibe范式实战如何让“氛围编程”不翻车Vibe这个术语最早形容的是一种“凭感觉写代码”的状态人不需要盯着技术细节只要把需求用很自然的语言描述出来AI就能凭借它从海量代码里学出来的“直觉”生成实现。AI编程助手之所以能“猜”出你想要的函数名、参数结构靠的也是这种模式匹配式的直觉。Vibe的优势非常明显快特别适合探索性场景。我在做一个内部数据清洗小工具的时候第一步永远是打开对话窗口用一段口语化的描述让AI先把整体流程捋出来。比如“我需要一个能把CSV里的日期字段统一格式化的脚本顺便把空值标出来”这种需求根本不用写文档一分钟就能拿到可运行代码。但Vibe也是最容易翻车的。最让人头疼的问题是上下文漂移——对话超过一定长度后AI会慢慢忘掉你前面提过的约束。有一次我让AI在某个函数里保持JSON输出结构不变它改着改着突然给字段换了命名风格下游程序立刻报错。另外AI在“氛围很好”的时候特别喜欢自作主张你让它写一个排序函数它默认帮你加上了去重逻辑看起来更“贴心”实际上改变了业务语义。要在实际操作中用好Vibe我总结了几条经验一次对话只解决一个明确小问题。不要在一个对话里既让它写接口又让它写测试还让它修bug。上下文越杂漂移越快。用“角色约束条件输出格式”三段式来收紧氛围。比如明确告诉它“你是一名Python后端工程师不要用第三方库输出必须包含异常处理”比单纯说“写个接口”可靠得多。让AI先出骨架再填细节。先让它列出函数签名和模块结构确认没问题后再让它补实现能减少很多整体性偏差。代码生成了就要立刻归档别囤在聊天记录里。对话窗口不是代码仓库时间一长AI自己也理不清之前给过什么。生成结果先跑一遍最小冒烟测试再进版本库。Vibe产生的代码经常“看起来对”但边界条件一个都不处理。我见过太多次一跑真实数据就崩。注意Vibe生成的代码如果之后要长期维护一定要在归档当天补上最小测试集。拖延只会让“先跑起来”变成“永远跑起来”。Vibe适合什么场景原型验证、一次性数据处理脚本、对某个API用法的快速确认。不适合什么场景核心业务逻辑、团队长期维护的基础设施、涉及强一致性要求的模块。判断标准很简单你愿不愿意为这段代码后续可能出的bug买单愿意的程度决定了Vibe能不能上。2.2 Spec范式实战用规格和测试锁死AI输出Spec范式正好站在Vibe的反面。它不信任“氛围”只信任“可验证的行为”。核心思路是先把需求写成规格把规格转成测试用例然后让AI只负责实现代码是否合格完全由测试说了算。我第一次尝试Spec是因为被一个订单模块搞怕了。Vibe式让AI生成的函数单看逻辑没问题但订单金额、库存扣减、状态流转这些关键行为谁都不敢说它一定对。于是换了个思路先不写实现代码把业务规则拆成一条条验收条件用测试用例把每个条件锁死再让AI照着测试去写。举个具体例子假设需要一个计算订单折扣的函数规格可以这么写当订单金额大于1000元且用户等级为VIP时打8折当订单金额大于1000元但用户等级为普通用户时打9折其他情况不打折折扣后金额向下取整到分转化成的测试大概是import pytest from discount import calculate_discount def test_vip_over_1000_gets_20_percent_off(): assert calculate_discount(1200, vip) 960.0 def test_normal_over_1000_gets_10_percent_off(): assert calculate_discount(1200, normal) 1080.0 def test_below_1000_no_discount(): assert calculate_discount(800, vip) 800.0 def test_result_rounded_down_to_cents(): assert calculate_discount(1001, normal) 900.90然后把这些测试直接丢给AI让它实现calculate_discount直到测试通过。AI写出的代码固然重要但更重要的是测试用例把行为的边界定义清楚了后面任何人改动这段代码只要测试还在回归风险就可控。写Spec最需要注意的一点是规格要站在使用者角度描述行为而不是站在实现者角度描述过程。很多人在写规格时忍不住开始设计数据结构、拟定算法步骤这其实是在做Plan甚至直接做实现。Spec真正该关心的是“在什么输入下应该产生什么输出并满足什么不变量”。Spec也不是没有成本。把模糊需求转成精确测试本身需要不少思考时间。我的经验是只对正确性要求高的模块使用Spec比如支付、库存、权限、规则计算对于内部工具脚本用Vibe就够了别让所有代码都背上规格包袱。2.3 两派结合先Vibe探索再Spec收敛Vibe和Spec看起来是天平两端但在我的工作流里它们是最佳搭档。方向不确定时先用Vibe。比如产品经理描述了一个模糊的用户行为分析需求直接写规格根本没头绪。这时我会让AI基于对话快速生成一个原型脚本先用假数据跑起来看看效果验证这个分析思路是否可行。原型被确认可行后立刻进入Spec阶段把原型里被验证过的行为拆成验收测试把每个关键规则转成断言再让AI照着测试重写实现。这样做的好处是Vibe帮我们低成本找到了“对的方向”Spec则保证最终实现“正确且不跑偏”。两者结合既避免了Vibe的失控也避免了Spec的僵化。我见过很多团队一上来就想用Spec管理一切结果规格写了三天代码一行没写士气崩溃。反过来一直Vibe下去项目离失控也不远了。花Vibe的成本探索用Spec的成本锁住结果是我目前最推荐的个人开发者工作流。3. Plan范式把架构决策前置别让AI替你拍板3.1 为什么必须有人的规划参与如果说Spec管的是“每个功能对不对”Plan管的则是“整个项目往哪走”。AI生成代码的能力很强但让它一口气规划一个复杂项目结果通常不那么靠谱。我让AI规划过一个包含用户中心、订单、支付、后台管理四个模块的内部系统。它给出的方案听起来很完整但仔细看就发现两个问题一是过度设计用了一个团队根本维护不动的微服务架构来支撑一个日均几百请求的内部工具二是边界遗漏它规划的任务里几乎没有涉及日志、异常兜底、权限校验这些“脏活”。如果不加人肉评审照着执行这套方案大概率会把项目带沟里。AI的规划之所以会这样根源在于它缺少对真实项目的感知。它不知道团队几个人、服务器几台、维护成本多高、哪些模块其实可以砍掉。它看到的是“通用意义上最完整的方案”而不是“当前条件下最合适的方案”。所以Plan范式的第一步永远要人工参与决策架构选型、模块边界、优先级这些关键条目必须由人拍板AI最多是提供候选方案和细化执行路径。3.2 Plan实操四步法我在项目里摸索出来的Plan流程可以拆成四步。第一步用AI生成候选方案。把需求背景、约束条件、期望的技术栈喂给AI让它输出2到3套备选架构方案并列出每套的优缺点。这时候不追求方案的完美追求的是覆盖足够多的可能性。第二步人工评审定架构。对照团队实际情况把AI给的方案砍到只剩一套。这一步要处理AI的过度设计倾向能用一个模块解决的就不要拆成两个服务能用数据库事务解决的不要引入消息队列。第三步把计划拆成AI可执行的里程碑。架构定了之后让AI基于这个架构产出任务清单但人必须把任务再切一次识别哪些任务是强依赖必须顺序做哪些可以并行给每个任务加上明确的验收标准和上下文摘要。第四步按里程碑逐段交给AI实现。每开始一个任务把该任务的上下文、接口约束、验收标准打包成提示词交给AI完成。一块一块拼起来而不是让AI从零规划到天荒地老。以一个订单模块为例拆出来的任务卡片会是这样任务实现订单创建接口上下文订单服务已定义数据模型支付模块接口见接口文档约束订单金额必须大于0创建时校验用户状态验收调用接口传入合法参数返回订单ID非法金额返回参数错误提示不要修改既有数据模型只新增服务方法有了这种卡片AI实现时就不太容易跑偏人工review也有据可依。3.3 Plan的落地要点与常见误区Plan做得不好最常见的结果是规划文档写得漂亮落地时发现完全没法执行。我自己踩过的一个坑是让AI规划了非常详尽的任务拆解细化到每一个函数级别结果真开始写代码时发现那些细节跟后面的技术选型冲突了整个计划推倒重来。后来我意识到Plan的粒度要“管住架构放掉细节”。人的精力应该花在架构选型、模块边界、接口契约、优先级这些决策点上函数级的实现细节应该留给AI在具体写代码时自行决定。计划是给人和AI共同引用的一张路线图而不是一份步步紧逼的施工图纸。另一个误区是以为Plan就是写文档。计划的价值在于“在执行过程中不断被校验和修正”而不是写完即归档。每次里程碑完成都应该回头对照计划检查偏差把AI实际实现中暴露出的新问题补充进下一步计划。计划是活的不是死文档。4. Glue范式模块拼接是AI项目真正的修罗场4.1 胶水代码为什么会成为大头开始重度使用AI编程之后我很快发现一个反直觉的现象AI生成单个模块的速度确实快得惊人但把这些模块拼成一个能跑的系统花的时间反而比手写一个整体系统还多。原因是模块与模块之间的对接恰恰是AI最不擅长、也最不容易被发现错的地方。AI生成A模块时不知道B模块的返回结构生成B模块时没人告诉它A模块调用的方式。两边各自都正确拼在一起就互相不对付。这种“各自正确但不匹配”的矛盾只能靠胶水代码来兜底。胶水代码就是专门负责模块对接的一层代码。它做的事情很杂把A的输出转换成B期望的输入把第三方API的错误码翻译成内部统一异常把同步调用拆成事件异步给外部依赖加上超时和重试。可以说没有胶水层AI生成的模块就是一堆孤岛。Glue范式的核心态度是承认每个AI模块都是“孤岛制造机”然后把胶水层的设计当成正经工程来做。4.2 三类典型胶水层实现根据我的经验胶水层最常见的形态有三种适配器、数据映射、事件枢纽。第一种适配器模式用于统一不同模块或者第三方服务的接口。比如两个AI生成的模块一个返回created_at另一个用createTime接口契约压根不一致。直接改模块内部字段会牵动一堆逻辑性价比低更稳妥的做法是在中间加一层适配器负责把两边字段格式互转。适配器要薄、要单方向不要在胶水层里写业务逻辑。代码形态大致是这样class LegacyOrderAdapter: 把旧系统订单结构转换成内部标准结构 def to_internal(self, legacy_order): return { order_id: legacy_order[id], created_at: legacy_order[createTime], # 字段重命名、格式转换统一收口到这里 }第二种数据映射与校验。这个主要用在跨模块传输数据时A模块给B模块传数据B模块不能默认数据一定合法。胶水层里加一道校验在入口处把关键字段的非空、类型、取值范围检查一遍能挡掉大量因为AI生成代码遗漏校验而导致的线上故障。校验不通过就返回标准错误不要揣着坏数据继续往下游传。第三种事件枢纽。当模块间是异步关系时直接互相调用会让耦合越来越深。这时候在中间安排一个事件枢纽A模块只负责发事件B模块只负责订阅处理。模块之间不再需要知道对方的地址只管好自己的事件格式。这种解耦对AI生成代码特别友好——因为你没法保证AI生成的模块之间调用关系永远不变事件边界给了它们各自演化的空间。4.3 胶水层的容错与治理胶水层做得不好会比业务代码更容易崩。因为它处于模块之间任何一个上游超时、下游异常、数据格式变化都会在胶水层集中爆发。所以胶水层的容错设计必须一口气做完整。经验上至少要做到三件事超时必须有、重试必须限次数、失败必须能被观测。比如对接第三方支付查询接口胶水层设置3秒超时重试最多2次重试之间用指数退避超过重试上限就触发告警并把错误落到日志里方便排查。这些看起来是常识但AI生成代码时经常把requests.get()裸写出来连最基本的超时参数都不设置。人肉review胶水层时我会优先检查这种漏项。另外胶水层最容易犯的治理错误是不断膨胀。今天加个字段映射明天加个临时兼容逻辑几个月后胶水层变成一坨没人敢动的意大利面。控制膨胀的办法是给胶水层建立边界胶水层只做转换、校验、路由不写业务规则任何业务规则都要下推到模块内部去实现。你会发现只要把规则和胶水层分开重构时就能精准找到改动点。5. Smell范式给AI代码做体检比给人类代码做评审更难5.1 AI代码的六类高发坏味道代码坏味道这个概念并不新鲜但AI生成的代码有自己的“高发病谱”。幻觉依赖是最有欺骗性的一种。AI生成代码时会替你“脑补”出一些不存在的库、不存在的API参数、不存在的配置项。代码看起来有模有样一运行导入就失败或者某个方法根本不存在。越是看起来自信的输出越要警惕。死代码也很常见。AI经常生成一大段没有被任何地方调用的辅助函数或者留着永远不会走到的分支。它自己意识不到这些代码真的是人肉删掉的负担也是后续维护者理解程序的噪音。刻意复杂化是AI的另一个毛病。明明一个字典就能解决的问题它给你包了三层类、两个抽象接口。这往往不是因为思考深入而是因为它训练数据里的代码平均复杂度就是偏高。用Vibe风格生成的核心模块这种味道尤其浓。重复实现也很典型。同一个取时间戳的函数在五个模块里被AI各写了一遍还用了三种不同的写法。这种重复在AI生成场景下几乎是必然因为它每次生成都从零开始不知道项目里已经出现过同样逻辑。注释谎话是指代码注释和实际行为不一致。AI经常在生成时把旧设计的注释一起带过来或者为了实现方便改了逻辑但忘了改注释。误导性注释比没有注释更坑人。测试过弱则是AI生成测试用例的通病。它生成的断言大多都是“输出不为空”“返回成功”真正能锁住业务行为的断言寥寥无几。这种测试跑起来全绿但什么都保护不了。5.2 静态检查加人工复查的组合打法Smell范式的落地思路很直白先靠工具筛掉能自动识别的坏味道再用人工集中处理工具看不出来的问题。静态检查这一层重点配置几类规则未使用变量和死代码检测类型注解缺失异常处理遗漏危险API调用比如裸的eval、SQL字符串拼接复杂度过高分。AI生成代码一进来先过静态检查能挡掉相当大一部分低质量问题。我这里说的静态检查不单是“语法检查”而是把规则严格度调到接近“团队长期维护”的标准因为AI代码如果不强制它一定会走最低质量路线。人工复查走查清单可以根据项目情况定制我自己的最小清单是边界条件是否覆盖空值、极值、重复调用、超时外部依赖是否兜底超时、重试、错误码翻译公共接口是否稳定返回值结构是否和调用方约定一致是否有注释谎话代码和注释逐条对照是否有不该出现的复杂度拔高朴素实现够用的就不允许上抽象走查时不要试图一段段细读全部AI代码那样效率太低。正确姿势是先看接口和边界再看异常和外部调用最后抽查逻辑主干。5.3 重构优先级与节奏Smell做完检测发现问题不等于马上重写。我的原则是从风险最高的坏味道开始改不要贪多。优先级排序大致是幻觉依赖和错误处理缺失排第一因为它们直接导致运行失败注释谎话和刻意复杂化排第二因为影响维护效率死代码和重复实现排第三可以在后续迭代中慢慢清理。每次重构都要遵循一个铁律先补测试再改代码。AI生成的模块往往没有靠谱测试直接重构等于在流沙上盖楼。先把关键行为锁定成测试一旦测试变绿再开始调整实现。改完一段立刻跑测试确认没有回归。节奏上我建议把Smell拆成“合入前检查”和“合入后持续清理”两个阶段。合入前只处理会导致线上事故或者接口不稳定的问题剩下的死代码、重复实现、复杂度过高全部丢进技术债清单在后续功能迭代时顺手清理。这个节奏能避免一种很常见的翻车因为想彻底重构AI代码导致功能交付无限延期最后团队放弃用AI编程。6. 常见问题与排查技巧实录6.1 五类高频问题速查表现象可能原因处理手段AI生成的代码模块单独能跑一集成就报错模块间接口契约不匹配缺少胶水层引入适配器/校验层统一字段和错误格式让AI改一个函数它顺手改了旁边的代码上下文漂移、职责边界不清晰任务拆分得更小明确“只改这里”的指令用测试锁行为AI生成的测试全绿但业务还是出bug测试断言过弱没有覆盖真实行为重写测试从业务规格反推Given-When-Then用例规划文档看着完美执行时处处冲突计划粒度太细或太粗架构决策偏离实际人重新定架构边界计划只保留里程碑和接口约束AI代码越改越乱复杂度螺旋上升缺少坏味道检测和重构节奏引入静态检查走查清单按风险排序逐步重构这五类问题基本上覆盖了我碰到过的高频故障。处理每一类问题时的共同点是不要跟AI“讲道理”期望它自己改对而是通过增加约束或增加检测手段来兜底。6.2 一个组合落地的完整流程实录拿一个实际的例子串一下五种范式。某开发者准备做一个内部日志分析小工具需求是读取各服务日志、按关键字聚合、输出可读报告。第一天用Vibe探索直接用对话让AI生成了一个粗糙脚本跑在测试日志上发现聚合逻辑可行但内存占用很高。方向确认没问题。第二天切到Spec收敛把“按关键字聚合”“时间范围过滤”“结果排序”几个关键行为写成pytest测试再让AI按测试重写数据处理模块。这次实现稳定了很多内存问题也被测试逼出来了。第三天用Plan补全路径由于要接多个服务的日志源架构上需要统一输入解析层。用Plan把任务拆成“统一日志格式适配”“聚合模块”“报告输出”三个里程碑每个里程碑都带明确的接口约束。第四天进入Glue阶段各模块分别由AI生成后开发团队在中间加了格式适配器和一个简单的事件队列解决了各日志源字段不一致和异步处理顺序问题。第五天Smell上线所有AI生成的代码过一遍静态检查发现两个模块缺少异常处理走查又抓到了一个问题——某个日志解析函数在空行输入时直接崩溃。补上边界处理后进入测试回归没有问题。整个流程看起来平平无奇但每一个环节都踩住了坑Vibe没有失控、Spec把关键行为锁死、Plan保证了不返工、Glue解决了集成矛盾、Smell守住了质量底线。五者合力一个小工具从想法到可用一周之内就完成了。6.3 几条值得长期坚持的小习惯最后整理几条我长期坚持的习惯对任何范式都适用。每条指令都带上足够的上下文。AI的记忆能力再强也不是永久的任务越复杂越容易忘把“你要解决的问题你手里的约束你期望的输出”打包发出去能明显减少返工。先写测试再写实现。不管是Spec还是Smell工作流测试都是核心纽带。它既是给AI的验收标准也是给人做的回归保护。没有测试的AI代码等同于没有安全网的高空作业。随时归档有效的提示词。我在项目里建了一个提示词片段库把“设置超时”“限制重试次数”“不要修改公共接口”这类高频约束存下来。每次新任务直接复用AI生成质量的稳定性会高很多。对AI代码保持“低信任”心态。不因为生成的代码能跑就放松审查也不因为它是AI写的就过度怀疑。以测试和走查结果说话用流程约束代替对AI的朴素的信任。注意低信任不代表每行都要人肉审查而是体现在流程设计上静态检查、测试门禁、走查清单缺一不可。我个人把五种范式当成了同一条流水线上的不同工位先Vibe探路用Spec锁住核心行为拿Plan定好路径靠Glue拼起模块最后由Smell守住上线质量。这套组合不是一开始就成型的是我在一次又一次的项目翻车里慢慢调出来的。如果你刚开始从“让AI写代码”转向“让AI好好参与项目”我建议不要一上来就五件套全上先选最疼的那个问题切入集成就把Glue做扎实正确性差就补Spec失控就上Plan。跑顺一条再慢慢加另一条。AI编程真正难的不是让模型生成代码而是让生成的代码在一个真实系统里稳定活着。希望这份实践指南能帮你少走几段我正在走的弯路。 
长河君 · 2026/10/21 12:57:09 · 阅读 1.2k 五种AI编程范式：Vibe、Plan、Glue、Spec与Smell的工程化实践
过去这半年我身边的开发者几乎没人不在用AI编程。天天用也天天在争论到底应该怎么用有人说直接聊就行要啥给啥有人说必须先写好规划再动手不然AI多改几次就失控还有人觉得AI生成完必须做一次彻底review否则上线就是给自己埋雷。这些争论其实指向了同一件事——AI编程正在从“个人零散玩法”走向“团队工程实践”。在这个阶段社区里沉淀出了五种非常有代表性的范式Vibe、Plan、Glue、Spec、Smell。Vibe是靠对话氛围和直觉一路快速生成Plan是把规划和决策前置再让AI执行Glue是花大力气拼接AI产出的模块Spec是用规格和测试约束结果Smell是对AI代码做系统性的气味检测和重构。它们各自代表一条解决问题的路径也各自有适用场景和致命弱点。这篇文章不是要抬哪个踩哪个。我打算把这五种范式逐个拆开讲讲它们到底怎么落地、会在什么地方踩坑、又该怎么组合使用最后再分享一套我在真实项目里反复调出来的工作流。1. 五大范式一次看懂它们到底在解决什么问题1.1 从“能用”到“可控”AI编程被逼出来的进化AI编程最开始给大多数人的印象是对话框里来一段自然语言然后代码就有了。早期大家关心的是“能不能生成”后来发现生成已经不成问题真正难的是“生成之后怎么办”。我在实际项目里遇到的最典型场景是这样的让AI帮忙写一个回调解析模块第一次生成的代码确实能跑但换个状态就崩让AI改一下某个函数结果它把相邻模块的代码也顺手“优化”了更常见的是AI生成的模块单独测试都通过一旦拼到主流程里错误处理和边界条件全都没对上。这些问题的本质可以归纳成一句话AI编程的前半段也就是代码生成环节已经足够强后半段也就是验证、规划、集成、维护环节还远没有成熟。五大范式的出现恰恰是大家针对后半段给出的不同解法。Vibe解决的是速度问题Spec解决的是正确性问题Plan解决的是方向问题Glue解决的是集成问题Smell解决的是质量问题。把它们放在一起看其实已经构成了一套相对完整的AI编程工程化拼图。1.2 一张表看清五种范式这里我先放一张总览表后面每一小节再展开讲范式核心动作适合场景主要风险关键产出Vibe对话驱动靠氛围和直觉快速生成原型验证、一次性脚本、探索性任务质量不稳定、上下文漂移、无测试可运行的草稿代码Plan规划前置人工决策AI执行复杂功能、多模块项目规划过度、计划脱离实际任务计划书、里程碑Glue模块拼接构建胶水层多AI模块集成、第三方API对接胶水层膨胀、依赖混乱适配器、DTO、事件总线Spec规格驱动测试作为验收标准业务逻辑强、正确性要求高的模块规格成本高、spec化过度行为规格、测试用例SmellAI代码质量体检系统化重构所有AI生成代码进入主分支前过度重构、效率反降坏味道清单、重构记录光看表可能觉得它们是五种独立的流派但我在实践中发现它们更像是一条流水线上的不同工位。Vibe负责快出方案Spec负责把方案锁稳Plan负责规划路径Glue负责把各段连起来Smell负责在合入前守好最后一道门。真正高效的团队很少只用其中一种。1.3 选型不是单选题按阶段组合很多初次接触这些概念的人会问我到底该学哪种范式我的回答是先别急着选先看你处于项目的哪个阶段。在需求还不清晰、技术路线没有验证过的阶段用Vibe去快速探索是成本最低的。这时候你让AI生成几个不同方向的实现比如试试两种接口设计风格、对比返回结构半天就能获得足够多的判断依据。等方向确定了需求开始收敛就该切到Spec或Plan把关键行为写成规格和测试把实现路径拆成里程碑让AI在约束下干活。多模块并行开发时Glue会变得至关重要——AI生成的模块很少天然对齐接口没有一套清晰的胶水层集成时就是灾难。最后不管哪范式产出的代码合入主分支前建议都过一遍Smell。这套组合思路我在多个项目里反复验证过后面会拿一个具体例子完整串一遍。2. Vibe与Spec快与稳的两极2.1 Vibe范式实战如何让“氛围编程”不翻车Vibe这个术语最早形容的是一种“凭感觉写代码”的状态人不需要盯着技术细节只要把需求用很自然的语言描述出来AI就能凭借它从海量代码里学出来的“直觉”生成实现。AI编程助手之所以能“猜”出你想要的函数名、参数结构靠的也是这种模式匹配式的直觉。Vibe的优势非常明显快特别适合探索性场景。我在做一个内部数据清洗小工具的时候第一步永远是打开对话窗口用一段口语化的描述让AI先把整体流程捋出来。比如“我需要一个能把CSV里的日期字段统一格式化的脚本顺便把空值标出来”这种需求根本不用写文档一分钟就能拿到可运行代码。但Vibe也是最容易翻车的。最让人头疼的问题是上下文漂移——对话超过一定长度后AI会慢慢忘掉你前面提过的约束。有一次我让AI在某个函数里保持JSON输出结构不变它改着改着突然给字段换了命名风格下游程序立刻报错。另外AI在“氛围很好”的时候特别喜欢自作主张你让它写一个排序函数它默认帮你加上了去重逻辑看起来更“贴心”实际上改变了业务语义。要在实际操作中用好Vibe我总结了几条经验一次对话只解决一个明确小问题。不要在一个对话里既让它写接口又让它写测试还让它修bug。上下文越杂漂移越快。用“角色约束条件输出格式”三段式来收紧氛围。比如明确告诉它“你是一名Python后端工程师不要用第三方库输出必须包含异常处理”比单纯说“写个接口”可靠得多。让AI先出骨架再填细节。先让它列出函数签名和模块结构确认没问题后再让它补实现能减少很多整体性偏差。代码生成了就要立刻归档别囤在聊天记录里。对话窗口不是代码仓库时间一长AI自己也理不清之前给过什么。生成结果先跑一遍最小冒烟测试再进版本库。Vibe产生的代码经常“看起来对”但边界条件一个都不处理。我见过太多次一跑真实数据就崩。注意Vibe生成的代码如果之后要长期维护一定要在归档当天补上最小测试集。拖延只会让“先跑起来”变成“永远跑起来”。Vibe适合什么场景原型验证、一次性数据处理脚本、对某个API用法的快速确认。不适合什么场景核心业务逻辑、团队长期维护的基础设施、涉及强一致性要求的模块。判断标准很简单你愿不愿意为这段代码后续可能出的bug买单愿意的程度决定了Vibe能不能上。2.2 Spec范式实战用规格和测试锁死AI输出Spec范式正好站在Vibe的反面。它不信任“氛围”只信任“可验证的行为”。核心思路是先把需求写成规格把规格转成测试用例然后让AI只负责实现代码是否合格完全由测试说了算。我第一次尝试Spec是因为被一个订单模块搞怕了。Vibe式让AI生成的函数单看逻辑没问题但订单金额、库存扣减、状态流转这些关键行为谁都不敢说它一定对。于是换了个思路先不写实现代码把业务规则拆成一条条验收条件用测试用例把每个条件锁死再让AI照着测试去写。举个具体例子假设需要一个计算订单折扣的函数规格可以这么写当订单金额大于1000元且用户等级为VIP时打8折当订单金额大于1000元但用户等级为普通用户时打9折其他情况不打折折扣后金额向下取整到分转化成的测试大概是import pytest from discount import calculate_discount def test_vip_over_1000_gets_20_percent_off(): assert calculate_discount(1200, vip) 960.0 def test_normal_over_1000_gets_10_percent_off(): assert calculate_discount(1200, normal) 1080.0 def test_below_1000_no_discount(): assert calculate_discount(800, vip) 800.0 def test_result_rounded_down_to_cents(): assert calculate_discount(1001, normal) 900.90然后把这些测试直接丢给AI让它实现calculate_discount直到测试通过。AI写出的代码固然重要但更重要的是测试用例把行为的边界定义清楚了后面任何人改动这段代码只要测试还在回归风险就可控。写Spec最需要注意的一点是规格要站在使用者角度描述行为而不是站在实现者角度描述过程。很多人在写规格时忍不住开始设计数据结构、拟定算法步骤这其实是在做Plan甚至直接做实现。Spec真正该关心的是“在什么输入下应该产生什么输出并满足什么不变量”。Spec也不是没有成本。把模糊需求转成精确测试本身需要不少思考时间。我的经验是只对正确性要求高的模块使用Spec比如支付、库存、权限、规则计算对于内部工具脚本用Vibe就够了别让所有代码都背上规格包袱。2.3 两派结合先Vibe探索再Spec收敛Vibe和Spec看起来是天平两端但在我的工作流里它们是最佳搭档。方向不确定时先用Vibe。比如产品经理描述了一个模糊的用户行为分析需求直接写规格根本没头绪。这时我会让AI基于对话快速生成一个原型脚本先用假数据跑起来看看效果验证这个分析思路是否可行。原型被确认可行后立刻进入Spec阶段把原型里被验证过的行为拆成验收测试把每个关键规则转成断言再让AI照着测试重写实现。这样做的好处是Vibe帮我们低成本找到了“对的方向”Spec则保证最终实现“正确且不跑偏”。两者结合既避免了Vibe的失控也避免了Spec的僵化。我见过很多团队一上来就想用Spec管理一切结果规格写了三天代码一行没写士气崩溃。反过来一直Vibe下去项目离失控也不远了。花Vibe的成本探索用Spec的成本锁住结果是我目前最推荐的个人开发者工作流。3. Plan范式把架构决策前置别让AI替你拍板3.1 为什么必须有人的规划参与如果说Spec管的是“每个功能对不对”Plan管的则是“整个项目往哪走”。AI生成代码的能力很强但让它一口气规划一个复杂项目结果通常不那么靠谱。我让AI规划过一个包含用户中心、订单、支付、后台管理四个模块的内部系统。它给出的方案听起来很完整但仔细看就发现两个问题一是过度设计用了一个团队根本维护不动的微服务架构来支撑一个日均几百请求的内部工具二是边界遗漏它规划的任务里几乎没有涉及日志、异常兜底、权限校验这些“脏活”。如果不加人肉评审照着执行这套方案大概率会把项目带沟里。AI的规划之所以会这样根源在于它缺少对真实项目的感知。它不知道团队几个人、服务器几台、维护成本多高、哪些模块其实可以砍掉。它看到的是“通用意义上最完整的方案”而不是“当前条件下最合适的方案”。所以Plan范式的第一步永远要人工参与决策架构选型、模块边界、优先级这些关键条目必须由人拍板AI最多是提供候选方案和细化执行路径。3.2 Plan实操四步法我在项目里摸索出来的Plan流程可以拆成四步。第一步用AI生成候选方案。把需求背景、约束条件、期望的技术栈喂给AI让它输出2到3套备选架构方案并列出每套的优缺点。这时候不追求方案的完美追求的是覆盖足够多的可能性。第二步人工评审定架构。对照团队实际情况把AI给的方案砍到只剩一套。这一步要处理AI的过度设计倾向能用一个模块解决的就不要拆成两个服务能用数据库事务解决的不要引入消息队列。第三步把计划拆成AI可执行的里程碑。架构定了之后让AI基于这个架构产出任务清单但人必须把任务再切一次识别哪些任务是强依赖必须顺序做哪些可以并行给每个任务加上明确的验收标准和上下文摘要。第四步按里程碑逐段交给AI实现。每开始一个任务把该任务的上下文、接口约束、验收标准打包成提示词交给AI完成。一块一块拼起来而不是让AI从零规划到天荒地老。以一个订单模块为例拆出来的任务卡片会是这样任务实现订单创建接口上下文订单服务已定义数据模型支付模块接口见接口文档约束订单金额必须大于0创建时校验用户状态验收调用接口传入合法参数返回订单ID非法金额返回参数错误提示不要修改既有数据模型只新增服务方法有了这种卡片AI实现时就不太容易跑偏人工review也有据可依。3.3 Plan的落地要点与常见误区Plan做得不好最常见的结果是规划文档写得漂亮落地时发现完全没法执行。我自己踩过的一个坑是让AI规划了非常详尽的任务拆解细化到每一个函数级别结果真开始写代码时发现那些细节跟后面的技术选型冲突了整个计划推倒重来。后来我意识到Plan的粒度要“管住架构放掉细节”。人的精力应该花在架构选型、模块边界、接口契约、优先级这些决策点上函数级的实现细节应该留给AI在具体写代码时自行决定。计划是给人和AI共同引用的一张路线图而不是一份步步紧逼的施工图纸。另一个误区是以为Plan就是写文档。计划的价值在于“在执行过程中不断被校验和修正”而不是写完即归档。每次里程碑完成都应该回头对照计划检查偏差把AI实际实现中暴露出的新问题补充进下一步计划。计划是活的不是死文档。4. Glue范式模块拼接是AI项目真正的修罗场4.1 胶水代码为什么会成为大头开始重度使用AI编程之后我很快发现一个反直觉的现象AI生成单个模块的速度确实快得惊人但把这些模块拼成一个能跑的系统花的时间反而比手写一个整体系统还多。原因是模块与模块之间的对接恰恰是AI最不擅长、也最不容易被发现错的地方。AI生成A模块时不知道B模块的返回结构生成B模块时没人告诉它A模块调用的方式。两边各自都正确拼在一起就互相不对付。这种“各自正确但不匹配”的矛盾只能靠胶水代码来兜底。胶水代码就是专门负责模块对接的一层代码。它做的事情很杂把A的输出转换成B期望的输入把第三方API的错误码翻译成内部统一异常把同步调用拆成事件异步给外部依赖加上超时和重试。可以说没有胶水层AI生成的模块就是一堆孤岛。Glue范式的核心态度是承认每个AI模块都是“孤岛制造机”然后把胶水层的设计当成正经工程来做。4.2 三类典型胶水层实现根据我的经验胶水层最常见的形态有三种适配器、数据映射、事件枢纽。第一种适配器模式用于统一不同模块或者第三方服务的接口。比如两个AI生成的模块一个返回created_at另一个用createTime接口契约压根不一致。直接改模块内部字段会牵动一堆逻辑性价比低更稳妥的做法是在中间加一层适配器负责把两边字段格式互转。适配器要薄、要单方向不要在胶水层里写业务逻辑。代码形态大致是这样class LegacyOrderAdapter: 把旧系统订单结构转换成内部标准结构 def to_internal(self, legacy_order): return { order_id: legacy_order[id], created_at: legacy_order[createTime], # 字段重命名、格式转换统一收口到这里 }第二种数据映射与校验。这个主要用在跨模块传输数据时A模块给B模块传数据B模块不能默认数据一定合法。胶水层里加一道校验在入口处把关键字段的非空、类型、取值范围检查一遍能挡掉大量因为AI生成代码遗漏校验而导致的线上故障。校验不通过就返回标准错误不要揣着坏数据继续往下游传。第三种事件枢纽。当模块间是异步关系时直接互相调用会让耦合越来越深。这时候在中间安排一个事件枢纽A模块只负责发事件B模块只负责订阅处理。模块之间不再需要知道对方的地址只管好自己的事件格式。这种解耦对AI生成代码特别友好——因为你没法保证AI生成的模块之间调用关系永远不变事件边界给了它们各自演化的空间。4.3 胶水层的容错与治理胶水层做得不好会比业务代码更容易崩。因为它处于模块之间任何一个上游超时、下游异常、数据格式变化都会在胶水层集中爆发。所以胶水层的容错设计必须一口气做完整。经验上至少要做到三件事超时必须有、重试必须限次数、失败必须能被观测。比如对接第三方支付查询接口胶水层设置3秒超时重试最多2次重试之间用指数退避超过重试上限就触发告警并把错误落到日志里方便排查。这些看起来是常识但AI生成代码时经常把requests.get()裸写出来连最基本的超时参数都不设置。人肉review胶水层时我会优先检查这种漏项。另外胶水层最容易犯的治理错误是不断膨胀。今天加个字段映射明天加个临时兼容逻辑几个月后胶水层变成一坨没人敢动的意大利面。控制膨胀的办法是给胶水层建立边界胶水层只做转换、校验、路由不写业务规则任何业务规则都要下推到模块内部去实现。你会发现只要把规则和胶水层分开重构时就能精准找到改动点。5. Smell范式给AI代码做体检比给人类代码做评审更难5.1 AI代码的六类高发坏味道代码坏味道这个概念并不新鲜但AI生成的代码有自己的“高发病谱”。幻觉依赖是最有欺骗性的一种。AI生成代码时会替你“脑补”出一些不存在的库、不存在的API参数、不存在的配置项。代码看起来有模有样一运行导入就失败或者某个方法根本不存在。越是看起来自信的输出越要警惕。死代码也很常见。AI经常生成一大段没有被任何地方调用的辅助函数或者留着永远不会走到的分支。它自己意识不到这些代码真的是人肉删掉的负担也是后续维护者理解程序的噪音。刻意复杂化是AI的另一个毛病。明明一个字典就能解决的问题它给你包了三层类、两个抽象接口。这往往不是因为思考深入而是因为它训练数据里的代码平均复杂度就是偏高。用Vibe风格生成的核心模块这种味道尤其浓。重复实现也很典型。同一个取时间戳的函数在五个模块里被AI各写了一遍还用了三种不同的写法。这种重复在AI生成场景下几乎是必然因为它每次生成都从零开始不知道项目里已经出现过同样逻辑。注释谎话是指代码注释和实际行为不一致。AI经常在生成时把旧设计的注释一起带过来或者为了实现方便改了逻辑但忘了改注释。误导性注释比没有注释更坑人。测试过弱则是AI生成测试用例的通病。它生成的断言大多都是“输出不为空”“返回成功”真正能锁住业务行为的断言寥寥无几。这种测试跑起来全绿但什么都保护不了。5.2 静态检查加人工复查的组合打法Smell范式的落地思路很直白先靠工具筛掉能自动识别的坏味道再用人工集中处理工具看不出来的问题。静态检查这一层重点配置几类规则未使用变量和死代码检测类型注解缺失异常处理遗漏危险API调用比如裸的eval、SQL字符串拼接复杂度过高分。AI生成代码一进来先过静态检查能挡掉相当大一部分低质量问题。我这里说的静态检查不单是“语法检查”而是把规则严格度调到接近“团队长期维护”的标准因为AI代码如果不强制它一定会走最低质量路线。人工复查走查清单可以根据项目情况定制我自己的最小清单是边界条件是否覆盖空值、极值、重复调用、超时外部依赖是否兜底超时、重试、错误码翻译公共接口是否稳定返回值结构是否和调用方约定一致是否有注释谎话代码和注释逐条对照是否有不该出现的复杂度拔高朴素实现够用的就不允许上抽象走查时不要试图一段段细读全部AI代码那样效率太低。正确姿势是先看接口和边界再看异常和外部调用最后抽查逻辑主干。5.3 重构优先级与节奏Smell做完检测发现问题不等于马上重写。我的原则是从风险最高的坏味道开始改不要贪多。优先级排序大致是幻觉依赖和错误处理缺失排第一因为它们直接导致运行失败注释谎话和刻意复杂化排第二因为影响维护效率死代码和重复实现排第三可以在后续迭代中慢慢清理。每次重构都要遵循一个铁律先补测试再改代码。AI生成的模块往往没有靠谱测试直接重构等于在流沙上盖楼。先把关键行为锁定成测试一旦测试变绿再开始调整实现。改完一段立刻跑测试确认没有回归。节奏上我建议把Smell拆成“合入前检查”和“合入后持续清理”两个阶段。合入前只处理会导致线上事故或者接口不稳定的问题剩下的死代码、重复实现、复杂度过高全部丢进技术债清单在后续功能迭代时顺手清理。这个节奏能避免一种很常见的翻车因为想彻底重构AI代码导致功能交付无限延期最后团队放弃用AI编程。6. 常见问题与排查技巧实录6.1 五类高频问题速查表现象可能原因处理手段AI生成的代码模块单独能跑一集成就报错模块间接口契约不匹配缺少胶水层引入适配器/校验层统一字段和错误格式让AI改一个函数它顺手改了旁边的代码上下文漂移、职责边界不清晰任务拆分得更小明确“只改这里”的指令用测试锁行为AI生成的测试全绿但业务还是出bug测试断言过弱没有覆盖真实行为重写测试从业务规格反推Given-When-Then用例规划文档看着完美执行时处处冲突计划粒度太细或太粗架构决策偏离实际人重新定架构边界计划只保留里程碑和接口约束AI代码越改越乱复杂度螺旋上升缺少坏味道检测和重构节奏引入静态检查走查清单按风险排序逐步重构这五类问题基本上覆盖了我碰到过的高频故障。处理每一类问题时的共同点是不要跟AI“讲道理”期望它自己改对而是通过增加约束或增加检测手段来兜底。6.2 一个组合落地的完整流程实录拿一个实际的例子串一下五种范式。某开发者准备做一个内部日志分析小工具需求是读取各服务日志、按关键字聚合、输出可读报告。第一天用Vibe探索直接用对话让AI生成了一个粗糙脚本跑在测试日志上发现聚合逻辑可行但内存占用很高。方向确认没问题。第二天切到Spec收敛把“按关键字聚合”“时间范围过滤”“结果排序”几个关键行为写成pytest测试再让AI按测试重写数据处理模块。这次实现稳定了很多内存问题也被测试逼出来了。第三天用Plan补全路径由于要接多个服务的日志源架构上需要统一输入解析层。用Plan把任务拆成“统一日志格式适配”“聚合模块”“报告输出”三个里程碑每个里程碑都带明确的接口约束。第四天进入Glue阶段各模块分别由AI生成后开发团队在中间加了格式适配器和一个简单的事件队列解决了各日志源字段不一致和异步处理顺序问题。第五天Smell上线所有AI生成的代码过一遍静态检查发现两个模块缺少异常处理走查又抓到了一个问题——某个日志解析函数在空行输入时直接崩溃。补上边界处理后进入测试回归没有问题。整个流程看起来平平无奇但每一个环节都踩住了坑Vibe没有失控、Spec把关键行为锁死、Plan保证了不返工、Glue解决了集成矛盾、Smell守住了质量底线。五者合力一个小工具从想法到可用一周之内就完成了。6.3 几条值得长期坚持的小习惯最后整理几条我长期坚持的习惯对任何范式都适用。每条指令都带上足够的上下文。AI的记忆能力再强也不是永久的任务越复杂越容易忘把“你要解决的问题你手里的约束你期望的输出”打包发出去能明显减少返工。先写测试再写实现。不管是Spec还是Smell工作流测试都是核心纽带。它既是给AI的验收标准也是给人做的回归保护。没有测试的AI代码等同于没有安全网的高空作业。随时归档有效的提示词。我在项目里建了一个提示词片段库把“设置超时”“限制重试次数”“不要修改公共接口”这类高频约束存下来。每次新任务直接复用AI生成质量的稳定性会高很多。对AI代码保持“低信任”心态。不因为生成的代码能跑就放松审查也不因为它是AI写的就过度怀疑。以测试和走查结果说话用流程约束代替对AI的朴素的信任。注意低信任不代表每行都要人肉审查而是体现在流程设计上静态检查、测试门禁、走查清单缺一不可。我个人把五种范式当成了同一条流水线上的不同工位先Vibe探路用Spec锁住核心行为拿Plan定好路径靠Glue拼起模块最后由Smell守住上线质量。这套组合不是一开始就成型的是我在一次又一次的项目翻车里慢慢调出来的。如果你刚开始从“让AI写代码”转向“让AI好好参与项目”我建议不要一上来就五件套全上先选最疼的那个问题切入集成就把Glue做扎实正确性差就补Spec失控就上Plan。跑顺一条再慢慢加另一条。AI编程真正难的不是让模型生成代码而是让生成的代码在一个真实系统里稳定活着。希望这份实践指南能帮你少走几段我正在走的弯路。