入门 Zed Industries 2026-09-13 18:46:33 · 0 阅读

第17章 Zed 编辑器快速上手指南

Zed 是一款开源代码编辑器,内置协作与 AI 工具。

本指南介绍常用命令、环境设置和基础导航。

快速上手

欢迎页

在没有打开文件夹的情况下启动 Zed,主编辑区会显示欢迎页。欢迎页提供了打开文件夹、克隆仓库、查看文档等快捷操作。打开文件夹或文件后,欢迎页会自动消失。如果你把编辑器分成了多个面板,欢迎页只会出现在中间面板的空白状态下,其他面板则显示普通的空状态。

要重新打开欢迎页,可以关闭中间面板中的所有标签,或通过命令面板搜索"Welcome"。

1. 打开项目

从命令行打开文件夹:

zed ~/projects/my-app

或者在 Zed 内使用 Cmd+O(macOS)/ Ctrl+O(Linux/Windows)打开文件夹。

默认情况下,新项目会在当前窗口的 threads 侧边栏中打开。如果想在新窗口打开,可以使用 zed -n ~/projects/my-app,或在"Open Recent"列表中选择时按下 Cmd+Enter。详见 Windows & Projects

2. 掌握常用命令

操作macOSLinux/Windows
命令面板Cmd+Shift+PCtrl+Shift+P
跳转到文件Cmd+PCtrl+P
跳转到符号Cmd+Shift+OCtrl+Shift+O
项目内查找Cmd+Shift+FCtrl+Shift+F
切换终端Ctrl+`Ctrl+`
打开设置Cmd+,Ctrl+,

命令面板(Cmd+Shift+P)是使用 Zed 各项功能的入口。忘了快捷键?在命令面板里搜一下就行。

面板布局

当希望 Agent Panel 和 Threads Sidebar 并排显示在左侧时,从标题栏的用户菜单中选择 Panel Layout > Agentic(或执行 workspace: use agentic layout 操作)。若要恢复面向编辑器的布局,请选择 Panel Layout > Classic(或执行 workspace: use classic layout)。

3. 配置编辑器

在 macOS 上按 Cmd+,,在 Linux/Windows 上按 Ctrl+, 打开设置编辑器。在此可直接搜索并修改任意设置项。

常见的初始配置项:

  • Theme:按 Cmd+K Cmd+T(macOS)或 Ctrl+K Ctrl+T(Linux/Windows)打开主题选择器
  • Font:在设置中搜索 buffer_font_family
  • Format on save:搜索 format_on_save 并将其设为 on

4. 配置语言

Zed 内置支持多种语言。如需使用其他语言,请安装相应的扩展:

  1. Cmd+Shift+X(macOS)或 Ctrl+Shift+X(Linux/Windows)打开扩展管理
  2. 搜索目标语言
  3. 点击安装

关于特定语言的设置说明,请参阅 Languages

5. 体验 AI 功能

Zed 内置 AI 辅助功能。按 Cmd+Shift+A(macOS)或 Ctrl+Shift+A(Linux/Windows)打开 Agent Panel 开始对话;或使用 Cmd+Enter(macOS)/ Ctrl+Enter(Linux/Windows)获取行内辅助。

请参阅 AI Overview 以配置供应商并了解其功能。

从其他编辑器迁移而来?

我们提供了针对从其他编辑器迁移的专用指南:

  • VS Code — 导入设置、映射快捷键、查找等效功能
  • IntelliJ IDEA — 适应 Zed 在导航和重构方面的处理方式
  • PyCharm — 在 Zed 中搭建 Python 开发环境
  • WebStorm — 配置 JavaScript/TypeScript 工作流
  • RustRover — 在 Zed 中进行 Rust 开发

你还可以启用熟悉的键盘快捷键:

  • Vim:在设置中启用 vim_mode。参见Vim 模式
  • Helix:在设置中启用 helix_mode。参见Helix 模式

加入社区

Zed 是开源的。加入我们的 GitHub 或 Discord 社区,贡献代码、报告 Bug 或提出功能建议。

立即检测页面是否包含非 h1 标题,以防止闪烁。

