一、引言：编程范式的演进

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

从打孔卡到汇编语言，从高级语言到可视化编程，每一次跃迁都在降低"人的意图"与"机器执行"之间的鸿沟。而 2024-2025 年间，大语言模型（LLM）的快速成熟，正在催生一场新的范式革命：

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

这一演进催生了三种新兴的编程范式，它们代表了人与 AI 协作关系的不同层次：

范式	人的角色	AI 的角色	一句话概括
Vibe Coding	需求描述者	代码生成器	"我说你写，能跑就行"
Spec Coding	规格撰写者	规范执行者	"按我写的规格来，严格实现"
Agentic Coding	目标设定者	自主开发者	"我定目标，你自己想办法搞定"

这三种范式不是简单的"好 vs 坏"，而是适用于不同场景的工具。理解它们的差异，在实际工作中做出正确选择，是 AI 时代开发者的核心竞争力之一。

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

2.1 定义与起源

2025 年 2 月 2 日，OpenAI 联合创始人、前 Tesla AI 负责人 Andrej Karpathy 在 X（原 Twitter）上发了一条推文，定义了一种新的编程方式：

"There's a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. I 'Accept All' always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. It's not really coding — I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."

这条推文迅速引爆了整个技术圈。短短几周内：

• 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 所说："If an LLM wrote every line of your code, but you've reviewed, tested, and understood it all, that's not vibe coding — that's using an LLM as a typing assistant."
3. 错误粘贴式修复：遇到报错，直接把错误信息粘贴给 AI，不添加任何分析
4. 迭代式对话：通过多轮对话逐步细化，代码不断膨胀超出开发者的理解范围
5. 结果导向：只看运行效果，不关心代码实现质量

2.3 工作流程

开发者用自然语言描述需求
 ↓
 AI 生成代码
 ↓
 开发者 "Accept All"
 ↓
 运行代码
 ↙ ↘
 能跑通 报错
 ↓ ↓
 完成! 复制粘贴错误给 AI
 ↓
 AI 修复 → 再运行...

典型工具：Cursor + Claude Sonnet、Replit Agent、Bolt.new、Lovable

2.4 应用场景

场景	说明	典型案例
快速原型验证	几小时内从想法到可运行的 Demo	Karpathy 原话："not too bad for throwaway weekend projects"
个人项目 / Side Project	"Software for One"——只给自己用的软件	纽约时报记者 Kevin Roose 用 AI 制作的个人应用
初创公司 MVP	快速验证市场假设	YC 2025 冬季批次 25% 公司 95% 代码由 AI 生成
内部工具 / 一次性脚本	写完用完即丢的工具	数据清洗、一次性报表等
UI/UX 设计实现	将视觉概念快速转化为前端代码	"给我一个深色背景、霓虹蓝发光效果的登录页"
学习探索	快速了解新技术或框架	"用 React 帮我写一个 TodoList"

2.5 实践示例

示例 1：非程序员创建个人网站

开发者输入：

"帮我创建一个登录页面，要有未来科技感，深色背景，霓虹蓝的发光效果，简洁的表单设计，带有一些粒子动画效果。"

AI 直接生成完整的 HTML/CSS/JS 代码，开发者不需要理解任何一行代码，只需看效果是否满意。满意就用，不满意就继续描述调整。

示例 2：数据分析脚本

开发者输入：

"写一个 Python 脚本，读取 sales.csv，计算每个产品的总销售额和平均单价，画一个柱状图展示 top 10 产品，风格要专业商务。"

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 倍
• 代码搅动率（过早合并后被重写）几乎 翻倍

安全事故

时间	事件	影响
2025.5	Lovable（瑞典 vibe coding 平台）被曝安全漏洞	170/1645 个应用的个人信息可被任何人访问
2025.7	Replit AI Agent 删除用户生产数据库	用户明确指示不要做任何修改，Agent 仍删除了数据库并伪造数据
2025.10	VeraCode 研究报告	3 年来 LLM 生成代码功能性大幅提升，但安全性几乎没有改善
2026.2	Orchids vibe coding 平台安全漏洞	BBC 记者演示被黑客攻击

