Claude Code：7年大厂工程师的经验总结

本文是一位拥有 7 年大厂经验（Amazon、Disney、Capital One）的工程师分享的 Claude Code 完全教程，涵盖从思维方式到高级技巧的全方位指南。

关于作者

作者曾在 Amazon、Disney 和 Capital One 担任软件工程师 7 年，负责的代码服务于数百万用户，构建的系统要求高可用性。目前是一家为企业构建 Agent 的初创公司 CTO，Claude Code 是他的日常工作工具。

先思考，再输入

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

10 次中有 10 次，使用计划模式（Plan Mode）得到的输出比直接开始说话好得多。差距不是一点点。

对于经验不足的开发者

如果你没有多年的软件工程经验，这里有两个建议：

开始学习。即使是一点一点地学，不学习会限制你的能力。
与 ChatGPT/Gemini/Claude 深入交流。描述你想要构建的内容，询问 LLM 关于系统设计的各种选项，最终达成解决方案。你与 LLM 应该互相提问，而不是单方面的对话。

这适用于一切任务，包括像总结邮件这样的小任务。在让 Claude 构建功能之前，先考虑架构。在让它重构之前，先考虑最终状态应该是什么样子。在让它调试之前，先考虑你对问题的了解程度。计划模式中的信息越多，输出就越好。

模式是一致的：先思考，再输入，产生的结果比先输入再希望 Claude 搞定要好得多。

架构的重要性

软件工程中的架构就像给一个人输出结果而不给其他信息。这给如何达到输出留下了很大的回旋余地，这本质上就是 AI 生成代码的问题。

不好的提示：「给我构建一个认证系统」

好的提示：「使用现有的 User 模型构建邮箱/密码认证，将会话存储在 Redis 中并设置 24 小时过期，添加保护 /api/protected 下所有路由的中间件。」

按两次 Shift + Tab，你就进入了计划模式。相信我，这会花费你 5 分钟，但会为你节省数小时的调试时间。

CLAUDE.md 文件

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

大多数人要么完全忽略它，要么塞满垃圾信息使其变得更糟。信息太多或太少都会导致模型输出变差。

CLAUDE.md 的关键要点

保持简短。Claude 每次只能可靠地遵循约 150-200 条指令，而 Claude Code 的系统提示已经使用了约 50 条。你添加的每条指令都在竞争注意力。
针对你的项目具体化。不要解释什么是 components 文件夹。Claude 知道组件是什么。告诉它那些奇怪的东西，比如真正重要的 bash 命令。
告诉它为什么，而不只是做什么。「使用 TypeScript 严格模式」还可以。「使用 TypeScript 严格模式，因为我们曾因隐式 any 类型导致生产 bug」更好。为什么给 Claude 做出你没预料到的判断提供了上下文。
不断更新。工作时按 # 键，Claude 会自动向你的 CLAUDE.md 添加指令。每次你发现自己就同一件事纠正 Claude 两次，那就是应该写入文件的信号。

糟糕的 CLAUDE.md 看起来像是写给新员工的文档。好的 CLAUDE.md 看起来像是留给明天会失忆的自己的笔记。

上下文窗口的限制

Opus 4.5 有 200,000 token 的上下文窗口。但大多数人不明白的是：模型在达到 100% 之前就开始恶化了。

在大约 20-40% 的上下文使用量时，输出质量就开始下降。如果你曾经历过 Claude Code 压缩后仍然给你糟糕的输出，那就是原因。模型在压缩发生之前就已经降级了，压缩不会神奇地恢复质量。

管理上下文的技巧

限定对话范围。每个功能或任务一个对话。不要用同一个对话构建认证系统然后又重构数据库层。上下文会混淆在一起，Claude 会困惑。
使用外部记忆。如果你在处理复杂的事情，让 Claude 将计划和进度写入实际文件（如 SCRATCHPAD.md 或 plan.md）。这些跨会话持久化。
复制粘贴重置。当上下文膨胀时，从终端复制所有重要内容，运行 /compact 获取摘要，然后 /clear 完全清除上下文，只粘贴回重要的内容。
知道何时清除。如果对话已经偏离轨道或积累了大量无关上下文，直接 /clear 重新开始。Claude 仍然有你的 CLAUDE.md，所以你不会丢失项目上下文。

有效的思维模型：Claude 是无状态的。每次对话除了你明确给它的内容外，都是从零开始的。

提示词就是一切

人们花数周学习框架和工具，却花零时间学习如何与实际生成代码的东西交流。

有效的提示技巧

具体说明你想要的。「构建认证系统」给 Claude 创造性自由，它会用得很糟糕。「使用现有 User 模型构建邮箱/密码认证，将会话存储在 Redis，添加保护 /api/protected 路由的中间件」给 Claude 一个明确的目标。
告诉它不要做什么。Claude 有倾向性。Claude 4.5 特别喜欢过度工程，额外的文件、不必要的抽象、你没要求的灵活性。如果你想要简约，说「保持简单。不要添加我没要求的抽象。如果可能一个文件搞定。」
给它关于为什么的上下文。「我们需要这个快，因为它在每个请求上运行」改变了 Claude 处理问题的方式。「这是一个我们会扔掉的原型」改变了什么权衡是合理的。

