AI三大编程范式：Vibe、Spec、Agentic对比

AI 时代的三种编程范式：Vibe Coding、Spec Coding 与 Agentic Coding

软件开发的历史，其实就是一部人与机器交流方式不断进化的历史。

从打孔卡到汇编语言，从高级语言到可视化编程，每一次跃迁的目标都很清晰：拉近“人的意图”与“机器执行”之间的距离。到了 2024-2025 年，大语言模型（LLM）的快速成熟，正在催生一场新的范式革命。回顾一下时间线：

• 2022-2023 年：GitHub Copilot 等代码补全工具出现，AI 开始“辅助”编码——帮你补全下一行。
• 2024 年：Cursor、Windsurf 等 AI 原生 IDE 兴起，支持对话式编程——帮你写完一个函数。
• 2025 年：Claude Code、Devin 等 AI Agent 涌现——帮你完成一个完整的开发任务。

这一演进催生了三种新兴的编程范式，它们代表了人与 AI 协作关系的不同层次。理解它们各自的定位和适用场景，是 AI 时代开发者的核心竞争力之一。

这三种范式不是简单的“好 vs 坏”，而是适用于不同场景的工具。

二、Vibe Coding — “跟着感觉走”的编程

2.1 定义与起源

2025 年 2 月 2 日，OpenAI 联合创始人、前 Tesla AI 负责人 Andrej Karpathy 在社交平台上发了一条推文，正式定义了一种新的编程方式。

这条推文迅速引爆了整个技术圈，短短几周内引发了连锁反应：

• 2025 年 3 月：Merriam-Webster（韦氏词典）将 “vibe coding” 收录为“俚语与流行词”。
• 2025 年 3 月：Y Combinator 报告其 2025 冬季批次中，25% 的初创公司代码库有 95% 由 AI 生成。
• 2025 年 7 月：《华尔街日报》报道 Vibe Coding 开始进入商业应用。
• 2025 年 11 月：Collins 词典将 “vibe coding” 评为 2025 年度词汇。
• 2026 年 1 月：连 Linux 之父 Linus Torvalds 也承认用 vibe coding 写了一个 Python 可视化工具。

2.2 核心特征

Vibe Coding 的本质，是将编程从“写代码”转变为“描述意图”，有以下五个显著特征：

1. 自然语言驱动：用日常语言描述需求，而非编写精确代码。关注“感觉”和“体验”，比如“让这个页面看起来更有科技感”。
2. 不审查即接受：开发者不阅读 AI 生成的代码 diff，直接 “Accept All”。正如知名开发者 Simon Willison 所说：“如果 LLM 写了你代码的每一行，但你已经审查、测试并理解了所有内容，那就不叫 vibe coding——那只是把 LLM 当成一个打字助手。”
3. 错误粘贴式修复：遇到报错，直接把错误信息粘贴给 AI，不添加任何分析。
4. 迭代式对话：通过多轮对话逐步细化，但代码也会不断膨胀，直到超出开发者的理解范围。
5. 结果导向：只看运行效果，不关心代码实现质量。

2.3 工作流程

典型流程如下：开发者用自然语言描述需求，AI 生成代码，开发者直接“Accept All”后运行。如果能跑通，那就算完成；如果报错，就把错误复制粘贴给 AI，让它修复后再运行。典型工具包括 Cursor + Claude Sonnet、Replit Agent、Bolt.new、Lovable 等。

2.4 应用场景

2.5 实践示例

示例 1：非程序员创建个人网站
开发者输入需求后，AI 直接生成完整的 HTML/CSS/JS 代码。开发者不需要理解任何一行代码，只需看效果是否满意。满意就用，不满意就继续描述调整。

示例 2：数据分析脚本
开发者输入需求后，AI 生成包含 pandas 数据处理、matplotlib 图表绘制、专业配色方案的完整脚本。

2.6 局限性与风险

Vibe Coding 的便利性背后，隐藏着严重的质量和安全隐患。来自多项研究和真实事故的证据值得警惕：

代码质量问题
CodeRabbit 研究（2025.12）分析了 470 个开源 GitHub PR，发现 AI 辅助生成的代码中，“重大问题”数量是人工代码的 1.7 倍，安全漏洞高 2.74 倍，配置错误多 75%。
GitClear 分析（2025.2）对 2.11 亿行代码变更（2020-2024）的纵向分析显示：代码重构率从 25% 降至不到 10%，代码重复量增长了 4 倍，代码搅动率（过早合并后被重写）几乎翻倍。

安全事故

