企业官网建设流程全解析

过去大半年，我几乎把所有精力都花在跟 AI 结对写代码上。从最初图新鲜拿着对话窗口让它帮我写点脚本，到后来认认真真把 AI 当成团队里的一个成员来管理，这个过程里最大的感受是：会跟 AI 聊天和能把 AI 用好，完全是两码事。前一阵子在几个技术社区里看到大家在讨论 AI 编程的"流派"，后来慢慢沉淀出了五个词——Vibe、Plan、Glue、Spec、Smell。我不是什么术语发明者，但作为一个把 AI 写进日常开发流程的人，这五个词确实把我这一年多踩过的坑、趟出来的路，几乎一个不落地概括进去了。

这篇东西不打算讲玄学，也不做科普式罗列。我会把这五种范式当成五套可执行的协作方案，逐个拆开讲清楚：它们各自解决什么问题、核心操作步骤是什么、适合用在什么地方、最容易翻车的地方在哪。最后再用一个虚构的中型项目把五种范式串起来，你看完就能照着给自己手头的项目配一套组合拳。内容会很长，建议先收藏再慢慢看。

1. 五种范式到底在说什么：先建立一套统一认知

1.1 每一个词都对应一种"跟AI打交道的姿势"

这五个词不是官方制定标准，更像是社区在大量实践中形成的"黑话"。你可以把它们理解成五种完全不同的协作姿态：

• Vibe（氛围编程）：凭感觉驱动 AI，把大部分代码生成交给 AI，人主要负责判断方向对不对、下一步往哪走。核心姿态是"让它先跑起来，我来看感觉"。
• Plan（计划编程）：动手写代码之前，先让 AI 参与制定一份明确的实施计划，把任务拆解、依赖关系、验收标准都写清楚，计划通过后再进入编码。核心姿态是"先画地图，再开车"。
• Glue（粘合编程）：人负责设计系统结构和关键模块，AI 负责把各个模块、第三方服务、内部工具用胶水代码粘起来。核心姿态是"主干我来定，接缝你去填"。
• Spec（规格编程）：把需求转化为机器可读、可验证的规格说明书，AI 严格按照规格去实现代码。人写的是"契约"，AI 按照契约交付。核心姿态是"先签合同，再施工"。
• Smell（气味编程）：像传统开发里"代码坏味道（Code Smell）"一样，对 AI 生成的内容做系统性审查，识别出 AI 经常产生的"AI 味代码"，再针对性修正。核心姿态是"不信任输出，只看证据"。

1.2 为什么一定要给 AI 编程方式做区分

我见过很多团队在 AI 编程上吵得不可开交。有人觉得 AI 就是废物，生成的东西根本跑不通；有人觉得 AI 是神，需求丢进去它自己能搞定一切。真让他们坐在一起复盘，你很快会发现他们说的根本不是同一件事——前者可能拿 AI 去写核心算法，后者可能只是让 AI 给表格数据做格式化。一旦把过程拆成 Vibe、Plan、Glue、Spec、Smell 这五个维度，很多争论的焦点其实就变成了"在哪个阶段用哪个姿势"，而不是"该不该用 AI"。这个认知统一对团队协作的价值，远大于记住这些名词本身。

1.3 一张表预读五种范式的核心差异

下面这张表建议直接截图保存，后面每一章都会围绕它展开。

现在我们把每一种范式单独拉出来，讲透它背后的逻辑。

2. Vibe Coding：让语感和直觉带着代码跑

2.1 Vibe 不是"不思考"，而是换一种方式思考

Vibe Coding 这种说法传开之后，我见过不少误解，最典型的就是有人把它等同于"把需求丢给 AI 然后躺平"。这完全错了。真正的 Vibe 式工作，是你对项目有足够的全局观和审美判断力，然后把具体的语法、API 调用、模板代码这类"表达层"工作交给 AI，你专注在最顶层的"方向感"上。就像你开车去一个陌生城市，Vibe 不等于闭眼让车自己跑，而是你握着方向盘，AI 只是那个不断提醒你"前面路口该左转"的导航。

