1. 五种AI编程范式到底在解决什么问题

过去一年我几乎把市面上主流的AI编程工具轮了个遍，从最早的代码补全插件到后来的对话式编程助手，再到最近半年火起来的各种"氛围编程"玩法。踩了无数坑之后我发现，真正拉开效率差距的，不是工具本身有多强，而是你用什么样的范式去驱动它。同一个模型，有人用它十分钟搞定一个模块，有人折腾两小时还在改bug，差别就在范式选择上。

所谓AI编程范式，说白了就是"你和AI协作的固定套路"。就像做菜有爆炒、慢炖、凉拌，不同的菜用不同的手法，AI编程也一样。Vibe、Plan、Glue、Spec、Smell这五种范式，分别对应了五种截然不同的协作场景。Vibe是"跟着感觉走"，适合快速原型和探索性任务；Plan是"先谋后动"，适合复杂功能拆解；Glue是"当胶水用"，把AI当成连接各种API和库的中间层；Spec是"规格驱动"，用精确的接口定义约束AI输出；Smell则是"代码闻味"，让AI帮你识别坏味道和潜在缺陷。

这套分类不是拍脑袋想出来的。我在实际项目里反复验证过，当你面对一个任务时，先判断它属于哪一类，再选择对应的范式，效率能差出三到五倍。比如写一个一次性数据清洗脚本，用Plan范式就是自找麻烦，Vibe直接上反而最快；但如果是给团队写一个要长期维护的核心模块，Spec范式才是正解，Vibe出来的代码三个月后你自己都不敢改。

这篇文章我会把五种范式逐一拆开，讲清楚每种范式的适用场景、具体用法、真实案例，以及我在实操中总结的避坑经验。不管你是刚接触AI编程的新手，还是已经用了一段时间想提升效率的老手，都能从中找到可以直接抄作业的东西。核心关键词AI编程、Vibe、Plan、Glue、Spec、Smell会贯穿全文，我会尽量用大白话把每个概念讲透。

2. Vibe范式：跟着感觉走的快速原型利器

2.1 Vibe范式的核心逻辑与适用边界

Vibe coding这个词最早是从社区里传出来的，核心意思就是"别想太多，跟着感觉走"。你不需要写详细的规格说明，不需要画流程图，甚至不需要想清楚最终要什么，直接跟AI说"我想要一个能XXX的东西"，然后看它给你什么，再基于结果迭代。这种范式听起来很不专业，但实际用起来效率惊人，尤其是在探索性任务上。

我自己的经验是，Vibe范式最适合三类场景。第一类是一次性脚本，比如临时要处理一个CSV文件、批量重命名一堆图片、从某个页面抓点数据，这种代码写完就扔，不需要考虑可维护性。第二类是技术验证，你想试试某个库能不能用、某个方案可不可行，用Vibe快速搭个demo跑通就行。第三类是创意探索，比如你想做个可视化效果但不确定要什么风格，让AI先出几版看看，再挑一个方向深入。

但Vibe范式有明确的边界。任何需要长期维护、多人协作、或者有严格正确性要求的代码，都不适合用Vibe。我见过太多人用Vibe写了一个"看起来能跑"的功能，结果上线后各种边界情况崩溃，回头改的时候发现代码结构一团糟，还不如重写。所以用Vibe之前，先问自己一句：这段代码三个月后还有人看吗？如果有，换范式。

2.2 Vibe实操：从一句话到可运行代码

Vibe范式的操作流程非常简单，但有几个技巧能让效果翻倍。我拿一个真实案例来演示：我需要一个脚本，把某个目录下所有Markdown文件里的图片链接从相对路径改成图床的绝对路径。

第一步，直接描述需求，不要过度约束。我会说："写一个Python脚本，遍历指定目录下所有.md文件，把里面形如![](./images/xxx.png)的图片链接替换成![](https://mycdn.com/images/xxx.png)，注意要处理子目录，并且先备份原文件。"这段话里我给了目标、给了格式、给了注意事项，但没有规定用什么库、怎么组织代码，给AI留了发挥空间。

