启动你的第一个 Claude Code 会话

「我已经装好了 Claude Code，接下来该说什么？」

这是很多开发者装好 CLI 之后的第一个卡点。安装章解决的是「能不能跑起来」；本章带你走完第一次真正有用的对话——从启动、发指令、读懂权限弹窗，到让 Agent 在你的项目里完成一件可验证的小事。

不必一次记牢所有命令。按下面顺序边读边做，每节末尾有一两个小检查；通过再往下走，比一口气翻完更省时间。

---

启动会话

它和网页聊天差在哪里？

ChatGPT 在浏览器里，不知道你的 package.json 长什么样。Claude Code 从你执行 claude 时所在的目录出发——默认把当前文件夹当作工作区，像一位刚坐到你对面的同事：能翻 repo、跑测试、改文件，但改之前和跑危险命令之前会问你。

用一句话说清这个区别，后面很多设计（@ 引用、权限弹窗、在项目根启动）就都不难理解了。

基本启动

cd ~/projects/my-app   # 建议先进入项目根
claude

首次运行若尚未登录，会引导你在浏览器完成 OAuth；若已按安装章配置 API 密钥，会直接进入会话。

已经想清楚要做什么，可以带开场白：

claude "用三句话概括这个项目的目录结构和主要技术栈"

交互会话与单次查询

方式	命令	适合
交互会话	claude 或 claude "..."	日常多轮开发、看 diff、逐步授权
单次查询	claude -p "..."	脚本、CI、问完即走

cat build.log | claude -p "找出导致构建失败的前三个错误及修复建议"

需要指定模型时（例如走 OpenRouter）：

claude --model claude-sonnet-4-6
claude --model anthropic/claude-sonnet-4-6

恢复会话

状态保存在 ~/.claude/：

claude -c                                    # 继续当前目录最近一次会话
claude -r "auth-refactor" "继续上次未完的 PR"  # 按名称或 ID 恢复

为什么最好在项目根目录启动？ 工作区以启动目录为锚。在根目录，Agent 更容易看到 package.json、CLAUDE.md 和整体结构；在 src/components/ 里启动也可以，但要意识到——它此刻「眼中的项目」变小了。

动手： 在真实项目根运行 claude，输入 /doctor，再问一句：这个项目用的是什么包管理器和测试框架？ 看它是否会去读配置文件。三项都顺利，继续下一节。

---

Slash 命令：会话里的控制面板

以 / 开头的内容不是普通聊天，而是发给 CLI 的指令——切换模式、清上下文、看用量，类似 IDE 里的 Command Palette。输入 / 列出全部命令，/hel 会过滤到 /help。

第一个会话就要认识的

命令	作用	什么时候用
/help	列出命令	忘了有什么
/config	设置模型、主题、权限模式等	换模型或默认权限
/clear	新话题、空上下文；旧会话仍可在 /resume 找回	任务彻底换了
/compact	压缩长对话为摘要，腾出窗口	同一任务聊很久还要继续
/context	看上下文占用	感觉变慢或「变笨」
/cost	查看用量（即 /usage）	关心消耗
/doctor	诊断安装与环境	异常或升级后
/permissions	管理 allow / ask / deny	提示太烦或想预授权

/clear 和 /compact 别混： /clear 是换一道菜——旧功能细节不该污染新任务。/compact 是换盘子不换菜——把同一条任务的长对话压成摘要。修完功能 A 要做无关的功能 B，用 /clear；同一个 bug 查了二十轮，用 /compact。

能向同事讲清上面这句区别，比背命令表有用得多。

在新仓库里的起手式

第一次长期在某个 repo 里用时，值得花几分钟：

/init          # 生成或完善 CLAUDE.md
/permissions   # 为常见只读/测试命令预置 allow，少被打断

细节见后续 CLAUDE.md；更多命令分类与日常组合见 Slash 命令。

动手： 运行 /context 看占用；多聊几轮后 /compact，看任务是否仍连贯；再 /clear 开新话题。

---

把信息交给 Claude

方式	示例	你可以把它想成
自由文本	解释 src/auth 的登录流程	口头布置任务
@ 引用	阅读 @src/auth/login.ts 找出竞态	把文件放到桌上
管道 + -p	cat error.log | claude -p "分析"	把日志递过去
图片	粘贴或拖拽截图	指给同事看界面/报错

@ 后跟路径，CLI 会注入文件内容：

@package.json 有哪些 script？哪个适合跑单测？

多个文件：@src/a.ts @src/b.ts 对比这两个模块的边界

管道更适合日志、一次性脚本：

git diff HEAD~1 | claude -p "用中文总结这次提交的意图和风险"

终端里粘贴或拖拽截图也常用——报错弹窗、设计稿标注，往往比纯文字省事。

@src/foo.ts 和写「请读取 src/foo.ts」有什么不同？ 前者由 CLI 解析并注入，路径可靠；后者靠模型是否主动去 Read，大仓库里更容易漏读或读错。

