这可能是目前最“工程师视角”的 Claude Code 教程

1）最重要的习惯：先想清楚，再让它写

很多人一上来就“把脑子里的想法一股脑倒进去”，然后期待 Claude 自己补全架构、补全约束、补全边界。结果通常是：

• 写了一堆你没要的抽象
• 结构看起来“很工程”，但后面改起来很痛
• 你 debug 的时间比你亲手写还长

作者给的解法很朴素：先用 Plan Mode 把事情想明白。

你真正要做的是把“我要什么”说成“工程可执行的规格”，像这样：

• ❌ “给我做个登录系统”
• ✅ “用现有 User 模型做邮箱+密码登录，会话放 Redis，24 小时过期，/api/protected 下面的路由都要中间件保护”

差别在于：你给的是“结果”，还是“实现边界 + 约束 + 验收标准”。 Claude 最怕你只给结果，因为它会自己脑补路径，而且经常脑补过头。

一个实用经验： 你在 plan 里多花 5 分钟讲清楚，能省掉后面几小时的返工和对齐。

2）CLAUDE.md 是你的“杠杆”，但别写成说明书

CLAUDE.md 是 Claude 每次开始干活前都会读的“项目入门材料”。 它会直接影响 Claude 的默认决策，比如它喜欢怎么组织代码、用什么命令、遵循什么约定。

但作者也提醒：多数人要么不写，要么写成“新员工入职文档”，然后效果反而变差。

怎么写才有用

原则就四个：

1. 短：别写长篇大论。模型的“可稳定遵循的指令量”是有限的，你写太多它会开始随机忽略。
2. 只写项目特有的东西：别解释“components 是什么”，Claude 知道。要写“我们项目里哪些东西坑最多、哪里最容易犯错、正确姿势是什么”。
3. 说清原因：只写“要做什么”不够，加一句“为什么要这样做”，Claude 的判断会稳很多。比如“必须 strict，因为我们被隐式 any 坑过线上 bug”。
4. 持续更新：你如果发现自己第二次纠正 Claude 同一个点，就别再口头纠正了，直接写进 CLAUDE.md，让它以后自动记住。

作者给了一个很形象的对比：

• 差的 CLAUDE.md：像写给新人看的规范文档
• 好的 CLAUDE.md：像你明天会失忆，留给自己“最关键的工作备注”

3）上下文窗口不是“快满了才糟”，而是“用到一半就开始变钝”

很多人误以为：上下文 200k tokens 很大，可以一直聊一直堆。 作者说实际体验是：质量会在使用到 20%–40% 的时候就开始下降，后面越堆越糟。

你看到的典型症状就是：

• Claude 开始前后矛盾
• 修一个 bug 引出两个新 bug
• 你越解释，它越混乱
• /compact 之后也没有明显变好

关键点：压缩不是“恢复智商”，只是把大段内容变成摘要。 如果模型已经因为上下文臃肿而变钝，compact 只能缓解一点点。

怎么解决上下文退化

作者给了几招，都是“工程习惯”：

• 一个会话只做一件事：不要在同一聊天里既做 auth 又重构数据库。上下文会串味。
• 外部记忆：让 Claude 把计划、进度写进文件，比如 PLAN.md、TODO.md。第二天继续干，读文件就能续上，不靠聊天历史硬扛。
• 复制-重置法：当对话变臃肿时：

1. 把关键内容复制出来
2. /compact 让它总结
3. /clear 清空
4. 只把关键内容粘回去

你会得到一个“干净但保留要点”的新上下文，通常比硬聊下去好很多。

• 该清就清：如果对话跑偏了，不要试图把它救回来，直接 /clear。你还有 CLAUDE.md，不会真从零开始。

作者的心智模型很关键： Claude 是无状态的。你不给，它就不知道。 所以不要指望它“自己会记得你上次说过啥”。

4）提示词不玄学，本质是“你会不会写需求”

作者说得很直白：很多人花时间学框架、学工具，却不学怎么跟“真正写代码的对象”沟通。

好的提示词通常包含三类信息：

1. 我要什么：目标明确，可验收
2. 不要什么：比如不要过度工程化，不要新增一堆抽象，不要拆成 12 个文件
3. 为什么：这是生产级、性能敏感，还是一次性原型，影响它的取舍

