Claude 代码完整教程

Eyad @eyad_khrais

完整的 Claude 代码教程

2.4K

这是一个你可能会觉得有用的新手剧本，其中包含了我使用 Claude 构建健壮系统以处理来自大型公司的复杂工作负载后，学到的关于 Claude 的一切。请在下方告诉我它是否有帮助。

先思考

大多数人认为使用 Claude Code 和其他 AI 工具，首先要做的是打字（或开始说话）。但这可能是你一开始就会犯的最大错误之一。你实际上需要做的第一件事是思考。

十有八九，我通过计划模式得到的输出比我直接开始说话并将所有内容喷到 Claude Code 中时要好得多。这根本没法比。

现在，对于你们中的一些人来说，这说起来容易做起来难。你可能没有多年的软件工程经验，无法独自思考这个问题。为此，我有两条建议：1. 开始学习。如果你一直不学习这些，即使只是在一点一点地学，你也会束缚自己的手脚。

2. 与 ChatGPT/Gemini/Claude 进行深入的来回交流，你准确地描述你想要构建的内容，你向 LLM 询问在系统设计方面可以采取的各种选项，最终你们两个达成一个解决方案。你和 LLM 应该互相提问，而不是单行道。

这适用于所有事情。这也包括非常小的任务，比如总结电子邮件。在你要求 Claude 构建一个功能之前，先考虑一下架构。在你要求它重构某些东西之前，先考虑一下最终状态应该是什么样子。在你要求它调试之前，先考虑一下你对这个问题到底了解多少。你在计划模式中拥有的信息越多，你的输出实际上会越好，因为输入会更好。

模式是一致的：先思考，再打字，产生的效果比先打字并希望 Claude 自己搞清楚要好得多。

这引出了我的下一个架构观点。架构，尤其是在软件工程中，有点像只给一个人输出，而没有其他任何东西。这为如何获得输出留下了很大的回旋余地，这从本质上来说就是 AI 生成代码的问题所在。如果你说一些非常宽泛的东西，比如“构建一个 auth 系统”，而不是“使用现有的 User 模型构建电子邮件/密码验证，将 session 存储在 Redis 中，有效期为 24 小时，并添加中间件以保护 /api/protected 下的所有路由。”，你可以看到其中的区别。

你点击 shift + tab 两次，就进入了计划模式。相信我说的话，这会占用你 5 分钟的时间，但会为你节省以后数小时的调试时间。

CLAUDE.md CLAUDE.md

是一个 markdown 文件。Markdown 是一种 AI 模型处理得非常好的文本格式，尤其是 Claude，它处理得比我测试过的大多数其他模型都要好。

当你启动一个 Claude Code 会话时，Claude 首先要做的是读取你的 CLAUDE.md 文件。该文件中的每一条指令都会影响 Claude 处理你的项目的方式。它本质上是 Claude 在每次对话之前都会阅读的入门材料。

大多数人要么完全忽略它，要么用垃圾填满它，这让 Claude 变得更糟，而不是更好。存在一个阈值，即信息过多或过少都意味着更差的模型输出。

以下是真正重要的事项：

保持简短。Claude 一次只能可靠地遵循大约 150 到 200 条指令，并且 Claude Code 的系统提示已经使用了其中的大约 50 条。你添加的每条指令都在争夺注意力。如果你的 CLAUDE.md 是一部小说，Claude 会开始随机忽略一些事情，而你不会知道是哪些事情。

使其特定于你的项目。不要解释什么是 components 文件夹。Claude 知道什么是 components。告诉它那些奇怪的东西，比如真正重要的 bash 命令。你流程中的所有内容都应该包含在其中。

告诉它为什么，而不仅仅是什么。Claude 在这方面有点像人类。当你给出一条指令背后的原因时，Claude 实现它的效果比你只是告诉它该怎么做要好。 “使用 TypeScript strict 模式”是可以的。“使用 TypeScript strict 模式，因为我们已经从隐式 any 类型中发现了生产错误”更好。为什么为 Claude 提供了制定你没有预料到的判断的上下文。你会惊讶于这实际上有多有效。

不断更新它。在工作时按 # 键，Claude 会自动将指令添加到你的 CLAUDE.md 中。每次你发现自己两次纠正 Claude 同一件事，这都是一个信号，表明它应该在文件中。随着时间的推移，你的 CLAUDE.md 会成为你的代码库实际工作方式的鲜活文档。

