图像

这篇英文区爆火的Claude Code 101教程，流量直接破了100万。现在把全文完整翻译出来，看看这位资深软件工程师的实战心得。

作者干了7年软件工程师，亚马逊、迪士尼、Capital One都待过，上线的代码服务过几百万用户，也亲手搭过绝对不允许崩溃的关键系统。

现在是一家给企业做Agent的创业公司CTO，而Claude Code，就是他的日常主力工具。

这份手册完全面向新手实战，把他在大厂用Claude构建稳健系统时学到的东西全倒出来了。希望对你有用。

先思考，再动手

大多数人用Claude Code或者其他AI工具时，第一反应就是闷头打字或者直接开口说话。这可能是你犯的第一个、也是最大的错误之一。正确的第一步，其实是动脑子。

每一次——10次里有10次——只要我先用规划模式（Plan Mode）走一遍，最后得到的结果绝对碾压直接上手对Claude Code一顿输出。差距不是一点半点，是肉眼可见的那种。

当然，对有些人来说，说起来容易做起来难。你未必有多年软件工程经验撑腰，能独自把架构想清楚。

两个建议：

开始学习。如果不培养这种思维习惯，哪怕只是一点点，你都是在给自己设限，等于自废武功。

多跟ChatGPT/Gemini/Claude深聊、来回聊。描述你想做什么，问问LLM系统设计上有哪些选项，最后一起确定一个方案。理想状态是：你和LLM互相提问，而不是你单向扔指令。

这个原则适用于所有事，哪怕只是总结邮件这种小任务。

在让Claude写功能之前，先想好架构。在让它重构之前，先想清楚最终状态应该长什么样。在让它调试之前，先问问自己对这个bug到底了解多少。你在规划模式里给的料越多，输出的质量就越高——因为输入的质量摆在那了。

这个模式一向有效：先思考，后打字，比“先打字然后指望Claude自己搞定”强太多。

这也引出了下一个关于架构的观察。在软件工程里，架构有点像只告诉别人“输出什么结果”，却不交代“怎么得出的过程”。

操作空间太大，这正是AI生成代码的麻烦所在。你说“给我做一个认证系统”太宽泛，但如果你说“用现有的User模型做邮箱密码认证，session存Redis里设24小时过期，再给/api/protected下面所有路由加个中间件”——差别一目了然。

按两次Shift+Tab就能进规划模式（Plan Mode）。别嫌麻烦，花5分钟想想，后面能省你数小时的调试时间。

CLAUDE.md：你的秘密武器

CLAUDE.md就是一个Markdown文件。Markdown是AI模型处理起来最顺手的文本格式，Claude尤其擅长。

每次启动Claude Code会话，Claude第一件事就是读你的CLAUDE.md。文件里每一条指令都在悄悄影响它怎么处理你的项目。某种意义上，这就是Claude每次对话前的“入职培训材料”。

大多数人要么完全忽略这个文件，要么往里塞一堆垃圾资讯，结果Claude的表现更差。这里有个阈值：信息太多或太少，都会拖累模型的效果。

真正重要的几点：

保持简短。Claude目前只能可靠地遵循150到200条指令左右，而Claude Code的系统提示已经占掉了大致50条。你每多加一条指令，都是在分散它的注意力。如果CLAUDE.md写成长篇小说，Claude就会开始随机忽略内容，而你根本不知道它忽略了哪些。

针对项目具体化。不用解释“什么是组件文件夹”，Claude知道组件是什么。告诉它那些奇怪但关键的bash命令，凡是属于你工作流的东西都要放进去。

告诉“为什么”，不止是“做什么”。Claude在这一点上有点像人——你给出指令背后的原因，它执行起来比只告诉它“做什么”效果更好。“用TypeScript严格模式”可以，但“用TypeScript严格模式，因为我们之前因为隐式any类型搞出过生产环境Bug”更棒。“为什么”给了Claude上下文，让它能做出你都没预料到的判断。实际用下来你会惊讶效果有多好。

持续更新。工作时按#键，Claude会自动把指令添加到CLAUDE.md里。每次你需要在同一件事上纠正Claude两次，就是提醒你该写进去了。时间久了，CLAUDE.md会成为你代码库实际运作方式的活文档。

糟糕的CLAUDE.md像给新员工写的入职文档。优秀的CLAUDE.md则像你明天就要失忆、今晚写给自己的备忘。

上下文窗口的局限

Opus 4.5有20万个token的上下文窗口。但多数人不知道的是：模型远在上下文使用率达到100%之前，性能就已经开始衰退了——具体取决于你是用API还是桌面应用。

大约在上下文使用率冲到20%到40%时，输出质量就开始受损，哪怕还没到严重的地步。如果你遇到过Claude Code执行压缩（compacting）后仍然给出糟糕输出的情况，原因就在这儿。模型在压缩发生之前就已经退化了，压缩并不能神奇地恢复质量。注意：输入/compact可以手动压缩。

