适用场景与局限性

Vibe Coding 不是万能药，也不是玩具。清楚地知道它在哪里发光、在哪里失效，是高效使用它的前提。本章从实战角度出发，给出场景分级和局限性的缓解策略。

场景适用性分级

我们将常见开发场景分为四个等级：强烈推荐、谨慎使用、需要特别小心、不适合。

强烈推荐

这些场景是 Vibe Coding 的甜蜜区，效率收益最大，风险最小。

原型与 MVP 验证

快速验证一个想法是否可行，是 Vibe Coding 最典型的用例。一个周末，你可以用它构建一个带用户登录、核心业务流程和基础 UI 的可演示原型。

典型任务：

• 验证 SaaS 产品的核心工作流
• 构建投资人演示用的 demo
• 快速试验新的技术方案是否可行

为什么合适： 原型的目标是"能展示"，不是"能维护"。即便生成的代码后来被全部重写，验证阶段的价值已经实现。

内部工具

供内部团队使用的效率工具（数据看板、内容审核工具、运营报表系统）对安全性和可靠性的要求相对较低，非常适合 Vibe Coding。

示例：

"帮我做一个内部工具，从我们的 PostgreSQL 数据库读取每日用户注册数，
用折线图展示最近 30 天的趋势，支持按渠道筛选。"

一两个小时内，这个工具就可以投入内部使用。

样板代码与脚手架

项目初始化、标准 CRUD API、数据库迁移脚本、配置文件——这些机械重复的工作是 Vibe Coding 最无争议的应用场景。

示例：

• 生成 RESTful API 的标准增删改查接口
• 初始化 Dockerfile 和 docker-compose.yml
• 生成 TypeScript 类型定义（从 JSON Schema 或数据库表结构）
• 编写标准的 ESLint / Prettier 配置

文档站点与静态内容

技术文档、博客、营销页面——内容为主、逻辑简单的站点非常适合 Vibe Coding。即便生成的代码存在小问题，影响也有限。

学习与探索

当你学习一个新框架、探索一个不熟悉的 API，或者想快速理解某个库的用法时，Vibe Coding 是极好的学习加速器。

"用 React Query 帮我写一个从 /api/users 获取数据并展示的组件，
要处理 loading、error 和空数据三种状态。"

生成结果不仅是代码，本身也是一个可运行的学习示例。

谨慎使用

这些场景可以使用 Vibe Coding，但需要搭配额外的审查和测试措施。

Web 应用开发

对于面向外部用户的 Web 应用，Vibe Coding 可以显著提升开发速度，但需要注意：

• 必须审查所有涉及用户输入处理的代码（XSS、CSRF 防护）
• 必须验证所有数据库查询使用了参数化语句
• 推荐搭配 Context Coding 的上下文文件来约束安全规范

API 开发

构建 REST 或 GraphQL API 时，Vibe Coding 在生成路由、控制器、序列化逻辑方面效率极高，但需要：

• 仔细检查认证和授权逻辑
• 验证输入校验是否覆盖了边缘情况
• 确保错误响应不会泄露内部实现细节

数据处理脚本

ETL 流程、数据清洗脚本、报表生成——这类任务逻辑相对独立，Vibe Coding 可以快速生成初版。注意点：

• 在生产数据上运行前，先用样本数据验证
• 留意数据类型转换和边界值处理
• 大数据量场景需要验证性能和内存使用

需要特别小心

这些场景风险较高，如果使用 Vibe Coding，必须配合严格的人工审查和测试。

面向用户的生产系统

任何直接影响用户体验和数据安全的功能，都需要额外谨慎。建议：

• 对 AI 生成的关键路径代码进行逐行审查
• 建立完整的自动化测试套件
• 上线前进行安全扫描（SAST 工具）

支付与金融逻辑

金额计算、退款逻辑、账单生成——这类代码的错误直接造成经济损失，且往往很难被普通测试发现（例如浮点数精度问题）。

推荐做法： 用 Vibe Coding 生成框架结构，核心计算逻辑由有经验的开发者手写并通过严格的边界值测试。

认证与会话管理

登录、注册、密码重置、Token 刷新——这些流程的实现细节直接决定系统的安全性。AI 生成的认证代码可能遗漏时序攻击防护、不安全的 Token 存储等问题。

推荐做法： 优先使用成熟的认证库（如 NextAuth、Passport.js、Auth0），而非让 AI 从头实现。

不适合

对于以下场景，应避免使用 Vibe Coding 作为主要开发方式。

密码学实现

AES、RSA、椭圆曲线加密——这些算法的正确实现需要深厚的密码学知识，一个细小的错误（如 IV 重用、弱随机数生成）可能使整个加密体系形同虚设。

正确做法： 使用经过审计的标准库（OpenSSL、libsodium、Node.js crypto 模块），绝不自行实现加密算法。

高性能底层代码

当你需要优化到 CPU 指令级别，或者为嵌入式系统编写实时控制代码时，AI 无法理解硬件约束和性能权衡，生成的代码往往达不到要求。

安全审计代码

为审计其他系统而编写的工具，必须本身是可信的。用 AI 生成安全检测逻辑，存在"用不可信的工具验证可信性"的逻辑悖论。

关键基础设施核心逻辑

操作系统内核模块、数据库存储引擎、网络协议栈——这些代码的错误会引发级联故障，必须由领域专家精心设计并验证。

