# The complete claude code tutorial 克劳德代码完整教程
**作者**: Eyad
**日期**: 2026-01-10T19:51:06.000Z
**来源**: [https://x.com/eyad_khrais/status/2010076957938188661](https://x.com/eyad_khrais/status/2010076957938188661)
---
I’ve been a SWE for 7 years, between Amazon, Disney, and Capital One. The code I’ve shipped touches millions of users, and I built systems that couldn’t afford to break. Now I’m the CTO of a startup that builds agents for enterprise, and Claude Code is my daily driver.我从事软件工程师工作已有 7 年，先后就职于亚马逊、迪士尼和 Capital One。我编写的代码影响着数百万用户，我构建的系统容不得半点差错。现在，我是一家为企业开发代理的初创公司的首席技术官，Claude Code 是我日常使用的工具。
Here’s a beginners playbook you might find useful, containing everything I’ve learned about Claude after using it to build robust systems that handle complex workloads from large companies. Let me know if it helps below.这里有一份入门指南，或许对你有所帮助。其中包含了我使用 Claude 构建能够处理大型企业复杂工作负载的稳健系统后总结出的所有经验。如果你觉得有用，请在下方留言告诉我。
## Think First先思考
Most people assume that with Claude Code and other AI tools, the first thing you need to do is type (or start talking). But that's probably one of the biggest mistakes that you can make straight off the bat. The first thing that you actually need to do is think.大多数人认为，使用 Claude Code 和其他人工智能工具时，首先要做的是输入文字（或开始说话）。但这可能是你一开始就会犯的最大错误之一。你真正需要做的第一件事是思考。
10 out of 10 times, the output I've gotten with plan mode did significantly better than when I just started talking and spewing everything into Claude Code. It's not even close.十次有十次，使用规划模式得到的输出结果都比我直接对着 Claude Code 胡乱输入要好得多。差距非常明显。
Now for some of you, this is easier said than done. You might not have years of software engineering experience that would allow you to think about this on your own. To this extent I have two pieces of advice:
1. Start learning. You are handicapping yourself if you never pick up on this, even if just a little bit at a time.对你们中的一些人来说，这说起来容易做起来难。你们可能没有多年的软件工程经验，无法独立思考这个问题。对此，我有两点建议：
1. 开始学习。如果你一直不学习，哪怕每次只学一点点，你都会给自己设限。
2. Have a deep back and forth with ChatGPT/Gemini/Claude, where you describe exactly what you want to build, you ask the LLM for the various options you can take in terms of system design, and ultimately the two of you settle on a solution. You and the LLM should be asking each other questions, not just a one way street. .2. 与 ChatGPT/Gemini/Claude 进行深入的交流，详细描述你想要构建的内容，向 LLM 咨询系统设计方面的各种方案，最终你们双方共同确定解决方案。你和 LLM 应该互相提问，而不是单向交流。
This applies to everything. This also includes very small tasks like summarizing emails. Before you ask Claude to build a feature, think about the architecture. Before you ask it to refactor something, think about what the end state should look like. Before you ask it to debug, think about what you actually know about the problem. The more information that you have in plan mode, the better your output is actually going to be because the better the input is going to be.这适用于所有事情，包括像摘要邮件这样的小任务。在让 Claude 构建某个功能之前，先考虑一下架构；在让它重构某些内容之前，先想想最终状态应该是什么样子；在让它调试之前，先想想你对问题究竟了解多少。计划阶段掌握的信息越多，输出结果就越好，因为输入信息也会越好。
The pattern is consistent: thinking first, then typing, produces dramatically better results than typing first and hoping Claude figures it out.规律是：先思考后打字，比先打字再指望克劳德能明白要好得多。
This brings me onto my next point of architecture. Architecture, especially in software engineering, is a little bit like giving a person the output and nothing more. This leaves for A LOT of wiggle room in how to get to the output, which is essentially what the problem with AI generated code is. If you say something super broad like “build me an auth system” as opposed to “Build email/password authentication using the existing User model, store sessions in Redis with 24-hour expiry, and add middleware that protects all routes under /api/protected.”, you can see the difference.这就引出了我关于架构的下一个观点。架构，尤其是在软件工程领域，有点像直接给出最终结果，不多也不少。这就给如何实现最终结果留下了很大的回旋余地，而这正是人工智能生成代码的根本问题所在。如果你说的是一个非常宽泛的指令，比如“帮我构建一个身份验证系统”，而不是“使用现有的用户模型构建邮箱/密码身份验证，将会话存储在 Redis 中，并设置 24 小时过期时间，然后添加中间件来保护 /api/protected 下的所有路由”，你就能看出其中的区别了。
You click shift + tab twice, and you’re in plan mode. Trust me when I say this, this is going to take 5 minutes of your time, but will save you hours upon hours of debugging later on.按两次 Shift + Tab 键，即可进入计划模式。相信我，这只需要你五分钟的时间，但能为你节省之后数小时的调试时间。
## CLAUDE.md
CLAUDE.md is a markdown file. Markdown is a text format that AI models process extremely well, and Claude in particular handles it better than most other models I've tested.CLAUDE.md 这是一个 Markdown 文件。Markdown 是一种文本格式，人工智能模型能够很好地处理它，尤其是 Claude，它比我测试过的大多数其他模型处理得更好。
When you start a Claude Code session, the first thing Claude does is read your CLAUDE.md file. Every instruction in that file shapes how Claude approaches your project. It's essentially onboarding material that Claude reads before every single conversation.当你启动 Claude Code 会话时，Claude 首先会读取你的代码。CLAUDE.md 该文件中的每一条指令都决定了克劳德处理项目的方式。它本质上是克劳德在每次对话前都会阅读的新用户培训资料。
Most people either ignore it completely or stuff it with garbage that makes Claude worse instead of better. There is a threshold where too much or too little information means worse model output.大多数人要么完全忽略它，要么往里面塞满垃圾信息，结果反而让克劳德的情况更糟。信息过多或过少都会导致模型输出变差，存在一个临界点。
Here's what actually matters:真正重要的是：
Keep it short. Claude can only reliably follow around 150 to 200 instructions at a time, and Claude Code's system prompt already uses about 50 of those. Every instruction you add competes for attention. If your CLAUDE.md is a novel, Claude will start ignoring things randomly and you won't know which things.尽量简洁。Claude 一次只能可靠地执行大约 150 到 200 条指令，而 Claude Code 的系统提示符已经占用了大约 50 条。你添加的每条指令都会争夺 Claude 的注意力。如果你的 CLAUDE.md 如果这是一部小说，克劳德会开始随机地忽略一些事情，而你不会知道他忽略的是哪些事情。
Make it specific to your project. Don't explain what a components folder is. Claude knows what components are. Tell it the weird stuff, like the bash commands that actually matter. Everything that is part of your flow should go into it.让它与你的项目紧密相关。不要解释什么是组件文件夹，Claude 知道组件是什么。告诉它一些真正重要的细节，比如那些看似无关紧要的 bash 命令。你工作流程中的所有内容都应该放进去。
Tell it why, not just what. Claude is a little bit like a human in this way. When you give it the reason behind an instruction, Claude implements it better than if you just tell it what to do. "Use TypeScript strict mode" is okay. "Use TypeScript strict mode because we've had production bugs from implicit any types" is better. The why gives Claude context for making judgment calls you didn't anticipate. You'll be surprised how effective this actually is.告诉它为什么，而不仅仅是做什么。Claude 在这方面有点像人。当你解释指令背后的原因时，Claude 的执行效果会比你只告诉它做什么更好。“使用 TypeScript 严格模式”是可以的，但“使用 TypeScript 严格模式是因为我们遇到过隐式 any 类型导致的生产环境 bug”更好。解释原因能让 Claude 做出你意想不到的判断。你会惊讶于这种方法的效果。
Update it constantly. Press the # key while you're working and Claude will add instructions to your CLAUDE.md automatically. Every time you find yourself correcting Claude on the same thing twice, that's a signal it should be in the file. Over time your CLAUDE.md becomes a living document of how your codebase actually works.不断更新。工作时按#键，克劳德就会添加说明。CLAUDE.md 自动完成。每次你发现自己两次纠正克劳德同一个错误时，就说明应该把这个错误记录到文件中。随着时间的推移，你的 CLAUDE.md 它会成为一份鲜活的文档，记录你的代码库实际的运行方式。
Bad CLAUDE.md looks like documentation written for a new hire. Good CLAUDE.md looks like notes you'd leave yourself if you knew you'd have amnesia tomorrow.坏的 CLAUDE.md 看起来像是为新员工编写的入职资料。不错。CLAUDE.md 看起来像是你知道自己明天会失忆时会留给自己的字条。
## The Limitations of Context Windows上下文窗口的局限性
For example, Opus 4.5 has a 200,000 token context window. But here's what most people don't realize: the model starts to deteriorate way before you hit 100%. (this is varying dependent on whether you use through API vs desktop app)例如，Opus 4.5 的 token 上下文窗口大小为 20 万。但大多数人没有意识到的是：在达到 100% 之前，模型的性能就开始下降了。（这取决于您是通过 API 使用还是通过桌面应用程序使用）
At around 20-40% context usage is where the quality of the output starts to chip away, even if not significantly. If you've ever experienced Claude Code compacting and then still giving you terrible output afterwards, that's why. The model was already degraded before the compaction happened, and compaction doesn't magically restore quality. (hit /compact for compacting)当上下文使用率达到 20-40% 左右时，输出质量就开始下降，即使下降幅度不大。如果你曾经遇到过 Claude Code 压缩后输出仍然很差的情况，原因就在这里。模型在压缩之前就已经劣化了，而压缩并不能神奇地恢复质量。（使用 /compact 命令进行压缩）
Every message you send, every file Claude reads, every piece of code it generates, every tool result - all of it accumulates. And once quality starts dropping, more context makes it worse, not better. So here are some things that actually help with not having terrible context你发送的每条消息、Claude 读取的每一个文件、它生成的每一段代码、每一个工具的运行结果——所有这些都会累积。一旦质量开始下降，更多的上下文信息只会让情况更糟，而不是更好。所以，以下是一些有助于避免糟糕上下文信息的方法。
Scope your conversations. One conversation per feature or task. Don't use the same conversation to build your auth system and then also refactor your database layer. The contexts will bleed together and Claude will get confused. I know at least one of you reading this is guilty of that.明确对话的范围。每个功能或任务只进行一次对话。不要用同一个对话来构建身份验证系统，然后再重构数据库层。上下文会混淆，Claude 会感到困惑。我知道你们当中至少有一位犯过这种错误。
Use external memory. If you're working on something complex, have Claude write plans and progress to actual files (I use SCRATCHPAD.md or plan.md). These persist across sessions. When you come back tomorrow, Claude can read the file and pick up where you left off instead of starting from zero. Sidenote: if you have a hierarchy system of files, keeping these at thievery top is how you can get these to work for every task / feature that you decide to build out.使用外部存储器。如果你在处理一些复杂的项目，让克劳德把计划和进度记录到实际文件中（我用草稿本.md 或者计划.md 这些信息会在会话之间保留。明天你回来时，Claude 可以读取该文件并从你上次中断的地方继续，而无需从头开始。附注：如果你有一个文件层级系统，将这些文件放在最顶层，就能确保它们适用于你计划构建的每个任务/功能。
The copy-paste reset. This is a trick I use constantly. When context gets bloated, I copy everything important from the terminal, run /compact to get a summary, then /clear the context entirely, and paste back in only what matters. Fresh context with the critical information preserved. Way better than letting Claude struggle through degraded context.复制粘贴重置。这是我经常用的一个技巧。当上下文信息过多时，我会从终端复制所有重要内容，运行 `/compact` 命令获取摘要，然后彻底清除上下文，最后只粘贴关键信息。这样就能得到一个全新的上下文，关键信息也得以保留。这比让 Claude 费力地在混乱的上下文中摸索要好得多。
Know when to clear. If a conversation has gone off the rails or accumulated a bunch of irrelevant context, just /clear and start fresh. It's better than trying to work through confusion. Claude will still have your CLAUDE.md, so you're not losing your project context. Nine times out of ten, using clear is actually better than not using it, as counterintuitive as that sounds.要懂得何时清场。如果对话偏离主题或积累了太多无关信息，直接使用 /clear 命令清场，重新开始。这比试图理清混乱的对话要好得多。克劳德仍然会记得你。CLAUDE.md 这样就不会丢失项目上下文。十有八九，使用 clear 实际上比不使用更好，尽管这听起来可能有点违反直觉。
The mental model that works: Claude is stateless. Every conversation starts from nothing except what you explicitly give it. Plan accordingly.行之有效的思维模型：克劳德是无状态的。每一次对话都始于虚无，除非你明确地赋予它某种信息。据此做好计划。
## Prompts Are Everything提示至关重要
People spend weeks learning frameworks and tools. They spend zero time learning how to communicate with the thing that's actually generating their code.人们花费数周时间学习框架和工具，却从未花时间学习如何与实际生成代码的系统进行通信。
Prompting isn't some mystical art. It’s probably the most fundamental form of communication there is. And like any communication, being clear gets you better results than being vague. Every. Single. Time.提示并非什么神秘的艺术。它或许是最基本的沟通方式。而且，就像任何沟通一样，清晰的表达比含糊不清的效果要好得多。每一次都是如此。
What actually helps:真正有帮助的是：
Be specific about what you want. "Build an auth system" gives Claude creative freedom it will use poorly. "Build email/password authentication using this existing User model, store sessions in Redis, and add middleware that protects routes under /api/protected" gives Claude a clear target. Even this is still not perfect.明确你的需求。“构建一个身份验证系统”给了克劳德很大的创作自由，但他可能无法充分利用。“使用现有的用户模型构建邮箱/密码身份验证，将会话存储在 Redis 中，并添加中间件来保护 /api/protected 下的路由”则为克劳德提供了一个清晰的目标。即便如此，这仍然不够完美。
Tell it what NOT to do. Claude has tendencies. Claude 4.5 in particular likes to overengineer - extra files, unnecessary abstractions, flexibility you didn't ask for. If you want something minimal, say "Keep this simple. Don't add abstractions I didn't ask for. One file if possible." Also, always cross-reference what Claude produces because you don't want to end up having technical debt, especially if you're building something super simple and it ends up building 12 different files for a task that realistically could have been fixed with a couple of lines of code.告诉它哪些事情不该做。Claude 有一些习惯。特别是 Claude 4.5，它喜欢过度设计——生成额外的文件、不必要的抽象层，以及你根本没要求的灵活性。如果你想要一个极简的东西，就告诉它：“保持简单。不要添加我没要求的抽象层。如果可能的话，最好只用一个文件。” 此外，务必交叉检查 Claude 生成的代码，因为你肯定不想背负技术债务，尤其是在你构建一个非常简单的东西时，它却为了一个实际上只需几行代码就能完成的任务生成了 12 个不同的文件。
Something that you have to remember is that AI is designed to speed us up and not completely replace us, especially in the era of very professional software engineering. Claude still makes mistakes. I'm sure that it will keep making mistakes, even if it's going to get better over time. So being able to recognize these mistakes will actually solve a lot of your problems.你必须记住，人工智能旨在提高我们的工作效率，而不是完全取代我们，尤其是在软件工程高度专业化的时代。克劳德仍然会犯错。我相信它还会继续犯错，即使随着时间的推移它会变得更好。因此，能够识别这些错误实际上可以解决你很多问题。
Give it context about why. "We need this to be fast because it runs on every request" changes how Claude approaches the problem. "This is a prototype we'll throw away" changes what tradeoffs make sense. Claude can't read your mind about constraints you haven't mentioned.解释原因。“我们需要它运行速度快，因为它每次请求都会执行”会改变克劳德解决问题的方式。“这是一个原型，我们会弃用它”会改变哪些权衡取舍是合理的。克劳德无法读懂你未提及的限制条件。
Remember: output is everything, but it only comes from input. If your output sucks, your input sucked. There's no way around this.记住：输出至关重要，但它源于输入。如果你的输出很差，那说明你的输入也很差。这是无法避免的。
## Bad Input == Bad Output错误输入 == 错误输出
People blame the model when they get bad results. "Claude isn't smart enough" or "I need a better model."人们在得到不好的结果时会责怪模型。“克劳德不够聪明”或者“我需要一个更好的模型”。
Reality check: you suck. If you're getting bad output with a good model like Opus 4.5, that means your input and your prompting sucks. Full stop.认清现实：你太差劲了。如果你用像 Opus 4.5 这样优秀的模型都产出差，那就说明你的输入和提示都很糟糕。就这么简单。
The model matters. A lot, actually. But model quality is table stakes at this point. The bottleneck is almost always on the human side: how you structure your prompts, how you provide context, how clearly you communicate what you actually want.模型很重要，真的非常重要。但就目前而言，模型质量只是基本要求。瓶颈几乎总是出在人身上：你如何构建提示语，如何提供背景信息，以及如何清晰地传达你的实际需求。
If you're consistently getting bad results, the fix isn't switching models. The fix is getting better at:如果你一直得到不好的结果，解决办法不是更换模型。解决办法在于提高以下方面的能力：
How you write prompts. Specific > vague. Constraints > open-ended. Examples > descriptions.如何编写提示语。具体优于模糊。限定性优于开放式。示例优于描述。
How you structure requests. Break complex tasks into steps. Get agreement on architecture before implementation. Review outputs and iterate.如何组织请求？将复杂任务分解成多个步骤。在实施前就架构达成一致。审查输出并迭代。
How you provide context. What does Claude need to know to do this well? What assumptions are you making that Claude can't see?你如何提供背景信息？克劳德需要了解哪些信息才能做好这件事？你做了哪些克劳德看不到的假设？
That said, there are real differences between models:也就是说，不同型号之间确实存在差异：
Sonnet is faster and cheaper. It's excellent for execution tasks where the path is clear - writing boilerplate, refactoring based on a specific plan, implementing features where you've already made the architectural decisions.Sonnet 速度更快、成本更低。它非常适合执行路径清晰的任务——例如编写样板代码、根据特定计划进行重构、以及在架构决策已经确定的情况下实现功能。
Opus is slower and more expensive. It's better for complex reasoning, planning, and tasks where you need Claude to think deeply about tradeoffs.Opus 速度较慢，价格也更高。它更适合复杂的推理、规划以及需要 Claude 深入思考权衡利弊的任务。
A workflow that works: use Opus to plan and make architectural decisions, then switch to Sonnet (Shift+Tab in Claude Code) for implementation. This will depend on your task, sometimes you can use opus 4.5 for implementation as well. Think about selling your kidney if you’re doing this through the API usage tab though. Your CLAUDE.md ensures both models operate under the same constraints, so the handoff is clean.一个可行的工作流程是：先用 Opus 进行规划和架构决策，然后切换到 Sonnet（在 Claude Code 中按 Shift+Tab）进行实现。具体情况取决于你的任务，有时你也可以使用 Opus 4.5 进行实现。不过，如果你是通过 API 使用选项卡来完成这些操作，那可就得做好卖肾的准备了。CLAUDE.md 确保两个模型在相同的约束条件下运行，从而实现无缝切换。
## MCP, Tools, and ConfigurationsMCP、工具和配置
Claude has a ridiculous amount of features. MCP servers. Hooks. Custom slash commands. Settings.json configurations. Skills. Plugins.Claude 的功能多得惊人。MCP 服务器。钩子。自定义斜杠命令。Settings.json 配置。技能。插件。
You don't need all of them. But you should actually try them and experiment, because if you're not experimenting, you're probably leaving time or money on the table. I promise you there's at least one new feature coming out in Claude that you don't know about, that you can actually learn about if you follow Boris, the founder of Claude Code.你不需要全部都用上。但你应该尝试一下，做些实验，因为如果你不去尝试，很可能是在浪费时间和金钱。我保证，Claude Code 至少会推出一项你还不知道的新功能，如果你关注 Claude Code 的创始人 Boris，就能了解到这些功能。
MCP (Model Context Protocol) lets Claude connect to external services. Slack, GitHub, databases, APIs. If you find yourself constantly copying information from one place into Claude, there's probably an MCP server that can do it automatically. There's a ton of MCP marketplaces, and if there is not an MCP, it's just a way of getting structured data, so you can just create your own MCP server for whatever tool that you need added that doesn't exist at the moment. I will be very surprised if you find one that doesn't exist though.MCP（模型上下文协议）允许 Claude 连接到外部服务，例如 Slack、GitHub、数据库和 API。如果您发现自己经常需要将信息从一个地方复制到 Claude，那么很可能存在一个 MCP 服务器可以自动完成这项工作。市面上有很多 MCP 服务商，即使没有现成的 MCP，它也只是获取结构化数据的一种方式，因此您可以为任何目前尚不存在的工具创建自己的 MCP 服务器。不过，如果您真的找不到现成的 MCP 服务器，我会非常惊讶。
Hooks let you run code automatically before or after Claude makes changes. Want Prettier to run on every file Claude touches? Hook. Want type checking after every edit? Hook. This catches problems immediately instead of letting them pile up. This is actually what helps remove technical debt as well. If you set a specific hook after every thousand lines, you have the security feature potentially cleaning up your code. Should be very helpful when Claude reviews your PRs.钩子允许你在 Claude 修改代码之前或之后自动运行代码。想让 Prettier 在 Claude 修改的每个文件上都运行一次？用钩子。想在每次编辑后进行类型检查？用钩子。这样可以立即发现问题，而不是让问题堆积起来。这实际上也有助于消除技术债务。如果你每千行代码后设置一个特定的钩子，那么这项安全功能就有可能清理你的代码。这在 Claude 审查你的 PR 时会非常有用。
Custom slash commands are just prompts you use repeatedly, packaged as commands. Create a .claude/commands folder, add markdown files with your prompts, and now you can run them with /commandname. If you're running the same kind of task often - debugging, reviewing, deploying - make it a command.自定义斜杠命令其实就是将你反复使用的提示打包成命令。创建一个 `.claude/commands` 文件夹，添加包含提示的 Markdown 文件，现在你就可以使用 `/commandname` 来运行它们了。如果你经常执行同类型的任务——例如调试、代码审查或部署——那就把它做成一个命令。
If you have the Pro Max plan (I pay the $200/month), why not try everything Claude has to offer? See what works and what doesn't. You're paying for it anyway.如果你订购了 Pro Max 套餐（我每月支付 200 美元），为什么不试试 Claude 提供的所有服务呢？看看哪些有效，哪些无效。反正你已经付了钱。
And here's the thing: don't get shut off if something doesn't work on the first try. These models are improving basically every week. Something that didn't work a month ago might work now. Being an early adopter means staying curious and re-testing things.关键在于：如果第一次尝试失败，不要灰心丧气。这些模型几乎每周都在改进。一个月前行不通的方法，现在可能就管用了。作为早期使用者，意味着要保持好奇心，并不断重新测试。
## When Claude Gets Stuck克劳德陷入困境
Sometimes Claude just loops. It tries the same thing, fails, tries again, fails, and keeps going. Or it confidently implements something that's completely wrong and you spend twenty minutes trying to explain why.有时候，克劳德会陷入循环。它尝试同样的事情，失败，再尝试，再次失败，然后继续。或者，它自信满满地执行了一些完全错误的东西，而你却要花二十分钟试图解释原因。
When this happens, the instinct is to keep pushing. More instructions. More corrections. More context. But the reality is that the better move is just to change the approach entirely.遇到这种情况，人们的本能反应是继续施压，给出更多指示，更多纠正，更多背景信息。但实际上，更好的做法是彻底改变方法。
Start off simple - clear the conversation. The accumulated context might be confusing it. /clear gives you a fresh start.先从简单的开始——理清对话。积累的上下文可能会让对话变得混乱。/clear 命令可以让你重新开始。
Simplify the task. If Claude is struggling with a complex task, break it into smaller pieces. Get each piece working before combining them. But in reality, if Claude is struggling with a complex task, that means that your plan mode is insufficient.简化任务。如果克劳德在处理一项复杂的任务时遇到困难，就把任务分解成更小的部分。确保每个部分都能顺利完成，然后再将它们组合起来。但实际上，如果克劳德在处理一项复杂的任务时遇到困难，那就意味着你的计划模式还不够完善。
Show instead of tell. If Claude keeps misunderstanding what you want, write a minimal example yourself. "Here's what the output should look like. Now apply this pattern to the rest." Claude is extremely good at understanding what success metrics look like and actually being able to follow them, of what a good example is.用实例说话，而不是空谈。如果克劳德总是误解你的意思，那就自己写一个简单的例子。“输出结果应该是这样的。现在把这个模式应用到其他部分。”克劳德非常擅长理解成功指标的含义，并且能够切实地遵循这些指标，他也知道什么是好的例子。
Be creative. Try a different angle. Sometimes the way you framed the problem doesn't map well to how Claude thinks. Reframing - "implement this as a state machine" vs "handle these transitions" - can unlock progress.发挥创意，尝试不同的角度。有时候，你描述问题的方式可能与克劳德的思维方式不符。重新定义问题——比如从“处理这些状态转换”改为“将其实现为状态机”——或许能带来突破。
The meta-skill here is recognizing when you're in a loop early. If you've explained the same thing three times and Claude still isn't getting it, more explaining won't help. Change something.这里的关键技巧在于及早意识到自己陷入了循环。如果你已经解释了三遍，克劳德还是不明白，再解释也没用。那就得做出改变。
## Build Systems构建系统
The people who get the most value from Claude aren't using it for one-off tasks. They're building systems where Claude is a component. But claude code is way better than that. It has a -p flag for headless mode. It runs your prompt and outputs the result without entering the interactive interface. This means you can script it. Pipe output to other tools. Chain it with bash commands. Integrate it into automated workflows.真正能从 Claude 中获益的人并非将其用于一次性任务，而是构建以 Claude 为组件的系统。但 Claude 的代码远不止于此。它有一个 `-p` 标志，用于无头模式。在无头模式下，它会直接运行你的提示符并输出结果，而无需进入交互式界面。这意味着你可以编写脚本、将输出传递给其他工具、将其与 bash 命令链接起来，以及将其集成到自动化工作流程中。
Enterprises are using this for automatic PR reviews, automatic support ticket responses, automatic logging and documentation updates. All of it logged, auditable, and improving over time based on what works and what doesn't.企业利用这项技术实现自动公关审核、自动支持工单回复、自动日志记录和文档更新。所有操作都会被记录、可审计，并根据有效和无效的反馈不断改进。
The flywheel: Claude makes a mistake, you review the logs, you improve the CLAUDE.md or tooling, Claude gets better next time. This compounds. Right now I'm in the process of being able to have Claude already improve its own Claude.md files though. After months of iteration, systems built this way are meaningfully better than they were at launch - same models, just better configured.飞轮效应：克劳德犯了错误，你查看日志，你改进。CLAUDE.md 或者说，工具方面，克劳德下次会做得更好。这种效果会不断累积。目前，我正在努力让克劳德能够改进它自身的性能。 克劳德·医学博士文件方面，经过数月的迭代，以这种方式构建的系统比刚发布时有了显著改进——同样的模型，只是配置更优化。
If you're only using Claude interactively, you're leaving value on the table. Think about where in your workflow Claude could run without you watching.如果你只是以交互方式使用 Claude，那就错失了它的全部价值。想想看，在你的工作流程中，哪些环节可以让 Claude 在无需你监督的情况下运行。
## TLDR
Think before you type. Planning produces dramatically better results than just starting to talk.打字前先思考。事先做好计划比贸然开口要有效得多。
CLAUDE.md is your leverage point. Keep it short, specific, tell it why, and update constantly. This single file affects every interaction.CLAUDE.md 这是你的杠杆点。务必保持简洁、具体，说明原因，并不断更新。这一个文件会影响每一次交互。
Context degrades at 30%, not 100%. Use external memory, scope conversations, and don't be afraid to clear and restart with the copy-paste reset trick.上下文会在 30% 时开始劣化，而不是 100%。使用外部存储器，限定对话范围，并且不要害怕使用复制粘贴重置技巧来清除并重新开始。
Architecture matters more than anything. You cannot skip planning. If you don't think through structure first, output will be bad.建筑设计比什么都重要。规划必不可少。如果事先不仔细考虑结构，最终成果肯定会很糟糕。
Output comes from input. If you're getting bad results with a good model, your prompting needs work. Get better at communicating.输出源于输入。如果使用优秀的模型却得到糟糕的结果，说明你的引导方式需要改进。你需要提升沟通技巧。
Experiment with tools and configuration. MCP, hooks, slash commands. If you're paying for Pro Max, try everything. Stay curious even when things don't work the first time.尝试各种工具和配置。MCP、钩子、斜杠命令等等。如果你付费购买了 Pro Max 版本，那就应该尝试所有功能。即使第一次尝试失败，也要保持好奇心。
When stuck, change the approach. Don't loop. Clear, simplify, show, reframe.遇到瓶颈时，换个方法。不要陷入循环。理清思路，简化问题，展示结果，重新构建框架。
Build systems, not one-shots. Headless mode, automation, logged improvements over time.构建系统，而非一次性项目。采用无头模式、自动化，并记录随时间推移的改进情况。
If you're building with Claude - whether it's your own projects or production systems - these are the things that determine whether you're fighting the tool or flowing with it.如果你正在使用 Claude 进行构建——无论是你自己的项目还是生产系统——这些因素将决定你是在与工具对抗还是顺应它。
Modern day technology is absurdly capable. If you want more tips on how to get the most out of AI for yourself or your business, subscribe to my free weekly AI newsletter: https://varickagents.com/newsletter现代科技功能强大得令人难以置信。如果您想了解更多关于如何最大限度地利用人工智能为自己或企业带来的益处，请订阅我的免费每周人工智能简讯：https://varickagents.com/newsletter
## 相关链接
- [Eyad](https://x.com/eyad_khrais)
- [@eyad_khrais](https://x.com/eyad_khrais)
- [707K](https://x.com/eyad_khrais/status/2010076957938188661/analytics)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [SCRATCHPAD.md](https://scratchpad.md/)
- [plan.md](https://plan.md/)
- [草稿本.md](https://scratchpad.md/)
- [计划.md](https://plan.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [Claude.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [克劳德·医学博士](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [https://varickagents.com/newsletter](https://varickagents.com/newsletter)
- [https://varickagents.com/newsletter](https://varickagents.com/newsletter)
- [Upgrade to Premium升级至高级版](https://x.com/i/premium_sign_up)
- [3:51 AM · Jan 11, 2026](https://x.com/eyad_khrais/status/2010076957938188661)
---
*导出时间: 2026/1/11 10:33:05*