来源：https://github.com/datawhalechina/vibe-vibe

阅读完本节后，你将会收获：

• 掌握 VibeCoding 标准五步工作流：探索 → 规划 → 执行 → 验证 → 提交
• 理解 Agent Native 开发思维，学会从"怎么做"转向"做什么"的产品导向思维
• 学会编写高质量提示词：直接描述任务、提供上下文、给出具体约束
• 掌握权限模式、斜杠命令、检查点功能等 Claude Code 核心交互方式
• 了解多 Agent 并行协作机制，学会利用 AI 自动化能力提升开发效率

序言中提到的"Workflow（工具流）"是 Vibecoding 的核心，以及 VibeCoding 的标准开发流程。

前置知识

graph TB
    A[Agent Native] --> B["意图驱动：告诉 AI '做什么'"]
    A --> C["异步协作：AI 持续工作"]
    A --> D["信任但验证：快速验证机制"]

B --> E["不要管 '怎么做'"]
C --> F["设定目标后可离线"]
D --&gt; G["默认信任，发现问题再修正"]</code></pre>

❌ 传统思维：
"帮我写一个函数，接收数组参数，用 for 循环遍历，
遇到大于 10 的就 push 到新数组里..."

# 你设定目标，AI 自主执行
"实现用户评论功能，包括：
1. 数据库 schema（Comment 模型）
2. CRUD API
3. 前端评论表单
4. 评论列表展示

graph LR
    A[AI 生成] --> B{功能正常?}
    B -->|是| C[接受]
    B -->|否| D[告诉 AI 问题]
    D --> A

graph TD
    A[传统开发者] --> B[亲自动手]
    B --> C[写每一行代码]
    C --> D[调试每个 Bug]

E[Agent Native] --> F[编排 Agent]
F --> G[定义目标]
G --&gt; H[验证结果]</code></pre>

核心概念

Vibecoding 的核心理念

Vibecoding = Prompt（提示词） + Workflow（工具流）

Prompt 告诉 AI 做什么
Workflow 决定怎么做

graph TB
    A[任务] --> B["Prompt: 需求描述"]
    B --> C["Workflow: 执行流程"]

    C --> D[探索项目结构]
    C --> E[规划实现步骤]
    C --> F[编写代码]
    C --> G[测试验证]
    C --> H[提交代码]

    D --> I[高质量输出]
    E --> I
    F --> I
    G --> I
    H --> I

提示词的核心原则

AI 是一个强大的编程助手，它理解技术术语、熟悉各种框架、能快速分析代码。

沟通的关键是：直接、具体、有上下文。

❌ 绕弯子：

"你是一位资深的全栈工程师，精通各种技术栈..."

→ AI 不需要角色扮演，它知道自己能做什么

✅ 直接说事：

"检测这个 React 组件的类型安全问题"

→ 一句话讲清楚要做什么

❌ 模糊描述：

"帮我优化一下代码"

→ AI 不知道优化什么方向

✅ 具体需求：

"优化登录页面的加载性能：
1. 添加图片懒加载
2. 延迟加载非关键资源
3. 使用 Next.js 的动态导入"

→ 明确优化目标和实现方式

提示词原则

好提示词的特征

graph TB
    A[好提示词] --> B["明确任务上下文"]
    A --> C["具体输出要求"]
    A --> D[提供出口]

    B --> E["不要让 AI 猜"]
    C --> F["不要含糊其辞"]
    D --> G["不要强行编造"]

提示词对比：欠佳 vs 推荐

核心原则：

• 不要让 AI 猜 → 提供明确上下文
• 不要含糊其辞 → 给出具体要求
• 不要强行编造 → 给 AI 一个"不确定"的出口

让 AI 反复提问

"我要开发一个任务管理应用。
请反复问我问题，直到你完全理解我的需求。
不要猜测，直接问。"

提示词模板

代码生成模板

"实现 [功能名称]

技术栈：
- Next.js [版本]
- TypeScript
- Drizzle ORM
- [其他技术]

需求：
1. [具体需求1]
2. [具体需求2]
3. [具体需求3]

注意事项：
- 遵循项目现有代码风格
- 不要引入新依赖，除非必要
- 包含错误处理"

Bug 修复模板

"修复 Bug

文件路径: [完整路径]
错误信息:
[完整报错日志]

当前代码:
[相关代码片段]

期望行为: [描述]
实际行为: [描述]

请分析原因并提供修复方案"

标准工作流

AI 的自动化能力

在开始工作流之前，记住：AI 能自动处理很多任务。

