Claude Code 完整教程：7 年经验老兵的实战心得

本文译自 X（原 Twitter）上 Eyad 的帖子 The complete claude code tutorial。作者是一位有 7 年经验的软件工程师，曾在 Amazon、Disney 和 Capital One 工作，现在是一家企业级智能体初创公司的 CTO。这篇教程干货满满，实用技巧不仅适用于 Claude Code，对所有主流 AI 编码工具都通用。

我做软件工程师已经 7 年了，先后在 Amazon、Disney 和 Capital One 任职，经手的代码服务过数百万用户，负责的系统要求极高的稳定性。现在我是一家企业级智能体初创公司的 CTO，Claude Code 是我每天都在使用的主力工具。

这篇初学者手册是我用 Claude 构建过大量企业级高复杂度系统后总结的实战经验，相信会对你有用。如果觉得有帮助，欢迎在评论区交流。

先思考，再动手

很多人以为有了 Claude Code 这类 AI 工具，第一件事就是直接敲需求（或者语音输入）。但这恰恰是新手最容易犯的错误——你最该做的第一件事，是先自己想清楚。

每次用计划模式得到的输出质量，都远好于直接把一堆零散需求塞给 Claude Code，效果差距可以说天差地别。

可能有人会说这话说起来容易做起来难，毕竟不是所有人都有多年软件工程经验，能自己想清楚所有问题。对此我有两个建议：

1. 主动学习基础能力。哪怕只掌握一点点架构设计思维，也能避免你严重自我限制
2. 先和 ChatGPT/Gemini/Claude 做一轮深入的需求沟通，清晰描述你要做的东西，询问不同的系统设计方案，最终和 LLM 共同确定一个最优解。整个过程应该是双向提问、互相澄清，而不是你单向输出要求。

这个原则适用于所有场景，哪怕是总结邮件这种非常小的任务也一样：

• 让 Claude 开发功能之前，先想清楚架构设计
• 让它重构代码之前，先想清楚最终要达成的状态
• 让它调试问题之前，先梳理清楚你已经掌握的问题信息

你在计划阶段提供的信息越充分，最终输出质量就越高，因为输入决定输出。

核心逻辑永远不变：先思考，再动手，比上来就敲需求然后指望 Claude 帮你搞定一切，产出的结果要好得多。

这就引出了下一个关键点：架构设计。软件工程里的架构设计，就像只告诉别人最终要产出什么，却不说怎么实现——这给执行留下了太大的灵活空间，恰恰是 AI 生成代码最容易出问题的地方。 如果你只说”给我做个鉴权系统”，和你说”基于现有 User 模型实现邮箱/密码登录，会话存在 Redis 中 24 小时过期，添加中间件保护所有 /api/protected 下的路由”，得到的结果天差地别。

按两次 Shift+Tab 就能进入计划模式，虽然会花你 5 分钟时间，但能帮你省下后面几小时的调试时间，非常划算。

用好 CLAUDE.md

CLAUDE.md 是一个 Markdown 文件，AI 模型对这种格式的处理效果非常好，尤其是 Claude，比我测试过的大多数其他模型表现都要好。

启动 Claude Code 会话时，Claude 做的第一件事就是读取 CLAUDE.md 文件，里面的每一条指令都会影响 Claude 处理你项目的方式，相当于 Claude 每次对话前必读的项目入门手册。

大多数人要么完全忽略这个文件，要么往里面塞一堆没用的信息，反而让 Claude 的表现更差。信息太多或太少都会降低模型输出质量，这里有个最优阈值。

CLAUDE.md 里真正需要写的内容：