生产力悖论

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 对此的定义是：

"In this new world, maintaining software means evolving specifications. The lingua franca of development moves to a higher level, and code is the last-mile approach."

Tessl 对此的定义是：

"A development approach where specs — not code — are the primary artifact. Specs describe intent in structured, testable language, and agents generate code to match them."

3.2 三个层次

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

┌─────────────────────────────────────────────────────┐
│ Spec-as-source（规格即源码）                          │
│ 只维护 Spec，人不直接编辑代码                          │
│ 代码标记 "// GENERATED FROM SPEC - DO NOT EDIT"       │
├─────────────────────────────────────────────────────┤
│ Spec-anchored（规格锚定）                             │
│ Spec 持续保留，作为功能演进和维护的参照                 │
│ 功能变更时先改 Spec 再改代码                          │
├─────────────────────────────────────────────────────┤
│ Spec-first（规格先写）                                │
│ 先写 Spec 指导 AI 生成代码                             │
│ 完成后 Spec 可以丢弃（类似传统 PRD）                   │
└─────────────────────────────────────────────────────┘

• 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 编码。以下是一个实际示例：

## 功能：订单状态管理

### 接口定义
- POST /api/v1/orders/{orderId}/status
- 认证：需要 JWT Token

### 状态流转规则
1. pending → paid：支付成功后自动流转
2. paid → shipped：管理员手动触发
3. shipped → delivered：物流回调触发
4. 任意状态 → cancelled：用户取消或超时

### 业务约束
- 已发货订单不可取消
- 取消后 30 分钟内可恢复
- 状态变更需记录审计日志

### 错误处理
- 400：非法状态流转
- 404：订单不存在
- 409：状态冲突（并发操作）

### 非功能需求
- 接口 P99 延迟 < 200ms
- 状态变更操作需幂等

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

3.5 代表性工具

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

Kiro（AWS）

最轻量的 SDD 工具，基于 VS Code 构建。

工作流：Requirements → Design → Tasks

• Requirements：以用户故事（"As a..."）+ 验收标准（"GIVEN... WHEN... THEN..."）的形式撰写需求
• Design：包含组件架构图、数据流、数据模型、错误处理、测试策略等
• Tasks：可追溯到需求编号的任务列表，支持逐个执行和变更审查

spec-kit（GitHub）

GitHub 推出的 SDD 工具，以 CLI 形式分发，支持多种编码助手。

工作流：Constitution → Specify → Plan → Tasks

• Constitution（章程）：定义不可变的高层原则，类似于强力版的 rules 文件
• Specify：撰写详细的需求规格
• Plan：基于规格制定技术方案
• Tasks：从方案分解为可执行的任务

spec-kit 为每个 Spec 创建了大量的 Markdown 文件（spec、plan、tasks、research、api、component 等），是三者中最重量级的。

Tessl Framework（私有测试阶段）

唯一明确追求 Spec-as-source 的工具：

• Spec 和代码文件一一对应
• 代码文件顶部标注 // GENERATED FROM SPEC - DO NOT EDIT
• 通过 tessl build 从 Spec 生成代码
• 支持 tessl document --code 从现有代码反向工程出 Spec

3.6 应用场景

场景	说明
企业级应用开发	需要严格遵守业务规则；涉及合规性和审计要求
中大型功能开发	需求明确、多人协作的正式项目
复杂系统集成	多系统接口对接，需要精确的数据流转定义
关键基础设施	核心交易系统、安全敏感模块
团队知识传递	Spec 文档本身就是需求文档，方便新成员理解

3.7 局限性与挑战

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

杀鸡用牛刀

