部分内容可能来自网络或者由AI生成。
如有雷同，纯属巧合，仅供学习参考之用。

---

一、书籍定位与核心主旨

《Claude Code 橙皮书》是目前国内最系统、最贴近工程实战的 AI 编码 Agent 专业手册。本书区别于普通 AI 工具速查教程，不局限于基础指令讲解，核心目标是帮助开发者完成从「手动写代码」到「驾驭 AI 自主完成工程」的身份跃迁，从零掌握 Claude Code 的底层逻辑、标准工作流、高阶工程技巧与团队落地方案。

全书核心主旨：Claude Code 不是代码补全工具、不是聊天机器人，而是具备自主感知项目、工具调用、文件修改、命令执行、自我纠错能力的终端编程智能体。普通开发者用它提速，高阶开发者用它搭建「一人工程团队」，实现十倍级工程效率提升。

核心认知颠覆：AI 编程的瓶颈从来不是模型能力，而是使用者的工程思维、上下文管理能力、任务拆解能力与规范约束能力。工具上限由模型决定，下限由使用者的方法论决定。

二、核心概念：重新认识 Claude Code

1. 本质定义

Claude Code 是运行在终端的工程级 AI Agent，拥有完整的项目感知与工具执行权限，可直接读取项目结构、解析代码逻辑、批量增删改文件、运行终端命令、修复报错、提交代码、优化架构，实现端到端自主开发。

与普通对话式 AI、IDE 补全工具的核心区别：普通 AI 只给答案，Claude Code 直接落地执行。

2. 两大核心运行模式（全书重点）

（1）Plan 规划模式（专家首选）

核心逻辑：先规划、后执行，先论证、再落地。启动任务后，Claude Code 只会分析项目、梳理方案、拆解步骤、评估风险、列出修改清单，不会改动任何代码。使用者审核方案无误后，再允许执行。

适用场景：复杂功能开发、架构重构、代码大规模迭代、线上项目修改、不确定需求开发，是规避 AI 乱改代码、破坏项目的核心手段。

（2）Auto 自动模式（快速迭代）

核心逻辑：用户给出需求后，AI 自主完成分析、编码、调试、修复全流程，无需人工分步干预。

适用场景：简单功能开发、Bug 修复、格式优化、代码精简、配置修改等低风险场景。新手慎用，极易出现过度修改、逻辑冗余、破坏原有业务的问题。

3. 权限与安全体系

Claude Code 拥有终端执行、文件读写、命令调用权限，因此权限管控是核心基础。书中明确核心准则：高权限操作必须人工确认，陌生项目禁止全开自动权限，避免误删文件、篡改配置、执行危险命令。

三、新手入门：基础能力与核心指令体系

全书入门篇聚焦「能用、不踩坑」，梳理了高频核心指令与基础操作规范，是所有高阶能力的基础。

————书籍摘要————

01 为什么是Claude Code

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

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

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

◆ 当前Claude Code背后的模型有三个：
Opus 4.6 — 推理能力最强，处理复杂任务和架构决策
Sonnet 4.6 — 性价比最优，日常编码的主力
Haiku 4.5 — 响应最快，适合简单查询和补全

02 10分钟完成安装

◆ 安装过程比你想象的简单。
◆ 保持更新。Claude Code迭代极快，几乎每周都有新功能。新版本不只是修bug，经常带来能力上的明显提升。建议至少每两周更新一次。

03 你的第一个项目

◆ 从现在开始，你是产品经理，Claude是你的工程师。你的活是说清楚要什么，不是写代码。哪怕你是资深程序员，也请先按这个方式来一遍。

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

◆ 需求描述的质量直接决定输出质量。几个原则：说清楚最终产物长什么样（Markdown日报）、指定技术选型（TypeScript + tsx）、给具体数据源URL而不是说「几个RSS源」。越具体越好。
◆ 第二步：看它怎么想的 Review the Plan
◆ 第三步：看它干活 Watch Claude Work
◆ 第四步：看看结果对不对 Verify the Output
◆ 第五步：加功能 Iterate and Improve

◆ 你的价值不在于写代码，而在于定义要做什么、判断做得对不对。

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

◆ 这一章的核心：描述需求、审查方案、确认执行、验证结果、迭代改进。你管要什么和好不好，Claude管怎么实现。这个分工形成默契之后，生产力会有质的变化。

04 核心工作流

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

◆ 一条实用判断标准：如果你需要跟同事解释才能让他做的任务，就值得用Plan模式。如果你能用一句话说清的任务，直接做就行。

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

◆ Auto模式 vs --dangerously-skip-permissions

◆ Boris的做法：不用Auto模式也不跳过权限，而是用 /permissions 仔细配置一套白名单。白名单会check进git，和团队共享。这是最精细也最安全的方案，只是初始配置需要花点时间。

◆ Git worktree允许你在同一个仓库中同时checkout多个分支，每个分支有自己的工作目录。创建一个worktree，在新目录中开始工作 claude --worktree

◆ Claude Code的Computer Use功能让Claude直接看到你的屏幕截图，然后操控鼠标和键盘。不是模拟，不是调API，是真的在看你的屏幕、移动你的光标、点击你的按钮。

◆ AI的操作边界从「能写代码的地方」扩展到「屏幕上看得到的一切」。这是一个质变。

◆ Computer Use现阶段最好的定位是：把它当成一个耐心但手速慢的测试员。给它那些「按照固定流程重复操作」的任务，它做得很好。需要灵活判断和快速反应的，还是自己来。