适用场景速查表

场景类型	适用等级	关键注意点
原型 / MVP	强烈推荐	无特别限制，专注速度
内部工具	强烈推荐	基础功能验证即可
样板代码 / 脚手架	强烈推荐	按需定制生成结果
文档站点	强烈推荐	无特别限制
学习探索	强烈推荐	理解生成结果，不盲目复制
Web 应用	谨慎使用	审查输入处理和 XSS 防护
REST API	谨慎使用	检查认证授权逻辑
数据处理	谨慎使用	样本数据验证，边界值测试
面向用户的生产功能	需要特别小心	逐行审查 + 自动化测试
支付 / 金融逻辑	需要特别小心	核心计算手写 + 严格测试
认证 / 会话管理	需要特别小心	优先用成熟库，不从零实现
密码学实现	不适合	使用标准库，拒绝 AI 实现
高性能底层代码	不适合	需要专业手写和 profiling
安全审计工具	不适合	必须是可信的人工实现
关键基础设施核心	不适合	领域专家精心设计

核心局限性与缓解策略

局限性一：幻觉（Hallucinations）

表现： AI 自信地生成看起来合理但实际上错误的代码——不存在的 API 方法、错误的函数签名、过时的库用法。

风险等级： 高（尤其在使用不熟悉的框架时）

缓解策略：

1. 即时运行验证：每次生成后立即运行代码，不要积累大量未验证的生成结果
2. 维护上下文文件：在 CLAUDE.md 中列出项目使用的库版本，减少 AI 使用过时 API 的概率
3. 对不熟悉的 API 进行人工核查：生成代码中引用了你不认识的方法时，查阅官方文档确认其存在

# CLAUDE.md 中的版本声明示例
## 依赖版本（请严格遵循，不要使用其他版本的 API）
- React: 19.x（使用新的 use() hook，不要用旧的 useEffect 数据获取模式）
- Next.js: 15.x（使用 App Router，不要使用 Pages Router）
- Prisma: 6.x（使用 prisma.findFirst，不要使用已废弃的 findUnique 别名）

局限性二：安全盲点（Security Blind Spots）

表现： AI 在生成代码时不会主动提示安全风险，除非你明确要求。常见问题包括：SQL 注入、XSS、不安全的直接对象引用（IDOR）、硬编码密钥。

风险等级： 严重（可能导致数据泄露或系统被攻破）

缓解策略：

1. 安全规范写入上下文文件：

# CLAUDE.md 安全规范
## 强制要求
- 所有数据库查询必须使用 ORM 或参数化查询，禁止字符串拼接 SQL
- 用户输入在渲染前必须进行 HTML 转义（使用 DOMPurify 或框架内置机制）
- 密钥和凭证只能从环境变量读取，禁止硬编码
- 对象 ID 访问必须验证当前用户是否有权限（检查 userId 归属）

2. 生成后安全审查：对每个涉及用户输入或数据库操作的功能，进行针对性的安全检查
3. 使用 SAST 工具：集成 Semgrep、SonarQube 等静态分析工具到 CI 流程

局限性三：上下文窗口限制（Context Limits）

表现： 在大型项目中，AI 无法同时"看到"整个代码库。随着对话历史积累，早期的设计决策可能被遗忘，导致生成的代码与已有代码不一致。

风险等级： 中（主要影响代码一致性和可维护性）

缓解策略：

1. 模块化开发：将任务拆解为独立的小模块，每个模块在独立的会话中处理
2. 维护活文档：用 CLAUDE.md 记录核心架构决策，每次新会话时作为上下文注入
3. 定期重置会话：当对话历史过长时，开启新会话并重新提供关键上下文，而不是在一个越来越长的对话中继续

# 新会话开始时的标准上下文提示模板
请先阅读以下文件了解项目背景：
- CLAUDE.md（架构规范和约束）
- src/lib/auth.ts（认证模块）
- docs/spec/[当前功能规格].md

然后我们继续实现[具体功能]...

局限性四：过度自信（Overconfidence）

表现： AI 在生成错误解决方案时，语气与生成正确方案时完全一样自信。这导致开发者难以判断何时需要质疑 AI 的输出。

风险等级： 中至高（取决于开发者的判断力）

缓解策略：

1. 建立验证文化：无论 AI 表现得多么确定，关键逻辑都要运行测试验证
2. 主动追问：对 AI 的生成结果提出"这里有什么潜在问题吗？"、"你确定这个方法在当前版本中存在吗？"
3. 小步前进：避免让 AI 一次生成大量代码，分小步生成并逐步验证，错误发现得越早，代价越小

局限性总结表

局限性	主要表现	缓解优先级	核心缓解措施
幻觉	API 不存在、逻辑错误	高	即时运行验证 + 版本声明
安全盲点	注入漏洞、硬编码密钥	严重	安全规范写入上下文 + SAST 扫描
上下文限制	代码不一致、遗忘决策	中	模块化 + 活文档 + 定期重置
过度自信	错误输出难以识别	中高	主动质疑 + 小步验证文化

结语

Vibe Coding 的适用边界，本质上是风险与效率的权衡。在低风险、高重复、需要快速验证的场景中，它是毋庸置疑的效率利器。在高风险、高复杂度、安全关键的场景中，它需要被工程纪律约束，或者直接让位给传统开发方式。

掌握这套场景判断框架，比掌握任何单一工具都更有价值。