当 Fowler 用 Kiro 修一个小 bug 时，工具把它变成了 4 个用户故事和 16 条验收标准，其中包括这样的"宝石"：

"User story: As a developer, I want the transformation function to handle edge cases gracefully, so that the system remains robust when new category formats are introduced."

Fowler 的结论：SDD 工具缺乏对不同问题规模的灵活适应能力。

审查 Markdown 比审查代码更累

spec-kit 生成了大量重复的 Markdown 文件，读起来冗长乏味。Fowler 坦言：

"To be honest, I'd rather review code than all these markdown files."

虚假的掌控感

即使有了模板、清单、工作流，AI 仍然经常不遵循 Spec。Fowler 观察到 Agent 忽略了已有代码的描述，把它们当成新规格重新生成了一遍。他的结论：

"The past has shown that the best way for us to stay in control of what we're building are small, iterative steps, so I'm very skeptical that lots of up-front spec design is a good idea."

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 agentic programming is an emerging paradigm in which large language models autonomously plan, execute, and interact with external tools like compilers, debuggers, and version control systems to iteratively perform complex software development tasks."

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

传统代码补全（2022-2023）
 GitHub Copilot / TabNine
 ↓ 被动响应，单行/单函数补全

对话式编程（2024）
 Cursor / Windsurf
 ↓ 多轮对话，开发者主导

Agentic Coding（2025+）
 Claude Code / Cursor Agent / SWE-Agent
 ↓ AI 自主规划和执行，开发者审查

这一演进的关键转折点：

• 2024.3：Cognition 发布 Devin，首个"AI 软件工程师"，展示了从需求到部署的端到端能力
• 2024.5：SWE-Agent 论文发表，提出多 Agent 协作解决 GitHub Issues 的框架
• 2025.2：Claude Code 发布，Anthropic 推出命令行 AI Agent
• 2025.6：Karpathy 在 AI Startup School 发表演讲 "Software Is Changing (Again)"，系统阐述软件开发的范式转变

4.3 核心能力

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

1. 自主性（Autonomy）

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

2. 交互性（Interactivity）

Agent 可以与外部工具交互：编译器（gcc/javac）、调试器（gdb/pdb）、测试框架（pytest/JUnit）、Linter（ESLint/flake8）、版本控制（Git）、构建系统（Maven/npm）等。

3. 迭代优化（Iterative Refinement）

Agent 不是一次性生成代码，而是在"生成 → 执行 → 检查结果 → 修正"的循环中持续改进：

接收任务目标
 ↓
分解为子任务 ←───────────┐
 ↓                         │
生成代码 / 执行操作         │
 ↓                         │
运行测试 / 编译 / Lint     │
 ↓                         │
 通过？                     │
 ↙ ↘                       │
 是 否 → 分析错误 → 修正代码
 ↓
完成!

4. 目标导向（Goal-oriented）

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

4.4 技术架构

一个典型的 AI Coding Agent 包含以下核心组件：

┌──────────────────────────────────────────────┐
│           AI Coding Agent                    │
│                                              │
│  ┌──────────┐ ┌───────────┐ ┌──────────┐    │
│  │ 推理引擎 │ │ 规划模块  │ │ 记忆系统 │    │
│  │ (LLM)    │ │ (任务分解)│ │ (上下文) │    │
│  └────┬─────┘ └─────┬─────┘ └─────┬────┘    │
│       │             │             │         │
│       └──────────┬──┴─────────────┘         │
│                  ↓                          │
│            ┌──────────────┐                 │
│            │ 执行引擎     │                 │
│            │ (工具调用)   │                 │
│            └──────┬───────┘                 │
└───────────────────┼──────────────────────────┘
                    ↓
        ┌─────────────────────────────┐
        │        外部工具环境          │
        │                              │
        │ 编译器 │ 调试器 │ 测试框架   │
        │ Git    │ Linter │ 浏览器     │
        │ 终端   │ 文件系统│ 数据库     │
        └─────────────────────────────┘