第二步，拿到代码后先跑一遍，不要急着读。Vibe的精髓就是快速验证，AI给的代码大概率能跑，但细节可能有问题。跑通之后再看输出对不对，不对就描述现象让它改。比如第一次跑完发现子目录没处理到，我就说"子目录里的文件没被处理，用os.walk重写一下遍历逻辑"，它立刻就改对了。

第三步，迭代到能用为止，不要追求完美。Vibe出来的代码通常不够优雅，但只要功能对了就行。我那个脚本最终版本也就三十来行，变量命名一般，没有异常处理，但它完成了任务，我用了两次就删了，没必要优化。

提示：Vibe范式下，给AI的反馈要具体到"现象"而不是"感觉"。说"子目录没处理到"比说"好像不太对"有效十倍。

2.3 Vibe范式的常见坑与规避技巧

用Vibe最容易踩的坑是范围蔓延。一开始只想写个小脚本，结果AI给你加了一堆用不上的功能，代码越来越复杂，最后你自己都看不懂了。我的做法是每次迭代只提一个改动点，改完验证完再提下一个，避免一次性让AI大改。

第二个坑是幻觉依赖。AI可能会用一个根本不存在的库或者错误的API，Vibe模式下你跑一下就知道，但如果你不跑直接信了，后面就等着报错吧。所以Vibe的铁律是：AI给的代码必须立刻运行验证，不要攒着一起测。

第三个坑是安全边界。Vibe出来的代码经常缺少输入校验、异常处理、资源释放这些东西，如果这段代码要处理用户输入或者操作重要文件，一定要手动补上。我一般会在Vibe完成后，专门让AI"检查这段代码有没有安全隐患和边界问题"，让它自己审一遍，通常能揪出几个漏网的。

3. Plan范式：复杂任务的先谋后动

3.1 什么任务值得先做计划

Plan范式和Vibe正好相反，它要求你在动手之前先把任务拆解清楚，让AI生成一个执行计划，你确认后再逐步实现。这种范式适合复杂度高、步骤多、依赖关系明确的任务。判断标准很简单：如果你自己都说不清楚第一步该干什么，那就该用Plan。

我通常在这几种情况下切换到Plan范式。一是从零搭建一个项目，比如要做一个完整的后端服务，涉及数据库设计、API定义、业务逻辑、部署配置，这种必须先把架构和模块划分想清楚。二是重构现有代码，重构最怕改着改着失控，先让AI分析现状、列出重构步骤、评估影响范围，再一步步执行，风险可控得多。三是跨多个文件的改动，比如要给项目加一个新功能，涉及路由、控制器、模型、测试好几个文件，Plan能帮你理清改动顺序，避免遗漏。

Plan范式的核心价值在于把思考成本前置。Vibe是边做边想，Plan是想清楚再做。对于简单任务，前置思考是浪费；对于复杂任务，前置思考能省下大量返工时间。我做过统计，一个涉及五个以上文件的功能开发，用Plan范式平均比直接Vibe快40%左右，因为返工次数少太多了。

3.2 Plan实操：如何让AI生成靠谱的执行计划

Plan范式的关键在第一步：让AI生成一个靠谱的计划。很多人直接说"帮我做个XXX"，AI给的计划往往很粗糙，执行到一半发现漏了关键步骤。我的做法是分两轮：第一轮让AI自由发挥列计划，第二轮我基于自己的经验补充和修正。

具体操作上，我会先给AI一个结构化的提示："我要实现XXX功能，技术栈是XXX，现有代码结构是XXX。请先不要写代码，而是列出实现这个功能需要哪些步骤，每个步骤涉及哪些文件，步骤之间的依赖关系是什么，以及可能的风险点。"这个提示的关键是明确要求它先别写代码，否则AI很容易直接开始输出实现，跳过计划环节。

