1. 五种AI编程范式到底在解决什么问题1.1 从“让AI写代码”到“和AI一起写代码”的认知转变过去两年我身边不少开发者对AI编程的理解还停留在“让AI帮我补全一个函数”的阶段。但真正把AI用出效率的人早就不这么干了。他们不再把AI当成一个高级的自动补全工具而是把它当成一个可以对话、可以规划、可以审查、可以兜底的协作对象。这个转变听起来简单但实际操作起来差别巨大。我最初也是“让AI写代码”那一派的。给一个需求让AI生成一段实现复制粘贴跑通就完事。结果就是代码能跑但我不敢改改了一处另一处就崩想加个功能发现原来的结构根本撑不住。后来我才意识到问题不在于AI写得不好而在于我没有给它足够的上下文和约束。于是我开始尝试不同的协作方式慢慢总结出了五种比较典型的范式Vibe、Plan、Glue、Spec、Smell。这五种范式不是互斥的也不是什么官方标准而是我在实际项目中反复切换、组合使用后沉淀下来的经验分类。它们分别对应不同的场景、不同的任务粒度、不同的风险等级。你可以把它们理解成五种“和AI对话的姿态”有时候你需要放松地聊有时候你需要严谨地规划有时候你只需要它帮你粘合两段代码有时候你必须把规格写死有时候你得让它帮你闻一闻代码里的坏味道。这篇文章会把这五种范式逐一拆开讲清楚它们各自适合什么场景、具体怎么用、有哪些坑、怎么组合。如果你正在用AI辅助编程或者准备把AI引入团队的工作流这些内容应该能帮你少走一些弯路。1.2 五种范式的核心定位与适用边界先给一个整体的定位方便你建立全局认知。Vibe范式核心是“氛围驱动”。你不需要给AI特别精确的指令而是通过描述一种感觉、一个方向、一段模糊的需求让AI先给出一个可运行的草稿。它适合探索性任务、原型搭建、你不确定具体怎么实现但知道大概想要什么的场景。优点是快缺点是粗糙需要后续打磨。Plan范式核心是“先规划再执行”。你把需求拆解成步骤让AI帮你制定实现计划确认后再逐步执行。它适合中等复杂度的功能开发尤其是涉及多个文件、多个模块协作的场景。优点是结构清晰缺点是前期沟通成本高。Glue范式核心是“粘合与适配”。你已经有了一些现成的代码、接口、数据结构需要AI帮你把它们连接起来。它适合集成第三方库、适配不同接口、写胶水代码的场景。优点是针对性强缺点是对上下文依赖高。Spec范式核心是“规格驱动”。你把接口定义、数据结构、边界条件、错误处理都写清楚让AI严格按照规格生成代码。它适合核心业务逻辑、对正确性要求高的模块、需要长期维护的代码。优点是可靠缺点是前期投入大。Smell范式核心是“代码审查与重构”。你让AI帮你识别代码中的坏味道比如重复代码、过长函数、深层嵌套、命名混乱等并给出重构建议。它适合代码审查、技术债清理、遗留系统改造的场景。优点是能发现你忽略的问题缺点是AI的判断需要你把关。这五种范式的关系可以用一个简单的表格来对比范式核心动作适用场景风险等级前期投入Vibe描述氛围生成草稿探索、原型、不确定需求低低Plan制定计划分步执行中等复杂度功能开发中中Glue连接现有代码与接口集成、适配、胶水代码中中Spec写死规格严格生成核心逻辑、高正确性要求低高Smell识别坏味道重构建议代码审查、技术债清理低低实际工作中我经常是组合使用的。比如一个新功能先用Vibe快速出一个原型确认方向后切换到Plan做详细规划核心模块用Spec写死规格集成部分用Glue粘合最后用Smell做一轮审查。这个流程走下来效率和质量都能兼顾。2. Vibe范式氛围驱动快速出草稿2.1 什么是Vibe Coding为什么它适合探索期Vibe Coding这个词最近很火但很多人理解得比较片面以为就是“随便让AI写”。其实不是。Vibe的核心在于“氛围”二字你给AI的不是精确的规格而是一种方向感、一种风格倾向、一种模糊但可感知的目标。你是在用自然语言描述一个“感觉”让AI把这个感觉翻译成代码。我最早接触这个思路是在做一个内部工具的时候。当时我需要一个简单的数据看板但具体要展示什么指标、用什么图表、怎么布局我自己都没想清楚。如果按照传统方式我得先画原型、定需求、再开发周期很长。于是我试着用Vibe的方式给AI描述了一段话“我想要一个深色主题的数据看板顶部有几个关键指标卡片下面是一个趋势图和一个分布图整体感觉要简洁、现代、信息密度适中。”AI很快就生成了一个可运行的页面虽然细节粗糙但方向对了。我在此基础上调整了几轮半天就搞定了。Vibe范式最大的价值是帮你快速跨越“从零到一”的门槛。很多时候最难的不是实现而是确定要什么。Vibe让你先有一个可以看、可以摸、可以改的东西然后再逐步细化。它特别适合以下几种场景新产品原型、内部工具、个人项目、你不确定技术方案时的探索、需要快速验证想法的时候。但Vibe也有明显的边界。它不适合核心业务逻辑不适合对正确性要求高的模块不适合需要长期维护的代码。因为Vibe生成的代码结构往往比较随意命名可能不规范边界处理可能不完整。你可以把它当成一个草稿但不能当成最终交付物。2.2 Vibe实操怎么描述氛围怎么控制方向用Vibe范式关键在于“描述氛围”的能力。你不能只说“帮我写个登录页面”那太宽泛了。你需要给AI一些具体的、可感知的线索。我通常从四个维度来描述第一视觉风格。比如“深色主题、圆角卡片、留白充足、字体偏细”。这些描述会影响AI生成的CSS和布局选择。第二交互感觉。比如“点击后有轻微的缩放反馈、切换标签时平滑过渡、加载时用骨架屏而不是转圈”。这些描述会影响AI对交互细节的处理。第三信息密度。比如“每屏展示不超过五个核心指标、列表项高度紧凑、重要数据用大字号突出”。这些描述会影响AI对布局和排版的决策。第四技术倾向。比如“用React函数组件、样式用Tailwind、状态管理先用useState就够了”。这些描述会影响AI的技术选型。举个例子我最近用Vibe方式让AI帮我做一个Markdown预览器。我的描述是这样的“我想要一个左右分栏的Markdown预览器左边是编辑区右边是实时预览。整体风格要像VS Code的深色主题字体用等宽字体预览区的标题要有明显的层级感代码块要有语法高亮。交互上滚动要同步编辑时预览区不要闪烁。技术栈用React加marked库样式用CSS Modules。”AI拿到这段描述后生成的代码基本符合预期。虽然有些细节需要调整比如滚动同步的阈值、代码高亮的配色但整体框架和方向都是对的。这就是Vibe的价值你不需要写规格只需要描述感觉AI就能给你一个可用的起点。注意Vibe范式下不要一次性让AI生成太多代码。我建议每次只生成一个组件或一个页面确认方向后再继续。否则一旦方向偏了返工成本很高。2.3 Vibe的常见坑与应对策略Vibe用多了你会发现几个典型的坑。第一个坑是“方向漂移”。你描述的是AAI理解成了B生成的东西和你想要的差很远。这时候不要急着改代码而是回到描述本身看看是不是自己的表达有歧义。我通常会重新组织语言把模糊的词换成具体的例子。比如“现代风格”太模糊改成“类似Linear的界面风格”就具体多了。第二个坑是“过度生成”。AI可能会给你生成一大堆你不需要的功能比如你只要一个按钮它给你生成了整个表单。这时候你需要明确边界告诉AI“只生成按钮组件不要包含表单逻辑”。第三个坑是“技术栈偏离”。你明明说了用ReactAI却给你生成了Vue的代码。这种情况通常是因为描述不够明确或者AI的默认倾向太强。解决办法是在描述开头就明确技术栈并且重复强调。第四个坑是“代码质量参差”。Vibe生成的代码质量波动很大。有时候很优雅有时候很粗糙。我的经验是Vibe阶段不要纠结代码质量先看方向对不对。方向对了后续可以用Smell范式来清理。3. Plan范式先规划再执行降低返工率3.1 Plan范式的核心逻辑把AI当成技术负责人Plan范式的核心是把AI当成一个技术负责人而不是一个代码生成器。你先和它讨论方案让它帮你制定实现计划确认后再逐步执行。这个范式适合中等复杂度的功能开发尤其是涉及多个文件、多个模块协作的场景。我为什么强调Plan的重要性因为直接让AI写代码最大的风险是“结构不对”。代码能跑但扩展性差、耦合度高、后续改不动。而Plan范式强迫你先想清楚结构再动手写。这就像盖房子先画图纸再砌墙。虽然前期多花了一些时间但后期省下的返工时间更多。我通常的Plan流程是这样的第一步把需求完整地描述给AI包括功能点、边界条件、技术约束。第二步让AI给出一个实现计划包括需要哪些文件、每个文件的职责、模块之间的依赖关系、关键数据结构。第三步我审查这个计划调整不合理的地方。第四步确认计划后让AI按步骤逐个实现。第五步每实现一个步骤我验证一下确认无误后再继续。这个流程看起来繁琐但实际用下来效率反而更高。因为每一步都是可控的不会出现“写了一大堆代码发现方向错了”的情况。3.2 怎么让AI给出靠谱的实现计划让AI给出靠谱的计划关键在于你的需求描述要足够清晰。我通常从五个方面来描述需求功能目标这个功能要解决什么问题用户怎么使用它。输入输出每个接口的输入是什么输出是什么数据格式是什么。边界条件空值怎么处理超长怎么处理并发怎么处理错误怎么返回。技术约束用什么语言、什么框架、什么库有没有性能要求。现有代码如果有现成的代码或接口需要一并提供给AI让它知道上下文。举个例子我之前让AI帮我规划一个“批量导入用户”的功能。我的描述是这样的“我需要一个批量导入用户的功能。输入是一个CSV文件包含姓名、邮箱、部门三个字段。输出是导入结果包括成功数量、失败数量、失败原因。边界条件CSV文件可能为空邮箱可能重复部门可能不存在。技术约束用Python实现读取CSV用pandas数据库操作用SQLAlchemy需要事务保证。现有代码用户表已经存在字段有id、name、email、department_id。”AI拿到这段描述后给出了一个很清晰的计划第一步解析CSV文件校验字段完整性。第二步批量查询已存在的邮箱过滤重复。第三步批量查询部门校验部门是否存在。第四步开启事务批量插入用户。第五步提交事务返回导入结果。这个计划基本符合我的预期我只调整了一点把“批量查询部门”改成“先缓存部门数据避免多次查询”。3.3 Plan范式的执行技巧与注意事项执行Plan的时候有几个技巧可以分享。第一分步验证。不要一次性让AI实现所有步骤而是每实现一个步骤你验证一下。这样一旦发现问题可以及时调整不会影响后续步骤。第二保持对话上下文。Plan范式下对话会很长。你需要确保AI始终记得之前的计划。我通常会在每个步骤开始前简要复述一下当前步骤的目标和约束。第三及时纠偏。如果AI的实现偏离了计划不要将就而是明确指出问题让它重新实现。将就的代价是后续更大的返工。第四记录决策。Plan过程中会有很多决策比如为什么用这个数据结构、为什么用这个算法。我建议把这些决策记录下来方便后续维护。提示Plan范式下AI给出的计划不一定是最优的。你需要用自己的经验来判断。如果计划中有你不确定的地方可以让AI解释它的理由或者让它给出多个方案对比。4. Glue范式粘合代码解决集成难题4.1 Glue范式的典型场景当你有现成代码但接不起来Glue范式的核心是“粘合”。你已经有了一些现成的代码、接口、数据结构需要AI帮你把它们连接起来。它适合集成第三方库、适配不同接口、写胶水代码的场景。我遇到最多的Glue场景是集成第三方API。比如你要接入一个支付接口文档很厚参数很多你不想从头写封装就可以让AI帮你生成一个适配层。你只需要把接口文档的关键部分贴给AI告诉它你的数据结构它就能帮你写出转换和调用的代码。另一个典型场景是适配不同模块。比如你有一个老系统用的是XML新系统用的是JSON你需要一个中间层来做转换。这种胶水代码逻辑不复杂但写起来很繁琐交给AI很合适。Glue范式的优点是针对性强你不需要给AI太多背景只需要把需要连接的两端说清楚。缺点是对上下文依赖高如果AI不了解两端的细节生成的代码可能跑不通。4.2 Glue实操怎么把两端说清楚用Glue范式关键在于把“两端”说清楚。我通常从三个方面来描述第一源端。数据从哪里来格式是什么有哪些字段字段类型是什么。如果是API还需要提供请求方式、URL、认证方式、请求参数、响应格式。第二目标端。数据要到哪里去格式是什么有哪些字段字段类型是什么。如果是数据库还需要提供表结构、字段约束。第三转换规则。源端到目标端的映射关系是什么哪些字段需要转换转换逻辑是什么。比如日期格式从“YYYY-MM-DD”转成“timestamp”金额从“分”转成“元”。举个例子我之前让AI帮我写一个“GitHub API到内部用户系统”的适配层。我的描述是这样的“源端是GitHub API的/users/{username}接口返回JSON包含login、name、email、avatar_url、company字段。目标端是内部用户系统的User对象包含username、display_name、email、avatar、organization字段。转换规则login映射到usernamename映射到display_nameemail直接映射avatar_url映射到avatarcompany映射到organization。如果email为空用login加github.com填充。”AI拿到这段描述后生成的代码基本可用。我只调整了一点增加了错误处理当GitHub API返回404时抛出明确的异常。4.3 Glue范式的边界与风险控制Glue范式虽然好用但有几个边界需要注意。第一不要用Glue处理复杂业务逻辑。Glue适合简单的转换和适配如果涉及复杂的业务规则应该用Spec范式。第二注意错误处理。胶水代码最容易忽略的就是错误处理。源端可能超时目标端可能拒绝转换可能失败。这些都需要考虑。第三注意性能。胶水代码可能被频繁调用如果每次都要做大量转换性能会成为瓶颈。需要考虑缓存、批量处理等优化。第四注意版本兼容。第三方接口可能会变胶水代码需要有一定的容错能力。我通常会在代码里加一些版本判断和降级逻辑。5. Spec范式规格驱动把正确性写死5.1 Spec范式的适用场景核心逻辑与高正确性要求Spec范式的核心是“规格驱动”。你把接口定义、数据结构、边界条件、错误处理都写清楚让AI严格按照规格生成代码。它适合核心业务逻辑、对正确性要求高的模块、需要长期维护的代码。我为什么强调Spec的重要性因为AI生成代码的质量很大程度上取决于你给的约束。你给的约束越明确AI的自由发挥空间越小生成的结果越可控。Spec范式就是把约束写到极致你不给AI任何猜测的空间所有细节都写死。Spec范式特别适合以下几种场景金融计算、权限校验、状态机、协议解析、数据校验。这些场景的共同特点是逻辑复杂、边界多、错误代价高。一旦出错后果严重。所以必须用Spec的方式把每个细节都定义清楚。5.2 怎么写一份AI能看懂的Spec写Spec的关键是“无歧义”。我通常从五个方面来写第一接口定义。函数名、参数名、参数类型、返回值类型、异常类型。每个参数都要说明含义和约束。第二数据结构。用到的所有数据结构包括字段名、字段类型、字段含义、是否可空、默认值。第三业务规则。每一步的逻辑用伪代码或自然语言描述清楚。如果有计算公式把公式写出来。第四边界条件。空值、零值、负数、超长、超限、并发、重复调用这些情况怎么处理。第五错误处理。每种错误对应什么异常异常信息是什么是否需要记录日志。举个例子我之前让AI帮我写一个“优惠券计算”的函数。我的Spec是这样的def calculate_discount(coupon, order_amount): 计算优惠券折扣金额。 参数: coupon: Coupon对象包含type、value、min_amount、max_discount字段 order_amount: 订单金额Decimal类型必须大于0 返回: 折扣金额Decimal类型保留两位小数 业务规则: 1. 如果order_amount coupon.min_amount返回0 2. 如果coupon.type fixed折扣金额 coupon.value 3. 如果coupon.type percent折扣金额 order_amount * coupon.value / 100 4. 如果coupon.max_discount不为空折扣金额不能超过coupon.max_discount 5. 折扣金额不能超过order_amount 边界条件: - order_amount 0抛出ValueError - coupon为None抛出ValueError - coupon.type不是fixed或percent抛出ValueError 错误处理: - 所有异常信息用中文描述 - 记录warning日志 AI拿到这份Spec后生成的代码几乎不需要修改。这就是Spec的价值你把所有细节都写死AI就没有犯错的空间。5.3 Spec范式的维护与迭代策略Spec范式的前期投入大但后期维护成本低。因为规格就是文档代码是规格的实现。当需求变化时你先改规格再让AI重新生成代码。这样代码和文档始终一致。我通常会把Spec保存在代码仓库里和代码放在一起。每次修改Spec都会在提交信息里说明原因。这样后续维护的人能清楚地知道每个逻辑的来龙去脉。注意Spec范式下不要频繁让AI重新生成整个模块。我建议只重新生成变化的部分避免引入不必要的改动。6. Smell范式让AI帮你闻出代码里的坏味道6.1 Smell范式的价值AI作为代码审查助手Smell范式的核心是“代码审查与重构”。你让AI帮你识别代码中的坏味道比如重复代码、过长函数、深层嵌套、命名混乱等并给出重构建议。它适合代码审查、技术债清理、遗留系统改造的场景。我为什么把Smell单独列为一个范式因为很多人用AI只关注“写代码”忽略了“审代码”。但实际上AI在代码审查方面非常擅长。它可以快速扫描大量代码发现你忽略的问题。而且它不会累不会因为代码太长就跳过。我通常用Smell范式做三件事第一定期审查自己的代码发现潜在问题。第二审查团队成员的代码提供改进建议。第三审查遗留系统制定重构计划。6.2 怎么让AI给出有价值的重构建议让AI给出有价值的重构建议关键在于“引导”。你不能只说“帮我看看这段代码”那太宽泛了。你需要告诉AI关注哪些方面给出具体的审查维度。我通常从六个维度来引导第一重复代码。有没有重复的逻辑能不能提取成函数或类。第二函数长度。有没有过长的函数能不能拆分。第三嵌套深度。有没有过深的嵌套能不能用早返回或策略模式简化。第四命名规范。变量名、函数名、类名是否清晰是否表达了意图。第五耦合度。模块之间的依赖是否合理有没有循环依赖。第六错误处理。错误处理是否完整有没有吞异常的情况。举个例子我之前让AI审查一个“订单处理”的模块。我的提示是这样的“请审查这段订单处理代码重点关注重复代码、函数长度、嵌套深度、命名规范、错误处理。对每个问题给出具体的重构建议并说明理由。”AI给出的审查结果很有价值。它发现了一个重复的“校验订单状态”逻辑出现在三个地方发现了一个超过200行的函数建议拆分成多个小函数发现了一个深层嵌套的if-else建议用策略模式替代还发现了几处命名不清晰的地方比如“data”改成“orderData”“handle”改成“processOrder”。6.3 Smell范式的局限与人工把关Smell范式虽然好用但也有局限。AI的判断不一定总是对的。有时候它认为的“坏味道”在你的业务场景下是合理的。比如某些重复代码是为了保持模块独立性故意不提取。某些长函数是因为逻辑确实复杂拆分反而增加理解成本。所以Smell范式下人工把关很重要。AI给出建议你来判断是否采纳。我通常会把AI的建议分成三类必须改的、可以改的、不用改的。必须改的是明显的错误和风险可以改的是优化项不用改的是业务需要。提示Smell范式下不要一次性让AI审查太多代码。我建议每次只审查一个模块或一个文件这样AI的分析更深入建议更具体。7. 五种范式的组合使用与实战案例7.1 一个完整功能的开发流程从Vibe到Smell前面分别讲了五种范式但实际工作中它们往往是组合使用的。我以一个“用户反馈系统”的开发为例展示完整的流程。第一步Vibe。我先用Vibe的方式让AI快速生成一个原型。我描述的是“我想要一个用户反馈系统用户可以提交反馈管理员可以查看和回复。界面要简洁提交表单包含标题、内容、联系方式。管理员界面用表格展示反馈列表可以筛选状态。”AI很快生成了一个可运行的原型虽然细节粗糙但方向对了。第二步Plan。原型确认后我切换到Plan范式。我把需求细化让AI制定实现计划。计划包括数据库表设计、API接口设计、前端页面拆分、状态管理方案。我审查了计划调整了表结构增加了“反馈分类”字段。第三步Spec。核心的“反馈状态流转”逻辑我用Spec范式写死规格。状态包括待处理、处理中、已回复、已关闭。每个状态的流转条件、权限要求、通知逻辑都写清楚。AI按照规格生成了状态机代码。第四步Glue。集成邮件通知功能时我用Glue范式。把邮件服务的API文档和反馈系统的数据结构提供给AI让它生成适配层。AI很快写出了发送邮件的封装代码。第五步Smell。功能开发完成后我用Smell范式做了一轮审查。AI发现了几处重复的权限校验逻辑建议提取成中间件发现了一个过长的控制器函数建议拆分还发现了几处命名不清晰的地方。我根据建议做了重构。这个流程走下来从原型到上线用了大约三天时间。如果按照传统方式至少需要一周。而且代码质量更好因为每个环节都有AI的参与和审查。7.2 不同场景下的范式选择建议不同的场景适合不同的范式。我整理了一个选择建议表场景推荐范式理由新产品原型Vibe快速验证方向不需要精确规格中等复杂度功能Plan需要结构清晰分步可控集成第三方服务Glue针对性强不需要太多背景核心业务逻辑Spec正确性要求高需要写死规格代码审查Smell快速发现问题提供改进建议遗留系统改造Smell Plan先审查问题再规划重构紧急修复Vibe Glue快速出方案粘合现有代码这个表不是绝对的你可以根据实际情况灵活调整。关键是理解每种范式的核心逻辑知道什么时候该用哪种。7.3 团队协作中的范式落地经验在团队中推广这五种范式我踩过一些坑也总结了一些经验。第一不要强制统一。每个人的习惯不同有人喜欢Vibe的随意有人喜欢Spec的严谨。强制统一会适得其反。我通常建议团队成员先了解五种范式然后根据自己的任务选择。第二建立共享的Spec库。Spec范式下规格是核心资产。我建议团队建立一个共享的Spec库把核心模块的规格保存下来。这样新人可以快速理解业务逻辑AI也可以参考历史规格。第三定期做Smell审查。我建议团队每周做一次Smell审查用AI扫描代码发现潜在问题。这比等到问题积累多了再处理成本低得多。第四记录范式使用案例。我建议团队记录每次使用范式的案例包括场景、提示词、AI输出、人工调整。这些案例可以作为培训材料帮助新人快速上手。提示团队协作中AI生成的代码需要有人把关。我建议指定一个“AI代码审查员”负责审查AI生成的代码确保质量。8. 常见问题与排查技巧实录8.1 五种范式使用中的典型问题速查在实际使用中我遇到了一些典型问题整理成速查表问题可能原因解决方法Vibe生成的方向不对描述太模糊用具体例子替代抽象词Plan给出的计划不合理需求描述不完整补充边界条件和技术约束Glue生成的代码跑不通两端信息不完整提供完整的接口文档和数据结构Spec生成的代码有偏差规格有歧义用伪代码或公式写死逻辑Smell给出的建议不适用业务场景特殊人工判断选择性采纳AI生成的代码风格不一致没有统一约束在提示词中明确代码风格对话太长导致AI遗忘上下文超限分阶段对话每阶段复述目标生成的代码有安全漏洞没有安全约束在Spec中增加安全要求8.2 独家避坑技巧与经验分享除了上面的速查表我还总结了一些独家技巧。技巧一用“角色扮演”提升AI表现。在提示词开头给AI一个角色比如“你是一个资深Python后端工程师”。这会让AI的输出更专业、更符合角色预期。技巧二用“反面例子”约束AI。告诉AI“不要做什么”有时候比“要做什么”更有效。比如“不要用全局变量”、“不要吞异常”、“不要写超过50行的函数”。技巧三用“分步确认”降低风险。对于复杂任务不要一次性让AI完成而是分步确认。每一步都验证后再继续避免方向性错误。技巧四用“代码审查”闭环。每次AI生成代码后都让AI自己审查一遍。这能发现不少低级错误比如变量未定义、类型不匹配、边界遗漏。技巧五用“版本对比”评估改进。当你要优化一段代码时让AI生成多个版本然后对比选择。这比只生成一个版本更容易找到最优解。8.3 从踩坑到熟练我的个人经验总结回顾我用AI编程的这两年从最初的“让AI写代码”到现在的“和AI一起写代码”最大的变化是心态。我不再把AI当成一个工具而是当成一个协作伙伴。我会和它讨论方案让它帮我审查代码甚至让它挑战我的设计决策。Vibe让我快速起步Plan让我结构清晰Glue让我集成无忧Spec让我正确性有保障Smell让我持续改进。这五种范式就像五种不同的对话方式让我在不同的场景下都能和AI高效协作。如果你刚开始用AI编程我建议从Vibe入手先感受一下和AI协作的节奏。然后逐步尝试Plan和Glue最后再挑战Spec和Smell。不要一开始就追求完美先跑起来再优化。最后分享一个小技巧每次用AI完成一个任务后花两分钟记录一下这次用的什么范式、提示词是什么、AI的输出质量如何、你做了哪些调整。坚持一个月你就会形成自己的AI编程方法论。这比看任何教程都管用。