五种AI编程范式：Vibe、Plan、Glue、Spec、Smell的选型与实战指南

1. 五种AI编程范式的底层逻辑与选型思路

1.1 为什么需要区分不同的AI编程范式

很多人用AI写代码，习惯打开对话框直接甩一句“帮我写个XX功能”，然后拿到代码复制粘贴。这种方式在简单场景下确实能用，但一旦项目复杂度上来，问题就暴露了：AI给的代码跟现有架构不兼容、变量命名风格混乱、边界条件没处理、改了一处崩了三处。根本原因在于，你把AI当成了一个“代码自动贩卖机”，而不是一个需要明确协作方式的开发伙伴。

所谓“AI编程范式”，说白了就是你和AI协作时的工作模式约定。不同的任务类型、不同的项目阶段、不同的复杂度，需要匹配不同的协作模式。我把它归纳为五种：Vibe、Plan、Glue、Spec、Smell。这五种不是互斥的，而是像工具箱里的不同工具，你得知道什么时候该用哪把。

选错了范式，轻则返工重写，重则把整个代码库搞得一团糟。我见过最典型的翻车案例是：有人用Vibe模式去改一个核心支付模块，结果AI“凭感觉”改了几行，上线后对账直接差了十几万。这不是AI的问题，是范式选错了。

1.2 五种范式的核心定位与适用边界

先给一个全局视角，后面再逐个展开。

这张表建议你存下来。每次准备让AI写代码之前，花十秒钟判断一下当前任务该用哪种范式，能帮你省下大量返工时间。

1.3 范式选择的核心判断标准

怎么判断该用哪种？我总结了一个简单的决策链：

第一，问自己“这段代码将来谁来维护”。如果只是你自己临时用一下，Vibe就够了。如果是团队项目、要进主分支、半年后还有人改，那就得往上走到Plan或Spec。

第二，问自己“需求是否已经完全想清楚”。如果脑子里只有一个模糊的方向，先用Vibe快速试错，试出感觉了再转Plan或Spec。如果需求已经很明确，直接上Spec。

第三，问自己“这段代码是独立的新功能还是跟现有系统深度耦合”。独立新功能，Plan或Spec都行。深度耦合的集成代码，Glue模式更合适，因为你需要AI理解现有的接口和数据结构。

第四，问自己“这段代码有没有隐藏的坑”。如果你对现有代码质量心里没底，先用Smell模式让AI帮你做一轮体检，再决定怎么改。

注意：范式之间是可以切换的。一个典型的流程是：Vibe探索方向 → Plan确定方案 → Spec细化规格 → Glue集成落地 → Smell审查验收。不要死守一种模式。

2. Vibe编程：凭感觉写代码的正确打开方式

2.1 Vibe编程到底是什么

Vibe coding这个词最近很火，但很多人理解偏了。它不是“让AI随便写”，而是“你用自然语言描述你想要的 vibe（感觉/效果），AI帮你实现”。重点在于快速把脑子里的想法变成能跑的东西，不追求代码质量，追求的是验证速度。

举个我自己的例子。上周我想做一个自动整理下载文件夹的小工具，需求很模糊：按文件类型分文件夹、重名自动加序号、每周跑一次。我懒得写详细规格，直接跟AI说：“帮我写个Python脚本，扫描下载文件夹，按扩展名分类到子文件夹，重名文件加时间戳后缀，用schedule库每周一早上9点跑一次。”三十秒后代码就出来了，跑了一下基本能用，改了两个小地方就搞定了。这就是Vibe编程的典型场景。

2.2 Vibe编程的实操要点

用Vibe模式有几个关键技巧：

第一，描述要带“感觉”而不是“规格”。不要说“创建一个函数，参数为字符串类型，返回值为布尔类型”，而要说“我想要一个能判断用户输入是不是有效邮箱的东西，别太严格，常见的格式就行”。后者给AI的发挥空间更大，出来的代码往往更实用。

第二，一次只描述一个功能点。很多人喜欢一口气说“帮我写个网站，要有登录、注册、发帖、评论、点赞、搜索功能”，结果AI给出来的东西每个功能都是半成品。正确的做法是一个功能一个功能来，每个功能跑通了再叠加下一个。

第三，接受“不完美但能用”。Vibe编程的产出物，代码风格可能不统一，错误处理可能不完善，但核心功能是通的。这没关系，因为这个阶段的目的是验证想法，不是交付产品。

