Claude Code
从入门到精通

§01 为什么是Claude Code

Why Claude Code

AI编程工具在三年里变了三次。搞清楚这个演变路径，你就能理解Claude Code到底在做一件什么不一样的事。

三年变了三次

2022年，GitHub Copilot出来了。你写上半句，它帮你猜下半句。像一个坐在旁边的实习生，打字确实快了，但本质没变：你还是那个写代码的人。

2023到2024年，Cursor火了。你可以用自然语言让编辑器帮你改函数、重构模块，不用精确描述「怎么写」，说「我想要什么效果」就行。后来Cursor也加了Agent模式，能跨文件操作、自动跑命令。但它始终长在IDE里，是编辑器的延伸。

2025年，Claude Code出来了。它不住在任何编辑器里，直接在终端运行。你描述一个需求，它自己规划步骤、读代码、写代码、跑测试、操作git，整个循环自动完成。你的角色从「写代码的人」变成了「给指令的人」。

三步走下来，变的不是技术有多先进，而是你和AI之间的关系。Copilot是你的输入法，Cursor是你的结对伙伴，Claude Code是你的独立工程师团队。

它跟Cursor到底有什么不一样

这是被问得最多的问题：「Cursor也有Agent模式了，不都是AI帮我写代码吗？」

确实，2024年之后的Cursor已经很强了，能跨文件操作、理解整个项目、自动执行命令。两者的差异不在「能不能做」，而在做到什么程度。

重点看最后两行。CLAUDE.md让你把项目知识、编码规范、架构决策写成文件，Claude Code每次启动都会读，相当于给AI一个持久的项目记忆。多实例并行意味着你可以同时让几个Claude Code各自处理不同模块，像一个小团队。

打个比方：Cursor像坐在你IDE里的结对伙伴，你们看着同一个屏幕协作；Claude Code更像一个独立干活的工程师，你告诉他需求，他自己拉代码、写代码、跑测试、提交，你去喝杯咖啡回来看结果就好。

Boris Cherny，Claude Code的创建者，说自己用Opus 4.5之后就再也没有手写过一行代码。47天里有46天都在用，最长单次session跑了1天18小时50分钟。这不是营销话术，是一个正在大规模发生的现实。

它其实不是在帮你写代码

这句话听起来有点奇怪，但确实是我用了半年之后最大的感受：Claude Code不是在帮你写代码，它在帮你构建产品。

传统的AI编程工具解决的是代码生产效率：怎么更快地写出这个函数、这个组件。Claude Code解决的是产品构建效率：怎么更快地从一个想法变成一个能跑的东西。

两种场景对比一下：

前者你在做产品决策，后者你在做过程监督。随着AI能力持续提升，「盯着AI干活」会越来越不值钱，产品决策能力会越来越值钱。

Claude Code增长快，本质上是命中了一个真实需求：大量聪明人想做出东西来，缺的不是想法，是把想法变成产品的能力。

这本书写给谁

工程师，想提高10倍效率。你已经会写代码，但每天大量时间花在样板代码、调试、写测试、处理CI/CD上。Claude Code能接管这些，让你把精力放在架构决策和产品思考上。

产品经理，想自己做MVP。你有产品直觉和用户洞察，但受限于开发资源。Claude Code让你一个周末做出一个能跑的原型，不用等排期，不用写PRD等开发理解。

创业者，想实现一人公司。你想验证商业想法，但不想在技术上花太多钱和时间。Claude Code让一个人拥有一个小团队的开发能力，网站、App、后端API，都可以一个人搞定。

增长有多快

说几个数字。

Claude Code在2025年2月公开发布（研究预览版），5月正式GA。GA后仅6个月，达到10亿美元年化收入。这个速度在SaaS历史上极其罕见。

企业端采用也很快。Netflix、Spotify、DoorDash、Notion、Vercel都在内部大规模使用。Anthropic的数据显示，使用Claude Code的团队平均提效2-5倍。

当前Claude Code背后的模型有三个：

• Opus 4.6 — 推理能力最强，处理复杂任务和架构决策
• Sonnet 4.6 — 性价比最优，日常编码的主力
• Haiku 4.5 — 响应最快，适合简单查询和补全

这些数字背后的信号其实就一个：Agent式编程不再是极客的玩具，正在变成软件开发的标准方式。

全书路线图

全书按一条主线走：一个聪明人怎么在一周内从零用AI构建产品。

每章都有实操部分，可以跟着做。不用一口气读完，读一章、做一章、再回来读下一章，完全没问题。

下一章，我们花10分钟把Claude Code装好。

§02 10分钟完成安装

Get Started in 10 Minutes

安装过程比你想象的简单。这一章覆盖安装、使用环境选择、付费方案，以及你和Claude Code的第一次对话。

三种安装方式

macOS、Linux、Windows都支持。选哪个取决于你的系统：

装一下试试

macOS / Linux

打开终端（macOS用Terminal或iTerm2，Linux用你习惯的终端），运行：

curl -fsSL https://claude.ai/install.sh | bash

脚本会自动检测系统、下载二进制文件、把 claude 命令加到你的PATH。

装完输入 claude 就能启动。Homebrew用户也可以用 brew install --cask claude-code，效果一样。

Windows

Windows的安装多一个前置步骤：你需要先装Git for Windows。

winget install Anthropic.ClaudeCode

五种用法，选哪个

装完之后，其实有五种方式使用Claude Code。体验各有不同：

账号和钱的事

Claude Code需要Anthropic账号。首次启动时会自动弹浏览器让你登录或注册。

付费三档：

怎么选？一个简单标准：每天用超过2小时，Pro大概率会撞限额。这时候升Max 5x是值得的。$100/月听起来不少，但跟它省下来的时间比，挺划算。

企业用户还可以通过Anthropic API按token计费，适合有自定义集成或合规要求的团队。但对本书读者来说，直接订阅是最简单的开始方式。

说第一句话

装好了，账号也登录了。来试试。

mkdir ~/my-first-project && cd ~/my-first-project

claude

创建一个简单的HTML页面，显示"Hello, Claude Code!"，用好看的CSS样式。

open index.html    # macOS
xdg-open index.html # Linux
start index.html   # Windows

如果你能看到一个带样式的「Hello, Claude Code!」页面，恭喜，一切正常。

看起来简单，但注意它的意义：一句自然语言，AI完成了「理解需求 → 创建文件 → 编写代码」的完整循环。后面所有进阶操作都是在这个基础上展开的。

确认一切正常

跑一遍这个清单：

全部通过？可以开干了。

遇到问题了？

连不上、登录不了

Claude Code需要访问Anthropic的API服务器。国内网络环境下可能连不上，需要配代理：

# 设置HTTP代理（替换为你的代理地址）
export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890

建议把这两行加到你的shell配置文件（~/.zshrc 或 ~/.bashrc）中，这样每次打开终端都会自动生效。

安装时报Permission denied

macOS / Linux用户遇到权限错误，不要用 sudo。这么搞：

# 确保本地bin目录存在且有写权限
mkdir -p ~/.local/bin
# 重新运行安装脚本
curl -fsSL https://claude.ai/install.sh | bash

如果问题仍然存在，检查你的PATH中是否包含 ~/.local/bin。

怎么升级

Claude Code会提醒你有新版本。手动更新就重新跑一遍安装命令：

# Native Install用户
curl -fsSL https://claude.ai/install.sh | bash

# Homebrew用户
brew upgrade --cask claude-code

# WinGet用户
winget upgrade Anthropic.ClaudeCode

装VS Code扩展

想在VS Code里用Claude Code的话：

1. 打开VS Code的扩展市场（Cmd+Shift+X 或 Ctrl+Shift+X）
2. 搜索「Claude Code」
3. 安装Anthropic官方的扩展
4. 安装后在侧边栏会出现Claude Code的图标，点击即可开始对话

VS Code扩展底层调用的是同一个CLI，所以你不需要单独配置账号，登录状态是共享的。

装Desktop App

不习惯终端的用户可以用桌面应用。去 claude.ai/download 下载安装包，双击装好就行。本质上是终端CLI的图形界面包装。

装完了，账号登了，第一次对话也跑通了。下一章，正式开始做一个真实项目。

§03 你的第一个项目

Your First Project — Learning by Doing

理论讲完了，直接上手。这一章从零做一个真实的CLI工具。做完之后，你就真正理解对话式编程是怎么回事了。

做个什么

一个每日AI新闻聚合器，CLI工具。功能很简单：

• 从几个RSS源（TechCrunch AI、The Verge AI、Hacker News等）抓取最新文章
• 用AI总结每篇文章的要点
• 输出一份格式整齐的Markdown日报

为什么选这个？够小，一个下午能做完。又够完整，涉及网络请求、数据处理、AI调用、文件输出。一次项目就能把Claude Code的各种能力体验个遍。

