上一篇你已经把 Claude Code 装好并跑通了第一次对话。但「能用」和「会用」之间还有距离。
这篇讲的是和 Claude Code 交互的基本模式。掌握这些，你就能把它从「偶尔问一下」升级为「日常协作搭档」。
在项目目录里启动：
cd your-project
claude
你会看到一个交互式的命令行界面。光标闪烁，等待你输入。
这里有个关键点：Claude Code 的工作目录就是你启动它的目录。 它能「看到」的文件范围，就是这个目录及其子目录。所以永远在你要操作的项目根目录里启动它。
和 Claude Code 的交互本质上就三种：你问它答、你让它看、你让它做。
最简单的用法，和 ChatGPT 差不多：
这个项目用了什么技术栈？
package.json 里的 scripts 都是干什么的？
解释一下 src/lib/auth.ts 的认证逻辑
区别在于——它不需要你把代码粘贴过来。你提到一个文件路径，它会自己去读。
有时候你不确定问什么，就让它先看：
看看 src/components/ 目录，告诉我这些组件的组织方式有没有问题
检查一下最近的 git log，帮我总结这周都改了什么
读一下 README.md，看看和实际项目结构是否一致
Claude Code 会用自己的工具去执行——读文件用 Read，搜索用 Grep 和 Glob，看目录用 Bash 的 ls。你不用关心它具体用了什么工具，关注结果就行。
这是 Claude Code 最有价值的部分：
在 src/utils/ 下创建一个 format-date.ts，写一个日期格式化函数
把 UserProfile 组件里的 class 语法改成函数式组件
运行 npm test，如果有失败的测试就修复它
做事的时候它会用到各种工具——Write 创建文件、Edit 修改文件、Bash 执行命令。每一步都会告诉你它打算做什么，等你批准。
这是新手最需要理解的机制。
Claude Code 不会偷偷改你的代码。每次它要执行一个操作（创建文件、修改文件、运行命令），都会先告诉你它打算做什么，然后等你确认。
你会看到类似这样的提示：
Claude wants to edit src/utils/format-date.ts
function formatDate(date: Date): string {
- return date.toString()
+ return date.toISOString().split('T')[0]
}
Allow? (y/n)
你也可以配置不同的权限模式。在对话中输入 /permissions 可以查看和调整。日常使用中，我们建议保持默认的逐次确认模式——至少在你对它建立信任之前。
踩过一个坑：刚开始用的时候总觉得每次都要确认很烦，就把权限开到最大。结果有一次它在错误的目录里执行了 rm 命令。从那以后我们老老实实逐次确认了。
在对话中输入 / 开头的命令可以快速执行一些操作。用得最多的几个：
| 命令 | 作用 | 什么时候用 |
|---|---|---|
/help | 查看所有可用命令 | 忘了有什么命令的时候 |
/clear | 清空当前对话 | 对话太长想重新开始 |
/compact | 压缩对话历史 | 对话很长但不想完全清空，保留关键上下文 |
/model | 切换模型 | 想换个模型试试 |
/cost | 查看本次对话的 token 用量 | 想知道花了多少钱 |
/init | 生成项目的 CLAUDE.md | 第一次在一个项目里用 Claude Code |
其他命令（/review、/doctor、/permissions 等）后续文章会展开讲。
Claude Code 理解自然语言，但不是所有说法效果都一样。几个实用的技巧：
效果差：
帮我改一下那个 bug
效果好：
用户反馈登录页面提交后一直 loading。看看 src/app/api/auth/login/route.ts，
检查一下 POST 请求的处理逻辑有没有没返回 response 的路径
关键区别：第二种写法告诉了它哪个文件、什么现象、可能的方向。它就不用大海捞针，直接去看那个文件。
容易出问题：
帮我创建一个用户管理模块，包括注册、登录、修改密码、头像上传、
角色管理、权限控制，还有对应的数据库表和 API 路由
更可控：
我们来搭建用户管理模块。先从数据库开始——
帮我设计 users 表的结构，需要支持邮箱注册和 OAuth 登录
一口气说太多，它可能会遗漏细节或者做出你不想要的设计决策。拆成小步骤，每步确认后再推进，最终结果反而更好。
用 better-sqlite3，不要 ORM
样式用 Tailwind，不要写单独的 CSS 文件
这个函数要兼容 Node.js 18，不要用 22 的新语法
Claude Code 很擅长遵循具体的约束。如果你不说，它会按自己的「最佳判断」来——可能和你的项目规范不一致。
先读一下 src/lib/db.ts，了解我们的数据库连接方式。
然后再帮我写一个新的查询函数。
这比直接说「帮我写个查询函数」好很多。它会先理解你项目的风格和模式，写出来的代码就不会格格不入。
把上面说的串起来，看一个实际的对话过程：
你：这个项目的 API 路由是怎么组织的？先帮我了解一下
Claude Code：[读取 src/app/api/ 目录结构，分析路由模式]
你的 API 路由按功能模块组织在 src/app/api/ 下，每个模块一个目录...
你：好。我需要加一个 /api/feedback 接口，接收用户反馈并存入数据库。
先看看 users 相关的路由是怎么写的，参考那个风格来写
Claude Code：[读取现有路由代码，然后提出方案]
我参考了 /api/users/route.ts 的模式，准备创建以下文件...
Allow? (y/n)
你：y
Claude Code：[创建文件]
已创建。需要我同时写一下对应的数据库迁移脚本吗？
你：对，参考 src/db/migrations/ 下已有的迁移文件格式
Claude Code：[读取现有迁移文件，创建新迁移]
...
注意这个节奏：先了解 → 再指定参考 → 逐步推进 → 每步确认。这比直接甩一段需求过去，效果好得多。
用了一段时间后总结的教训，帮你少走弯路：
1. 在错误的目录启动
在 home 目录启动 Claude Code，然后让它去改某个项目的文件。它能做到（用绝对路径），但它缺乏项目的整体上下文——不知道你的技术栈、代码风格、项目结构。永远 cd 到项目目录再启动。
2. 对话太长不清理
Claude Code 有上下文窗口限制。对话太长，早期的信息会被压缩甚至丢失。完成一个相对独立的任务后，用 /clear 开启新对话，或者用 /compact 压缩历史。
3. 不看它做了什么就批准
每次它提出修改，花几秒看一下 diff。绝大多数时候没问题，但偶尔它会做出你不想要的改动——比如顺手「优化」了你没让它动的代码。养成看 diff 的习惯。
4. 期望一次完美
它不是魔法。复杂任务可能需要几轮调整。第一次输出不满意，告诉它哪里不对、你想要什么效果，它会迭代改进。
除了在对话里交互，Claude Code 也支持「一次性提问」，不进入交互界面：
# 直接问一个问题
claude -p "这个项目的入口文件在哪？"
# 管道输入
cat error.log | claude -p "分析这个错误日志，告诉我问题在哪"
# 输出为 JSON
claude -p "列出所有 API 路由" --output-format json
这在写脚本或者集成到其他工具链时很有用。日常使用还是交互模式更顺手。
到这里，你已经掌握了和 Claude Code 交互的基本功。下一篇我们来做一个完整的实战项目——从需求分析到代码实现到测试，全程用 Claude Code 完成，让你感受真实的协作节奏。