第四，随时准备扔掉重写。Vibe出来的代码，如果后面要正式用，建议让AI基于当前逻辑重新用Spec模式生成一遍。直接在上面改，很容易越改越乱。

2.3 Vibe编程的典型翻车场景

Vibe模式最大的坑是在错误的场景用了它。以下几种情况千万别用Vibe：

• 涉及金钱计算的逻辑。AI“凭感觉”写的浮点数运算，精度问题能让你赔到怀疑人生。
• 涉及用户数据安全的代码。AI可能给你生成一个看起来能用但实际上有注入风险的查询语句。
• 需要跟现有系统深度集成的模块。AI不了解你的系统架构，写出来的东西大概率跑不通。
• 有严格性能要求的场景。AI默认生成的代码通常不考虑性能优化。

我踩过最惨的一次坑：用Vibe模式让AI写了一个批量处理Excel的脚本，处理小文件没问题，一上生产环境处理十万行数据直接内存溢出。后来用Plan模式重新设计，加了分批读取和流式处理才解决。

3. Plan编程：先谋后动的工程化协作

3.1 Plan模式的核心价值

Plan模式的核心就一句话：让AI先出方案，你确认后再写代码。这个“确认”环节是整个范式最关键的地方，它把AI从“执行者”变成了“方案提供者”，你从“验收者”变成了“决策者”。

为什么这个转变重要？因为AI写代码很快，但写错了改起来也快——快到你来不及思考它为什么错。Plan模式强制你在写代码之前先过一遍思路，把逻辑漏洞、架构冲突、边界条件这些问题在方案阶段就暴露出来。

我现在的习惯是：任何超过50行的代码，都先让AI出方案。方案不用很长，但必须包含：整体思路、关键数据结构、核心函数签名、潜在风险点。看完方案我再决定是直接让它写，还是调整方案后再写。

3.2 Plan模式的实操流程

一个完整的Plan模式协作流程是这样的：

第一步，描述需求背景。不要只说你想要什么，还要说清楚现有系统的情况。比如“我现在有一个Flask项目，用户表已经有id、name、email三个字段，现在想加一个手机号字段，需要支持国际号码，并且要能通过手机号登录。”

第二步，让AI出方案。明确要求：“先不要写代码，给我一个实现方案，包括数据库改动、接口改动、需要新增的函数。”

第三步，审查方案。重点看几个地方：数据库改动是否兼容现有数据、接口设计是否符合现有风格、有没有遗漏的边界情况、有没有引入不必要的依赖。

第四步，确认或调整。如果方案有问题，直接指出来让AI改。这一步可以来回几轮，直到方案满意为止。

第五步，让AI按方案写代码。这时候AI的产出质量会明显高于直接写，因为它有了明确的约束。

第六步，验收。对照方案检查代码是否完整实现了所有点。

3.3 Plan模式的注意事项

Plan模式最容易犯的错误是方案太粗。如果AI给的方案只有“加一个字段、改一个接口”这种级别，那跟没做方案差不多。好的方案应该细到“这个字段用什么类型、默认值是什么、索引怎么加、旧数据怎么迁移、接口的请求参数和返回结构是什么”。

另一个坑是方案确认后AI跑偏。有时候你确认了方案，但AI写代码的时候还是自由发挥。解决办法是在让它写代码时，把方案原文再贴一遍，并加上一句“严格按照上述方案实现，不要自行添加或修改任何设计”。

还有一个经验：Plan模式特别适合多人协作的场景。因为方案本身就是一份天然的沟通文档，你可以把AI出的方案发给同事review，收集完意见再让AI写代码。这比写完代码再review效率高得多。

4. Glue编程：用AI做系统间的粘合剂

4.1 Glue模式的适用场景

Glue编程，顾名思义，就是写“胶水代码”——把两个或多个已有系统连接起来的代码。这类代码通常不包含复杂的业务逻辑，但需要准确理解各个系统的接口、数据格式和调用约定。

典型的Glue场景包括：调用第三方API获取数据后写入自己的数据库、把A系统的数据格式转换成B系统能识别的格式、写定时脚本同步两个平台的数据、给现有系统加一个Webhook接收外部通知。

这类代码的特点是：逻辑不复杂，但细节特别多。字段名对不对、时间格式是不是UTC、分页参数怎么传、错误码怎么处理、频率限制是多少——任何一个细节搞错，代码就跑不通。而这恰恰是AI擅长的：它能快速处理这些琐碎的细节，只要你把接口文档给它。

