1. 五顶帽子先戴好Vibe/Plan/Glue/Spec/Smell 的定位与关系过去两年我见过太多团队在“AI 编程到底行不行”这个问题上反复内耗。有人拿着聊天窗口狂写一通结果代码库变成垃圾场有人又走向另一个极端把 AI 彻底锁死在自动补全里。真正的问题从来不是 AI 水平不够而是大多数人只会一种用法。AI 编程早已不是单一模式而是至少可以拆成五种范式Vibe、Plan、Glue、Spec、Smell。这五个词不是学术黑话而是五顶不同功能的帽子戴错了场合项目就会翻车。1.1 一张表看懂五范式先用一张表把这五个范式的核心差异摆出来后面每个范式再单独展开。范式核心动作输入输出典型场景最大风险Vibe边聊边改、凭感觉引导模糊想法、口头描述可运行但未必规范的代码原型验证、一次性脚本失控与不可维护Plan先拆解、再执行目标、约束、资源限制可执行的任务清单复杂功能开发、多人协作计划脱离实际Glue上下文拼接、信息缝合分散的代码、文档、工具输出连贯的代码变更多文件重构、跨工具集成上下文丢失、张冠李戴Spec把需求写成无歧义规格需求描述结构化规格说明接口设计、契约锁定规格与实现脱节Smell检查、嗅探、发现问题已生成的代码问题清单与修复方案Code Review、质量守门误报与吹毛求疵这五个词里Vibe 和 Smell 是两极。Vibe 强调感觉先行Smell 强调理性审查。Plan 和 Spec 都讲究结构但 Plan 管的是“怎么做”Spec 管的是“做什么、做到什么程度”。Glue 则是最容易被低估的一个它解决的是 AI 编程里最现实的上下文断层问题。1.2 为什么是五种范式而不是一种“万能姿势”很多人以为 AI 编程的最高境界是“说话就能写代码”于是拼命追求让 AI 理解你所有意图。这个方向没有错但它只覆盖了 Vibe 这一种模式。真实工程里需求是模糊的、代码库是旧的、接口是别人定的、模型是有上下文窗口限制的。单一范式根本无法应对这种复杂度。五种范式本质上是人机协作的五种距离形态Vibe 离得最近凭直觉实时互动Plan 拉开一点距离先定方案再做Spec 把距离拉得更远用规格消灭歧义Glue 像胶水一样在松散部件之间传递信息Smell 则在最后一步退后审视全局。一个成熟的 AI 程序员应该是五顶帽子轮换着戴而不是只练一招。从我自己的实践看判断一个人 AI 编程是否入门就看他能不能说出“当前这个任务该用哪个范式”。接下来我就按这五个范式逐一拆解场景、用法和案例。2. Vibe Coding 的正确姿势和失灵时刻Vibe Coding 大概是这五个词里出圈最猛的一个因为 Codex 的聊天模式让无数人第一次体验到“边说边生成代码”的爽感。我见过有人把语音直接转成文字描述喂给 AI 一路改着玩这就是典型的 vibe 语音转文字式玩法。但 Vibe Coding 的流行也带来了严重的误用。2.1 Vibe Coding 的本质让“感觉”参与编程Vibe Coding 并不是“乱写代码”而是一种刻意降低前期规划成本、用快速反馈替代精确设计的编程状态。它的核心循环是描述想法、生成代码、运行观察、发现问题、再描述。整个过程里你的“感觉”是主要驱动力——代码“感觉对了”就继续“感觉不对”就叫 AI 调整。这种模式最适合三类场景。第一类是原型验证比如你脑子里有个小工具想看看思路是否成立半小时内能跑起来比什么都重要。第二类是一次性脚本处理完数据就不再用第二遍没必要纠结架构。第三类是个人项目、内部工具的快速迭代维护者只有你自己怎么方便怎么来。我在用 Codex 这类工具做 Vibe Coding 时会刻意把描述拆成“输入、处理、输出”三段再附上两个正反例。比如我会说“写一个脚本输入是 CSV 文件路径输出是每个分类的条数统计处理时忽略空行。举例a.csv 里有三行其中一行空行输出应该是 {A: 1, B: 1}。”这种描述方式让 AI 的首次生成命中率大大提升而不用反复掰扯。2.2 什么情况下千万别 Vibe三个红色信号Vibe Coding 的失控往往不是突然发生的而是“感觉”骗了你。我总结出三个红色信号只要命中一个就应该立刻切换到 Plan 或 Spec 范式。第一个信号是代码要进生产环境的核心链路。Vibe 生成的代码通常没有充分处理边界条件和异常看起来能用但一旦遇到超时、空指针、重复调用就可能线上事故。第二个信号是多人协作的代码库。你“凭感觉”让 AI 改了一段逻辑可能破坏别人依赖的隐式约定这种问题 Review 都很难查出来。第三个信号是接口契约敏感的业务比如支付、权限、数据处理——这些场景一个字段错误就是事故不能靠感觉。我还想补充一个容易被忽略的点Vibe 模式下的 AI 特别容易“自作主张”。你以为只是让 AI 加一个排序它顺手帮你把函数名改了、依赖升级了这种“惊喜”在个人原型里很可爱在团队项目里就是灾难。所以我的习惯是Vibe Coding 的每一轮修改之后先问 AI 一句“你具体改了哪些文件、动了哪些逻辑”确认它没有越权。3. Plan 范式把模糊需求变成可执行的作战地图如果说 Vibe 是冲锋Plan 就是战前推演。我在多个项目里发现AI 生成代码的质量很大程度取决于你有没有在生成之前把任务拆成一张可执行的作战地图。很多人让 AI 写复杂功能时翻车原因就是直接跳过了 Plan想一步到位。3.1 Plan 的本质是任务分解共识Plan 范式不是让 AI 给你列一个好看的 TODO而是你与 AI 共同确认四件事目标、约束、步骤、验证方式。目标描述“要什么”约束描述“不能碰什么”步骤描述“按什么顺序做”验证描述“怎么证明做完了”。缺了其中任何一项AI 都可能在中途给你惊喜或惊吓。我常用的 Plan 提示词模板长这样目标给现有订单模块增加一个按用户导出 CSV 的功能 约束 - 不改变现有数据库表结构 - 复用已有的鉴权逻辑不新写 - 导出文件大小上限 50MB 步骤 1. 新增导出接口路径 /api/orders/export 2. 查询当前用户权限内的订单数据 3. 在内存中生成 CSV 并写入响应流 4. 添加响应头 Content-Disposition 验证 - 调用接口返回 200且文件可正常打开 - 无权限用户调用返回 403 - 订单量为空时返回空 CSV不报错这个模板看起来简单但它的价值在于把“怎么做”的决策主动权从 AI 手里拿回了一部分。AI 依然负责实现细节但大的路线是你定的它不能随便绕道。3.2 Coding Plan 与 Token PlanPlan 范式里的两个产物在实践 Plan 范式时你会发现产物其实有两类一类是代码实现计划也就是上面那种结构化的开发计划另一类是 token 预算计划也就是对上下文、调用次数和模型资源消耗的统筹。现在各家模型厂商通常都有自己的 token plan 概念比如 qwen 的 token plan 会明确模型上下文窗口大小和计费阶梯。国内很多云厂商也在推自己的 coding plan 和 token 套餐产品本质是帮你把“AI 编程过程中的资源消耗”纳入规划。你可能觉得这很商业但在真实项目里token 规划不是小事。上下文窗口是有限的代码生成一次可能吃掉几千 token反复生成几次预算就爆了。我在做中大项目时会在 Plan 阶段顺便估算一个 Token 预算预计要生成多少文件、每个文件多大、需要几轮迭代。如果预算偏高我就先把大文件拆成小任务避免在 Glue 阶段因为上下文不足而出错。还有人会遇到类似“this account is ineligible for higher rate limits”之类的配额限制提示这本质上也是 Plan 阶段没有把供应商的速率限制和账号等级算进去。3.3 案例一个 API 接入任务的 Plan 拆解举一个我最近做的虚拟案例给内部系统接入一个第三方语音转文字 API。表面上需求很清楚——“把录音文件转成文字”但直接让 AI 写实现必然踩坑。我是这样拆 Plan 的目标接入第三方语音转文字服务支持上传音频并异步获取转写结果 约束 - 音频格式仅支持 mp3/wav单文件不超过 20MB - 转写结果需要落库避免重复调用第三方省钱 - 回调地址走现有内网网关不做公网暴露 步骤 1. 调研第三方 API 的鉴权与回调机制输出接口字段清单 2. 设计转写任务表结构保存任务状态与回调结果 3. 实现音频上传接口上传后创建转写任务 4. 实现回调接收逻辑更新任务状态 5. 实现查询接口支持按任务 ID 获取转写结果 6. 写一个 mock 服务模拟第三方回调供联调使用 验证 - 用 1MB 和 19MB 两个音频文件走通全流程 - 重复回调时任务状态不产生脏数据 - mock 回调失败时任务能标记为失败并有重试入口这个 Plan 的价值在于第 4 步的“mock 服务模拟第三方回调”是我特别加的因为真实接入第三方 API 时回调联调最容易卡住等对方环境不如自己造一个 mock。Plan 的颗粒度不需要到每一行代码但必须到“能发现潜在风险步骤”的程度。4. Glue 范式在上下文缝里做缝合很多人没意识到AI 编程里最多的 bug 不是“代码写错”而是“上下文没接上”。AI 生成了一个模块却不知道另一个模块里已有的工具函数或者它读了一个文件却忘了你两轮对话前交代的约束。这就是 Glue 范式要解决的问题——把分散的知识、文件、约束缝合到一起。4.1 为什么需要 Glue上下文窗口是现实物理约束一切缝合问题的根源是模型有限的上下文窗口。哪怕是号称大窗口的模型像 qwen token plan 里宣传的上下文窗口大小可能达到数万甚至更多 token但在真实代码项目里一个工程的文件加起来轻松超过这个量级。AI 不可能“看到”整个仓库它只能看到你喂给它的那一小块。理解这个物理约束后你就明白 Glue 的核心手法不是“让 AI 自己理解全仓库”而是你作为人在不同片段之间充当信息搬运工。你需要主动把 A 文件的关键函数签名、B 文件的调用约定、C 文件的历史决策摘要拼接成 AI 一次能读完的上下文包。4.2 Glue 的三种核心手法第一种是上下文压缩。AI 对话长了之后早期信息会稀释你要定期把已经确认的决策提炼成几条简短结论重新喂给 AI。比如“已确认使用 MQ 异步处理不使用定时任务数据库表结构不变鉴权走现有中间件”。这比让它重新读一遍历史记录高效得多。第二种是结构化中间文件。典型案例就是 spec 文件或 JSON 清单。我会在项目根目录放一个CONTEXT.md记录当前项目的技术栈、目录结构、关键函数、已定决策。每次开启新会话时先把这份文件丢给 AI它就能快速“进入状态”。这属于用文件系统做长期记忆专门对抗上下文丢失。第三种是多文件拼接和跨工具衔接。AI 在处理跨文件重构时往往只盯着你当前打开的文件。我的做法是把涉及的文件内容按依赖顺序裁剪拼接成一个临时文件让 AI 一次性读完再改。接外部工具时也一样——比如让 AI 生成 SQL我会顺手把表结构 DDL 塞进上下文而不是指望它“记得”你的表结构。4.3 案例跨文件重构中的 Glue 操作我做过一个库存模块重构涉及 6 个文件。第一步在 Plan 阶段拆出依赖关系Service 层调用 Repository 层Controller 层调用 Service 层。第二步我生成了一份精简上下文内容只包含三个 Repository 的方法签名和两个 Service 类的关键逻辑摘要总共不到 300 行。第三步让 AI 基于这份上下文重写 Service 层。结果比直接把整个 6 个文件全塞给它好得多——全塞的话AI 常常在无关细节里迷失甚至改坏 Controller 层的接口。Glue 不是把信息越多越好地塞给你而是挑选“相关度最高”的信息进行缝合。缝合的边界直接决定模型输出的质量边界。5. Spec 范式消除 AI 理解偏差的硬约束如果说 Plan 是作战地图Spec 就是施工图纸。地图告诉你往哪走图纸告诉你每一块砖砌在哪、用哪种型号。Spec 范式的核心是把需求写成无歧义的规格说明而不是一段抒情散文。这是五个范式里最有工程味的一个。5.1 Spec 不是文档是 AI 的执行标准很多团队把写 Spec 理解为“多写文档”这是误解。Spec 范式的目标不是给别人看而是给 AI 当执行标准。人看文档可以容忍模糊表述——“处理好异常情况”AI 不行它会对这句话进行最随机的发挥。Spec 要做的是把“处理好异常情况”替换成“当第三方接口返回 5xx 或超时 10 秒时重试 2 次依旧失败则将任务标记为 FAILED 并写入 error_log 表”。写 Spec 还有一个隐藏好处它逼你提前想清楚验收条件。人脑的特点是模糊思考不觉得累但一旦写规格就会发现“这里没想好”“那里有歧义”。这些模糊点如果不及时暴露最后就会变成 AI 生成的隐藏 bug。我的 Spec 模板通常包含五部分输入、处理规则、输出、异常分支、边界条件。处理规则用“当……则……”句式边界条件必须显式列出比如空值、最大值、重复值、并发场景。5.2 版本规格里的坑InvalidVersionSpecError 的启示Spec 写作里最容易被忽略的是对“精确值”的约束。这里我要提一个很有代表性的报错InvalidVersionSpecError: invalid version spec: 2.7。这个错误我见过不止一次原因是需求里写的版本约束是2.7但按依赖解析器的语法正确的精确版本约束应该是2.7。一个等号之差AI 或依赖库就会直接报错。这个例子的启示是写规格时的每个符号都是语义的一部分。你以为写的是自然语言AI 可能把它解析成代码语言。Spec 范式要求你像写接口契约一样写需求描述——每个字段名、每个符号、每个枚举值都要明确。如果需求里出现规则冲突比如“超时重试 2 次”和“总耗时不超过 5 秒”同时存在Spec 阶段就应该明确优先级而不是让 AI 猜。5.3 案例接口定义的 Spec 化过程我举一个接口定义的例子。第一版需求是“提供一个查询订单详情的接口。”这种需求给 AI它大概率会给你一个随机设计的接口。Spec 化之后是这样接口GET /api/v1/orders/{order_id}/detail 输入 - order_idLong必填大于 0 - 请求头Authorization 必填校验失败返回 401 处理规则 - 当订单属于当前用户时返回订单详情 - 当订单不存在时返回 404 error_codeORDER_NOT_FOUND - 当订单存在但属于其他用户时返回 404不泄露订单存在性 输出字段 - id、status、items[]、total_amount、created_at - items 为空时返回空数组不返回 null - total_amount 精确到分数字类型 超时要求接口 P95 响应时间 300ms这个规格写完AI 第一次生成基本可用Review 时几乎不用改逻辑。你也可以把这份 Spec 直接给不同厂商的模型跑一遍输出一致性会非常高。这就是 Spec 范式最实际的收益让 AI 的“自由发挥空间”压到最小。6. Smell 范式练出发现 AI 代码坏味道的嗅觉代码气味Code Smell这个概念并不新鲜但 AI 编程时代Smell 有了新的含义AI 生成代码的坏味道往往和人类写的坏味道不太一样。人类坏味道多是“过度设计”AI 坏味道多是“表面正确、深层脆弱”。6.1 从 Code Smell 到 AI Code SmellAI 生成的代码有一个显著特征结构看起来很规范但逻辑链条里藏着“看似合理的错误”。比如它会很自然地使用一个不存在的库函数因为它见过类似的 API但不确定参数顺序。又比如它会为了处理一个不存在的边界情况写三段死代码让阅读者困惑。Smell 范式要求你养成一种审查习惯每次让 AI 生成代码后不是直接信任它而是用一套固定清单去嗅探可疑点。我把这套清单挂在面前每一条都有具体的“气味信号”。6.2 我用来揪出 AI 代码味道的检查清单检查项典型气味信号处理方式幻觉 API用了看起来像库自带、但你从没见过的函数名先查官方文档别直接跑重复逻辑同一段处理出现在多个文件且细节有微妙差异抽取公共方法重新生成空异常处理except: pass或catch (Exception e) {}补日志和错误码必须明确兜底魔法数字代码里凭空出现3、60、1024等常量提为有名字的常量或配置项过度防御为不存在的前置条件写大量 if 判断删除冗余判断保持简单并发无保护见共享变量就写synchronized或lock()确认是否真的有竞态避免性能隐患这套清单我用下来最大的好处是能把“感觉不对劲”变成“具体哪里不对”。嗅探时也别只看代码本身还要看生成模式。如果 AI 在同一个文件里连续三轮修改都把逻辑绕回同一条路径说明它可能在缝补错误设计这时候应该直接推倒重写别再补丁上叠补丁。6.3 案例一段 AI 生成的代码怎么闻出坏味道举个很典型的例子。我让 AI 写一个“读取配置文件并设置默认值”的函数它给了我一个版本def load_config(path): with open(path) as f: data json.load(f) if data.get(timeout) is None: data[timeout] 60 return data表面看没问题但用 Smell 清单一查就有两处味道第一没有处理文件不存在的情况这在生产环境几乎必现第二timeout60是魔法数字。进一步追问后我发现这个函数在日志里没有任何输出一旦加载失败排查只能靠盲猜。这就是典型的 AI 表面正确代码。修复版本是加上了路径缺失处理、默认值集中管理和日志输出。看起来改动不大但这就是 Smell 范式的价值——它不让“能跑”成为质量标准而让“可靠、可维护、可排查”成为底线。7. 组合拳与选型心法真实项目里的五范式排兵布阵最后聊选型。我见过有人背下五种范式定义一上手还是乱套。问题在于他们不知道范式和项目阶段的关系。五范式从来不是互斥的而是随着项目推进动态切换的组合拳。7.1 五范式组合的典型模式按项目生命周期我总结了一个使用参考表阶段推荐范式使用要点探索/原型期Vibe快速验证想法不追求规范设计/拆解期Plan确定目标、约束、步骤、验证详细设计期Spec把关键接口、规则写成无歧义规格编码/集成期Glue管理上下文缝合多文件信息审查/稳定期Smell用检查清单逐项嗅探坏味道实际执行时会在几个范式间来回跳。比如我开始可能用 Vibe 快速验证一个技术思路确认可行后立刻进入 Plan 重新梳理再用 Spec 锁定关键接口编码过程用 Glue 维护上下文最后用 Smell 做输出守门。这不是流程化的表演而是每个阶段有每个阶段最省力的工具。7.2 决策问题当前这个任务到底该用哪种范式当你犹豫“现在该用哪种范式”时拿下面四个问题过一遍这个代码是一次性脚本还是长期维护的核心模块一次性就 Vibe长期维护就必须 Spec至少也得深度 Plan。我能接受多大的不确定性如果失败了只是重试不损失数据Vibe 和 Glue 就够如果失败可能导致脏数据或资损Plan、Spec、Smell 一个都不能少。代码库是只有我在写还是多人协作多人协作意味着上下文断裂的风险大增Glue 和 Spec 的权重就要提高。验收标准能不能写清楚能写清楚就走 Spec写不清楚就先 Vibe 探路探出方向再补 Plan、Spec。这四个问题回答完范式一般就自然浮现了。不要为了“用满五种范式”而强行切换那会变成流程表演。7.3 我的实战心法最后分享一点个人体会。我在实际项目里最常用的一条心法是从 Vibe 开始但尽快进入 Spec。Vibe 是用来降低探索门槛的不是用来交付的。一旦功能方向确认我会把“刚才那段对话里确认的事实”提炼成 5 行以内的 Spec 摘要塞给 AI 再进入正式编码。这样既享受了 Vibe 的快速又避免了它的失控。另一个心法是Glue 是 Plan 的延伸。我做的 Plan 不仅包含步骤还会顺手标注“这一步需要 Glue 哪些上下文”——比如第 3 步需要把某两个 Repository 的方法签名塞进提示词。这样执行时就不用手忙脚乱地临时找上下文。至于 Smell我会把它安排在“AI 连续改同一个文件第三轮”的时候强制开启因为这个时候 AI 最容易开始缝补而缝补正是坏味道的高发期。这套打法并不是什么高深理论但它确实让我从“每次都在和 AI 争吵代码”的状态里跳了出来。范式的价值不在于名称而在于它强迫你在动手之前先想清楚现在这个节点我到底该凭感觉、靠规划、拼上下文、写规格还是做审查。想清楚这一点AI 编程的质量才会有质的提升。