• 保持简短：Claude 一次最多能稳定遵守 150-200 条指令，而 Claude Code 的系统提示已经占了约 50 条。你加的每一条指令都在抢占注意力资源，如果 CLAUDE.md 写得像小说一样长，Claude 会开始随机忽略部分内容，你还不知道它忽略了什么。
• 只写项目特有的内容：不用解释什么是 components 文件夹，Claude 知道组件是什么。你只需要告诉它项目里特殊的地方，比如常用的 bash 命令、你们团队特有的流程规范。
• 告诉它原因，而不只是要求：Claude 在这一点上和人类很像，当你给它说明指令背后的原因时，它的执行效果会好很多。“使用 TypeScript 严格模式”是普通要求，“使用 TypeScript 严格模式，我们之前因为隐式 any 类型出过生产事故”是更好的要求。原因能给 Claude 提供上下文，让它在遇到你没预料到的情况时做出正确判断，效果好到超乎你的想象。
• 持续更新：工作时按 # 键，Claude 会自动往 CLAUDE.md 里添加指令。如果你发现自己在同一件事上纠正了 Claude 两次，就说明这条规则应该写到文件里。随着时间推移，你的 CLAUDE.md 会变成代码库实际运行规则的活文档。

差的 CLAUDE.md 写得像给新员工看的入职文档，好的 CLAUDE.md 写得像你给明天会失忆的自己留的便签。

上下文窗口的限制

比如 Opus 4.5 有 20 万 token 的上下文窗口，但大多数人不知道的是：模型的输出质量在上下文占满之前就会开始下降（具体下降阈值取决于你是用 API 还是桌面应用）。

当上下文使用率到 20-40% 时，输出质量就会开始逐渐下降，哪怕下降幅度不明显。如果你遇到过 Claude Code 压缩后输出还是很差的情况，就是这个原因——压缩之前模型能力已经退化了，压缩不会神奇地恢复质量。（输入 /compact 可以手动压缩上下文）

你发的每条消息、Claude 读的每个文件、它生成的每段代码、每个工具返回结果——所有内容都会累积。一旦质量开始下降，更多上下文只会让情况更糟。这里有几个实用技巧可以避免上下文臃肿：

• 对话隔离：每个功能或任务开一个新对话，不要用同一个对话既做鉴权系统又重构数据库层，上下文混在一起 Claude 会混乱。我相信至少有一个正在看这篇文章的人干过这事。
• 使用外部记忆：如果你在处理复杂任务，让 Claude 把计划和进度写到实际文件里（我一般用 SCRATCHPAD.md 或 plan.md），这些文件会在会话之间持久化。第二天回来时，Claude 可以直接读文件从你离开的地方继续，不用从零开始。建议把这些文件放在项目顶层，这样每个任务都能方便使用。
• 复制粘贴重置：这是我经常用的技巧。当上下文变得臃肿时，我会从终端复制所有重要内容，运行 /compact 获取摘要，然后用 /clear 完全清空上下文，再把重要内容粘贴回去。这样既保留了关键信息，又获得了干净的上下文，比让 Claude 在退化的上下文里挣扎效率高得多。
• 知道什么时候该清空：如果一个对话已经偏离轨道，或者累积了一堆不相关的上下文，直接 /clear 重新开始。这比试图在混乱的上下文里硬抠要高效得多，Claude 依然会读取你的 CLAUDE.md，所以不会丢失项目上下文。十有八九，清空重开会比硬撑着更好，虽然听起来违反直觉。

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

提示词就是一切

人们愿意花数周时间学习框架和工具，却不愿意花一点时间学习怎么和生成代码的 AI 沟通。

提示词不是什么神秘的艺术，它就是最基础的沟通能力。和任何沟通一样，清晰永远比模糊得到的结果好，次次如此。

真正有用的提示词技巧：