说得更直白一点：Vibe Coding 的典型场景是 AI 写代码，你来当那个说"这不对""感觉对了""再往这个方向改一下"的人。它最适合需求还没有完全成型、需要快速验证想法的阶段，也是我做原型最快的方式。

2.2 一个高效的 Vibe 工作流是怎么运转的

很多人用 Vibe 翻车，根源在于他们把对话窗口当成搜索引擎，希望 AI 一次给全答案。真正高效的 Vibe 流是分轮次推进的：

1. 第一轮：给足语境，不给命题作文。别上来就"帮我写一个订单系统"，那只会得到一堆泛泛的样板代码。更好的做法是直接抛出一段现状描述、一个小实验目标，比如"我现在有一个 CSV 文件，里面有十万行订单记录，我想快速看看不同区域的销售趋势，先给我一段能出图表的脚本"。AI 给出的东西可能粗糙，但它是基于真实语境的起点。

2. 第二轮：带着反馈继续磨。看到脚本之后，不要光说"不行"，AI 不是读心者。你要像跟实习生成对编程一样给出具体反馈："折线图看不出差异，改成按月份分组的堆积图""数据清洗那段太复杂，我们只需要剔掉金额为负的行"。每一轮反馈都要指向一个具体改变。

3. 第三轮：跑起来，把报错当对话素材。我最常用的一招是直接把报错信息整段贴回对话窗口，让它自己解释并修改。AI 对自己生成的代码的报错，理解速度通常比人快得多。这时候你只管看它改出来的方案是否符合直觉，符合就继续，不符合就打断。

4. 关键一步：随时准备"另起炉灶"。Vibe Coding 最大的风险是对话上下文越长，历史包袱越重，AI 会不断迎合你之前的错误方向。我的经验是：每隔三到五轮，如果感觉方向不对，直接新开会话，把最有价值的那段代码和需求描述复制过去重新开始。在 Vibe 模式里，定期清空上下文，就像定时释放内存一样重要。

2.3 我用 Vibe 做完一个完整数据看板后的复盘

前阵子我帮某个内部团队做数据看板的原型，用 Vibe 的方式从零开始：第一天把数据文件丢进去，让它生成一个 HTML 页面；第二天让它把数据筛选、图表联动、导出功能一点点加进去。整个过程几乎没有手写一行代码，但是我的大脑并没有闲着——我一直在判断图表布局合不合理、颜色对比够不够清楚、刷新数据的速度能不能接受。最后做出来的原型，团队看了非常满意，甚至直接拿去当正式版本迭代的基础。

但我也要说清楚代价：这个原型里大概有三分之一的代码是我完全没逐行读过的，我只知道它"能跑、看起来对、交互合理"。一旦遇到领域相关的隐性问题，比如时区处理、小数点精度、超大文件内存占用，Vibe 模式给出的代码几乎必然藏着坑。所以我的结论是：Vibe 适合一切"验证想法、找感觉、快速让干系人看到东西"的阶段，但它产出的代码，绝不应该未经审查就进入核心系统。

3. Plan Coding：先画地图再开车的工作流

3.1 为什么光靠 Vibe 会在复杂项目上栽跟头

等你接手一个稍微像样的项目，比如要改一个老系统的模块、加一个涉及数据库迁移和多端联调的功能，Vibe 模式立刻失灵。原因不是 AI 能力不行，而是你脑子里没有一个可执行的"路线图"，AI 也就只能猜你下一步要什么。每一轮交互都在消耗 token，每一次猜测都可能让代码偏离真实目标两个方向。你会发现对话越聊越长，代码越来越散，最后连你自己都说不清这个需求到底算不算做完了。

Plan 范式就是冲着这个问题来的：把"先想清楚再动手"这件事，变成 AI 和人共同执行的流程。

3.2 我的 Plan 文件长什么样

实际落地 Plan Coding 时，我会在项目根目录创建一个PLAN.md，结构非常固定：

