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

　　
来源：AI寒武纪

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

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

　　先思考，后动手

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

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

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

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

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

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

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

　　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