Claude Code 精通指南 第10篇：Vibe Coding 哲学

你已经学会了工具。命令、技能、子代理、MCP 服务器、无头自动化——你知道 Claude Code 怎么用了。但知道工具和真正融会贯通，完全是两回事。

这最后一章讲的是思维方式。让你从一个称职的 Claude Code 用户，变成一个开发速度完全不在同一量级的人。

什么是 Vibe Coding？

这个概念源自 Andrej Karpathy 2025 年 2 月的一条爆款推文：

"有一种新的编程方式，我称之为 'vibe coding'——你完全跟随感觉走，拥抱指数级增长，忘掉代码的存在。这成为可能是因为 LLM 已经太强了。"

他描述了自己的工作流：不看 diff 直接接受所有更改，不加任何评论地复制粘贴错误信息，让 AI 做一些"把侧边栏的内边距减半"之类简单到懒得自己找的事情。

然后他加了关键的一句："用在一次性的周末项目上还不错，挺好玩的。"

这个补充很重要。Vibe coding 不是一种万能方法——它是一种在特定场景下才合适的工作模式。

AI 辅助开发的光谱

Simon Willison 说得好："并非所有 AI 辅助编程都是 vibe coding。"

这是一个光谱：

纯 Vibe Coding — 全盘接受，不看 diff，复制粘贴错误，让 AI 自己搞定。适合周末 hack 和一次性原型。

引导式 AI 开发 — 你指挥，Claude 实现，你审查。这是本系列一直在介绍的方法。

AI 增强工程 — 传统的工程规范加上 AI 加速。设计文档、代码审查、测试、安全审计——一样都不少，只是更快了。

大多数专业工作都在中间地带。一头的纯 vibe coding 对实验以外的东西风险太大。另一头的纯手工编码则意味着白白浪费速度优势。

关键技能在于：知道对任何给定任务，你应该处在光谱的哪个位置。

何时 Vibe

Vibe coding 在以下情况有效：

• 是原型 — 你在探索想法，不是交付给用户
• 可以扔掉 — 不行就从头来
• 安全不重要 — 没有真实用户数据，没有生产凭证
• 只有你用 — 没人依赖这段代码
• 速度比质量更重要 — 你在验证概念，不是构建基础设施

适合 vibe 的任务示例：

"给我快速搭一个仪表板来可视化这个 CSV 数据"
"做一个 Chrome 扩展实现 X 功能"
"原型化这个功能想法，好让我展示给利益相关者看"

何时不要 Vibe

以下情况请从 vibe 模式退出：

• 涉及安全 — 认证、支付、用户数据。这些代码必须审查。
• 别人依赖它 — 团队成员、用户、生产系统
• 涉及资金 — API 费用、计费、财务计算
• 难以撤回 — 数据库迁移、破坏性操作
• 需要长期维护 — 未来几个月甚至几年都要维护的代码

在这些场景下，切换到引导式 AI 开发：Claude 实现，你审查每一处更改，你理解发生了什么。

指挥家思维

即使不是完全的 vibe coding，核心洞察依然适用：你是指挥家，不是演奏者。

传统编码：你写每一行。

AI 辅助编码：你指挥乐队。Claude 负责演奏技巧，你决定演奏什么曲子。

你："我们需要认证功能"
         ↓
你的工作：构建什么、为什么、约束条件
         ↓
Claude 的工作：如何实现
         ↓
你的工作：验证是否正确

这种转变正是为什么规划变得更重要而不是更不重要。没有清晰的方向，Claude 会做出看似合理但不符合你架构的决定。

悖论：需要更多规划

让很多人惊讶的是：AI 辅助开发需要更多前期规划，而不是更少。

没有规划的话，Claude 会：

• 在不同文件中创建不一致的模式
• 遗漏你没有说明的架构约束
• 重复已有的功能
• 做出难以逆转的决策

好的规划是什么样的

我要构建一个仪表板功能。以下是计划：

架构：
- 页面使用 Server Component
- 交互图表使用 Client Component
- 数据获取用 React Query
- 可视化用 Recharts

约束：
- 必须适配移动端
- 数据每 30 秒刷新
- 遵循 src/components/ 中现有的组件模式

任务（按顺序）：
1. 创建 DashboardPage server component
2. 构建 StatsCards client component
3. 用 Recharts 添加图表
4. 实现刷新逻辑

从任务 1 开始。

