打开后的第一小时
这一章解决什么问题
安装只是一小步。真正决定你能不能把 Zed 用起来的，是第一次打开项目之后能不能顺畅完成这些动作：
- 找到文件
- 看懂界面
- 改一段代码
- 运行项目
- 查看错误
- 提交一次改动
这一章按实际操作顺序来，不急着讲所有功能。
第一步：打开一个真实项目
推荐不要从空文件开始，而是打开一个你已经熟悉的小项目。
在 Windows 上可以这样做：
cd D:\projects\my-app
zed .如果命令不可用，就从 Zed 的菜单里打开项目文件夹。第一次使用时，先确认左侧能看到项目目录，底部状态栏能看到当前文件、分支或诊断提示。
TIP
不要一上来就打开特别大的项目。先用一个小项目熟悉文件查找、终端、Git 和设置。
第二步：用键盘找到文件
Zed 的日常使用重点不是在文件树里一层层点，而是快速跳转。
| 你想做什么 | 推荐动作 |
|---|---|
| 打开已知文件 | Ctrl+P，输入文件名 |
| 找一个命令 | Ctrl+Shift+P，输入关键词 |
| 全项目搜文字 | Ctrl+Shift+F |
| 当前文件内搜索 | Ctrl+F |
| 跳到定义 | F12 或右键菜单 |
| 回到刚才位置 | 使用返回/前进导航命令 |
练习方式很简单：打开项目后，不要用鼠标点文件树，试着只用 Ctrl+P 打开 5 个文件。
第三步：理解主界面分区
第一次看 Zed，不要把它当成 VS Code 的完整复制品。你只需要先记住几个区域：
| 区域 | 用途 | 常见动作 |
|---|---|---|
| 左侧项目面板 | 看文件结构 | 新建、重命名、删除、拖动文件 |
| 中间编辑区 | 写代码、看 diff、看搜索结果 | 分屏、多光标、跳转 |
| 底部终端 | 运行命令 | 启动项目、跑测试、执行 Git 命令 |
| Git 面板 | 看改动和提交 | stage、diff、commit、push |
| Agent 面板 | AI 辅助 | 解释代码、生成改动、检查问题 |
Zed 的强项是把这些区域切换得很快。你可以把“项目面板、终端、Git 面板、Agent 面板”理解成四个工作抽屉，用的时候打开，用完收起。
第四步：改一段代码并看反馈
选择一个小改动，比如改页面标题、函数返回值或 README 文案。
你要观察三件事：
- 编辑器有没有自动补全
- 错误提示有没有出现在代码旁边
- 保存后格式有没有变化
如果你发现没有补全、没有类型提示，通常不是 Zed 坏了，而是项目依赖没装、语言服务没启动，或者这个语言需要扩展。
第五步：打开终端运行项目
按 Ctrl+` 打开内置终端。
常见命令：
npm install
npm run dev
npm test
python main.py
git status如果终端里命令找不到，先在 Windows 自带 PowerShell 里试同一个命令。外部 PowerShell 也找不到，说明是系统环境变量或工具安装问题；外部能找到、Zed 找不到，再检查 Zed 的终端配置。
第六步：做第一次提交
按 Ctrl+Shift+G 或从状态栏打开 Git 面板。
建议第一次提交按这个顺序：
- 先看文件列表，确认改了哪些文件
- 点开 diff，看每一处改动是否符合预期
- 只暂存你准备提交的内容
- 写一条清楚的提交说明
- 提交
Zed 的 Git 面板能直接完成日常提交，但遇到复杂操作，比如 rebase、cherry-pick、修远程分支配置，仍然建议回到终端执行。
第七步：做一份最小配置
先不要复制网上很长的配置。第一小时只建议改这些：
{
"base_keymap": "VSCode",
"buffer_font_family": "Cascadia Code",
"buffer_font_size": 14,
"tab_size": 2,
"format_on_save": "on",
"autosave": {
"after_delay": {
"milliseconds": 1000
}
},
"terminal": {
"working_directory": "current_project_directory"
}
}这份配置的目标是降低迁移成本：快捷键接近 VS Code，字体适合 Windows，保存和格式化行为比较稳定。
第一小时检查清单
- [ ] 能打开一个真实项目
- [ ] 能用
Ctrl+P找文件 - [ ] 能用终端启动项目
- [ ] 能看到代码错误提示
- [ ] 能查看 Git diff
- [ ] 能提交一次改动
- [ ] 能打开设置并保存一份基础配置
完成这些，再继续学习 Git、终端、AI、扩展和任务配置，会顺很多。