4.2 Glue编程的实操方法

用Glue模式的关键是给AI提供足够的上下文。具体来说：

第一，把接口文档贴给AI。不要只说“调用微信支付接口”，而是把接口的请求地址、请求方法、请求参数、返回格式、错误码说明都贴进去。AI不需要你解释这些参数是什么意思，它只需要知道这些参数存在。

第二，说明数据流向。告诉AI数据从哪来、经过什么处理、到哪去。比如“从A接口拿到订单列表，提取订单号和金额，调用B接口创建对账单，把B接口返回的对账单ID写回A系统的备注字段”。

第三，指定异常处理策略。胶水代码最容易出问题的就是异常处理。明确告诉AI：网络超时怎么办、接口返回错误码怎么办、数据格式不符合预期怎么办、部分成功部分失败怎么办。

第四，要求输出日志。胶水代码跑在后台，出问题了没有日志根本没法排查。让AI在关键节点加上日志输出，记录请求参数、响应结果、处理耗时。

4.3 Glue编程的避坑经验

Glue模式最大的坑是AI“脑补”接口细节。比如你告诉AI“调用用户查询接口”，AI可能会自己编一个/api/user/query的路径和{“name”: “xxx”}的参数格式，但实际上你的接口是/api/v2/users/search和{“keyword”: “xxx”}。这种错误在代码审查时很难发现，因为看起来逻辑是对的，只有跑起来才会报404。

解决办法很简单：把真实的接口文档或示例请求响应贴给AI。如果没有文档，先用curl或Postman调一次接口，把请求和响应的原始内容复制给AI。这一步多花两分钟，能省下两小时的调试时间。

另一个坑是忽略了接口的频率限制和重试策略。很多第三方API都有调用频率限制，AI默认生成的代码通常不带重试和退避逻辑。你需要明确要求：“加上重试机制，最多重试3次，每次间隔指数增长，遇到429状态码时等待更长时间。”

还有一个经验：Glue代码写完后，一定要用真实数据跑一遍。不要用mock数据测试，因为mock数据往往太干净了，真实数据里的空值、特殊字符、超长字段才是真正的考验。

5. Spec编程：规格驱动的高可靠性开发

5.1 Spec模式的核心思想

Spec编程是我个人最推崇的范式，也是最适合核心业务代码的方式。它的核心思想是：先写一份精确的规格说明，然后让AI严格按照规格实现代码。

这里的“规格”不是那种几百页的需求文档，而是一份精确到函数级别的技术说明。它应该包含：每个函数的输入输出、数据结构的字段定义、边界条件的处理方式、错误情况的返回值、关键逻辑的伪代码或流程图。

为什么Spec模式可靠性最高？因为它把“AI自由发挥”的空间压缩到了最小。AI不需要猜测你的意图，不需要做架构决策，它只需要把规格翻译成代码。翻译过程中即使有偏差，也很容易通过对照规格来发现。

5.2 Spec模式的实操流程

写一份好的Spec，我通常按这个结构来：

第一部分：数据结构定义。把所有涉及的数据结构用表格或代码块列出来，包括字段名、类型、是否必填、默认值、取值范围、示例值。这一步看起来繁琐，但能避免大量“字段名拼错”“类型不匹配”的低级错误。

第二部分：函数签名列表。列出每个函数的名称、参数、返回值、一句话功能描述。不需要写实现，但签名要精确。

第三部分：核心逻辑说明。对每个函数，用自然语言描述它的处理逻辑。重点说明：正常流程怎么走、异常情况怎么处理、边界条件怎么判断。

第四部分：测试用例。给出几个典型的输入输出示例，包括正常情况和异常情况。这既是给AI的参考，也是后续验收的标准。

写完之后，把整份Spec贴给AI，加上一句：“严格按照以下规格实现代码，不要添加规格之外的任何功能，不要修改任何函数签名。”

5.3 Spec模式的参数计算与细节处理

Spec模式最考验功力的是边界条件的定义。举个例子，假设你要写一个“计算订单折扣”的函数，Spec里必须明确：

• 订单金额为0时返回什么？
• 折扣率为负数时怎么处理？
• 折扣后金额出现小数时怎么舍入？
• 多个折扣叠加时的计算顺序是什么？
• 折扣金额超过订单金额时怎么处理？