拿到计划后，我会做三件事。第一，检查步骤是否完整，有没有遗漏的环节，比如忘了写测试、忘了改配置。第二，检查依赖顺序对不对，有些步骤必须串行，有些可以并行，顺序错了会卡住。第三，评估每步的粒度，太粗的步骤要拆细，太细的可以合并。修正完计划后，我再让AI按步骤逐个实现，每完成一步验证一步。

举个例子，我之前要给一个Flask项目加用户权限系统。AI第一版计划是"1.加用户模型 2.加登录接口 3.加权限装饰器 4.改现有接口"，看起来对但太粗。我补充成"1.设计用户表和角色表结构 2.写迁移脚本 3.实现用户模型和角色模型 4.实现注册登录接口 5.实现JWT签发和校验 6.写权限装饰器 7.给现有接口逐个加装饰器 8.补测试"，细化后执行起来顺畅多了。

3.3 Plan范式的执行节奏与验证节点

Plan范式执行时最容易犯的错是一口气让AI把所有步骤都做完。这样做的后果是，中间某一步出了问题，后面全崩，而且你很难定位是哪一步错的。正确的节奏是一步一验证，每完成一个步骤就跑一下、测一下，确认没问题再进入下一步。

我在实操中会把步骤分成三类：可独立验证的、需要依赖前序的、需要整体验证的。可独立验证的步骤，比如写一个工具函数，写完立刻单元测试。需要依赖前序的，比如接口实现依赖模型定义，那就等前序完成后再测。需要整体验证的，比如权限系统，得等所有步骤完成才能端到端测试。分清楚这三类，验证节奏就清晰了。

还有一个技巧是在每个关键节点让AI做一次自检。比如完成模型定义后，我会问"这个模型定义有没有考虑索引、有没有考虑软删除、字段类型合不合理"，让AI以审查者视角过一遍。这比我自己逐行看效率高，而且经常能发现我没想到的问题。

注意：Plan范式下，如果执行到一半发现计划有问题，不要硬着头皮往下做，停下来重新规划。我见过太多人因为"已经做了一半"而不愿意调整计划，最后做出一个四不像的东西。

4. Glue范式：把AI当成连接万物的胶水

4.1 Glue范式的本质：AI作为集成层

Glue范式的思路和前面两种都不一样。它不是让AI写业务逻辑，而是让AI充当连接层，把各种现成的API、库、服务粘合在一起。你告诉AI"我要调用A服务的接口拿到数据，处理后传给B服务，再把结果存到C数据库"，AI负责写这中间的胶水代码。业务逻辑本身可能很简单，难点在于各种接口的对接、数据格式的转换、错误处理。

这种范式在现在的开发场景里越来越常见，因为现代应用基本都是拼装出来的，很少从零造轮子。你可能要用到支付接口、地图接口、消息推送、对象存储、各种SaaS服务，每个都有自己的SDK和调用方式，写胶水代码又繁琐又容易出错，交给AI正合适。

Glue范式最适合的场景包括：第三方API集成、数据管道搭建、多服务编排、SDK封装。判断标准是：如果你的任务主要是"把已有的东西连起来"而不是"实现新的逻辑"，那就该用Glue。比如你要做一个功能，从某个API拉数据、清洗后存到数据库、再触发一个通知，这里面没有复杂的算法，全是连接和转换，Glue范式能帮你省下大量查文档的时间。

4.2 Glue实操：接口对接与数据转换的标准化流程

Glue范式的操作有一套标准流程，我把它总结成"三步走"：给接口信息、定数据契约、写胶水代码。

第一步，给AI足够的接口信息。这是Glue范式成败的关键，因为AI不知道你用的第三方服务长什么样。我会把相关的API文档片段、SDK的示例代码、请求响应的样例数据都贴给AI。比如要集成一个支付接口，我会贴出它的请求参数说明、返回字段说明、错误码列表，以及一段官方示例。信息给得越全，AI写出来的胶水代码越靠谱。

