第一时间捕获有价值的信号
本文译自 X（原 Twitter）上 Eyad 的帖子 The complete claude code tutorial。作者是一位有 7 年经验的软件工程师，曾在 Amazon、Disney 和 Capital One 工作，现在是一家构建企业级代理的初创公司的 CTO。这篇教程干货满满，小技巧非常受用，不仅适用于 Claude Code，任何流行的 AI 编码工具都适用。
我做 SWE 已经 7 年了，在 Amazon、Disney 和 Capital One 工作过。我发布的代码触及数百万用户，我构建的系统不容出错。现在我是一家为企业构建代理的初创公司的 CTO，Claude Code 是我的日常工具。
这里有一个你可能会觉得有用的初学者手册，包含我在使用 Claude 构建处理大公司复杂工作负载的健壮系统后学到的所有内容。如果这对你有帮助，请在下面告诉我。
先思考
大多数人认为，有了 Claude Code 和其他 AI 工具，你需要做的第一件事就是打字（或开始说话）。但这可能是你一开始能犯的最大错误之一。你实际上需要做的第一件事是思考。
10 次中有 10 次，我使用计划模式获得的输出比我刚开始说话并把所有东西都塞进 Claude Code 时要好得多。这甚至没有可比性。
现在对于你们中的一些人来说，这说起来容易做起来难。你可能没有多年的软件工程经验让你能够自己思考这个问题。就此而言，我有两条建议：1. 开始学习。如果你从不学习这一点，即使只是一点点，你也是在 handicapping 自己。
- 与 ChatGPT/Gemini/Claude 进行深入的来回交流，在那里你准确描述你想要构建什么，你询问 LLM 你可以在系统设计方面采取的各种选项，最终你们两个确定一个解决方案。你和 LLM 应该互相问问题，而不只是单向交流。
这适用于所有事情。这也包括非常小的任务，如总结电子邮件。在你要求 Claude 构建功能之前，思考架构。在你要求它重构某些东西之前，思考最终状态应该是什么样子。在你要求它调试之前，思考你实际上对这个问题了解什么。你在计划模式中拥有的信息越多，你的输出实际上就会越好，因为输入就会越好。
模式是一致的：先思考，再打字，比先打字然后希望 Claude 弄清楚产生显著更好的结果。
这引出了我的下一个观点，架构。架构，特别是在软件工程中，有点像只给一个人输出而没有其他内容。这为如何到达输出留下了很大的回旋余地，这本质上就是 AI 生成代码的问题所在。如果你说一些非常宽泛的话，比如”给我构建一个 auth 系统”，而不是”使用现有的 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 会开始随机忽略东西，你不会知道是哪些东西。
让它特定于你的项目。不要解释什么是 components 文件夹。Claude 知道组件是什么。告诉它奇怪的东西，比如实际上重要的 bash 命令。作为你流程一部分的所有内容都应该进入其中。
告诉它为什么，而不只是什么。Claude 在这方面有点像人类。当你给它指令背后的原因时，Claude 比你只告诉它做什么实现得更好。“使用 TypeScript 严格模式”是可以的。“使用 TypeScript 严格模式，因为我们从隐式 any 类型产生过生产 bug”更好。为什么给 Claude 上下文来做出你没有预料到的判断调用。你会惊讶于这实际上有多有效。
不断更新它。在你工作时按 # 键，Claude 会自动向你的 CLAUDE.md 添加指令。每次你发现自己在同样的事情上纠正 Claude 两次，这就是一个信号，它应该在文件中。随着时间的推移，你的 CLAUDE.md 变成你的代码库实际上如何工作的活文档。
糟糕的 CLAUDE.md 看起来像为新员工写的文档。好的 CLAUDE.md 看起来像你留给自己的笔记——如果你知道你明天会失忆的话。
上下文窗口的限制
例如，Opus 4.5 有 200,000 的上下文窗口。但这里是大多数人没有意识到的：模型在达到 100% 之前就开始恶化了。（这取决于你是通过 API 还是桌面应用程序使用）
在大约 20-40% 的上下文使用时，输出质量开始逐渐下降，即使不显著。如果你曾经体验过 Claude Code 压缩后仍然给你糟糕的输出，那就是原因。模型在压缩发生之前就已经退化了，压缩不会神奇地恢复质量。（点击 /compact 进行压缩）
你发送的每条消息、Claude 读取的每个文件、它生成的每段代码、每个工具结果——所有这些都在累积。一旦质量开始下降，更多的上下文会让它变得更糟，而不是更好。所以这里有一些实际上有助于不拥有糟糕上下文的事情
界定你的对话。每个功能或任务一个对话。不要使用同一个对话来构建你的 auth 系统，然后还重构你的数据库层。上下文会混在一起，Claude 会困惑。我知道至少有一个正在读这个的人会对此感到内疚。
使用外部记忆。如果你正在处理复杂的事情，让 Claude 将计划和进度写入实际文件（我使用 SCRATCHPAD.md 或 plan.md）。这些在会话之间持续存在。当你明天回来时，Claude 可以读取文件并从你离开的地方继续，而不是从零开始。旁注：如果你有一个文件层次结构系统，将这些保持在顶层是让它们对你决定构建的每个任务/功能都有效的方式。
复制粘贴重置。这是我经常使用的一个技巧。当上下文变得臃肿时，我从终端复制所有重要的内容，运行 /compact 获取摘要，然后完全 /clear 上下文，并只粘贴回重要的内容。保留关键信息的新鲜上下文。比让 Claude 在退化的上下文中挣扎好得多。
知道何时清除。如果一个对话已经偏离轨道或累积了一堆不相关的上下文，只需 /clear 并重新开始。这比试图通过困惑来工作更好。Claude 仍然会有你的 CLAUDE.md，所以你不会丢失你的项目上下文。十次中有九次，使用清除实际上比不使用它更好，尽管这听起来违反直觉。
有效的心智模型：Claude 是无状态的。每次对话都从零开始，除了你明确给它的东西。相应地计划。
提示就是一切
人们花数周学习框架和工具。他们花零时间学习如何与实际生成他们代码的东西交流。
提示不是什么神秘的艺术。它可能是最基本的交流形式。就像任何交流一样，清晰比模糊给你更好的结果。每一次。都是这样。
实际上有帮助的：
具体说明你想要什么。“构建一个 auth 系统”给 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 确保两个模型在相同的约束下运行，所以切换是干净的。
MCP、工具和配置
Claude 有荒谬数量的功能。MCP 服务器。钩子。自定义斜杠命令。Settings.json 配置。技能。插件。
你不需要所有这些。但你应该实际尝试它们并实验，因为如果你不实验，你可能会把时间或金钱留在桌面上。我向你保证，Claude 中至少有一个你不知道的新功能，如果你关注 Claude Code 的创始人 Boris，你实际上可以了解到它。
MCP（模型上下文协议）让 Claude 连接到外部服务。Slack、GitHub、数据库、API。如果你发现自己不断将信息从一个地方复制到 Claude，可能有一个 MCP 服务器可以自动完成。有很多 MCP 市场，如果没有 MCP，它只是获取结构化数据的一种方式，所以你可以只为目前不存在的任何工具创建自己的 MCP 服务器。如果你找到一个不存在的，我会非常惊讶。
钩子让你在 Claude 做出更改之前或之后自动运行代码。希望 Prettier 在 Claude 接触的每个文件上运行？钩子。每次编辑后进行类型检查？钩子。这立即捕获问题，而不是让它们堆积起来。这实际上也是帮助消除技术债务的方法。如果你在每一千行之后设置一个特定的钩子，你可能有安全功能清理你的代码。当 Claude 审阅你的 PR 时，这应该非常有帮助。
自定义斜杠命令只是你重复使用的提示，打包为命令。创建一个 .claude/commands 文件夹，添加带有你的提示的 markdown 文件，现在你可以用 /commandname 运行它们。如果你经常运行相同类型的任务——调试、审阅、部署——把它变成一个命令。
如果你有 Pro Max 计划（我支付 200 美元/月），为什么不尝试 Claude 必须提供的所有东西？看看什么有效，什么无效。反正你已经在付钱了。
而且这里是：不要因为某些东西第一次不工作就关闭。这些模型基本上每周都在改进。一个月前不工作的东西现在可能工作了。成为早期采用者意味着保持好奇并重新测试东西。
当 Claude 卡住时
有时 Claude 只是循环。它尝试同样的事情，失败，再试一次，失败，并继续下去。或者它自信地实现一些完全错误的东西，你花二十分钟试图解释为什么。
当发生这种情况时，本能是继续推动。更多指令。更多更正。更多上下文。但现实是，更好的举动是完全改变方法。
从简单开始——清除对话。累积的上下文可能让它困惑。/clear 给你一个新的开始。
简化任务。如果 Claude 在复杂任务上挣扎，将其分解成更小的部分。在组合它们之前让每个部分工作。但实际上，如果 Claude 在复杂任务上挣扎，那意味着你的计划模式不够。
展示而不是告诉。如果 Claude 一直误解你想要什么，自己写一个最小的例子。“这是输出应该看起来的样子。现在将这个模式应用到其余部分。“Claude 非常擅长理解成功指标是什么，并且实际上能够遵循它们，了解好的例子是什么。
要有创意。尝试不同的角度。有时你构建问题框架的方式与 Claude 的思考方式不太匹配。重新框架——“将其实现为状态机” vs “处理这些转换”——可以解锁进展。
这里的元技能是尽早识别你何时处于循环中。如果你已经解释了同样的事情三次而 Claude 仍然没有理解，更多解释不会有帮助。改变一些东西。
构建系统
从 Claude 获得最多价值的人不是将其用于一次性任务的人。他们正在构建 Claude 作为组件的系统。但 Claude Code 比那更好得多。它有一个用于无头模式的 -p 标志。它运行你的提示并输出结果，而不进入交互式界面。这意味着你可以脚本化它。将输出管道传输到其他工具。用 bash 命令链接它。将其集成到自动化工作流中。
企业正在使用此进行自动 PR 审阅、自动支持工单响应、自动日志记录和文档更新。所有这些都被记录、可审计，并随着时间的推移基于什么有效什么无效而改进。
飞轮：Claude 犯错，你审阅日志，你改进 CLAUDE.md 或工具，Claude 下次变得更好。这会复合。现在我正在能够让 Claude 已经改进它自己的 Claude.md 文件。经过数月的迭代，以这种方式构建的系统比发布时明显更好——相同的模型，只是配置更好。
如果你只是交互式地使用 Claude，你正在把价值留在桌面上。想想你的工作流中 Claude 可以在你不观看的情况下运行的地方。
TLDR
打字前先思考。规划产生的结果比刚开始说话显著更好。
CLAUDE.md 是你的杠杆点。保持简短、具体、告诉它为什么，并不断更新。这个单个文件影响每次交互。
上下文在 30% 时退化，而不是 100%。使用外部记忆、界定对话，并且不要害怕使用复制粘贴重置技巧清除并重新开始。
架构比任何东西都重要。你不能跳过规划。如果你不先思考结构，输出会很糟糕。
输出来自输入。如果你使用好模型得到糟糕的结果，你的提示需要工作。变得更好于交流。
用工具和配置做实验。MCP、钩子、斜杠命令。如果你为 Pro Max 付费，尝试所有东西。即使事情第一次不工作也要保持好奇。
卡住时，改变方法。不要循环。清除、简化、展示、重新框架。
构建系统，而不是一次性任务。无头模式、自动化、随时间的日志改进。
如果你正在用 Claude 构建——无论是你自己的项目还是生产系统——这些是决定你是在与工具作斗争还是与它一起流动的事情。
现代技术荒谬地强大。如果你想要更多关于如何为自己或你的企业充分利用 AI 的提示，订阅我的免费每周 AI 新闻通讯：