2 百万人围观的 Claude Code 实战使用指南

分享一个这两天非常火的Claude Code使用指南，2百万人围观，近7000点赞，都是作者在实践中的干货

Eyad 曾作为软件工程师（SWE）在亚马逊、迪士尼和第一资本工作了7年，交付的代码触达数百万用户，构建的系统不容有失。现在，他是一家为企业构建智能体的创业公司的CTO，而 Claude Code 是他日常工作的核心驱动力

这份初学者指南，浓缩了Eyad使用 Claude 构建处理大型公司复杂工作负载的稳健系统后，所学到的一切。希望能对你有所帮助

先思考，后动手

大多数人认为，使用 Claude Code 等 AI 工具时，第一步就是开始打字（或说话）。但这恰恰是你能犯下的最大错误之一。你真正需要做的第一件事是思考。

十次里有十次，我在“规划模式”下获得的输出，都远胜于我直接开口、把所有想法倾倒给 Claude Code 的结果。两者效果天差地别。

对一些人来说，这可能说起来容易做起来难。你可能没有多年的软件工程经验来自行思考。对此，我有两点建议：

1. 1. 开始学习。 如果你从不掌握这项技能，你就在限制自己，哪怕每次只学一点点。

2. 2. 与 ChatGPT/Gemini/Claude 进行深入的来回交流。 精确描述你想构建什么，询问 LLM 在系统设计方面有哪些选项，最终你们共同确定一个解决方案。你和 LLM 应该互相提问，而不是单向灌输。

这一点适用于所有事，包括像总结邮件这样的小任务。在让 Claude 构建功能前，先思考架构；在让它重构代码前，先思考最终应有的形态；在让它调试前，先思考你对问题已知的确切信息。你在规划模式中提供的信息越多，输入质量就越高，输出质量也自然会越好。

这个模式始终如一：先思考，再输入，比先输入、指望 Claude 自己搞明白，能产生好得多的结果。

这就引出了我的下一点：架构。尤其在软件工程中，只给出一个最终目标而不提供过程，就像只告诉一个人目的地却不给地图。这为如何到达目的地留下了巨大的“自由发挥”空间，而这正是 AI 生成代码问题的核心所在。

比较一下两种说法的区别：宽泛的“给我建一个认证系统”，与明确的“使用现有的 User 模型构建邮箱/密码认证，将 session 存储在 Redis 中并设置 24 小时过期，同时添加中间件保护 /api/protected 下的所有路由。” 你会发现差异巨大。

连按两次 Shift + Tab 键，即可进入规划模式。相信我，这会花掉你5分钟，但能为你省下后续数小时的调试时间。

CLAUDE.md：你的项目专属说明书

CLAUDE.md 是一个 Markdown 文件。Markdown 是一种 AI 模型处理得非常好的文本格式，而 Claude 对它的处理能力尤其出色。

当你启动一个 Claude Code 会话时，它做的第一件事就是读取你的 CLAUDE.md 文件。文件中的每条指令都会塑造 Claude 处理你项目的方式。这本质上是 Claude 在每次对话前都会阅读的“入职材料”。

大多数人要么完全忽略它，要么用一些垃圾信息把它填满，结果反而让 Claude 表现更差。信息过多或过少都存在一个阈值，超过或低于这个阈值都会导致模型输出质量下降。

以下是真正重要的几点：

1. 1. 保持简短。 Claude 一次只能可靠地遵循大约150到200条指令，而 Claude Code 的系统提示本身已经占用了约50条。你添加的每条指令都在争夺它的注意力。如果你的 CLAUDE.md 像一本小说，Claude 就会开始随机忽略某些内容，而你无从知晓。

2. 2. 内容要针对你的项目。 不要解释什么是“components”文件夹，Claude 知道。告诉它那些项目特有的、奇怪的东西，比如那些真正重要的 bash 命令。所有属于你工作流的东西都应该放进去。

3. 3. 解释原因，而不仅仅是做什么。 在这方面，Claude 有点像人。当你给出指令背后的原因时，它会比只被告知做什么时执行得更好。“使用 TypeScript 严格模式”是可以的，但“使用 TypeScript 严格模式，因为我们曾因隐式的 any 类型导致过生产环境的 bug”则更佳。这个“为什么”为 Claude 在处理你未预料到的判断时提供了上下文。你会惊讶于这种方法的有效性。

4. 4. 持续更新。 在工作时按下 # 键，Claude 会自动将指令添加到你的 CLAUDE.md 中。每当你发现自己第二次纠正 Claude 同一个问题时，这就是一个信号：它应该被写进文件里。随着时间的推移，你的 CLAUDE.md 会成为一份关于你代码库如何运作的活文档。

