1. 五种范式到底在解决什么问题第一次听到“Vibe Coding”这个词是在一个周末的深夜当时我正对着一个报错堆栈发呆脑子里想的是“能不能别让我一行行查了直接告诉我要改哪里”。后来陆续接触到 Plan、Glue、Spec、Smell 这几个词才发现它们并不是什么玄学概念而是把“人和 AI 一起写代码”这件事拆成了五种截然不同的协作姿势。有人把它们当成五个工具其实更准确的理解是这是五种你和 AI 之间的分工协议。先说清楚这五种范式各自站在什么位置。Vibe 是“我描述感觉你来写”Plan 是“我先想清楚你按计划执行”Glue 是“我搭骨架你填血肉”Spec 是“我把规格写死你严格照做”Smell 是“我闻着不对劲你来帮我诊断”。它们不是互斥的一个真实项目里往往五种都会用到只是不同阶段侧重点不同。为什么现在要专门聊这个因为大多数人用 AI 写代码还停留在“打开对话框粘贴需求复制结果”的阶段。这种方式在写一个独立函数时没问题但一旦项目超过几百行、涉及多个文件、需要长期维护就会立刻崩盘。我见过太多人抱怨“AI 写的代码跑不起来”“改着改着就乱了”根因不是模型不行而是协作范式选错了。你让一个擅长即兴发挥的模式去干需要严格约束的活结果必然失控。这篇文章面向的是已经用过 AI 编程工具、但总觉得“差那么点意思”的开发者。不管你是写 Python 脚本做数据处理还是维护一个中型前端项目或者只是想让 AI 帮你改改配置文件这五种范式都能直接套用。我会把每种范式的适用场景、具体操作步骤、真实案例和踩坑经验都摊开讲你可以当成一份“协作姿势选择手册”来用。提示下面每种范式我都会给出“什么时候用”“怎么操作”“实测案例”三个部分你可以按需跳读但建议至少把 Vibe 和 Spec 这两节看完因为它们代表了两个极端理解了这两个中间三种就很好把握了。2. Vibe Coding把感觉说清楚让 AI 先跑起来2.1 什么场景下该用 VibeVibe Coding 的核心是低约束、高速度。你不需要提前想清楚所有细节只需要把“我想要什么感觉”描述出来AI 会给你一个能跑的初版。它最适合这几种情况一是你在探索一个不熟悉的领域比如第一次写某个库的调用代码自己都不知道 API 长什么样二是你在做原型验证只需要快速看到效果不关心代码质量三是你在写一次性脚本用完就扔不需要维护。反过来如果你要写的是核心业务逻辑、需要长期维护的模块、或者涉及数据安全的代码Vibe 就不合适了。我见过有人用 Vibe 模式让 AI 生成数据库迁移脚本结果 AI 凭感觉写了个DROP TABLE幸好是在测试环境。所以用之前先问自己这段代码如果写错了后果严重吗严重就别用 Vibe。2.2 怎么把“感觉”翻译成 AI 能懂的指令很多人用 Vibe 效果不好是因为描述太模糊。你说“帮我写个登录功能”AI 只能猜。有效的 Vibe 指令要包含三个要素输入输出示例、技术栈约束、风格偏好。比如用 Python 写一个函数输入是一个包含用户信息的字典列表 输出是过滤掉年龄小于 18 岁的用户后的列表。 用列表推导式不要用 for 循环代码尽量短。这个指令里“输入输出示例”让 AI 知道数据形状“技术栈约束”限定了语言和写法“风格偏好”告诉它你要什么味道。实测下来加上这三样AI 一次生成可运行代码的概率能从三成提到七成以上。还有一个技巧是给 AI 一个“参照物”。比如你说“按照 requests 库的风格来写”AI 就会模仿那种简洁的链式调用。你说“像 Flask 路由那样组织”它就知道要用装饰器。这比你说“写好看点”有效得多。2.3 一个真实案例用 Vibe 快速搭一个数据清洗脚本上周我需要处理一批 CSV 文件里面有日期格式不统一、有空值、有重复行。这种活我完全不想手写就用 Vibe 模式试了一下。我的指令是写一个 Python 脚本读取当前目录下所有 csv 文件 把日期列统一成 YYYY-MM-DD 格式删除全空的行 去掉完全重复的行输出到 cleaned 目录。 用 pandas代码要能直接跑不要用 argparse。AI 给了我一版代码我跑了一下发现日期列的名字它猜的是date但我的文件里叫日期。我补了一句“日期列名是中文的‘日期’”它立刻改对了。整个过程不到五分钟脚本就能用了。这就是 Vibe 的价值你不需要提前知道 pandas 的to_datetime怎么处理混合格式AI 会帮你查。但我也踩过一个坑AI 生成的代码里用了df.drop_duplicates()但没有指定subset结果它把所有列都考虑进去了而我只想去重“订单号”相同的行。这个错误在 Vibe 模式下很常见因为 AI 不知道你的业务规则。所以用 Vibe 生成的代码一定要跑一遍真实数据检查边界情况。注意Vibe 模式生成的代码建议加一行注释标明“AI 生成未经过完整测试”方便后续维护时知道这段代码的来路。3. Plan 模式先写“施工图”再让 AI 砌墙3.1 Plan 和 Vibe 的本质区别Vibe 是“边想边做”Plan 是“想好了再做”。Plan 模式要求你在让 AI 写代码之前先和它一起把实现方案讨论清楚。这个方案包括要改哪些文件、每个文件改什么、函数签名是什么、数据结构怎么定义、异常怎么处理。听起来很繁琐但对于超过 200 行的改动Plan 模式能帮你省下大量返工时间。我自己的经验是如果一个任务需要改三个以上文件或者涉及两个以上模块的交互就必须用 Plan。比如“给用户模块加一个手机号登录功能”这涉及路由、数据库、验证逻辑、错误处理直接让 AI 写它很可能只改路由就交差了。但如果你先让它列计划它会告诉你“需要改 user_routes.py、user_model.py、auth_service.py并在数据库加一个字段”。3.2 怎么和 AI 一起做计划Plan 模式的操作流程分三步。第一步你把需求描述给 AI让它输出一个文件级别的改动清单。第二步你审查这个清单补充它漏掉的部分删掉它多做的部分。第三步你让它按清单逐个文件生成代码每生成一个你确认一个。这里有个关键技巧让 AI 用“伪代码”先写一遍。比如你说“先用注释写出每个函数的逻辑不要写实现”。这样你能快速看出它的思路对不对不对就改比看几百行代码快得多。我通常会让它输出这样的格式# 1. 在 user_model.py 中新增 phone 字段 # 2. 在 auth_service.py 中新增 send_sms_code 函数 # - 输入手机号 # - 输出验证码 # - 逻辑生成6位随机数存入缓存设置5分钟过期 # 3. 在 user_routes.py 中新增 /login/phone 路由 # - 接收手机号和验证码 # - 调用 auth_service 验证 # - 返回 token这个伪代码清单就是你的“施工图”。确认无误后再让 AI 逐个实现。实测下来这种方式生成的代码一次通过率比直接生成高很多因为你在计划阶段就排除了逻辑错误。3.3 Plan 模式中最容易忽略的“接口对齐”Plan 模式有一个隐藏陷阱AI 在生成不同文件时可能会对同一个数据结构有不同的理解。比如它在 model 里把用户 ID 定义成int但在 route 里当成str用。这种错误在单独看每个文件时很难发现只有跑起来才会报类型错误。我的应对方法是在计划阶段就明确写出关键数据结构的定义。比如User 对象 - id: int - phone: str - created_at: datetime然后要求 AI 在每个文件里都引用这个定义。如果项目里有types.py或models.py就让它从那里导入。这样能避免大部分接口不一致的问题。还有一个经验Plan 模式适合有明确验收标准的任务。比如“实现一个排序算法”你知道排完序就是对的。但如果是“优化页面加载速度”验收标准模糊Plan 模式反而会限制 AI 的发挥。这种时候更适合 Vibe 或 Glue。4. Glue 模式你搭骨架AI 填血肉4.1 Glue 模式的适用边界Glue 模式是我日常用得最多的一种。它的核心是你负责架构和关键逻辑AI 负责填充重复性代码。比如你定义了一个类的所有方法签名让 AI 写每个方法的具体实现或者你写好了主流程让 AI 补全每个步骤的细节。这种模式特别适合有固定套路的代码。比如 CRUD 接口、数据转换函数、配置文件解析、单元测试。这些代码结构相似但手写又很费时间。你搭好骨架后AI 能很快填满而且质量通常不错因为套路固定它不容易出错。但 Glue 模式不适合需要创造性设计的部分。比如你要设计一个缓存淘汰策略或者实现一个复杂的业务规则引擎这些需要你自己想清楚AI 只能帮你写边角料。我见过有人让 AI 设计整个微服务架构结果生成了一堆互相矛盾的接口定义根本跑不起来。4.2 怎么搭一个“AI 好填”的骨架骨架的质量直接决定 AI 填充的效果。一个好的骨架应该包含完整的函数签名、清晰的注释说明、输入输出的类型标注、以及关键步骤的占位注释。比如def process_order(order: dict) - dict: 处理订单计算最终价格。 输入 order 包含 - items: list[dict]每个 dict 有 price 和 quantity - discount_code: str可选 - user_level: strnormal 或 vip 输出 - final_price: float - discount_amount: float # 1. 计算商品总价 # 2. 根据 discount_code 计算折扣 # 3. 根据 user_level 计算额外折扣 # 4. 返回最终价格和折扣金额 pass这个骨架里注释已经写清楚了每一步要做什么AI 只需要把pass替换成实现。实测下来这种骨架的填充准确率很高因为 AI 不需要猜你的意图。4.3 Glue 模式的验收技巧AI 填完代码后不要直接跑先做静态检查。我通常会让 AI 自己检查一遍“你写的代码里有没有变量未定义、类型不匹配、边界条件没处理的地方”它往往能自己发现几个问题。然后我再跑单元测试重点测边界情况空输入、超大输入、异常输入。还有一个技巧是让 AI 写测试。你说“给刚才生成的每个函数写一个 pytest 测试覆盖正常情况和两种异常情况”。这样你不仅得到了实现还得到了测试用例。如果测试跑不过说明实现有问题你可以把报错信息贴回给 AI让它修。提示Glue 模式下建议把 AI 生成的代码和你的骨架放在同一个文件里用注释分隔。这样后续维护时你能一眼看出哪些是手写的哪些是 AI 填的。5. Spec 模式把规格写死让 AI 没有发挥空间5.1 什么时候需要“规格驱动”Spec 模式是五种范式里约束最强的一种。它的做法是你先写一份形式化的规格说明然后让 AI 严格按照规格生成代码。规格里要包含函数签名、参数类型、返回值类型、异常类型、边界条件、性能要求。AI 不允许“自由发挥”只能照做。这种模式适合对正确性要求极高的场景。比如金融计算、数据校验、协议解析、安全相关的代码。这些地方一旦出错后果很严重你不能接受 AI“猜”你的意图。Spec 模式通过把规格写死把 AI 的创造力限制在“翻译”而不是“设计”上。我自己的经验是Spec 模式写规格的时间可能比直接写代码还长。但它是值得的因为规格本身就是文档后续维护、测试、交接都用得上。而且规格写好后你可以让 AI 生成多个语言的实现或者生成测试用例复用性很高。5.2 一份合格的 Spec 长什么样Spec 不是自然语言描述而是接近代码的伪形式化语言。它应该包含这几个部分函数名calculate_interest 输入 principal: float, 必须 0 rate: float, 必须 0 且 1 years: int, 必须 1 输出 float, 保留两位小数 异常 ValueError: 当 principal 0 或 rate 不在 [0,1] 或 years 1 边界条件 rate 0 时返回 0 years 1 时按单利计算 算法 复利公式principal * (1 rate) ** years这份规格里每个参数的类型和约束都写清楚了异常情况也列出来了。AI 拿到这份规格只需要把它翻译成代码几乎没有发挥空间。实测下来这种方式的生成结果一次通过率接近百分之百因为所有歧义都在规格阶段消除了。5.3 Spec 模式的“过度约束”陷阱Spec 模式最大的风险是规格写得太死导致代码无法适应变化。比如你把“返回两位小数”写进规格但后来业务要求返回四位你就得改规格、重新生成、重新测试。如果这种变化很频繁Spec 模式反而会拖慢速度。我的建议是只把真正稳定的部分写进规格。比如算法逻辑、异常类型、参数约束这些通常不会变。而输出格式、日志级别、错误信息文案这些容易变的部分可以留给 AI 自由发挥或者用配置项控制。这样既保证了核心逻辑的正确性又保留了灵活性。还有一个经验Spec 模式适合有明确数学定义或协议定义的任务。比如“实现一个 Base64 编码器”规格就是 RFC 文档AI 照着写就行。但如果是“实现一个推荐算法”规格很难写清楚因为推荐效果的好坏没有绝对标准这种时候 Spec 模式就不合适。6. Smell 模式代码有“味道”时让 AI 帮你诊断6.1 什么是代码的“坏味道”Smell 模式不是用来写新代码的而是用来诊断和修复已有代码的。它的核心是你感觉代码“不对劲”但说不清楚哪里不对让 AI 帮你找出问题。这种“不对劲”就是代码坏味道常见的包括函数太长、重复代码太多、命名混乱、耦合太紧、异常处理缺失、性能瓶颈。我通常在这几种情况下用 Smell 模式一是接手别人的代码看不懂但感觉有问题二是自己写的代码跑得慢但不知道慢在哪三是代码能跑但改起来很痛苦每次改都要动好几个地方。这些时候让 AI 帮你“闻一闻”往往能发现你忽略的问题。6.2 怎么让 AI 帮你“闻”出问题Smell 模式的操作很简单你把代码贴给 AI然后问“这段代码有什么问题”但这样问太宽泛AI 可能只给你一些表面建议。更有效的方式是指定你要闻的方向。比如“这段代码有没有重复的逻辑”“这个函数的圈复杂度是多少哪里可以拆分”“这段代码有没有潜在的并发问题”“这个循环的时间复杂度是多少有没有优化空间”我试过让 AI 分析一个 300 行的函数它指出了三个问题一是中间有一段重复的日期格式化逻辑可以抽成函数二是异常处理只捕获了Exception太宽泛三是有一个循环里做了数据库查询会导致 N1 问题。这三个问题我自己看的时候都没注意到特别是 N1因为代码逻辑是对的只是性能差。6.3 Smell 模式的修复策略AI 诊断出问题后不要让它直接改。先让它给出修复方案你确认后再改。因为有些“坏味道”是故意的比如为了性能牺牲了可读性或者为了兼容旧接口保留了冗余代码。AI 不知道这些背景可能会把有用的代码“优化”掉。我的做法是让 AI 列出问题清单每个问题标注严重程度高/中/低和修复建议。然后我逐个判断哪些要修哪些不改。对于要修的再让 AI 生成修复后的代码我对比一下改动范围确认没有引入新问题。还有一个技巧让 AI 写一个“修复前后对比”。比如修复前函数 300 行圈复杂度 25 修复后拆成 5 个函数每个 50 行左右圈复杂度 8这样你能直观看到修复的效果也方便向团队解释为什么要做这次重构。7. 五种范式怎么组合使用7.1 一个项目的完整范式切换流程真实项目里五种范式不是孤立的而是按阶段切换的。我通常的流程是项目启动时用 Vibe 快速搭原型验证想法可行然后切换到 Plan 模式设计整体架构和文件结构接着用 Glue 模式填充各个模块的实现对于核心算法和关键逻辑用 Spec 模式严格约束最后用 Smell 模式做代码审查和优化。举个例子我之前做一个数据报表系统。第一周用 Vibe 模式让 AI 快速生成了一个能跑的原型虽然代码很乱但验证了数据源和报表格式没问题。第二周用 Plan 模式重新设计了模块划分数据获取、数据清洗、报表生成、导出。第三周用 Glue 模式把每个模块的骨架搭好让 AI 填充实现。第四周对报表生成的公式部分用 Spec 模式写了严格的规格确保计算准确。最后用 Smell 模式做了一轮审查发现了几处重复代码和性能问题修完后上线。这个流程的关键是不要试图用一种范式解决所有问题。Vibe 快但不可靠Spec 可靠但慢Plan 和 Glue 是中间地带Smell 是收尾。根据任务的性质和阶段灵活切换。7.2 范式选择速查表为了让你更快做决定我整理了一个速查表场景推荐范式理由探索新领域、写原型Vibe快速看到效果不纠结细节改多个文件、涉及模块交互Plan先理清依赖避免返工写 CRUD、数据转换、测试Glue套路固定AI 填充效率高核心算法、金融计算、协议解析Spec正确性要求高不能有歧义接手旧代码、性能优化Smell先诊断问题再决定怎么改一次性脚本、临时工具Vibe用完就扔不需要维护长期维护的核心模块Spec Glue关键逻辑用 Spec边角料用 Glue这张表不是绝对的但能帮你快速定位。我自己的习惯是新项目从 Vibe 开始稳定后转 Plan实现用 Glue核心用 Spec收尾用 Smell。7.3 组合使用时的注意事项组合使用最大的坑是范式切换太频繁。比如你刚用 Vibe 生成了一个函数马上切到 Spec 去改它结果发现 Spec 的约束和 Vibe 的代码风格冲突改起来很痛苦。我的建议是一个模块内尽量用一种范式模块之间可以不同。比如数据层用 Spec业务层用 Glue接口层用 Vibe。这样每个模块内部风格一致维护起来不混乱。还有一个经验范式切换时让 AI 重新读一遍上下文。比如你从 Plan 切到 Glue先让 AI 把之前的计划复述一遍确认它还记得。因为对话太长时AI 可能会忘记前面的约定。我通常会说“回顾一下我们刚才定的文件结构然后按那个结构填充 user_service.py”。这样能避免它跑偏。8. 实测中踩过的坑和总结的经验8.1 Vibe 模式的“幻觉代码”怎么防Vibe 模式最大的问题是 AI 会“编造”不存在的 API。比如它可能写df.read_csv_with_encoding()但 pandas 根本没有这个方法。这种错误在跑的时候才会暴露浪费调试时间。我的应对方法是让 AI 在生成代码后自己检查一遍所有 API 调用是否存在。你说“检查你刚才写的代码有没有调用不存在的函数或方法如果有改成正确的”。实测下来它能自己发现大部分幻觉。另一个技巧是让 AI 标注每个 API 的来源。比如“在代码注释里写明每个函数来自哪个库的哪个版本”。这样你一眼就能看出哪些是它编的。虽然它不一定标得准但至少能提醒你哪些地方需要验证。8.2 Plan 模式的“计划膨胀”问题Plan 模式容易走向另一个极端AI 会列出一个巨大的计划包含很多你根本不需要的步骤。比如你让它加一个登录功能它可能计划“重构整个用户模块、引入 OAuth、加双因素认证”。这时候你需要明确告诉它范围“只加手机号登录不要动其他部分不要引入新依赖”。把边界划清楚计划才不会膨胀。我通常会在 Plan 阶段加一句“只列必须的改动不要加‘顺便优化’的内容”。这样 AI 会收敛很多。如果它还是列多了你就手动删掉然后说“按这个精简后的计划执行”。8.3 Spec 模式的“规格漂移”怎么避免Spec 模式写好后如果需求变了规格也要改。但很多人改了代码忘了改规格导致规格和代码不一致后续维护时被误导。我的做法是把规格和代码放在同一个文件里规格用注释形式写在函数上方。这样改代码时自然会看到规格改完代码顺手改规格。如果规格太长就放在同目录的.spec.md文件里并在代码里引用。还有一个经验规格里不要写实现细节。比如你写“用快速排序”但后来发现数据量小用插入排序更快。规格应该写“排序结果正确时间复杂度不超过 O(n log n)”而不是指定算法。这样 AI 有优化空间你也不会被规格绑死。8.4 Smell 模式的“过度重构”风险Smell 模式诊断出问题后AI 可能会建议大规模重构。但重构是有风险的特别是没有测试覆盖的代码。我的原则是没有测试不重构。如果代码没有测试先让 AI 写测试跑通后再重构。这样重构过程中如果引入 bug测试能立刻发现。另外一次只修一个问题。不要一次性接受 AI 的所有建议那样改动太大出了问题很难定位。我通常按严重程度排序先修高严重度的跑一遍测试确认没问题再修下一个。这样即使出问题也能快速回滚。8.5 五种范式的共同底线不管用哪种范式有几条底线是不能破的。第一AI 生成的代码必须经过你的审查不能直接上线。第二关键逻辑必须有测试不能只靠“看起来对”。第三不要泄露敏感信息比如数据库密码、API 密钥这些不要贴给 AI。第四保持代码风格一致AI 生成的代码要符合项目的规范不能它写它的、你写你的。我自己的习惯是每次 AI 生成代码后先跑一遍 lint再跑一遍测试最后人工看一遍关键部分。这三步走完基本能过滤掉大部分问题。虽然麻烦但比上线后出故障再修要省事得多。最后分享一个小心得把每次和 AI 协作的过程记录下来。比如“这次用 Vibe 生成了数据清洗脚本踩了日期格式的坑”。积累多了你就能形成自己的“范式选择直觉”看到任务就知道该用哪种方式。这比任何教程都管用。