第二步，定义清楚数据契约。也就是明确"从A拿到什么格式的数据，要转换成什么格式给B"。我会用一段伪代码或者JSON样例来描述输入输出，比如"输入是{user_id, amount, currency}，输出是{order_id, status, pay_url}"。有了这个契约，AI就知道转换逻辑该怎么写，不会瞎猜。

第三步，让AI写代码并处理边界。胶水代码的难点不在主流程，而在边界情况：接口超时怎么办、返回格式不符合预期怎么办、部分成功怎么办。我会明确要求AI"处理网络异常、处理返回码非成功的情况、处理字段缺失的情况"，把这些都覆盖到。

举个真实案例，我之前要做一个功能：用户上传图片到对象存储，然后调用图像识别API打标签，再把标签存到数据库。涉及三个服务。我把对象存储的SDK用法、识别API的请求响应格式、数据库的表结构都给了AI，然后说"写一个函数，接收图片文件，完成上传、识别、存储三个步骤，每步都要有错误处理和日志"。AI一次就给出了可用的代码，我只改了几个字段名就上线了。

4.3 Glue范式的错误处理与重试策略

Glue范式里最容易被忽视但又最重要的是错误处理和重试。因为胶水代码连接的是外部服务，外部服务随时可能出问题，没有健壮的错误处理，整个流程就会因为一个偶发的网络抖动而崩溃。

我在实操中会要求AI实现三层防护。第一层是超时控制，每个外部调用都要设超时，不能无限等待。第二层是重试机制，对于可重试的错误（比如超时、限流），要自动重试，通常重试三次，每次间隔递增。第三层是降级处理，对于不可重试的错误（比如参数错误、权限不足），要记录日志并返回明确的错误信息，而不是抛一个看不懂的异常。

这里有个细节值得展开：重试不是无脑重试。有些操作是幂等的（比如查询），重试安全；有些操作是非幂等的（比如扣款），重试可能导致重复执行。对于非幂等操作，要么用幂等键，要么干脆不重试。我一般会让AI在写重试逻辑时明确标注"这个操作是否幂等"，不幂等的操作改成"记录失败、人工介入"。

还有一个经验是给胶水代码加可观测性。外部调用出问题时，如果没有日志，你根本不知道是哪个环节挂了。我会要求AI在每个关键步骤打日志，记录请求参数、响应结果、耗时、错误信息。这些日志在排查问题时价值巨大，尤其是涉及多个服务的链路，没有日志就是盲人摸象。

5. Spec范式：用规格约束AI的输出

5.1 Spec范式的核心：先定接口再写实现

Spec范式是我个人最推崇的一种，尤其适合团队协作和长期维护的项目。它的核心思想是先定义规格，再让AI按规格实现。规格包括接口签名、输入输出类型、边界条件、错误码等等，相当于给AI画了一个框，它只能在框里发挥。

这种范式的价值在于可控性。Vibe和Glue模式下，AI的输出有很大的随机性，同样的提示词两次运行结果可能不一样。Spec模式下，因为规格是精确的，AI的输出也被约束在规格范围内，结果稳定得多。而且规格本身就是最好的文档，后面维护的人看规格就知道这个模块该干什么，不用去读实现。

Spec范式特别适合这几种场景：核心业务逻辑，因为正确性要求高；公共库和工具函数，因为要被多处调用，接口必须稳定；多人协作的模块，因为需要明确的契约；需要长期维护的代码，因为规格能防止后续改动破坏原有行为。

5.2 Spec实操：从接口定义到实现验证

Spec范式的操作流程是写规格、生成实现、验证符合性三步。我用一个真实案例来演示：实现一个"分页查询用户列表"的函数。

第一步，写规格。我会用类似TypeScript接口定义的方式描述清楚：

// 输入 interface QueryUsersInput { page: number; // 页码，从1开始，最小1 pageSize: number; // 每页数量，1-100 keyword?: string; // 可选，按用户名模糊搜索 status?: 'active' | 'inactive'; // 可选，按状态筛选 } // 输出 interface QueryUsersOutput { total: number; // 总记录数 page: number; // 当前页码 pageSize: number; // 每页数量 items: User[]; // 用户列表 } // 错误 // INVALID_PAGE: page < 1 // INVALID_PAGE_SIZE: pageSize < 1 或 > 100