graph TB
    A["你需要做的"] --> B["描述任务目标"]
    A --> C["提供必要上下文"]
    A --> D["验证结果并反馈"]

    E["AI 自动做的"] --> F[探索项目结构]
    E --> G["选择合适工具"]
    E --> H["处理错误重试"]
    E --> I["生成提交信息"]

AI 的自动化能力：

• ✅ 自动探索项目结构（你不需要告诉它看哪些文件）
• ✅ 自动选择合适的工具（Read、Edit、Bash）
• ✅ 自动处理错误（失败会重试或换方案）
• ✅ 自动生成提交信息（根据修改内容）
• ✅ 自动识别依赖关系（知道修改会影响哪些文件）

你需要做的：

• 清楚描述任务目标
• 提供必要的上下文
• 验证结果并反馈

不需要做：

• ❌ 指定具体步骤（"先读文件A，再读文件B"）
• ❌ 告诉它用哪个工具（"用 Read 工具读取"）
• ❌ 手动组合命令（"运行 git add 然后 git commit"）
• ❌ 手动处理错误（"如果失败就重试"）

权限模式

三种权限模式

快速决策：

• 不确定时 → Default
• 只想看代码 → Plan
• 频繁跑命令 → Accept Edits

试试交互模拟，感受不同模式的区别：

Default 模式（推荐）

只读操作（读取文件、搜索代码、查看状态、列出文件）自动批准，修改操作（编辑文件、删除文件、运行命令、网络请求、Git push）需要确认。

权限弹窗选项：

• Yes：同意本次操作
• Yes, don't ask again for this tool：同意本次，且后续同类操作不再询问
• No, and tell AI what to do differently：拒绝并告诉 AI 换个方式

Plan 模式（代码审查）

仅允许只读操作，所有修改操作都会被阻止。

适用场景：

• 代码审查
• 了解代码库结构
• 探索性分析

graph LR
    A[用户切换 Plan 模式] --> B[AI 进入只读探索]
    B --> C[分析代码结构和依赖]
    C --> D[生成实施方案]
    D --> E[用户审批方案]
    E -->|批准| F[切回正常模式执行]
    E -->|修改| B

# 先切换到 Plan 模式（Shift+Tab 切换）
"帮我把用户认证从 express-session 迁移到 JWT"

编辑操作需要确认，其他操作自动批准。

# 示例行为
"读取配置文件"
"运行测试"
# AI 直接执行（非编辑操作）

"修改函数签名"
"删除这个文件"
# AI 会询问（编辑操作需确认）

适用场景：

• 需要频繁运行命令/测试
• 对文件修改要谨慎
• 高度信任的自动化工作流

模式切换

快捷键

Shift+Tab # 在三种模式间循环切换

常用交互命令

在 Claude Code 中，以 / 开头的命令称为斜杠命令，用于快速执行特定操作：

常用场景：

# 开新任务时清空上下文
/clear

# 查看剩余额度
/status

# 切换到更强模型
/model opus

# 恢复到之前的状态
/rewind

CLI 命令与启动选项

! npm test
! git status
! ls -la

claude --agents '{
  "code-reviewer": {
    "description": "Expert code reviewer",
    "prompt": "You are a senior code reviewer",
    "tools": ["Read", "Grep", "Glob", "Bash"],
    "model": "sonnet"
  }
}'

五步工作流

交互式工作流演示 —— 点击每步查看详情：

1. 探索项目结构

先了解项目现状，能在 prompt 中给出更精准的上下文——比如"项目已有 Comment 表，请复用"、"代码风格参考 src/modules/posts"。上下文越明确，AI 的输出越贴合你的项目。

先探索，再动手：

"探索这个项目的结构，告诉我:
1. 使用的技术栈
2. 文件组织方式
3. 现有的功能模块
4. 配置文件的作用"

你会得到：

项目使用 Next.js 16 + TypeScript + Drizzle
- app/: 页面和 API
- components/: 可复用组件
- src/db/: 数据库模型（已有 User 表，可关联）

关键信息：已有 User 表 → 直接关联，省去建表 + 10 分钟。

2. 规划实现步骤

目的: 先想清楚再动手，减少返工

"我要添加用户评论功能。
请规划实现步骤，包括:
1. 需要创建哪些文件
2. 需要修改哪些现有文件
3. 数据库 schema 变更
4. 实现顺序"

输出示例:

步骤:
1. 更新 Drizzle schema (添加 Comment 模型)
2. 运行 npx drizzle-kit push
3. 创建 API route (app/api/comments/route.ts)
4. 创建评论组件 (components/CommentForm.tsx)
5. 集成到详情页

3. 编写代码

目的：按计划实现功能

AI 的自动拆分能力：

复杂任务会被自动拆解：