你越不说清楚，Claude 就越会按自己的偏好“替你做决定”。 而它的偏好往往是“更完整、更灵活、更可扩展”——也就是你最不想要的那种复杂。

5）“输出差”很多时候是输入差，别急着怪模型

作者态度挺狠：如果你用的是很强的模型（比如 Opus），还一直出烂活，优先反思你的输入。

他的意思不是“模型没差别”，而是：现在模型差别更像“加成”，真正的瓶颈多在你这边：

• 任务拆解
• 约束表达
• 上下文管理
• 输出复核

6）模型怎么选：Opus 用来想，Sonnet 用来干

作者给了一个现实的分工方式：

• Opus：更适合规划、权衡取舍、做架构决策
• Sonnet：更适合执行，实现已经想清楚的方案（更快更便宜）

一个实用流程是： 先 Opus 把 plan 和边界定下来，再切 Sonnet 把活干完。 CLAUDE.md 会让两个模型在同一规则下工作，交接不会太乱。

7）工具很多，但别把自己搞成配置狂

MCP、Hooks、自定义命令、各种配置……作者的建议是：

• 你不需要一上来全上
• 但你应该定期试试，因为这些东西能把“重复劳动”自动化掉

几个更落地的解释：

• MCP：把外部信息（GitHub、Slack、数据库、API）直接接进 Claude，减少你复制粘贴
• Hooks：让格式化、类型检查、lint 之类的动作自动跑，避免 Claude 改完你才发现一堆问题
• 自定义 slash 命令：把你常用的一段提示词封装成命令，比如 review、debug、deploy

8）Claude 卡住时，别硬顶，换策略

典型“卡住”就是：它开始循环试错、或者越改越错。 作者说这时候更有效的做法通常是：

• /clear 直接重来
• 把任务拆小
• 给一个最小示例，让它照着扩展（“你看输出应该长这样，把其它地方也按这个模式改”）
• 换一种表述方式重新 framing

一个判断标准很实用： 同一句话你解释三遍它还不懂，继续解释大概率没用。换打法。

9）最高阶玩法：把 Claude 变成你系统里的一个环节

作者最后强调：最有价值的用法不是“问一次、写一次”，而是把 Claude 当作工作流里的一个组件。

Claude Code 有 headless 模式（-p），可以脚本化、流水线化，比如：

• 自动 PR review
• 自动更新文档/日志
• 自动处理支持工单

而且它有“飞轮效应”：

Claude 犯错 → 你复盘日志 → 你改 CLAUDE.md / 工具 → 下次更好 模型不变，系统会越跑越顺。

你可以直接照做的“最小落地清单”

如果你只想马上变好，不想学一堆概念，就做这 6 件事：

1. 每个任务先写 10 行 plan，明确目标、范围、约束、验收点
2. 把项目特有规则写进 CLAUDE.md，保持短且可执行
3. 一个会话只做一件事，做完就结束
4. 质量开始飘就 /clear，用复制-重置法重建干净上下文
5. 提示词里写清楚“不要做什么”，防止过度工程化
6. 让 Claude 把进度写进 PLAN.md / TODO.md，第二天直接续上

全文翻译

作者：X 上的 Eyad：

“The complete claude code tutorial”

我做软件工程师已经 7 年了，先后在 Amazon、Disney 和 Capital One 工作过。 我写过的代码服务过数百万用户，我构建过不能出任何问题的系统。

现在，我是一家为企业构建 Agent 的创业公司 CTO，而 Claude Code 是我每天都在用的主力工具。

下面是一份新手入门手册，汇集了我使用 Claude 构建、并维护大型公司复杂系统过程中学到的全部经验。 如果你觉得有帮助，欢迎在下面告诉我。

先思考，再动手（Think First）

大多数人一用 Claude Code 或其他 AI 工具，第一反应就是开始打字（或者开始说话）。 但这很可能是你一上来就会犯的最大错误之一。

你真正应该做的第一件事，是先思考。

10 次里有 10 次，我在 plan mode（计划模式）里得到的结果，都明显好于我一上来就随便输入需求的情况。 差距非常明显。

当然，对你们中的一些人来说，“先思考”这句话说起来容易，做起来很难。 你可能并没有多年的软件工程经验，没法自己把系统设计想清楚。

对此，我有两个建议：

1. 开始学习。

