很多人在装好 Claude Code 的第一分钟，就迫不及待地打出了那句话：
帮我把登录页面改一下。
终端刷得飞快，文件改了七八个，你觉得很爽。但半小时后，问题来了：越纠正它，它绕得越远，diff 越来越大。
这不是 Claude Code 不够聪明。是你把它当老员工用了，而它其实是个刚来第一天的新同事。
人聪明、手快，但你没给项目地图，没告诉它哪些地方不能碰，也没告诉它什么叫"做完"。这种情况下，它越勤快，你越累。
所以这份新手攻略的核心只有一句话：第一次用 Claude Code，不要先提需求。先做开工检查，再堵 6 个坑。
开工检查：先看 git status
进项目不要直接开 Claude Code。先确认一件事：当前工作区是不是干净的。
git status --short
如果什么都没输出，干净，可以继续。
如果已经有改动，进 Claude Code 后的第一句话要划清边界：
先不要修改任何文件。
请先查看 git status，告诉我当前有哪些未提交改动。
这些改动默认都是我手工改的，你不要覆盖。
等我确认后，再开始下一步。
成功标志：Claude Code 能说清楚当前有哪些改动，而且没有直接开始写代码。
这就像请师傅上门维修前，先告诉他"这面墙我昨天刚刷过，别碰"。你不说，他真有可能顺手给你重新刷一遍。
第 1 坑：没有 CLAUDE.md
Claude Code 里最重要的项目记忆文件是 CLAUDE.md——你可以把它理解成"给新同事看的入职纸条"：项目怎么跑、哪些地方不能碰、改完怎么验收。
第一次进项目可以输入 /init，它会分析项目生成起步版。如果文件已存在，它通常只给改进建议，不会直接覆盖。
但 /init 生成的内容往往像"项目说明书"，不一定像"干活规矩"。你需要补一层真正能管住它的规则。
CLAUDE.md 不是许愿墙，是施工规矩。
不要写成"保持代码整洁""注意性能"这种空话。要写能检查的动作——先看 git status、别乱加依赖、别碰 .env、没验证别说完成。
核心结构应该覆盖这几个维度：
- 开工前：先看工作区状态，不确定项目结构时先读 README 和配置文件
- 项目地图：源码入口、测试位置、配置入口、禁止主动修改的目录
- 命令发现：不要假设工具链，先看锁文件，优先复用已有 scripts
- 禁区：.env、密钥、破坏性命令、涉及 auth/billing/payments 时默认高风险
- 验收：改了哪些文件、跑了哪些检查、还有哪些没验证
成功标志：项目根目录里真的出现了 CLAUDE.md，而且里面是能检查的动作，不是泛泛的建议。
第 2 坑：一上来就改代码
很多人第一句话就是"帮我加一个登录页面"。这句话太猛了——它还不知道你的技术栈、路由、组件风格、测试怎么跑，你就让它开始写。
更稳的第一句话应该是：
先不要修改任何文件。
请先阅读项目结构，找出：
1. 技术栈
2. 启动命令
3. 测试命令
4. 主要目录用途
5. 现有代码风格
6. 这个项目最容易踩的 3 个坑
整理完以后，再问我要不要进入开发。
关键只有一句：先不要修改任何文件。
做完以后看两个成功标志：
git status --short没有新文件或被修改的文件- 它能说出项目的真实情况，而不是泛泛而谈
如果它顺手改了文件，立刻纠正：
停。我刚才要求只读扫描，不允许修改文件。
请先说明你改了哪些文件、为什么改、怎么恢复。
在我确认前，不要继续修改。
前面有没有把边界立住，决定了后面它会不会听话。
第 3 坑：工具箱没配齐
Claude Code 再聪明，也是你的电脑上干活。它要找代码、查文件、读 JSON。如果这些基础工具没配，它就会绕远路，速度慢，误判也多。
先在终端跑这三条：
rg --version
fd --version
jq --version
成功标志：三条都能打印版本号。
如果提示 command not found：
- Mac：brew install ripgrep fd jq
- Ubuntu/Debian：sudo apt install ripgrep fd-find jq（fd 有时叫 fdfind）
- Windows：用 WSL 或者确认 Claude Code 运行环境里能调用类似工具
如果 fdfind 可用但 fd 不可用，在 CLAUDE.md 里补一句：本机查文件命令使用 fdfind，不是 fd。
这三把刀各有所长：rg 是找某句话在哪个文件，fd 是找某个文件在哪里，jq 是把 JSON 拆开看。刀顺手，做饭才不会乱。
第 4 坑：直接在主分支上试
Claude Code 最大优点是手快，但副作用是一次可能改很多文件。如果直接在主目录里试，跑偏后清理起来很累。
用 git worktree 给它开一个隔离目录：
git status --short # 先确认当前状态
git worktree add ../myproject-ai-first -b ai/first-claude-task
cd ../myproject-ai-first
# 再启动 Claude Code
成功标志是 git worktree list 能看到两个工作区：
/Users/you/myproject abc1234 [main]
/Users/you/myproject-ai-first abc1234 [ai/first-claude-task]
主项目是正屋，worktree 是旁边临时搭出来的练习间。它可以在练习间里拆、装、试，不用担心一锤子砸到承重墙。
做完如果不需要了：git worktree remove ../myproject-ai-first
刚开始不用开很多，先拿一个低风险任务试一次，比如改一个按钮文案、补一个小测试、修一个明确报错。先养成这个习惯，你心里会踏实很多。
第 5 坑：不写验收标准
Claude Code 很会总结，它改完会说"已完成""已修复""测试通过"，语气很稳。但你不能只看它怎么说——代码能不能交，要看证据。
以后不要这样提需求：
修一下登录失败的问题。
换成这种：
任务：修复用户 session 过期后重新登录失败的问题。
范围：
1. 只看 src/auth 和 src/api/session 相关文件；
2. 不要重构整个登录模块；
3. 不要修改数据库结构。
要求：
1. 先说明当前登录流程；
2. 找到最小修改方案；
3. 如果项目有测试，优先补一个能复现问题的测试；
4. 修改后运行最小相关测试；
5. 最后输出 git diff --stat；
6. 如果某个检查无法运行，直接说明原因，不要说已经验证。
这段话看着长，其实是在给它尺子。没有尺子它只能凭感觉修。有了尺子，它至少知道边界、目标和交卷方式。
改完以后你自己也要跑两条：
git status
git diff --stat
如果是代码改动，再让它做一次只读 review：
请只读 review 这次 diff。
重点看：
1. 有没有改动超出需求范围；
2. 有没有漏掉测试；
3. 有没有破坏项目已有约定；
4. 有没有安全、数据或权限风险；
5. 哪些地方需要我人工确认。
不要修改文件，只输出 review 结果。
成功标志不是它说"好了"，而是你手里有三样东西：改了哪些文件、跑了哪些检查、还有哪些没验证。这三样比一句"完成了"可靠得多。
第 6 坑：所有事塞进一个会话
很多人用 Claude Code 还是以前用聊天机器人的习惯——修 Bug 问一句，顺手让它解释一个文件，又回到 Bug，中途再让它写提交说明。
这会把会话变成杂物间。Claude Code 的上下文会保存对话、读过的文件、命令输出和修改过程。一个会话塞得越满，早期规则越容易被冲淡。
最简单的习惯：一个会话只做一个任务。
任务结束后如果要换主题，输入 /clear。如果感觉上下文快满了，可以先看 /context，需要压缩时用 /compact。如果它走错方向想回到检查点，用 /rewind。
判断标准：同一个问题纠正它两次，它还是绕不出来，就不要在原会话里继续纠缠。把已知信息整理成一个新提示，重新开始。
我们重新开始这个问题。
已知信息：
1. 报错出现在登录回调阶段；
2. token 刷新逻辑可能有问题；
3. 刚才尝试修改 session 存储方向失败；
4. 不要重构整个登录模块。
请先阅读 src/auth 相关文件，找出最小修改方案。
在给出计划前，不要修改代码。
这就像桌面太乱了，不是继续把新文件堆上去，而是先把桌子清一下，再摊开下一件事。
完整检查清单
第一次用 Claude Code，就按这个顺序走：
[ ] 0. 进项目后先跑 git status --short
[ ] 1. 用 /init 建 CLAUDE.md，再补上项目规矩
[ ] 2. 先发"不要修改任何文件"的只读扫描提示词
[ ] 3. 检查 rg / fd / jq 是否可用
[ ] 4. 用 git worktree 给它开隔离目录
[ ] 5. 每个任务都写清范围、验收和不能碰的地方
[ ] 6. 任务结束后 /clear，别把所有事塞进一个会话
你现在就可以做一件很小的事：打开你正在用 Claude Code 的项目，先别让它写新功能。先跑 git status --short，然后输入 /init，再把 CLAUDE.md 模板贴进去改成你的项目地图。
这一步不酷，但管用。工具越能动手，越要先给它地图、工具箱和验收尺。你把这 6 步做完，再让 Claude Code 写代码，它才更像一个能配合你的助手，而不是一个很勤快但到处乱改的新同事。