Eyad这篇Claude Code完整指南「The complete claude code tutorial 」不错。

中国龙卷风

Eyad这篇Claude Code完整指南「The complete claude code tutorial 」不错。


我做软件工程师 7 年了，先后在 Amazon、Disney 和 Capital One 工作过。我交付的代码影响过数百万用户，也构建过不能出错的系统。现在我是一个创业公司的 CTO，公司专门为企业构建智能体，而 Claude Code 是我每天都在用的主力工具。

下面是一份新手指南，包含我在用 Claude 构建可处理大型企业复杂负载的稳健系统时学到的一切，希望对你有帮助。

一、先思考

大多数人以为，用 Claude Code 或其他 AI 工具，第一步就是开始输入或说话。但这可能是你一开始就会犯的最大错误之一。真正应该先做的，是思考。

在我所有的实践中，只要使用 plan 模式，得到的结果几乎总是显著优于直接开始输入的情况，而且差距非常大。

当然，这对一些人来说说起来容易做起来难。你可能没有多年的工程经验去独立思考架构。所以我有两个建议：

1，你要开始学习。如果你永远不培养这项能力，你就是在削弱自己，即使慢慢学也好。
2，与 ChatGPT、Gemini 或 Claude 深入对话，描述你想构建什么，询问不同系统设计方案，最终一起确定方案。对话应该是双向的，而不是单向输入。

这适用于一切任务，哪怕是总结邮件。
在让 Claude 写功能前，先想架构。
在让它重构前，先想目标形态。
在让它调试前，先想你真正知道什么。

plan 模式里信息越多，输出越好，因为输入更好。

模式很一致：先思考，再输入，结果会好得多。

二、架构的重要性

在软件工程里，只给输出目标而不给实现路径，就会留下大量自由度，这正是 AI 生成代码问题的根源。

“给我做一个认证系统” 太宽泛。

而
“用现有 User 模型做邮箱密码登录，会话存 Redis，24 小时过期，给 /api/protected 加中间件”

差别非常明显。

按两次 Shift+Tab 进入 plan 模式。
这只花 5 分钟，却能帮你省下数小时调试时间。

三、CLAUDE.md

CLAUDE.md 是一个 Markdown 文件，而 Markdown 是 AI 非常擅长处理的格式。

每次 Claude Code 会话启动时，它首先读取这个文件。里面的每条指令都会影响它如何理解你的项目。这相当于 Claude 每次对话前的入职培训资料。

多数人要么忽视它，要么写一堆无用信息，反而降低效果。

真正重要的是：

1，保持简短。Claude 同时只能稳定遵循约 150–200 条指令，而系统提示本身已经占了约 50 条。写太多，它会随机忽略。
2，只写项目特有信息。不要解释组件目录是什么。写那些真正影响流程的东西，比如关键 bash 命令。
3，写“为什么”，不只是“做什么”。
“启用 TS strict 模式” 可以。
“启用 strict 模式，因为我们曾因 any 类型导致生产事故” 更好。

原因能帮助 Claude 做你没想到的判断。

4，持续更新。
工作时按 （井号） 键，Claude 会自动把指令写进 CLAUDE.md。
当你第二次纠正同一件事时，就该写进文件了。

坏的 CLAUDE.md 像写给新员工的文档。
好的 CLAUDE.md 像你给未来失忆的自己留的笔记。

四、上下文窗口的限制

例如 Opus 4.5 有 20 万 token 上下文。

但很多人没意识到：
在使用 20%–40% 时质量就开始下降了。

如果你经历过 compact 后结果仍然很差，那就是因为质量早已下降，压缩并不会恢复能力。

每条消息、每个文件、每段生成代码、每次工具输出都会累积。
一旦质量下降，更多上下文只会更糟。

避免问题的方法：

1，每个任务一个会话。不要在同一会话里既做认证系统又重构数据库。
2，使用外部记忆文件，例如 SCRATCHPAD.md 或 plan.md。
3，复制粘贴重置法：复制重要信息，/compact，总结，再 /clear，然后只粘回关键内容。
4，知道何时清空。如果会话混乱，直接 /clear。Claude 仍会读取 CLAUDE.md。

正确心智模型是：Claude 是无状态的。

五、提示词就是一切

人们花几周学框架，却不学如何与生成代码的系统沟通。

提示词不是玄学，而是沟通。
清晰永远优于模糊。

有效的方法：

1，说清楚需求。
2，说明不要做什么。Claude 喜欢过度工程化。
3，说明约束原因，例如性能或是否是原型。

AI 是加速器，不是替代品。
它仍会犯错，你要能识别错误。

记住：输出只来自输入。

六、坏输入 = 坏输出

很多人怪模型不够聪明。

现实是：如果你用好模型仍得到坏结果，问题通常在你。

真正的瓶颈是：

1，提示词写法
2，请求结构
3，上下文提供方式

模型确实有差异：

Sonnet 更快更便宜，适合执行任务。
Opus 更慢更贵，适合规划与复杂推理。

一个有效流程是：
用 Opus 规划架构，再切 Sonnet 实现。

CLAUDE.md 保证模型切换后仍遵循相同规则。

七、MCP、工具和配置

Claude 有大量功能：
MCP、Hooks、Slash 命令、插件、配置等。

你不需要全部，但应该尝试。

MCP 能连接外部服务。
如果你在复制信息进 Claude，很可能 MCP 能自动化。

Hooks 能在 Claude 修改代码前后执行操作，例如自动格式化或类型检查。

自定义 Slash 命令就是复用提示词。

如果你已经付费，就多尝试。
模型每周都在变好。

八、当 Claude 卡住

有时 Claude 会循环失败。

本能是继续补充说明，但更好的办法是改变策略：

1，清空会话
2，拆分任务
3，给示例而不是解释
4，换种表述方式

关键技能是尽早识别循环。

九、构建系统，而不是一次性工具

最能获得价值的人不是拿 Claude 做单次任务，而是把它嵌入系统。

Claude Code 支持 headless 模式（-p），
可脚本化、自动化、串联命令。

企业正在用它自动审 PR、处理支持请求、更新文档。

飞轮效应是：
Claude 出错 → 改进 CLAUDE.md 或工具 → 下次更好。

几个月后系统会显著提升，即使模型没变。

如果你只交互式使用 Claude，你正在浪费价值。

十、总结

先思考再输入
CLAUDE.md 是杠杆点
上下文在 30% 就开始劣化
架构决定质量
输出来自输入
尝试工具与配置
卡住就换方法
构建系统而不是单次使用

现代技术已经强得离谱。
如果你在用 Claude 构建系统或产品，这些因素决定你是在与工具对抗，还是顺势而行。

原文：x.com/eyad_khrais/status/2010076957938188661