如果你从来不去补这些基础，你其实是在给自己设置上限，哪怕你只是每天学一点点。

2. 和 ChatGPT / Gemini / Claude 进行深入的来回对话。

你需要清楚地描述你想构建什么，让 LLM 给你不同的系统设计方案，然后你们一起讨论，最终确定一个方案。 你和 LLM 应该是双向提问，而不是单向下指令。

这个原则适用于一切事情，哪怕是很小的任务，比如总结一封邮件。

在你让 Claude 构建一个功能之前，先想清楚架构。 在你让它重构代码之前，先想清楚最终形态应该是什么。 在你让它 debug 之前，先想清楚你已经掌握了哪些线索。

你在 plan mode 里给的信息越多、越清晰，Claude 的输出就越好。 因为输入本身就更好了。

这个模式非常稳定： 先思考，再输入，效果远好于先输入、指望 Claude 自己想明白。

这也引出了我接下来要讲的一个重点：架构（Architecture）。

在软件工程中，架构有点像是只给一个人最终结果，却不给任何过程约束。 这就给了实现路径极大的自由度。

而这，正是 AI 生成代码最大的问题之一。

举个例子：

• 你说：

> “给我做一个认证系统”

• 对比你说：

> “使用现有的 User 模型，实现邮箱 + 密码登录； > 会话存储在 Redis 中，有 24 小时过期时间； > 并添加中间件，保护 /api/protected 下的所有路由。”

这两种输入，差别非常明显。

在 Claude Code 里，按两次 Shift + Tab，你就能进入 plan mode。 相信我，这可能只会花你 5 分钟， 但能帮你省下数小时甚至数天的 debug 时间。

CLAUDE.md 文件（Markdown）

CLAUDE.md 是一个 Markdown 文件。 Markdown 是一种 AI 非常擅长处理的文本格式，而 Claude 对 Markdown 的理解尤其好。

当你开启一个 Claude Code 会话时，Claude 做的第一件事，就是读取你的 CLAUDE.md 文件。 这个文件里的每一条指令，都会影响 Claude 如何理解和处理你的项目。

它本质上是 Claude 在每一次对话开始前都会阅读的入职培训材料。

但大多数人要么完全忽略它，要么往里面塞一堆垃圾信息，反而让 Claude 变得更差。

这里存在一个临界点： 信息太多或太少，都会让模型输出变差。

真正重要的只有这些：

保持简短

Claude 在同一时间内，大概只能可靠地遵循 150–200 条指令。 而 Claude Code 的系统提示本身，就已经占掉了大约 50 条。

你往 CLAUDE.md 里加的每一条指令，都是在争夺注意力。 如果你的 CLAUDE.md 像一本小说，Claude 会开始随机忽略其中的一些内容，而你根本不知道它忽略了哪些。

只写与你项目相关的内容

不要去解释什么是 components 文件夹。 Claude 知道什么是 components。

你应该告诉它的是那些奇怪但关键的东西，比如：

• 真正重要的 bash 命令
• 你们项目里特有的工作流
• 那些一旦做错就会出问题的约定

凡是属于你日常工作流的一部分，都应该写进去。

讲清楚“为什么”，不只是“做什么”

Claude 在这一点上有点像人。

当你告诉它为什么要这样做， 它往往比只告诉它“要做什么”，执行得更好。

比如：

• “开启 TypeScript strict 模式” —— 可以
• “开启 TypeScript strict 模式，因为我们之前在生产环境中被隐式 any 类型坑过” —— 更好

这个“为什么”会给 Claude 提供判断上下文， 让它在你没想到的地方，也能做出更合理的决策。

你会惊讶于这有多有效。

持续更新它

在 Claude Code 工作时，按下 # 键，Claude 会自动把新指令写进你的 CLAUDE.md。

一个非常重要的信号： 如果你发现自己第二次纠正 Claude 同一个问题， 那就说明这条规则应该写进文件里。

随着时间推移，CLAUDE.md 会变成一份真实反映你代码库运作方式的活文档。

坏的 CLAUDE.md： 看起来像写给新同事的正式文档。

好的 CLAUDE.md： 看起来像你知道自己明天会失忆，于是留给自己的速记笔记。

上下文窗口的限制（The Limitations of Context Windows）

举个例子，Opus 4.5 的上下文窗口是 200,000 tokens。

