第三章：第一次会话：从“目标”到“可审阅 diff”

3.1 先把“对话”变成“工程任务”

Claude Code 不是让你“聊得开心”，而是让你“交付一个可审阅的改动”。第一次会话就用最稳的格式：

目标：……
约束：……
验收：……

示例（你可以直接复制给 Claude Code）：

目标：修复用户列表页搜索框输入后无响应的问题。
约束：不要改接口协议；不要引入新依赖；只改前端代码。
验收：能复现问题→修复→跑 lint 与单测通过；提供 /diff 供审阅。

3.2 让 Claude 先探索，再动手

当你把目标说清楚后，第一步不要让它直接改代码，而是让它先把“入口与证据”找出来：

先不要改代码。
请先定位：相关路由、组件、请求函数在哪里；给出你认为导致问题的证据（文件/函数/调用链）。
然后给出最小修复方案（改动范围与风险点）。

这一步的价值是：把修复从“猜”变成“基于证据的修改”。

3.3 做小步提交：一次只解决一个问题

第一次会话推荐你刻意把任务拆小：

• 第一轮只修复“无响应”这一个点
• 第二轮再补测试/补边界
• 第三轮再做重构/清理

拆小的好处是：每一步都有 diff，容易审阅与回滚。

3.4 高频命令：/help、/diff、/run

你会反复用到这些命令：

• /help：查看可用命令
• /diff：在关键节点查看改动（一定要看）
• /run <command>：让 Claude 跑测试/构建/lint

建议你把“验收命令”明确写给 Claude，例如：

修复后请依次运行：
1) npm test
2) npm run lint
3) npm run build
并把失败原因与修复方案说明清楚。

3.5 本章小结

你现在有了一个稳定的第一会话模板：

• 用“目标/约束/验收”把任务工程化
• 先探索再修改，基于证据定位
• 小步交付，关键节点用 /diff 审阅
• 用 /run 把验证自动化

下一章我们进一步提升成功率：如何在一个新仓库里让 Claude 快速读懂你的项目约定与边界。