主题
05.2 第一次会话完整走查
从 claude 到第一个由 Claude 提交的 commit，一步都不跳。
读完你能做什么：走完一个完整的"描述需求 → 改代码 → 跑测试 → 提交"闭环，建立对 Agent 工作方式的直觉。
一、准备一个练习项目
不要拿重要项目做第一次实验。找一个玩具项目，或者新建一个：
bash
mkdir claude-first-run && cd claude-first-run
git init
npm init -y创建一个有小 bug 的文件，用来练习：
bash
mkdir src test
cat > src/calc.js <<'EOF'
function add(a, b) {
return a - b; // 故意写错，应该是 +
}
module.exports = { add };
EOF
cat > test/calc.test.js <<'EOF'
const { add } = require('../src/calc');
test('add works', () => {
expect(add(2, 3)).toBe(5);
});
EOF
npm pkg set scripts.test="jest"
npm install --save-dev jest二、启动并初始化
bash
claude第一件事：
text
> /init它会分析项目，生成 CLAUDE.md。看一眼生成的内容，感受它对项目的理解程度。
三、第一个任务：让它自己发现 bug
不要直接告诉它哪里错了。 让它通过跑测试来发现 —— 这是训练你观察它工作方式的最佳场景。
text
> 运行测试，如果有失败的，定位根因并修复。
修复后重新运行测试确认全部通过。
在确认通过之前不要说"完成了"。3.1 观察它的工作流
你会看到它大致这样做（每一步都可能弹出权限提示）：
text
1. 请求运行 `npm test`
→ 你会看到权限提示：是否允许 Bash(npm test)？
→ 批准
2. 读到测试失败：expected 5, received -1
3. 请求读取 src/calc.js
→ 权限提示：是否允许 Read？
→ 批准
4. 发现 return a - b 应该是 a + b
5. 请求编辑 src/calc.js
→ 权限提示：显示 diff，是否允许 Edit？
→ 审阅 diff，批准
6. 请求重新运行 npm test
→ 批准
7. 报告：测试通过3.2 这里发生了什么（对应 04.1 的机制）
- 它不能自己执行命令，每一步都是"请求 → 你批准 → 客户端执行 → 结果回填"
- 它是看到真实的测试输出才知道哪里错，而不是猜
- 修复后它自己又跑了一遍测试验证 —— 因为你给了"确认通过前不要说完成"的标准
这就是 Agent Loop。完整机制见 06.1 终端接管逻辑与工具循环。
四、减少权限打断
第一次你可能被每一步的权限提示烦到。有几种方式减少打断：
4.1 会话内临时批准
批准某个操作时，选择"总是允许这类"（如"总是允许 npm test"）。
4.2 用 Shift+Tab 切换权限模式
在会话中按 Shift+Tab 循环切换权限模式。常用的是 acceptEdits（自动接受文件编辑，但危险命令仍然问）。
4.3 预配置允许规则
在 .claude/settings.json 里：
json
{
"permissions": {
"allow": [
"Bash(npm test)",
"Bash(npm run build)",
"Bash(git status)",
"Bash(git diff *)",
"Read",
"Edit"
]
}
}注意：不要一上来就 --dangerously-skip-permissions。先理解每一步在做什么，再逐步放开。权限模型详见 05.5。
五、第二个任务：让它提交
text
> 把刚才的修复提交。commit message 遵循 conventional commits 规范，
说清楚修了什么、为什么。提交前先给我看 message，我确认后再提交。它会：
text
1. 请求 git add 和 git status
2. 起草 commit message，比如：
fix(calc): correct add() to use addition instead of subtraction
The add function was using subtraction operator, causing
test failures. Changed to use + operator.
3. 等你确认
4. 执行 git commit观察：它遵守了"先给我看 message"的检查点。这是你控制 Agent 的关键手段 —— 在危险/重要操作前设置人工确认。
六、第三个任务：体验 Plan Mode
对于更大的改动，先规划再动手。切换到计划模式：
text
> /plan或按 Shift+Tab 切到 Plan 模式。然后：
text
> 我想给这个 calc 模块增加 subtract、multiply、divide 三个函数，
每个都要有对应测试。divide 要处理除零。先给我完整方案，不要写代码。Plan 模式下它只读不写，给你一个方案。你审阅、调整，满意后再让它执行。
这是处理复杂任务的标准姿势：先在只读模式下对齐方案，再进入执行模式。
七、常用的会话内命令（第一次就该知道的）
| 命令 | 作用 | 什么时候用 |
|---|---|---|
/init | 生成 CLAUDE.md | 项目第一次 |
/plan | 进入计划模式 | 大改动前 |
/context | 查看上下文占用 | 感觉变慢时 |
/clear | 清空对话（保留 CLAUDE.md） | 换任务 |
/compact | 压缩历史 | 上下文快满 |
/rewind | 回退代码/对话 | 走错方向 |
/model | 切换模型 | 遇到难题升 Opus |
/diff | 查看改动 | 审阅它做了什么 |
/usage | 查看消耗 | 关心成本 |
Esc | 中断当前生成 | 它跑偏了 |
Shift+Tab | 切换权限模式 | 调整自动化程度 |
全量命令见 05.4 斜杠命令速查。
八、第一次会话的心法
8.1 像带一个能干但需要监督的新人
- 给清晰的验收标准，不要含糊
- 在关键节点设检查点（提交前、删除前、大批量改动前）
- 审阅它的 diff，不要盲批
- 看到跑偏立刻
Esc，不要等它错到底
8.2 三个新手常犯的错
| 错误 | 后果 | 正确做法 |
|---|---|---|
一上来就 --dangerously-skip-permissions | 不知道它在干什么 | 先手动批准，理解流程 |
| 需求说一半，让它猜 | 反复返工 | 一次说清目标+约束+验收 |
| 盲目批准所有 diff | 引入你没注意的改动 | 认真看 diff |
| 在一个会话里干十件不相关的事 | 上下文污染 | 每件事一个 /clear |
8.3 一个好习惯：让它先复述
复杂任务开始前：
text
> 在动手之前，先用你自己的话复述一遍你理解的任务目标和约束，
以及你打算怎么做。我确认后你再开始。这能在浪费时间之前暴露理解偏差。
九、验收：你完成第一次会话的标志
text
□ 让它通过跑测试发现并修复了 bug
□ 观察到了"请求 → 批准 → 执行 → 回填"的循环
□ 让它提交了一个规范的 commit
□ 体验了 Plan 模式的"只读规划"
□ 用过 /context 查看占用
□ 知道怎么用 Esc 中断
□ 配置了至少一条 allow 规则减少打断全部做到，你已经跨过了 Claude Code 的入门线。接下来去 05.5 权限模型 把安全边界搞清楚，然后进入 第 06 章 的深度内容。