企业官网建设流程全解析

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做详细规划，核心模块用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用多了，你会发现几个典型的坑。

第一个坑是“方向漂移”。你描述的是A，AI理解成了B，生成的东西和你想要的差很远。这时候不要急着改代码，而是回到描述本身，看看是不是自己的表达有歧义。我通常会重新组织语言，把模糊的词换成具体的例子。比如“现代风格”太模糊，改成“类似Linear的界面风格”就具体多了。

第二个坑是“过度生成”。AI可能会给你生成一大堆你不需要的功能，比如你只要一个按钮，它给你生成了整个表单。这时候你需要明确边界，告诉AI“只生成按钮组件，不要包含表单逻辑”。

第三个坑是“技术栈偏离”。你明明说了用React，AI却给你生成了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映射到username，name映射到display_name，email直接映射，avatar_url映射到avatar，company映射到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 不同场景下的范式选择建议

不同的场景，适合不同的范式。我整理了一个选择建议表：

这个表不是绝对的，你可以根据实际情况灵活调整。关键是理解每种范式的核心逻辑，知道什么时候该用哪种。

7.3 团队协作中的范式落地经验

在团队中推广这五种范式，我踩过一些坑，也总结了一些经验。

第一，不要强制统一。每个人的习惯不同，有人喜欢Vibe的随意，有人喜欢Spec的严谨。强制统一会适得其反。我通常建议团队成员先了解五种范式，然后根据自己的任务选择。

第二，建立共享的Spec库。Spec范式下，规格是核心资产。我建议团队建立一个共享的Spec库，把核心模块的规格保存下来。这样新人可以快速理解业务逻辑，AI也可以参考历史规格。

第三，定期做Smell审查。我建议团队每周做一次Smell审查，用AI扫描代码，发现潜在问题。这比等到问题积累多了再处理，成本低得多。

第四，记录范式使用案例。我建议团队记录每次使用范式的案例，包括场景、提示词、AI输出、人工调整。这些案例可以作为培训材料，帮助新人快速上手。

提示：团队协作中，AI生成的代码需要有人把关。我建议指定一个“AI代码审查员”，负责审查AI生成的代码，确保质量。

8. 常见问题与排查技巧实录

8.1 五种范式使用中的典型问题速查

在实际使用中，我遇到了一些典型问题，整理成速查表：

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编程方法论。这比看任何教程都管用。