Claude 的实现能力极强。它在架构层面的战略决策上则稍逊。发挥各自优势：你做架构，Claude 做实现。

有效指挥

令人沮丧的 AI 会话和高效的之间的区别，往往在于你怎么给指令。

太模糊：

"给我做个仪表板"

没有约束，没有架构，没有模式。注定得到不符合预期的输出。

太细致：

"创建一个函数。命名为 handleSubmit。它接收一个 event 参数。
首先调用 preventDefault。然后获取表单数据..."

你这是在多加了一步来写代码。让 Claude 去写吧。

刚刚好：

"在管理员区域添加一个显示用户统计的仪表板。
使用 src/components/ui/ 中现有的卡片组件模式。
包括：总用户数、本周注册数、活跃会话数。
数据来自 /api/stats 端点。"

目标明确，约束清晰，给 Claude 留出发挥空间。

信任但验证

Karpathy 能 vibe code 是因为他能立刻看到代码是否工作，不行就扔掉。对于原型之外的任何东西，都要加上验证环节。

对于实现：

"实现这个功能，然后解释你做出的关键决策"

迫使 Claude 表达推理过程。尽早发现不一致。

对于安全敏感代码：

"实现这个，但标记出任何我应该审查的安全考虑"

让 Claude 成为你的第一道安全审查防线。

对于复杂逻辑：

"实现之前，用 2-3 句话解释你的方案"

在坏方案变成坏代码之前把它拦住。

迭代思维

Vibe coding 本质上是迭代的。第一轮不会完美。没关系。

"能用了，但错误消息太笼统。让它们更有帮助。"

"好的，现在加上加载状态。"

"移动端布局坏了，修一下。"

快速迭代胜过完美的第一次。Claude 既便宜又快。用好这一点。

反模式

从不验证者

❌ *不看代码直接发布 Claude 的输出*

对生产环境进行纯 vibe coding。这就是你得到安全漏洞和边界情况 Bug 的方式。

微管理者

❌ "创建一个函数。叫做 handleSubmit。它接收一个 event 参数..."

你这是在多绕一步写代码。要么信任 Claude 来实现，要么自己写。

上下文囤积者

❌ *从不用 /clear，保留 50 条消息的上下文*

过时的上下文会降低输出质量。经常清理，尤其是任务之间。

模糊梦想家

❌ "给我做个 Twitter"

目标太大，没有约束，没有架构。你会得到某个东西，但不是你想要的。

找到你的 Flow

从 Claude Code 中获益最多的开发者都有一些共同模式：

他们经常清理。 每个任务都用全新上下文。参见第2篇。

他们先做规划。 实现之前先做架构决策。参见第3篇。

他们用命令处理重复工作。 编码化的工作流，而不是重复的提示。参见第4篇。

他们验证安全性。 始终手动审查认证、支付、数据处理。

他们快速迭代。 快速反馈循环，小幅调整，而不是追求完美的第一次。

他们知道何时退一步看全局。 当 Claude 在打转时，他们会补充上下文或使用 ultrathink。

速度思维

一旦你内化了指挥家的角色，某种转变就发生了。你开始从构建什么的角度思考，而不是怎么构建。

一个经验丰富的 vibe coder 可能这样想：

"我需要一个导出用户数据的功能"
→ "CSV 和 JSON 格式"
→ "使用报告中现有的导出模式"
→ "加到用户设置里"

然后准确地告诉 Claude 就是这些。实现变成了细节——重要，但不是你认知负荷的主要消耗。

这就是生产力的突破口。不是因为 Claude 替你写代码，而是你可以在更高的抽象层面上操作，同时仍然交付可工作的软件。

系列完结

你现在已经掌握了完整的 Claude Code 工具包：

1. 入门指南 — 安装、首次命令、思维方式
2. 心智模型 — Claude 如何思考、上下文管理
3. 项目配置 — CLAUDE.md 和设置
4. 自定义命令 — 工作流斜杠命令
5. 技能 — 自动加载的知识模块
6. 子代理 — 并行专业工作者
7. MCP 服务器 — 外部服务集成
8. 生产工作流 — GitHub Actions、团队模式
9. 高手秘籍 — ultrathink、无头模式、隐藏功能
10. Vibe Coding 哲学 — 将一切串联起来的思维方式

工具只是工具。真正的差距在于思维方式——知道何时 vibe、何时验证、何时规划、何时放手让 Claude 跑。

现在，去构建些东西吧。