1. 五种AI编程范式到底在解决什么问题1.1 从“让AI写代码”到“和AI一起写代码”的认知转变过去两年我身边不少同行都经历过一个相似的曲线最开始用AI补全代码觉得效率提升明显用了一段时间后开始抱怨AI“乱写”“不靠谱”“改一处崩三处”再后来一部分人彻底放弃另一部分人则摸索出了一套和AI协作的固定套路。这个分水岭本质上就是AI编程范式的差异。所谓AI编程范式不是某个具体工具的功能而是人和AI在编码这件事上的分工方式与协作节奏。同样是用AI写一个功能模块有人一句话丢过去等结果有人先让AI出方案再逐段实现有人把AI当成胶水层来串联现有代码有人先写规格再让AI填充还有人专门让AI帮自己“闻”代码里的坏味道。这五种方式分别对应Vibe、Plan、Glue、Spec、Smell它们不是互斥的选项而是五种可以按场景切换的协作模式。我自己的体会是选错范式的代价远大于选错工具。用Vibe模式去做一个需要长期维护的核心模块前期爽后期痛用Spec模式去写一个一次性脚本则是杀鸡用牛刀。这篇内容就是把我这一年多在真实项目里反复切换这五种范式的经验拆开讲清楚包括每种范式适合什么场景、具体怎么操作、容易踩哪些坑。不管你是刚接触AI编程的新手还是已经用了一段时间但总觉得“差口气”的老手应该都能找到可以直接抄作业的部分。1.2 五种范式的核心定位与适用边界先把五种范式的定位用一句话说清楚后面再逐个展开。Vibe模式是“凭感觉快速出活”适合探索性、一次性、低风险的编码任务。Plan模式是“先谋后动”让AI先出实现方案人审核后再动手适合中等复杂度、需要架构判断的任务。Glue模式是“把AI当胶水”用来连接现有模块、适配接口、写转换层适合集成类工作。Spec模式是“规格驱动”先写清楚输入输出和约束再让AI填充实现适合需要长期维护、多人协作的模块。Smell模式是“让AI闻味道”专门用来识别代码坏味道、找潜在bug、做重构建议适合代码审查和遗留系统维护。这五种范式的选择核心看三个维度任务的生命周期一次性还是长期维护、风险等级写错了会不会出大事、人的精力预算你愿意花多少时间在前期设计上。下面这张表是我自己常用的决策参考范式核心动作适合场景风险等级前期投入Vibe直接描述需求让AI生成脚本、原型、探索性任务低极低Plan先让AI出方案再实现中等复杂度功能模块中中Glue让AI写适配和转换代码集成、接口对接、数据转换中低低Spec先写规格再让AI填充核心模块、多人协作高高Smell让AI审查和重构建议代码审查、遗留系统低低注意这张表里的“风险等级”指的是“AI写错后造成的后果严重程度”不是“AI写错的概率”。Vibe模式AI写错的概率其实不低但因为场景本身容错率高所以风险等级低。2. Vibe模式凭感觉快速出活的正确姿势2.1 Vibe coding的本质与适用场景Vibe coding这个词这两年被提得很多但很多人理解偏了。它的核心不是“随便写”而是在容错率高的场景下用最少的沟通成本换取最快的产出速度。你脑子里有个大概的想法不需要精确描述直接告诉AI“帮我写个什么东西”AI给你一版能跑的代码你看一眼觉得方向对就继续不对就换个说法再来。这种模式最适合的场景包括写一次性数据处理脚本、做技术验证原型、生成测试数据、写正则表达式、快速搭一个demo页面。这些场景的共同特点是代码不需要长期维护写错了重写成本极低而且你本身对要写的东西有基本判断力。我自己的习惯是凡是预计生命周期不超过一天的代码一律用Vibe模式。比如上周我需要把一批CSV文件里的时间字段统一格式这种任务我连函数名都懒得想直接跟AI说“写个Python脚本读目录下所有CSV把时间列统一成ISO格式输出到新目录”一版就过了。但如果是要写一个会被其他模块调用的工具函数我就会切换到Plan或Spec模式。2.2 Vibe模式的操作要点与避坑经验Vibe模式看起来最简单但有几个细节直接决定体验好坏。第一描述里要包含“验收标准”。很多人只说“写个什么”不说“写成什么样算对”。我一般会加一句“跑通后输出前5行给我看”或者“用pandas实现不要用csv模块”。这样AI生成的代码你一眼就能判断对不对不用逐行读。第二一次只做一件事。Vibe模式最大的坑是贪多。你让AI“写个脚本读数据、清洗、分析、画图、导出报告”它大概率会给你一坨能跑但结构混乱的代码改起来比重写还累。正确做法是拆成几步每步单独Vibe一次中间你自己看一眼结果。第三保留“重来”的勇气。Vibe模式下AI第一版不对是常态不要试图在错误的基础上修修补补。我通常的做法是如果第一版方向不对直接重新描述需求再来一次而不是让AI“把刚才那个改一下”。因为Vibe模式的代码本身就没有精心设计修补的成本往往高于重写。第四注意上下文窗口的消耗。Vibe模式对话轮次多如果在一个会话里连续做很多任务上下文会越来越长AI后面会开始“忘事”。我的习惯是每完成一个独立任务就新开会话把上一个任务里值得保留的代码片段手动存下来。实操心得Vibe模式下我一般会要求AI“用最直白的写法不要用高级特性”。因为这种代码我可能只看一眼就扔用列表推导式还是for循环对我来说没区别但直白写法出bug的概率更低我扫一眼就能确认逻辑。3. Plan模式先让AI出方案再动手3.1 为什么中等复杂度任务必须先PlanVibe模式用久了会遇到一个瓶颈当任务复杂度上升到“需要设计”的程度时直接让AI写代码会得到一个能跑但结构糟糕的结果。这时候就需要Plan模式——先让AI输出实现方案人审核调整后再让它写代码。Plan模式的核心价值在于它把“设计”和“实现”拆成了两步。设计阶段人参与度高确保方向正确实现阶段AI参与度高确保速度。我自己的经验是凡是预计代码量超过100行、或者会被其他模块调用的功能都应该先Plan。举个例子我之前要做一个配置加载模块需要支持多环境、多格式、热更新。如果直接VibeAI大概率会给我一个能读JSON的函数但多环境切换、格式自动识别、热更新这些点它可能漏掉或者实现得很别扭。用Plan模式我先让AI输出“这个模块应该有哪些类、每个类的职责、关键接口长什么样”它给了我一个三层结构ConfigLoader负责读取、ConfigMerger负责合并、ConfigWatcher负责监听。我看了觉得合理只调整了一处把格式识别从Loader里拆出来然后让它按这个结构实现一次就过了。3.2 Plan模式的具体操作流程我的Plan模式标准流程分四步第一步描述需求和约束。不要只说“我要做什么”要说清楚“在什么环境下、和什么系统交互、有什么性能要求、团队有什么编码规范”。这些约束会直接影响方案设计。第二步让AI输出方案而不是代码。明确说“先不要写代码给我一个实现方案包括模块划分、关键接口、数据流”。这一步的输出应该是文字描述加接口签名不是完整实现。第三步审核并调整方案。重点看三件事模块划分是否合理、接口设计是否清晰、有没有遗漏的边界情况。我一般会问AI“如果输入是空值会怎样”“如果并发调用会有什么问题”让它补充这些点的处理方案。第四步确认方案后让AI分模块实现。不要让它一次性把所有模块都写完而是一个模块一个模块来每个模块写完你扫一眼再继续。这样如果发现方案有问题调整成本低。步骤人的动作AI的动作产出物1描述需求与约束理解需求需求确认2要求出方案输出模块划分与接口方案文档3审核调整补充边界处理最终方案4逐模块确认分模块实现可运行代码注意Plan模式下最容易犯的错是“方案太粗”。如果AI给的方案只有“一个类负责处理数据”这种级别那和没Plan差不多。好的方案应该细到“这个类有哪些方法、每个方法的输入输出是什么、异常怎么处理”。4. Glue模式把AI当成模块之间的粘合剂4.1 Glue模式的典型场景与价值Glue模式是我在日常工作中用得最多的一种范式因为大部分实际开发工作不是从零写新模块而是把已有的东西连起来。比如把A系统的输出转成B系统能吃的格式、给旧接口写一个适配层、把两个不同来源的数据合并、写一个中间件做协议转换。这些工作的共同特点是逻辑本身不复杂但细节繁琐手写容易出错。Glue模式的核心思路是你告诉AI“输入长什么样、输出要什么样”让它生成中间的转换代码。你不需要描述转换逻辑AI会根据输入输出的结构自己推断。这比Vibe模式更聚焦比Plan模式更轻量。我最近的一个实际案例是需要把一个内部系统的日志格式转成另一个监控平台能识别的格式。输入是JSON Lines每条日志有十几个字段输出需要特定的字段名映射、时间格式转换、部分字段的枚举值翻译。这种活手写大概要一两个小时还容易漏字段。我用Glue模式把输入样例和输出样例各贴几条给AI说“写个转换函数输入是这种格式输出是这种格式”它五分钟就给我了我跑了几条测试数据确认无误就用了。4.2 Glue模式的实操技巧与注意事项Glue模式看起来简单但有几个技巧能显著提升成功率。第一给样例比给描述更有效。转换类任务里“输入长这样、输出要这样”比“把字段A改成字段B”这种描述清晰得多。我一般会贴2-3条输入样例和对应的期望输出AI基本能准确推断映射关系。第二明确异常处理策略。转换代码最怕的是遇到意外输入直接崩掉。我会明确告诉AI“遇到无法解析的字段时记录警告并跳过不要抛异常”或者“如果必填字段缺失抛出带字段名的异常”。不说的话AI默认行为不确定。第三要求生成测试用例。Glue模式的代码逻辑不复杂但分支多我一般会让AI“同时生成一组测试用例覆盖正常情况和边界情况”。这样我不用自己想测试数据跑一遍就知道有没有问题。第四注意性能敏感场景。如果转换代码会被高频调用要明确告诉AI“这个函数每秒会被调用上千次注意性能”。否则AI可能写出每次调用都重新编译正则、或者做不必要的深拷贝的代码。实操心得Glue模式下我习惯让AI把转换逻辑写成纯函数——输入输出都是数据不依赖外部状态。这样测试起来方便也容易在需要的时候改成批量处理。如果AI写成了带副作用的代码我会让它重写成纯函数形式。5. Spec模式规格驱动的高可靠编码5.1 Spec模式的核心思想与适用条件Spec模式是五种范式里前期投入最大的但也是长期收益最高的。它的核心思想是先把规格写清楚再让AI按规格填充实现。规格包括输入输出的精确类型、边界条件、异常行为、性能约束、依赖关系。写规格的过程本身就是一次设计审查很多问题在写规格阶段就会暴露。Spec模式适合的场景很明确核心业务模块、会被多人调用的公共库、需要长期维护的代码、有严格质量要求的系统。这些场景下前期多花一小时写规格后期能省十小时的调试和重构。我自己的判断标准是如果这段代码半年后还有人用就值得用Spec模式。反过来如果是一次性脚本或者原型验证用Spec就是浪费时间。5.2 Spec模式的规格模板与实操流程Spec模式的规格不需要写得很正式但必须包含几个关键部分。我常用的模板是这样的模块名称XXX 职责一句话说明这个模块做什么 输入类型、格式、取值范围、是否可空 输出类型、格式、正常情况、异常情况 边界条件空输入、超长输入、非法输入、并发调用 性能要求时间复杂度、内存限制、调用频率 依赖依赖哪些外部模块、版本要求 测试要求需要覆盖哪些场景写规格的时候我一般先自己写一版草稿然后让AI“审查这个规格指出遗漏的边界情况和潜在歧义”。AI经常能发现我没想到的点比如“如果输入是负数会怎样”“如果两个字段同时为空怎么处理”。补充完这些点之后再让AI按规格实现出来的代码质量明显高于直接Vibe。Spec模式的实现阶段也有讲究。我一般让AI先写测试再写实现也就是“根据规格生成测试用例确认测试用例覆盖了所有边界条件然后再写实现让测试通过”。这样出来的代码测试覆盖率天然就高而且测试用例本身就是规格的可执行版本。规格要素常见遗漏点补充方法输入空值、超长、非法格式让AI审查规格输出异常情况的返回明确异常类型边界并发、超时、资源耗尽逐项确认性能调用频率、数据规模给出具体数字依赖版本兼容、降级方案明确版本范围注意Spec模式最容易犯的错是“规格写得太抽象”。如果规格里写“输入是用户数据”那和没写一样。好的规格应该细到“输入是包含id、name、email三个字段的字典id是正整数name是非空字符串且长度不超过50email需要符合基本格式校验”。6. Smell模式让AI帮你闻出代码里的坏味道6.1 Smell模式的定位与使用时机Smell模式和其他四种不太一样它不是用来“写新代码”的而是用来审查和改进已有代码的。核心动作是把一段代码贴给AI让它指出潜在问题、坏味道、改进建议。这个模式特别适合几种场景接手遗留代码时快速摸底、代码审查时补充视角、重构前评估风险、学习别人的代码时理解设计意图。我自己的习惯是每次要改一段不熟悉的代码之前先用Smell模式让AI过一遍。它经常能发现一些我扫一眼没注意到的问题比如“这个循环里的异常捕获会吞掉所有错误”“这个变量在分支里被重新赋值但后面没用到”“这个函数同时做了三件事建议拆分”。这些观察不一定都对但能帮我快速建立对代码的判断。6.2 Smell模式的提问技巧与结果处理Smell模式的效果很大程度上取决于你怎么问。如果只问“这段代码有什么问题”AI会给一堆泛泛的建议。我一般会分几个维度问第一轮问“这段代码有没有明显的bug或逻辑错误”。重点看边界条件、异常处理、资源释放、并发安全。这一轮AI经常能发现一些隐蔽的问题。第二轮问“这段代码有哪些坏味道按严重程度排序”。坏味道包括重复代码、过长函数、过多参数、深层嵌套、魔法数字等。让AI排序能帮你优先处理影响最大的。第三轮问“如果要重构建议按什么顺序改”。重构最怕一次改太多导致引入新bug让AI给出分步方案每步改一点、测一点。第四轮问“这段代码有没有性能隐患”。重点看循环里的重复计算、不必要的内存分配、N1查询等。处理AI的反馈时我的原则是AI指出的问题不一定都要改但每一条都要过一遍脑子。有些是误报有些是风格偏好有些确实是真问题。我一般会把AI的建议分成三类必须改的真bug、安全问题、值得改的可读性、可维护性、可以忽略的风格偏好、过度设计。实操心得Smell模式下我习惯让AI“用提问的方式指出问题”比如“这个变量在异常分支里没有被初始化如果走到这个分支会怎样”。这种提问式的反馈比直接给结论更有助于我理解问题也避免了我盲目采纳AI的建议。7. 五种范式的切换时机与组合使用7.1 什么信号提示你该切换范式了实际工作中五种范式不是孤立使用的而是根据任务进展动态切换。我总结了几条切换信号从Vibe切到Plan的信号当你发现AI第一版代码方向不对、需要大改的时候当你意识到这个任务比预想复杂的时候当你开始纠结“这个逻辑放哪里”的时候。从Plan切到Spec的信号当方案讨论中发现边界情况很多、需要精确约定的时候当这个模块会被多人调用、接口需要稳定的时候当你发现方案里的接口设计反复调整的时候。从任何模式切到Glue的信号当你发现任务的核心是“把A转成B”而不是“实现某个逻辑”的时候当你手头已经有可用的模块、只需要连接的时候。从写代码切到Smell的信号当你接手一段不熟悉的代码的时候当你改完代码想确认没有引入问题的时候当你觉得“这段代码能跑但总觉得哪里不对”的时候。7.2 一个完整任务的范式切换实录用一个真实任务串一下。假设要做一个“用户行为日志分析模块”输入是原始日志输出是统计报表。第一步用Vibe模式快速验证可行性。先让AI写个最简单的脚本读日志、按用户分组、统计次数、打印结果。目的是确认数据格式和基本逻辑不追求代码质量。第二步用Plan模式设计正式结构。确认需求可行后让AI输出模块划分日志解析器、数据聚合器、报表生成器。审核接口设计确认数据流。第三步用Spec模式写核心模块。对日志解析器写详细规格支持哪些日志格式、字段类型、异常处理、性能要求。让AI按规格实现并生成测试。第四步用Glue模式写适配层。报表生成器需要对接现有的报表平台用Glue模式写格式转换代码把聚合结果转成平台能吃的格式。第五步用Smell模式做最终审查。整个模块写完后让AI过一遍检查有没有遗漏的边界情况、性能隐患、可读性问题。这个流程走下来比全程Vibe慢一些但代码质量高很多后期维护成本低。如果任务很小可能只走第一步和第五步就够了。任务阶段推荐范式主要产出时间占比可行性验证Vibe能跑的脚本10%结构设计Plan模块划分与接口20%核心实现Spec高质量代码与测试40%集成适配Glue转换与连接代码20%审查改进Smell问题清单与重构建议10%8. 常见问题与排查技巧实录8.1 五种范式下的高频问题速查在实际使用中每种范式都有几个反复出现的问题。我整理了一张速查表遇到问题时可以先对照排查。范式高频问题排查思路解决方法VibeAI生成的代码能跑但结构混乱检查是否一次做了太多事拆成多个小任务分别VibeVibe改一处崩三处检查是否在错误基础上修补重新描述需求从头生成Plan方案太粗实现时还是乱检查方案是否细到接口级别要求AI补充接口签名和数据流Plan方案合理但实现走样检查是否一次性实现所有模块分模块实现逐个确认Glue转换结果和预期不一致检查样例是否覆盖所有分支补充边界样例重新生成Glue遇到意外输入直接崩溃检查异常处理策略是否明确明确指定异常处理行为Spec规格写完了但实现还是有问题检查规格是否有歧义让AI审查规格补充边界Spec测试覆盖不全检查测试是否按规格生成先写测试再写实现SmellAI给的建议太多太泛检查提问是否太宽泛分维度提问要求排序SmellAI误报太多检查是否给了足够上下文补充代码背景和约束8.2 几个我踩过的坑和对应的解法坑一在Vibe模式里追求完美。刚开始用AI编程时我总想让AI一次生成完美的代码结果反复调整描述、反复让AI改效率反而比手写还低。后来想通了Vibe模式的定位就是快速出活代码质量不是首要目标。现在我Vibe的时候只关注“能不能跑通”跑通了就进入下一步不纠结代码风格。坑二Plan模式里让AI直接写代码。有段时间我让AI“先出方案再实现”但它经常在方案里夹带大量代码导致我审核方案时被代码细节带偏。后来我明确要求“方案里只写文字描述和接口签名不要写实现代码”审核效率高了很多。坑三Spec模式规格写太细导致僵化。有一次我把规格写得极其详细连每个变量的命名都规定了结果AI实现出来的代码虽然符合规格但很死板后续需求微调时改动成本很高。后来我调整了策略规格只约定接口和边界内部实现给AI留自由度。坑四Smell模式盲目采纳AI建议。有次AI指出我的代码“应该用策略模式替换if-else”我照做了结果代码复杂度反而上升。后来我给自己定了个规矩AI的重构建议如果会让代码行数增加超过30%就先放一放想清楚再说。实操心得这五种范式里我花时间最多的是Plan和Spec因为这两个阶段人参与度高做得好后面就顺。Vibe和Glue我基本是“用完即走”不投入太多精力。Smell我一般放在代码提交前做一次当作最后一道检查。8.3 关于工具选择的一点个人看法工具层面我用过不少AI编程助手最后稳定下来的组合是日常Vibe和Glue用一个响应快的Plan和Spec用一个上下文窗口大的Smell用一个能读整个项目的。具体产品名字就不提了因为这类工具迭代太快半年前好用的现在可能已经落后了。选工具的时候我主要看三点响应速度Vibe模式下等太久很影响节奏、上下文窗口Plan和Spec需要AI记住更多信息、代码理解能力Smell模式需要AI能读懂项目结构。这三点满足基本就能覆盖五种范式的需求。另外提一句不同范式对提示词的要求不一样。Vibe模式提示词可以很随意Plan模式需要结构化描述Spec模式需要精确的规格文档Glue模式需要清晰的输入输出样例Smell模式需要分维度的提问。我建议把这五种范式的提示词模板各准备一套用的时候直接套比每次现想要高效得多。最后分享一个我最近在用的技巧把五种范式的选择做成一个检查清单每次开始一个新任务前花30秒过一遍——这个任务的生命周期多长、风险多高、我愿意投入多少前期时间——然后决定用哪种范式。这个习惯帮我避免了很多“用错工具”的浪费也让整个开发节奏更可控。