直接开门见山说吧。我最近一段时间花了大量精力在同一个问题上：现在 AI 编程工具这么强，为什么有人用起来像开挂，有人用起来却像在给 AI 打工？后来我发现，问题根本不出在工具选型上，而是出在“人和 AI 的协作方式”上。同样一个需求，你用聊天框直接把需求丢给 AI，和你先让它出一份实施计划再动手，最后拿到的东西完全是两个质量层级。这篇文章我就想系统梳理一下，我目前认为最值得掌握的五大 AI 编程范式，也就是项目标题里写的 Vibe、Plan、Glue、Spec、Smell。这五个词不是我发明的，是社区里慢慢沉淀出来的一套说法，分别代表了五种完全不同的人机协作模式。我会挨个拆解，讲清楚它们各自适合什么场景、有什么坑，以及我在实战中验证过的落地流程。如果你还在困惑“AI 写的代码能不能用于生产”“为什么 AI 生成的东西看着能跑但一改就崩”，那这篇文章大概率能给你一个比较清晰的答案。无论你是独立开发者、小团队的技术负责人，还是刚接触 AI 编程不久的新手，这五种范式里至少有一种能立刻改善你现在的开发方式。1. 五大范式全景拆解：它们到底在解决什么问题？先把定义放前面。这五大范式不是并列的五个工具，而是五种“如何与 AI 协作”的思维模式，每一种都对应着不同的输入方式、控制粒度和适用场景。Vibe 范式（氛围编程）是最早流行起来的形态。你打开对话框，用自然语言描述你想要的东西，比如“帮我写一个 Python 脚本，批量把 CSV 里面某几列提取出来转成 JSON”，AI 直接返回完整代码。它的核心特征是：需求描述即全部输入，AI 一次性完成从理解到生成的全部工作。这种模式上手门槛最低，但也是最容易翻车的一种，因为 AI 对模糊描述的补全能力虽然强，补全方向却未必是你真正想要的。Plan 范式（规划先行）把协作过程拆成了两个阶段。第一阶段，让 AI 输出一份实施方案，包含模块划分、技术选型、依赖关系、实施顺序。第二阶段，按方案逐步生成代码。这样做的好处非常直接：AI 在动手前先展现了它对问题的理解，你可以在它写第一行代码之前就纠偏，而不是等它写完一整套之后再推倒重来。Glue 范式（胶水编程）关注的是接口而非实现。它主张把整个系统拆成若干独立的模块或函数，让 AI 逐个生成，然后由你来编写“胶水层”，把这些模块按业务逻辑粘合起来。这套模式最早来自一些大型项目的实践，目的是控制 AI 生成内容带来的不可预测性，把风险隔离在单个模块内部。Spec 范式（规格驱动）是工程化最重的一种。AI 不直接面对自然语言需求，而是面对一份结构化的规格文档，里面包含功能定义、输入输出约束、边界条件、验收标准。AI 的角色从“脑补需求的生成器”变成了“照着蓝图施工的工程师”，人为干预程度大幅上升，但产出的稳定性和可维护性也成倍提升。Smell 范式（气味侦探）换了个角度——不再是让 AI 从零生成，而是让你把已有代码喂给 AI，让它像一个经验丰富的老工程师做 Code Review 一样，嗅出代码里的坏味道：重复逻辑、过长函数、资源泄漏隐患、边界条件遗漏、安全隐患等。这五个范式之间的关系不是替代，而是互补。Vibe 适合快速验证，Plan 适合中等复杂度任务，Glue 适合模块化系统，Spec 适合需要长期维护的核心模块，Smell 适合质量保障环节。后面几章我会逐个展开，每个都配上实操步骤、参数选择和避坑点。2. Vibe 范式实战：自然语言驱动的快速原型落地Vibe 这个词听起来很玄妙，但它本质上就是最朴素的人机交互：你描述，AI 实现。它核心解决的是“从想法到可运行代码”的效率问题，特别适合在需求尚未收敛、方案还在探索阶段时快速验证思路。2.1 Vibe 范式的适用边界与底层逻辑我自己的经验里，Vibe 范式最容易出成果的场景有三类：一次性脚本、数据清洗任务、原型验证。比如你手头有一批日志文件，需要把特定时间段的条目抽出来做统计；或者你有一个 Python 脚本要写，但你自己 20 分钟能写完，又懒得写——这类任务交给 Vibe 范式是最优解。它的底层逻辑也很简单：AI 在海量开源代码上训练过，对“常见任务的标准实现”有着极其稳定的掌握。你只要把任务用自然语言描述清楚，它生成出来的第一版代码往往就是可运行的。难点从来不是“AI 能不能写出来”，而是“你能不能把需求描述到让 AI 一次写准”。有人可能会问：那 Vibe 范式的缺点是什么？答案是可控性差。你拿到的代码像是一个陌生人替你写的项目——它能跑，但你不一定理解它为什么这么写；它的风格不一定符合你的项目规范；面对边界情况时的处理策略，AI 是猜的，而你只有运行时才会发现。所以 Vibe 范式产出的代码，我建议默认按“需要人工复核的物理隔离代码”来处理，而不是直接合并进主干。2.2 一次完整的数据清洗实战演示说个我最近实际做过的事。某个模拟项目里，我需要把一份几千行的销售记录 CSV 做清洗，剔除重复记录、补全缺失的金额字段，并输出按月份聚合的报表。这个任务用 Vibe 范式来做，前后大概十分钟搞定。我用了一个很基础的提示词：请帮我写一个 Python 脚本，读取当前目录下的 sales.csv 文件。 它包含以下字段：order_id，order_date，customer_name，product_id，amount。 要求： 1. 剔除 order_id 完全重复的记录，保留第一条。 2. 如果 amount 字段为空，将这个字段置为 0。 3. 增加一个 month 字段，格式形如 2025-03，根据 order_date 提取。 4. 按月份聚合，输出每个月的订单总数与总销售额。 5. 结果另存为 monthly_report.csv。 请使用 pandas 实现，并输出完整代码。AI 给出的实现非常标准：pandas 读取，drop_duplicates 去重，fillna 补零，pd.to_datetime 做时间格式解析，groupby 聚合，最后 to_csv 输出。这段代码我能直接跑，结果完全符合预期。但这个案例里真正的关键动作在提示词之外。我在描述需求时主动做了三件事：明确输入输出的文件名和字段名、限定了技术栈（pandas）、给出了输出格式的样子。这三件事直接决定了结果质量。如果你只是说“帮我清洗一下这个 CSV 文件”，AI 就需要猜字段含义、猜清洗规则、猜输出格式，猜得越多，偏得越远。2.3 提高 Vibe 生成质量的五个提示词要点把这段时间试出来的经验浓缩成五条：先说背景，再说任务。让 AI 知道它面对的是什么类型的数据、什么类型的系统，它生成出来的代码会更贴合上下文。明确输入输出的具体格式。文件路径、字段名、编码方式、输出格式。越具体越好。划清边界条件。缺失值怎么处理、重复值怎么去重、异常数据是报错还是忽略。这部分 AI 默认是会猜的，你不强制指定，它可能用最容易实现而不是最符合业务逻辑的方案。指定实现偏好。你可以让 AI 用 pandas、用纯 Python、用异步方式，也可以要求它写注释、写类型标注。这些偏好会影响代码的风格与可维护性。要求自检。在提示词结尾加上“请检查你的实现是否处理了所有边界情况”，经常能触发 AI 的自我修正能力，生成出比初版更健壮的代码。Vibe 范式最好的使用姿势是把“描述需求”本身当作一项核心能力来练习。描述得越清楚，AI 返工次数越少，你在验证和修正上花费的时间就越少。3. Plan 范式实战：从“直接写代码”到“先规划再编码”如果说 Vibe 是“让 AI 猜你想干什么”，那 Plan 范式就是“先让 AI 证明它理解了你想干什么，再让它动手”。这对于复杂度中等偏上、涉及多个模块协同的任务来说，是性价比最高的范式。3.1 为什么先规划能显著减少返工大部分 AI 编程返工的原因，不是 AI 写的代码有语法错误，而是 AI 理解的需求和你的真实需求存在偏差。这种偏差在 Vibe 模式下往往在代码写完、跑出结果之后才暴露。而 Plan 范式相当于给了你一个“需求对齐环节”：AI 输出计划，你审阅计划，发现偏差，当场纠偏，然后再进入编码阶段。举一个我实际遇到过的场景。某个模拟项目里需要实现一个“多平台文件同步工具”，支持本地目录与若干远程节点的增量同步。如果直接用 Vibe 范式，把需求往对话框一丢，AI 给出的代码大概率是一个伪同步——充其量是递归遍历目录、按修改时间比较、复制文件，所有网络层逻辑都被简化成假函数。运行起来功能“看起来对”，但拿到真实环境里根本不可用。Plan 范式下，我让 AI 先给出实施方案。它给出的方案包含了模块划分、关键技术决策和风险点：该同步工具建议拆分为四个模块： 1. 文件扫描模块：负责遍历目录，生成文件指纹列表（路径 + 修改时间 + 哈希值）。 2. 差异化比较模块：对比本地与远端指纹，生成增量操作列表（上传/下载/删除）。 3. 传输执行模块：基于操作列表执行实际文件传输，支持断点续传。 4. 状态上报模块：记录每次同步结果，异常时告警。 关键技术决策： - 指纹使用文件大小 + 修改时间 + SHA256 哈希，兼顾性能与准确性。 - 传输模块使用分块传输，单块 4MB，避免大文件长时间占用连接。 - 并发策略：文件级并发，最大并发数 4，防止对端压力过大。 风险点：大量小文件会导致指纹计算开销高，建议缓存上次扫描结果。这份计划本身比我最初的模糊想法要严谨得多。它让我注意到了断点续传和指纹缓存这两个我原本没考虑的细节，也暴露了它对需求的一个误判：它默认了所有文件都要做全量哈希，这对大文件来说性能是不可接受的。我随后追加了约束：只对大小或修改时间有变化的文件做哈希，这属于计划阶段就能完成的纠偏，不需要等代码写出来再返工。3.2 Plan 范式的执行流程与关键控制点我目前稳定使用的流程分五步：提交需求：用自然语言描述功能目标、约束条件、已知风险。要求计划：让 AI 输出实施方案，包含模块拆分、数据流、依赖关系、实施顺序。审阅纠偏：把计划和你自己的经验进行比对，重点审查技术选型是不是过度设计、模块边界是否合理、有没有遗漏关键非功能需求。分步实施：按计划让 AI 逐个模块生成代码，每生成一个模块就进行验证，而不是等全部生成完再统一看。回归联调：所有模块生成完毕后，整体跑一遍集成测试，验证模块间接口是否正确对接。这个流程里最重要的控制点在第 3 步。计划阶段是纠偏成本最低的时期，你要像对待自己写的设计文档一样对待 AI 生成的计划，逐条审视，不需要客套。发现不合理的方案直接要求替换，发现过度设计直接砍掉。实际操作中我经常在计划阶段砍掉 AI 想出来的冗余功能，比如加配置中心、加消息队列这类明显超出当前项目规模的设计。3.3 不同任务规模下 Plan 的粒度选择Plan 范式的粒度不是固定的，需要根据任务规模调整。小任务（比如实现一个工具函数），计划可以短到一句话：用一个函数，接收 A 返回 B，用某某算法。中任务（比如一个 API 服务模块），计划应该列出接口定义、数据模型、依赖项。大任务（比如一个完整应用），计划至少应该包含模块划分、数据库设计、部署方案、安全策略。我有一个习惯：任何预期代码量超过 200 行的任务，我都会先跑一遍 Plan 流程。这个过程通常只花 5 到 10 分钟，但能节省的返工时间往往是数倍以上。同时，Plan 阶段生成的计划文档也可以作为后续维护期的重要参考——它能告诉你 AI 当初为什么要做某类修改，这在代码 review 时非常有用。4. Glue 范式实战：让 AI 写零件，你来组装Glue 范式是我个人在工程实践中最推崇的一种协作模式。它的核心思想是：不要让 AI 独立完成一个整体系统，而是让它生成各个独立的功能模块，由你来编写集成逻辑把它们粘合起来。4.1 胶水代码的意义：控制风险边界为什么需要人为地加一层“胶水”？原因是 AI 生成内容的不可预测性会随着代码规模的增大而急剧放大。单个函数只有几十行，AI 完全可控；但一旦你让 AI 生成一个包含十几个模块、互相调用的完整系统，模块之间的接口约定就可能出现偏差——一个模块里的函数名、参数顺序、返回值格式，与另一个模块里假设的不一致，最后跑起来直接抛错。Glue 范式通过物理隔离来控制这个风险。你让 AI 生成的是独立的、可独立测试的模块，每个模块的输入输出都由你预先定义好。模块内部无论怎么实现，只要满足契约就行。模块之间的逻辑由你通过胶水代码串联，你可以控制调用顺序、异常处理策略、数据转换规则。这样一来，AI 出错的影响范围就被限制在了单个模块内部。用一句通俗的话说：AI 只负责写零件，每个零件干什么、有什么规格你说了算；装不装得上、装在哪里，由你来决定。这就像你请了个技术很熟练但不太懂你家里布局的水电工，让他帮你把各个线路做好，但总闸怎么拉、线路怎么走，你必须自己把关。4.2 一个系统集成场景的完整拆解说一个我实际做过的模拟项目：一个跨平台数据采集与上报系统。需求是从多个异构数据源采集数据，做规格化处理后上报到统一端点。如果用 Vibe 范式直接把所有需求丢给 AI 生成，那大概率是灾难——数据源格式各不相同，每个源的解析逻辑都不同，一旦某个源格式发生变化，整个代码都受影响。Glue 范式的做法是分四步走。第一步，定义模块边界。我给 AI 定义了四个独立函数，每个承担一个职责：函数1: fetch_raw_data(source_config) -> raw_data 从指定数据源读取原始数据，返回格式不限。 函数2: normalize_record(raw_data, schema) -> normalized_data 将原始数据转换为符合 schema 的规格化数据。 函数3: validate_record(normalized_data) -> (is_valid, errors) 校验规格化数据是否合法，返回布尔值与错误列表。 函数4: upload_batch(records) -> upload_result 将记录批量上报到目标端点。第二步，逐个让 AI 实现这些函数。每个函数单次生成，单独测试，可以保证每个零件的正确性。最关键的是每个函数里都包含数据源或格式相关的信息，这个信息由我在函数描述中显式传入，而不是隐藏在一些隐式的全局约定里。第三步，编写胶水代码。这部分是我手写的，大概逻辑如下：def run_sync_once(source_config, schema): raw_data = fetch_raw_data(source_config) normalized = normalize_record(raw_data, schema) valid, errors = validate_record(normalized) if not valid: log_errors(errors) return upload_batch(normalized)这段胶水代码虽然只有几行，但它决定了整个流程的顺序：先取数、再转换、再校验、最后上报。任何一步失败，流程直接终止并记录错误。这个编排逻辑是业务规则的一部分，不应该让 AI 自动生成。第四步，集成测试。把 AI 生成的四个独立模块与我手写的胶水代码拼起来，用测试数据跑一遍全流程。因为每个模块都已经验证过，集成阶段出现的问题基本只会出在接口对接上，排查范围大大缩小。4.3 单元接口设计的三条核心原则Glue 范式对接口设计的要求比较高，我总结出三条原则：接口要窄。每个函数只做一件事，参数越少越好。一个函数超过三个参数就说明边界拆分有问题。数据结构要明确。跨模块传递的数据用明确的结构（dataclass、TypedDict、Pydantic 模型），尽量避免用裸字典。因为裸字典的键名一旦写错，只有运行时才能发现，而明确结构可以在静态检查阶段就暴露问题。错误处理要外置。模块内部不要吞异常，让异常向上抛，由胶水层统一处理。这样每个模块的职责更纯粹，全局错误策略更可控。Glue 范式的代价是你需要花时间设计接口和编写胶水代码，这部分看起来不够“AI 化”，但在项目中后期会非常值。它让整个系统保持了你可理解的形态，而不是一个黑盒。对于任何需要持续迭代、后续要加需求改逻辑的项目，我强烈建议优先用 Glue。5. Spec 范式实战：用规格说明驱动稳定的模块交付Spec 范式是工程化程度最高的范式，它把 AI 当作一支可以反复调用的实施团队，而你自己担任架构师兼产品经理。你输出的不是零散的需求描述，而是一份完整的规格说明书，AI 的职责就是照着规格实现。5.1 从需求到规格的转化方法写规格文档的第一步是确定需求的边界。你需要明确：这个模块给谁用、输入是什么、输出是什么、在什么环境下运行、性能要求是什么。这不是随意写的，它需要你对自己要做的功能有清晰的理解——这正是 Spec 范式对开发者能力要求高于其他范式的地方。第二步是分解约束。把从接口设计、异常处理、数据校验、日志输出等方方面面全部写进规格文档。规格越具体，AI 的自由裁量空间越小，产出越稳定。这里有一个对比可以说明问题：Vibe 模式下你说“做一个用户注册接口”，AI 可能给出四种不同的实现：有的用邮箱注册，有的用手机号，有的默认用户名就行。Spec 模式下你写的是“用户注册接口，携带参数 user_name（字符串，3-20 个字符）、email（字符串，邮箱格式）；email 已存在时返回 409 + 错误码 EMAIL_EXISTS；注册成功后自动生成默认昵称并返回用户 ID 与 token”。AI 看到这种规格，产出的代码与你的预期几乎不会偏差。5.2 规格文档的标准结构与必备要素我在实践中通常把规格文档分成六块：背景与目标：模块要解决什么问题。功能列表：每个功能的编号、描述、优先级。接口定义：输入、输出、错误码、异常处理规则。数据结构定义：字段、类型、必填性、约束。非功能需求：性能指标、并发要求、兼容性要求。验收标准：如何判断这个模块是否合格。验收标准这一块很多人会忽略，但它恰恰是 Spec 范式的精髓。没有验收标准的规格，本质上只是换了种方式说需求。有没有验收标准，直接决定了 AI 是“做完就行”还是“做对才行”。5.3 用规格驱动一个用户认证模块的完整示例下面这个示例我基于一个实际做过的模拟项目整理而来。需求是实现一个轻量级的用户认证服务，包含注册、登录、令牌刷新三个接口。我没有直接把这些需求丢给 AI 写代码，而是先写了一份规格摘要：模块：用户认证服务 1. 注册接口 POST /api/register 请求：{ "username": string(3-20), "password": string(6-32, 必须包含数字和字母) } 成功（201）：{ "user_id": int, "token": string(32) } 失败（400）：密码不符合规则时返回错误码 WEAK_PASSWORD 失败（409）：用户名已存在时返回错误码 USERNAME_TAKEN 实现要求：密码使用 bcrypt 哈希保存，禁止明文存储。 2. 登录接口 POST /api/login 请求：{ "username": string, "password": string } 成功（200）：{ "token": string(32), "expires_in": 3600 } 失败（401）：用户名或密码错误时返回统一错误码 INVALID_CREDENTIALS 3. 刷新接口 POST /api/refresh 请求：{ "refresh_token": string(64) } 成功（200）：{ "token": string(32), "expires_in": 3600 } 失败（401）：refresh_token 无效或过期时返回 TOKEN_EXPIRED 4. 数据存储：使用 SQLite，表名为 users，结构由你设计，但必须包含 user_id, username, password_hash, refresh_token, created_at。 5. 非功能要求：所有接口需要记录访问日志；密码字段不得出现在日志中。 6. 验收标准：上述三个接口在本地可启动，用 curl 测试可得到预期结果。这份规格传达的信息量远超一句“帮我写个登录注册”。它把字段约束、错误码、哈希方案、日志规则、验收方式全部具象化了。然后我把规格发给 AI，让它完整实现。它的输出非常符合预期：FastAPI 应用，bcrypt 哈希，JWT 令牌，SQLite 存储，日志过滤了密码字段。过程中我几乎没有介入，全程只做了两轮审阅：第一轮检查接口实现是否严格遵守错误码命名，第二轮检查密码字段是否真的没有出现在日志记录里。Spec 范式最大的好处是结果可预期。同一份规格发十次，产出的代码虽然内部实现可能有变化，但接口行为一定是稳定的。这让它非常适合核心业务模块的开发——这些模块的特点是：需求明确、变更频率低、对稳定性要求极高。Spec 范式可以保证在这些模块上投入的每一分 AI 算力都在产出正确的功能，而不是在试探需求。5.4 Spec 范式的代价与适用范围当然 Spec 范式也有明显的代价：前期写规格的时间成本高。一个中等模块的规格文档，我通常要写 20-40 分钟，比直接写代码还慢。所以我不建议所有代码都走 Spec，它最适用的场景是“值得被稳定维护的模块”，比如用户认证、支付、权限控制、核心业务逻辑。而为了快速验证而写的脚本、一次性工具、UI 原型的探究——这些统统不适合 Spec，用 Vibe 或 Plan 效率更高。还有一个容易踩的坑：规格文档写得过于追求面面俱到，会导致 AI 在实现时束手束脚。比如你规定了数据库表结构每一个字段名，又规定了缓存策略，又规定了日志格式，最后 AI 被各种约束绑死了，反倒会花费大量不必要的思考。规格制定者的核心能力应该是“知道哪些需要约束、哪些应该放权”。把关键接口、数据安全、验收标准锁死，把实现路径留给 AI，这才是合理的规格设计。6. Smell 范式实战：让 AI 成为代码评审的第一道关卡前四种范式都聚焦在“怎么让 AI 写出更好的代码”，Smell 范式换了个方向：让 AI 帮你审查已经存在的代码，找出不合理之处。它对应的是传统团队里 Code Review 环节，AI 在这里担当的是一个不会累的评审者。6.1 AI 代码评审与传统 Code Review 的差异传统 Code Review 受限于评审者的时间和精力，很难每次做到全面覆盖——尤其是那些不产生明显 bug 但会让后续维护变困难的问题，比如重复逻辑、函数过长、循环嵌套太深、命名不清晰、缺少边界处理。AI 在这方面有天然优势：它能一次处理大量代码，而且不会因为“看了太多遍”而失去专注力。但 AI 评审有自己的局限——它不掌握项目的完整上下文。一个函数写得复杂，不一定是坏的，可能是因为业务逻辑本身就复杂；一段看似重复的代码，可能是为了保证两个模块的独立部署。所以我在使用 Smell 范式时，始终强调的是它只能作为第一道关卡，不能代替人工评审。6.2 一次有效的 AI 评审是怎么做的我有一套固定的提问模板，实际效果还不错。例如我对一段 Python 模块发起评审：以下是某项目中负责订单状态流转的模块核心代码。 请从以下几个维度进行评审： 1. 是否有重复逻辑可提取？ 2. 是否有可以抽离为独立函数的长段落？ 3. 是否有边界条件未处理？ 4. 是否有资源未释放的风险？ 5. 变量命名与函数职责是否匹配？ 请逐条输出发现的问题，每条问题请指出具体行号或代码段，并给出修改建议。AI 在收到这种含“具体代码 + 明确的评审维度”的请求后，产出的反馈质量非常稳定。我实际遇到的几类问题，它几乎都指出来了：循环内重复执行数据库查询（N+1 查询风险）、异常分支里没有回滚部分已更新的状态、一个工具函数里混入了与业务相关的硬编码配置。6.3 我踩过的一个高频评审误区很多人在让 AI 评审时，直接把 API 文档里随便扒出来的代码片段贴进去，不给任何上下文。这会导致一个典型问题：AI 基于它自己的经验指出一堆问题，但实际上大部分不适用。比如它会说“这个函数最好拆成三个小函数”，可实际情况是这段代码是一个极致性能敏感的热点函数，拆分得不偿失。正确做法是：把代码所在模块的职责说明文字加在代码前面。比如“这是一个定时任务模块，每 5 分钟运行一次，负责从某队列拉取数据并写入数据库，并发场景下可能出现重复写入”。有了这层上下文，AI 的评审建议会精准很多，它会把“重复写入”当成关键点去查，而不是泛泛地建议拆函数。这是一个非常值得重视的细节。6.4 Smell 范式与传统工具链的联动策略Smell 范式与传统静态检查工具（如 linter、SonarQube 一类）不冲突，而是互补。静态工具擅长查语法规范、潜在 bug 模式，AI 更擅长查语义层面的问题，比如模块职责混乱、错误处理缺失、命名与逻辑意图不符。我在项目里通常的组合是：静态工具随代码提交自动运行，AI 评审放在大功能合并之前的把关阶段，两者叠加能覆盖绝大部分质量问题。另外，Smell 范式完全可以移植到需求阶段。你可以把接口文档或设计草案扔给 AI，让它站在“实现者”角度找问题：字段有没有缺失、状态流转有没有死路、鉴权漏没漏。这类评审比代码评审更早发现问题的价值更高，因为改文档的成本远低于改代码。7. 范式选型对比与组合实战建议这五种范式各有各的适用范围。为了让大家一眼看清差异，我按自己实战中的体感整理了一个选型表格。维度VibePlanGlueSpecSmell核心输入自然语言需求需求 + 实施计划模块接口定义结构化规格文档已有代码 + 评审维度开发者控制力最低中等较高最高单向（只审不改）产物可维护性低中等高最高提升已有代码质量典型适用任务脚本、原型、一次性任务中等复杂度模块多模块系统核心稳定业务模块合并前把关上手难度低中等中等偏上高低主要风险需求理解偏差计划偏离实际接口设计不合理规格编写耗时误报率高我个人的建议是，这五个范式不要割裂着用。一个典型的中等复杂度项目，全流程可能是这样的：早期探索阶段：用 Vibe 快速验证技术可行性，确认关键方案。确定要做之后：用 Plan 生成整体实施计划，明确模块划分与顺序。正式开发阶段：核心模块用 Spec 写出规格再让 AI 实现，普通模块用 Glue 范式做零件组装。开发收尾阶段：用 Smell 范式对全部代码做一次综合评审，修正发现的问题。这套组合拳我实践下来，整体效率比单一范式至少高一倍。关键原因在于每个环节都选择了最适合的协作模式，而不是一味追求“让 AI 多干活”——这恰恰是很多人的误区。8. 常见问题与避坑经验汇总最后把我这段时间踩过的一些高频坑集中列一下，算是给前面内容做个实践侧的补充。8.1 AI 生成代码难以理解的应对策略很多人反馈 AI 生成的代码风格与自己习惯不一致，后续维护困难。我的应对方式：在生成之前，明确指定代码风格和结构要求。例如“使用类型标注”“每个函数必须带 docstring”“在关键逻辑处补充注释”“禁止使用第三方库，用标准库实现”等约束。这样产出的代码能保持较高的可读性。如果乱入已经发生了，那么用 Smell 范式让 AI 自己解释并重写一遍，也是一种有效的补救方式。8.2 AI 产出错误结论的判断方法AI 在编程场景下其实很少出现“明显错误”，更多是“看起来对但悄悄绕开了你真正想要的逻辑”。比如你让它实现“同步时跳过临时文件”，结果它只在文件名匹配.tmp后缀的层面做，但你的临时文件实际是隐藏目录里的文件——逻辑虽然有，但没覆盖你的实际场景。要避免这种情况，只能在需求描述阶段就把这些例外规则显式写明白。8.3 把上下文管理当作核心技能不管哪种范式，上下文管理都是绕不开的课题。AI 的上下文窗口有限，长项目里早期需求描述可能丢失。我的建议有三条：一是重要需求写成独立文件，而不是只存在于对话框里；二是每次让 AI 干活，先给它一个“项目导读”式的简短说明，避免它根据残缺上下文脑补；三是关键设计决定，主动在对话中复述确认，确保双方理解一致。8.4 什么时候应该放弃 AI 生成也不是所有代码都适合 AI 写。我自己的经验是，涉及高精度逻辑（比如复杂的日期时间处理、加密协议实现）、强实时性能要求的热点代码、以及与现有系统有大量隐式耦合的模块，这些场景建议优先人写。AI 在这些领域错误率不低，而错误代价往往很高。8.5 复合协作模式的最佳实践最后想强调的是，上述各种范式不是固定套路，而是可以互相组合的积木。就拿我最近负责的一个内部工具项目来说，我采用的是“Plan 规整大方向 + Spec 锁死核心模块 + Glue 串联扩展功能 + Smell 做最终把关”，Vibe 只在写辅助脚本时出现。这种组合方式能最大化发挥每种范式在不同环节的优势。根据我个人的体会，AI 编程范式的选择本质上不是工具问题，而是管理问题：你在管理一个能力很强但极其需要明确指令的协作者。你给它的自由度越高，它的想象力发挥余地就越大，但出错概率也随之上升。你给它的约束越多，它的产出就越稳定，但你的前期投入也越大。找到这个平衡点，比学习任何一种单一工具本身更重要。如果你刚入门，我给的建议是从 Vibe 开始练手，这是成本最低的切入方式；当你在生成结果中开始频繁发现“差一点就对了但总差点意思”的问题时，就是切换到 Plan 与 Glue 的时候了；等到你负责核心模块的稳定交付时，Spec 会是你的主战场。最后别把 Smell 落下，它是一种可以在任何阶段帮助你提升已有代码质量的手段。这五种范式一路用下来，AI 生产力在你的项目中才能真正兑现成交付质量。
直接开门见山说吧。我最近一段时间花了大量精力在同一个问题上：现在 AI 编程工具这么强，为什么有人用起来像开挂，有人用起来却像在给 AI 打工？后来我发现，问题根本不出在工具选型上，而是出在“人和 AI 的协作方式”上。同样一个需求，你用聊天框直接把需求丢给 AI，和你先让它出一份实施计划再动手，最后拿到的东西完全是两个质量层级。这篇文章我就想系统梳理一下，我目前认为最值得掌握的五大 AI 编程范式，也就是项目标题里写的 Vibe、Plan、Glue、Spec、Smell。这五个词不是我发明的，是社区里慢慢沉淀出来的一套说法，分别代表了五种完全不同的人机协作模式。我会挨个拆解，讲清楚它们各自适合什么场景、有什么坑，以及我在实战中验证过的落地流程。如果你还在困惑“AI 写的代码能不能用于生产”“为什么 AI 生成的东西看着能跑但一改就崩”，那这篇文章大概率能给你一个比较清晰的答案。无论你是独立开发者、小团队的技术负责人，还是刚接触 AI 编程不久的新手，这五种范式里至少有一种能立刻改善你现在的开发方式。1. 五大范式全景拆解：它们到底在解决什么问题？先把定义放前面。这五大范式不是并列的五个工具，而是五种“如何与 AI 协作”的思维模式，每一种都对应着不同的输入方式、控制粒度和适用场景。Vibe 范式（氛围编程）是最早流行起来的形态。你打开对话框，用自然语言描述你想要的东西，比如“帮我写一个 Python 脚本，批量把 CSV 里面某几列提取出来转成 JSON”，AI 直接返回完整代码。它的核心特征是：需求描述即全部输入，AI 一次性完成从理解到生成的全部工作。这种模式上手门槛最低，但也是最容易翻车的一种，因为 AI 对模糊描述的补全能力虽然强，补全方向却未必是你真正想要的。Plan 范式（规划先行）把协作过程拆成了两个阶段。第一阶段，让 AI 输出一份实施方案，包含模块划分、技术选型、依赖关系、实施顺序。第二阶段，按方案逐步生成代码。这样做的好处非常直接：AI 在动手前先展现了它对问题的理解，你可以在它写第一行代码之前就纠偏，而不是等它写完一整套之后再推倒重来。Glue 范式（胶水编程）关注的是接口而非实现。它主张把整个系统拆成若干独立的模块或函数，让 AI 逐个生成，然后由你来编写“胶水层”，把这些模块按业务逻辑粘合起来。这套模式最早来自一些大型项目的实践，目的是控制 AI 生成内容带来的不可预测性，把风险隔离在单个模块内部。Spec 范式（规格驱动）是工程化最重的一种。AI 不直接面对自然语言需求，而是面对一份结构化的规格文档，里面包含功能定义、输入输出约束、边界条件、验收标准。AI 的角色从“脑补需求的生成器”变成了“照着蓝图施工的工程师”，人为干预程度大幅上升，但产出的稳定性和可维护性也成倍提升。Smell 范式（气味侦探）换了个角度——不再是让 AI 从零生成，而是让你把已有代码喂给 AI，让它像一个经验丰富的老工程师做 Code Review 一样，嗅出代码里的坏味道：重复逻辑、过长函数、资源泄漏隐患、边界条件遗漏、安全隐患等。这五个范式之间的关系不是替代，而是互补。Vibe 适合快速验证，Plan 适合中等复杂度任务，Glue 适合模块化系统，Spec 适合需要长期维护的核心模块，Smell 适合质量保障环节。后面几章我会逐个展开，每个都配上实操步骤、参数选择和避坑点。2. Vibe 范式实战：自然语言驱动的快速原型落地Vibe 这个词听起来很玄妙，但它本质上就是最朴素的人机交互：你描述，AI 实现。它核心解决的是“从想法到可运行代码”的效率问题，特别适合在需求尚未收敛、方案还在探索阶段时快速验证思路。2.1 Vibe 范式的适用边界与底层逻辑我自己的经验里，Vibe 范式最容易出成果的场景有三类：一次性脚本、数据清洗任务、原型验证。比如你手头有一批日志文件，需要把特定时间段的条目抽出来做统计；或者你有一个 Python 脚本要写，但你自己 20 分钟能写完，又懒得写——这类任务交给 Vibe 范式是最优解。它的底层逻辑也很简单：AI 在海量开源代码上训练过，对“常见任务的标准实现”有着极其稳定的掌握。你只要把任务用自然语言描述清楚，它生成出来的第一版代码往往就是可运行的。难点从来不是“AI 能不能写出来”，而是“你能不能把需求描述到让 AI 一次写准”。有人可能会问：那 Vibe 范式的缺点是什么？答案是可控性差。你拿到的代码像是一个陌生人替你写的项目——它能跑，但你不一定理解它为什么这么写；它的风格不一定符合你的项目规范；面对边界情况时的处理策略，AI 是猜的，而你只有运行时才会发现。所以 Vibe 范式产出的代码，我建议默认按“需要人工复核的物理隔离代码”来处理，而不是直接合并进主干。2.2 一次完整的数据清洗实战演示说个我最近实际做过的事。某个模拟项目里，我需要把一份几千行的销售记录 CSV 做清洗，剔除重复记录、补全缺失的金额字段，并输出按月份聚合的报表。这个任务用 Vibe 范式来做，前后大概十分钟搞定。我用了一个很基础的提示词：请帮我写一个 Python 脚本，读取当前目录下的 sales.csv 文件。 它包含以下字段：order_id，order_date，customer_name，product_id，amount。 要求： 1. 剔除 order_id 完全重复的记录，保留第一条。 2. 如果 amount 字段为空，将这个字段置为 0。 3. 增加一个 month 字段，格式形如 2025-03，根据 order_date 提取。 4. 按月份聚合，输出每个月的订单总数与总销售额。 5. 结果另存为 monthly_report.csv。 请使用 pandas 实现，并输出完整代码。AI 给出的实现非常标准：pandas 读取，drop_duplicates 去重，fillna 补零，pd.to_datetime 做时间格式解析，groupby 聚合，最后 to_csv 输出。这段代码我能直接跑，结果完全符合预期。但这个案例里真正的关键动作在提示词之外。我在描述需求时主动做了三件事：明确输入输出的文件名和字段名、限定了技术栈（pandas）、给出了输出格式的样子。这三件事直接决定了结果质量。如果你只是说“帮我清洗一下这个 CSV 文件”，AI 就需要猜字段含义、猜清洗规则、猜输出格式，猜得越多，偏得越远。2.3 提高 Vibe 生成质量的五个提示词要点把这段时间试出来的经验浓缩成五条：先说背景，再说任务。让 AI 知道它面对的是什么类型的数据、什么类型的系统，它生成出来的代码会更贴合上下文。明确输入输出的具体格式。文件路径、字段名、编码方式、输出格式。越具体越好。划清边界条件。缺失值怎么处理、重复值怎么去重、异常数据是报错还是忽略。这部分 AI 默认是会猜的，你不强制指定，它可能用最容易实现而不是最符合业务逻辑的方案。指定实现偏好。你可以让 AI 用 pandas、用纯 Python、用异步方式，也可以要求它写注释、写类型标注。这些偏好会影响代码的风格与可维护性。要求自检。在提示词结尾加上“请检查你的实现是否处理了所有边界情况”，经常能触发 AI 的自我修正能力，生成出比初版更健壮的代码。Vibe 范式最好的使用姿势是把“描述需求”本身当作一项核心能力来练习。描述得越清楚，AI 返工次数越少，你在验证和修正上花费的时间就越少。3. Plan 范式实战：从“直接写代码”到“先规划再编码”如果说 Vibe 是“让 AI 猜你想干什么”，那 Plan 范式就是“先让 AI 证明它理解了你想干什么，再让它动手”。这对于复杂度中等偏上、涉及多个模块协同的任务来说，是性价比最高的范式。3.1 为什么先规划能显著减少返工大部分 AI 编程返工的原因，不是 AI 写的代码有语法错误，而是 AI 理解的需求和你的真实需求存在偏差。这种偏差在 Vibe 模式下往往在代码写完、跑出结果之后才暴露。而 Plan 范式相当于给了你一个“需求对齐环节”：AI 输出计划，你审阅计划，发现偏差，当场纠偏，然后再进入编码阶段。举一个我实际遇到过的场景。某个模拟项目里需要实现一个“多平台文件同步工具”，支持本地目录与若干远程节点的增量同步。如果直接用 Vibe 范式，把需求往对话框一丢，AI 给出的代码大概率是一个伪同步——充其量是递归遍历目录、按修改时间比较、复制文件，所有网络层逻辑都被简化成假函数。运行起来功能“看起来对”，但拿到真实环境里根本不可用。Plan 范式下，我让 AI 先给出实施方案。它给出的方案包含了模块划分、关键技术决策和风险点：该同步工具建议拆分为四个模块： 1. 文件扫描模块：负责遍历目录，生成文件指纹列表（路径 + 修改时间 + 哈希值）。 2. 差异化比较模块：对比本地与远端指纹，生成增量操作列表（上传/下载/删除）。 3. 传输执行模块：基于操作列表执行实际文件传输，支持断点续传。 4. 状态上报模块：记录每次同步结果，异常时告警。 关键技术决策： - 指纹使用文件大小 + 修改时间 + SHA256 哈希，兼顾性能与准确性。 - 传输模块使用分块传输，单块 4MB，避免大文件长时间占用连接。 - 并发策略：文件级并发，最大并发数 4，防止对端压力过大。 风险点：大量小文件会导致指纹计算开销高，建议缓存上次扫描结果。这份计划本身比我最初的模糊想法要严谨得多。它让我注意到了断点续传和指纹缓存这两个我原本没考虑的细节，也暴露了它对需求的一个误判：它默认了所有文件都要做全量哈希，这对大文件来说性能是不可接受的。我随后追加了约束：只对大小或修改时间有变化的文件做哈希，这属于计划阶段就能完成的纠偏，不需要等代码写出来再返工。3.2 Plan 范式的执行流程与关键控制点我目前稳定使用的流程分五步：提交需求：用自然语言描述功能目标、约束条件、已知风险。要求计划：让 AI 输出实施方案，包含模块拆分、数据流、依赖关系、实施顺序。审阅纠偏：把计划和你自己的经验进行比对，重点审查技术选型是不是过度设计、模块边界是否合理、有没有遗漏关键非功能需求。分步实施：按计划让 AI 逐个模块生成代码，每生成一个模块就进行验证，而不是等全部生成完再统一看。回归联调：所有模块生成完毕后，整体跑一遍集成测试，验证模块间接口是否正确对接。这个流程里最重要的控制点在第 3 步。计划阶段是纠偏成本最低的时期，你要像对待自己写的设计文档一样对待 AI 生成的计划，逐条审视，不需要客套。发现不合理的方案直接要求替换，发现过度设计直接砍掉。实际操作中我经常在计划阶段砍掉 AI 想出来的冗余功能，比如加配置中心、加消息队列这类明显超出当前项目规模的设计。3.3 不同任务规模下 Plan 的粒度选择Plan 范式的粒度不是固定的，需要根据任务规模调整。小任务（比如实现一个工具函数），计划可以短到一句话：用一个函数，接收 A 返回 B，用某某算法。中任务（比如一个 API 服务模块），计划应该列出接口定义、数据模型、依赖项。大任务（比如一个完整应用），计划至少应该包含模块划分、数据库设计、部署方案、安全策略。我有一个习惯：任何预期代码量超过 200 行的任务，我都会先跑一遍 Plan 流程。这个过程通常只花 5 到 10 分钟，但能节省的返工时间往往是数倍以上。同时，Plan 阶段生成的计划文档也可以作为后续维护期的重要参考——它能告诉你 AI 当初为什么要做某类修改，这在代码 review 时非常有用。4. Glue 范式实战：让 AI 写零件，你来组装Glue 范式是我个人在工程实践中最推崇的一种协作模式。它的核心思想是：不要让 AI 独立完成一个整体系统，而是让它生成各个独立的功能模块，由你来编写集成逻辑把它们粘合起来。4.1 胶水代码的意义：控制风险边界为什么需要人为地加一层“胶水”？原因是 AI 生成内容的不可预测性会随着代码规模的增大而急剧放大。单个函数只有几十行，AI 完全可控；但一旦你让 AI 生成一个包含十几个模块、互相调用的完整系统，模块之间的接口约定就可能出现偏差——一个模块里的函数名、参数顺序、返回值格式，与另一个模块里假设的不一致，最后跑起来直接抛错。Glue 范式通过物理隔离来控制这个风险。你让 AI 生成的是独立的、可独立测试的模块，每个模块的输入输出都由你预先定义好。模块内部无论怎么实现，只要满足契约就行。模块之间的逻辑由你通过胶水代码串联，你可以控制调用顺序、异常处理策略、数据转换规则。这样一来，AI 出错的影响范围就被限制在了单个模块内部。用一句通俗的话说：AI 只负责写零件，每个零件干什么、有什么规格你说了算；装不装得上、装在哪里，由你来决定。这就像你请了个技术很熟练但不太懂你家里布局的水电工，让他帮你把各个线路做好，但总闸怎么拉、线路怎么走，你必须自己把关。4.2 一个系统集成场景的完整拆解说一个我实际做过的模拟项目：一个跨平台数据采集与上报系统。需求是从多个异构数据源采集数据，做规格化处理后上报到统一端点。如果用 Vibe 范式直接把所有需求丢给 AI 生成，那大概率是灾难——数据源格式各不相同，每个源的解析逻辑都不同，一旦某个源格式发生变化，整个代码都受影响。Glue 范式的做法是分四步走。第一步，定义模块边界。我给 AI 定义了四个独立函数，每个承担一个职责：函数1: fetch_raw_data(source_config) -> raw_data 从指定数据源读取原始数据，返回格式不限。 函数2: normalize_record(raw_data, schema) -> normalized_data 将原始数据转换为符合 schema 的规格化数据。 函数3: validate_record(normalized_data) -> (is_valid, errors) 校验规格化数据是否合法，返回布尔值与错误列表。 函数4: upload_batch(records) -> upload_result 将记录批量上报到目标端点。第二步，逐个让 AI 实现这些函数。每个函数单次生成，单独测试，可以保证每个零件的正确性。最关键的是每个函数里都包含数据源或格式相关的信息，这个信息由我在函数描述中显式传入，而不是隐藏在一些隐式的全局约定里。第三步，编写胶水代码。这部分是我手写的，大概逻辑如下：def run_sync_once(source_config, schema): raw_data = fetch_raw_data(source_config) normalized = normalize_record(raw_data, schema) valid, errors = validate_record(normalized) if not valid: log_errors(errors) return upload_batch(normalized)这段胶水代码虽然只有几行，但它决定了整个流程的顺序：先取数、再转换、再校验、最后上报。任何一步失败，流程直接终止并记录错误。这个编排逻辑是业务规则的一部分，不应该让 AI 自动生成。第四步，集成测试。把 AI 生成的四个独立模块与我手写的胶水代码拼起来，用测试数据跑一遍全流程。因为每个模块都已经验证过，集成阶段出现的问题基本只会出在接口对接上，排查范围大大缩小。4.3 单元接口设计的三条核心原则Glue 范式对接口设计的要求比较高，我总结出三条原则：接口要窄。每个函数只做一件事，参数越少越好。一个函数超过三个参数就说明边界拆分有问题。数据结构要明确。跨模块传递的数据用明确的结构（dataclass、TypedDict、Pydantic 模型），尽量避免用裸字典。因为裸字典的键名一旦写错，只有运行时才能发现，而明确结构可以在静态检查阶段就暴露问题。错误处理要外置。模块内部不要吞异常，让异常向上抛，由胶水层统一处理。这样每个模块的职责更纯粹，全局错误策略更可控。Glue 范式的代价是你需要花时间设计接口和编写胶水代码，这部分看起来不够“AI 化”，但在项目中后期会非常值。它让整个系统保持了你可理解的形态，而不是一个黑盒。对于任何需要持续迭代、后续要加需求改逻辑的项目，我强烈建议优先用 Glue。5. Spec 范式实战：用规格说明驱动稳定的模块交付Spec 范式是工程化程度最高的范式，它把 AI 当作一支可以反复调用的实施团队，而你自己担任架构师兼产品经理。你输出的不是零散的需求描述，而是一份完整的规格说明书，AI 的职责就是照着规格实现。5.1 从需求到规格的转化方法写规格文档的第一步是确定需求的边界。你需要明确：这个模块给谁用、输入是什么、输出是什么、在什么环境下运行、性能要求是什么。这不是随意写的，它需要你对自己要做的功能有清晰的理解——这正是 Spec 范式对开发者能力要求高于其他范式的地方。第二步是分解约束。把从接口设计、异常处理、数据校验、日志输出等方方面面全部写进规格文档。规格越具体，AI 的自由裁量空间越小，产出越稳定。这里有一个对比可以说明问题：Vibe 模式下你说“做一个用户注册接口”，AI 可能给出四种不同的实现：有的用邮箱注册，有的用手机号，有的默认用户名就行。Spec 模式下你写的是“用户注册接口，携带参数 user_name（字符串，3-20 个字符）、email（字符串，邮箱格式）；email 已存在时返回 409 + 错误码 EMAIL_EXISTS；注册成功后自动生成默认昵称并返回用户 ID 与 token”。AI 看到这种规格，产出的代码与你的预期几乎不会偏差。5.2 规格文档的标准结构与必备要素我在实践中通常把规格文档分成六块：背景与目标：模块要解决什么问题。功能列表：每个功能的编号、描述、优先级。接口定义：输入、输出、错误码、异常处理规则。数据结构定义：字段、类型、必填性、约束。非功能需求：性能指标、并发要求、兼容性要求。验收标准：如何判断这个模块是否合格。验收标准这一块很多人会忽略，但它恰恰是 Spec 范式的精髓。没有验收标准的规格，本质上只是换了种方式说需求。有没有验收标准，直接决定了 AI 是“做完就行”还是“做对才行”。5.3 用规格驱动一个用户认证模块的完整示例下面这个示例我基于一个实际做过的模拟项目整理而来。需求是实现一个轻量级的用户认证服务，包含注册、登录、令牌刷新三个接口。我没有直接把这些需求丢给 AI 写代码，而是先写了一份规格摘要：模块：用户认证服务 1. 注册接口 POST /api/register 请求：{ "username": string(3-20), "password": string(6-32, 必须包含数字和字母) } 成功（201）：{ "user_id": int, "token": string(32) } 失败（400）：密码不符合规则时返回错误码 WEAK_PASSWORD 失败（409）：用户名已存在时返回错误码 USERNAME_TAKEN 实现要求：密码使用 bcrypt 哈希保存，禁止明文存储。 2. 登录接口 POST /api/login 请求：{ "username": string, "password": string } 成功（200）：{ "token": string(32), "expires_in": 3600 } 失败（401）：用户名或密码错误时返回统一错误码 INVALID_CREDENTIALS 3. 刷新接口 POST /api/refresh 请求：{ "refresh_token": string(64) } 成功（200）：{ "token": string(32), "expires_in": 3600 } 失败（401）：refresh_token 无效或过期时返回 TOKEN_EXPIRED 4. 数据存储：使用 SQLite，表名为 users，结构由你设计，但必须包含 user_id, username, password_hash, refresh_token, created_at。 5. 非功能要求：所有接口需要记录访问日志；密码字段不得出现在日志中。 6. 验收标准：上述三个接口在本地可启动，用 curl 测试可得到预期结果。这份规格传达的信息量远超一句“帮我写个登录注册”。它把字段约束、错误码、哈希方案、日志规则、验收方式全部具象化了。然后我把规格发给 AI，让它完整实现。它的输出非常符合预期：FastAPI 应用，bcrypt 哈希，JWT 令牌，SQLite 存储，日志过滤了密码字段。过程中我几乎没有介入，全程只做了两轮审阅：第一轮检查接口实现是否严格遵守错误码命名，第二轮检查密码字段是否真的没有出现在日志记录里。Spec 范式最大的好处是结果可预期。同一份规格发十次，产出的代码虽然内部实现可能有变化，但接口行为一定是稳定的。这让它非常适合核心业务模块的开发——这些模块的特点是：需求明确、变更频率低、对稳定性要求极高。Spec 范式可以保证在这些模块上投入的每一分 AI 算力都在产出正确的功能，而不是在试探需求。5.4 Spec 范式的代价与适用范围当然 Spec 范式也有明显的代价：前期写规格的时间成本高。一个中等模块的规格文档，我通常要写 20-40 分钟，比直接写代码还慢。所以我不建议所有代码都走 Spec，它最适用的场景是“值得被稳定维护的模块”，比如用户认证、支付、权限控制、核心业务逻辑。而为了快速验证而写的脚本、一次性工具、UI 原型的探究——这些统统不适合 Spec，用 Vibe 或 Plan 效率更高。还有一个容易踩的坑：规格文档写得过于追求面面俱到，会导致 AI 在实现时束手束脚。比如你规定了数据库表结构每一个字段名，又规定了缓存策略，又规定了日志格式，最后 AI 被各种约束绑死了，反倒会花费大量不必要的思考。规格制定者的核心能力应该是“知道哪些需要约束、哪些应该放权”。把关键接口、数据安全、验收标准锁死，把实现路径留给 AI，这才是合理的规格设计。6. Smell 范式实战：让 AI 成为代码评审的第一道关卡前四种范式都聚焦在“怎么让 AI 写出更好的代码”，Smell 范式换了个方向：让 AI 帮你审查已经存在的代码，找出不合理之处。它对应的是传统团队里 Code Review 环节，AI 在这里担当的是一个不会累的评审者。6.1 AI 代码评审与传统 Code Review 的差异传统 Code Review 受限于评审者的时间和精力，很难每次做到全面覆盖——尤其是那些不产生明显 bug 但会让后续维护变困难的问题，比如重复逻辑、函数过长、循环嵌套太深、命名不清晰、缺少边界处理。AI 在这方面有天然优势：它能一次处理大量代码，而且不会因为“看了太多遍”而失去专注力。但 AI 评审有自己的局限——它不掌握项目的完整上下文。一个函数写得复杂，不一定是坏的，可能是因为业务逻辑本身就复杂；一段看似重复的代码，可能是为了保证两个模块的独立部署。所以我在使用 Smell 范式时，始终强调的是它只能作为第一道关卡，不能代替人工评审。6.2 一次有效的 AI 评审是怎么做的我有一套固定的提问模板，实际效果还不错。例如我对一段 Python 模块发起评审：以下是某项目中负责订单状态流转的模块核心代码。 请从以下几个维度进行评审： 1. 是否有重复逻辑可提取？ 2. 是否有可以抽离为独立函数的长段落？ 3. 是否有边界条件未处理？ 4. 是否有资源未释放的风险？ 5. 变量命名与函数职责是否匹配？ 请逐条输出发现的问题，每条问题请指出具体行号或代码段，并给出修改建议。AI 在收到这种含“具体代码 + 明确的评审维度”的请求后，产出的反馈质量非常稳定。我实际遇到的几类问题，它几乎都指出来了：循环内重复执行数据库查询（N+1 查询风险）、异常分支里没有回滚部分已更新的状态、一个工具函数里混入了与业务相关的硬编码配置。6.3 我踩过的一个高频评审误区很多人在让 AI 评审时，直接把 API 文档里随便扒出来的代码片段贴进去，不给任何上下文。这会导致一个典型问题：AI 基于它自己的经验指出一堆问题，但实际上大部分不适用。比如它会说“这个函数最好拆成三个小函数”，可实际情况是这段代码是一个极致性能敏感的热点函数，拆分得不偿失。正确做法是：把代码所在模块的职责说明文字加在代码前面。比如“这是一个定时任务模块，每 5 分钟运行一次，负责从某队列拉取数据并写入数据库，并发场景下可能出现重复写入”。有了这层上下文，AI 的评审建议会精准很多，它会把“重复写入”当成关键点去查，而不是泛泛地建议拆函数。这是一个非常值得重视的细节。6.4 Smell 范式与传统工具链的联动策略Smell 范式与传统静态检查工具（如 linter、SonarQube 一类）不冲突，而是互补。静态工具擅长查语法规范、潜在 bug 模式，AI 更擅长查语义层面的问题，比如模块职责混乱、错误处理缺失、命名与逻辑意图不符。我在项目里通常的组合是：静态工具随代码提交自动运行，AI 评审放在大功能合并之前的把关阶段，两者叠加能覆盖绝大部分质量问题。另外，Smell 范式完全可以移植到需求阶段。你可以把接口文档或设计草案扔给 AI，让它站在“实现者”角度找问题：字段有没有缺失、状态流转有没有死路、鉴权漏没漏。这类评审比代码评审更早发现问题的价值更高，因为改文档的成本远低于改代码。7. 范式选型对比与组合实战建议这五种范式各有各的适用范围。为了让大家一眼看清差异，我按自己实战中的体感整理了一个选型表格。维度VibePlanGlueSpecSmell核心输入自然语言需求需求 + 实施计划模块接口定义结构化规格文档已有代码 + 评审维度开发者控制力最低中等较高最高单向（只审不改）产物可维护性低中等高最高提升已有代码质量典型适用任务脚本、原型、一次性任务中等复杂度模块多模块系统核心稳定业务模块合并前把关上手难度低中等中等偏上高低主要风险需求理解偏差计划偏离实际接口设计不合理规格编写耗时误报率高我个人的建议是，这五个范式不要割裂着用。一个典型的中等复杂度项目，全流程可能是这样的：早期探索阶段：用 Vibe 快速验证技术可行性，确认关键方案。确定要做之后：用 Plan 生成整体实施计划，明确模块划分与顺序。正式开发阶段：核心模块用 Spec 写出规格再让 AI 实现，普通模块用 Glue 范式做零件组装。开发收尾阶段：用 Smell 范式对全部代码做一次综合评审，修正发现的问题。这套组合拳我实践下来，整体效率比单一范式至少高一倍。关键原因在于每个环节都选择了最适合的协作模式，而不是一味追求“让 AI 多干活”——这恰恰是很多人的误区。8. 常见问题与避坑经验汇总最后把我这段时间踩过的一些高频坑集中列一下，算是给前面内容做个实践侧的补充。8.1 AI 生成代码难以理解的应对策略很多人反馈 AI 生成的代码风格与自己习惯不一致，后续维护困难。我的应对方式：在生成之前，明确指定代码风格和结构要求。例如“使用类型标注”“每个函数必须带 docstring”“在关键逻辑处补充注释”“禁止使用第三方库，用标准库实现”等约束。这样产出的代码能保持较高的可读性。如果乱入已经发生了，那么用 Smell 范式让 AI 自己解释并重写一遍，也是一种有效的补救方式。8.2 AI 产出错误结论的判断方法AI 在编程场景下其实很少出现“明显错误”，更多是“看起来对但悄悄绕开了你真正想要的逻辑”。比如你让它实现“同步时跳过临时文件”，结果它只在文件名匹配.tmp后缀的层面做，但你的临时文件实际是隐藏目录里的文件——逻辑虽然有，但没覆盖你的实际场景。要避免这种情况，只能在需求描述阶段就把这些例外规则显式写明白。8.3 把上下文管理当作核心技能不管哪种范式，上下文管理都是绕不开的课题。AI 的上下文窗口有限，长项目里早期需求描述可能丢失。我的建议有三条：一是重要需求写成独立文件，而不是只存在于对话框里；二是每次让 AI 干活，先给它一个“项目导读”式的简短说明，避免它根据残缺上下文脑补；三是关键设计决定，主动在对话中复述确认，确保双方理解一致。8.4 什么时候应该放弃 AI 生成也不是所有代码都适合 AI 写。我自己的经验是，涉及高精度逻辑（比如复杂的日期时间处理、加密协议实现）、强实时性能要求的热点代码、以及与现有系统有大量隐式耦合的模块，这些场景建议优先人写。AI 在这些领域错误率不低，而错误代价往往很高。8.5 复合协作模式的最佳实践最后想强调的是，上述各种范式不是固定套路，而是可以互相组合的积木。就拿我最近负责的一个内部工具项目来说，我采用的是“Plan 规整大方向 + Spec 锁死核心模块 + Glue 串联扩展功能 + Smell 做最终把关”，Vibe 只在写辅助脚本时出现。这种组合方式能最大化发挥每种范式在不同环节的优势。根据我个人的体会，AI 编程范式的选择本质上不是工具问题，而是管理问题：你在管理一个能力很强但极其需要明确指令的协作者。你给它的自由度越高，它的想象力发挥余地就越大，但出错概率也随之上升。你给它的约束越多，它的产出就越稳定，但你的前期投入也越大。找到这个平衡点，比学习任何一种单一工具本身更重要。如果你刚入门，我给的建议是从 Vibe 开始练手，这是成本最低的切入方式；当你在生成结果中开始频繁发现“差一点就对了但总差点意思”的问题时，就是切换到 Plan 与 Glue 的时候了；等到你负责核心模块的稳定交付时，Spec 会是你的主战场。最后别把 Smell 落下，它是一种可以在任何阶段帮助你提升已有代码质量的手段。这五种范式一路用下来，AI 生产力在你的项目中才能真正兑现成交付质量。