第一步：告诉Claude你要什么 Describe What You Want

打开终端，进一个空文件夹，启动Claude Code：

mkdir ai-news-digest && cd ai-news-digest
claude

然后，用自然语言告诉Claude你想要什么：

# 你在Claude Code中输入的prompt：

帮我做一个AI新闻聚合CLI工具。需求如下：

1. 从以下RSS源抓取最近24小时的文章：
   - TechCrunch AI (https://techcrunch.com/category/artificial-intelligence/feed/)
   - The Verge AI (https://www.theverge.com/rss/ai-artificial-intelligence/index.xml)
   - Hacker News前30条 (https://hnrss.org/newest?q=AI&count=30)

2. 对每篇文章提取标题、链接、发布时间、来源

3. 按时间倒序排列，输出一份Markdown格式的日报到 output/ 目录

4. 用TypeScript写，用tsx直接运行

先别急着写代码，给我一个实现方案。

注意最后那句「先别急着写代码，给我一个实现方案」。这不是客气，是一个重要技巧：让Claude先想清楚再动手。

第二步：看它怎么想的 Review the Plan

Claude收到需求后，不会直接开写，会先给你一个方案。大概长这样：

我来帮你做这个AI新闻聚合工具。先说一下方案：

项目结构：
ai-news-digest/
├── src/
│   ├── index.ts          # 入口文件
│   ├── fetcher.ts        # RSS抓取逻辑
│   ├── formatter.ts      # Markdown格式化
│   └── types.ts          # 类型定义
├── output/               # 日报输出目录
├── package.json
└── tsconfig.json

技术方案：
- RSS解析用 rss-parser 库
- HTTP请求用 node内置的fetch
- 日期处理用 date-fns
- 用tsx直接运行TypeScript，不需要编译步骤

实现流程：
1. 并行抓取三个RSS源
2. 统一格式、过滤24小时内文章
3. 按时间排序
4. 生成Markdown格式日报
5. 写入 output/YYYY-MM-DD.md

需要我开始实现吗？

这时候你就是在看工程方案的产品经理。觉得行就说OK，想调整就直接说。比如：

# 你的反馈：
方案没问题。补充两点：
1. 日报里每篇文章除了标题和链接，加一句话摘要（从文章description里截取前100字）
2. 日报开头加一个统计：共收录X篇，来自Y个源

这个来回就是对话式编程的核心：Claude出方案，你补充细节，Claude修正。不用画流程图、不用写技术文档，直接用人话说。

第三步：看它干活 Watch Claude Work

确认方案后，Claude开始执行。终端里会看到一系列操作：

Claude wants to run: npm init -y
Allow? (y/n)

整个过程大约2-5分钟。你干嘛？看着就行。就像把任务交给新同事，前几次你会盯着看他怎么做事。等熟悉了他的风格，以后放心让他自己干就好。

第四步：看看结果对不对 Verify the Output

Claude干完了，跑一下看看：

npx tsx src/index.ts

如果一切顺利，你会在 output/ 目录下看到一个Markdown文件，内容大概是这样的：

# AI新闻日报 — 2026-03-28

> 共收录 23 篇文章，来自 3 个源

---

## TechCrunch AI

### OpenAI发布新版GPT-5.4，上下文窗口扩展至200万
🔗 https://techcrunch.com/2026/03/28/openai-gpt-54...
📅 2026-03-28 14:30
> OpenAI今日发布了GPT-5.4版本，最大的变化是上下文窗口从100万扩展至200万tokens...

### Anthropic推出Claude Code Desktop App
🔗 https://techcrunch.com/2026/03/28/anthropic-desktop...
📅 2026-03-28 11:00
> Anthropic宣布Claude Code正式推出桌面应用程序，支持macOS和Windows...

---

## The Verge AI
...

打开文件看看格式和内容。大多数情况下，第一次就能跑通。

如果报错了？直接把错误信息丢给Claude：

# 运行报错时，把错误信息粘贴给Claude：
运行报错了：
TypeError: Cannot read properties of undefined (reading 'map')
  at formatArticles (src/formatter.ts:15:23)

Claude会读错误信息、定位问题、改代码、再跑。这个报错到修复的循环，一般1-2轮就搞定。

第五步：加功能 Iterate and Improve

能跑了，但你想加点东西。继续用自然语言说就行：

# 第一个改进：加AI摘要
现在每篇文章的摘要是从description里截取的，比较粗糙。
改成用AI来总结：对每篇文章的标题+description，用Claude API生成一句话总结。
API key从环境变量 ANTHROPIC_API_KEY 读取。

Claude会修改代码，加入API调用逻辑。你验证后继续：

# 第二个改进：加定时运行
加一个cron模式，每天早上8点自动运行一次，用node-cron实现。
加一个命令行参数：
- `npx tsx src/index.ts` 立即运行一次
- `npx tsx src/index.ts --cron` 开启定时模式

# 第三个改进：加去重逻辑
有些文章在多个源里重复出现了。加一个基于URL的去重。

每一轮，Claude改代码、跑测试、确认结果。你始终只做两件事：说清楚要什么，验证结果。

到这里，第一个项目完成了。回头看看整个过程：

不管项目大小，不管是小工具还是完整产品，底层模式都是这五步。

一个重要的心态转变 The Mental Shift

做完这个项目，你应该有个直觉上的感受：你的价值不在于写代码，而在于定义要做什么、判断做得对不对。

很多工程师第一次用Claude Code时，本能地想看每一行代码、理解每个实现细节。正常反应，但它会让你变慢。

更高效的方式是把它当团队成员来管理：

不是说完全不管代码。而是你的注意力应该在更高层面：需求准不准确？方案合不合理？结果符不符合预期？这些才是你该花时间的地方。

新手常见困惑 Common Questions from Beginners

「代码看不懂怎么办？」

直接问它。「解释一下 fetcher.ts 的实现逻辑」，Claude会用人话讲清楚。还可以追问：「为什么用 Promise.allSettled 而不是 Promise.all？」它会解释背后的技术选择。

你不需要能写出这段代码，但需要理解它在做什么。就像你不用会修发动机，但得知道车在正常运转。

「写错了怎么办？」

直接说哪里不对。你不需要知道怎么改，描述现象就够了：

描述现象比定位代码行更有效。Claude可能发现问题根源不在你以为的地方。

「该管多少？」

四个字：信任但验证。让Claude去做，但每一步检查结果。方案阶段仔细看，确保方向对。编码阶段扫一眼文件结构就行。运行阶段看输出符不符合预期。改进阶段多测试边界情况：空数据、网络超时、格式异常。

这个分寸感做几个项目自然就有了。

「跑偏了怎么办？」

偏得不远，直接纠正：「停，不要用XXX库，换YYY。」偏得太远，按 Esc 停止，重新描述需求。按两次 Esc 会打开Rewind菜单，可以回滚对话、回滚代码改动，或者两者都回滚。

一个经验：纠正两次还不行，就果断停下来重来。在错误基础上打补丁只会越补越乱。

§04 核心工作流

Core Workflows — The Patterns That Matter

跑通第一个项目之后，你可能觉得Claude Code也就这样——写代码、确认权限、看结果。但日常用下来，真正拉开效率差距的是几个核心工作模式。这一章把它们拆开聊。

Plan模式：先想清楚再动手 Plan Mode

Boris（Claude Code的创建者）说过一句话：「一个好的计划真的很重要。」他自己大多数会话都从Plan模式开始。

Plan模式的作用很直接：让Claude只规划、不执行。它会告诉你它打算怎么做，但不会动你的代码、不会装包、不会运行命令。你们来回讨论方案，确认了再放手让它去做。

如何进入Plan模式

在Claude Code的输入框中，按两次 Shift+Tab。你会看到界面切换到Plan模式。此时Claude的行为会改变：

• 它可以读取文件来理解代码，但不会修改任何文件
• 它会给出详细的实现方案，包括要改哪些文件、怎么改
• 你可以反复讨论、修改方案

Plan模式的黄金工作流

Boris推荐的完整流程是这样的：

这个流程的精髓在于：把纠结放在Plan阶段解决完，执行阶段一气呵成。边做边改、反复返工是最浪费tokens的用法。

什么时候该用Plan模式

Auto模式：更安全的自动驾驶 Auto Mode

用了一阵Claude Code之后，你大概已经体会到那种「烦躁感」了。每次写文件要确认、运行命令要确认、装个依赖也要确认。按到第50次 y 的时候，你根本不看它要执行什么了。

Anthropic内部的数据证实了这一点：93%的权限请求被用户直接批准了。审批疲劳让安全机制形同虚设。

Auto模式就是为了解决这个问题。核心思路：用一个AI分类器替你做权限判断。安全操作自动放行，危险操作才拦截。

Auto模式的工作原理

Auto模式有两层防御：

输入层：一个Prompt Injection探测器会扫描Claude读取的所有内容（文件、网页、命令输出）。如果内容看起来像在试图劫持Claude的行为（比如某个文件里写着「忽略之前的指令」），探测器会在内容传给Claude之前附加一条警告。

输出层：一个Transcript分类器会在每个操作执行前评估它的风险。分类器分两个阶段运行：

• 第一阶段：快速判断（一个token的 yes/no），倾向于谨慎，有8.5%的误报率
• 第二阶段：只对第一阶段标记的操作做深度推理，把误报率降到0.4%

大部分安全操作在第一阶段就直接通过了，只有可疑操作才会触发第二阶段的深度分析。

Auto模式会拦截什么

Anthropic从内部事件日志中提炼出的真实案例：

• 范围升级 — 你说「清理旧分支」，Claude把远程分支也删了。Auto模式会拦截，因为「清理」这个词太模糊，不构成删远程分支的授权
• 凭证探索 — Claude遇到认证错误，开始自行在环境变量中搜索其他API token。会被拦截
• 绕过安全检查 — 部署命令预检失败，Claude用 --skip-verify 重试。会被拦截
• 数据外泄 — Claude想分享代码，自行创建了一个公开的GitHub Gist。会被拦截

如何启用Auto模式

# 启动时指定
claude --permission-mode auto

# 或者在运行中用 Shift+Tab 循环切换模式
# 默认 → Auto-accept edits → Plan → Auto → 默认
# Auto模式目前是Team plan的Research Preview功能

Auto模式 vs --dangerously-skip-permissions

你可能在社区里看到有人推荐用 --dangerously-skip-permissions 来跳过所有权限提示。两者的区别很关键：

Boris本人的做法是两者都不用。他用 /permissions 预授权安全命令（下一节会讲）。但对于大多数人来说，Auto模式是一个很好的平衡点。

权限管理：你来定规矩 Permission Management

Auto模式之外，Claude Code还有更精细的权限控制。

/permissions：预授权安全命令

输入 /permissions 打开权限管理界面。你可以预先允许Claude执行某些操作，这样它就不会每次都问你了。

支持通配符匹配：

# 允许运行所有npm脚本
Bash(npm run *)

# 允许编辑docs目录下的所有文件
Edit(/docs/**)

# 允许运行测试
Bash(npx vitest *)
Bash(npx jest *)

# 允许git操作
Bash(git add *)
Bash(git commit *)
Bash(git push)

这些规则可以保存到 .claude/settings.json 并提交到Git，让整个团队共享同一套权限配置。

三层权限选择

总结一下Claude Code的权限体系，从最省心到最精细：

刚开始用的时候，建议先用默认的逐个确认。等你跑了几个项目、知道Claude通常会执行哪些命令之后，再切换到Auto模式或配置白名单。

Git操作：Claude天然就懂 Git Operations

Claude Code对Git的理解不只是帮你跑 git 命令。它真的知道你项目当前的版本控制状态，知道你改了哪些文件、在哪个分支上。

一句话commit和PR

最常用的操作：

# 让Claude自己看看改了什么，写一个commit message
提交当前的改动，写一个有意义的commit message

# 或者更具体一点
commit这些变更，描述清楚我们添加了RSS抓取功能

# 直接创建PR
创建一个PR，标题和描述写清楚这个功能的作用

Claude会分析你的代码变更，生成一个描述性的commit message，然后执行 git add + git commit。创建PR时它还会自动生成PR描述，包括改了什么、为什么改。

Git Worktrees：并行工作利器

这是Boris的第一推荐技巧。Git worktree允许你在同一个仓库中同时checkout多个分支，每个分支有自己的工作目录。

# 创建一个worktree，在新目录中开始工作
claude --worktree

--worktree 标志会让Claude Code自动创建一个新的git worktree，在一个隔离的目录中工作。好处是：

• 不影响你当前分支的代码
• 可以同时开多个worktree，每个处理不同的任务
• 每个worktree有独立的工作目录，Claude不会互相干扰

这在多任务并行时特别有用。比如你在修一个bug的同时，想让Claude在另一个分支做一个新功能。用worktree，两件事互不干扰。

会话管理：别让上下文变成垃圾场 Session Management

Claude Code有上下文限制。对话越长，Claude对当前任务的注意力越分散。用好Claude Code，会话管理这件事比你想的重要得多。

核心命令速查

/clear 的使用时机

这个命令比你想象的更重要。/clear 会清空当前会话的所有对话历史，回到一个干净的起点。Claude Code启动时读取的CLAUDE.md和项目文件不受影响。

什么时候该用？当你要开始一个和之前对话完全不同的任务时。

比如你刚才在修一个API的bug，现在想让Claude帮你写一个新的前端组件。如果不clear，Claude的上下文里还残留着大量关于那个API bug的信息，会干扰它对新任务的理解。

/compact 和 /btw 的妙用

/compact 不是清空对话，而是让Claude把当前对话压缩成一个摘要。适合在一个长会话中途使用：你和Claude已经讨论了很多，上下文太长影响了性能，但你不想丢掉讨论的结论。/compact 会保留关键信息，释放上下文空间。

/btw 是一个容易被忽略但非常实用的命令。它开启一个「侧链」对话：你可以问Claude一个和当前任务不相关的问题，问完之后侧链结束，主对话的上下文不受影响。

比如你正在让Claude重构一段代码，突然想问「TypeScript的 Record 类型怎么用来着？」用 /btw 问，不会污染重构任务的上下文。

六个坑，你大概率会踩 Common Anti-Patterns

聊聊使用Claude Code时最常见的错误。这些坑我自己踩过，官方Best Practices也反复提，社区里更是老生常谈。

坑1：一个会话什么都塞

修bug、加功能、重构代码、写文档，全在一个会话里做。上下文被塞满，Claude对每个任务的理解都很浅。

一个会话聚焦一个任务。做完就 /clear，或者开新终端窗口。

坑2：反复纠正，越改越偏

Claude做错了一步，你纠正；改了又错另一个地方，再纠正；第三次还是不对。你花在纠正上的时间比自己动手还多。

纠正两次不行，果断 /clear 重来。重新描述需求，这次说得更具体。在一个已经跑偏的对话上修补，远不如推倒重来。

坑3：看着像对的就接受了

Claude写了一大堆代码，输出看着挺合理，你就接受了，没实际跑一下。过几天发现边界情况的bug。

每一轮改动都实际运行一次。「代码看起来对」和「代码是对的」差距可能很大。Boris说的第13条技巧就是：给Claude一种验证工作的方式。你自己也一样。

坑4：过度微操

Claude每写一个文件你都要看、每改一行代码你都要评论。结果你和Claude都很慢，而且你其实在用Claude Code做传统编程。

关注结果。让Claude把一个完整任务做完，看最终输出是否符合预期。中间过程除非明显跑偏，不用管。

坑5：需求模糊，然后怪Claude不懂你

「帮我优化一下这个代码」「让这个页面好看点」。Claude只能猜，而它猜的方向很可能不是你想要的。

给具体的、可验证的需求：「把这个API的响应时间从2秒优化到500ms以内，瓶颈在数据库查询，考虑加缓存或优化SQL」。越具体，输出越接近预期。

坑6：不写CLAUDE.md

项目根目录没有CLAUDE.md，或者有但从不更新。每次新会话都要重新解释项目背景、代码规范、技术选型。

这个太重要了，整整一章来讲。翻到§05。

§05 CLAUDE.md：给AI一张地图

CLAUDE.md — The Map You Draw for Your AI

Claude Code每次对话开始时会自动读取CLAUDE.md。这个文件不是说明书，它更像一份契约。你和AI之间关于怎么干活的约定，就写在这一个文件里。

为什么它是最重要的文件

用Claude Code写代码，你会接触到很多配置文件。package.json、tsconfig.json、.eslintrc...但有一个文件的重要性超过它们加起来。

CLAUDE.md。

原因很简单：Claude Code每次启动新会话，第一件事就是读这个文件。项目结构、代码风格、测试命令、常见陷阱，Claude都从这里了解。没有它，Claude就像空降到陌生代码库的新同事，什么都得从头摸索。有了它，它一进来就知道规矩。

Shrivu Shankar（Abnormal AI的AI战略VP，团队每月消耗数十亿tokens做代码生成）说得很直白：

他用了「宪法」这个词。宪法的特点是短、原则性强、不处理细节。这个类比很精确。

从护栏开始，别写手册 Guardrails, Not Manuals

新手写CLAUDE.md最常犯的错：试图写一本百科全书。把每个函数的用法、每个文件的作用、每个API的参数都塞进去。写了几千行，Claude光读这个文件就吃掉大量上下文，真正干活的空间反而被挤小了。

Boris（Claude Code的创建者）团队的CLAUDE.md只有大约2500 tokens，大概100行。管理Claude Code这个产品本身的核心规则文件，就这么短。

Shrivu分享了一个更有意思的做法：

这个方法好在哪？规则文件永远精准，因为每条都对应一个真实踩过的坑。文件也天然保持精简，因为你只记录真正出过问题的地方。

Boris在他的使用技巧中还提到一个飞轮效应：

他在代码审查时甚至会在同事的PR上@.claude，让它自动把某条规则加到CLAUDE.md里。团队共享一个CLAUDE.md文件，check进git，每周都有人贡献。这个文件是活的，不是写完就放那不管的。

Boris的原话：「Claude非常擅长为自己编写规则。」你告诉它犯了什么错，它自己就能写出精确的规则防止下次再犯。

CLAUDE.md到底该写什么

这可能是最实用的部分。判断标准就一条：Claude自己能从代码里读出来的，不要写；Claude猜不到的，必须写。

Shrivu补充了几个常见反模式：

不要用@引用大文档。在CLAUDE.md里@一个长文件，它会在每次会话开始时被完整嵌入，白白吃掉上下文。正确做法是提到路径，告诉Claude什么情况下去读。比如：「遇到FooBarError时，参阅docs/troubleshooting.md了解故障排除步骤。」

不要只写「永远不要做X」。当Claude觉得必须做X时它会卡住。永远提供替代方案：「不要用--foo-bar标志，改用--baz。」

把CLAUDE.md当作简化代码库的强制函数。如果某个CLI命令复杂到需要在CLAUDE.md里写几段话来解释，那说明这个命令本身需要简化。写一个bash包装器，用清晰的API，然后在CLAUDE.md里只记录那个包装器。

层级结构 Hierarchy

CLAUDE.md不只是一个文件，而是一套层级系统。Claude Code会自动按顺序读取多个位置的CLAUDE.md：

还有一个@引用语法，可以在CLAUDE.md中导入其他文件：

# CLAUDE.md
@docs/coding-standards.md
@docs/api-conventions.md

但注意前面说的：被@引用的文件会完整嵌入上下文。只引用那些真正每次都需要的短文件。

一个真实的好CLAUDE.md长什么样

下面是一个简洁精炼的项目级CLAUDE.md示例。注意它有多短：

# MyApp

## 架构
- Next.js 15 + TypeScript + Tailwind CSS
- 数据库：PostgreSQL + Drizzle ORM
- 认证：Better Auth
- 状态管理：Zustand（不要用Redux）

## 开发命令
- 启动开发服务器：pnpm dev
- 跑测试：pnpm test（Jest + React Testing Library）
- 类型检查：pnpm typecheck
- Lint：pnpm lint

## 代码风格
- 组件用函数式，不用class
- 样式用Tailwind，不要写CSS文件
- 数据获取用server component，不用useEffect
- 错误处理用error.tsx边界，不用try-catch包裹组件

## 常见陷阱
- Drizzle迁移后必须跑 pnpm db:generate，否则类型不同步
- 环境变量改了之后要重启dev server
- better-auth的session检查在middleware中，不要在页面组件里重复检查

## 不要做
- 不要安装新依赖除非我明确同意
- 不要修改 drizzle.config.ts
- 不要在client component中直接调数据库

整个文件不到300字。但每一行都有价值：要么是Claude猜不到的命令，要么是踩过坑的经验。没有一句废话。

Auto Memory：Claude自己记住的东西 Automatic Memory

除了你手写的CLAUDE.md，Claude Code还有一个自动记忆系统。

当你在对话中纠正Claude的行为，比如「以后commit message都用英文」「测试文件放在__tests__目录」，Claude会自动把这些偏好保存下来。下次对话它就记住了，不需要你再说一遍，也不需要你手动写进CLAUDE.md。

这些记忆存储在~/.claude/projects/<项目>/memory/目录下，以MEMORY.md为入口文件，和CLAUDE.md并行工作。区别是：

两者配合使用效果最好。团队规则写在项目CLAUDE.md里，个人习惯让Auto Memory自动处理。

迭代飞轮：越用越好的系统 The Iterative Flywheel

回到开头说的飞轮。这不只是个比喻，它就是Claude Code用户的真实体验曲线。

Mitchell Hashimoto（HashiCorp联合创始人，Terraform的创造者）描述过一模一样的过程。他给Ghostty搭建AI工作流时，配置文件里的每一行都对应agent过去犯过的一次错。文件是活的，一直在长。

这个过程是这样的：

这就是为什么说CLAUDE.md是最重要的文件。每一条规则背后都是一次真实踩过的坑，每次迭代都让Claude更懂你的项目。

§06 进阶对话技巧

Advanced Prompting & Context Engineering

Claude Code不是搜索引擎，你不需要精心雕琢关键词。但怎么跟它说话，确实会影响输出质量。这一章聊的都是实战中真正管用的对话策略，不讲理论。

怎么说话Claude才听得懂 Describing What You Want

很多人第一次用Claude Code，会写「帮我做一个用户管理系统」。Claude会做，但做出来的东西大概率不是你想要的。信息太少，它只能猜。

官方Best Practices总结了三条原则，我觉得确实管用：

看几个Before/After对比就明白了：

帮我加个搜索功能

在 src/components/Header.tsx 的导航栏
中添加搜索框，用 Fuse.js 做模糊搜索，
搜索范围是 posts 数组，参考现有的
FilterDropdown 组件的样式

接口报错了，帮我看看

POST /api/orders 在 quantity > 100 时
返回500，检查 src/api/orders.ts
的输入验证和数据库写入逻辑

优化一下性能

首页加载需要4秒，主要瓶颈在
Dashboard组件，它一次获取了所有用户
数据。改成分页加载，每页20条

Context Engineering：信息不是越多越好 Context Engineering

后面第十章会详细聊Harness Engineering的三层架构：Prompt、Context、Harness。这一节先聊Context。

Context不只是你打的那句话。CLAUDE.md的内容、Claude读过的文件、你粘贴的截图、对话历史，全部加起来都是Context。

直觉上你可能觉得：给Claude的信息越多越好吧？

恰恰相反。

Anthropic工程团队发现，上下文太多，模型表现反而变差。它会在海量信息中迷失，做出混乱的决策。Shrivu建议定期用/context命令看看上下文窗口的使用情况。他在monorepo里测过，一个新会话光加载基础配置就吃掉约20k tokens，剩下180k才是干活的空间。

你可以通过几种方式主动管理上下文：

• @引用文件：用@src/utils/auth.ts告诉Claude去读某个特定文件
• 粘贴截图：UI问题直接截图粘贴，比文字描述准确10倍
• Pipe数据：cat error.log | claude直接把日志喂给Claude
• 给URL：Claude可以读取网页内容，给它API文档的链接比复制粘贴更好

让Claude采访你 Let Claude Interview You

当你要做一个比较大的功能（比如从零搭建一个支付系统），不要一上来就写需求文档。先对Claude说：

我想做一个支付功能，在动手之前，先采访我，
问清楚所有你需要知道的事情。

Claude会开始问你一系列问题：支持哪些支付方式？需要处理退款吗？并发量预估多少？需要支持webhook回调吗？用什么货币？

这些问题中，至少有一半是你自己没考虑过的。Claude帮你做了需求分析师的工作。

采访结束后，让Claude把答案整理成一份Spec（规格文档）。然后关键来了：开一个全新的会话，把Spec喂给新的Claude，让它执行。

为什么要开新会话？因为采访过程中积累的对话历史已经很长了，占了大量上下文。新会话从一份干净的Spec开始，Claude能更专注地执行，不会被中间讨论过程干扰。

把Claude当高级工程师提问 Claude as Your Senior Engineer

很多人只把Claude Code当写代码的工具。其实它同样是一个极好的代码库导航员。

你可以直接问它：

• 「项目里的logging怎么工作的？」
• 「怎么新建一个API endpoint？」
• 「这个useAuth hook的调用链是什么？」
• 「src/lib/db.ts和src/utils/database.ts有什么区别？为什么有两个？」

Claude会读相关代码，然后给你一个结构化的解释。比读文档快，比问同事方便，尤其是刚接手一个新项目的时候。

Boris团队的人就是这么用的。新成员入职不是先读一堆wiki，而是直接问Claude Code。它对代码库的理解往往比过时的文档更准确。

多轮对话策略 Multi-turn Conversation Strategy

和Claude Code的对话不是一次性的。你经常需要在多轮对话中逐步推进一个任务。这里有几个经过实战验证的策略：

紧密反馈循环

别等Claude写完500行代码再看结果。发现方向偏了，立刻纠正。越早纠正成本越低。Claude写了10行时你说「不对，换个方式」，成本几乎为零。写完整个功能再推倒重来，浪费的是tokens和时间。

两次纠正不行，换条路

纠正了两次Claude还是不按你的意思来？别继续纠正了。/clear清掉上下文，用一个更好的初始prompt重新开始。在一个已经跑偏的对话里纠缠，往往越绕越远。

换任务就清上下文

写完一个组件后要去改数据库schema？/clear。不同任务有不同的上下文需求，把前一个任务的对话历史带进新任务只会增加噪音。Shrivu推荐的做法：/clear之后跑一个自定义的/catchup命令，让Claude读取当前git分支中的变更来恢复上下文。

用subagent做调研

有时你需要Claude先调研再动手：「看看这个库怎么用」「分析一下竞品的实现方式」。这些调研任务可以用subagent来做，调研结果返回主会话，中间的思考过程不会污染主上下文。

Effort级别：别省这个钱 Effort Level

Claude Code有四个effort级别：Low、Medium、High、Max。控制Claude执行任务时投入多少推理资源。

High本身就是默认值，Boris的做法是从不把它调低。理由和他坚持用Opus一样：Claude想得更深，需要返工的次数更少，总体效率反而更高。

很多人觉得「这个任务简单，调到Low省点时间」。但Low做错了，你纠正它花的时间可能比直接用High做对还长。

三个提问原则 The Art of Asking

和Claude Code对话的核心其实就三个字。

具体。文件名、行号、函数名、期望行为，能给就给。越具体的指令，越精确的输出。

指向。你代码库里一定有写得好的部分。把它们当参考范本指给Claude看。「像那个一样做」比「做一个漂亮的」有效100倍。

克制。一次只做一件事。任务大就分步来，每步确认结果后再下一步。一条消息里塞三个不相关的需求，Claude大概率只做好其中一个。

我觉得一个好的心态是：把Claude当成一个非常聪明但刚入职的同事。能力很强，但不了解你项目的历史和惯例。你给的上下文越精准，它的产出越接近预期。

§07 扩展能力：Skills、Hooks与MCP

Extensions: Skills, Hooks & MCP

用到后面你会发现，Claude Code真正的价值不是它本身有多强，而是你能在它身上接多少东西。Skills、Hooks、MCP三种扩展机制，让它从一个终端工具变成一个可以无限生长的工作台。

为什么需要扩展

我一开始以为Claude Code装好就完事了。后来发现自己总在重复同样的话：每次提交代码前念叨一遍「先跑个lint」、每次新建组件要交代一遍项目规范、每次查数据要手动复制SQL结果贴给Claude。

这种重复一旦超过三次，就该想办法自动化了。Claude Code提供了三种扩展机制，各自解决不同层面的问题：

三者的关系：Skills教Claude怎么做事，Hooks在关键节点自动执行检查，MCP把外面的世界接进来。我个人用得最多的是Skills，几乎每天都在加新的。

Skills：我觉得最值得先学的

Skills是最容易上手的扩展方式。原理简单到有点不像话：在 .claude/skills/ 目录下创建一个文件夹，放一个 SKILL.md 文件，Claude就会根据上下文自动加载里面的指令。

用 /skill-name 可以手动调用某个skill，Claude也会根据对话内容自动判断要不要加载。比如你说「帮我创建一个新的React组件」，Claude会自动加载 react-component skill里的规范。

两种类型的Skills

知识型：告诉Claude「这个项目里的事情应该怎么做」。比如API规范、编码风格、项目约定。这类skill更像文档，Claude读完会按里面的规则办事。

工作流型：告诉Claude「遇到这种任务按什么步骤执行」。比如 /fix-issue（修bug的标准流程）、/review-pr（代码审查流程）。这类skill更像SOP，有明确的步骤和检查点。

Boris有一个挺实用的判断标准：如果一件事你每天做超过一次，就应该把它变成skill或command。我自己更激进一点，超过两次我就写了。

工作流型skill的关键配置

工作流型skill通常会执行有副作用的操作（比如创建issue、发消息、部署）。为了防止Claude在不合适的时候自动触发，可以在 SKILL.md 的front matter中加一行：

---
disable-model-invocation: true
---

加了这个配置后，skill只能通过 /skill-name 手动调用，Claude不会自作主张地触发它。

安装别人的skill

Skills可以共享。Boris自己整理了一套高频使用的skills，你可以一行命令安装：

mkdir -p ~/.claude/skills/boris && \
curl -L -o ~/.claude/skills/boris/SKILL.md \
  https://howborisusesclaudecode.com/api/install

安装后你就拥有了Boris日常使用的工作流，包括他的commit规范、PR模板、代码审查标准等。社区也在不断贡献新的skills，你可以在Claude Code里用 /plugin 浏览市场。

Hooks：不是建议，是强制

Skills有一个天然的局限：它本质上是对Claude的「建议」。Claude会尽量遵守，但遵从率不是100%，尤其在长对话后期，它可能就忘了。大多数场景下够用，但有些事情你需要100%的确定性。

比如我自己踩过一个坑：在CLAUDE.md里写了「每次编辑文件后跑eslint格式化」，前几轮对话都好好的，聊到后面上下文一压缩，这条规则就被吃掉了。

Hooks就是为了解决这个问题。

Hooks vs CLAUDE.md：本质区别

很多人会把规则写在CLAUDE.md里：「每次修改文件后请运行 npx eslint --fix」。这在大多数时候有效，但Claude偶尔会忘记，尤其在长对话、上下文被压缩之后。

CLAUDE.md是建议，Hooks是强制执行。CLAUDE.md通过自然语言影响Claude的行为；Hooks是Claude Code平台层面的机制，在特定生命周期节点触发Shell脚本，Claude无法跳过或忽略。

生命周期钩子

Hooks支持多个触发时机：

实用案例

案例1：自动格式化。每次Claude编辑文件后自动跑eslint，不依赖Claude「记住」要格式化。

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "command": "npx eslint --fix $CLAUDE_FILE_PATH"
      }
    ]
  }
}

案例2：自动批准低风险操作。用PermissionRequest hook把权限请求路由到一个脚本，脚本判断操作类型，低风险的（读文件、运行测试）自动批准，高风险的（删除文件、推送代码）仍然弹出确认。

案例3：上下文压缩后注入关键指令。长对话中Claude会压缩上下文来节省token。压缩后，一些早期的重要指令可能丢失。PostCompact hook可以在压缩发生后自动把关键规则重新注入，确保Claude不会「失忆」。

案例4：推动Claude继续。有时候Claude会在一个复杂任务中途停下来问「要继续吗？」。Stop hook可以检测这种情况，自动让Claude继续执行，适合无人值守的批处理场景。

MCP：让Claude看到外面的世界

Skills教Claude知识，Hooks保证执行确定性，但它们都在Claude Code的内部世界运作。如果你需要Claude直接查数据库、调API、读取设计稿，就需要MCP。

MCP（Model Context Protocol）是Anthropic推出的开放标准，让AI工具能连接外部数据源和服务。把它想象成Claude Code的USB接口：插上不同的MCP服务器，Claude就获得了对应的能力。

添加MCP服务器

# 添加一个MCP服务器
claude mcp add slack -- npx -y @modelcontextprotocol/server-slack

# 查看已安装的MCP
claude mcp list

添加后，MCP服务器的能力会以「工具」的形式暴露给Claude。比如安装了Slack MCP后，Claude就可以搜索Slack消息、发送消息、创建频道。

实用MCP推荐

Boris有一个经典用法：他给Claude Code接上Slack MCP，当有人在Slack里报告bug时，Claude会自动读取bug描述、找到相关代码、尝试修复、提交PR，然后在Slack里回复「已修复，PR链接在这里」。整个过程不需要人工介入。

MCP配置文件

MCP的配置存在项目根目录的 .mcp.json 中，可以跟代码一起提交到Git仓库，这样团队成员clone项目后就自动获得相同的MCP配置。

// .mcp.json
{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_TOKEN": "${SLACK_TOKEN}"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "${DATABASE_URL}"]
    }
  }
}

Plugins：打包好的扩展包

Skills、Hooks、MCP可以各自独立使用，但组合起来才真正厉害。Plugins就是这种组合的打包形式。

在Claude Code里输入 /plugin，你可以浏览一个不断增长的插件市场。每个Plugin可能包含skills、hooks、agents、MCP配置中的一种或多种，一键安装就全部配置好。

比如一个「代码智能」Plugin，可能同时包含：

• 一个skill：告诉Claude如何利用符号导航理解代码结构
• 一个hook：编辑后自动运行类型检查
• 一个MCP：连接语言服务器获取精确的符号信息

这三者配合，让Claude在理解和修改代码时更准确，而你只需要一次安装。

Slash Commands：带预计算的快捷入口

除了 /skill-name 调用skill，还有一种更灵活的方式：Slash Commands。

Commands存在 .claude/commands/ 目录中。和skills不同的是，commands可以包含内联的Bash脚本来预计算信息。在Claude读到prompt之前，command先跑一些shell命令，把结果嵌入进去。

# .claude/commands/commit-push-pr.md

帮我完成以下操作：

1. 查看当前的git diff：
```bash
git diff --stat
```

2. 生成commit message并提交
3. 推送到远程分支
4. 创建Pull Request，标题基于commit内容

注意：PR描述要包含变更摘要。

输入 /commit-push-pr，Claude就会按照这个流程自动执行。因为command文件存在 .claude/commands/ 里，它会随Git一起提交，团队成员都能用。

三种扩展机制的协作

实际项目中，三种机制经常协同工作。一个完整的例子：

假设你的团队有这样一个工作流：收到bug报告 → 定位问题 → 修复 → 跑测试 → 提交PR → 通知相关人。

• MCP（Slack）让Claude收到bug报告并能回复修复结果
• Skill（fix-issue）指导Claude按标准流程定位和修复问题
• Hook（PostToolUse）确保每次修改后都自动跑测试和格式化

单独用任何一个都有价值，组合起来就是一个完整的自动化bug修复流水线。

§08 多Agent协作

Multi-Agent Collaboration

Claude Code最被低估的能力不是它写代码有多快，而是它可以同时跑很多个。学会并行之后，你的工作模式会从「一个人配一个AI」变成「一个人指挥一支AI团队」。

一个人为什么要开那么多窗口

Boris Cherny日常是这么干活的：本地开5个Claude Code实例（独立的git checkout），云端再开5到10个claude.ai/code网页会话，每个跑不同的任务。一个写新功能，一个修bug，一个写测试，一个重构，一个做代码审查。同时进行。

我一开始觉得这也太夸张了。后来自己试了才理解，这不是炫技，是Boris给团队的第一条生产力建议：做更多并行工作。

原因很直接：Claude Code的工作模式是「你给任务 → Claude花几分钟执行 → 你review结果 → 给下一个任务」。中间有大量等待时间。只开一个session，大部分时间你在等Claude干活。开5个session，你review第一个的时候其他4个还在跑，等待时间几乎降到零。

关键前提是：每个session需要在独立的代码环境中运行，否则它们会互相覆盖文件，制造冲突。这就是Git Worktrees要解决的问题。

Git Worktrees：并行的基础设施

Git Worktree允许你从同一个仓库创建多个工作目录，每个工作目录在不同的分支上，文件系统完全隔离。Claude Code对worktree做了原生支持：

# 启动一个在独立worktree中运行的Claude session
claude --worktree

# 在Tmux会话中启动（可以后台运行）
claude --worktree --tmux

每次运行 claude --worktree，Claude Code会自动创建一个新的worktree、切到一个新分支，然后在那个隔离环境中工作。完成后你可以把分支合并回主分支。

Tmux集成

加上 --tmux 参数，session会在一个Tmux窗口中启动，你可以用快捷键在不同session之间切换。Boris设置了shell别名来快速跳转：

# ~/.zshrc 中添加
alias za="tmux select-window -t claude:0"
alias zb="tmux select-window -t claude:1"
alias zc="tmux select-window -t claude:2"

za 跳到第一个session，zb 跳到第二个，以此类推。如果你用Desktop App，界面上有一个worktree复选框，勾上就行，不需要手动配置Tmux。

Subagents：给主session叫个帮手

并行session适合处理互不相关的独立任务。但有时候你要的不是开一个新窗口，而是在当前任务中调一个「专家」来处理特定环节，比如让一个安全审查专家review你刚写的认证代码。这就是Subagents干的事。

在 .claude/agents/ 目录下放一个 .md 文件，就定义了一个subagent：

每个agent文件可以定义自定义名称、工具集权限、权限模式，甚至指定使用的模型。比如安全审查agent可以配置为只有读权限（不能改代码），指定使用推理能力更强的模型。

Subagents的核心价值

Subagents最重要的特性不是「专业分工」，而是独立上下文。

每个subagent运行在自己的上下文窗口中，不消耗主session的上下文空间。当主session的对话已经很长、上下文快要满了的时候，调用一个subagent来处理子任务，相当于开了一个新的「思考空间」，不会挤压主session的容量。

你甚至可以在prompt中加上「use subagents」，让Claude主动判断什么时候该把子任务分配给subagent。这会让Claude投入更多计算资源来完成复杂任务。

Agent Teams：让它们自己协调

Worktrees让你手动管理多个并行session，Subagents让主session调一个专家。Agent Teams更进一步：多个session之间能互相通信、协调分工。

Agent Teams在2026年2月发布，目前是Claude Code最强大的协作模式。核心理念很简单：不是你来协调多个agent，而是让agent自己协调。我之前写过一篇用3个AI队友45分钟做红白机游戏厅的实测，就是用的这个功能。

Writer/Reviewer模式

最经典的用法是一个写代码、另一个审代码：

这个模式比单个agent写代码好不少。原因和人类团队一样：写代码的人容易陷入自己的思路，审代码的人能从不同角度发现问题。两个agent互相盯着，产出质量肉眼可见地提升。

测试驱动模式

另一个高效的模式：一个agent写测试，另一个写实现。写测试的agent先根据需求定义「什么是正确行为」，写实现的agent再去满足这些测试。这就是AI版的TDD（Test-Driven Development）。

Agent Teams会自动共享任务状态和消息，你不需要手动在agent之间复制粘贴信息。它们有一个team lead角色来协调分工和进度。

Fan-out批处理：人海战术的AI版

前面都是几个agent配合做一件事。Fan-out模式解决的是另一类问题：同一个操作需要对大量文件重复执行。

非交互模式

Claude Code支持非交互模式，用 -p 参数传入prompt，适合在脚本中调用：

# 非交互模式执行单个任务
claude -p "把这个文件从 JavaScript 迁移到 TypeScript"

配合shell循环，你可以批量处理：

# 批量迁移一批文件
for file in $(cat files-to-migrate.txt); do
  claude -p "Migrate $file from JS to TS" \
    --allowedTools "Edit,Bash(git commit *)" &
done

注意末尾的 &：这让每个Claude实例在后台并行运行。如果有50个文件要迁移，50个Claude同时跑，可能几分钟就完成了原本需要一整天的工作。

/batch 命令

如果你不想自己写shell脚本，Claude Code提供了 /batch 命令来简化这个过程：

这种模式特别适合大规模重构、代码迁移、批量修复等场景。一个人加Claude，抵得上一个工程团队花一周做的迁移工作。

不一定要盯着电脑

前面说的都是本地终端操作。但Claude Code也支持远程和异步执行，不用一直守在终端前面。

Remote Control

通过Remote Control功能，可以生成一个连接链接。在手机上打开这个链接，就能远程创建和管理本地的Claude session。适合通勤路上想启动一个任务、出门前让Claude跑起来的场景。Boris提到自己早上会用iPhone通过Claude移动App启动会话，之后在桌面继续。

Claude Code on Web

开发环境在云端的话（或者你只是想在浏览器里用），可以通过 claude.ai/code 直接在浏览器中运行Claude Code，不需要安装本地环境。

/schedule：云端定时任务

# 设定一个云端定时任务
/schedule "Check for outdated dependencies and create PRs"

/schedule 设定定时触发的Claude任务，在云端执行。电脑关机了任务照样按时跑。适合日常维护类工作：依赖更新、安全扫描、日报生成。

/loop：本地长时间运行

有些任务要跑很长时间（监控CI状态、持续集成测试）。/loop 让Claude在本地最多无人值守运行3天，你去做别的事，它在后台一直跑。

Anthropic自己怎么用的

Anthropic发布过一份白皮书「How Anthropic Teams Use Claude Code」，记录了内部各团队的真实用法。挑几个有意思的：

数据基础设施团队用Claude Code调试Kubernetes集群。Pod出问题时，让Claude读取日志、分析错误栈、定位根因、给修复建议。过去需要Senior工程师花很长时间排查的问题，Claude几分钟就能给出方向。

安全团队用Claude Code追踪复杂的控制流。安全审计需要跟踪一个请求从入口到数据库的完整路径，手动做极其耗时。他们让Claude自动追踪并生成调用链路图。

营销团队用Claude Code生成广告变体。一次活动需要几十个版本的文案和素材组合，过去设计师和文案要花好几天迭代。现在Claude批量生成，营销人员只做选择和微调。

但最让我意外的是法务团队的案例：一位律师用Claude Code搭了一个电话树系统（来电后自动路由到对应的法律顾问）。这位律师不是工程师，不会写代码，但从零搭建了这个系统并上线了。这个案例让我觉得，Claude Code的受众已经不局限于工程师了。

我自己摸索出来的几条经验

从2个session开始就好。不用一上来就开10个。先习惯在两个之间切换：一个做主任务，另一个做辅助的（写测试、做code review）。等觉得游刃有余了再加。

每个session给一个明确的角色。不要让所有session都做「随便什么任务」。给它们分工：这个负责前端、那个负责后端、那个专门跑测试。角色越清晰，你管理起来越轻松。

用git分支隔离一切。每个session在自己的分支上工作，通过PR合并。千万不要让多个session操作同一个分支，我试过一次，冲突解到怀疑人生。

定期扫一眼，不要完全放羊。并行不等于不管。每隔15-20分钟看看各个session的进度，及时纠偏。一个session跑偏了及时停掉，比让它跑完再返工划算得多。

§09 从零构建一个完整产品

Build a Complete Product from Scratch

前8章讲零件，这一章组装。用一个真实项目把前面学的东西全串起来，你会发现Claude Code真正的威力不在于某个单一功能，而在于它们连起来之后的化学反应。

为什么拿「AI周报助手」当例子

选这个项目我想了一会儿。好的教学案例得满足几个条件：真实有用（不是todo list这种永远不会打开第二次的东西）、复杂度适中（半天到一天能搞定，但涉及前后端+API+AI调用）、技术栈匹配（Next.js + Tailwind是Claude Code最擅长的组合）。

AI周报助手做的事情很直白：连接你的GitHub，获取本周所有commit，用AI总结成一份可读的周报页面，支持一键分享给同事。每个工程师每周五都在做的事，每次花半小时。我们要把它缩短到10秒。

这个项目会用到前面几乎所有章节的东西。不过你不需要全记住，跟着做就行。

Phase 0：先别急着写代码

我一开始做产品时犯过一个错：想到什么就立刻让Claude开始写代码。结果做到一半发现需求没想清楚，只能推翻重来。

后来我养成了一个习惯：先让Claude采访我。它其实很擅长这个。

claude "I want to build a weekly report tool. Before writing any code,
interview me to understand the requirements. Ask me questions one at a
time about target users, core features, and technical constraints."

Claude会开始像产品经理一样采访你：

• 目标用户是谁？（个人开发者？还是团队？）
• 核心功能有哪些？（只生成周报？还是也需要分享？）
• 技术偏好？（部署到哪里？用什么框架？）
• 有没有设计参考？（周报长什么样？）

回答完这些问题后，让Claude把结论整理成一份规格文档：

claude "Based on our discussion, create a SPEC.md file that captures
all requirements, user stories, and technical decisions."

这份SPEC.md是整个项目的锚点。后续所有开发都围绕它展开。

Phase 1：项目初始化

新session，干净的开始。一句话创建项目骨架：

claude "Create a Next.js project called weekly-report with Tailwind CSS.
Set up the basic folder structure following SPEC.md requirements.
Include TypeScript, and configure ESLint."

Claude会执行一连串操作：运行npx create-next-app、安装依赖、配置Tailwind、创建基础目录结构。你在终端里看到的是它自动执行的每一条命令和创建的每一个文件。

项目创建完成后，文件结构大致是这样的：

接下来是关键一步：配置CLAUDE.md。这是§05整章的核心，现在是实战：

# CLAUDE.md

## Project Overview
AI-powered weekly report generator. Connects to GitHub, summarizes
commits with AI, generates shareable report pages.

## Tech Stack
- Next.js 15 (App Router) + TypeScript
- Tailwind CSS for styling
- NextAuth.js for GitHub OAuth
- Claude API (via Anthropic SDK) for summarization

## Code Style
- Use server components by default, 'use client' only when needed
- API routes in app/api/, use Route Handlers
- Prefer named exports
- Error handling: always use try-catch in API routes

## Testing
- Run `npm run lint` before committing
- Test API routes with curl before building UI

有了这份CLAUDE.md，后续每次新session或新的对话，Claude都知道这个项目的技术决策和代码规范。不需要你每次都重新说明。

Phase 2：正式开发（最耗时但也最爽的部分）

到这里才真正开始写代码。我一般会先用Plan模式聊一轮架构，不急着动手。在终端里输入/plan切换到Plan模式：

"I need to implement the core flow: GitHub OAuth login → fetch this
week's commits → send to Claude API for summarization → display
the report. Let's discuss the architecture before coding."

Claude会给出一个完整的技术方案：API路由如何设计、数据流怎么走、组件怎么拆分。你可以在这个阶段提出疑问、调整方案。这就像是和一个高级工程师在白板前讨论。

确认方案后，退出Plan模式，让Claude开始实现：

"Plan looks good. Now implement it step by step. Start with GitHub
OAuth, then the commit fetching API, then the AI summarization."

Claude会按照讨论好的方案，逐步创建文件、写代码、安装必要的依赖包。你会看到它在终端里创建app/api/auth/[...nextauth]/route.ts配置NextAuth，然后创建lib/github.ts封装GitHub API调用，再创建app/api/summarize/route.ts接入Claude API。

每完成一个模块，做一次验证：

Phase 3：让它好看起来

功能跑通了，但界面大概率很丑。正常。我做任何产品都是先让功能跑起来，再管好不好看。

Claude Code支持图片输入。最直接的方式：截一张当前页面的图，粘贴给Claude：

claude "Here's a screenshot of the current report page.
[paste screenshot]
Issues: 1) The header is too cramped 2) The commit list needs
better spacing 3) Add a share button in the top right"

Claude会看到你的截图，理解当前的视觉问题，然后精准修改对应的CSS和组件代码。

这种「截图→反馈→修改」的循环非常高效。传统开发中，你需要在设计稿和代码之间反复对照；现在你只需要截图、说问题、等修好。

几轮迭代后，继续打磨响应式：

"Test the report page on mobile viewport (375px width). Fix any
layout issues. The share button should be full-width on mobile."

Claude会自己调整浏览器视口大小（如果你用了VS Code集成），或者直接修改Tailwind的响应式类名。

Phase 4：扩展能力实战

核心产品已经能用了。现在是§07内容的实战时间：给项目加上Skills、MCP和Hooks。

创建一个Skill

每次想生成周报，都要打开项目、执行一串操作。能不能一句话搞定？可以，用Skill。

在项目根目录创建.claude/skills/generate-report/SKILL.md：

# /weekly-report

Generate this week's report.

## Steps
1. Run the dev server if not running
2. Call /api/github to fetch commits since last Monday
3. Call /api/summarize to generate the report
4. Open the report page in browser
5. Show the shareable URL

配置完成后，在任何Claude Code session中输入/weekly-report，它就会自动执行以上所有步骤。一个命令，10秒出周报。这就是Skills的威力：把重复流程变成一键操作。

添加MCP：连接Slack

周报生成了，手动发到Slack频道太麻烦。用MCP把两者打通：

claude "Add a Slack MCP server so the generated report can be
automatically posted to #team-updates channel. Use the Slack
Web API with a bot token."

Claude会帮你配置MCP server，在.claude/mcp.json里注册Slack连接。配置完成后，你的/weekly-report skill可以加上最后一步：把周报内容发送到Slack。

设置Hook：自动Lint

最后一个扩展：每次Claude提交代码前，自动跑lint检查。

claude "Set up a pre-commit hook that runs ESLint and TypeScript
type checking. If there are errors, fix them before committing."

这样每次Claude Code执行git commit时，都会先确保代码质量。这是§07里Hook的典型用法：在关键节点注入自动检查。

Phase 5：部署上线

产品在本地跑得好好的，该让全世界都能访问了。

claude "Deploy this project to Vercel. Set up the environment
variables for GitHub OAuth, Claude API key, and Slack bot token.
Also create a GitHub Actions workflow that runs lint and type
check on every PR."

Claude会执行部署命令、配置环境变量、创建CI/CD配置文件。整个过程你不需要打开Vercel的dashboard，也不需要手写GitHub Actions的YAML。

部署完成后，你会拿到一个线上URL。在浏览器里打开，走一遍完整流程：登录→获取commit→生成周报→分享。确认一切正常。

如果你的团队也在用Claude Code，还可以加上一个额外步骤：

claude "Add a Claude Code Action to the GitHub repo that
automatically reviews PRs for code quality and potential bugs."

这样每次有人提PR，Claude会自动做code review，在PR上留评论。CI/CD的完整闭环就建立起来了。

回顾：这个项目用到了什么

回头看看，这个下午我们做了什么。一个完整的Web应用，从想法到上线，全部在终端里完成。

如果从头到尾比较顺利，整个过程大概需要5-8个小时。其中最耗时的是Phase 2（核心功能开发），OAuth配置和API调试需要反复验证，环境变量、回调URL这些琐碎的东西每个都可能卡你十几分钟。不顺利的话，一天也正常。

同样的项目，如果纯手写呢？一个熟悉Next.js和OAuth的全栈工程师大概需要2-3天。不太熟悉的话可能需要一周。差距不只是速度，更重要的是：你在整个过程中做的是产品决策而不是代码实现。你在思考「周报应该包含哪些信息」「分享页面需要登录吗」这些产品问题，而不是在Stack Overflow上查「NextAuth GitHub provider怎么配」。

我自己踩出来的几条经验

说点掏心窝子的话。

小猫补光灯做到App Store付费榜Top 1的时候，很多人问我是不是有一个开发团队。答案是没有。从第一行代码到上架审核，全部是AI写的。我从未手写过代码。

但这不意味着开发过程很轻松。恰恰相反，我踩过非常多坑，总结出来几条最核心的经验：

一、需求拆小，每次只给一步

新手最常见的做法：兴奋地把整个产品需求一股脑甩给Claude，「帮我做一个完整的XX应用，需要登录、数据库、付费、推送、分享...」Claude确实会开始做，但最终产出往往是一团乱。

我现在的做法是拆成最小可验证的步骤。先做登录，确认能跑。再做数据存储，确认能存能取。然后是核心业务逻辑，然后才是UI。每一步验证通过，再进下一步。

二、先跑通最小功能，再一步步加

和上一条有关系但不一样。拆小是关于怎么给Claude下指令，这一条是关于产品策略。

做小猫补光灯时，第一个版本只有一个功能：打开App，屏幕变白，亮度拉满。就这么简单。我拿它自拍了一张，确认补光效果还行，才开始加色温调节、亮度滑块、定时拍照这些功能。

用Claude Code也是一样。先做一个能跑的最简版本，自己用两天，发现真正需要什么再加。你脑子里想象的功能和实际用起来需要的功能，往往差异很大。

三、验证比开发更重要

这句话我反复强调。Claude Code写代码的速度很快，快到你可能会产生一种幻觉：它写得这么快，应该是对的吧？

不一定。AI生成的代码需要验证，就像人写的代码需要测试一样。区别在于：人写代码可能一天写200行，验证成本可控；Claude Code一小时能写2000行，如果你不验证，问题会在后面以更大的成本爆发出来。

我的做法是：每完成一个功能模块，立刻打开浏览器或跑测试。发现问题立刻修，不要积累。

四、不要在一个session里做太多不相关的事

Claude Code的每个session有上下文窗口限制。如果你在一个session里又改前端又调后端又配部署又修bug，到后面上下文会变得很混乱，Claude的回答质量会明显下降。

实际开发中，我通常这样分session：

• Session 1：项目初始化 + 基础架构
• Session 2：核心后端逻辑
• Session 3：前端页面和交互
• Session 4：测试和bug修复
• Session 5：部署和CI/CD

每个session专注做一类事情。session之间靠CLAUDE.md和代码本身传递上下文。这比在一个超长session里硬撑要高效得多。

五、产品感知才是你最大的杠杆

这条是最重要的。

Claude Code能帮你写代码、调UI、配部署、修bug。但它帮不了你决定：这个产品到底应该解决什么问题？目标用户是谁？什么功能该做什么功能该砍？

这些是产品判断。来自你对用户的理解、对市场的感知、对自己能力的诚实评估。AI能让你的执行速度提升10倍，但方向错了，你只是以10倍速度走向错误。

小猫补光灯能成功，不是因为它的代码写得好（代码非常普通），而是因为它精准地击中了一个真实需求：想自拍好看，但不想下载复杂的修图App。一个简单的补光功能，解决一个简单的问题。

我踩过的坑，你别踩了

列几个在实际产品开发中经常遇到的问题：

提前知道这些坑，能帮你省掉不少返工时间。

到这里，你已经具备了独立用Claude Code构建产品的能力。最后一章，聊几个更根本的问题。

§10 心智模型与持续进化

Mental Models & Continuous Evolution

工具会过时，功能会更新，但好的思维方式不会贬值。最后一章退后一步，聊几个我觉得比具体操作更重要的东西。

三层模型：你的时间该花在哪

讲了这么多具体操作，现在值得建立一个全局视角。Claude Code的所有能力，其实可以归入三个层次：

Prompt层是你在终端里输入的每一句话。「帮我加一个登录页面」「这个bug修一下」。大多数初学者的全部交互都停留在这一层。它有效，但每次都需要你开口，每次都从零开始。

Context层是Claude在回答你之前已经「看到」的所有信息。CLAUDE.md文件、项目的文件结构、git提交历史、package.json里的依赖列表。这些信息不需要你每次重复，Claude会自动读取。§05讲的CLAUDE.md，本质上就是在优化这一层。

Harness层是你构建的自动化环境。Skills让你把常用工作流封装成可复用的指令；Hooks让特定事件自动触发操作；MCP连接外部服务；Agent Teams让多个Claude实例并行协作。这一层的特点是：一旦搭好，它就一直在工作，不需要你每次手动触发。

初学者把所有精力都花在Prompt层，反复琢磨措辞、研究提示词技巧。这没有错，但天花板很低。高手的做法是：尽量把信息沉淀到Context层，把重复劳动交给Harness层，只在Prompt层处理真正需要临时决策的事情。

如果你读完这本手册只记住一件事，就记住这个：把时间花在构建Context和Harness上，而不是优化Prompt。

身份在变：从写代码到构建产品

这个变化比大多数人预期的要快。

Boris Cherny，Claude Code的创建者，公开说过自己超过90%的代码都由Claude Code生成。他的日常更多是：描述需求、审查输出、做架构决策。他有句话挺有意思：「我现在的工作更像是一个有技术判断力的产品经理。」

我自己的经历更极端。我从未手写过代码，所有产品都是用AI构建的，包括小猫补光灯（AppStore付费榜Top 1）。很多人听到会觉得不可思议，但真正用过Claude Code你就知道这完全合理。决定一个产品好不好的，从来不是代码有多精妙，而是需求定义得有多准确、用户体验有多流畅。

这意味着关键能力正在发生转移：

注意，我说的是「重要性下降」而不是「没用」。理解代码仍然有价值，它能帮你更好地描述需求、更准确地评审输出。但你不再需要能从零手写一个完整应用，你需要的是能判断一个应用写得好不好。

这个转变的核心问题是：从「怎么写」到「写什么」。

以前，你可能花80%的时间在「怎么实现这个功能」上，20%在「应该做什么功能」上。现在比例倒过来了。Claude Code解决了「怎么写」的问题，但「写什么」这个问题，它帮不了你太多。你需要自己想清楚：这个产品解决什么问题？目标用户是谁？核心体验是什么？哪些功能必须有，哪些可以砍掉？

迭代这么快，怎么跟

回看Claude Code的功能时间线，迭代速度确实很快：

平均每2个月一个大功能。这意味着你手上这本手册的某些具体操作步骤，可能在3个月后就需要更新了。

怎么跟上？我推荐几个稳定的信息渠道：

官方第一手信息：

• Claude Code官方changelog：每次更新都有详细说明
• Anthropic官方博客：重大功能发布会配深度文章
• Anthropic Academy：十余门免费课程，覆盖从基础到进阶

创建者和团队的分享：

• Boris Cherny的X账号（@bcherny）：Claude Code创建者，经常分享使用技巧和设计思路
• howborisusesclaudecode.com：Anthropic官方的实践指南页面
• 「How Anthropic Teams Use Claude Code」白皮书：官方团队的真实工作流

高质量播客访谈（了解设计哲学）：

• Lenny's Podcast：Boris深度谈产品设计和AI编程的未来
• Pragmatic Engineer：技术视角的深度对话
• YC Lightcone：创业者视角，聊AI工具如何改变构建产品的方式

真正该关注的不是具体功能变化，而是方向。过去一年半的演进，有三条线索始终没变：

1. 自主性持续增强。从需要你逐步指令，到能自主规划和执行。
2. 上下文窗口持续扩大。从8K到200K到1M，Claude能「看到」的项目规模越来越大。
3. 协作模式持续丰富。从单Agent到SubAgents到Agent Teams，多Agent协作越来越自然。

这意味着你今天学的「怎么和AI协作」不会过时。具体命令可能变，但「描述需求→审查输出→迭代改进」这个核心循环，在可预见的未来不会变。

推荐资源

如果你读完这本手册想继续深入，以下是我精选的资源清单。不多，但每一个都值得花时间。

必读

进阶

最后

写这本手册的时候，我时不时会想：AI编程的终局是什么？

想了很久也没想明白。但有一件事我比较确定：过去一年多，我用Claude Code构建了十几个产品，从iOS应用到Chrome扩展到PDF生成工具。每一个产品最终的质量，都不是由AI的能力上限决定的，而是由我对「什么是好的」的判断决定的。

AI可以在30秒内写出一个登录页面。但是否需要登录页面、登录后应该看到什么、什么样的体验才算流畅，这些只能由人来判断。

所以我的建议就一条：别花太多时间研究工具，去构建东西。找一个你真正想解决的问题，打开终端，开始和Claude对话。遇到卡住的地方翻翻这本手册，翻完继续做。

从想法到产品的距离，现在短到你可能还不太适应。