转载x上文章
Claude 完整代码教程
我做了 7 年软件工程师，先后在亚马逊、迪士尼和 Capital One 工作过。我发布的代码服务了数百万用户，我构建的系统不容有失。现在我是一家为企业构建智能体的初创公司的 CTO，Claude Code 是我的日常工具。
这里有一份新手指南，你可能会觉得有用，包含了我在使用 Claude 构建处理大公司复杂工作负载的稳健系统后学到的一切。如果对你有帮助，请在下方告诉我。
先思考
大多数人认为使用 Claude Code 和其他 AI 工具时，首先要做的就是打字（或开始说话）。但这可能是你一开始就会犯的最大错误之一。你真正需要做的第一件事是思考。
十次中有十次，我使用计划模式得到的输出明显优于我直接开始说话并把所有内容倾倒给 Claude Code 的结果。差距甚至不是一点点。
对你们中的一些人来说，这说起来容易做起来难。你可能没有多年的软件工程经验来让你独立思考这些问题。对此我有两条建议： 1. 开始学习。如果你从不掌握这一点，你就是在限制自己，哪怕只是一点一点地学。
与 ChatGPT/Gemini/Claude 进行深入的来回对话，详细描述你想要构建的内容，询问 LLM 在系统设计方面可以采取的各种选项，最终你们两个共同确定一个解决方案。你和 LLM 应该互相提问，而不是单向交流。
这适用于所有事情。这也包括像总结邮件这样的小任务。在你要求 Claude 构建功能之前，先思考架构。在你要求它重构某些内容之前，先思考最终状态应该是什么样子。在你要求它调试之前，先思考你对问题的实际了解。你在计划模式下掌握的信息越多，你的输出就会越好，因为输入也会越好。
这个模式是一致的：先思考，再输入，比先输入然后希望 Claude 能搞清楚，会产生显著更好的结果。
这让我想到下一个要点：架构。架构，尤其是在软件工程中，有点像只给一个人输出结果，别的什么都不给。这在如何达到输出结果方面留下了很大的回旋余地，这本质上就是 AI 生成代码的问题所在。如果你说一些非常宽泛的话，比如
"给我构建一个认证系统"，
而不是
"使用现有的 User 模型构建邮箱/密码认证，将会话存储在 Redis 中并设置 24 小时过期时间，并添加中间件来保护 /api/protected 下的所有路由。"，
你就能看出区别。
你按两次 shift + tab，就进入了计划模式。相信我，这会占用你 5 分钟时间，但会为你节省数小时的后续调试时间。
CLAUDE.md
大多数人要么完全忽略它，要么塞满垃圾内容，反而让 Claude 变得更糟而不是更好。存在一个阈值，信息过多或过少都会导致模型输出质量下降。
以下是真正重要的内容：
让它针对你的项目。不要解释什么是组件文件夹。Claude 知道什么是组件。告诉它那些奇怪的东西，比如真正重要的 bash 命令。所有属于你工作流程的内容都应该写进去。
告诉它为什么，而不仅仅是做什么。Claude 在这方面有点像人类。当你给出指令背后的原因时，Claude 的实现效果会比你只告诉它做什么要好。
"使用 TypeScript 严格模式"还可以。
"使用 TypeScript 严格模式，因为我们曾因隐式 any 类型导致生产环境 bug"更好。
"为什么"为 Claude 提供了上下文，让它能够做出你未曾预料的判断。你会惊讶于这实际上有多有效。
CLAUDE.md会成为一份记录代码库实际运作方式的活文档。看起来像是你在知道自己明天会失忆的情况下给自己留的笔记。
上下文窗口的局限性
例如 拥有 200,000 token 的上下文窗口。但大多数人没有意识到的是：模型在达到 100% 之前就会开始退化。（这取决于你是通过 API 还是桌面应用使用）
在上下文使用率达到 20-40% 左右时，输出质量就会开始下降，即使下降幅度不大。
如果你曾经遇到过 Claude Code 压缩后仍然给出糟糕输出的情况，这就是原因。模型在压缩发生之前就已经退化了，压缩并不能神奇地恢复质量。（输入 /compact 进行压缩）
你发送的每条消息、Claude 读取的每个文件、它生成的每段代码、每个工具结果------所有这些都会累积。一旦质量开始下降，更多的上下文会让情况变得更糟，而不是更好。所以这里有一些真正有助于避免糟糕上下文的方法
限定对话范围。一个对话只处理一个功能或任务。
不要在同一个对话中既构建身份验证系统又重构数据库层。上下文会混在一起，Claude 会搞混。我知道正在读这段话的人里至少有一个犯过这个错。
这些文件会跨会话保留。当你明天回来时，Claude 可以读取文件并从上次中断的地方继续，而不是从零开始。附注：如果你有文件的层级系统，把这些文件放在最顶层可以让它们适用于你决定构建的每个任务/功能。
复制粘贴重置法。
这是我经常用的技巧。当上下文变得臃肿时，我从终端复制所有重要内容，运行 /compact 获取摘要，然后用 /clear 完全清空上下文，再只粘贴回重要的内容。清爽的上下文，关键信息得以保留。比让 Claude 在退化的上下文中挣扎要好得多。
有效的思维模型：Claude 是无状态的。每个对话都从零开始，除了你明确提供的内容。据此做好规划。
提示词就是一切
人们花费数周学习框架和工具，却花零时间学习如何与真正生成代码的东西沟通。
提示词不是什么神秘的艺术。它可能是最基本的沟通形式。就像任何沟通一样，清晰表达总能比含糊其辞获得更好的结果。每一次都是如此。
真正有用的做法：
明确你想要什么。"构建一个认证系统"给了 Claude 它会用得很糟的创作自由。"使用现有的 User 模型构建邮箱/密码认证，将会话存储在 Redis 中，并添加中间件保护 /api/protected 下的路由"给了 Claude 一个清晰的目标。即便如此仍不完美。
告诉它不要做什么。Claude 有自己的倾向。Claude 4.5 尤其喜欢过度设计------额外的文件、不必要的抽象、你没要求的灵活性。如果你想要简单的东西，就说"保持简单。不要添加我没要求的抽象。如果可能的话用一个文件。"另外，始终交叉检查 Claude 生成的内容，因为你不想最终背上技术债务，特别是当你在构建超级简单的东西时，它却为一个实际上只需几行代码就能解决的任务构建了 12 个不同的文件。
你必须记住的是，
AI 的设计目的是加速我们的工作，而不是完全取代我们，
尤其是在非常专业的软件工程时代。Claude 仍然会犯错。我确信它会继续犯错，即使随着时间推移会变得更好。所以能够识别这些错误实际上会解决你的很多问题。
给它关于原因的上下文。"我们需要这个快速运行，因为它在每个请求上都会执行"会改变 Claude 处理问题的方式。"这是一个我们会丢弃的原型"会改变哪些权衡是合理的。Claude 无法读懂你对未提及约束条件的想法。
记住：输出就是一切，但它只来自输入。如果你的输出很糟糕，那是因为你的输入很糟糕。这一点无法回避。
错误的输入 == 错误的输出
人们在得到糟糕结果时会责怪模型 不够聪明"或"我需要一个更好的模型。"
现实检验：问题出在你身上。如果你在使用像 Opus 4.5 这样的优秀模型时得到糟糕的输出，那意味着你的输入和提示词很糟糕。就是这样。
模型确实重要。实际上非常重要。但模型质量在这个阶段已经是基本要求了。瓶颈几乎总是在人的这一端：你如何构建提示词，如何提供上下文，如何清晰地表达你真正想要什么。
如果你持续得到糟糕的结果，解决方法不是换模型。解决方法是提升以下能力：
如何编写提示词:
具体 > 模糊。约束 > 开放式。示例 > 描述。
如何构建请求。将复杂任务分解为步骤。在实施前就架构达成一致。审查输出并迭代。
你如何提供上下文。Claude 需要知道什么才能做好这件事？你做了哪些 Claude 看不到的假设？
话虽如此，模型之间确实存在真正的差异：
更快更便宜。它非常适合执行路径明确的任务------编写样板代码、基于特定计划进行重构、实现你已经做出架构决策的功能。
更慢更贵。它更擅长复杂推理、规划，以及需要 Claude 深入思考权衡的任务。
MCP、工具和配置
有数量惊人的功能。MCP 服务器。钩子。自定义斜杠命令。Settings.json 配置。技能。插件。
你不需要全部使用。但你应该真正尝试和实验它们，因为如果你不实验，你可能会浪费时间或金钱。我向你保证，Claude 至少有一个你不知道的新功能即将推出，如果你关注 Claude Code 的创始人 Boris，你就能了解到。
模型上下文协议）让 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.md文件,经过数月的迭代，以这种方式构建的系统比发布时明显更好------模型相同，只是配置更优。
如果你只是交互式地使用 Claude，就错失了价值。想想在你的工作流程中，哪些地方 Claude 可以在无人监督的情况下运行。
太长不看
先思考再输入。规划能产生比直接开始对话好得多的结果。
架构比任何事情都重要。你不能跳过规划。如果不先考虑清楚结构，输出就会很糟糕。
输出来自输入。如果你用一个好模型却得到糟糕的结果，说明你的提示词需要改进。提升沟通能力。
尝试各种工具和配置。MCP、钩子、斜杠命令。如果你付费使用 Pro Max，就把所有功能都试一遍。即使第一次不成功也要保持好奇心。
遇到困难时，换个方法。不要陷入循环。清晰化、简化、展示、重新构思。
构建系统，而非一次性方案。无头模式、自动化、记录长期改进。
如果你在使用 Claude 进行开发------无论是个人项目还是生产系统------这些因素决定了你是在与工具对抗还是顺畅协作。