• 明确说明你要什么：“做个鉴权系统”给 Claude 留了太大的发挥空间，结果往往很差；“基于现有 User 模型实现邮箱/密码登录，会话存在 Redis 中，添加中间件保护 /api/protected 下的所有路由”给了 Claude 清晰的目标，哪怕不完美也差不到哪去。
• 告诉它不要做什么：Claude 有自己的偏好，尤其是 Claude 4.5 特别喜欢过度工程——额外的文件、不必要的抽象、你没要求的灵活性。如果你想要简单的实现，直接说”保持简单，不要加我没要求的抽象，尽量用单个文件实现”。另外，一定要交叉检查 Claude 生成的内容，不要留下不必要的技术债务，特别是本来几行代码就能搞定的简单任务，它可能给你建十几个文件。
• 给它背景原因：“这个接口要快，因为每个请求都会调用”会改变 Claude 处理问题的方式；“这是个会扔掉的原型”会让它选择更合适的权衡方案。Claude 不会读心术，你不说的约束它不知道。
• 记住：输出完全由输入决定。如果输出很差，那肯定是你的输入有问题，没有例外。

糟糕的输入 == 糟糕的输出

人们得到糟糕结果时总会怪模型：“Claude 不够聪明”或者”我需要个更好的模型”。

现实是：问题出在你自己身上。如果你用 Opus 4.5 这种级别的模型还得到糟糕的输出，说明你的输入和提示词有问题，就这么简单。

模型当然重要，但现在这个阶段，模型质量已经是标配了，瓶颈几乎永远在人这边：你怎么组织提示词、怎么提供上下文、怎么清晰地表达你真正想要的东西。

如果你一直得到糟糕的结果，解决方法不是换模型，而是提升这几方面的能力：

• 写提示词的能力：具体 > 模糊，有约束 > 开放式，给示例 > 纯描述
• 组织请求的能力：把复杂任务拆成多个步骤，实现前先对齐架构，审核输出并迭代
• 提供上下文的能力：Claude 需要知道什么才能做好这件事？你有什么默认假设是 Claude 看不到的？

当然，模型之间确实有实际差异：

• Sonnet 更快更便宜，非常适合路径清晰的执行类任务：写样板代码、基于明确方案重构、实现已经做好架构决策的功能
• Opus 更慢更贵，更适合复杂推理、规划，以及需要 Claude 深入权衡的任务

一个高效的工作流：用 Opus 做规划和架构决策，然后切到 Sonnet（Claude Code 里按 Shift+Tab 切换）做实现。当然也要看具体任务，有时候也可以用 Opus 4.5 直接做实现。不过如果你用 API 调用 Opus，成本会非常高。你的 CLAUDE.md 能保证两个模型在相同的约束下运行，所以切换起来非常干净。

MCP、工具和配置

Claude 有非常多功能：MCP 服务器、Hooks、自定义斜杠命令、Settings.json 配置、Skills、插件等等。

你不需要用到所有功能，但你应该实际去尝试和实验，不然你可能在浪费时间或金钱。我敢保证 Claude 里至少有一个你不知道的新功能能提升你的效率，关注 Claude Code 的创始人 Boris 就能了解最新功能动态。

• MCP（模型上下文协议）：让 Claude 连接到外部服务，比如 Slack、GitHub、数据库、API。如果你发现自己一直在把信息从别的地方复制到 Claude 里，大概率有现成的 MCP 服务器能帮你自动化。现在有很多 MCP 市场，就算没有现成的，你也可以自己写，MCP 本质就是获取结构化数据的标准方式，你很难遇到完全没有对应 MCP 的工具。
• Hooks：让你在 Claude 做出更改前后自动运行代码。想让 Claude 碰过的每个文件都自动跑 Prettier？用 Hook。每次编辑后自动做类型检查？用 Hook。这能第一时间发现问题，而不是让问题堆积起来，还能帮你减少技术债务。如果你设置合适的 Hook，甚至可以在每千行代码提交前自动做安全检查和清理，对 Claude 做 PR 审核也非常有帮助。
• 自定义斜杠命令：就是把你常用的提示词打包成命令。创建一个 .claude/commands 文件夹，在里面加带提示词的 Markdown 文件，你就可以用 /commandname 直接运行它们。如果你经常做同类任务——调试、审核、部署——就把它做成命令。