规格里我把输入输出的每个字段、类型、约束、错误码都写清楚了。然后我把这个规格给AI，说"按这个规格实现，用Python，数据库用SQLAlchemy"。

第二步，生成实现。AI拿到精确规格后，生成的代码质量明显高于模糊提示。它会自动处理参数校验、边界情况、错误抛出，因为这些都在规格里写明了。我拿到代码后基本只需要微调。

第三步，验证符合性。这一步很多人会跳过，但它是Spec范式的精髓。我会写一组测试用例，覆盖规格里的每个约束：page传0应该报错、pageSize传101应该报错、keyword为空应该返回全部、status筛选应该正确。跑一遍测试，全过才算完成。如果AI的实现有偏差，测试会立刻暴露出来。

5.3 Spec范式的版本管理与变更控制

Spec范式有一个额外的好处：规格可以版本化。当需求变更时，你先改规格，再让AI按新规格改实现，这样变更过程是可控的、可追溯的。我一般会把规格文件单独放在一个目录里，和实现代码分开管理，每次变更都记录在规格的注释里。

变更控制上有个原则：规格的变更要慎重，实现的变更可以灵活。因为规格是契约，改了规格意味着所有依赖这个模块的地方都可能受影响。所以改规格前，我会先评估影响范围，看看有哪些调用方，需不需要同步改。而实现层面的优化，比如换个算法、改个数据结构，只要不违反规格，随便改。

还有一个实操技巧是用规格做代码审查的基准。审查AI生成的代码时，我不看实现细节，先看它有没有违反规格。比如规格说pageSize最大100，实现里有没有校验；规格说错误码是INVALID_PAGE，实现里抛的是不是这个。以规格为基准审查，效率高而且不容易漏。

提示：Spec范式下，如果AI生成的实现和规格有冲突，永远以规格为准。不要因为"实现看起来更合理"就改规格，那会破坏契约的严肃性。

6. Smell范式：让AI帮你闻出代码坏味道

6.1 Smell范式的定位：AI作为代码审查者

Smell范式和前面四种都不一样，它不是用来"写"代码的，而是用来"审"代码的。核心思路是让AI扮演一个经验丰富的代码审查者，帮你找出代码里的坏味道、潜在bug、性能问题、安全隐患。这种范式在维护老项目、审查AI自己生成的代码、做代码重构前特别有用。

为什么需要Smell范式？因为AI写代码快，但写出来的代码质量参差不齐。Vibe和Glue模式下生成的代码，往往能跑但不够好，有各种隐藏问题。如果直接上线，后面就是无尽的bug。Smell范式相当于给AI的输出加了一道质检关卡，让另一个AI实例（或者同一个AI换个角色）来挑毛病。

Smell范式适合的场景包括：审查AI生成的代码，这是最常见的用法；接手老项目时快速摸底，让AI帮你找出最需要重构的地方；代码提交前的自检，在人工review之前先过一遍AI审查；学习代码规范，看AI指出的问题，慢慢就知道什么是好代码了。

6.2 Smell实操：系统化识别代码问题

Smell范式的操作关键是给AI明确的审查维度。如果你只说"帮我看看这段代码有没有问题"，AI会给一些泛泛的意见。但如果你说"从可读性、性能、安全、边界处理四个维度审查"，AI就会系统性地过一遍。

我常用的审查维度有这几个。可读性：命名是否清晰、函数是否过长、嵌套是否过深、注释是否到位。性能：有没有N+1查询、有没有不必要的循环、有没有可以缓存的计算、数据结构选择是否合理。安全：有没有SQL注入、有没有XSS、有没有硬编码密钥、输入校验是否充分。边界处理：空值、越界、并发、异常路径是否都考虑到了。可维护性：耦合度、重复代码、魔法数字、职责是否单一。