生产力悖论
METR 组织（2025.7）对经验丰富的开源开发者进行了随机对照试验，结果发现：使用 AI 工具后实际效率下降 19%，但开发者自己预测会快 24%，事后仍认为自己快了 20%。结论很明确：AI 工具给人造成了一种“更快”的错觉。
2025 年 9 月，Fast Company 发文称“Vibe Coding 宿醉”已经来临——高级工程师开始抱怨用 AI 生成代码导致的“开发地狱”。Andrew Ng（吴恩达）也公开表示，“vibe coding”这个名字误导了人们，让人以为软件工程师只是在“凭感觉”做事。

2.7 小结

Vibe Coding 的价值在于极大地降低了编程的门槛，让创意能够快速变为现实。但它更适合一次性的、不需要长期维护的项目，原型验证和概念探索，以及对安全性和质量要求不高的场景。一句话总结：Vibe Coding 是快速原型的利器，但不适合生产环境。

三、Spec Coding — “规格先行”的编程

3.1 定义与起源

如果说 Vibe Coding 是“拍脑袋写需求”，那么 Spec Coding 就是“先想清楚再动手”。

Spec-Driven Development（SDD，规格驱动开发）是 2025 年中期兴起的一种编程范式。它的核心理念是：先写规格说明（Spec），再让 AI 根据 Spec 生成代码。Spec 而非代码，才是核心产物。

这个理念并非凭空出现，而是业界对 Vibe Coding 的反思：AI 生成代码的质量，与输入规范的精确度成正比。给 AI 一句模糊的需求，它给你一堆模糊的代码；给 AI 一份结构化的规格文档，它给你一套结构化的实现。GitHub 和 Tessl 等机构对此都有明确的定义。

3.2 三个层次

Martin Fowler（《重构》作者，ThoughtWorks 首席科学家）在 2025 年 10 月发表了对 SDD 的深度分析，提出了三个递进的层次：

• Spec-first（规格先写）：这是最基础的层次——写一份详细的需求文档给 AI，AI 据此生成代码，任务完成后文档可以丢弃。
• Spec-anchored（规格锚定）：更进一步，Spec 持续保留，功能演进时先修改 Spec 再更新代码。
• Spec-as-source（规格即源码）：这是终极形态——人类只维护 Spec，永远不直接编辑代码，代码完全由 Spec 生成。

目前大多数 SDD 实践处于 Spec-first 层次，少数工具（如 Tessl）在探索 Spec-as-source。

3.3 工作流程

流程很简单：先撰写结构化的需求规格文档（包含用户故事、验收标准、技术约束），然后将 Spec 作为上下文输入给 AI，AI 按照 Spec 生成代码，最后由开发者审查代码是否符合 Spec。如果符合就完成，不符合则完善 Spec 或指导 AI 修正，然后重新生成。

3.4 什么是 Spec？

一个好的 Spec 是一份结构化的、面向行为的、用自然语言撰写的文档，用来表达软件功能并指导 AI 编码。以下是一个实际示例：

以“订单状态管理”功能为例，一份规范的 Spec 会包括：接口定义（POST /api/v1/orders/{orderId}/status，需要 JWT Token 认证）、状态流转规则（pending→paid→shipped→delivered 的完整链路）、业务约束（已发货订单不可取消，取消后 30 分钟内可恢复）、错误处理（400 非法状态流转、404 订单不存在、409 状态冲突）以及非功能需求（接口 P99 延迟小于 200ms，状态变更操作需幂等）。

基于这样一份 Spec，AI 可以生成完整的状态机实现、数据库 schema、API 接口代码、Swagger 文档、覆盖所有状态流转路径的单元测试和审计日志模块。

3.5 代表性工具

目前已经有多个工具在实践 Spec-Driven Development：

Kiro（AWS），最轻量的 SDD 工具，基于 VS Code 构建。工作流分为三个阶段：Requirements（以用户故事 + 验收标准形式撰写需求）、Design（包含组件架构图、数据流、数据模型、错误处理、测试策略等）、Tasks（可追溯到需求编号的任务列表，支持逐个执行和变更审查）。

spec-kit（GitHub），GitHub 推出的 SDD 工具，以 CLI 形式分发，支持多种编码助手。工作流包括 Constitution（定义不可变的高层原则，类似于强力版的 rules 文件）、Specify（撰写详细的需求规格）、Plan（基于规格制定技术方案）、Tasks（从方案分解为可执行的任务）。spec-kit 为每个 Spec 创建大量的 Markdown 文件，是三者中最重量级的。