这些问题如果不提前定义，AI就会自己“合理猜测”，而它的猜测大概率跟你的预期不一致。我见过一个案例：AI把“折扣后金额”做了四舍五入到整数，但业务要求保留两位小数，结果财务对账时差了0.01元，查了一整天才找到原因。

另一个Spec模式的关键点是版本兼容性。如果你的代码需要兼容旧版本的数据格式，Spec里必须明确说明：旧格式是什么样的、新格式是什么样的、如何判断用哪种格式、转换规则是什么。AI不会自动考虑这些，你必须显式告诉它。

提示：Spec写完后，建议先让AI复述一遍它理解的规格，确认没有歧义后再让它写代码。这个“复述确认”环节能拦截大部分理解偏差。

6. Smell编程：用AI做代码体检与重构评估

6.1 Smell模式的价值定位

Smell编程，指的是用AI来识别代码中的“坏味道”（code smell）——那些不是bug但会导致维护困难的代码模式。比如：过长的函数、重复的代码块、过深的嵌套、不清晰的命名、过多的参数、散落的魔法数字。

这个范式的价值在于：人写代码时间长了会有盲区，AI没有。你觉得自己写的代码挺清晰，AI一眼就能看出“这个函数有200行，做了5件不同的事，应该拆成5个函数”。你觉得自己命名挺合理，AI能指出“这个变量叫data，但实际存的是用户列表，应该叫userList”。

我现在的习惯是：每次完成一个模块，先让AI做一轮Smell审查，根据审查结果决定是直接提交还是先重构。这个习惯帮我避免了很多“当时能跑，三个月后看不懂”的代码。

6.2 Smell模式的实操方法

用Smell模式时，提示词的设计很关键。不要只说“帮我看看这段代码有什么问题”，这样AI会给你一堆无关痛痒的建议。要具体指定审查维度：

维度一：可读性。命名是否清晰、注释是否充分、函数长度是否合理、嵌套层级是否过深。

维度二：可维护性。是否有重复代码、是否有硬编码值、模块间耦合度是否过高、是否有未使用的变量或函数。

维度三：健壮性。是否有未处理的异常、是否有边界条件遗漏、是否有资源泄漏风险、是否有并发安全问题。

维度四：性能。是否有不必要的循环嵌套、是否有重复计算、是否有可以缓存的查询、是否有N+1查询问题。

让AI按这四个维度分别给出评估，每个问题标注严重程度（高/中/低）和修改建议。这样出来的报告结构清晰，你可以按优先级逐个处理。

6.3 Smell模式的常见问题与排查

Smell模式最常见的坑是AI过度建议。它会把你代码里所有“不够完美”的地方都列出来，包括很多其实没必要改的。比如“这个函数有15行，建议拆成两个函数”——15行真的不算长，拆了反而增加理解成本。

我的处理方式是：让AI按严重程度排序，只关注“高”和“中”级别的问题，“低”级别的直接忽略。另外，对于每个建议，我会问自己一个问题：“如果不改，三个月后会不会有人因为这个踩坑？”如果答案是“不会”，那就不改。

另一个坑是AI的重构建议可能引入新bug。特别是涉及逻辑调整的重构，AI改完之后一定要跑一遍完整的测试用例。我一般会让AI在重构前后各生成一份测试报告，对比确认行为一致。

还有一个经验：Smell审查最好在代码刚写完时做，不要等到项目快上线了才做。刚写完时你对代码还熟悉，AI的建议你能快速判断是否合理。等到三个月后再看，你自己都忘了当时为什么这么写，AI的建议就更难判断了。

7. 五种范式的组合使用与实战案例

7.1 一个完整项目的范式切换实录

光说理论没意思，我拿最近做的一个“用户反馈自动分类系统”来串一遍五种范式的实际使用。

阶段一：需求探索。老板说“用户反馈太多了，能不能自动分类”。需求很模糊，我用Vibe模式快速试了几个方向：先让AI写了一个基于关键词匹配的分类脚本，跑了一下发现准确率太低；又让AI试了一个基于简单机器学习的方案，效果也不理想。但这个过程中我逐渐明确了需求：需要能处理中文、需要能自定义分类、需要能持续学习新样本。