如果你买了 Pro Max 计划（我每个月付 200 美元），为什么不把 Claude 提供的所有功能都试一遍？看看哪些有用哪些没用，反正钱已经付了。

还有一点：不要因为某个功能第一次不好用就完全放弃。这些模型基本上每周都在迭代，一个月前不好用的功能现在可能已经很好用了。做早期采用者就要保持好奇心，定期重试过时的结论。

当 Claude 卡住时

有时候 Claude 会进入死循环：重复做同样的事、反复失败，或者自信地实现完全错误的逻辑，你花二十分钟都解释不清楚为什么错。

遇到这种情况，人的本能是继续推动：加更多指令、更多纠正、更多上下文。但实际上更好的做法是完全换个方法：

• 从最简单的开始：清空对话。累积的上下文可能让它混乱了，/clear 给你一个全新的开始
• 简化任务：如果 Claude 在复杂任务上卡住了，把它拆成更小的部分，每个部分单独跑通再组合。如果 Claude 搞不定复杂任务，说明你之前的计划模式做得不够充分
• 展示而不是告诉：如果 Claude 一直误解你的需求，自己写一个最小示例。“这是输出应该的样子，把这个模式应用到剩下的部分”。Claude 非常擅长理解成功标准，只要给它好的示例，它就能准确遵循。
• 换个角度：有时候你描述问题的方式和 Claude 的思考方式不匹配，换个框架——比如把”处理这些状态转换”说成”把它实现为状态机”——可能就打通了。

这里的元技能是尽早识别死循环：如果你已经把同一件事解释了三遍 Claude 还是没懂，再解释更多也没用，换个方法。

构建系统，而不是一次性任务

从 Claude 获得最大价值的人，不是用它做一次性任务的人，而是把 Claude 作为系统组件的人。Claude Code 还有个无头模式的 -p 参数，不用进入交互界面就能运行你的提示词并输出结果，这意味着你可以把它脚本化、把输出管道给其他工具、和 bash 命令串联、集成到自动化工作流里。

企业已经在用这个做自动 PR 审核、自动支持工单回复、自动日志分析和文档更新。所有流程都可记录、可审计，还能根据运行效果不断迭代优化。

形成飞轮效应：Claude 犯错 → 你审核日志 → 你改进 CLAUDE.md 或工具 → Claude 下次表现更好，这个效应是复利的。我现在已经能让 Claude 自己优化它的 Claude.md 文件了，经过几个月的迭代，用这种方式构建的系统会比刚发布时好得多——用的还是同一个模型，只是配置更好了。

如果你只交互性地使用 Claude，你正在浪费很大一部分价值。想想你的工作流里有哪些地方可以让 Claude 在你不用盯着的情况下自动运行。

核心要点总结

• 打字前先思考。提前规划得到的结果远好于上来就直接提需求
• CLAUDE.md 是你的核心杠杆点。保持简短、具体、说明原因、持续更新，这一个文件影响你和 Claude 的每一次交互
• 上下文使用率到 30% 就开始退化，不是等到 100%。用外部记忆、隔离对话，不要害怕清空上下文重开
• 架构设计比什么都重要，不能跳过规划。如果你不先想清楚结构，输出质量一定会很差
• 输出由输入决定。用好模型还得到糟糕结果，说明你的提示词需要优化，提升沟通能力
• 多尝试工具和配置。MCP、Hooks、斜杠命令，如果你付了高级订阅费，就把所有功能都试一遍，保持好奇心
• 卡住时换方法，不要死循环。清空、简化、给示例、换角度描述
• 构建系统，而不是做一次性任务。用无头模式做自动化，基于日志持续迭代优化

如果你正在用 Claude 做开发——不管是个人项目还是生产系统——以上这些点决定了你是在和工具对抗，还是和它协作提效。

现代技术的能力强到难以置信，如果你想了解更多如何充分利用 AI 为个人或企业创造价值的技巧，可以订阅我的免费 AI 周刊：