Tessl Framework（私有测试阶段），唯一明确追求 Spec-as-source 的工具：Spec 和代码文件一一对应，代码文件顶部标注“// GENERATED FROM SPEC - DO NOT EDIT”，通过 tessl build 从 Spec 生成代码，支持 tessl document --code 从现有代码反向工程出 Spec。

3.6 应用场景

3.7 局限性与挑战

Martin Fowler 在实际试用 Kiro、spec-kit、Tessl 之后，提出了一系列尖锐的观察：

杀鸡用牛刀：当 Fowler 用 Kiro 修一个小 bug 时，工具把它变成了 4 个用户故事和 16 条验收标准。结论是：SDD 工具缺乏对不同问题规模的灵活适应能力。

审查 Markdown 比审查代码更累：spec-kit 生成了大量重复的 Markdown 文件，读起来冗长乏味。Fowler 坦言，审查这些文档的体验并不比审查代码轻松。

虚假的掌控感：即使有了模板、清单、工作流，AI 仍然经常不遵循 Spec。Fowler 观察到 Agent 忽略了已有代码的描述，把它们当成新规格重新生成了一遍。他的结论是：不要高估规范对 AI 的约束力。

MDD 的历史教训：Fowler 还指出，Spec-as-source 与历史上的 MDD（模型驱动开发）有惊人的相似之处——当年 MDD 也试图用高层模型生成代码，但最终未能普及，因为“抽象层级尴尬，带来的开销和限制太多”。LLM 消除了 MDD 的部分问题（不再需要固定的 DSL 和定制代码生成器），但也带来了新问题（非确定性）。

3.8 小结

Spec Coding 的价值在于为 AI 编程引入了工程化的纪律——先想清楚再动手。但它目前仍面临“什么规模的问题值得用 SDD”的困境。一句话总结：Spec Coding 是确保 AI 输出质量的最佳实践，但需要找到“刚好够用”的粒度。

四、Agentic Coding — AI 智能体自主开发

4.1 定义与起源

如果对比来看，Vibe Coding 中 AI 是“打字员”，Spec Coding 中 AI 是“规范执行者”，那么 Agentic Coding 中 AI 就是一个初级开发者——它可以自己理解需求、制定计划、编写代码、运行测试、修复 Bug、生成文档，全程自主完成。

AI Agentic Programming（AI 智能体编程）是 2024-2025 年间逐渐成型的编程范式。根据 arXiv 上一篇系统性综述论文（2025.8）的定义，它代表了 AI 从工具到协作者的根本转变。

4.2 从代码补全到自主 Agent 的演进

这一演进路径非常清晰：传统代码补全（2022-2023）时代，GitHub Copilot 等工具被动响应，提供单行或单函数补全；对话式编程（2024）时代，Cursor 等工具支持多轮对话，但开发者仍然主导；到了 Agentic Coding（2025+）时代，Claude Code、Cursor Agent 等工具开始实现 AI 自主规划和执行，开发者转向审查角色。

关键转折点包括：2024 年 3 月 Cognition 发布首个“AI 软件工程师”Devin；2024 年 5 月 SWE-Agent 论文发表，提出多 Agent 协作框架；2025 年 2 月 Claude Code 发布；2025 年 6 月 Karpathy 在 AI Startup School 系统阐述软件开发的范式转变。

4.3 核心能力

Agentic Coding 与传统代码生成的本质区别在于四个关键能力：

自主性（Autonomy）：Agent 可以在无需持续人工监督的情况下，自主决策和行动。开发者设定目标，Agent 自行决定实现路径。

交互性（Interactivity）：Agent 可以与外部工具交互——编译器、调试器、测试框架、Linter、版本控制、构建系统等。

迭代优化（Iterative Refinement）：Agent 不是一次性生成代码，而是在“生成 → 执行 → 检查结果 → 修正”的循环中持续改进。

目标导向（Goal-oriented）：Agent 追求的是高层目标（如“实现用户认证系统”）而非响应单一指令（如“写一个 login 函数”）。它能分解目标为多个子任务，并协调它们的执行顺序。

4.4 技术架构

一个典型的 AI Coding Agent 包含以下核心组件：推理引擎（基于 LLM 如 GPT-5、Claude 4 Opus、Gemini 2.5 Pro、DeepSeek R1 等作为核心大脑）、规划模块（负责任务分解、子任务调度和优先级管理）、记忆系统（包含短期上下文和长期记忆）、执行引擎（负责工具调用、代码执行和反馈收集）。

4.5 代表性工具与系统

4.6 应用场景

4.7 实践示例