你每发一条消息、Claude读取的每个文件、它生成的每段代码、每个工具结果——全都在累积。一旦质量开始下滑，继续添加上下文只会让情况更糟，而不是更好。

几个真正管用的招数：

限定对话范围。每个功能或任务用一个独立对话。别用同一个对话先搭认证系统，回头又用它重构数据库层。上下文会混在一起，Claude就糊涂了。我猜读完这段，你们中间至少有一个人心里在发虚。

使用外部记忆。如果处理的事情很复杂，让Claude把计划和进度写进实际的文件里——我习惯用SCRATCHPAD.md或者plan.md。这些文件跨会话保持，第二天回来时，Claude能读文件并从你停下的地方继续，而不是每次从零开始。如果你有文件层级系统，把这些文件放在最顶层，这样你敲定的每个任务或功能都能用得上。

复制粘贴重置法。这是我很喜欢的一个技巧。上下文变得臃肿时，把终端里所有重要内容都复制出来，运行/compact拿到摘要，然后/clear彻底清空上下文，只把关键信息粘贴回去。一个保留关键信息的新上下文，远胜于让Claude在退化的上下文里挣扎。

知道何时清空。如果对话已经跑偏或堆了一堆不相关的上下文，直接/clear重新开一盘。这比试着在混乱中硬干要好得多。Claude依然保留你的CLAUDE.md，所以项目背景不会丢。十次里有九次，用clear的效果反而比不用更好——虽然听起来有点反直觉。

一个有效的思维模型：把Claude看作无状态的（Stateless）。每次对话都是从零开始，唯独你明确塞给它的东西除外。按这个思路去规划。

提示词决定一切

人们花大把时间学框架、学工具，却从来不肯花时间学学怎么跟自己实际用来生成代码的东西好好沟通。

提示工程不是什么玄学。它是最基本的沟通形式。跟任何沟通一样，清晰永远比含糊带来更好的结果。次次如此。

真正有用的做法：

明确你想要的。“构建一个认证系统”给了Claude糟糕的创作自由。“用现有User模型做邮箱密码认证，session存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服务器、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在复杂任务上挣扎，那本身就意味着你的规划模式（plan mode）做得不够好。

展示而非讲述。如果Claude一直误解你的意思，你自己写一个最小示例。“输出应该长这样。现在把这个模式应用到剩下的部分。” Claude非常擅长理解“成功指标”长什么样，也能很好地跟着好的示例走。

要有创意。试试换个角度。有时候你构建问题的方式，正好跟Claude的思维方式对不上。重新解构——“把它作为一个状态机实现”对比“处理这些转换”——可能就打开了新局面。

这里真正的元技能是：尽早识别出自己已经陷入死循环。如果你已经把同一件事解释了三遍，Claude还是不懂，再来更多解释也不会有什么用。换点别的东西试试。

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

那些从Claude身上获得最大价值的人，绝不仅仅是拿它做一次性任务。他们在构建系统，而Claude只是系统中的一个组件。但Claude Code远不止于此。它有一个-p标志用于无头模式（headless mode）——直接运行你的提示词并输出结果，不需要进入交互界面。这意味着你可以把它脚本化，把结果通过管道传输给其他工具，跟bash命令串联，集成到自动化工作流里。

企业正在用这个能力做自动PR审查、自动支持工单回复、自动日志记录和文档更新。所有操作都被记录下来，可以审计，而且随着时间推移，还能根据什么有效、什么无效不断改进。

这是一个飞轮效应：Claude犯了个错，你查看日志，改进CLAUDE.md或工具，Claude下次就做得更好。这就是复利增长。我现在正在让Claude自己改进它自己的CLAUDE.md文件。经过几个月的迭代，以这种方式构建的系统在推出时已经比最初版本好得多了——同样的模型，只不过配置更好了。

如果你只在交互模式下用Claude，那就是把价值留在桌子上没拿。想一下你的工作流里，哪些地方可以让Claude在不盯着它的时候自己去跑。

太长不看版

先思考再打字。规划出来的结果远好于直接开口就说。

CLAUDE.md是你的杠杆点。保持简短、具体，告诉它“为什么”，并且持续更新。这一个文件影响每一次交互。

上下文在30%时就退化了，不是100%。用外部记忆，限定对话范围，别怕“复制粘贴重置”技巧——清空然后重启。

架构比什么都重要。你不能跳过规划这一步。不先把结构想清楚，输出肯定烂。

输出源于输入。用好模型却拿坏结果，那就说明你的提示词需要升级。提升自己的沟通能力。

尝试工具和配置。MCP、Hooks、斜杠命令。既然付了Pro Max的钱，就把所有功能都试一遍。即使第一次不行，也要保持好奇心。

卡住时，改变方法。别在死循环里耗着。清空、简化、展示示例、重新构建问题。

构建系统，而不是一次性任务。无头模式、自动化、随时间推移的日志改进——这些才是放大价值的核心。

如果你正用Claude搭东西，不管是你自己的项目还是生产系统——上面这些就是决定你是跟工具对抗，还是顺势而为的关键。