实操时我会把代码贴给AI，然后说"从以上五个维度审查这段代码，每个问题指出具体行号和修改建议，按严重程度排序"。AI会给出一个清单，我再逐条判断哪些要改、哪些可以接受。这个清单本身就是很好的重构todo list。

举个真实例子，我之前用Vibe写了一个数据处理脚本，跑起来没问题，但让AI审查后发现了好几个问题：一个循环里重复查询数据库（性能问题）、一个地方没处理空列表（边界问题）、变量名用了data1data2（可读性问题）。改完之后代码质量上了一个台阶。

6.3 Smell范式的审查清单与优先级判断

Smell范式用多了之后，我总结出一套审查清单，可以直接拿来用。下面这个表格是我常用的审查维度和对应的典型问题：

优先级判断上，我的原则是安全和正确性问题必须改，性能问题看场景，可维护性和可读性问题看代码寿命。如果这段代码是一次性的，可读性问题可以忽略；如果是要长期维护的，那命名混乱、重复代码这些也得改，否则后面维护成本会越来越高。

还有一个技巧是让AI给出修改后的代码，而不只是指出问题。这样你可以直接对比修改前后的差异，理解为什么这样改更好。我一般会说"针对你指出的高优先级问题，给出修改后的完整代码"，AI会重写一遍，我对比着看，学习效果很好。

注意：Smell范式下，AI指出的问题不一定都对，有些是误报。比如它可能说某个循环可以优化，但实际上那个循环的数据量很小，优化反而增加复杂度。所以审查结果要自己判断，不要无脑全改。

7. 五种范式的组合使用与选择决策

7.1 范式选择决策树

单独用某一种范式能解决大部分问题，但真实项目往往是多种范式混合使用。我总结了一个简单的决策流程，帮你快速判断当前任务该用哪种范式。

第一步，问自己"这个任务的输出需要长期维护吗"。如果不需要，比如一次性脚本、临时验证，直接用Vibe，别浪费时间做计划。如果需要，进入第二步。

第二步，问自己"这个任务主要是写新逻辑还是连现有服务"。如果是连现有服务，用Glue；如果是写新逻辑，进入第三步。

第三步，问自己"这个任务的正确性要求高吗，接口需要稳定吗"。如果高，用Spec；如果一般，进入第四步。

第四步，问自己"这个任务复杂吗，涉及多个文件或多个步骤吗"。如果复杂，用Plan；如果简单，回到Vibe。

第五步，不管用了哪种范式，完成后都用Smell审查一遍。这一步是通用的，相当于质检。

这个决策树不是绝对的，实际使用时可以灵活调整。比如一个复杂任务，可以先用Plan拆解，每个子任务根据性质分别用Vibe或Glue实现，关键模块用Spec约束，最后统一用Smell审查。这种组合用法在真实项目里很常见。

7.2 混合范式的实战案例

我拿一个真实项目来演示混合用法：给一个现有的Web应用加"用户行为分析"功能。这个功能要收集用户操作事件、存储到数据库、提供查询接口、做一个简单的可视化面板。

我的做法是这样的。首先用Plan范式做整体规划，让AI列出这个功能涉及哪些模块、每个模块的职责、模块间的依赖。规划结果是四个模块：事件收集SDK、事件存储服务、查询API、可视化面板。

然后逐个模块实现。事件收集SDK用Glue范式，因为它主要是封装上报接口、处理批量发送、失败重试这些连接性工作。事件存储服务用Spec范式，因为这是核心模块，接口要稳定，我定义了trackEvent、batchTrack、queryEvents三个接口的精确规格。查询API用Plan加Vibe，先规划接口设计，再快速实现。可视化面板用Vibe，因为是一次性的展示层，不需要太讲究。

每个模块完成后，用Smell范式审查一遍，重点看安全（事件数据可能含敏感信息）和性能（事件量大，查询要快）。最后整体联调，端到端测试。