阶段二：方案设计。需求明确后，切到Plan模式。我让AI出了三个方案：基于规则引擎、基于预训练模型微调、基于大模型API调用。每个方案都给出了优缺点、实现复杂度、预估成本。我选了第三个方案，因为开发周期最短，效果也够用。

阶段三：规格编写。方案确定后，切到Spec模式。我写了一份详细的规格：输入是用户反馈文本，输出是分类标签和置信度；支持通过配置文件自定义分类标签；调用大模型API时需要有重试和降级策略；分类结果需要记录到数据库供后续分析。规格写完后让AI实现，一次通过。

阶段四：集成对接。核心逻辑写完后，需要跟现有的反馈系统对接。切到Glue模式，把反馈系统的数据库结构、消息队列格式、API文档都贴给AI，让它写数据同步和结果回写的代码。这部分代码逻辑简单但细节多，AI处理得很好。

阶段五：代码审查。全部写完后，切到Smell模式做一轮全面审查。AI指出了几个问题：API调用的错误处理不够完善、数据库连接没有用连接池、日志级别设置不合理。按建议修改后，代码质量明显提升。

整个项目从开始到上线，大概用了三天。如果全程只用一种范式，我估计至少要一周，而且代码质量还没这么好。

7.2 范式选择的速查决策表

为了让你更快做决定，我整理了一个速查表：

7.3 常见误区与纠正

最后说几个我见过的典型误区：

误区一：认为Spec模式太慢。写规格确实要花时间，但省下的是调试和返工的时间。我统计过，写规格花1小时，能省下至少3小时的调试和修改。对于要长期维护的代码，这个投入产出比极高。

误区二：Vibe模式出来的代码直接上生产。这是最危险的。Vibe代码必须经过Smell审查和充分测试才能上生产，否则就是在埋雷。

误区三：Plan模式只做一次。项目进行中需求变了，要重新走一遍Plan流程。不要觉得“方案已经定了就按这个走”，需求变了方案不变，最后做出来的东西一定不对。

误区四：Glue模式不需要测试。胶水代码的测试恰恰最重要，因为它连接的是两个独立系统，任何一个系统的行为变化都可能导致胶水代码失效。建议给每个Glue模块写集成测试，定期跑一遍。

误区五：Smell审查一次就够了。代码是活的，每次大的改动后都应该重新做一轮Smell审查。我一般是在每个迭代结束时做一次，作为代码质量的一个检查点。

8. 工具链与提示词模板

8.1 各范式的提示词模板

直接给可复用的模板，你拿去改改就能用。

Vibe模式模板：

我想做一个[功能描述]，大概的效果是[描述你期望的使用体验]。 不用太完美，能跑就行。用[编程语言]写，依赖尽量少。

Plan模式模板：

背景：[描述现有系统的情况] 需求：[描述你想要实现的功能] 请先不要写代码，给我一个实现方案，包括： 1. 整体思路 2. 需要改动的文件或模块 3. 关键数据结构 4. 核心函数签名 5. 潜在风险和注意事项

Glue模式模板：

我需要把[A系统]的数据同步到[B系统]。 A系统的接口文档：[粘贴文档] B系统的接口文档：[粘贴文档] 数据流向：[描述数据怎么流转] 异常处理要求：[描述超时、错误码、部分失败等情况怎么处理] 请写一个[语言]脚本实现这个同步逻辑，加上详细的日志输出。

Spec模式模板：

请严格按照以下规格实现代码，不要添加规格之外的任何功能。 数据结构： [列出所有数据结构] 函数列表： [列出函数签名和功能描述] 核心逻辑： [描述每个函数的处理流程] 边界条件： [列出所有需要特殊处理的情况] 测试用例： [给出典型输入输出示例]

Smell模式模板：

请从以下四个维度审查这段代码： 1. 可读性（命名、注释、函数长度、嵌套层级） 2. 可维护性（重复代码、硬编码、耦合度、无用代码） 3. 健壮性（异常处理、边界条件、资源泄漏、并发安全） 4. 性能（循环嵌套、重复计算、缓存机会、查询效率） 每个问题标注严重程度（高/中/低）和具体修改建议。 按严重程度排序，只关注高和中级别的问题。 代码： [粘贴代码]

8.2 实操中的经验补充

这些模板是我用了大半年之后沉淀下来的，但有几个细节需要根据实际情况调整。

第一，语言选择。如果你的项目有特定的代码风格要求，在模板里加上一句“遵循PEP8规范”或“使用项目现有的命名风格”。AI默认的风格可能跟你的项目不一致。