一个糟糕的 CLAUDE.md 看起来像为新员工写的文档。一个好的 CLAUDE.md 看起来像你为明天失忆的自己留下的笔记。

理解上下文窗口的局限性

例如，Opus 4.5 拥有20万 token 的上下文窗口。但大多数人没有意识到的是：在远未达到100%使用率时，模型的性能就开始衰退了。（具体情况取决于你是通过 API 还是桌面应用使用）

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

你发送的每条消息、Claude 读取的每个文件、它生成的每段代码、每个工具的返回结果——所有这些都会累积。一旦质量开始下降，增加更多的上下文只会让情况变得更糟。以下是一些避免上下文质量糟糕的有效方法：

• • 限定对话范围。 每个功能或任务使用一个独立的对话。不要在同一个对话中既构建认证系统又重构数据库层。上下文会混杂在一起，让 Claude 感到困惑。

• • 使用外部记忆。 如果你在处理复杂问题，让 Claude 把计划和进展写到实际文件中（我使用 SCRATCHPAD.md 或 plan.md）。这些文件可以跨会话持久存在。当你第二天回来时，Claude 可以读取文件，从你离开的地方继续，而不是从零开始。

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

• • 知道何时清空。 如果一个对话已经偏离轨道或积累了大量不相关的上下文，直接用 /clear 重新开始。这比试图在混乱中继续工作要好。Claude 仍然会读取你的 CLAUDE.md，所以你不会丢失项目上下文。十次中有九次，使用 /clear 实际上是更好的选择。

有效的心智模型是：Claude 是无状态的。 每次对话都从零开始，除了你明确提供给它的信息。请据此进行规划。

Prompt 即一切

人们花数周时间学习框架和工具，却花零时间学习如何与那个实际生成他们代码的东西进行沟通。

Prompt 工程不是什么神秘艺术，它可能是最基本的沟通形式。和任何沟通一样，清晰明确总比含糊不清能获得更好的结果。每一次都是如此。

真正有帮助的做法是：

• • 具体说明你想要什么。 “构建一个认证系统”给了 Claude 它会滥用的创作自由。“使用这个已有的 User 模型构建邮箱/密码认证，将 session 存入 Redis，并添加中间件保护 /api/protected 下的路由”则给了 Claude 一个清晰的目标。

• • 告诉它不该做什么。 Claude 有其倾向性。特别是 Claude 4.5 喜欢过度工程化——额外的文件、不必要的抽象、你没要求过的灵活性。如果你想要最简化的东西，就说：“保持简单。不要添加我没要求的抽象。如果可能，只用一个文件。” 同时，一定要交叉检查 Claude 的产出，你不想最终背上技术债。

• • 提供“为什么”的背景。 “我们需要这个功能速度快，因为它在每个请求上都会运行”会改变 Claude 解决问题的方式。“这是一个我们会扔掉的原型”则会改变它在权衡取舍时的考量。Claude 无法读懂你心中那些未提及的约束。

记住：输出决定一切，但输出只来源于输入。如果你的输出很差，那说明你的输入很差。 别无他法。

坏输入 = 坏输出

当得到不好的结果时，人们会责怪模型。“Claude 不够聪明”或者“我需要一个更好的模型”。

现实是：问题出在你身上。如果你用像 Opus 4.5 这样的好模型却持续得到糟糕的输出，那意味着你的输入和你的 Prompt 很差。就是这样。

模型固然重要，但模型质量如今已是基本门槛。瓶颈几乎总是在人这一边：你如何构建 Prompt，如何提供上下文，如何清晰地传达你真正想要什么。

如果你持续得到糟糕的结果，解决方法不是换模型，而是提升以下能力：

• • 你如何编写 Prompt： 具体 > 模糊，约束 > 开放，示例 > 描述。

• • 你如何组织请求： 将复杂任务分解成步骤，在实现前先就架构达成一致，审查输出并迭代。

• • 你如何提供上下文： Claude 需要知道什么才能做好这件事？你做了哪些 Claude 看不到的假设？

话虽如此，不同模型之间确实存在差异：

• • Sonnet 更快、更便宜。它非常适合执行路径明确的任务——编写样板代码、根据具体计划进行重构、实现你已做出架构决策的功能。

• • Opus 更慢、更贵。它更擅长复杂的推理、规划以及需要 Claude 深入思考权衡的任务。

一个有效的工作流是：用 Opus 进行规划和架构决策，然后切换到 Sonnet (在 Claude Code 中按 Shift+Tab) 进行实现。 你的 CLAUDE.md 确保两个模型在相同的约束下运作，使得交接过程非常顺畅。

