本文整理自 Varick Agents CTO Eyad Khrais 发布的文章：The complete claude code tutorial
作者 Eyad 结合其 7 年的软件工程经验指出，使用 Claude Code 等 AI 工具时，最大的错误是直接开始输入或生成代码。成功的关键在于先进行架构规划和系统设计，通过与 AI 的深度对话确定方案，而非单向指令。
AI 模型是无状态的，输出质量完全取决于输入的质量。如果 Claude 的表现不佳，通常是因为用户的提示词（Prompt）模糊、缺乏上下文或架构指令不明确。掌握清晰的沟通技巧和约束条件是提升效率的核心。
高效使用 Claude Code 需要精细化管理上下文窗口，利用 .clauderc 文件进行项目级配置，并灵活运用 MCP 和 Hooks 等高级功能来实现自动化和系统化集成，而非仅仅将其作为一次性问答工具。
关键细节
规划模式（Plan Mode）的重要性
- 先思考再输入：直接生成代码往往效果不佳。建议先进入“计划模式”（按两次 Shift+Tab），花时间与 AI 讨论架构、端到端状态和调试思路。
- 双向对话：不应只是单向下达指令，而应与 ChatGPT 、 Gemini 或 Claude 进行深入的来回对话，共同确定系统设计方案。
核心配置文件 .clauderc 的使用技巧
- 作为入职文档： .clauderc 是一个 Markdown 文件， Claude 在每次会话前都会读取。它应像给“失忆后的自己”写的笔记，而非给新员工的文档。
- 保持精简： Claude 只能可靠地遵循约 150 到 200 条指令。文件内容应简短且与项目高度相关，避免无关信息。
- 解释“为什么”：告诉 Claude 指令背后的原因（例如：“使用 TypeScript 严格模式是因为我们曾遇到隐式类型导致的生产错误”），这能帮助模型做出更好的判断。
- 持续更新：将其视为活文档，一旦发现需要重复纠正 AI 某件事，就应立即将其加入配置文件。
上下文窗口管理的艺术
- 性能衰减点：模型性能在上下文使用率达到 20-40% 时就开始下降，而不是 100% 。
- 会话隔离：每个功能或任务应开启一个新的会话，避免上下文混杂。
- 外部记忆：对于复杂任务，让 Claude 将计划和进度写入外部文件，以便跨会话读取。
- 复制粘贴重置法（The copy-paste reset）：当上下文臃肿时，复制关键信息，运行
/compact或/clear清空上下文，然后只粘贴最关键的内容，以恢复模型智商。
提示词与沟通策略
- 具体明确：避免模糊指令（如“构建一个认证系统”），应提供具体的技术栈、存储方式和中间件要求。
- 设定负面约束：明确告诉 Claude 不要过度设计或添加不必要的抽象，特别是对于 Claude 4.5 这种喜欢过度工程化的模型。
- 模型选择：使用 Opus 进行复杂的推理和架构规划，使用 Sonnet 进行具体的代码执行和重构。
自动化与高级功能
- MCP (Model Context Protocol)：利用 MCP 连接外部服务（如 GitHub、数据库），自动获取结构化数据。
- Hooks：设置钩子在 Claude 修改文件前后自动运行代码（如 Prettier 格式化或类型检查），及时发现技术债务。
- Headless 模式：使用
-p标志在非交互模式下运行 Claude Code ，将其集成到 CI/CD、自动 PR 审查或日志分析等自动化工作流中。
摆脱死循环
- 及时止损：如果 Claude 陷入尝试-失败的循环，不要继续堆砌指令。应清空会话、简化任务、提供具体示例（Show instead of tell），或者换个角度重新描述问题。
原文：The complete claude code tutorial
我当了 7 年软件工程师，曾在亚马逊、迪士尼和 Capital One 工作。我发布的代码触达数百万用户，我构建过不仅能崩溃的关键系统。现在我是一家为企业构建 Agent 的初创公司的 CTO，Claude Code 是我的日常主力工具。
这是一份你可能会觉得有用的初学者手册，包含了我在使用 Claude 为大公司构建能够处理复杂工作负载的稳健系统过程中学到的所有关于它的知识。如果这对你有帮助，请在下面告诉我。
大多数人认为有了 Claude Code 和其他 AI 工具，你要做的第一件事就是打字（或开始说话）。但这可能是你一开始能犯的最大的错误之一。你真正需要做的第一件事是思考。
10 次有 10 次，我使用**计划模式（plan mode）**得到的输出都比我直接开始说话并把所有东西都抛给 Claude Code 时要好得多。这简直是天壤之别。
对你们中的一些人来说，说起来容易做起来难。你可能没有多年的软件工程经验来让你独立思考这个问题。对此我有两条建议：
- 开始学习。如果你从不尝试掌握这一点，哪怕只是一点点，你就是在给自己设限。
- 与 ChatGPT/Gemini/Claude 进行深入的反复交流，准确描述你想构建的内容，询问 LLM 在系统设计方面有哪些选项，最终你们共同确定一个解决方案。你和 LLM 应该互相提问，而不是单行道。
这适用于任何事情。这也包括像总结邮件这样非常小的任务。在你要求 Claude 构建功能之前，先思考架构。在你要求它重构某些东西之前，先思考最终状态应该是什么样子的。在你要求它调试之前，先思考你对这个问题实际了解多少。你在计划模式中拥有的信息越多，你的输出实际上就会越好，因为输入越好了。
模式是一致的：先思考，后打字，产生的结果要比先打字并希望 Claude 能自己搞定要好得多。
这将我带到了关于架构的下一点。架构，尤其是在软件工程中，有点像只给一个人结果而没有其他东西。这给如何得出结果留下了大量的回旋余地，这本质上就是 AI 生成代码的问题所在。如果你说得很宽泛，比如“给我建一个认证系统”，而不是“使用现有的 User 模型构建电子邮件/密码认证，将会话存储在 Redis 中并设置 24 小时过期，添加中间件保护 /api/protected 下的所有路由”，你能看出其中的区别。
按两次 Shift + Tab，你就进入了计划模式。相信我，这会占用你 5 分钟的时间，但会在以后为你节省数小时的调试时间。
CLAUDE.md 是一个 markdown 文件。Markdown 是一种 AI 模型处理得非常好的文本格式，Claude 处理它的能力比我测试过的大多数其他模型都要好。
当你开始一个 Claude Code 会话时，Claude 做的第一件事就是读取你的 CLAUDE.md 文件。该文件中的每条指令都会塑造 Claude 处理你项目的方式。它本质上是 Claude 在每次对话前都会阅读的入职材料。
大多数人要么完全忽略它，要么塞满垃圾信息，这反而让 Claude 变得更糟。存在一个阈值，信息过多或过少都会导致模型输出变差。
以下是真正重要的内容：
保持简短。Claude 一次只能可靠地遵循大约 150 到 200 条指令，而 Claude Code 的系统提示词已经使用了大约 50 条。你添加的每条指令都在争夺注意力。如果你的 CLAUDE.md 是一本小说，Claude 就会开始随机忽略一些东西，而你不知道它忽略了什么。
针对你的项目具体化。不要解释什么是组件文件夹。Claude 知道什么是组件。告诉它那些奇怪的东西，比如真正重要的 bash 命令。所有属于你工作流程的内容都应该放进去。
告诉它为什么，而不仅仅是什么。Claude 在这方面有点像人类。当你给出指令背后的原因时，Claude 的执行效果比你只告诉它做什么要好。“使用 TypeScript 严格模式”是可以的。“使用 TypeScript 严格模式，因为我们在生产环境中遇到过隐式 any 类型导致的 bug”则更好。“为什么”给了 Claude 做出你未预料到的判断所需的上下文。你会惊讶于这实际上有多有效。
不断更新它。在你工作时按 # 键，Claude 会自动将指令添加到你的 CLAUDE.md 中。每当你发现自己在同一件事上纠正 Claude 两次时，这就是一个信号，表明它应该在文件中。随着时间的推移，你的 CLAUDE.md 会变成一份关于你的代码库实际如何工作的活文档。
糟糕的 CLAUDE.md 看起来像是为新员工写的文档。好的 CLAUDE.md 看起来像是如果你知道明天会失忆而留给自己的笔记。
例如，Opus 4.5 有 200,000 个 token 的上下文窗口。但大多数人没有意识到的是：模型在达到 100% 之前很久就开始恶化了。（这取决于你是通过 API 还是桌面应用程序使用）
在大约 20-40% 的上下文使用率时，输出质量就开始下降，即使不显著。如果你曾经历过 Claude Code 压缩上下文（compacting）后仍然给出糟糕的输出，这就是原因。模型在压缩发生之前就已经退化了，压缩并不能神奇地恢复质量。（输入 /compact 进行压缩）
你发送的每一条消息、Claude 读取的每一个文件、它生成的每一段代码、每一个工具结果——所有这些都在积累。一旦质量开始下降，更多的上下文只会让情况变得更糟，而不是更好。所以，这里有一些实际上有助于避免糟糕上下文的方法：
划定对话范围。每个功能或任务一个对话。不要用同一个对话来构建你的认证系统，然后又用它来重构你的数据库层。上下文会混在一起，Claude 会感到困惑。我知道你们中至少有一个正在阅读这篇文章的人对此感到内疚。
使用外部记忆。如果你在处理复杂的事情，让 Claude 将计划和进度写入实际的文件（我使用 PLAN.md 或 todo.md）。这些文件跨会话持久存在。当你明天回来时，Claude 可以读取文件并从你停下的地方继续，而不是从零开始。附注：如果你有一个文件层级系统，将这些文件保持在最顶层，是你让它们为你决定构建的每个任务/功能发挥作用的方法。
复制粘贴重置。这是我经常使用的一个技巧。当上下文变得臃肿时，我会从终端复制所有重要的内容，运行 /compact 获取摘要，然后完全 /clear（清除）上下文，只粘贴回重要的内容。保留了关键信息的全新上下文。这比让 Claude 在退化的上下文中挣扎要好得多。
知道何时清除。如果对话偏离了轨道或积累了一堆不相关的上下文，只需 /clear 并重新开始。这比试图在混乱中工作要好。Claude 仍然拥有你的 CLAUDE.md，所以你不会丢失项目上下文。十有八九，使用清除实际上比不使用要好，尽管这听起来可能有些反直觉。
有效的心智模型：Claude 是无状态的。每一次对话都是从无开始，除了你明确给它的东西。据此进行规划。
人们花数周时间学习框架和工具。他们花零时间学习如何与实际生成代码的东西进行交流。
提示词编写并不是什么神秘的艺术。这可能是最基本的沟通形式。就像任何沟通一样，清晰比含糊其辞能获得更好的结果。每一。次。都。是。
具体说明你想要什么。“构建一个认证系统”给了 Claude 糟糕地使用创作自由的空间。“使用这个现有的 User 模型构建电子邮件/密码认证，将会话存储在 Redis 中，并添加保护 /api/protected 下路由的中间件”给了 Claude 一个明确的目标。即使这样也还不完美。
告诉它不要做什么。Claude 有它的倾向性。Claude 4.5 特别喜欢过度设计——额外的文件、不必要的抽象、你没要求的灵活性。如果你想要简单的东西，就说“保持简单。不要添加我没要求的抽象。如果可能的话，就用一个文件。”另外，总是要交叉核对 Claude 产生的内容，因为你不想最终背上技术债务，尤其是如果你正在构建非常简单的东西，结果它为一个实际上几行代码就能搞定的任务构建了 12 个不同的文件。
你必须记住的是，AI 旨在加速我们，而不是完全取代我们，尤其是在非常专业的软件工程时代。Claude 仍然会犯错。我确信它会继续犯错，即使它会随着时间的推移变得更好。所以能够识别这些错误实际上会解决你的很多问题。
提供关于“为什么”的上下文。“我们需要这个很快，因为它在每个请求上都运行”会改变 Claude 处理问题的方式。“这是一个我们要丢弃的原型”会改变哪些权衡是有意义的。Claude 无法读懂你没提到的约束条件。
记住：输出就是一切，但它只来自输入。如果你的输出很烂，那是你的输入很烂。这是无法回避的。
人们得到糟糕结果时会责怪模型。“Claude 不够聪明”或“我需要更好的模型”。
现实核查：是你烂。如果你用像 Opus 4.5 这样的好模型却得到糟糕的输出，那意味着你的输入和提示词很烂。句号。
模型很重要。实际上非常重要。但模型质量在这一点上只是入场券。瓶颈几乎总是在人这一边：你如何构建提示词，你如何提供上下文，你如何清晰地传达你真正想要的东西。
如果你持续得到糟糕的结果，解决办法不是换模型。解决办法是做得更好：
你如何编写提示词。具体 > 模糊。约束 > 开放式。示例 > 描述。
你如何构建请求。将复杂任务分解为步骤。在实施之前就架构达成一致。审查输出并迭代。
你如何提供上下文。Claude 需要知道什么才能做好这件事？你做了哪些 Claude 看不到的假设？
话虽如此，模型之间确实存在差异：
Sonnet 更快更便宜。它非常适合路径清晰的执行任务——编写样板代码、根据特定计划重构、实现你已经做过架构决策的功能。
Opus 更慢更贵。它更适合复杂的推理、规划以及需要 Claude 深入思考权衡的任务。
一个有效的工作流：使用 Opus 进行规划和做出架构决策，然后切换到 Sonnet（在 Claude Code 中按 Shift+Tab）进行实施。这取决于你的任务，有时你也可以使用 Opus 4.5 进行实施。不过，如果你是通过 API 使用选项卡执行此操作，请考虑一下卖肾的问题。你的 CLAUDE.md 确保两个模型都在相同的约束下运行，因此交接是干净的。
Claude 有大量的功能。MCP 服务器。Hooks（钩子）。自定义斜杠命令。Settings.json 配置。技能。插件。
你不需要所有这些。但你应该实际尝试和实验，因为如果你不实验，你可能就在浪费时间或金钱。我向你保证，Claude 中至少有一个你不知道的新功能即将推出，如果你关注 Claude Code 的创始人 Boris，你实际上可以了解到它。
MCP (Model Context Protocol) 让 Claude 连接到外部服务。Slack、GitHub、数据库、API。如果你发现自己经常从一个地方复制信息到 Claude，可能就有一个 MCP 服务器可以自动完成。有大量的 MCP 市场，如果没有 MCP，它只是获取结构化数据的一种方式，所以你可以为你需要添加但目前不存在的任何工具创建自己的 MCP 服务器。不过如果你找不到现成的，我会很惊讶。
Hooks（钩子） 让你在 Claude 进行更改之前或之后自动运行代码。想要 Prettier 在 Claude 触碰的每个文件上运行？用 Hook。想要每次编辑后进行类型检查？用 Hook。这能立即捕捉问题，而不是让它们堆积起来。这实际上也是帮助消除技术债务的方法。如果你设置一个特定的 hook 在每一千行代码后运行，你就有可能通过安全功能清理你的代码。当 Claude 审查你的 PR 时应该非常有帮助。
自定义斜杠命令 只是你重复使用的提示词，被打包成了命令。创建一个 .claude/commands 文件夹，添加带有你提示词的 markdown 文件，现在你可以用 /commandname 运行它们。如果你经常运行同类任务——调试、审查、部署——把它做成命令。
如果你有 Pro Max 计划（我付的是 200 美元/月），为什么不尝试 Claude 提供的所有功能呢？看看什么有效，什么无效。反正你都付钱了。
还有一点：如果第一次尝试没有成功，不要放弃。这些模型基本上每周都在改进。一个月前行不通的东西现在可能行得通。作为早期采用者意味着保持好奇心并重新测试事物。
有时 Claude 只是在循环。它尝试同样的事情，失败，再次尝试，失败，并继续下去。或者它自信地实施了一些完全错误的东西，而你花了二十分钟试图解释为什么。
当发生这种情况时，本能是继续推进。更多指令。更多修正。更多上下文。但现实是，更好的举措是完全改变方法。
从简单开始 - 清除对话。积累的上下文可能会让它困惑。/clear 给你一个新的开始。
简化任务。如果 Claude 在复杂的任务上挣扎，将其分解成更小的部分。在合并之前让每个部分工作。但实际上，如果 Claude 在复杂的任务上挣扎，这意味着你的计划模式（plan mode）是不充分的。
展示而不是讲述。如果 Claude 一直误解你想要的，自己写一个最小的例子。“这是输出应该看起来的样子。现在将此模式应用于其余部分。”Claude 非常擅长理解成功指标是什么样子的，并且实际上能够遵循它们，理解什么是好的例子。
发挥创造力。尝试不同的角度。有时你构建问题的方式不能很好地映射到 Claude 的思维方式。重构——“将其实现为状态机”与“处理这些转换”——可以解锁进度。
这里的元技能是尽早识别出你处于循环中。如果你已经解释了同一件事三次，Claude 仍然不明白，更多的解释通常不会有帮助。改变一些东西。
从 Claude 获得最大价值的人不是用它来做一次性任务。他们正在构建以 Claude 为组件的系统。但 Claude Code 远比那更好。它有一个用于无头模式的 -p 标志。它运行你的提示词并输出结果，而不进入交互式界面。这意味着你可以编写脚本。将输出管道传输到其他工具。将其与 bash 命令链接。将其集成到自动化工作流中。
企业正在使用它进行自动 PR 审查、自动支持票据回复、自动日志和文档更新。所有这些都被记录下来、可审计，并根据有效和无效的内容随着时间的推移进行改进。
飞轮效应：Claude 犯了一个错误，你查看日志，你改进 CLAUDE.md 或工具，Claude 下次会变得更好。这会复利。我现在正在让 Claude 能够改进它自己的 CLAUDE.md 文件。经过几个月的迭代，以这种方式构建的系统比它们在发布时要好得多——同样的模型，只是配置得更好。
如果你只以交互方式使用 Claude，你就把价值留在了桌面上。思考一下在你工作流程的哪里 Claude 可以在不需要你看着的情况下运行。
总结：
- 先思考再打字。规划产生的效果比直接开始说话要好得多。
CLAUDE.md是你的杠杆点。保持简短、具体，告诉它为什么，并不断更新。这单个文件影响每一次互动。- 上下文在 30% 时降级，而不是 100%。使用外部记忆，划定对话范围，并且不要害怕使用复制粘贴重置技巧来清除并重新开始。
- 架构比任何事情都重要。你不能跳过规划。如果你不先思考结构，输出就会很糟糕。
- 输出源自输入。如果你用好的模型得到糟糕的结果，你的提示词需要改进。在沟通方面做得更好。
- 实验工具和配置。MCP、hooks、斜杠命令。如果你购买了 Pro Max，尝试一切。即使第一次不起作用，也要保持好奇心。
- 受阻时，改变方法。不要循环。清除、简化、展示、重构。
- 构建系统，而不是一次性任务。无头模式、自动化、随时间推移记录改进。
如果你正在用 Claude 构建——无论是你自己的项目还是生产系统——这些事情决定了你是在与工具对抗还是顺势而为。