过去这半年，我身边的开发者几乎没人不在用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负责快出方案，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“讲道理”期望它自己改对，而是通过增加约束或增加检测手段来兜底。

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编程真正难的不是让模型生成代码，而是让生成的代码在一个真实系统里稳定活着。希望这份实践指南能帮你少走几段我正在走的弯路。