这个项目如果全用Vibe，估计能快速搭出来但后面bug不断；全用Spec，前期定义规格的时间会很长。混合用法在效率和质量之间找到了平衡点，实际开发时间比预期少了大概三分之一。

7.3 范式切换的时机判断

混合使用的难点在于什么时候切换范式。我的经验是，当出现以下信号时，就该考虑切换了。

信号一：Vibe出来的代码开始改不动了。一开始改一个地方就行，后来改一个地方崩三个地方，说明代码复杂度已经超出Vibe能驾驭的范围，该切换到Plan或Spec了。

信号二：Glue代码的错误处理越来越复杂。一开始只有几个错误分支，后来变成十几个，说明这个集成逻辑已经足够复杂，值得用Spec把接口和错误码定义清楚。

信号三：Plan执行到一半发现计划完全不对。这时候不要硬撑，回到规划阶段重新来，或者降级到Vibe先探索一下再重新规划。

信号四：Smell审查发现的问题反复出现。如果同一个类型的坏味道在多个地方出现，说明不是个别代码的问题，而是整体设计有问题，该回到Spec或Plan层面重新设计。

范式切换不是失败，而是正常的开发节奏。我见过太多人因为"已经用了某种范式"而不愿意切换，结果在错误的路上越走越远。记住，范式是工具，不是信仰，该换就换。

8. 实操中的常见问题与排查技巧

8.1 五种范式的高频问题速查

用这五种范式时间长了，我整理了一份高频问题清单，基本都是踩过的坑。下面这个表格可以直接当速查表用：

这张表我放在手边，遇到问题先查表，大部分情况都能快速定位。

8.2 提示词工程的通用技巧

五种范式虽然用法不同，但有一些提示词技巧是通用的，掌握了能让所有范式的效果都提升一个档次。

第一个技巧是给角色。让AI扮演特定角色，输出质量会明显不同。比如Smell范式下说"你是一个有十年经验的代码审查专家"，AI的审查会更严格、更专业。Spec范式下说"你是一个注重接口稳定性的架构师"，AI会更谨慎地定义规格。

第二个技巧是给示例。AI很擅长模仿，给一个输入输出的例子，比描述一百句都管用。Glue范式下，给一段请求响应的样例数据，AI立刻就知道该怎么转换。Spec范式下，给一个已有的接口定义作为参考，AI生成的规格风格会保持一致。

第三个技巧是分步引导。复杂任务不要一次性全丢给AI，拆成多轮对话，每轮聚焦一个点。Plan范式下，先让它列计划，确认后再让它实现第一步，验证后再实现第二步。这种节奏虽然看起来慢，但返工少，总体更快。

第四个技巧是要求自检。让AI在给出结果后自己检查一遍，经常能发现它自己犯的错。比如"给出实现后，检查一下有没有违反规格的地方"，AI会重新审视一遍，揪出一些低级错误。

8.3 从踩坑到形成肌肉记忆

最后分享一点个人体会。这五种范式刚接触时会觉得要记的东西很多，但用多了之后会形成肌肉记忆，看到任务自动就知道该用哪种范式。我大概用了两三个月才到这个状态，前期也是各种混用、各种踩坑。

加速形成肌肉记忆的方法是刻意练习。找一些不同类型的任务，强迫自己用对应的范式去做，而不是习惯性地用最熟悉的那种。比如你习惯用Vibe，就专门找几个复杂任务逼自己用Plan；你习惯直接写代码，就专门找几个集成任务逼自己用Glue。练上十几二十次，范式选择就变成条件反射了。

还有一个建议是记录每次的范式选择。我会在项目笔记里简单记一下"这个任务用了什么范式、效果如何、下次遇到类似的该用什么"。积累一段时间后，这份记录就成了你自己的决策参考，比任何通用指南都管用。

AI编程这件事，工具在快速迭代，但范式的底层逻辑是相对稳定的。掌握了这五种范式，不管以后出什么新工具，你都能快速找到和它协作的最佳方式。这比追着学每一个新工具要有价值得多。