1. 五种范式到底在解决什么问题
第一次听到“Vibe、Plan、Glue、Spec、Smell”这五个词被并列放在一起，我的反应是：又有人造概念了。但真正把一个大项目从零推到上线、中间经历三次重构之后，我才意识到这五个词其实精准地描述了“人和AI协作写代码”时五种截然不同的工作状态。它们不是互斥的技术栈，而是五种可以随时切换的协作模式。
先说清楚这五种范式各自的核心特征，后面再逐个拆解落地细节。
Vibe范式，我习惯叫它“氛围编程”。你有一个模糊的想法，不写任何设计文档，直接对着AI描述你想要什么感觉的东西，让它先吐出一版能跑的代码。这个阶段追求的是“先看到东西”，代码质量、架构合理性统统往后放。适合做原型验证、技术选型试探、或者纯粹找灵感。
Plan范式，核心是“先规划再动手”。在写任何一行代码之前，先把需求拆解成模块、定义接口、画出数据流，让AI帮你审查方案的漏洞。这个阶段产出的不是代码，而是一份可执行的计划。适合中大型功能开发、多人协作场景、以及任何“返工成本很高”的任务。
Glue范式，我称之为“胶水编程”。你的项目里已经有若干现成的库、服务、API，你的工作是把它们粘在一起。AI在这个范式里的角色是“快速生成适配层代码”，比如写一个把A格式转成B格式的中间件、补一个重试逻辑、加一层缓存。适合集成第三方服务、搭建内部工具链、做数据管道。
Spec范式，即“规格驱动”。你先用自然语言写一份精确的规格说明，包含输入输出示例、边界条件、错误处理策略，然后让AI严格按照规格生成代码和测试用例。这个范式的关键在于“规格本身的质量决定产出质量”。适合核心业务逻辑、需要长期维护的模块、以及有合规要求的场景。
Smell范式，直译是“坏味道驱动”。你拿一段已有的代码让AI分析，找出潜在的代码坏味道——重复逻辑、过长的函数、隐式的耦合、缺失的边界检查——然后有针对性地重构。这个范式适合接手遗留项目、做代码审查、以及在迭代中持续保持代码健康度。
这五种范式的关系不是线性的，而是一个循环。一个典型的项目周期可能是：Vibe探路 → Plan定框架 → Spec写核心 → Glue做集成 → Smell做优化 → 回到Plan进入下一轮迭代。关键在于你知道自己当前处于哪个阶段，以及该用哪种范式。
很多人用AI编程效率低，根本原因不是模型不够强，而是在Vibe阶段纠结代码质量，在Spec阶段又懒得写清楚规格，范式错配导致反复返工。
下面我逐个拆解每种范式的具体操作方式、适用边界、以及我在实际项目中踩过的坑。
2. Vibe范式：从模糊想法到可运行原型的最短路径
2.1 什么时候该用Vibe，什么时候不该用
Vibe范式的本质是“用最低成本换取最大信息量”。当你对一个技术方案没有把握时，最快的验证方式就是让AI先跑一版出来看看效果。比如你想做一个浏览器端的图像处理工具，不确定用Canvas还是WebGL，那就分别让AI生成两个最小Demo，跑一下性能对比，十分钟就能做出判断。
但Vibe范式有一个明确的禁区：不要用它来写任何需要长期维护的核心逻辑。原因很简单，Vibe产出的代码是“对话的副产品”，它的结构服务于当时的对话上下文，而不是服务于项目的整体架构。你让AI写一个用户认证模块，它可能给你一个能跑的版本，但里面的错误处理、日志埋点、配置管理大概率是缺失的。
我自己的判断标准是这样的：
| 场景 | 适合Vibe | 不适合Vibe |
|---|---|---|
| 技术选型验证 | 是 | — |
| 原型Demo | 是 | — |
| 一次性脚本 | 是 | — |
| 核心业务逻辑 | — | 是 |
| 对外API接口 | — | 是 |
| 数据处理管道 | — | 是 |
2.2 让Vibe产出质量提升一个档次的操作细节
虽然Vibe追求的是速度，但有几个操作细节能显著提升产出质量，而且几乎不增加时间成本。
第一，给AI一个具体的参照物。不要说“帮我写一个任务管理工具”，而是说“帮我写一个任务管理工具，交互风格参考Trello的看板视图，数据先存在localStorage里”。参照物越具体，AI的产出越接近你的预期。
第二，限制技术栈的范围。如果你不说，AI可能会选一个你完全不熟悉的框架。明确告诉它“只用原生JavaScript和CSS，不引入任何第三方库”，这样产出的代码你至少能看懂、能改。
第三，要求AI在代码里加注释说明关键决策。比如“在涉及状态管理的地方加注释，说明为什么这样设计”。这些注释在你后续决定是否保留这版代码时，是重要的判断依据。
第四，一次性生成完整可运行的文件。不要让AI分多次给你代码片段，那样拼装成本很高。直接要求“给我一个完整的HTML文件，包含所有必要的样式和脚本，我可以直接保存运行”。
2.3 Vibe产出的代码该怎么处理
Vibe跑出来的原型，通常有三种命运：直接丢弃、作为参考重写、或者小修小补后保留。
我的经验是：如果这个原型验证了核心可行性，那就把它当作“可执行的规格说明”，用Plan范式重新规划后再写正式代码。直接保留Vibe代码的风险在于，它的架构是“对话驱动”的，不是“需求驱动”的，随着功能增加会迅速变得难以维护。
具体操作上，我会把Vibe产出的代码通读一遍，提取出其中验证有效的部分——比如某个API的调用方式、某个算法的实现思路、某个交互的细节处理——然后在正式开发时参考这些片段。这样既保留了Vibe的速度优势，又避免了它的架构缺陷。
3. Plan范式：把返工成本扼杀在动手之前
3.1 一份合格的AI协作计划长什么样
Plan范式的核心产出是一份“人和AI都能读懂的执行计划”。这份计划不是传统的需求文档，它需要包含几个特定要素：
模块划分与依赖关系。把功能拆成独立的模块，明确每个模块的输入输出，以及模块之间的调用关系。这一步的关键是“让AI帮你检查有没有循环依赖或者遗漏的接口”。
每个模块的技术选型理由。不是简单地说“用Redis做缓存”，而是说“用Redis做缓存，因为需要支持TTL过期和原子递增操作，且数据量在单机内存可承受范围内”。
关键路径的伪代码。对于核心逻辑，用伪代码描述处理流程，让AI检查逻辑漏洞。伪代码的粒度控制在“能看出分支条件和循环边界”即可。
测试策略。明确哪些模块需要单元测试、哪些需要集成测试、哪些只需要手动验证。这一步经常被忽略，但它是后续Spec范式的基础。
我通常会让AI扮演“技术评审者”的角色，把计划发给它，让它从“可测试性、可扩展性、潜在性能瓶颈”三个维度提出质疑。这个操作能提前发现大量问题。
3.2 用AI做计划评审的具体提问方式
直接问“这个计划有什么问题”效果很差，AI会给你一堆泛泛而谈的建议。有效的提问需要限定视角和场景。
比如：
“假设这个系统上线后日活用户从100涨到10万，当前的数据存储方案会在哪个环节先出问题？给出具体的瓶颈点和触发条件。”
或者：
“这个模块的接口设计，如果后续需要支持批量操作和异步回调，当前的函数签名需要做哪些改动？改动会不会影响已有调用方？”
这种限定场景的提问方式，能逼着AI做具体的推演，而不是泛泛地罗列“要考虑性能、要考虑扩展性”之类的废话。
3.3 计划阶段的常见陷阱
过度规划。花三天时间写了一份五十页的设计文档，结果第一行代码还没写就发现某个核心假设不成立。Plan范式的计划应该是“足够指导下一步行动”即可，不需要穷尽所有细节。
计划与实现脱节。计划里写的是“用消息队列解耦”，实现的时候发现项目里根本没有消息队列的基础设施，临时改成同步调用，导致整个架构变形。避免这个问题的方法是：在计划阶段就确认所有依赖的基础设施是否就绪。
忽略非功能性需求。日志、监控、配置管理、错误追踪，这些东西在计划阶段如果不考虑，后期补上的成本极高。我的做法是在计划里专门留一个“可观测性”模块，明确日志格式、关键指标、告警阈值。
4. Spec范式：让AI写出可维护代码的关键
4.1 规格说明的四个必备要素
Spec范式和Plan范式的区别在于：Plan关注“怎么做”，Spec关注“做成什么样”。一份能让AI生成高质量代码的规格说明，必须包含以下四个要素：
输入输出的精确描述。包括数据类型、取值范围、格式要求。比如“输入是一个字符串数组，每个字符串长度不超过256，数组长度在1到1000之间”。
边界条件的明确列举。空输入怎么处理？超长输入怎么处理？非法字符怎么处理？这些必须在规格里写清楚，否则AI会自行脑补，而它的脑补往往和你的预期不一致。
错误处理策略。遇到错误是抛异常、返回错误码、还是降级处理？错误信息需要包含哪些上下文？这些决策需要在规格层面确定。
至少三个测试用例。一个正常用例、一个边界用例、一个错误用例。测试用例本身就是规格的一部分，它比自然语言描述更精确。
4.2 用规格驱动AI生成代码的实操流程
我的操作流程通常是这样的：
第一步，用自然语言写一份初版规格，不用追求完美，先把核心逻辑说清楚。
第二步，把规格发给AI，让它“找出规格中模糊、矛盾、遗漏的地方，列出需要澄清的问题”。这一步能发现大量自己没想清楚的地方。
第三步，根据AI的反馈补充规格，直到没有明显的歧义。
第四步，让AI根据最终规格生成代码和对应的测试用例。
第五步，运行测试用例，如果有失败，把失败信息连同规格一起发给AI，让它修正。
这个流程的关键在于：规格是唯一的真相来源。代码有问题改代码，测试有问题改测试，但如果规格本身有问题，必须回到第一步重新澄清。
4.3 规格的粒度控制
规格写得太粗，AI自由发挥的空间太大，产出不可控。规格写得太细，等于用自然语言把代码重写了一遍，失去了用AI提效的意义。
我的经验法则是：规格描述“做什么”和“约束是什么”，不描述“怎么做”。比如，规格里写“输入字符串需要去除首尾空白，中间连续空白压缩为单个空格”，但不写“使用正则表达式replace(/\s+/g, ' ')”。前者是行为约束，后者是实现细节。
对于核心算法，规格里可以包含伪代码，但伪代码的粒度控制在“能看出循环和分支结构”即可，不需要精确到变量命名。
4.4 Spec范式在团队协作中的价值
Spec范式最大的价值其实不在个人开发，而在团队协作。当规格成为唯一的真相来源时，多个开发者（或者多个AI会话）可以并行工作，只要大家都遵循同一份规格，集成时的冲突会大幅减少。
我参与过一个三人协作的项目，我们约定：任何人修改核心逻辑，必须先更新规格，再改代码。规格的变更需要另外一个人review。这个约定执行了两个月，代码合并冲突减少了大概七成。
5. Glue范式：集成工作的效率放大器
5.1 胶水代码的典型场景与生成策略
Glue范式处理的是“已有组件之间的连接问题”。典型场景包括：把第三方API的返回格式转成内部数据结构、给现有的函数加一层缓存、实现一个重试机制、写一个数据迁移脚本。
这类代码的特点是：逻辑不复杂，但细节繁琐，手写容易出错。让AI生成胶水代码的效率提升非常明显。
生成胶水代码的关键是提供完整的上下文。你需要告诉AI：源数据的格式是什么、目标格式是什么、中间需要做哪些转换、异常情况怎么处理。最好附上真实的示例数据。
比如，你要写一个把CSV转成JSON的脚本，不要只说“写一个CSV转JSON的脚本”，而是给出：
- CSV的列名和示例行
- 目标JSON的结构示例
- 特殊字段的处理规则（日期格式、空值处理、数字精度）
- 输出是数组还是按某个字段分组的对象
5.2 胶水代码的测试与验证
胶水代码的测试有一个特点：输入输出的对应关系非常明确，所以测试用例很容易构造。我通常会准备三组数据：一组正常数据、一组包含边界值的数据、一组包含异常数据。
验证的时候，除了看输出是否正确，还要关注：处理时间是否在可接受范围内、内存占用是否正常、异常情况下是否有合理的错误提示。
有一个容易忽略的点：胶水代码的日志。因为胶水代码通常是数据流经的通道，在关键转换节点加日志，能在出问题时快速定位是哪个环节的转换出了错。
5.3 胶水代码的维护策略
胶水代码最大的风险是“脆弱”。它依赖的外部接口一旦变化，胶水代码就会失效。所以胶水代码的维护策略核心是：把变化点集中管理。
具体做法是：把所有外部依赖的调用封装在独立的适配器函数里，业务逻辑不直接调用外部接口。这样当外部接口变化时，只需要修改适配器函数，不需要动业务逻辑。
另外，胶水代码应该有明确的版本标记和变更日志。每次外部接口变化导致胶水代码修改时，记录修改原因和影响范围。
6. Smell范式：用AI做代码审查的正确姿势
6.1 让AI识别代码坏味道的有效提问
直接让AI“审查这段代码”效果通常不好，它会给你一堆格式建议（比如“建议加空行”“变量名可以更 descriptive”），这些不是坏味道，是噪音。
有效的提问需要聚焦具体的坏味道类型。我常用的提问模板包括：
“这段代码里有没有重复的逻辑块？如果有，提取成独立函数的成本高不高？”
“这个函数的圈复杂度大概是多少？哪些分支条件可以合并或者提前返回？”
“这个模块对外暴露的接口，有没有暴露内部实现细节？调用方是否依赖了不应该依赖的东西？”
“这段代码里有没有隐式的假设？比如假设输入永远不为空、假设某个操作永远不会失败？”
这种聚焦式的提问，能让AI给出有实际价值的分析，而不是泛泛而谈。
6.2 坏味道的优先级排序
AI识别出的坏味道可能有很多，但不可能一次性全部修复。需要根据“修复成本”和“不修复的风险”做优先级排序。
我的排序原则是：
| 优先级 | 坏味道类型 | 判断标准 |
|---|---|---|
| 高 | 隐式假设、缺失边界检查 | 可能导致线上故障 |
| 高 | 重复逻辑 | 修改时容易遗漏，导致不一致 |
| 中 | 过长的函数 | 影响可读性和可测试性 |
| 中 | 深层嵌套 | 增加理解成本 |
| 低 | 命名不规范 | 影响可读性但不影响功能 |
| 低 | 格式问题 | 工具可以自动处理 |
6.3 重构过程中的AI协作方式
重构的时候，我习惯把AI当作“结对编程的搭档”。具体操作是：先让AI分析出需要重构的点，然后我决定重构的顺序和方式，再让AI生成重构后的代码，我来验证行为是否一致。
验证行为一致性的方法是：重构前后跑同一组测试用例。如果测试覆盖率不够，先补测试再重构。这是铁律，没有测试覆盖的重构等于赌博。
有一个实用的技巧：让AI在重构后的代码里，对每个修改点加注释，说明“原来是什么样、现在是什么样、为什么改”。这些注释在code review的时候非常有用，reviewer可以快速理解修改意图。
7. 五种范式的切换时机与组合策略
7.1 怎么判断当前该用哪种范式
判断标准其实很简单，问自己一个问题：我现在最大的不确定性是什么？
如果最大的不确定性是“这个东西能不能做出来”，用Vibe范式快速验证。
如果最大的不确定性是“怎么做才能不返工”，用Plan范式先规划。
如果最大的不确定性是“这些组件能不能接上”，用Glue范式做集成验证。
如果最大的不确定性是“逻辑对不对”，用Spec范式写清楚规格和测试。
如果最大的不确定性是“代码能不能撑住下一轮迭代”，用Smell范式做审查和重构。
7.2 一个完整项目的范式切换实例
以一个“内部数据看板”项目为例，我的范式切换路径是这样的：
第一周，Vibe范式。让AI快速生成一个静态页面，用假数据渲染图表，确认可视化效果和交互方式。
第二周，Plan范式。确定数据源、刷新频率、权限模型、部署方式，画出模块依赖图。
第三周，Spec范式。为核心的数据聚合逻辑写规格和测试用例，确保计算逻辑正确。
第四周，Glue范式。对接真实数据源，写数据转换和缓存层。
第五周，Smell范式。审查前四周的代码，重构重复逻辑，补充边界检查。
第六周，回到Plan范式，规划下一轮迭代的功能。
这个路径不是固定的，但核心逻辑是：先用低成本方式验证可行性，再用高成本方式保证质量。
7.3 范式错配的典型症状
范式错配的症状通常表现为：
- 在Vibe阶段纠结代码风格，导致原型产出速度极慢
- 在Plan阶段过度设计，写了大量永远不会用到的抽象层
- 在Spec阶段规格写得太粗，AI生成的代码反复修改
- 在Glue阶段没有做集成测试，上线后发现数据格式不匹配
- 在Smell阶段一次性重构太多，引入新的bug
识别这些症状的关键是：关注“返工次数”。如果同一个功能反复修改超过三次，大概率是范式用错了。
8. 我踩过的坑和总结出的几条硬规则
第一个坑：在Vibe阶段让AI生成“完整项目”。我曾经让AI一次性生成一个包含前后端的完整应用，结果代码量太大，AI在生成过程中丢失了上下文，前后端的接口定义对不上。后来我改成“每次只生成一个可独立运行的最小单元”，问题就消失了。
第二个坑：Plan阶段的计划没有版本管理。计划改了之后没有记录变更，导致实现的时候参考的是旧版计划。后来我养成了习惯：计划文件放在项目根目录，每次修改都在文件头部加变更记录。
第三个坑：Spec阶段的测试用例和规格脱节。规格改了但测试没改，导致测试通过但行为不符合预期。现在的做法是：规格和测试用例放在同一个文件里，修改规格时必须同步修改测试。
第四个坑：Glue阶段忽略了错误处理。胶水代码里对外部接口的调用没有做超时和重试，导致一个慢接口拖垮了整个数据管道。现在的做法是：所有外部调用必须设置超时，必须有重试逻辑，必须有降级方案。
第五个坑：Smell阶段的重构没有回滚方案。重构到一半发现方向错了，但代码已经改得面目全非，回滚成本极高。现在的做法是：重构前先打tag，每完成一个独立的重构点就提交一次，确保随时可以回滚到上一个可用状态。
几条硬规则：
- 任何阶段产出的代码，如果没有测试，就不算完成。
- 任何外部依赖，如果没有超时和重试，就不算集成完成。
- 任何规格，如果没有至少三个测试用例，就不算写清楚。
- 任何重构，如果没有回滚方案，就不算准备好。
这五条规则看起来简单，但执行到位能避免大部分返工。我在实际项目中反复验证过，效果很稳。