但大多数人没意识到的一点是： 模型在远没用满之前，就已经开始退化了。

（具体退化点会因为你是通过 API 还是桌面端使用而有所不同。）

通常在 20%–40% 的上下文使用量 时， 输出质量就已经开始下降了，只是你未必立刻察觉。

如果你经历过这种情况： Claude Code 已经压缩过上下文了，但输出依然很差， 原因就在这里。

模型在压缩之前就已经退化了， 而压缩并不会神奇地恢复质量。（可以用 /compact）

你发送的每一条消息、 Claude 读取的每一个文件、 它生成的每一段代码、 每一次工具调用结果—— 全部都会累积进上下文里。

一旦质量开始下降， 更多上下文只会让情况更糟，而不是更好。

下面是一些真正有用的做法：

限定会话范围

一个会话，只做一件事。

不要在同一个会话里： 一边做认证系统， 一边又去重构数据库层。

上下文会互相污染，Claude 会被搞糊涂。 我敢打赌，正在读这段话的你，肯定有人干过这事。

使用外部记忆

如果你在做复杂任务，让 Claude 把计划和进度写进真实文件里（我用 PLAN.md 或 TODO.md）。

这些文件会跨会话存在。 第二天回来时，Claude 只需要读文件，就能继续工作，而不是从零开始。

小提示： 如果你有一套文件层级结构，把这些文件放在最顶层，会让它们对所有任务都生效。

复制–粘贴重置法（Copy-paste reset）

这是我经常用的一个技巧。

当上下文变得臃肿时：

1. 把终端里所有重要内容复制出来
2. 运行 /compact 让 Claude 总结
3. 然后 /clear 清空上下文
4. 再只粘贴回真正重要的部分

你会得到一个干净的新上下文，同时保留关键信息。 比让 Claude 在退化上下文里挣扎要好得多。

知道什么时候该清空

如果一个会话已经跑偏，或者积累了大量无关内容， 直接 /clear，重新开始。

这通常比勉强修补要好。

你并不会丢失项目上下文，因为 CLAUDE.md 还在。

反直觉的一点是： 十次里有九次，清空比不清空更好。

一个好用的心智模型是： Claude 是无状态的。

每一次会话，除了你明确给它的内容，它什么都不知道。 请基于这个事实来规划你的使用方式。

提示词就是一切（Prompts Are Everything）

人们花几周时间学框架、学工具， 却几乎不花时间学如何和真正生成代码的东西沟通。

提示词并不是什么玄学。 它可能是最基础的一种沟通方式。

而和任何沟通一样： 清晰，总是比模糊效果好。

每一次，都是如此。

真正有用的做法

具体说明你要什么。 “做一个认证系统”给了 Claude 太多自由度，而它会把这些自由用在错误的地方。

“使用现有 User 模型，实现邮箱 + 密码认证； 会话存在 Redis； 保护 /api/protected 路由” 至少给了一个明确目标。

告诉它不要做什么。

Claude 有明显倾向。 尤其是 Claude 4.5，非常喜欢过度工程化：

• 多余的文件
• 不必要的抽象
• 你没要求的灵活性

如果你想要简单，就直接说：

“保持简单，不要加我没要求的抽象， 能一个文件解决就一个文件。”

并且，一定要复查它生成的内容。 否则你很容易在一个本该几行代码就能解决的问题上，背上技术债。

你需要记住： AI 是为了加速我们，不是完全取代我们。 Claude 仍然会犯错，而且短期内还会继续犯错。

能否识别这些错误，本身就是你的核心能力之一。

告诉它“为什么”

“这个逻辑跑在每一次请求上，所以必须快” 会改变 Claude 的实现方式。

“这是一个会被丢弃的原型” 会改变它权衡取舍的方向。

Claude 不会读心术。 你没说的约束，它就不知道。

记住一句话： 输出只来自输入。

如果你的输出很糟， 那你的输入也一定很糟。

垃圾输入 = 垃圾输出（Bad Input == Bad Output）

很多人把问题怪在模型上：

• “Claude 不够聪明”
• “我要换个更好的模型”

现实一点说： 问题在你身上。

如果你用的是 Opus 4.5 这种好模型，却仍然得到糟糕结果， 那就是你的输入、你的提示方式有问题。