# 你只需要说
"实现用户评论功能"

# AI 会自动拆分为：
1. 更新 Drizzle schema
2. 运行数据库迁移
3. 创建 API 端点
4. 编写前端组件
5. 集成到页面
6. 测试验证

你不需要手动指定每个步骤，AI 会：

• 识别任务依赖关系
• 确定执行顺序
• 并行处理独立部分
• 验证每个步骤的结果

当然，你也可以分步执行：

"按照步骤 1，更新 Drizzle schema"

"按照步骤 2，生成并运行迁移"

"按照步骤 3，创建评论 API"

4. 测试验证

目的：确保功能正常

"测试评论功能:
1. 验证 API 能正常创建评论
2. 验证评论能正确显示
3. 验证错误处理"

5. 提交代码

场景：AI 改崩了代码，想回退

AI 为了修一个 Bug，改了 10 个文件，结果功能全乱了。你想回退，但发现没有存档点。

解决方案：让 AI 自动提交代码。

配置方法：在 CLAUDE.md 中添加：

"每当你完成一个独立功能的开发，或修复完一个 Bug 并验证通过后，请自动运行 git commit 提交代码，并生成一句简洁的中文 commit message。"

效果：

• AI 写完登录功能 → 自动 git commit -m "feat: 实现登录"
• AI 写完首页 → 自动 git commit -m "feat: 添加首页"
• AI 搞崩了代码 → git log 找到上一个版本，git reset 回退

自动提交 vs 检查点：

建议：两者都用。检查点用于快速试错，Git 提交用于重要节点。

6. 检查点功能

场景：代码改崩了，想回滚

你让 AI 重构代码，结果功能全乱了。按 Esc+Esc，选择之前的检查点，代码恢复。松了口气。

但注意检查点的局限：

你用 /rewind 回滚到早期版本，然后 ls 一看——

• index.html 恢复了 ✓
• node_modules/ 还在（AI 删不了）
• 数据库表也还在（AI 动不了）

原因：检查点只回滚 AI 写入的文件，终端命令（npm install、mkdir）产生的变更无法回滚。

正确姿势：

• 小改动 → 检查点快速回滚
• 大改动 → git commit 后再让 AI 动手

使用方法：
按 Esc+Esc 或 /rewind，选择：

• 仅对话：回退消息，保留代码
• 仅代码：恢复文件，保留对话
• 两者都恢复

理解 Agent

什么是 Agent

Agent = AI 本身

AI 本身就是一个 Agent，它的工作是：

• 理解你的意图和需求
• 做决策（用什么工具、先做什么后做什么）
• 协调各种工具完成任务

可以把 Agent 理解为一个任务执行器：

• 接收你的指令（提示词）
• 调用各种工具完成任务
• 返回执行结果

与普通 AI 对话的区别：

什么是自定义 Agent

自定义 Agent = 你创建的专门 Agent

自定义 Agent 是主 Agent 可以调用的"专门助手"。每个自定义 Agent：

• 有特定的用途和专业领域
• 有独立的上下文窗口（不污染主对话）
• 有自定义的系统提示（专门训练）
• 可以限制工具访问权限

使用自定义 Agent 的优势：

Agent 类型：

你：[在计划模式] 帮我重构认证模块
我：让我先研究一下你的认证实现...
[内部调用 Plan Agent 探索认证相关文件]
[Plan Agent 搜索代码库并返回发现]
我：基于研究，这是我的建议方案...

创建自定义 Agent

使用 /agents 命令创建你自己的自定义 Agent。

第0步：在 Claude 内输入 /agents 回车

多 Agent 并行协作

自动启用

Claude Code 根据任务描述主动委派任务，使用 Task 工具创建通用 Agent 并行处理：

• 任务描述中的关键词："并行"、"同时"、"多 Agent"
• 自定义 Agent 配置中的 description 字段
• 当前上下文和可用工具

多个并行 Agent

任务：了解 Prisma、Drizzle、Supabase 三种数据持久化方案

任务：开发用户设置页面的多个功能模块

使用示例

# 自动并行 - AI 自动识别独立任务
"同时做这三件事：
1. 编写后端 API（用户认证）
2. 编写前端 UI（登录表单）
3. 编写数据库 schema（User 表）"

# 明确使用多 Agent
"使用多 Agent 并行开发任务模块：
- Agent 1 做 CRUD API
- Agent 2 做任务列表和表单
- Agent 3 做 Task 数据模型"

graph TD
    A[用户需求] --> B[主 Agent 拆解任务]
    B --> C[架构 Agent]
    B --> D[前端 Agent]
    B --> E[安全 Agent]
    C --> F[汇总结果]
    D --> F
    E --> F
    F --> G[输出最终方案]