• 推理引擎：GPT-5、Claude 4 Opus、Gemini 2.5 Pro、DeepSeek R1 等 LLM 作为核心大脑
• 规划模块：任务分解、子任务调度、优先级管理
• 记忆系统：短期上下文（当前任务状态）+ 长期记忆（向量数据库/结构化存储）
• 执行引擎：调用外部工具、执行代码、收集反馈

4.5 代表性工具与系统

工具	开发者	类型	特点
Claude Code	Anthropic	命令行 Agent	自主完成端到端开发，深度集成终端和文件系统
Cursor Agent Mode	Cursor	IDE 内置 Agent	在编辑器中自主执行多步任务
GitHub Copilot Agent	GitHub/MS	IDE 插件 Agent	从代码补全进化到任务自主执行
Google Jules	Google	异步 Agent	后台异步处理开发任务
Devin	Cognition	独立 Agent	首个"AI 软件工程师"，端到端全流程
SWE-Agent	Princeton	多 Agent 研究	自动解决 GitHub Issues
ChatDev / MetaGPT	开源	多 Agent 协作	模拟软件开发团队：产品经理 + 架构师 + 开发 + 测试

4.6 应用场景

场景	Agent 工作方式
Bug 修复	读取 Issue 描述 → 定位相关代码 → 分析根因 → 编写修复 → 生成测试 → 提交 PR
端到端功能开发	分析需求 → 设计方案 → 编写代码 → 运行测试 → 生成文档
代码重构	分析现有代码 → 制定重构计划 → 逐步执行 → 回归测试
代码迁移	理解源代码 → 转换到目标框架/语言 → 验证等价性
测试生成	分析被测代码 → 识别边界条件 → 生成测试用例 → 验证覆盖率

4.7 实践示例

示例：使用 Agent 开发用户认证系统

开发者输入：

"帮我开发一个完整的用户认证系统，包括注册、登录、密码重置、JWT Token 管理。使用 Node.js + Express + PostgreSQL，密码需要加密存储，API 需要限流保护。"

Agent 自主执行流程：

Step 1 — 需求分析与规划

Agent 分析需求，识别核心模块（用户模型、认证逻辑、Token 管理、限流中间件），制定执行计划。

Step 2 — 数据库设计

创建 PostgreSQL schema：用户表（含密码哈希、邮箱验证状态）、Token 黑名单表。

Step 3 — 核心模块实现

实现 bcrypt 密码加密、JWT Token 生成与验证、邮箱验证逻辑、基于 Redis 的限流中间件。

Step 4 — API 接口开发

实现 POST /auth/register、/auth/login、/auth/logout、/auth/refresh、/auth/forgot-password、/auth/reset-password。

Step 5 — 测试与验证

编写并运行单元测试，验证所有 API 响应，发现 bcrypt 未安装则自动添加依赖，测试失败则自主修复代码。

Step 6 — 文档输出

生成 OpenAPI/Swagger 文档、部署指南、环境变量模板。

全程 Agent 自主处理异常——缺少依赖自动安装，测试失败自动修复，整个过程开发者只需在最后做审查。

4.8 局限性与挑战

成本

Agent 的迭代执行模式消耗大量 Token。以 Claude 4 Opus 为例：

项目	价格
输入 Token	$15 / 百万 Token
输出 Token	$75 / 百万 Token
一个复杂任务可能消耗	数万~数十万 Token

相比之下，DeepSeek R1（$0.55/$2.19）和 Kimi K2（$0.15/$2.50）等模型成本低得多，但能力也有差距。

可靠性

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

工具链适配

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

长上下文与记忆

复杂项目可能跨越多个会话，当前 Agent 的跨会话记忆能力仍然有限：