糟糕的 CLAUDE.md 看起来像是为新员工编写的文档。好的 CLAUDE.md 看起来像是如果你知道你明天会失忆，你会留给自己的笔记。

上下文窗口的限制

例如，Opus 4.5 有一个 200,000 个 token 的上下文窗口。但这是大多数人没有意识到的：在你达到 100% 之前，模型就开始恶化。（这取决于你使用 API 还是桌面应用程序而有所不同）

在 20-40% 左右的上下文使用率时，输出的质量开始下降，即使不是很明显。如果你曾经遇到过 Claude Code 压缩后仍然给你糟糕的输出，那就是原因。在压缩发生之前，模型已经退化了，而压缩并不能神奇地恢复质量。（点击 /compact 进行压缩）

你发送的每条消息、Claude 读取的每个文件、它生成的每段代码、每个工具结果 - 所有这些都会累积。一旦质量开始下降，更多的上下文会使情况变得更糟，而不是更好。因此，以下是一些实际上有助于避免出现糟糕上下文的方法

限定你的对话范围。每个对话对应一个功能或任务。不要使用同一个对话来构建你的 auth 系统，然后再重构你的数据库层。上下文会混合在一起，Claude 会感到困惑。我知道至少有一个正在阅读此文的人对此感到内疚。

使用外部记忆。如果你正在处理复杂的事情，请让 Claude 将计划和进度写入实际文件（我使用 SCRATCHPAD.md 或 plan.md）。这些文件会在会话之间保留。当你明天回来时，Claude 可以读取该文件并从你离开的地方继续，而不是从头开始。旁注：如果你有一个文件的层次结构系统，将这些文件保存在最顶层是你可以让这些文件为你要构建的每个任务/功能工作的方式。

复制粘贴重置。这是我经常使用的一个技巧。当上下文变得臃肿时，我从终端复制所有重要的内容，运行 /compact 以获得摘要，然后 /clear 完全清除上下文，并仅粘贴回重要的内容。全新的上下文，保留了关键信息。比让 Claude 在退化的上下文中挣扎要好得多。

知道何时清除。如果对话偏离了轨道或积累了一堆不相关的上下文，只需 /clear 并重新开始。这比试图在混乱中工作要好。Claude 仍然会保留你的 CLAUDE.md，因此你不会丢失你的项目上下文。十次中有九次，使用 clear 实际上比不使用它更好，尽管这听起来违反直觉。

有效的心理模型：Claude 是无状态的。每个对话都从零开始，除了你明确提供给它的东西。据此进行计划。

提示就是一切

人们花费数周时间学习框架和工具。他们没有花费任何时间学习如何与实际生成他们代码的东西进行通信。

提示不是什么神秘的艺术。它可能是最基本的沟通形式。就像任何沟通一样，清晰比模糊能给你带来更好的结果。每一次都是如此。

真正有帮助的是：

具体说明你想要什么。“构建一个 auth 系统”给了 Claude 创造性的自由，它会拙劣地使用这种自由。“使用这个现有的 User 模型构建电子邮件/密码验证，将 session 存储在 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 确保两个模型都在相同的约束下运行，因此交接是干净的。

MCP、工具和配置

Claude 具有大量的特性。 MCP 服务器。Hook。自定义斜杠命令。Settings.json 配置。技能。插件。

你不需要所有这些。但你实际上应该尝试它们并进行实验，因为如果你不进行实验，你可能会把时间和金钱浪费掉。我保证在 Claude 中至少有一个你不知道的新功能即将推出，如果你关注 Claude Code 的创始人 Boris，你实际上可以了解它。

MCP（模型上下文协议）允许 Claude 连接到外部服务。Slack、GitHub、数据库、API。如果你发现自己不断地将信息从一个地方复制到 Claude 中，那么可能有一个 MCP 服务器可以自动完成此操作。有大量的 MCP 市场，如果没有 MCP，它只是一种获取结构化数据的方式，因此你可以为你需要的但目前不存在的任何工具创建自己的 MCP 服务器。如果你发现一个不存在的服务器，我会感到非常惊讶。

Hook允许你在 Claude 进行更改之前或之后自动运行代码。想要 Claude 在它接触的每个文件上运行 Prettier 吗？Hook。想要在每次编辑后进行类型检查吗？Hook。这可以立即发现问题，而不是让它们堆积起来。这实际上也有助于消除技术债务。如果你在每隔一千行代码后设置一个特定的Hook，你就有可能清理你的代码的安全功能。当 Claude 审查你的 PR 时，这应该会非常有帮助。