• 背景与目标：两三句话说明为什么做这个功能，完成之后用户能得到什么。
• 任务拆解：用无序列表把功能拆成多个可独立验收的子任务，每个子任务带上明确的完成标志。
• 依赖顺序：写明哪些任务依赖哪些前置任务。
• 验收标准：每条任务对应一到两条"怎么算做完"的描述，比如"用户能通过邮箱+密码登录，错误密码提示文案为 XXX"。
• 领域约束：把项目里不成文的规矩写清楚，比如"所有时间统一用 UTC 存储，展示层再转本地时区""所有对外接口必须加 traceId"。

关键在于：这个文件不能只是一份给人看的文档，必须是一份被 AI 当作"操作手册"来执行的输入。我每次会让 AI 专门读一遍 PLAN.md，然后问它"你理解的任务顺序是什么？第一个子任务的验收标准是什么？"它能答上来，计划才真正被它吸收；它答不上来，就说明计划里还有模糊的词，需要继续补充。

3.3 实例拆解：用 Plan Coding 做一个带权限的登录模块

假设要给系统做一个登录模块，直接说"帮我写个登录"最没效率。我一般会在 PLAN.md 里写：

• 任务一：建立用户表和会话表，完成基础建表 SQL 和迁移脚本。完成标志：本地执行迁移后能查出空表。
• 任务二：实现注册接口，完成邮箱格式校验、密码强度校验和唯一性检查。完成标志：用测试脚本调用，能返回成功和两类失败响应。
• 任务三：实现登录接口，完成密码哈希比对、失败计数和锁定策略。完成标志：错误密码连续 5 次后账号被锁 15 分钟。
• 任务四：实现登出和会话续期中间件。完成标志：模拟请求中携带过期 token 能返回 401 并引导重新登录。

把这样的计划喂给 AI，它产出的代码就不再是孤立的函数，而是一整套按顺序可推进的实现。每完成一个任务，我就把验收标准跑一遍，通过之后让 AI 把上一轮的代码做一次简要总结，下一步基于总结继续。这种方式的优点是每一步都有据可查、可回退，AI 不会突然给你一个完全偏离计划的大改造。

3.4 Plan 模式的两种失效信号，建议对照自查

我用 Plan Coding 时也踩过不少坑，最典型的两种失效信号是：

• 计划变成了流水账。如果任务拆得快、粒度太粗，AI 会在一个任务里偷偷塞进一堆你没提过的假设，比如"顺便加了一个缓存"或者"顺手调整了数据库索引"。这种 AI 的"自由发挥"经常导致很难排查的问题。解决方式是让计划里每个任务都带上"不做哪些事"的边界说明。
• 计划一成不变。计划是拿来指导开发节奏的，不是刻在石头上的法律。开发过程中一旦发现某个假设不成立，应该马上回到计划层更新它，而不是带着错误的计划继续闷头写。我跟团队强调最多的一句话是：Plan 的生命力在于迭代，它本身也是代码的一部分，需要被维护。

4. Glue Coding：把 AI 放在系统接缝处

4.1 什么是接缝处的"胶水代码"

每个真实系统里都有大量不属于核心业务、但又是系统运转不可缺少的代码。比如不同服务之间传数据时的格式转换、从数据库查出来的行转成内存对象的映射函数、在第三方接口响应里提取字段的解析规则、定时任务里把消息从一个队列推进另一个队列的桥接代码。这些代码没有太多智力含量，但写起来琐碎、量大、容易出错。Glue Coding 就是把这些"系统接缝处"的体力活交给 AI，把人的注意力留在真正需要业务判断的核心模块上。

我第一次意识到 Glue 的价值是有一天改了某个老项目，里面有一个文件 2000 多行，全是从各个上游系统拿数据、清洗、转换、再塞给下游服务的管道代码。这类代码单个函数看着都简单，但放在一起看，人的耐心很快被消磨掉了。我把这个文件的原型和字段映射表丢给 AI，让它按新协议重写，它花了不到两分钟就给了我一个可运行的版本。那一刻我理解了：Glue Coding 的主战场，是那些让人写又烦、不写又不行、AI 写却恰恰最擅长的部分。

4.2 两类最典型的 Glue 场景