动手： 选项目里一个真实文件，发送：@<路径> 用五句话说明这个文件做什么，并提一个改进点。 若回答明显基于文件内容而非空泛猜测，这一关就过了。

---

权限提示

Claude Code 能执行 Bash、改文件。若全无确认，一次误判就可能动错目录。权限的本质是 Human-in-the-Loop：Agent 提议，你拍板。

类型	例子	通常要不要你点头
只读	Read、Grep、Glob	否
改文件	Edit、Write	是（可对部分路径本会话不再问）
跑命令	Bash	是（可对 npm test 等模式长期 allow）

/permissions 里可看 allow / ask / deny；匹配顺序是 deny → ask → allow，deny 优先。

Shift+Tab 或 /config 可切换模式：

模式	行为	适合
default	首次用工具时询问	日常
plan	只读探索，不改源码	大改前先摸清
acceptEdits	自动接受工作区内编辑	信任度高的迭代
bypassPermissions	跳过提示	仅隔离环境（容器/VM）

弹窗出现时，先看三件事：要执行什么、动哪些路径、能不能「不再询问」。对 git push、rm、访问未知 URL 的 curl，宁可多拒一次，也别习惯性全放行。

团队在 .claude/settings.json 里可预置规则（个人偏好放 ~/.claude/settings.json）：

{
  "permissions": {
    "allow": [
      "Bash(npm run test *)",
      "Bash(npm run lint *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

选了「Yes, and don’t ask again」针对 Bash(npm test)，你信任的究竟是模型永远诚实，还是这条命令模式在这个项目目录下可以重复执行？通常是后者——批准的是一类命令，不是以后所有操作都不用问。

动手： 在 default 下让 Claude 跑一次 npm test（或等价命令），看弹窗；打开 /permissions 对照规则；用一句话说明为什么 deny 应优先于 allow。

---

完成第一个任务

下面两个练习建议都做：A 只读、低风险；B 约十分钟，走完整「改代码 → 验证」闭环。

练习 A：分析项目结构

在项目根启动 claude：

请分析这个仓库的目录结构：主要模块、入口文件、测试如何运行。
先列出你将读取哪些文件，再给出结论。不要修改任何文件。

你会看到类似这样的节奏：

你的意图 → 规划（列文件） → 读取（Read / Glob / Grep） → 总结

输出后看一眼：清单里有没有漏掉你关心的 tests/ 或 docs/？审查清单和审查 diff 一样值得花时间。

练习 B：修一条真实的 Lint 报错

1. 本地跑 npm run lint（或项目等价命令），复制一条真实报错
2. 在会话里发送：

下面是一条 linter 报错，请定位、修复，并再次运行 lint 确认通过。
不要改动与这条报错无关的文件。

<粘贴报错全文>

3. 对每个 Edit、Bash 提示看清再批
4. 让它说明改了什么，或用 /diff 查看

完整闭环通常是：

意图 → 规划 → 读文件定位 → 修改 → 跑 lint → 看结果 → 汇报或继续修

若仍失败，把新报错贴回去，看它是在迭代还是在乱改一片——不要悄悄替它改文件。

以后在新仓库可以用的提示骨架

【背景】我是新加入的开发者。
【目标】<一句话>
【约束】不要改 <路径>；改前说明计划；改后运行 <测试命令>。
【验收】<怎样算完成>

背景、目标、约束、验收写清楚，Agent 才知道何时该停。

动手： 完成 A 或 B 至少一个；能说出本轮 Agent 做了读、改、跑命令中的哪几类；至少有一次对不放心操作点了拒绝或追问。

---

继续读下一章之前

合上终端，试着不看文档回答：

1. Claude Code 会话和网页聊天，根本差在哪？
2. /clear 和 /compact 各解决什么问题？
3. 权限弹窗出现时，你先想哪三件事？
4. 一次完整修 bug，Agent 大致经过哪几步？

有卡壳，回到对应小节重做一次「动手」——漏洞往往在「以为懂了」的地方。

再问自己几句，会决定你后面用得顺不顺：

• 第一个任务够不够具体？「优化项目」会换来漫无目的的改动；「修 UserService.ts 第 42 行 unused variable」才是可交付单元。
• 你更怕 Agent 做错，还是怕自己点太多「永远允许」？多数事故来自后者——回想今天批准的「don’t ask again」是否都值得。
• Agent 的总结和你读代码的结论不一致时，信谁？以你跑过的测试和看过的 diff 为准；从第一个会话就养成副驾驶心态。
• 愿不愿意花两分钟写三行项目说明？/init 或手写：包管理器、测试命令、禁止改动的目录——后面每次会话都少解释一遍。

---

上一章：配套工具精选 · 下一章：Slash 命令与常用功能——把会话控制面板系统过一遍；再读 代理循环与工具调用，理解命令背后的执行机制。