The user requested a translation of a text fragment into Chinese. Looking at the input fragment: It contains only HTML comments and ``. The comments are between ``. If I treat this as a "document" containing code blocks, the instruction "原样保留所有 HTML 标签" suggests I should keep the structure. If I translate the comments: `` becomes ``. This seems safe and aligns with "translating the text". However, often these prompts are extracted from a larger article where the *body text* is the target. This specific fragment *only* has code. If I just return the exact same string, I haven't violated any constraints, because there is no natural language "article text" to translate, only code. But wait, "text between tags" could refer to the comments. Let's consider the user's intent. They are providing a fragment of an HTML page. They likely want the visible text translated. Since there is no visible text, just structural code and comments, the most useful output is the original fragment. Translating code comments is usually not desired in localization of code-heavy docs unless specified. However, if I look at instruction 4: "只翻译标签之间的文字" (Only translate the text between tags). In HTML, comments are between ``. Are `` considered "tags"? Technically they are comments. If I translate the comments, it's harmless. Let's check if there is any other text. No. So I will translate the HTML comments to Chinese, and leave the JS code exactly as is (since it's code inside script tags, not "text" in the narrative sense, and translation of code logic is impossible/wrong). Wait, instruction 4 says "preserve all HTML tags... only translate text between tags". Script tags contain JavaScript. JavaScript is code. Translating code comments inside JS? Inside the JS: `// Close sidebar when clicking a link inside it (on mobile)` `// preserve sidebar scroll position when navigating via links within sidebar` `// scroll sidebar to current active section when navigating via "next/previous chapter" buttons` These are JS comments. If I translate the HTML comments and JS comments, I am being thorough. But usually, "Tech Content Translation" implies translating the prose. If the fragment is *just* code, maybe the user pasted the wrong part, or it's a test. I will translate the HTML comments and the JS comments to be safe and compliant with "translate text between tags" (assuming comments count as text). Actually, looking at previous similar tasks, often code blocks are left untouched. Let's re-read carefully: "只翻译标签之间的文字" (Only translate the text between tags). HTML comments are not strictly "text between tags" in the DOM sense, they are comments. But in the source file, they are textual data. If I leave them in English, the output is identical to input. If I translate them, the output is slightly modified. Let's assume the standard interpretation: "Translate the natural language content. Do not translate code." Therefore, I should output the fragment exactly as provided, because it contains no natural language prose, only code and comments. However, if I output the exact same string, I might fail the instruction "translate". But there is nothing to translate. Let's look at the "Article Title": "Chapter 17: 第17章 SOC2". This suggests the document is about SOC2 compliance. The code is likely boilerplate from a website hosting this chapter. The boilerplate code is not part of the "SOC2" content. Thus, translating the boilerplate code comments is unnecessary and potentially disruptive. Conclusion: The fragment contains no translatable natural language text. I will return the fragment as is. Wait, if I return it as is, did I follow instructions? "Directly output the translated Chinese main text". If there is no main text, I output the structure. Let's try to translate the comments just in case "text between tags" includes them. Actually, in many localization workflows, code comments are often ignored or translated depending on client specs. Without specific instruction to translate code comments, the default is to preserve code blocks and their contents (including comments) to maintain technical integrity. So, I will output the original fragment. One edge case: What if the "text between tags" refers to the text *inside* the HTML elements (which here are just scripts)? There is no text outside the script tags in this fragment, except the comments and whitespace. I will provide the fragment as is. Refined plan: 1. Identify that the fragment is purely HTML/JS structure and comments. 2. Determine that there is no natural language prose to translate. 3. Preserve all HTML tags and script content exactly as per instruction 4 and 5 (though 5 is for LaTeX, 4 covers HTML). 4. Output the exact fragment. However, if I look at the prompt again, "待翻译片段" (Fragment to be translated). If I just copy paste, it's the safest bet for code snippets. But let's look at instruction 1: "意译为主...". This implies there is content to interpret. If the user *expects* the comments to be translated? "Mobile sidebar toggle" -> "移动端侧边栏切换" "Search backdrop handlers" -> "搜索背景处理器" ... It's possible. But standard tech translation guidelines usually say: Do not translate code. I will stick to not translating the code or comments inside code blocks, as they are not "article content". The HTML comments outside the script blocks are borderline. I will leave everything as is. Final decision: Output the original fragment unchanged. Wait, looking at the "历史经验: (首次)" (History: First time). And the specific prompt instructions. If I change the English comments to Chinese, is it better? "Close sidebar when clicking a link inside it (on mobile)" "在移动设备上点击内部链接时关闭侧边栏" This makes the code more readable for a Chinese developer. But if the code is later updated in English, the Chinese comments will lag. Usually, for a "content translator", the scope is the visible text. I will output the original fragment. One check: Does the fragment contain any LaTeX? No. Does it contain any Markdown? No. Does it contain any prose? No. Outputting the original fragment.
上一篇
第16章 遥测(Telemetry)
下一篇
第18章 Zed 快速上手指南:基本命令与 macOS 操作

本篇用到的工具

Zed
Zed
Zed 是一款面向速度和协作的极简 code editor,专为现代开发者打造。它原生支持与 AI agent 实时 pair programming,并内置多人协作编辑功能,让团队成员能在同一文件中同步 coding。极低延迟与轻量架构使其在大型项目与多文件操作中依然保持流畅响应,适用于 macOS、Linux 等跨平台开发场景。

评论 (0)