Glue Coding 最值得投入的两类场景分别是：

• 系统集成类：内部系统之间、内部系统和第三方 SaaS 之间的对接。这类代码的核心是"把 A 系统的数据结构翻译成 B 系统能理解的格式"，中间还要处理鉴权、重试、超时、异常映射。让 AI 去写这种翻译代码，效率极高，因为它只需要学会两份文档的数据结构定义，就能按规则生成。
• 工具链拼装类：把项目里现有的 CLI 工具、脚本、外部 API、数据库操作串成一个完整流程。比如"每天凌晨从数据库导出前一天的订单，转成 CSV 上传到存储服务，再把结果通知到群"这种任务，人工写也能写，但让 AI 来拼装，你只需要说清楚顺序、格式和目标，它就能把每一步的现有命令粘到一起。

4.3 实操案例：把三个独立工具串成一个自动化流程

我之前做过一个小工具，任务是这样的：每天要从某业务的数据库里拉出前一天的数据，跟另一份人工维护的名单做匹配，匹配到的记录自动标记，并把结果汇成表格发邮件给业务负责人。

如果把这件事拆开看，数据库操作、名单读取、邮件发送这几个能力在团队里各自都有现成的脚本或工具库。难点在于：把它们的输入输出格式对接起来。数据库查出来的字段名是 snake_case，名单里的名字是自然语言格式，匹配规则还包含同音和简繁体差异，邮件模板要按业务方的习惯排版。我把这些约束一条条写清楚，让 AI 去写中间的数据清洗和转换函数，再让 AI 把调用顺序用主脚本串起来。整个流程接近三百行胶水代码，我大概只改了十来处细节，大部分时间花在审读它的转换逻辑是否符合业务预期。

4.4 Glue 代码的两个隐藏痛点，别忽视

虽然 Glue Coding 效率高，但它的代码恰恰是系统里"最容易被忽略但影响面最大"的部分。两个痛点我想专门提醒：

• 版本漂移。胶水层连接的上下游任何一个字段改了名、调整了格式，胶水层不会自动跟着变。AI 写代码时是基于你给它的静态文档，但文档可能已经过期。所以每次让 AI 重写胶水代码之前，务必把最新的接口文档、最新的数据样例喂给它，并且跑一轮真实数据验证。
• 异常穿透。胶水层的异常处理尤其容易写得马虎。AI 默认的风格是"能简化就简化"，经常只在最外层包一个 try-catch。但接缝处恰恰是最容易出异常的地方，超时、断连、字段缺失、编码不一致。我的做法是：要求 AI 在每一个跨系统调用的边界上都做日志记录，明确异常类型转换规则，宁可在胶水层多写几行防御代码，也不要在查问题的时候靠猜。

5. Spec Coding：把需求变成 AI 能签字的合同

5.1 Spec 和 Plan 的分工：一个管过程，一个管契约

很多人刚接触 Spec Coding 时会和 Plan Coding 混淆。我自己的理解是：Plan 管的是"怎么走"，Spec 管的是"做到什么程度才算符合要求"。Plan 描述任务拆解和顺序，Spec 描述输入输出、边界条件、错误处理、性能指标这些可验证的细节。打个比方，你要盖一栋楼，Plan 是施工顺序表，Spec 是设计蓝图加验收标准。AI 可以并行执行 Plan 里的多个任务，但每个任务都对着同一份 Spec 校验，这样才能保证各干各的拼起来还是一栋完整的楼。

Spec Coding 的使用场景通常是：模块边界清晰、需求相对稳定、对正确性要求高的部分。典型例子包括支付计算、数据导出、文件解析、API 接口实现。这些功能不像 Vibe 那样讲究"感觉好就行"，它们讲究"每一个边界条件都有明确预期"。

5.2 一份高质量 Spec 的七个组成部分

我自己写 Spec 的时候，会固定检查七个部分是否齐全：

