第 1 章：Vibe Coding 入门与 Claude Code 环境搭建

第 1 章Vibe Coding 入门与 Claude Code 环境搭建本章是专栏的开篇我们先搞清楚「Vibe Coding 到底是什么」再从零搭建 Claude Code 的开发环境理解配置文件的三级体系和权限管理机制。学完本章你将拥有一个配置合理、权限可控的 Claude Code 开发环境。1.1 什么是 Vibe Coding1.1.1 定义Vibe Coding氛围编程 / 体感编程是一种新兴的软件开发范式核心特征是开发者不再逐行编写代码而是通过自然语言描述需求、意图和约束由 AI 编程助手如 Claude Code、Cursor、GitHub Copilot生成、修改和重构代码开发者的角色从「代码撰写者」转变为「需求描述者 结果验证者 方向把控者」。这个词最早在 2025 年初由开发者社区自发形成用来描述那种「跟 AI 聊着天就把代码写了」的开发状态。但随着实践深入人们发现 Vibe Coding 远不是「随便聊」那么简单——没有纪律的 Vibe Coding 很快会变成「AI 乱写、你乱擦屁股」的灾难。1.1.2 Vibe Coding 与传统编程的本质区别维度传统编程Vibe Coding代码生成方式开发者手动逐行编写AI 根据自然语言描述生成开发者核心能力语法掌握、算法实现、API 记忆需求拆解、结果验证、方向把控修改粒度手动定位并修改具体行描述「要改成什么样」AI 批量修改错误来源开发者自己的笔误和逻辑错误AI 的幻觉、遗漏、过度修改回退需求偶尔需要改之前心里有数高频需要AI 改了什么不一定全知道上下文管理开发者自己的大脑AI 的上下文窗口有限且会遗忘关键洞察Vibe Coding 把「写代码的成本」降到了接近零但把「验证代码、管理上下文、控制方向」的成本提到了前所未有的高度。本专栏的所有内容本质上都是在教你如何应对这三个新成本。1.1.3 Vibe Coding 的四大支柱一套工程化的 Vibe Coding 工作流建立在四大支柱之上这也是本专栏十章内容的组织逻辑┌─────────────────────┐ │ Vibe Coding │ │ 工程化工作流 │ └─────────┬───────────┘ │ ┌───────────────────┼───────────────────┐ │ │ │ ┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐ │ 安全回退 │ │ 效率提升 │ │ 质量保障 │ │ (第4章) │ │ (第2/5/10章)│ │ (第6/7/8章)│ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ └───────────────────┼───────────────────┘ │ ┌─────▼─────┐ │ 成本可控 │ │ (第3/9章) │ └───────────┘安全回退Git 版本控制、会话级回退、远程备份——任何 AI 的修改都可以撤销代码不会丢失。效率提升上下文压缩、自定义 Skill、进阶技巧——减少重复劳动让 AI 专注于真正需要智能的部分。质量保障代码审查、Subagent 多代理、Hook 自动化门禁——AI 生成的代码必须经过检查才能进入主分支。成本可控记忆体系、Token 优化——在保证质量的前提下最小化 API 调用成本和上下文消耗。1.1.4 本栏课程以 以 Visual Studio Code 的 Claude Code插件 deepseek-v4-pro API为背景展开讲解Claude Code 是 Anthropic 推出的命令行 AI 编程助手也是本专栏的实践工具。选择它的核心理由长上下文支持默认 200K 词元Token上下文窗口Opus 4.6 和 Sonnet 4.6 模型可选 1M 词元窗口足以容纳大型项目的代码库。强大的工具调用能力内置文件读写、Shell 命令执行、Git 操作等工具能真正「动手」改代码而不只是「动嘴」给建议。完善的扩展生态支持自定义 Skill、Hook 钩子、MCP 服务器、Subagent 子代理可以构建高度定制化的工作流。CLI IDE 双模式既可以在终端中使用也有 VS Code 和 JetBrains 插件适应不同开发习惯。说明本专栏的操作基于 Claude Code CLI截至 2026 年 8 月版本。如果你使用 Cursor、GitHub Copilot 等其他工具核心方法论上下文管理、回退策略、质量门禁完全通用只是具体命令和配置方式有所不同。1.2 Claude Code 安装与初始化1.2.1 环境要求操作系统macOS 12、Ubuntu 20.04、Windows 10推荐 WSL2Node.js18Claude Code CLI 基于 Node.js 运行网络能够访问 Anthropic API或配置了第三方 API 代理API 密钥Anthropic Console API Key或 Claude.ai 订阅账户1.2.2 安装 CLI# 方式一通过 npm 全局安装推荐npminstall-ganthropic-ai/claude-code# 验证安装claude--version安装完成后在终端输入claude即可启动交互式会话。首次启动会引导你登录账户或配置 API 密钥。1.2.3 安装 VS Code 扩展如果你习惯在 IDE 中工作可以安装 Claude Code 的 VS Code 扩展打开 VS Code 扩展面板CtrlShiftX/CmdShiftX搜索「Claude Code」安装官方扩展安装后编辑器侧边栏会出现 Claude Code 图标点击即可打开对话面板VS Code 扩展提供了以下增强功能选中代码后CmdShiftL直接发送给 Claude内联编辑建议在代码文件中直接显示 AI 的修改建议文件 diff 预览可视化对比 AI 修改前后的代码1.2.4 项目初始化/init 命令在一个新项目中首次启动 Claude Code 后建议运行/init命令/init这个命令会交互式地引导你创建项目的CLAUDE.md文件项目级记忆第 3 章详细讲解内容包括项目概述和技术栈构建和运行命令项目目录结构编码规范和重要约定/init会自动扫描项目文件提取技术栈信息和常用命令然后让你确认和补充。这比手动从零写CLAUDE.md高效得多。1.3 配置文件三级体系Claude Code 的配置采用「三级叠加」机制理解这个体系是定制化工作流的基础。1.3.1 三级配置的优先级级别文件路径作用域优先级说明项目本地级project/.claude/settings.local.json当前项目个人专用最高个人偏好不纳入 Git不共享给团队项目共享级project/.claude/settings.json当前项目团队共享中团队约定的配置纳入 Git所有团队成员生效用户全局级~/.claude/settings.json所有项目个人全局最低跨项目通用的个人配置叠加规则Claude Code 启动时会按「低优先级 → 高优先级」的顺序依次加载配置高优先级的配置会覆盖低优先级的同名键。最终生效的配置是三级合并后的结果。最终配置 用户全局配置 ⊕ 项目共享配置 ⊕ 项目本地配置 (底层) (中层覆盖) (顶层覆盖)1.3.2 每级配置应该放什么用户全局级~/.claude/settings.json放所有项目通用的个人偏好。{theme:dark,effortLevel:medium,permissions:{allow:[git status,git diff,git log]}}项目共享级project/.claude/settings.json放团队约定的配置纳入 Git 版本控制。{permissions:{allow:[npm test,npm run lint,npm run build],deny:[git push --force origin main]},hooks:{PreToolUse:{matcher:Bash(git commit*),command:./scripts/pre-commit-check.sh}}}项目本地级project/.claude/settings.local.json放个人在当前项目的特殊偏好不纳入 Git应加入.gitignore。{effortLevel:high,env:{ANTHROPIC_BASE_URL:https://api.my-proxy.com/anthropic}}1.3.3 settings.json 完整配置项一个完整的settings.json可以包含以下配置块{env:{ANTHROPIC_BASE_URL:https://api.anthropic.com,ANTHROPIC_AUTH_TOKEN:sk-ant-xxx,ANTHROPIC_MODEL:claude-sonnet-4-6,CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC:1},effortLevel:medium,theme:dark,permissions:{allow:[npm test,git status],allow-dry-run:[git push],deny:[rm -rf /,git push --force origin main]},hooks:{PreToolUse:{},PostToolUse:{},Stop:{}},skills:{deploy-staging:Deploy to staging: npm run build npm run deploy:staging},mcpServers:{github:{command:npx,args:[-y,anthropic/mcp-server-github]}}}各配置块的含义env传递给 Claude Code 子进程的环境变量常用于配置 API 代理和模型选择effortLevelAI 的分析深度low / medium / high / xhigh第 9 章详细讲解permissions工具调用权限规则1.5 节详细讲解hooks事件钩子配置第 8 章详细讲解skills简单技能的指令模板第 5 章详细讲解mcpServersMCPModel Context Protocol服务器配置第 10 章详细讲解1.4 目录结构总览理解 Claude Code 的文件存储结构有助于你在需要时手动查找、备份或清理数据。1.4.1 用户全局目录~/.claude/~/.claude/ ├── settings.json # 用户全局配置跨所有项目生效 ├── MEMORY.md # 用户级自动记忆Claude 自动学习的偏好 ├── memory/ # 分文件的记忆存储独立记忆条目 ├── history.jsonl # 命令历史记录 ├── keybindings.json # 自定义快捷键配置 ├── plugins/ # 自定义技能插件目录 │ └── my-skill/ │ └── skill.md ├── backups/ # 文件备份目录Claude 修改文件前的备份 ├── file-history/ # 文件修改历史记录 ├── sessions/ # 会话存档历史对话记录 ├── projects/ # 项目级数据按项目存储 │ └── {project-hash}/ │ ├── memory/ # 项目级自动记忆 │ └── settings.json # 项目共享配置 ├── agent-memory/ # 代理级记忆按 Subagent 类型存储 └── plans/ # Plan Mode 保存的计划文件1.4.2 项目级目录project/.claude/project/ ├── CLAUDE.md # 项目级记忆每次会话启动时全量加载 └── .claude/ ├── settings.json # 项目共享配置纳入 Git团队共享 ├── settings.local.json # 项目本地配置不纳入 Git个人专用 ├── MEMORY.md # 项目级自动记忆Claude 自动学习 ├── memory/ # 项目级分文件记忆 └── markers/ # 自定义标记文件如质量门禁的 PASS/FAIL 标记1.4.3 关键目录的用途说明目录/文件用途是否纳入 Git手动编辑建议CLAUDE.md项目宪法AI 每次会话必读✅ 推荐经常编辑保持最新settings.json项目共享团队共享配置✅ 推荐团队协商后编辑settings.local.json个人项目配置❌ 应加入 .gitignore个人自由编辑~/.claude/settings.json全局个人配置❌ 个人文件个人自由编辑MEMORY.mdClaude 自动学习的记忆❌ 通常不纳入不建议手动编辑让 Claude 管理plugins/自定义技能插件视情况开发技能时编辑sessions/历史对话存档❌不需要手动编辑backups/文件修改备份❌可定期清理释放空间注意MEMORY.md和CLAUDE.md是两个完全不同的东西。CLAUDE.md是你手动编写的「指令和规则」而MEMORY.md是 Claude 在工作过程中自动学习和记录的「经验和发现」。第 3 章会详细拆解两者的区别和使用场景。1.5 权限管理四级别Claude Code 在执行工具调用如运行 Shell 命令、修改文件时会根据权限配置决定是否需要用户确认。理解权限机制是安全使用 AI 编程的关键。1.5.1 四级权限模型权限级别配置键行为适用场景allowpermissions.allow无需确认直接执行安全的只读命令、项目固定命令allow-dry-runpermissions.allow-dry-run先展示执行计划用户确认后执行有副作用但可预期的命令ask默认行为不配置即 ask每次执行前询问用户大多数命令的默认行为denypermissions.deny完全禁止执行不询问危险命令绝对不允许 AI 执行1.5.2 权限配置示例{permissions:{allow:[npm test,npm run lint,git status,git diff,git log],allow-dry-run:[git push,npm run deploy:*,docker compose up],deny:[rm -rf /,rm -rf ~,git push --force origin main,git reset --hard origin/main]}}规则说明allow中的命令匹配支持通配符如npm run deploy:*匹配所有 deploy 开头的脚本deny的优先级高于allow——如果一个命令同时匹配 allow 和 denydeny 生效未在任何列表中出现的命令默认行为是ask每次询问1.5.3 权限匹配的格式权限规则使用工具名(命令模式)的格式来精确匹配Bash(npm test) # 匹配 Bash 工具执行 npm test Bash(git commit*) # 匹配 Bash 工具执行以 git commit 开头的命令 Edit(*) # 匹配所有文件编辑操作 Read(*) # 匹配所有文件读取操作这种格式可以精确控制「哪个工具的哪种操作」被允许或拒绝。1.5.4 /fewer-permission-prompts自动优化权限配置如果你觉得每次都要手动确认很烦可以使用/fewer-permission-prompts技能。Claude 会分析你的历史使用记录自动生成一份合理的allow列表建议你确认后写入配置文件。/fewer-permission-prompts执行后Claude 会输出类似这样的建议根据你最近的使用记录以下命令频繁执行且从未出现问题建议加入 allow 列表 - npm test执行了 23 次全部安全 - git status执行了 45 次只读操作 - npm run lint执行了 12 次安全 是否将以上命令添加到 permissions.allow确认后这些命令就不再需要每次手动确认了。1.5.5 权限管理的安全原则默认保守不要把太多命令加入allow保持默认ask是最安全的。危险命令必须 denyrm -rf、git push --force、格式化磁盘等命令必须明确加入deny。有副作用的命令用 allow-dry-rungit push、部署命令等有外部影响的操作先看计划再确认。定期审查每隔一段时间 review 一次allow列表移除不再需要的权限。项目级和全局级分开全局allow只放所有项目通用的安全命令项目特定的命令放在项目级配置中。1.6 本章小结本章我们完成了 Vibe Coding 专栏的环境搭建核心知识点Vibe Coding 的本质开发者从「代码撰写者」转变为「需求描述者 结果验证者 方向把控者」核心挑战从「写代码」转向「验证、上下文管理、方向控制」。四大支柱安全回退、效率提升、质量保障、成本可控——这是本专栏十章内容的组织逻辑。安装与初始化CLI 通过 npm 安装VS Code 扩展提供 IDE 集成/init命令交互式创建项目记忆。配置文件三级体系用户全局~/.claude/settings.json→ 项目共享.claude/settings.json→ 项目本地.claude/settings.local.json高优先级覆盖低优先级。目录结构~/.claude/存储全局数据project/.claude/存储项目数据关键区分CLAUDE.md手动指令和MEMORY.md自动记忆。权限四级别allow直接执行/allow-dry-run先看计划/ask每次询问默认/deny完全禁止/fewer-permission-prompts可自动优化权限配置。环境搭建完成后下一章我们将进入第一个核心主题上下文管理——学习如何让 AI 在长对话中保持专注、不遗忘、不幻觉。第 1 章课后思考参考答案基础题Claude Code 的三级配置文件分别是什么优先级顺序是怎样的如果你想让团队所有成员都遵循同一个代码审查流程应该把配置写在哪一级三级配置文件级别文件路径作用域项目本地级project/.claude/settings.local.json当前项目个人专用项目共享级project/.claude/settings.json当前项目团队共享用户全局级~/.claude/settings.json所有项目个人全局优先级顺序从高到低项目本地级 项目共享级 用户全局级高优先级的配置会覆盖低优先级的同名键。最终生效的配置是三级合并后的结果最终配置 用户全局配置 ⊕ 项目共享配置 ⊕ 项目本地配置团队共享代码审查流程应该写在哪一级写在项目共享级project/.claude/settings.json。原因这一级配置纳入 Git 版本控制团队所有成员 clone 项目后自动生效作用域是「当前项目团队共享」正好匹配「团队所有成员遵循同一流程」的需求不应该写在用户全局级只对个人生效团队其他人看不到不应该写在项目本地级不纳入 Git个人专用团队其他人看不到2.allow、allow-dry-run、ask、deny四种权限的行为分别是什么git push命令你会配置为哪种权限为什么四种权限的行为权限级别行为适用场景allow无需确认直接执行安全的只读命令、项目固定命令allow-dry-run先展示执行计划用户确认后执行有副作用但可预期的命令ask每次执行前询问用户默认行为大多数命令的默认行为deny完全禁止执行不询问危险命令绝对不允许 AI 执行git push应该配置为allow-dry-run。原因git push有副作用——它会修改远程仓库一旦 push 了错误的代码撤销成本较高需要 force push 或 revertallow-dry-run会先展示执行计划push 哪些分支、包含哪些 commit用户确认后才执行给了一个「最后检查」的机会不配置为allow因为 push 是有外部影响的操作不能完全不确认不配置为ask因为ask只是笼统地问「是否执行」不展示具体计划而allow-dry-run会先展示 push 的具体内容哪些 commit、推到哪个分支信息更充分补充deny中应该明确加入git push --force origin main——强制推送主分支是极其危险的操作必须完全禁止。3.CLAUDE.md和MEMORY.md有什么本质区别如果你的项目有一条硬性规定「所有 API 请求必须经过统一的 request 封装」这条规定应该写在哪里为什么本质区别维度CLAUDE.mdMEMORY.md谁写的你用户手动编写ClaudeAI 自动学习和记录内容性质指令和规则Instructions Rules经验和发现Learnings Patterns加载方式每次会话启动时全量加载启动时加载前 200 行约 25KB其余按需检索是否纳入 Git✅ 推荐纳入团队共享❌ 通常不纳入个人专属手动编辑建议经常编辑保持最新不建议手动编辑让 Claude 管理典型内容技术栈、编码规范、构建命令、硬性约定反复出现的构建命令、调试经验、踩过的坑、AI 发现的偏好一句话总结CLAUDE.md是你给 AI 下的「规矩」MEMORY.md是 AI 在工作中自己总结的「经验」。「所有 API 请求必须经过统一的 request 封装」这条规定应该写在CLAUDE.md中。原因这是一条硬性规则不是经验发现——它是项目的编码规范需要 AI 每次都遵守属于「指令和规则」的范畴需要全量加载——CLAUDE.md每次会话全量加载AI 从第一轮对话就知道这条规则而MEMORY.md只加载前 200 行这条规则可能不在前 200 行中AI 可能看不到需要团队共享——这条规则是项目级的约定所有团队成员都应该遵守CLAUDE.md纳入 Git 后团队共享MEMORY.md是个人专属不纳入 Git需要手动维护——这条规则是人为制定的需要人来编写和更新MEMORY.md是 AI 自动学习的不适合放人为制定的硬性规则4. 如果你在一个团队项目中既想共享一部分 Claude Code 配置如统一的代码审查 Hook又想保留个人偏好如深色主题、自定义快捷键应该如何分配三级配置请给出具体的文件分配方案。具体文件分配方案配置内容放置级别文件路径原因统一的代码审查 Hook项目共享级project/.claude/settings.json团队共享纳入 Git所有人 clone 后自动生效团队统一的编码规范、构建命令项目共享级project/CLAUDE.md团队共享的项目规范纳入 Git团队统一的权限规则如禁止 force push项目共享级project/.claude/settings.json安全规则需要对所有团队成员生效项目级自定义 Skill如项目特有的部署流程项目共享级project/.claude/plugins/项目特有的工作流团队共享深色主题用户全局级 或 项目本地级~/.claude/settings.json或.claude/settings.local.json个人偏好不需要共享不纳入 Git自定义快捷键用户全局级~/.claude/keybindings.json个人操作习惯跨所有项目通用个人的 Effort Level 偏好用户全局级 或 项目本地级~/.claude/settings.json或.claude/settings.local.json个人对分析深度的偏好不影响团队个人的 API 代理配置项目本地级project/.claude/settings.local.json个人网络环境不同代理地址不同且包含敏感信息不能纳入 Git个人的自动记忆用户全局级~/.claude/MEMORY.mdAI 自动学习的个人偏好个人专属核心原则团队共享的、需要统一的→ 项目共享级纳入 Git个人偏好的、不需要共享的→ 用户全局级跨项目或项目本地级仅当前项目包含敏感信息的API Key、代理地址→ 项目本地级加入.gitignore绝对不能纳入 Git.gitignore中必须包含.claude/settings.local.json .claude/MEMORY.md .claude/memory/5. Vibe Coding 把「写代码的成本」降到了接近零但把「验证代码、管理上下文、控制方向」的成本提高了。结合你自己的编程经验你认为这三个新成本中哪一个最难应对为什么参考答案以「验证代码」最难为例也可以选择其他两个言之有理即可我认为验证代码是三个新成本中最难应对的。原因分析1. 验证代码需要专业判断力无法完全自动化管理上下文有明确的工具/compact和量化指标Token 用量、对话轮数可以按规则执行控制方向有明确的方法论需求文档、Plan Mode、竞品分析可以通过流程规范来保障但验证代码需要判断「这段代码逻辑对不对」「这个边界场景有没有考虑到」「这个性能问题会不会在生产环境触发」——这些需要深厚的技术功底和业务理解比如路由守卫权限隔离等场景AI无法理解他不知道要进行场景区分所以AI 可以辅助审查但最终判断还是要靠人2. AI 生成的代码量太大人工逐行验证不现实AI 一次可以生成几十个文件、几百行代码人工逐行审查需要大量时间而且人在疲劳时容易遗漏自动化审查/code-review可以发现语法错误、安全漏洞、规范问题但无法判断业务逻辑是否正确——AI 不了解你的业务背景可能把「符合业务规则但看起来奇怪」的代码标记为问题也可能把「看起来正常但违反业务规则」的代码漏掉3. 验证需要「运行起来看」但运行环境复杂很多问题只有在实际运行时才会暴露环境变量配置错误、跨域问题、CSS 优先级冲突、并发竞态条件/verify可以辅助运行验证但复杂系统的端到端验证需要完整的测试环境、测试数据、测试用例搭建和维护成本很高个人项目往往没有完善的测试覆盖验证主要靠手动点一遍覆盖度有限4. 验证是「最后一道防线」一旦漏掉问题就进入生产上下文管理不好后果是 AI 幻觉、改不动代码可以通过压缩和开新对话补救方向控制不好后果是做了不需要的功能可以通过需求管理和迭代来修正但验证漏掉了问题代码可能直接进入主分支甚至生产环境后果可能是线上故障、数据丢失、安全漏洞——修复成本远高于前两者应对策略建立多层验证体系自动化审查/code-review→ 自动化测试单元测试 集成测试→ 手动验证/verify→ 人工复核核心逻辑小步提交每次只改少量代码降低每次验证的复杂度为核心业务逻辑编写完善的测试用例用自动化测试覆盖大部分验证场景培养「AI 的输出必须经过验证」的意识不要因为 AI 说「没问题」就相信注这是开放题选择「管理上下文」或「控制方向」也可以。选择「管理上下文」的核心理由可以是上下文窗口有限且 AI 的遗忘是渐进的、不易察觉的你很难精确知道 AI 「忘了什么」选择「控制方向」的核心理由可以是需求变更和蔓延是软件开发的经典难题AI 时代需求变更成本更低导致蔓延更快且方向错误会导致所有后续工作白费。