善用工具与配置：MCP、钩子和命令

Claude 拥有大量的功能：MCP 服务器、钩子（Hooks）、自定义斜杠命令、settings.json 配置、技能（Skills）、插件（Plugins）。

你不需要全部都用上。但你应该去尝试和实验，因为不实验，你可能就在浪费时间或金钱。

• • MCP (Model Context Protocol) 让 Claude 连接到外部服务，如 Slack、GitHub、数据库、API。如果你发现自己总是在从一个地方复制信息到 Claude，很可能有一个 MCP 服务器能自动完成这件事。

• • 钩子 (Hooks) 让你在 Claude 进行更改前后自动运行代码。想让 Prettier 在 Claude 碰过的每个文件上运行？用钩子。想在每次编辑后进行类型检查？用钩子。这能立即捕获问题，而不是让它们堆积起来。

• • 自定义斜杠命令 是你重复使用的 Prompt，被打包成了命令。创建一个 .claude/commands 文件夹，添加包含你 Prompt 的 Markdown 文件，然后你就可以用 /commandname 来运行它们。

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

而且，不要因为某样东西第一次尝试失败就放弃。这些模型几乎每周都在改进。一个月前行不通的东西，现在可能就可以了。

当 Claude 卡住时怎么办

有时 Claude 会陷入循环。它尝试同样的事情，失败，再试，再失败，如此往复。或者它自信地实现了一个完全错误的东西，你得花二十分钟去解释为什么错了。

发生这种情况时，人的本能是继续推进：给更多指令、更多修正、更多上下文。但现实是，更好的做法是彻底改变方法。

• • 清空对话。 累积的上下文可能正在迷惑它。/clear 给你一个全新的开始。

• • 简化任务。 如果 Claude 难以处理一个复杂任务，把它分解成更小的部分。在组合之前，确保每个部分都能正常工作。但实际上，如果 Claude 在复杂任务上挣扎，这通常意味着你的规划模式做得不够充分。

• • 展示而非告知。 如果 Claude 一直误解你的意图，自己写一个最小化的例子。“看，输出应该长这样。现在把这个模式应用到其余部分。” Claude 非常擅长理解成功的范例并遵循它。

• • 创新思路。 尝试一个不同的角度。有时你描述问题的方式与 Claude 的“思维”方式不匹配。重新表述——比如从“处理这些状态转换”变为“将此实现为一个状态机”——可能会打开僵局。

这里的元技能是及早识别出你正处于一个循环中。如果你已经把同一件事解释了三遍而 Claude 仍然不明白，更多的解释是无济于事的。改变点什么吧。

构建系统，而非一次性任务

从 Claude 获得最大价值的人，不是用它来完成一次性任务，而是构建以 Claude 为组件的系统。

Claude Code 的 -p 标志支持无头模式（headless mode）。它会运行你的 Prompt 并输出结果，而无需进入交互界面。这意味着你可以用脚本调用它，将输出通过管道传递给其他工具，与 bash 命令链接，将其集成到自动化工作流中。

企业正在用它来实现自动 PR 审查、自动支持工单回复、自动日志记录和文档更新。所有这些都被记录、可审计，并根据有效和无效的反馈随着时间推移而改进。

这是一个飞轮效应：Claude 犯错 -> 你审查日志 -> 你改进 CLAUDE.md 或工具 -> Claude 下次做得更好。这种改进是复合式的。我现在正在尝试让 Claude 能够自我改进它的 CLAUDE.md 文件。

如果你只在交互模式下使用 Claude，你就在浪费它的价值。思考一下，在你工作流的哪些环节，Claude 可以在没有你监督的情况下运行。

要点总结

先思考，后动手。 规划比直接开聊能产生好得多的结果

CLAUDE.md 是你的杠杆点。 保持简短、具体，解释原因，并持续更新。这个文件影响每一次交互

上下文在30%使用率时就开始退化，而不是100%。 使用外部记忆，限定对话范围，并善用“复制-粘贴重置”技巧

架构比任何事都重要。 你不能跳过规划。没有预先思考结构，输出就会很糟糕

输出源于输入。 如果你用好模型得到坏结果，是你的 Prompt 需要改进。提升你的沟通能力

实验工具和配置。 MCP、钩子、斜杠命令。如果你是付费用户，把所有功能都试一遍

卡住时，改变方法。 不要陷入循环。清空、简化、展示、重新构思

构建系统，而非一次性任务。 利用无头模式、自动化，并随时间记录和改进。

source：

https://x.com/eyad_khrais/status/2010076957938188661?s=20