1. 功能概述：三句话以内说清这个模块是干什么的。
2. 输入定义：所有输入参数的名字、类型、取值范围、是否必填。
3. 输出定义：返回结果的格式，成功响应和失败响应分别长什么样。
4. 边界条件：空值、超长值、重复值、特殊字符、超大并发等情况下模块应该怎么表现。
5. 错误处理：每个可预见的错误对应什么错误码和提示文案。
6. 依赖与限制：这个模块依赖哪些外部服务，在什么情况下允许降级或抛异常。
7. 验收用例：至少三个可直接执行的测试用例，对应正常路径、异常路径、边界路径。

有了这七块内容，AI 就不再是"自由创作"，而是在完成一份明确合同。

5.3 实例拆解：给"批量导入用户"功能写 Spec

我拿一个很常见、也很适合 Spec 化的功能举例子：批量导入用户。如果交给 AI 随便写，它很可能给你一个"读文件、逐行插入数据库"的朴素实现。但一旦把 Spec 写清楚，事情就完全不一样了：

• 输入定义：CSV 文件，字段为用户名、邮箱、手机号、部门编号；文件大小上限 5MB；单次最多 5000 行。
• 输出定义：返回任务 ID，任务执行结束后生成一份导入结果报告，包含成功行数、失败行数、每行失败原因。
• 边界条件：邮箱重复时默认覆盖还是跳过？手机号格式不合法时是中断整批还是跳过该行？CSV 里带 BOM 或引号内逗号怎么处理？
• 错误处理：文件解析失败返回错误码IMPORT_PARSE_ERROR；超出大小限制返回IMPORT_TOO_LARGE；数据库写入中途失败如何回滚已插入的行。

你们发现没有，同样一个功能，Spec 化之后 AI 实现的代码质量、可测试性和最终交付速度，全都远超直接"帮我写一个导入功能"得到的结果。而且这份 Spec 本身可以被团队评审、修改、复用，它沉淀下来的价值远远超过一次性代码。

5.4 Spec 也要版本管理，别让它变成幽灵契约

写过几轮 Spec 就会发现，Spec 最大的敌人不是写不清楚，而是写完之后没人维护。需求一变，代码跟着改了，但 Spec 没人更新，过两周你拿着一份过期的合同去找 AI 对质，它当然一脸无辜。我现在的做法是把 Spec 放在代码仓库里，和实现代码一起走评审、一起进版本，任何需求变更都先改 Spec 再改代码，这样 AI 任何时候拿到的 Spec 都是当前真实有效的版本。这条规则一开始执行时很痛苦，但坚持下来之后，AI 的返工率直线下降。

6. Smell Coding：给 AI 生成代码做体检

6.1 从"代码坏味道"到"AI 代码坏味道"

传统软件开发里有个概念叫 Code Smell，指那些不一定是 bug、但一看就觉得"不对劲"的代码特征。比如函数太长、命名含糊、重复代码成片出现。AI 生成代码也有它的"气味"，而且特别有规律。我花了不少时间总结这些规律，整理成了自己的 Smell 清单，把它当成审查 AI 输出时的检查表，效率提升非常明显。

我要先说一个前提：Smell Coding 不是每一轮都要做，它主要在两类时点介入——AI 完成一个较大的功能模块之后、以及代码进入代码评审之前。它的作用，是帮你建立一道防御 AI"看起来正确但实际糟糕"的防线。

6.2 我整理的 AI 代码坏味道 Top 10

下面这份清单来自我自己的项目实践和大量代码评审记录，不一定覆盖所有情况，但足够应对大多数常见的 AI 输出：

1. 过度通用化：AI 喜欢生成大量抽象类、接口、工厂方法，哪怕这个项目只有一处使用。它似乎天然倾向于"设计模式表演"。
2. 命名过度诗化：变量名和函数名充满隐喻，比如把数据处理函数叫做harmonizeData，新人根本看不懂。
3. 防御性代码堆砌：在没人会传空值的地方疯狂判空，在不需要重试的地方反复重试，代码量虚胖。
4. 重复逻辑复制粘贴：同一个校验逻辑在三个地方出现三份不同版本，改一处漏两处。
5. 注释描述"是什么"而不是"为什么"：几乎每一行都有注释，但没有一行告诉你当时为什么做了这个取舍。
6. 死代码和隐式依赖：生成了没被调用的函数、没生效的配置项、默默依赖某个全局状态的逻辑。
7. 测试用例太"完美"：测试全是 happy path，断言弱，几乎没有失败路径和边界值的覆盖。
8. 异常的静默吞掉：异常被 catch 之后只留一个空块，没有任何日志和提示。
9. 一步到位的巨型函数：所有逻辑塞进一个函数，参数越加越多，可读性接近零。
10. 引入不必要的第三方库：明明标准库十行能解决的问题，AI 给你拉进来一个 npm 包或者 pip 包，徒增供应链风险。