◆ Voice说需求，Computer Use执行操作。人可以完全脱离键盘和代码，纯靠说话让AI帮你构建东西。

◆ 一个实用的组合：语音快速启动任务（「帮我做个XXX」），然后切回键盘输入精确的细节和约束条件。两种交互方式混着用，比纯用一种效率高。

◆ 坑1：一个会话什么都塞

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

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

◆ 坑4：过度微操

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

◆ 坑6：不写CLAUDE.md

◆ 这一章的核心：Plan模式想清楚再动手，Auto模式减少审批疲劳，/permissions精细控权限，Git集成管版本，会话管理保持上下文干净。这五个工作流覆盖90%的日常场景。剩下10%的高级用法后面几章展开。

05 CLAUDE.md：给AI一张地图

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

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

◆ 每次Claude犯错，就加一条规则。这就是「从护栏开始」的意思。

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

◆ Claude自己能从代码里读出来的，不要写；Claude猜不到的，必须写。

◆ 不要用@引用大文档。在CLAUDE.md里@一个长文件，它会在每次会话开始时被完整嵌入，白白吃掉上下文。正确做法是提到路径，告诉Claude什么情况下去读。

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

◆ 1 全局级 ~/.claude/CLAUDE.md
放你个人的通用偏好。比如：优先用TypeScript、测试框架偏好Jest、commit message用英文。这些规则在所有项目中生效，不需要每个项目都写一遍。
2 项目级 ./CLAUDE.md
放项目特有的规则。这个文件应该检入git，团队成员共享。Boris团队就是这么做的。代码风格、架构约束、测试命令、常见陷阱，全在这里。
3 子目录级
monorepo场景下特别有用。前端目录放前端的规则，后端目录放后端的规则，互不干扰。Claude进入某个目录时会自动加载对应的CLAUDE.md。
还有一个@引用语法，可以在CLAUDE.md中导入其他文件：
@docs/coding-standards.md @docs/api-conventions.md
但注意前面说的：被@引用的文件会完整嵌入上下文。只引用那些真正每次都需要的短文件。

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

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

◆ 一句话总结：CLAUDE.md从空文件开始，每次犯错加一条，保持精简（Boris团队只用了约2500 tokens），检入git与团队共享。用三个月养出来的那个文件，是你最有价值的AI资产。

06 进阶对话技巧

◆ 1 具体化：指定文件、场景、偏好

◆ 2 指向已有模式：「照着这个做」

◆ 3 描述症状，不要猜原因

◆ 上下文管理的核心原则：不是给所有信息，而是给对的信息。

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

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

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

07 扩展能力：Skills、Hooks与MCP

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

◆ 三者的关系：Skills教Claude怎么做事，Hooks在关键节点自动执行检查，MCP把外面的世界接进来。

◆ 知识型：告诉Claude「这个项目里的事情应该怎么做」。比如API规范、编码风格、项目约定。这类skill更像文档，Claude读完会按里面的规则办事。
工作流型：告诉Claude「遇到这种任务按什么步骤执行」。比如/fix-issue（修bug的标准流程）、/review-pr（代码审查流程）。这类skill更像SOP，有明确的步骤和检查点。

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

◆ Hooks：不是建议，是强制

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

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

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

◆ Skills vs Commands选择指南
两者有重叠，但定位不同。Skills更像「知识和能力」，Claude根据上下文自动应用或手动调用；Commands更像「宏」，包含预计算步骤，强调执行流程。经验法则：如果需要Claude「知道什么」，用skill；如果需要Claude「做一串事」，用command。

08 多Agent协作

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

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

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

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

Worktree：在一个项目同时修复多个问题，即开多个分支每个分支修复一个问题。subagent : 在同一件事，可能需要多个牛马完成时，可以使用多个subagent 。agent teams ：在上述概念之上，可以比作外包公司，你可以给他们项目，他们自己拆分工作，无非就是走上面的worktree subagent，重点是他有自己的协调能力，而不是一个人在协调。

◆ Boris的总结我很认同：把并行工作想象成管理一个远程团队。你不需要盯着每个人写每一行代码，但你需要清楚每个人在做什么、进度如何、有没有卡住。你的工作从写代码变成了做项目管理。

09 从零构建一个完整产品

◆ 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会执

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

◆ # CLAUDE.md
略

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

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

◆ 每做完一步就验证，这是我踩过最多坑之后总结出来的最重要的习惯。不要让Claude一口气写完所有代码再测。问题越早发现越容易修。我曾经让它连续写了8个文件，最后发现第2个文件的API路由就写错了，后面全废了。

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

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

◆ 添加MCP：连接Slack

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

◆ Phase 5：部署上线
产品在本地跑得好好的，该让全世界都能访问了。

10 心智模型与持续进化

◆ 工具会过时，功能会更新，但好的思维方式不会贬值。

◆ Prompt层是你在终端里输入的每一句话。

◆ Context层是Claude在回答你之前已经「看到」的所有信息

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

◆ 尽量把信息沉淀到Context层，把重复劳动交给Harness层，只在Prompt层处理真正需要临时决策的事情。

◆ 把时间花在构建Context和Harness上，而不是优化Prompt。

◆ 实操建议：重要的约束和要求，写进CLAUDE.md而不是只在对话里说一次。对话会被压缩，但CLAUDE.md每次都会重新读取。这也呼应了前面「三层模型」里的结论：把信息沉淀到Context层

◆ 怎么跟上？我推荐几个稳定的信息渠道：
官方第一手信息：
• 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协作越来越自然

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