Agent	上下文窗口	持久记忆	记忆机制
GitHub Copilot	16k	否	滑动窗口
Cursor IDE	128k	是	项目历史语义搜索
SWE-Agent	16k	是	向量数据库检索
OpenDevin	32k	是	RAG + 命令历史

安全与权限

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

4.9 小结

Agentic Coding 代表了 AI 编程的最高形态，AI 从"工具"进化为"协作者"。但它目前仍需要人类的最终审查和安全监督。

一句话总结：Agentic Coding 让 AI 成为你的初级开发者，但你仍然需要做 Code Review。

五、三种范式对比分析

5.1 核心差异一览

维度	Vibe Coding	Spec Coding	Agentic Coding
核心理念	感觉驱动，快速出结果	规格先行，文档驱动	智能体自主，闭环执行
人的角色	需求描述者 + 效果验证者	规格撰写者 + 代码审查者	目标设定者 + 最终审查者
AI 的角色	代码生成器	按规格实现者	自主开发者
代码理解要求	不需要理解	需要审查代码是否符合 Spec	需要最终审查
输入精度	模糊的自然语言	结构化的规格文档	高层目标描述
适用规模	小型 / 原型	中大型 / 正式项目	中大型 / 复杂任务
代码质量	低-中	中-高	中-高
开发速度	极快（分钟级）	中等（小时-天级）	快（小时级）
可维护性	低	高	中
学习曲线	极低	中等	中等
典型工具	Cursor / Replit / Bolt	Kiro / spec-kit / Tessl	Claude Code / Cursor Agent / SWE-Agent
典型用户	非程序员 / 快速原型	有经验的工程师团队	有经验的工程师
最大风险	安全漏洞、不可维护	过度工程、流程繁琐	失控执行、成本高昂

5.2 三者的关系

三种范式不是互相替代，而是互相补充的关系：

  质量要求 ↑
  │
  │        ┌──────────┐
  │        │Spec Coding│ ← 高质量 + 可维护
  │        └──────────┘
  │
  │   ┌───────────────┐
  │   │Agentic Coding │ ← 高效 + 自主
  │   └───────────────┘
  │
  │ ┌────────────┐
  │ │Vibe Coding │ ← 极速 + 简单
  │ └────────────┘
  │
  └───────────────────→ 开发效率

在实际项目中，一个成熟的开发者可能会在不同阶段使用不同的范式。

六、如何选择？实践建议

6.1 场景匹配指南

你的场景	推荐范式	理由
周末 Side Project	Vibe Coding	快速出结果，不需要长期维护
给老板看的 Demo	Vibe Coding	速度第一，演示即可
正式项目的新功能	Spec Coding	需求明确，质量有保障
团队协作的核心模块	Spec Coding	Spec 文档本身就是需求文档
修一个复杂 Bug	Agentic Coding	Agent 擅长定位 + 分析 + 修复
大规模代码重构	Agentic Coding	Agent 能自主执行多步操作
技术方案调研	Agentic Coding	Agent 能自动收集资料并验证
需要合规审计的系统	Spec Coding	Spec 提供完整的可追溯性

6.2 渐进式采用路径

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

Phase 1: 探索期
 └─ 用 Vibe Coding 快速验证想法可行性
 "帮我用 React 搭一个 Dashboard 原型"

Phase 2: 规范期
 └─ 原型验证通过后，用 Spec Coding 规范化需求
 编写详细的功能规格、接口定义、状态流转

Phase 3: 实现期
 └─ 将 Spec 交给 Agentic Coding 完成实现
 Agent 按 Spec 自主编码、测试、生成文档

Phase 4: 维护期
 └─ Bug 修复用 Agentic Coding（Agent 自主定位修复）
 └─ 新功能用 Spec Coding（先更新 Spec 再实现）
 └─ 小调整用 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 根据项目特征自动推荐最合适的编程范式

对于开发者而言，理解这三种范式并根据场景灵活选择，将是 AI 时代核心竞争力的重要组成部分。