"从以下角度分析这个 API 设计：
1. 安全性：是否有注入风险、认证漏洞
2. 性能：N+1 查询、缓存策略
3. 可维护性：命名规范、职责划分
4. 向后兼容：API 版本策略"

# 创建自定义 Agent（放在 .claude/agents/ 目录）
# 例如：security-reviewer.md
你是一个安全审查专家。检查代码中的：
- SQL 注入
- XSS 漏洞
- 硬编码密钥
- 不安全的依赖

两个选项：

• --continue：自动继续最近的对话
• --resume：显示对话选择器

使用示例：

# 继续最近的对话
claude --continue

# 使用特定提示继续
claude --continue -p "显示我们的进度"

# 显示对话选择器
claude --resume

# 非交互模式继续
claude --continue -p "再次运行测试"

工作原理：

1. 对话自动保存在本地
2. 恢复时加载完整消息历史
3. 工具状态和结果被保留
4. 上下文完整恢复

:::

# 使用新分支创建
git worktree add ../project-feature-a -b feature-a

cd ../project-feature-a
claude

# 列出所有 worktrees
git worktree list

// package.json
{
  "scripts": {
    "lint:claude": "claude -p '你是 linter。检查 vs main 的更改，报告拼写错误。每行一个文件名和行号，第二行描述问题。不返回其他文本。'"
  }
}

# 管道数据
cat build-error.txt | claude -p '简明解释构建错误的根本原因' > output.txt

人在环路

AI 能够自主完成很多任务，但以下场景建议保持人工审查：

Hooks 自动化

使用 Hooks

运行 /hooks 打开交互式配置界面，这是最推荐的创建方式。

配置流程：

1. 选择 Hook 事件类型：

   • PreToolUse - 工具调用前
   • PostToolUse - 工具调用后
   • PostToolUseFailure - 工具执行失败后
   • Notification - 发送通知时
   • UserPromptSubmit - 用户提交提示时（推荐）

2. 配置 Hook 行为：

   • 选择触发条件（matcher）
   • 编写执行的 Shell 命令
   • 设置超时时间（默认 60 秒）

3. 保存并生效

常用场景

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [{
          "type": "command",
          "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/format-code.sh"
        }]
      }
    ]
  }
}

#!/usr/bin/env python3
# .claude/hooks/protect-files.py

{
  "session_id": "会话ID",
  "cwd": "当前工作目录",
  "hook_event_name": "事件名称",
  "tool_name": "工具名称",
  "tool_input": {...}
}

安全注意事项

# .env 文件（不要提交到 Git）
DATABASE_URL="postgresql://..."
OPENAI_API_KEY="sk-..."

核心理念

Workflow 让 AI 开发可预测、可复现。

graph TB
    A["无 Workflow"] --> B["想到哪做到哪"]
    B --> C["返工多"]
    B --> D["质量不稳定"]

    E["有 Workflow"] --> F["结构化思考"]
    F --> G["一次通过率高"]
    F --> H["质量稳定"]

记住工作流五步曲：探索 → 规划 → 执行 → 验证 → 提交（根据情况灵活应用）

提示词自检清单

发送提示词前检查：

任务描述清晰具体
提供了必要的上下文
明确了输出格式
给了 AI"不确定"的出口
包含了必要的约束条件
避免了冗长的角色设定
没有包含敏感信息（API Key、密码等）

常见问题

Q1: 提示词越长越好吗？

A: 不是。

提示词的质量在于精确，不在于长度。

简洁但具体的提示词 > 冗长但模糊的提示词

Q2: AI 还是会编造答案怎么办？

A: 加强约束：

"只使用项目已有的依赖。
如果需要新功能，先告诉我。
不要编造不存在的 API。"

Q3: 为什么不直接让 AI 写代码？

A: 直接写容易返工。

探索 → 规划 → 编写，这个流程能让你：

• 避免重复造轮子
• 发现潜在问题
• 保持代码风格一致

Q4: 工作流会不会太慢？

A: 不会。

看似多了步骤，实际上减少了返工时间。整体效率更高。

对比：

• 直接写：10 分钟，返工 30 分钟
• 按流程：15 分钟，一次通过

Q5: 什么时候该停止对话？

A: 信号：

• 连续 3 轮没有进展
• AI 开始重复相同的建议
• 问题需要更多信息（如查看生产环境日志）

策略：切换模型或换思路

相关内容

• 详见：2.3 MCP、插件与 Skills
• 详见：2.4 项目规则配置
• 前置：2.1 AI 编程的经济学
• 后续：2.5 高效调试心法