第二，依赖控制。Vibe模式下AI可能会引入一些不必要的依赖，加上“尽量使用标准库，不要引入第三方依赖”能避免这个问题。

第三，注释语言。如果你的团队用中文注释，明确告诉AI“注释用中文”。默认情况下AI会用英文注释。

第四，错误处理深度。AI默认的错误处理通常比较浅，只捕获异常不处理。如果你需要更完善的错误处理，在模板里明确要求“每个可能失败的操作都要有错误处理和日志记录”。

第五，测试代码。Spec模式下可以让AI同时生成单元测试，但要在规格里明确测试的覆盖范围。我一般要求“对每个公开函数生成至少一个正常用例和一个异常用例”。

8.3 不同AI编程工具的适配建议

不同的AI编程工具对提示词的响应风格不一样，简单说一下我的使用感受。

Cursor和Windsurf这类IDE集成的工具，适合Vibe和Glue模式，因为可以直接在编辑器里看到代码变化，快速迭代。Plan和Spec模式用这类工具也可以，但建议把方案和规格写在单独的文档里，不要直接在对话框里写，方便后续查阅。

VS Code Copilot适合Plan和Spec模式，它的补全能力很强，你写好函数签名和注释后它能自动补全实现。但Vibe模式下用它效率不高，因为它的交互方式更适合“你写一半它补一半”，而不是“你描述它全写”。

Trae这类工具我用的时间不长，感觉它在Glue模式下的表现不错，对接口文档的理解比较准确。但Spec模式下它的表现不如Copilot稳定，有时候会忽略规格里的细节要求。

不管用哪个工具，核心原则是一样的：范式决定协作方式，工具只是载体。先把范式用对，再考虑工具优化。

9. 从范式到习惯：我的日常协作流程

9.1 一天的工作流拆解

说说我现在的日常，你感受一下五种范式是怎么融入工作流的。

早上到工位，先花十分钟梳理今天的任务。每个任务在脑子里过一遍：这个任务属于哪种范式？需要AI做什么？我自己做什么？

如果是新功能开发，我一般上午做Plan和Spec。上午脑子清醒，适合做方案设计和规格编写这种需要思考的工作。把方案和规格写好后，下午让AI按规格实现，我来做审查和测试。

如果是修bug或小改动，直接用Vibe模式快速处理。但改完之后一定会跑一遍Smell审查，确认没有引入新的坏味道。

如果是跟外部系统对接，用Glue模式。先把接口文档整理好，一次性贴给AI，让它生成完整的对接代码。然后我用真实环境跑一遍，根据报错信息让AI调整。

一天结束前，花十五分钟做Smell审查。把今天写的代码过一遍，看看有没有可以优化的地方。这个习惯坚持了半年，我的代码质量明显提升了一个档次。

9.2 团队协作中的范式约定

如果你是团队负责人，建议在团队里推行范式约定。我们团队的做法是：

• 在代码仓库的README里写明：什么类型的任务用什么范式，对应的提示词模板放在哪个目录。
• Code Review时，审查者会检查提交的代码是否遵循了对应的范式要求。比如Spec模式的代码，必须附带规格文档；Glue模式的代码，必须有集成测试。
• 每周技术分享会，轮流分享一个范式使用的心得或踩坑经验。

这套机制运行了三个月，团队整体的代码返工率下降了大概四成。最明显的变化是：以前经常出现的“AI写的代码跟现有架构不兼容”问题，现在基本没有了，因为Plan和Spec模式在写代码之前就把架构对齐了。

9.3 持续优化的方向

最后分享几个我正在尝试的优化方向。

第一个是范式自动化推荐。我在尝试写一个简单的脚本，根据任务描述自动推荐应该用哪种范式。目前准确率大概七成，还在优化中。

第二个是规格模板库。把常见的功能类型（CRUD接口、数据同步、定时任务、消息处理）的规格模板整理成库，下次遇到同类需求直接套模板，省去从零写规格的时间。

第三个是Smell审查的量化指标。我在尝试给代码的“坏味道”打分，比如函数平均长度、重复代码比例、测试覆盖率等，用数据来跟踪代码质量的变化趋势。

这些东西不一定适合每个人，但方向可以参考：把AI编程从“随缘使用”变成“有方法、有流程、有度量”的工程实践。这才是五种范式真正的价值所在。