自定义斜杠命令只是你重复使用的提示，打包为命令。创建一个 .claude/commands 文件夹，添加带有你的提示的 markdown 文件，现在你可以使用 /commandname 运行它们。如果你经常运行同一种类型的任务 - 调试、审查、部署 - 将其设为一个命令。

如果你有 Pro Max 计划（我每月支付 200 美元），为什么不尝试 Claude 提供的所有功能呢？看看哪些有效，哪些无效。反正你也在为此付费。

这里有一件事：如果第一次尝试没有奏效，不要关掉。这些模型基本上每周都在改进。一个月前没有奏效的事情现在可能会奏效。成为早期采用者意味着保持好奇心并重新测试事物。

当 Claude 卡住时

有时 Claude 只是循环。它尝试相同的事情，失败，再次尝试，失败，然后继续。或者它自信地实施一些完全错误的事情，而你花费了 20 分钟试图解释原因。

当这种情况发生时，本能是继续推进。更多的指令。更多的更正。更多的上下文。但现实情况是，更好的做法是完全改变方法。

从简单的开始 - 清除对话。累积的上下文可能会使它感到困惑。/clear 让你重新开始。

简化任务。如果 Claude 正在努力完成一项复杂的任务，请将其分解为更小的部分。在将每个部分组合在一起之前，让每个部分都能正常工作。但实际上，如果 Claude 正在努力完成一项复杂的任务，这意味着你的计划模式不够充分。

展示而不是讲述。如果 Claude 一直误解你想要什么，请自己编写一个最小的示例。“这是输出应该是什么样子的。现在将此模式应用于其余部分。” Claude 非常擅长理解成功指标是什么样子的，并且实际上能够遵循它们，以及一个好的示例是什么。

发挥创造力。尝试不同的角度。有时你构建问题的方式与 Claude 的思考方式不太一致。重新构建 - “将此实现为状态机”与“处理这些转换” - 可以解锁进展。

这里的元技能是尽早识别你何时陷入循环。如果你已经解释了同一件事三次，而 Claude 仍然没有理解，那么更多的解释将无济于事。改变一些东西。

构建系统

从 Claude 获得最大价值的人不是将它用于一次性任务。他们正在构建 Claude 是一个组件的系统。但 claude code 比这要好得多。它有一个 -p 标志用于 Headless 模式。它运行你的提示并输出结果，而无需进入交互式界面。这意味着你可以编写脚本。将输出管道传输到其他工具。将其与 bash 命令链接。将其集成到自动化工作流程中。

企业正在使用此功能进行自动 PR 审查、自动支持票证响应、自动日志记录和文档更新。所有这些都经过记录、可审计，并根据哪些有效、哪些无效随着时间的推移而改进。

飞轮：Claude 犯了一个错误，你审查日志，你改进 CLAUDE.md 或工具，Claude 下次会做得更好。这会产生复合效应。目前，我正在能够让 Claude 已经改进自己的 Claude.md 文件的过程中。经过数月的迭代，以这种方式构建的系统明显比启动时更好 - 相同的模型，只是配置得更好。

如果你仅以交互方式使用 Claude，那么你就会错失价值。考虑一下在你的工作流程中，Claude 可以在没有你观看的情况下运行。

TLDR

在打字之前先思考。计划比仅仅开始说话产生更好的结果。CLAUDE.md 是你的杠杆点。保持简短、具体，告诉它原因，并不断更新。这个单一文件会影响每一次交互。

上下文在 30% 处降级，而不是在 100% 处降级。使用外部记忆，限定对话范围，并且不要害怕使用复制粘贴重置技巧清除和重新启动。

架构比任何事情都重要。你不能跳过计划。如果你不首先考虑结构，输出将会很糟糕。

输出来自输入。如果你使用一个好的模型得到糟糕的结果，那么你的提示需要改进。更好地进行沟通。

尝试工具和配置。MCP、Hook、斜杠命令。如果你正在为 Pro Max 付费，请尝试所有功能。即使事情第一次没有奏效，也要保持好奇心。

当卡住时，改变方法。不要循环。清除、简化、展示、重新构建。

构建系统，而不是一次性任务。Headless 模式，自动化，随着时间的推移记录改进。

如果你正在使用 Claude 构建 - 无论是你自己的项目还是生产系统 - 这些事情决定了你是在与工具作斗争还是在顺应工具。

• 原文链接： x.com/eyad_khrais/status...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～