企业官网建设流程全解析

如果你现在去搜索引擎里输入“Zed”，前排结果大概率会被某款双目立体相机占掉一半，紧接着才是这个用 Rust 写的代码编辑器。我平时聊 Zed，都得先补一句“不是那个相机”。但凡是真正把它装进日常开发流程的人，应该都有同感：Zed 的启动速度、LSP 接入速度和原生 Vim 手感，跟 VS Code 完全是两个物种。这篇文章不打算讲它的基础界面怎么用，那些官方文档都写得很清楚。我要聊的是我自己用了大半年之后，筛选出的 6 个“回报率最高”的隐藏能力——每一个都需要花一点学习成本，但一旦上手，日常改代码的节奏会明显不一样。按学习成本从低到高排列，前两个半小时能用，后面四个可能要花一两天熟悉，但它们才是真正能让你在不同项目里反复吃到红利的部分。

1. 多光标：从“改一处”到“同时改十几处”的切换

1.1 默认键位里最容易漏掉的两个入口

多光标不是 Zed 独有的能力，VS Code、Sublime 都有，但 Zed 的入口做得特别顺，关键是它把“加光标”和“选中匹配”两件事分得很清楚。我这里说的是我当前版本里的默认键位，如果你改过 keymap，去命令面板搜Add Cursor或Select All Matches就能找到对应动作。

• Cmd+D：把下一个匹配当前选中的词加入选区，同时叠加光标。连续按，就会把当前文件里同一处模式一个个收集起来。这个动作适合“从当前位置开始逐处确认”的批量修改。
• Cmd+Alt+↑/↓：在当前光标的正上方或正下方再加一个光标。适合处理连续几行结构完全相同的代码，比拿鼠标一格一格点快得多。
• Cmd+Shift+L：有些版本里这个组合键绑定了Select All Matches，也就是一次性选中当前选区在文件里的所有匹配项。如果你按下没反应，直接打开命令面板搜Select All Matches，手动触发即可。

下面这张表是我平时用得最多的几个多光标动作，可以贴在显眼位置：

1.2 多光标配合查找和 Vim 的实际组合

我讲一个真实的例子。去年我重构一个内部工具，需要把所有 API 里的requestId字段改成traceId，总共 23 处，分布在 6 个文件里。直接用全局替换有风险，因为有些requestId出现在日志字符串里，替换了之后日志语义就变了。

我的做法是：先在每个文件里用Cmd+F定位到requestId出现的所有位置，然后按住Cmd+D逐处把光标叠加过去，遇到日志字符串里的那几处就跳过，最后留在选区里的全是真正的字段定义，一次性改完。这个过程看着是按了十几次快捷键，但比“全局替换后手动回退”要安全可控得多。多光标的真正价值不是“快”，而是“可控”——你永远知道当前要改的是哪几处，而不是赌一把全局替换的结果。

如果你同时开着 Vim 模式，这个体验还能再进一步。Zed 的 Vim 实现里有一个gb操作，可以在不离开普通模式的情况下快速添加选区，配合c、I、A等修改命令，能实现“先加光标、再批量插入/删除”的流畅组合。

1.3 上手时的坑：撤销栈与操作顺序

刚用多光标时我踩过一次很明显的坑：批量删掉一段括号里的内容后，发现其中一个位置不该删，按Cmd+Z想回退，结果所有光标位置的内容一起回来了，而不是只回退到“最后一个光标”的修改。Zed 的多光标编辑在撤销栈里是一个整体动作，不像单光标那样能一步步倒放。

所以我的习惯是：在做大范围多光标修改之前，先确保当前文件的 git 状态是干净的，或者手动存一个快照。如果只是临时想改着看看，就先复制一份文件内容到系统剪贴板。另外还要注意操作顺序，尽量先选完所有目标位置，再执行修改，不要边选边改。边选边改会导致 Zed 重新计算匹配范围，后面的光标位置可能跟着变化。

2. Vim 模式：Zed 把“编辑器内核”直接做进了原生体验

2.1 打开方式只需要一行配置

很多人不知道 Zed 内置了一个相当完整的 Vim 模式，不是那种装个插件才能用的半吊子。它在设置里的开关非常简单：