模型当然重要。 但现在模型质量已经是入场���了。

真正的瓶颈，几乎永远在人这一侧：

• 你如何写提示词
• 你如何拆解任务
• 你如何提供上下文

你应该提升的能力

• 提示词写法：具体 > 模糊；约束 > 开放；示例 > 描述
• 任务结构：先对齐架构，再写代码；持续 review、迭代
• 上下文提供：Claude 需要知道什么？你默认了哪些假设？

模型之间的真实差异

• Sonnet：快、便宜，适合执行型任务
• Opus：慢、贵，但更擅长复杂推理和架构设计

一个有效流程是：

1. 用 Opus 规划、做架构决策
2. 切换到 Sonnet（Claude Code 里 Shift + Tab）执行实现

你的 CLAUDE.md 会保证两个模型在同一约束下工作，交接很干净。

MCP、工具与配置（MCP, Tools, and Configurations）

Claude 的功能多得离谱：

• MCP servers
• Hooks
• 自定义 slash 命令
• settings.json
• Skills
• Plugins

你不需要全部用上。 但你至少应该尝试它们。

如果你不去实验， 你大概率在浪费时间或钱。

我敢保证，现在 Claude 里一定有你不知道、但对你有用的新功能。 想第一时间知道这些，去关注 Claude Code 的创始人 Boris。

MCP（Model Context Protocol）

MCP 让 Claude 能连接外部服务： Slack、GitHub、数据库、API。

如果你发现自己总在复制信息给 Claude， 那很可能已经有 MCP 可以自动完成这件事。

即便没有现成的 MCP， 它本质上只是把结构化数据喂给模型， 你也可以自己写一个。

Hooks

Hooks 可以在 Claude 修改文件前或后自动运行代码。

比如：

• 每次修改后跑 Prettier
• 每次修改后跑类型检查

这样问题会立刻暴露，而不是积累成技术债。

自定义 Slash 命令

本质上就是可复用的提示词。

在 .claude/commands 目录里放 Markdown 文件， 你就能用 /commandname 调用。

如果你经常做同类任务，比如 debug、review、部署， 那就把它们做成命令。

如果你已经在用 Pro Max（我自己付 $200/月）， 那就把所有功能都试一遍。

你已经在付钱了。

而且不要因为一次失败就放弃。 模型几乎每周都在进化， 一个月前不好用的东西，现在可能已经能用了。

当 Claude 卡住时（When Claude Gets Stuck）

有时候 Claude 会陷入循环：

• 重复尝试
• 重复失败
• 自信但完全错误

你的本能反应可能是： 给更多指令、更多解释、更多上下文。

但实际上，更好的做法是： 彻底换一种方式。

可行的策略

• /clear，重新开始
• 拆分任务
• 写一个最小示例，让它照着来
• 换一种问题表述方式

如果你已经解释了三次，它还是没懂， 那再解释一次也不会有用。

改变策略。

构建系统（Build Systems）

真正从 Claude 获得最大价值的人， 不是把它当一次性工具用的人。

他们在构建系统，而 Claude 是其中一个组件。

Claude Code 有 -p 参数，可以无界面运行。 这意味着你可以：

• 脚本化
• 管道化
• 自动化

企业已经在用它做：

• 自动 PR Review
• 自动工单回复
• 自动日志和文档更新

全部可审计、可改进。

飞轮效应是这样的：

Claude 出错 → 你 review 日志 → 你改进 CLAUDE.md 或工具 → 下次 Claude 更好。

模型没变，系统变强了。

如果你只在交互式地用 Claude， 那你真的在浪费它的潜力。

TL;DR

（以下为原作者 TLDR 的逐条直译）

• 先思考，再输入。规划会显著提升结果质量
• CLAUDE.md 是你的杠杆点：短、具体、讲清原因、持续更新
• 上下文在 30% 就开始退化，学会清空和重启
• 架构比一切都重要
• 输出来自输入，结果不好，先反思提示词
• 多试工具和配置
• 卡住时换方式
• 构建系统，不要只做一次性任务

如果你正在用 Claude 构建东西，不管是个人项目还是生产系统， 这些因素决定了你是在和工具对抗， 还是顺着它的能力流动。

如果你想获取更多关于如何高效使用 AI 的经验，欢迎订阅我的免费每周 AI Newsletter。