6.3 如何把 Smell 清单变成团队共识

一个人用 Smell 清单只能保护自己的项目，要让整个团队受益，最好的办法是把它变成代码评审的必检项。我建议的做法是：先在项目里试行一个月，每次评审都对照清单给 AI 写的代码打勾打分。一个月之后把打勾频率最高的几项挑出来，写进团队的评审规范里，并且附上"见过的反面案例"和"期望的改写方式"。比如"禁止空 catch 块"写成硬性规则，"必须输出日志且包含上下文信息"写成硬性规则。Smell Coding 的最终目标不是消灭所有 AI 气味——这不可能——而是把最危险、最影响长期维护的气味扼杀在评审阶段。

6.4 在审查中具体怎么用这份清单

实际操作上，我不会把 AI 生成的代码从头到尾逐行读一遍，那是浪费 AI 的优势。我的做法是先让 AI 自己生成一段"这段代码里可能存在哪些 smells"的自查报告，然后我对照它的报告和我的 Top 10 清单做抽检。抽检重点集中在：有没有静默 catch？有没有重复逻辑？有没有没有断言的测试？一旦发现一个已知 smell，就立刻把对应规则追加到项目级审查清单里。这样几轮下来，AI 生成代码的初始质量会有肉眼可见的提升，因为它会主动规避你频繁提到的坏味道。

7. 实战串联：一个虚构中型项目的五种范式组合

7.1 项目背景：模拟项目 X 的由来

为了让你更直观地理解五种范式怎么配合，我虚拟一个项目来说事：内部工具平台"某跨平台系统"，功能是帮各小组做日常的数据收集、汇总、报表展示。它涉及多端数据采集、后台聚合处理、前端展示和定时推送，属于典型的"规模不大但五脏俱全"的中型项目，拿来演示非常合适。

7.2 阶段一：Vibe 定原型，先让需求可见

项目一开始，需求其实是不清晰的，或者说业务方只知道自己"想要一个平台"，但具体看什么报表、怎么录入数据，谁也说不全。这时候我直接进入 Vibe 模式：把几份样本数据丢给 AI，让它快速生成一个简陋的 Web 页面，先展示数据列表，再逐步加上筛选、汇总、图表。大概两三天时间，我们拿着一个可以点击的原型去跟业务方聊，"是不是这样的感觉？"对方一看到具体页面，需求才真正被激活。没有前面这个 Vibe 阶段，你直接进入需求讨论会，大概率听到的只有抽象名词和意见分歧。

7.3 阶段二：Spec 锁定契约，让核心逻辑可验证

原型确认之后，项目里的"数据清洗和汇总逻辑"成了最核心、也最需要稳定的部分。我马上把这块从原型中剥离出来，单独编写 Spec：明确输入字段、输出字段、分组聚合规则、异常数据丢弃规则、性能指标。然后让 AI 按 Spec 实现独立模块，一遍遍用测试用例验证。在这个阶段，我刻意切断了 Vibe 的节奏——不再让它"自由发挥"，因为自由发挥出来的清洗逻辑可能很智能，但不可预测。

7.4 阶段三：Plan 拆分里程碑，把大工程切块

核心逻辑稳定之后，项目进入大面积功能铺开阶段：用户管理、报表权限、数据推送、消息通知。这些功能彼此独立，但数量多。我按照 Plan Coding 的方式，在 PLAN.md 里按里程碑拆分，每个里程碑有独立的验收标准和测试脚本。团队每天根据里程碑推进，每完成一个就打一个勾，项目进度变得极其透明。Plan 在这时候的价值不是"规划未来"，而是"让所有人的注意力聚焦在下一个可交付的增量上"。