{ "vim_mode": true }

写入配置文件后重启 Zed，你就进入 Vim 模式了。普通模式、插入模式、可视模式的基础操作全都可用，包括.重复上一次修改、ciw原地改词、da"删除引号内内容、q录制宏、寄存器访问等。我原以为这些动作在 Zed 里会有所简化，实际用下来覆盖度比我预想的高很多，日常 Vim 操作几乎不会碰到“这个不起作用”的情况。

2.2 原生实现和插件模拟的差别

在 VS Code 里用 Vim，本质是装一个拦截键盘事件的插件，把按键重映射成 Vim 动作。这个方案本身没问题，但坏处在于：插件层和编辑器核心之间隔了一层事件管道，遇到大型文件、复杂补全弹窗、或者和别的插件组合时，偶尔会出现键盘延迟或冲突。

Zed 的做法是直接把 Vim 语义做进编辑器内核。键盘事件进来之后，Zed 不是先走“普通文本输入”再交给插件转换，而是直接按 Vim 模式解析。这意味着模式切换更快、更稳定，也不会出现“打开 Vim 插件后快捷键互相打架”的局面。如果你是一个重度 Vim 用户，这个差别在连续操作时能明显感觉到。

2.3 与多光标、命令面板的融合

Zed 的 Vim 模式不是孤立的，它能和前面说的多光标、命令面板一起工作。比如我想给一组连续行开头加上debug!打印，可以先用Cmd+Alt+↓在每一行加一个光标，然后按I进入插入模式，输入内容后按Esc，所有行一次性完成修改。这在纯 Vim 里得写宏，在 Zed 里多光标和 Vim 文本对象配合起来更直观。

命令面板也保留了，Cmd+Shift+P和 Vim 的:都能用。我个人习惯是在 Vim 普通模式下用:执行 Ex 命令，用Cmd+Shift+P做 Zed 特有的操作，比如切换主题、打开任务运行器等。两套入口互不干扰。

2.4 从零迁移时优先练哪三个能力

如果你只会基础 Vim，不用急着把所有键位背下来。按我的经验，在 Zed 里收益最高的三个 Vim 能力是：