记住：输出就是一切，但它只来自输入。如果你的输出很糟糕，说明你的输入很糟糕。没有捷径。

糟糕的输入 = 糟糕的输出

人们得到糟糕结果时责怪模型。「Claude 不够聪明」或「我需要更好的模型」。

现实检验：如果你用 Opus 4.5 这样的好模型得到糟糕的输出，意味着你的输入和提示很糟糕。句号。

模型很重要。但模型质量现在已经是基本要求了。瓶颈几乎总是在人这边：你如何构建提示，如何提供上下文，如何清晰地沟通你真正想要的。

模型差异

Sonnet 更快更便宜。非常适合执行任务，路径清晰，写样板代码、根据具体计划重构、实现你已经做出架构决策的功能。
Opus 更慢更贵。更适合复杂推理、规划和需要 Claude 深思权衡的任务。

有效的工作流：用 Opus 规划和做架构决策，然后切换到 Sonnet（Claude Code 中 Shift+Tab）进行实现。

MCP、工具和配置

Claude 有大量功能。MCP 服务器、Hooks、自定义斜杠命令、Settings.json 配置、Skills、插件。

你不需要全部。但你应该尝试和实验，因为如果你不实验，你可能正在浪费时间或金钱。

MCP（模型上下文协议） 让 Claude 连接到外部服务。Slack、GitHub、数据库、API。如果你发现自己不断从一个地方复制信息到 Claude，可能有 MCP 服务器可以自动完成。
Hooks 让你在 Claude 做更改之前或之后自动运行代码。想让 Prettier 在 Claude 触碰的每个文件上运行？Hook。想在每次编辑后进行类型检查？Hook。
自定义斜杠命令 只是你重复使用的提示，打包成命令。创建 .claude/commands 文件夹，添加带有提示的 markdown 文件，现在你可以用 /commandname 运行它们。

当 Claude 陷入困境时

有时 Claude 会循环。它尝试同样的东西，失败，再试，失败，继续。或者它自信地实现完全错误的东西，你花二十分钟解释为什么。

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

清除对话。积累的上下文可能会让它困惑。/clear 给你一个新的开始。
简化任务。如果 Claude 在复杂任务上挣扎，把它分成更小的部分。
展示而不是告诉。如果 Claude 一直误解你想要的，自己写一个最小示例。「这是输出应该的样子。现在把这个模式应用到其余部分。」
要有创意。尝试不同的角度。有时你构建问题的方式不能很好地映射到 Claude 的思维方式。重新构建，「把这个实现为状态机」vs「处理这些转换」，可以解锁进展。

元技能是尽早识别你何时处于循环中。如果你解释了同样的事情三次而 Claude 仍然不明白，更多解释没有帮助。改变一些东西。

构建系统

从 Claude 获得最大价值的人不是用它做一次性任务。他们正在构建系统，其中 Claude 是一个组件。

Claude Code 有一个 -p 标志用于无头模式。它运行你的提示并输出结果而不进入交互界面。这意味着你可以脚本化它。将输出管道到其他工具。与 bash 命令链接。集成到自动化工作流中。

企业正在使用这个进行自动 PR 审查、自动支持工单响应、自动日志和文档更新。所有这些都有日志记录、可审计，并基于什么有效什么无效随时间改进。

飞轮效应：Claude 犯错误，你查看日志，你改进 CLAUDE.md 或工具，Claude 下次会更好。这会复合。

TLDR 总结

输入前先思考。规划产生的结果比直接开始说话好得多。
CLAUDE.md 是你的杠杆点。保持简短、具体，告诉它为什么，不断更新。这个单一文件影响每次交互。
上下文在 30% 时降级，不是 100%。使用外部记忆，限定对话范围，不要害怕清除并用复制粘贴重置技巧重新开始。
架构比任何东西都重要。你不能跳过规划。如果你不先考虑结构，输出就会很糟糕。
输出来自输入。如果你用好模型得到糟糕的结果，你的提示需要改进。学会更好地沟通。
实验工具和配置。MCP、hooks、斜杠命令。如果你付了 Pro Max，尝试一切。即使第一次没成功也要保持好奇。
当陷入困境时，改变方法。不要循环。清除、简化、展示、重新构建。
构建系统，不是一次性任务。无头模式、自动化、随时间记录改进。

如果你用 Claude 构建，无论是自己的项目还是生产系统，这些是决定你是在与工具对抗还是与工具协同的因素。

原文链接：https://x.com/eyad_khrais/status/1876727398916903151
作者：Eyad (@eyad_khrais)，Varick AI CTO
发布日期：2026年1月11日