以开发用户认证系统为例。开发者只需输入高层目标，Agent 就会自主执行完整的流程：首先分析需求，识别核心模块（用户模型、认证逻辑、Token 管理、限流中间件），制定执行计划；然后进行数据库设计，创建 PostgreSQL schema；接着实现 bcrypt 密码加密、JWT Token 生成与验证等核心模块；完成 API 接口开发；编写并运行单元测试，发现错误自主修复；最后生成完整的 OpenAPI/Swagger 文档、部署指南和环境变量模板。全程开发者只需在最后做审查。

4.8 局限性与挑战

成本：Agent 的迭代执行模式消耗大量 Token。以 Claude 4 Opus 为例，输入 Token 价格 $15/百万，输出 Token 价格 $75/百万，一个复杂任务可能消耗数万到数十万 Token。相比之下，DeepSeek R1 等模型成本低得多，但能力也有差距。

可靠性：Agent 可能走向错误的方向且难以察觉。它可能“自信地”做出错误决策——比如 Replit 的 Agent 在用户明确禁止修改的情况下仍删除了数据库。

工具链适配：现有的编译器、调试器等工具都是为人类设计的。它们提供的错误信息对人类友好，但对 Agent 来说缺乏足够的结构化信息来进行精确推理。

长上下文与记忆：复杂项目可能跨越多个会话，当前 Agent 的跨会话记忆能力仍然有限。不同 Agent 的上下文窗口从 16k 到 128k 不等，持久记忆机制也存在差异。

安全与权限：Agent 拥有执行终端命令、读写文件、访问网络的能力，如果被恶意提示攻击（Prompt Injection），可能执行危险操作。

4.9 小结

Agentic Coding 代表了 AI 编程的最高形态，AI 从“工具”进化为“协作者”。但它目前仍需要人类的最终审查和安全监督。一句话总结：Agentic Coding 让 AI 成为你的初级开发者，但你仍然需要做 Code Review。

五、三种范式对比分析

5.1 核心差异一览

5.2 三者的关系

三种范式不是互相替代，而是互相补充的关系。在质量要求与开发效率的坐标轴上，Vibe Coding 占据极速且简单的区域，Spec Coding 追求高质量且可维护，Agentic Coding 则介于两者之间，兼顾高效与自主。在实际项目中，一个成熟的开发者可能会在不同阶段使用不同的范式。

六、如何选择？实践建议

6.1 场景匹配指南

6.2 渐进式采用路径

在一个完整的项目生命周期中，三种范式可以串联使用：

探索期用 Vibe Coding 快速验证想法可行性；原型验证通过后，用 Spec Coding 规范化需求，编写详细的功能规格、接口定义和状态流转；实现期将 Spec 交给 Agentic Coding 完成自主编码、测试和文档生成；维护期则根据不同情况灵活切换——Bug 修复用 Agentic Coding，新功能用 Spec Coding，小调整用 Vibe Coding。

6.3 不变的原则

无论选择哪种范式，以下原则不可动摇：

1. 代码审查不可省略：AI 生成的代码必须经过人工审查才能合入主干。即使是 Agentic Coding，人类开发者也必须扮演“审查者”角色。
2. 测试覆盖是最后的安全网：确保有足够的自动化测试来验证 AI 生成的代码。
3. AI 是工具，工程判断力仍是核心竞争力：理解架构、掌握最佳实践、做出权衡取舍——这些能力在 AI 时代更重要而非更不重要。
4. 渐进式采纳：不要一步到位全面切换，先在低风险场景试点，积累经验后逐步推广。

七、总结与展望

核心观点

三种编程范式代表了人与 AI 协作的三个层次：Vibe Coding 是“民主化编程”——让每个有想法的人都能把创意变为现实；Spec Coding 是“工程化回归”——在享受 AI 效率的同时保持可控性；Agentic Coding 是“自主化未来”——AI 从工具进化为协作者。它们不是替代关系，而是互补关系，可以在同一个项目中按需切换。

开发者角色的转变

AI 时代，开发者的角色正在从“代码编写者”转变为架构决策者、质量守门人、AI 协作者和领域专家。具体来说，开发者需要设计系统架构、定义技术方案，审查 AI 输出、确保安全和质量，选择合适的范式、编写有效的 Spec、监督 Agent 执行，并将业务知识转化为 AI 可理解的输入。

未来趋势

1. 范式融合：Spec + Agent 的结合可能是最佳实践——用结构化的 Spec 指导自主的 Agent。
2. 多 Agent 协作：前端 Agent + 后端 Agent + 测试 Agent 组成虚拟开发团队。
3. 工具链进化：编译器、调试器将开始为 AI Agent 提供专门的接口。
4. 自适应范式：AI 根据项目特征自动推荐最合适的编程范式。

来源：互联网