7.5 阶段四：Glue 补全接缝，把各个模块粘成一个系统

当数据模块、用户模块、报表模块分别都有了雏形，项目进入集成阶段，Glue Coding 开始发力。模块之间接口对不上、数据格式不统一、调用顺序需要编排的问题集中浮现。我把所有接缝任务收集起来——Excel 导出功能、定时任务调度、消息队列转换、前端 API 封装——逐个交给 AI 编写胶水代码。这个阶段 AI 的产出数量是最多的，但我审查的颗粒度反而最细，因为接缝处的问题往往要到跑一次完整流程才能暴露。

7.6 阶段五：Smell 建立护栏，让长期维护不掉链子

项目后期和上线之后，Smell Coding 进入常驻状态。每次 AI 提交一批新代码，先过一遍我和团队积累的坏味道清单，再进入代码库。有一回 AI 写了一段定时任务触发逻辑，看着完全正常，但清单里的"静默 catch"一项帮我指出了问题——那个异常处理块把调度器报错吞得一干二净，一旦推送失败不会有任何痕迹。如果没有 Smell 清单，这种问题要等用户在群里问"怎么没收到报表"才会被发现。

7.7 范式切换的判断信号

从上面这个流程能看出，五种范式不是五个独立工具任你挑，更像是同一套工作流里的不同档位。我总结了一套切换信号，供你参考：

• 需求不清晰 → 用 Vibe 快速验证可能性。
• 核心逻辑稳定、不容出错 → 切 Spec，用契约约束。
• 功能多、并行推进、要透明 → 上 Plan，拆里程碑。
• 模块成熟、开始集成 → 开启 Glue，大量处理接缝。
• 代码回归稳定、准备长期维护 → 常驻 Smell，持续审查。

8. 选型决策与最后叮嘱

8.1 一张决策矩阵帮你快速选范式

最后把选型逻辑浓缩成一张表，方便你拿到新需求时直接对照：

8.2 团队协作里的角色变化

如果你不是一个人单打独斗，而是带着一个小组一起推进，这五种范式还会改变团队内的分工方式。Vibe 和 Glue 可以大量交给初级工程师操作，因为它们的产出需要后续审查和修正，正好是练手和熟悉项目的好机会。Spec 的编写应该由最熟悉业务的人负责，因为规格里每条边界条件背后都是真金白银的业务经验。Plan 和 Smell 则适合全员参与，前者是统一节奏，后者是共同建立质量标准。AI 编程不是让团队变懒，而是让团队里每个人的角色更接近"所有者"而不是"打字员"。

8.3 最后分享几点亲测体会

写到这里，我想再分享几条最真切的感悟。第一条是：不要幻想有一种范式能解决所有问题。我见过有人从头到尾只认 Vibe，结果项目到了集成阶段一团乱麻；也见过有人过于迷信 Spec，在一个快速变化的早期项目上浪费大量时间写文档。范式是工具，不是信仰，切换比坚持更重要。

第二条是：范式之间要留过渡带，不要硬切。从 Vibe 切到 Spec，不是某天突然画一条线说"从今天起 AI 你只能按规格干活"，而是逐步增加约束、逐步补充规格说明，给 AI 一个适应过程，也给自己一个修正规格的机会。

第三条，也是我认为最重要的：不管用哪种范式，最终的代码你都要能看懂。这不是情怀，而是现实——系统总会有出故障的一天，你总会有需要调试的一天，AI 不会替你背这个锅。五种范式的终极目的，从来都是让代码更可控、更可维护、更可理解，而不是用代码量衡量绩效。

这套方法论我从摸索到落地用了将近一年，中间踩过的坑远比我写出来的多。希望这篇整理能帮你少走一些弯路。如果你在实践中有自己的范式组合心得，也欢迎在评论区聊聊，我挺好奇大家在真实项目里怎么组合这五种姿势的。