什么是VibeCoding
VibeCoding是在2025年提出核心概念是:用自然语言描述需求,AI自动生成。开发者将从原来单一的程序员变成产品架构师和看守者。 换句话说也就从写代码的人 成为描述需求的人
AI 可以代替所有编程知识?
现实中由于AI的发展反而提高了程序员的门栏,所以需要我们更懂基本的技术知识。不然无法判断AI生成的代码是对还是错,也无法有效描述需求或者你都不知道在那些情况采用那些技术以及为什么采用这种技术?
VibeCoding适合场景
| 场景 | 适合情况 | 举例 |
|---|---|---|
| 快速验证一个想法 | ☆☆☆☆☆ | Vibe Coding 一个简单的五子棋 |
| 写脚本 | ☆☆☆☆☆ | 写个脚本处理一下视频的重命名 |
| 重复的一些操作 | ☆☆☆☆☆ | 写一些增删查改的操作 |
| 前端的网页界面 | ☆☆☆☆☆ | 写个表白网页,写个XXXX网页,这是AI最擅长的 |
| 测试用例编写 | ☆☆☆☆☆ | 后端程序写完了,对程序进行测试,生成测试用例 |
| 复杂的算法 | ☆☆☆ | 并不是算法的实现,是你描述算法的准确度,这个是有困难的 |
| 涉及操作系统级别的改动 | ☆☆ | 涉及操作系统有安全问题,谨慎 |
提示词 (Prompt)
定义: 提示词是你与AI沟通的桥梁,决定了AI对你需求的理解程度。好的提示词 = 好的输出。
提示词基本结构
| 要素 | 说明 | 示例 |
|---|---|---|
| 角色 | 告诉AI以什么身份回答 | "你是一个资深前端工程师" |
| 背景 | 提供项目或任务上下文 | "我在做一个电商后台系统" |
| 任务 | 明确要做什么 | "请帮我设计一个商品列表组件" |
| 约束 | 限制条件 | "使用 Vue 3 + TypeScript,不要第三方UI库" |
| 输出格式 | 期望的输出形式 | "返回 Markdown 格式,包含代码和说明" |
官方最佳实践
根据 Anthropic 官方文档:
- 清晰具体 --- 明确说明"做什么"+"不做什么"
- 给出示例 --- 需要特定输出风格时,给1-3个输入/输出配对的 few-shot 示例
- 分解复杂任务 --- 大任务拆成小步骤,逐步完成(使用 checklist)
- 指定验证方式 --- 告诉AI生成后如何验证正确性
- 善用角色设定 --- 角色能让AI调用更针对性的知识
核心原则: Claude 已经非常聪明。只补充它不知道的上下文,不要解释它已知的概念。
常见模式
| 模式 | 适用场景 |
|---|---|
| 角色指令 | 需要专业视角时 |
| 思维链 (Chain-of-Thought) | 复杂逻辑推理 |
| 示例引导 (Few-shot) | 需要特定输出风格 |
| 逐步验证 (Checklist) | 代码生成、数据处理 |
| 反向约束 | 明确禁止什么 |
上下文 (Context)
定义: 上下文是AI推理时所依赖的全部信息。在 VibeCoding 中,上下文管理直接影响输出质量------给对的上下文比给多的上下文更重要。
上下文窗口 (Context Window)
根据 Anthropic 官方文档:
上下文窗口是指语言模型在生成响应时可以引用的所有文本,包括响应本身。它代表了模型的"工作记忆"。
关键认知:
- Claude Opus 4.8 / Sonnet 4.6 支持 最多 100 万 token
- 更大的窗口 ≠ 更好。随着 token 数增长,准确率会下降,这叫 上下文衰减 (Context Rot)
- 精心管理上下文内容比"装得下多少"更重要
官方上下文管理策略
1. 上下文感知 (Context Awareness)
Claude Sonnet 4.6+ / Haiku 4.5+ 能实时跟踪剩余 token 预算:
xml
<budget:token_budget>1000000</budget:token_budget>
<system_warning>Token usage: 35000/1000000; 965000 remaining</system_warning>
这让Claude能自我调节,合理安排资源。
2. 渐进式披露 (Progressive Disclosure)
不要一次性加载所有上下文,按需读取。
- Skills 的元数据只在启动时预加载
- SKILL.md 只在触发时加载
- 参考文件只在被引用时加载
3. 上下文压缩 (Compaction)
对于超长对话,官方推荐服务端压缩:
- 自动摘要早期对话内容
- 支持多轮对话超过上下文窗口限制
4. Memory 工具
让 Claude 在会话间存储和检索信息(/memories 目录):
- 跨会话持久化关键信息
- 即需即取,避免一次加载所有内容
- 跨会话学习:从过去的交互中改进
5. 多会话模式
- 每个会话聚焦一个子任务
- 通过 Memory 或文件在会话间传递状态
- 设计状态工件让新会话快速恢复上下文
上下文的层级来源
objectivec
第1层:系统提示 (System Prompt)
└─ 模型内置的系统指令
└─ --system-prompt / --append-system-prompt 传入
第2层:项目规则 (CLAUDE.md)
└─ .claude/CLAUDE.md(项目级)
└─ ~/.claude/CLAUDE.md(用户级,全局)
第3层:对话历史
└─ 所有用户消息和AI回复
第4层:Skills 元数据
└─ name + description(预加载)
└─ SKILL.md 内容(触发后加载)
第5层:Memory 工具
└─ 跨会话持久化(/memories 目录)
第6层:工具执行结果
└─ Bash/Grep/Read 等工具的返回
上下文组织原则
| 原则 | 说明 |
|---|---|
| Less is More | 只提供AI真正需要知道的 |
| 前置最重要 | 最重要的指令放在最前面 |
| 按需加载 | 渐进式披露减少无效占用 |
| 定期清理 | 压缩或状态文件清理过期结果 |
| 结构化存储 | Memory工具持久化关键信息 |
规则 (Rules)
定义: 规则是"契约"或"基本法",负责强制AI"必须知道什么",定义行为边界和底层原则。在 Claude Code 中,规则通过层级化的 CLAUDE.md 文件系统实现。
规则的层级体系
Claude Code 按以下优先级加载规则,高优先级覆盖低优先级:
scss
第1级:每会话级 (Session-level) ← 最高优先级
└─ --system-prompt 或 --append-system-prompt 传入
└─ 仅当前会话生效
第2级:每工作树级 (Per-worktree)
└─ .claude/CLAUDE.md(git worktree 模式下)
└─ 仅在特定工作树生效
第3级:项目级 (Project-level)
└─ .claude/CLAUDE.md
└─ 提交到 Git,团队共享
└─ 技术栈、架构约定、命名规范等
第4级:用户级 (User-level)
└─ ~/.claude/CLAUDE.md
└─ 该用户所有项目全局生效
└─ 个人编码偏好、语言偏好、安全规则
注: CLAUDE.md 中也可以包含项目概览、常见命令等通用背景信息(即你笔记中的 AGENTS.md 概念),但官方统一用 CLAUDE.md 实现。
规则 vs 技能
| 维度 | 规则 (Rules) | 技能 (Skills) |
|---|---|---|
| 核心功能 | 定义行为边界和底层原则 | 提供执行特定任务的流程 |
| 生命周期 | 每次会话自动加载 | 按需触发 |
| 范围 | 全局或项目级 | 具体任务场景 |
| 文件 | CLAUDE.md | SKILL.md |
| 触发方式 | 自动 | 自动匹配或手动 /skill-name |
| 数量 | 通常一个文件覆盖全面 | 可以有几十个,按需触发 |
Skill 中的规则------自由度原则
根据官方最佳实践,Skill 中的指令有三种自由度:
| 自由度 | 说明 | 写法 |
|---|---|---|
| 高自由 | 多种方法都有效 | 文本化指令:"分析代码结构,检查潜在 bug" |
| 中自由 | 有首选模式,允许变化 | 伪代码或脚本模板带参数 |
| 低自由 | 操作脆弱、一致性关键 | 精确脚本,"不要修改命令" |
反模式规则
规则是"必须遵守",反模式是"绝对不能做":
| 反模式 | 说明 |
|---|---|
| ❌ Windows 路径 | 始终用正斜杠 scripts/helper.py |
| ❌ 过多选项 | 给一个默认方案,不列五六个 |
| ❌ 时效性信息 | 不用"2025年8月前",用 <details> 折叠旧版 |
| ❌ 术语不一致 | 始终用"API endpoint",不混用 URL/path/route |
| ❌ 恶意指令 | 指示忽略安全规则、隐藏操作 → 高风险 |
| ❌ 数据泄露 | 要求将敏感信息写入日志或外部服务 → 高风险 |
个人规则举例
markdown
# 我的个人规则
## 1. 回答风格
- 始终使用中文回答。思考过程也是中文的。
- 回答简洁、直接,避免冗长的背景介绍。
- 如果代码有问题,先指出问题再给出修复方案。
## 2. 代码生成规范
- 变量、函数、类名使用英文,遵循"见名知意"原则。
- 复杂逻辑(超过5行或包含嵌套)必须写注释。
- 复杂函数必须在注释中说明参数类型、返回值和主要作用。
- 优先使用函数式编程,避免不必要的类。
- 代码缩进使用 4 个空格。
## 3. 安全与隐私
- 不要在代码注释或日志中输出真实的密码、Token、手机号等敏感信息,用占位符代替。
- 如果用户贴出了敏感信息,主动提醒用户注意安全。
## 4. 互动习惯
- 当用户问"为什么"时,给出原理性解释,而不仅仅是结论。
- 如果用户的问题可能产生歧义,先列出假设条件再回答。
技能 (Skills)
定义: 技能是"工具箱"或"秘籍",负责让AI"能快速做什么",提供执行特定任务的标准化流程,将你的经验和SOP固化下来。
Skills 的核心结构
一个 Skill 就是一个文件夹 + SKILL.md:
perl
my-skill/
├── SKILL.md # 必需:指令 + 元数据
├── scripts/ # 可选:可执行代码
├── references/ # 可选:文档资料
└── assets/ # 可选:模板、资源
SKILL.md 元数据
| 字段 | 必需 | 说明 |
|---|---|---|
| name | 是 | 最长64字符,只能小写字母、数字和-,不能含"anthropic"/"claude" |
| description | 是 | 最长1024字符,必须用第三人称,包含"做什么"+"何时触发" |
| allowed-tools | 否 | 允许使用的工具列表(实验性功能) |
| license | 否 | 许可证名称 |
| compatibility | 否 | 环境与依赖说明,最长500字符 |
| metadata | 否 | 自定义键值对(作者、版本号等) |
命名规范
- 推荐动名词:
processing-pdfs、analyzing-spreadsheets - 可接受名词短语:
pdf-processing、spreadsheet-analysis - 禁止:
helper、utils、anthropic-helper、claude-tools
Description 注意事项
必须用第三人称(这是官方强调的关键!):
- ✅
Processes Excel files and generates reports - ❌
I can help you process Excel files - ❌
You can use this to process Excel files
高质量 Skill 的官方最佳实践
1. 简洁是关键
默认假设:Claude 已经非常聪明。不要解释它已知的概念。
markdown
## Extract PDF text
Use pdfplumber for text extraction:
```python
import pdfplumber
with pdfplumber.open("file.pdf") as pdf:
text = pdf.pages[0].extract_text()
markdown
(~50 tokens,不解释PDF是什么、不解释为什么用pdfplumber)
### 2. 渐进式披露
- SKILL.md 主体控制在 **500 行以内**
- 长内容拆到多个文件,按需加载
- **只保持一层嵌套:** SKILL.md → reference.md,不到 SKILL.md → advanced.md → details.md
### 3. 评估驱动开发
> 在写大量文档之前,先构建评估测试。
1. 不用 Skill 完成代表任务 → 记录失败点
2. 创建 3 个测试场景,建立基线
3. 只为解决这些失败点写最小指令
4. 迭代测试
### 4. 工作流与反馈循环
使用 checklist 让 AI 严格按步骤执行:
```markdown
Task Progress:
- [ ] Step 1: Analyze the form
- [ ] Step 2: Create field mapping
- [ ] Step 3: Validate mapping
- [ ] Step 4: Fill the form
- [ ] Step 5: Verify output
5. 用 Claude 创建 Skill
- "Claude A" 写 Skill
- "Claude B"(带 Skill)完成实际任务
- 观察失败 → 改进 → 循环
Skills 与 Rules 的关系
arduino
规则 (Rules) ← 定义边界:"必须遵守什么"
│
▼
技能 (Skills) ← 定义能力:"能做什么"
│
▼
工具 (Tools) ← 执行手段:"用什么做"
│
▼
Agent ← 执行者:"谁来做"
Agent(智能代理)
定义: Agent 是具备自主决策和任务执行能力的AI实例,通过工具调用、多步骤推理和上下文管理来完成复杂任务。
Claude Code 中的 Agent 层级
1. 工具使用 (Tool Use)
Agent 的核心能力是调用工具与环境交互:
| 内置工具 | 功能 |
|---|---|
| Bash | 执行命令 |
| Read/Write/Edit | 文件操作 |
| Grep/Glob | 搜索代码 |
| WebSearch/WebFetch | 网页搜索与抓取 |
| Skill | 调用专业能力包 |
| Agent | 启动子代理 |
| Workflow | 编排多代理工作流 |
2. 推理循环
Agent 通过"思考 → 行动 → 观察 → 再思考"完成复杂任务:
scss
用户请求
│
▼
Agent 分析需求
│
▼
Agent 调用工具 (Bash / Read / Grep ...)
│
▼
观察工具返回结果
│
▼
调整策略 / 再次调用
│
▼
输出最终结果
3. 子代理 (Sub-agents)
通过 Agent 工具,主 Agent 可启动子代理并行处理任务:
- 每个子代理有独立上下文
- 结果返回主 Agent 汇总
- 支持多种子代理类型:Explore、code-reviewer、Plan、general-purpose
4. 工作流 (Workflow)
通过 Workflow 工具编排多个 Agent 协同:
js
// 示例:并行查找 + 串行验证
const results = await parallel(
finds.map(f => () => agent(`Check: ${f}`, {schema: BUG_SCHEMA}))
)
const verified = await parallel(
results.map(r => () => agent(`Verify: ${r.title}`, {schema: VERDICT}))
)
5. Agent 协作模式
| 模式 | 说明 | 场景 |
|---|---|---|
| 对抗式验证 | 多个 Agent 分别验证,多数被反驳则丢弃 | 决策正确性 |
| 多样性验证 | 不同视角验证(正确性、安全、性能) | 多维度问题 |
| 评审团 | 多个独立方案评分合成 | 方案设计 |
| 循环直到干涸 | 持续发现直到多轮无新发现 | 未知量发现 |
| 完整性评审 | 最终检查遗漏了什么 | 确保无遗漏 |
VibeCoding 中的 Agent 角色
在 VibeCoding 实践中,你的角色从"写代码的人"变成"Agent 的管理者":
markdown
你(管理者)
├── 定义任务目标
├── 提供上下文和约束
├── 选择适当的工具 / Skills / Agent
└── 审查 Agent 的产出
│
▼
Agent(执行者)
├── 理解需求
├── 拆解任务
├── 调用工具
├── 生成代码/文档
└── 验证结果
Agent 的限制与边界
| 限制 | 说明 |
|---|---|
| 工具限制 | 只能调用已授权的工具 |
| 上下文窗口 | 单个 Agent 的上下文有上限 |
| 并发上限 | 最多 16 个并发子 Agent |
| 安全边界 | 敏感操作需用户确认 |
如何更好的向大模型提问
问题本质的底层逻辑
确定当前状态 -> 确定目标状态 -> 确定状态之间的差距 -> 把问题定义出来 -> 确定目标 / 约束 / 对象 -> 求解路径 -> 执行校正 -> 结果验证 -> 反馈迭代 -> 目标达成 -> 问题求解能力。
问题的求解能力本质上就是:把"当前状态"推进到"目标状态"的能力。
所以,任何复杂能力往下拆,最后都可以落到这一件事上:
- 先看清楚问题是什么
- 再设计求解路径
- 再执行和校正
1. 先看清楚问题是什么
定义问题至少要回答:
- 目标:要达到什么结果
- 现状:现在是什么情况
- 差距:目标和现状之间差了什么
- 判断标准:怎样算解决了
公式:问题 = 目标状态 - 当前状态
2. 再设计求解路径
确定目标 / 约束 / 对象 -> 求解路径
3. 对象
对象可能是:事 / 人 / 系统 / 信息 / 资源 / 环境
4. 路径
用什么方法从现状走到目标:拆解 -> 排序 -> 试错 -> 反馈 -> 校正
问题求解能力
问题求解能力 = 准确定义问题,并在目标、约束条件、对象之下,设计并执行有效求解路径的能力。
AI能力 ^ 个人能力 = 超级协作力(无限可能性)
这里用的是"次幂"而不是"乘法"。AI能力是"底座",个人能力是"指数"。
个人能力可以成倍地激活、引导、放大AI的能力。乘法是线性的,次幂是指数级的。
所以,个人能力 + 大模型 = 王炸。
知识体系总图
swift
VibeCoding 知识体系
│
├── 提示词 (Prompt) ← 沟通桥梁:"怎么问"
│ ├── 基本结构:角色 / 背景 / 任务 / 约束 / 输出
│ └── 核心原则:Claude 已经很聪明,只说它不知道的
│
├── 上下文 (Context) ← 工作记忆:"给什么信息"
│ ├── 来源层级:System → CLAUDE.md → 对话 → Skills → Memory → 工具
│ ├── 管理策略:渐进式披露 / 压缩 / Memory / 多会话
│ └── 核心原则:Less is More,对的信息 > 多的信息
│
├── 规则 (Rules) ← 契约/基本法:"必须遵守什么"
│ ├── 层级:会话级 → 工作树级 → 项目级 → 用户级
│ ├── 自由度:高(文本指令)→ 中(模板)→ 低(精确脚本)
│ └── 反模式:路径错误 / 过多选项 / 时效性信息 / 术语不一致
│
├── 技能 (Skills) ← 工具箱/秘籍:"能快速做什么"
│ ├── 结构:SKILL.md + scripts + references
│ ├── 原则:简洁 / 渐进式披露 / 评估驱动 / 自由度量体裁衣
│ └── 禁忌:过度解释 / 多层嵌套 / 过多选项 / 时效性信息
│
└── Agent (智能代理) ← 执行者:"谁来做"
├── 能力:工具调用 / 推理循环 / 子代理 / 工作流
├── 协作:对抗式验证 / 多样性验证 / 评审团
└── 你的角色:从"写代码的人"变成"Agent 的管理者"
总纲: VibeCoding 不是"放弃编程知识",而是"在扎实的基础之上,学会用新的方式与 AI 协作"。掌握 提示词、上下文、规则、技能、代理 这五大要素,才能真正从"写代码的人"进化为"驾驭 AI 的架构师"。