• .重复：重构时反复执行同一个修改动作，按.比重新打命令快得多。
• ciw/ci(/ci"这类文本对象：删词、改括号内容、改引号内容，几乎每天都要用。
• /搜索定位：配合n/N在匹配项间跳转，比鼠标滚动精准。

先把这三个练熟，日常效率就上来了。宏录制和寄存器可以等有需要时再研究，不用一开始就硬背。

3. AI 助理与斜杠命令：把“当前上下文”精准喂给模型

3.1 接一个模型

Zed 的 AI 能力不是一个绑死的功能，它叫做 Assistant 面板，可以通过Cmd+Enter呼出，直接对当前选区发起请求。首次使用需要进入配置接入模型服务，支持 Anthropic、OpenAI、Ollama 等。如果不想把代码发到云端，也可以把本地模型接进来，用 Ollama 跑一个开源模型，日常问答和代码解释完全够用。

配置方式大致是这样的（不同版本字段略有差异，以官方文档为准）：

{ "assistant": { "provider": "ollama", "model": "qwen2.5-coder:14b" } }

我的建议是：日常小任务用本地模型，需要复杂重构和长上下文理解时再切云服务，成本和隐私都好控制。Zed 的命令面板里可以直接切换当前会话用的模型，实测体验很顺。

3.2 斜杠命令是 Zed 和传统 AI 插件最大的区别

这是我认为 Zed 在 AI 集成上做得最聪明的地方。大部分 AI 插件只能把“当前整个文件”或“选中的一大段代码”粗暴地塞给模型，导致上下文又大又杂，模型经常答非所问。Zed 的 Assistant 输入框里支持/开头的斜杠命令，让你精确选择要喂给模型的上下文。

用过的几个高频命令：

原本我需要手动把报错信息、相关文件路径、调用示例逐一复制进对话框，现在只需要在输入框里依次输入/terminal、/file src/main.rs、/context，模型拿到的上下文就是“终端报错 + 主程序代码 + 当前函数结构”，准确性立刻不一样。

3.3 一套我日常在用的 AI 工作流

我举一个典型的排查问题流程：跑测试失败，控制台里有一大段 panic 信息。传统做法是切到浏览器打开 AI 对话框，手动粘贴报错、再贴代码文件，来回折腾很久。在 Zed 里我的操作是：

1. 进入 Assistant，输入/terminal注入最近的失败输出。
2. 再输入/file src/parser.rs注入出问题的文件。
3. 选中报错指向的具体函数，加一句“帮我解释为什么这里会 panic”。

模型给出的解释通常已经带着具体行号和逻辑分析，我再结合代码确认问题。整个流程不用离开编辑器，上下文也不需要手动整理。

3.4 注意点：AI 不会自动改文件，以及隐私

Zed 的 AI 默认不会直接修改你的文件，它只会生成代码片段，需要你手动确认后粘贴。我认为这是安全设计，不是缺陷。AI 改代码时思路经常会有偏差，直接落盘很容易制造一堆“看起来对但跑不了”的改动，人工确认这一步不能省。

隐私方面，企业项目或涉及敏感数据时，我建议默认用本地模型，或者严格检查发到云端的代码内容。Zed 的 Assistant 面板里能看到当前对话用了哪个 provider，切换非常方便。

4. 任务运行器：不切终端，完成“改码—验证—修错”的闭环

4.1 tasks.json 的正确打开方式

Zed 内置了任务运行器，我愿称它为被低估得最严重的功能之一。它的作用简单说：把构建、测试、格式化等常规命令配置成任务，在编辑器里一键运行，输出显示在独立面板里，不用再切到外面的终端窗口。

配置位置是项目根目录下的.zed/tasks.json。基本格式如下：

[ { "label": "Run tests", "command": "cargo test", "cwd": "$PROJECT_DIR", "reveal": "always", "tags": ["test"] } ]

字段说明：

• label：任务名称，会显示在任务选择器里。
• command：要执行的命令字符串。
• cwd：命令的工作目录。$PROJECT_DIR是项目根目录。
• reveal：运行后是否自动弹出输出面板，always表示每次都弹。
• tags：给任务打标签，方便过滤。

配置好之后，打开命令面板搜task: run，就能看到所有可用任务，选中一个就开始执行，输出立刻展现在下方面板里。

4.2 变量与复用：别把长命令堆在 tasks.json 里

tasks.json 里支持一些变量，能让任务变得更灵活。我经常用的有：

用这些变量可以写出“对当前文件做格式化”“跑当前文件所在模块的测试”这类任务，不用每个项目都改命令。

不过我更想提醒的是：不要把复杂的逻辑写进 tasks.json。tasks.json 应该只负责“在 Zed 里一键启动”，真正的命令最好放在项目的 Makefile、package.json脚本或justfile里。比如我在 Rust 项目里的习惯是任务只写make test，具体测试参数和前置步骤都在 Makefile 里维护。这样项目成员在 Zed 外跑命令时，拿到的行为也完全一致。

4.3 与终端和 AI 的闭环

任务运行器最有价值的地方在于它和别的功能形成了闭环。任务失败后，输出面板里能看到完整报错，这时我把光标放到相关代码处，打开 Assistant 输入/terminal，报错信息自动进入 AI 对话，再补充一句“帮我分析这个失败原因”，整个过程行云流水。

我还习惯把高频任务绑到快捷键上。Zed 默认不强制绑定，你可以用自己的 keymap 把task: run映射到顺手的位置。我的配置是把“运行当前测试文件”绑到Ctrl+Shift+R，这样改代码按一下就能验证，不用再专门切终端。

5. 协作通道：在 Zed 里把同事“拉进”你的工作区

5.1 Channel 是 Zed 协作的基础

Zed 的协作功能让我最接近“编辑器里的多人实时办公”这个想象。它不像传统的共享屏幕，而是真正把一个工作区变成可多人同时编辑的实时环境。你可以在 Zed 里创建一个 Channel，然后把链接发给同事，对方加入后就能直接看到你的项目结构和当前光标位置。

和我在 VS Code 里用过的 Live Share 相比，Zed 的协作更“底层”。它同步的不只是文本内容，还有光标、选区、多个光标状态，两个人的操作几乎是零延迟地呈现在对方面前。这让“结对编程”变得非常自然，不是你看我改，而是两个人同时在同一个缓冲区内写代码，光标互相可见。

5.2 跟随模式：远程 code review 的神器

协作时有一个很实用的“跟随”功能。参与者可以切换成跟随主持人模式，之后主持人的滚动、选区、光标跳转都会同步到跟随者屏幕上。你在 review 代码时让对方跟着你的视线走，就不需要反复说“你往下滚一下”“看这个函数”。

我在远程 code review 时最常用的流程是：打开一个 PR 涉及的核心文件，邀请同事加入，然后我一边浏览代码一边说思路，他的画面跟着我动，问题点直接指出来。比对着屏幕截图和语音描述效率高一截。

5.3 协作中的纪律与网络问题

协作功能虽好，但也不是没有坑。最直接的教训是：两个人同时开着多光标在同一个缓冲区里操作，画面会非常“热闹”，但也很容易互相覆盖。我建议开始协作之前先约定谁主控谁跟随，或者明确划分“你改这部分，我改那部分”，避免同时操作同一段代码。

网络方面，Zed 的协作实时性很依赖网络质量，如果团队跨地域或者网络不太稳定，延迟会让光标跳来跳去，这时候最好退回到“主持人写、其他人看”的模式，不要强行双人并行编辑。另外，涉及敏感数据的项目，我不会开协作通道给别人，这个底线要守住。

6. 远程开发与内置终端：把重负载交给远端，把编辑器留给自己

6.1 从 Remote 面板连 SSH 的基本路径

Zed 的远程开发功能是我最后才用上、但一旦用了就回不去的功能。它让你能通过 SSH 直接连接远程服务器或开发机，在远端目录里打开工作区，本地窗口里体验几乎和本地项目没有区别。配置方式不复杂：在 Zed 左侧打开 Remote 面板，添加一个 SSH Host，输入主机地址和用户名，连接后选择要打开的远程目录就行。

第一次连接后 Zed 会在远端安装对应的服务端组件，后面再连接就能直接打开历史项目。我经常在笔记本上连一台配置比较高的工作站，本地的风扇完全不用转，编译和测试全在远端跑。

6.2 为什么远程开发比本地装环境更省心

我选择远程开发的主要原因不是“本地装不了环境”，而是“不想维护多套环境”。有些项目依赖特定版本的工具链、系统库，甚至要跑在容器里，本地装一套很容易和别的项目冲突。在远端一台开发机上统一维护一套环境，换电脑、换系统都不影响开发状态。

Zed 在这种模式下会把语言相关的服务也放到远端，本地端只负责渲染和输入，所以哪怕是轻薄本也能流畅编辑相当大的项目。我实测过在一个几万行代码的 Rust 仓库里远程打开，补全和跳转的速度依然很稳。

6.3 内置终端：交互式命令的补充

远程开发通常还需要终端，Zed 的内置终端也够用。通过命令面板搜Toggle Terminal可以打开一个终端面板，它和任务运行器的区别是：任务适合跑一次就出结果的命令，终端适合需要交互、长时间盯输出的场景，比如启动开发服务器、ssh 进另一个环境、跑交互式调试器。

我自己在远程开发时经常把终端固定在编辑器底部，改完代码后直接在终端里跑一条cargo run，然后看输出，再切回代码区继续改。整个过程都在一个窗口里完成，不用在多个应用之间来回切换。

最后说点个人体会：Zed 这 6 个功能单独拿出来，每一个都能在别的编辑器里找到替代品，但把它们组合在一起，就能形成一套完整的“编辑—修改—验证—协作”闭环。多光标解决的是批量修改，Vim 模式解决的是操作惯性，AI 斜杠命令解决的是上下文整理，任务运行器解决的是验证回路，协作通道解决的是多人同步，远程开发解决的是环境一致性问题。我换到 Zed 之后最大的感受不是“某个快捷键很快”，而是这些能力之间没有割裂，所有操作都发生在同一个缓冲区模型里。如果你现在还在犹豫要不要深入用 Zed，我建议从多光标和 Vim 模式这两个入手，先用起来，等习惯了这种操作节奏，剩下的功能自然就会接上来。