我从VSCode转投Zed

最严重的问题是VSCode变得越来越不稳定，运行明显变慢，频繁崩溃——考虑到Copilot新功能的发布速度，这也不足为奇。

💬 401 条评论 | zed/VSCode| 2026-01-07

多年来，VSCode一直是我日常使用的全能IDE：Python、Go、C语言、偶尔的前端开发等等。它虽非完美，但始终可靠。我偏爱配置简易的主流工具，因此它曾是我的完美搭档。但近期VSCode的改动迫使我另寻出路。去年12月我彻底转投Zed阵营，此后再无回头路。

告别VSCode

VSCode曾给我以稳定可靠的印象，但AI时代的到来彻底改变了这一切。如今每次更新都伴随着新的人工智能功能，我不得不费心寻找关闭方式。举几个例子：我不使用Github Copilot。我偏好的AI工具是命令行界面(近期使用Codex)。因此我禁用了Copilot，但VSCode仍强行推送该功能。某次更新后，编辑行内竟出现“cmd+I继续使用Copilot”提示。另次更新又新增内联终端建议，直接干扰我的shell命令输入。还有其他几处类似的侵入性操作，现在记不清了。

于是我的settings.json变成了一个禁用项清单。这我还能忍受。但最严重的问题是VSCode变得越来越不稳定，运行明显变慢，频繁崩溃——考虑到Copilot新功能的发布速度，这也不足为奇。

我依然认为VSCode是卓越的IDE，并感谢所有维护者和最出色的扩展社区。期待VSCode的AI集成方式能变得更少侵入性、更周全，系统趋于稳定，让VSCode重新实现“开箱即用”。但此刻，是时候寻找其他选择。

我明确不愿转向JetBrains系列IDE。它们功能强大却略显笨重，使用体验欠佳。Vim、Emacs及其现代变体则截然相反——或许退休后有充足时间配置学习，它们会成为理想选择。而Zed这个仅知其为Rust语言编写的现代轻量IDE的工具，便成了我的尝试对象。

Zed：初体验

从VSCode切换到Zed时，我立刻感到宾至如归。界面布局相似，默认键位映射也基本一致。对我而言最大的用户体验差异在于：VSCode将打开的文件(即编辑器)显示在左侧边栏，我常以此进行导航。而Zed没有此类面板，推荐使用文件搜索(Cmd+P)进行导航。不过可以自动导入VSCode设置。我选择从零开始，因此未启用该功能。唯一需要调整的配置是：修改字体大小和主题、禁用内联Git blame功能、开启自动保存。

Zed给我最深刻的印象是其相较VSCode的迅捷响应速度。甚至让我注意到其他工具的迟缓表现——这些工具我已习惯使用，并进行了优化。另一亮点是过去两周Zed运行稳定，未出现任何故障或崩溃。这一切让我重拾编程的乐趣。

我主要用Python编程，偶尔使用Go语言。Go语言支持开箱即用，无需额外配置；而Python则没那么顺利，我花了半天时间才让它正常工作。下面是些枯燥的细节，真希望当初就知道这些。

让Zed支持Python

先说明背景：Zed作为集成开发环境，依赖语言服务器提供自动补全、代码导航、类型检查等语言特性。它原生支持多种Python语言服务器。其中之一是Pyright，但其作为语言服务器的功能有限——它主要作为类型检查器，供其他语言服务器构建使用。例如微软开发的Pylance就是基于Pyright构建的语言服务器。Pylance虽是使用最广泛的Python语言服务器，但因其非开源性质，仅限于VSCode环境使用。Zed编辑器则默认采用Basedpyright作为语言服务器。

在Zed中打开Python项目时，我首先遇到的问题是代码中大量类型检查器错误被高亮显示。显然Basedpyright以更严格的typeCheckingMode运行。而我以往配置Pyright时未指定typeCheckingMode，默认采用standard模式。Zed文档说明称”虽然Basedpyright单独使用时默认采用recommended类型检查模式，但Zed默认配置为使用宽松的standard模式，这与Pyright的行为一致。这让我感到困惑，因为我确实见过它在recommended模式下正常工作。

我尝试在 settings.json 中显式指定 typeCheckingMode 如文档所示：

// ...
"lsp": {
    "basedpyright": {
      "settings": {
        "basedpyright.analysis": {
          "typeCheckingMode": "standard"
        }
      }
    }
  }
// ...

但这并未奏效。仍有大量我不希望检查的类型错误。最终发现只要存在包含[tool.pyright]节的pyproject.toml文件，Basedpyright就会默认使用typeCheckingMode = “recommended”。我的解决方案是在每个pyproject.toml中显式设置typeCheckingMode = “standard”。这个解决方案耗费了我大量时间——我发现多个GitHub问题报告都提到语言服务器设置被忽略或未按预期工作，因此最初以为是bug。现在看来这其实是设计使然，只是文档未明确说明。经验教训：若定义了[tool.pyright]，切勿依赖Pyright默认值，务必显式设置选项。

随后我注意到编辑代码时，文件未显示新的输入错误提示，直到我修改该文件后才出现。例如当某个符号被删除却仍在其他文件中使用时，我希望立即看到此类错误提示。通过在 settings.json 中设置 “disablePullDiagnostics”: true解决了这个问题：

// ...
  "lsp": {
    "basedpyright": {
      "initialization_options": {
        "disablePullDiagnostics": true
      },
    }
  }
// ...

基本就是这样。虚拟环境检测及其他Python特性的适配都很顺利。期间我还尝试过用ty替代Basedpyright——后者刚宣布进入Beta阶段。ty从一开始就运行良好。我最终仍选择Basedpyright，因为CI环境运行Pyright，我希望本地保持一致的类型检查器。但鉴于ruff和uv的成功，我(以及其他人)很有可能在开发和CI中都转向ty。

总结

Zed现已成为我处理Python和Go的首选IDE，也是通用编辑器的首选。它运行迅捷、稳定可靠、界面熟悉、功能丰富，开箱即用体验出色。虽然Zed的扩展生态远不及VSCode庞大，但完全满足我的需求。唯一缺憾是缺少像GitLens那样支持并排对比的强大Git差异查看器。

Zed的AI功能虽在持续开发中，但可轻松忽略且不影响使用。其提供的付费方案可实现编辑预测功能，这似乎是维持项目发展的良策。衷心祝愿Zed前程似锦！

至于VSCode，它终于迎来强劲对手，微软的优势可能不足以维持其主导地位。VSCode，该醒醒了！

最后附上我的Zed设置文件完整内容：

{
  "autosave": "on_focus_change",
  "git": {
    "inline_blame": {
      "enabled": false
    }
  },
  "icon_theme": {
    "mode": "light",
    "light": "Zed (Default)",
    "dark": "Zed (Default)"
  },
  "base_keymap": "VSCode",
  "ui_font_size": 22,
  "buffer_font_size": 18,
  "theme": {
    "mode": "light",
    "light": "One Light",
    "dark": "One Dark"
  },
  "lsp": {
    "basedpyright": {
      "initialization_options": {
        "disablePullDiagnostics": true
      },
      "settings": {
        "basedpyright.analysis": {
          // Won't take affect if pyproject.toml has `[tool.pyright]`
          "typeCheckingMode": "standard"
        }
      }
    }
  },
  "languages": {
    "Python": {
      "language_servers": ["!ty", "basedpyright", "..."]
    }
  }
}

本文由 TecHug 分享，英文原文及文中图片来自 I switched from VSCode to Zed。

共有{401}条精彩评论

bpasero说道：

2026-01-07

我们维护了一个VS Code设置项，可让您选择退出VS Code提供的AI功能：“chat.disableAIFeatures”(另见：https://code.visualstudio.com/updates/v1_104#_hide-and-disab…)。若配置该设置后仍出现AI功能，请通过https://github.com/microsoft/vscode提交问题报告，我们将及时处理。

偶尔可能出现未遵循该设置的新AI功能，但我们会尽力尽快修复。

感谢！Ben(VS Code团队)

回复
1. lioeters说道：
  
  2026-01-07
  
  赞！VS Code通过单一设置即可禁用所有AI功能的做法值得尊敬，这彰显了对用户选择权和自主性的重视。考虑到近期品牌重塑为“开源AI代码编辑器”，为新老用户提供不使用AI的选择权意义重大。
  
  当前在大型语言模型整合成为管理层和投资者热捧的新趋势时，许多公司和产品显然难以做到这一点。当人工智能渗透到工作、生活、计算、商业和治理等其他领域时，开发者、用户和公民理应获得拒绝使用人工智能功能的尊重与权利。
  
  回复
  1. blks说道：
    
    2026-01-07
    
    当他们如此定位品牌时，对厌恶“AI”的人群而言就是明确的拒用信号。Zed如今提供部分AI功能的退出机制，正是我彻底放弃重新尝试使用它的原因之一。
    
    Emacs仍是我的首选。
    
    回复
  2. echelon说道：
    
    2026-01-07
    
    在此补充：我们应当支持小型企业。当巨头掌控关键技术领域的过多表面积时，其响应速度再快也无济于事。
    
    行业巨头霸权有害无益。VSCode、谷歌搜索+Chrome、手机双寡头、亚马逊/AWS/MGM/全食超市/TeleDoc的跨界垄断…这些都无关紧要。我们需要更分散的权力格局。
    
    回复
    1. yndoendo说道：
      
      2026-01-07
      
      趣闻一则。
      
      我从不光顾任何挂着华尔街股票代码的餐厅。希望更多人效仿——与其资助华尔街CEO，不如支持本地社区更能造福大众。
      
      附注：若想使用微软产品或与亚马逊互动，必须付费给我。
      
      回复
      1. dijit说道：
        
        2026-01-07
        
        这其实颇具讽刺意味。
        
        若我理解正确，“股东”制度本是让无力全资创业者获得企业部分所有权的途径。
        
        其理念与合作社如出一辙。
        
        在这些模式中，CEO本质上只是股东雇佣的员工。
        
        颇具讽刺意味的是，我们看到上市公司CEO的待遇竟不如个体经营者——毕竟利润会直接流向个体经营者，却不会流向股东CEO。
        
        我理解现实发展轨迹：当今全球最大企业皆为上市公司，其CEO薪酬也已失控。但这种演变过程在我看来充满荒诞。
        
        回复
        
        coldtea说道：
        
        2026-01-07
        
        >当利润直接归属个体经营者时，上市公司CEO的处境竟不如个体经营者——但股东CEO却无法享受同等待遇，这实在耐人寻味。
        
        秉持与原帖相同的思维，我们完全接受利润直接归属个体经营者。
        
        事实上，我们追求的是利润背后的个人名号，而非空洞的职位头衔。
        
        我们并非反对盈利。
        
        我们反对的是那些平庸的企业领导者——他们既无声誉风险，又与公司毫无个人羁绊(往往还免于财务风险，参见“黄金降落伞”)，其唯一使命就是最大化利润，对产品、客户乃至企业传承置之不理。
        
        回复
        
        thaneross说道：
        
        2026-01-07
        
        鉴于前10%持有人掌控87%的股份，股市本质上显然是财富复利的工具。持有过剩资金才是参与游戏的最低门槛。
        
        回复
        
        gosub100说道：
        
        2026-01-07
        
        不仅如此，若真是“企业股权的零碎持有”，所有盈利公司都应派发股息。如今却以各种花哨理由将不派息常态化。
        
        回复
        
        Majromax说道：
        
        2026-01-07
        
        股票回购同样是向股东返还现金流的途径。回购本质等同于分红，只是在默认“不作为”情况下自动实现再投资。
        
        若计入回购，鲜有大型成熟企业完全不向股东分配利润；而成长型或初创企业保留盈余用于投资，恰是我们通常所期望的。
        
        回复
        
        gosub100说道：
        
        2026-01-07
        
        你不过是在复述我已提过的“花哨理论”。所有这些玄奥操作的本质，就是将财富集中到富人手中。这不过是分权所有制走向终结的一步。
        
        回复
        
        limagnolia说道：
        
        2026-01-07
        
        这没什么花哨的。从股东角度看，其逻辑直截了当，且与派发股息具有完全相同的效应。(实际上某些方面或许更优，因为它能更轻松地应对愚蠢的税法)
        
        回复
      2. DoctorOW说道：
        
        2026-01-07
        
        我最近搬到威斯康星州，觉得只买本地产品才合乎情理。确实味道更佳，但更意外的是价格竟更便宜。看来食物里掺多少塑料木屑都无所谓——只要你愿意为多运一百英里买单。
        
        回复
      3. seoulbigchris说道：
        
        2026-01-07
        
        起初我还以为你说的是那种墙上挂着滚动行情屏的餐厅，让食客边用餐边看股市行情。
        
        回复
      4. dangus说道：
        
        2026-01-07
        
        除非从我冰冷僵硬的手里撬走芝士蛋糕工厂的棕面包和橄榄园的意式面包棒。
        
        回复
        
        coldtea说道：
        
        2026-01-07
        
        若带着这些东西死在冰冷僵硬的手里，却从未知晓世上存在更优选择，岂非遗憾？
        
        回复
        
        dangus说道：
        
        2026-01-07
        
        我当然知道存在更优选择。我光顾过多家米其林二星餐厅，绝非炫耀。
        
        但这种“抵制大企业”的思维往往只是空洞的势利——“我比你高尚，因为我不支持邪恶大企业”。
        
        当然企业并非生而平等，无论规模大小或公私性质。有些经营得当且道德规范，有些则不然。
        
        我敢说，那些做见不得光勾当的小本生意，比任何上市公司都多。
        
        你知道吗？小型房东根本不受平等住房法的约束——这就是所谓的“墨菲夫人豁免条款”。
        
        走进奥利弗花园餐厅，我清楚知道每家分店体验完全一致，设施配置一目了然，价格也心知肚明。
        
        尽管芝士蛋糕工厂是上市公司，但他们在厨房准备和店内烹饪方面做得比我常去的酒吧烧烤店更扎实——后者不过是加热预制食品而已。
        
        回复
        
        coldtea说道：
        
        2026-01-07
        
        问题不在于“企业本质恶劣”，而在于这两家店食物难吃得堪称典范。这已超越任何不正当操作的范畴(反正不是我们讨论的重点)。
        
        至少橄榄园和芝士蛋糕工厂做得更好。
        
        回复
        
        cdelsolar说道：
        
        2026-01-07
        
        告诉我比橄榄园面包棒更美味的东西
        
        回复
        
        coldtea说道：
        
        2026-01-07
        
        任何像样的意大利餐厅的蒜香面包？
        
        回复
        
        roland35说道：
        
        2026-01-07
        
        面包棒还是无乳制品的！对我这个乳糖不耐受的胃来说简直是惊人的福音
        
        回复
        
        dangus说道：
        
        2026-01-07
        
        蘸着永不枯竭的番茄酱、五种奶酪酱和阿尔弗雷多酱享用。
        
        回复
2. colbythrowaway说道：
  
  2026-01-07
  
  嘿，本。
  
  我最近(不到两个月前)对许可证合规性进行了深入分析，发现微软及其他许多发布Electron应用的公司并未遵守LGPL协议。(种种迹象表明，Electron项目组似乎甚至不知其产品受LGPL约束——尽管事实确是如此。就连未违反许可的Slack，其合规性也仅是偶然达成：因其同时分发了其他明确标注LGPL的组件。)
  
  我原定于数周后(11月底)离职，实际也已离职，因此自离开后我的调查/发现未再有进展。我尚未准备或发布正式报告，仅在半公开场合提及过一次。但此事影响重大。能否请您向微软法务部门(非Electron/GitHub团队)反映此事并建议他们介入调查？
  
  回复
  1. intern4tional说道：
    
    2026-01-07
    
    若此事属实且您有权分享前任职单位的工作成果，应直接联系微软法务部门。
    
    通过Hacker News随机工程师渠道并非正当途径。
    
    链接：https://www.microsoft.com/en-us/legal/compliance/sbc/report-…
    
    回复
    1. rstuart4133说道：
      
      2026-01-07
      
      我再举个例子。“Microsoft Tunnel Gateway”是微软InTune VPN的终端节点，可从以下链接下载Linux版Docker镜像：https://learn.microsoft.com/en-us/intune/intune-service/prot…
      
      我简单查看了该Docker镜像，它显然是OpenConnect的重新打包版本。Debian的版权声明(链接自https://packages.debian.org/sid/openconnect)表明其主要采用LGPL许可，但同时包含GPL等多项其他许可。
      
      由于存在GPL许可，他们必须公开部分源代码；若进行修改，则根据LGPL要求必须公开修改内容。他们通过添加微软认证机制进行了扩展，但这可能只是DDL混合功能，我完全理解/原谅他们可能未意识到其他许可证的存在。
      
      难以原谅的是，他们完全不承认自己使用了开源资源。反而贴上了标准的微软许可声明，声称所有内容都是他们自己的作品，类似于这个链接：https://support.microsoft.com/en-us/office/microsoft-softwar…
      
      回复
    2. z3dd说道：
      
      2026-01-07
      
      这纯粹是博眼球，难以想象在微软工作过的人，如今最好的社交对象竟是Reddit上某个陌生人。
      
      回复
      1. riffraff说道：
        
        2026-01-07
        
        GGP并未声称曾在微软工作，评论内容确实有些晦涩，但他们写道“我离开了曾供职的公司”。
        
        回复
        
        pwdisswordfishy说道：
        
        2026-01-07
        
        细节确实匮乏，但晦涩倒不至于。
        
        问题在于，本帖讨论似乎采取了一种中间立场，可概括为：“凡未明确否认之事，皆可自由认定为真。”
        
        (更甚者，“根据你装腔作势的程度，那些明确否认的内容也可被方便地忽略。”)
        
        回复
    3. colbythrowaway说道：
      
      2026-01-07
      
      我并非工程师，也不该让任何人误以为有人认为Reddit是寻求权威裁决的场所。但这里确实适合进行此类(且仅限于此类)的同事间非正式提醒。
      
      不过你居高临下的态度，我们都看在眼里。
      
      回复
      1. nebezb说道：
        
        2026-01-07
        
        你并非那位随机工程师。你回复的评论者Ben才是。
        
        对方已提供实用建议和链接，我看不出这有何居高临下。
        
        回复
        
        intern4tional说道：
        
        2026-01-07
        
        没错，这正是我的本意——Ben并非合适渠道，他只是个在此回复评论的工程师。这类问题事关重大，必须上报处理。
        
        遵守开源许可证绝非儿戏。
        
        回复
      2. intern4tional说道：
        
        2026-01-07
        
        你误会了。
        
        本就是随机工程师，绝非合适的联络人。开源合规问题严肃，若情况属实请务必上报。
        
        回复
        
        colbythrowaway说道：
        
        2026-01-07
        
        您提供的指导至今仍具必要性，其价值与初次提出时同样珍贵。请放心，我完全有能力且充分了解如何处理此类事务。谨致问候。
        
        回复
      3. __jonas说道：
        
        2026-01-07
        
        若您能更具体说明问题所在，或许能引发更多讨论。是否涉及此处提及的ffmpeg问题：https://github.com/electron/electron/issues/34236？
        
        回复
3. kneath说道：
  
  2026-01-07
  
  我理解您的初衷。但想请教：贵团队是否有人使用此设置？我也因屡次在沮丧中禁用Copilot而最终放弃VS Code。我早知此设置并已禁用所有AI功能，可惜收效甚微。
  
  真正令人沮丧的是编辑器被改造成2000年代的弹窗盛宴(并非反AI本身)。编辑器的每行代码都会不断在光标旁弹出新提示或文本。我明白VS Code的设计理念是让编辑器尽可能多地弹出窗口，但仍有许多用户认为这不利于专注工作。当编辑器每隔一周左右就认定你的选择是错误时，那种挫败感简直难以言喻。
  
  回复
4. g947o说道：
  
  2026-01-07
  
  只要在欢迎页面设置为可选功能，我们就达成共识。
  
  (当然，我明白这永远不可能实现。)
  
  回复
  1. illiac786说道：
    
    2026-01-07
    
    实在不理解这种态度。什么交易？你用VS Code？为什么不直接改设置？
    
    回复
    1. kmoser说道：
      
      2026-01-07
      
      这正是我对VS Code最大的抱怨之一：各种功能设置相互重叠，我始终搞不清优先级规则。配置不同文件类型的格式化器(及其设置)简直是噩梦：VS Code总抱怨我没配置(明明配置了)，设置似乎被忽略，各种问题层出不穷，每次编辑配置文件我都冷汗直冒。
      
      但更关键的是，既然已有设置面板支持自然语言搜索并返回匹配项，为何还要直接编辑文件？VS Code为何不能让用户直接通过设置面板完成所有修改，而不必直接折腾JSON文件？
      
      回复
    2. spartanatreyu说道：
      
      2026-01-07
      
      > 为什么不能简单修改设置？
      
      我的默认设置存储在11922行的json文件里。
      
      难道要我通读整份文件才能找到目标设置？
      
      当我连设置名称都不清楚时，难道还得这么做？
      
      之所以无法直接修改设置，是因为这个设置本身就不简单。
      
      它本质上是个隐藏设置，用模糊名称伪装，以用户不友好的方式存在。
      
      回复
      1. vbezhenar说道：
        
        2026-01-07
        
        > 我的默认设置存储在一个11922行的json文件里。
        
        我还以为我那50行的settings.json已经够乱了，得精简一下。哇哦。
        
        回复
        
        httpsterio说道：
        
        2026-01-07
        
        我猜你回复的用户指的是vscode默认配置文件有1.1万行，而AI设置只是其中一行而已。
        
        我觉得他们并非指自己的配置这么长，而是指应用程序的默认配置，并评论说指望用户在里面找到它简直荒谬。
        
        回复
        
        vbezhenar说道：
        
        2026-01-07
        
        啊，我是在浏览GitHub问题时发现这个AI设置的，哈哈，确实有点藏得深。可能有更好的方法。
        
        回复
      2. sgc说道：
        
        2026-01-07
        
        这本就是程序员工具。用谷歌搜索+Ctrl+F就能找到，没必要为此争论不休。
        
        回复
        
        spartanatreyu说道：
        
        2026-01-07
        
        每月都改AI设置名称，靠谷歌搜索怎么可能找到？
        
        回复
        
        neutronicus说道：
        
        2026-01-07
        
        大型语言模型在这方面表现相当出色。
        
        我用emacs，或许它们在我的编辑器上训练得更好。但通过gptel和Claude对话，我成功解决了许多困扰多年的小烦恼。
        
        它做正经事简直一塌糊涂，但在帮我浪费时间处理琐碎事务上堪称A+。哈哈
        
        回复
        
        sgc说道：
        
        2026-01-07
        
        或者直接用上面刚给你的那个单一设置。这已经是最简便的方法了，总不能让Clippy助手复活来帮你搞定。既然用户有上万个设置在用，指望它提供臃肿的图形界面就不合理。
        
        回复
        
        spartanatreyu说道：
        
        2026-01-07
        
        问题在于他们总在添加新AI“功能”，每项都冠以不同名称和设置项，还不断调整设置布局。
        
        即便有个“总开关”也无济于事，因为他们的标准操作就是每月往vscode里塞更多“功能”，这些功能又会归入不同设置项，然后继续调整布局。
        
        他们对这种用户敌意的漠视才是核心问题。
        
        回复
      3. heartbreak说道：
        
        2026-01-07
        
        > 我的默认设置存储在11922行的json文件里。难道要我读完整份文件才能找到目标设置？
        
        这正是AI的用途——让它自己关掉。
        
        回复
        
        spartanatreyu说道：
        
        2026-01-07
        
        啊，但若AI判断正确，我根本无需关闭它。
        
        回复
    3. WolfeReader说道：
      
      2026-01-07
      
      你真该搞清楚“主动选择加入”和“默认加入”的区别。前者尊重用户意愿，后者则是强行推送用户可能不需要的功能。
      
      回复
      1. sauercrowd说道：
        
        2026-01-07
        
        换个角度看：新用户可能会困惑，为何朋友们热议的人工智能功能自己却无法使用。
        
        这本就是权衡取舍
        
        回复
        
        kmoser说道：
        
        2026-01-07
        
        若采用全员主动选择机制，那么朋友们同样会告知新用户需要主动选择才能获得该功能。
        
        回复
        
        WolfeReader说道：
        
        2026-01-07
        
        若这意味着更多用户不会使用生成式AI，我欣然接受这个权衡！
        
        回复
      2. CuriouslyC说道：
        
        2026-01-07
        
        反AI人士现在就该彻底分叉所有东西，因为一边抱怨一边使用大量AI构建的产品简直虚伪至极。这样你们就能退出社会了！
        
        回复
        
        WolfeReader说道：
        
        2026-01-07
        
        天啊，想想我们将错过多少AI创造的“优秀”作品。
        
        …真有吗？
        
        回复
        
        CuriouslyC说道：
        
        2026-01-07
        
        我敢说当前AI参与开发的比例，比职业运动员使用兴奋剂的比例还高，而且掩盖真相宣称“不含AI成分”的动机几乎同样强烈
        
        回复
    4. apetresc说道：
      
      2026-01-07
      
      关键在于高调宣扬自己多么高尚地反AI，实际对工作流程的破坏性根本无关紧要。
      
      回复
      1. g947o说道：
        
        2026-01-07
        
        我每天都用编码助手，只是不用VSCode自带的。因为我想自主选择是否使用及选用哪种编码助手，而不是被VSCode强加给我的东西。事实上，许多公司都明令禁止使用GitHub Copilot。
        
        把这说成反AI可不算最聪明的论点。
        
        回复
        
        KronisLV说道：
        
        2026-01-07
        
        我特别喜欢Copilot跨文件符号的自动补全功能(比如可通过Tab键切换的预测编辑)。
        
        其他功能我更倾向Cline/RooCode/KiloCode，可惜它们似乎都不支持类似的自动补全(Continue.dev曾通过Ollama支持本地模型实现过，但整个插件漏洞百出且效果欠佳)。对了，有时直接在终端使用Claude Code或Codex也很方便。
        
        个人而言，我并不介意某些功能默认存在(就像JetBrains预装插件的同时也提供Junie这类选择)，只要能轻松关闭或卸载即可。
        
        这就像即使我更喜欢使用Sourcetree或GitKraken，也不会对Git集成插件嗤之以鼻。
        
        回复
        
        g947o说道：
        
        2026-01-07
        
        > 只要能轻松关闭或卸载
        
        这正是问题所在。
        
        “禁用所有AI功能”选项实在难以寻觅。
        
        回复
      2. blks说道：
        
        2026-01-07
        
        根据我的经验，那些动用“智能助手”批量修改代码的人，往往是在第十次尝试说服工具按自己意愿行事——他们的工作流程已被打乱，始终与工具处于对抗状态。
        
        回复
      3. bigyabai说道：
        
        2026-01-07
        
        瞥了眼Windows 11
        
        不，我认为关键在于规避日益侵蚀本地设备文本编辑价值的商业化扩张。
        
        回复
5. ustad说道：
  
  2026-01-07
  
  VS Code是微软的旗舰产品。对于全球范围的退出设置，仅依靠“我们会尽力尽快推出修复方案”的做法，显然低于我们期望的工程标准。此类设计本应具备容错机制，而非仅做尽力而为的承诺。
  
  回复
  1. scotty79说道：
    
    2026-01-07
    
    世间万物至多只能做到尽力而为。那些宣称自家产品能做到完美的人纯属欺骗。你愿意被欺骗吗？指责他人坦诚实情只会招致更多谎言。
    
    回复
    1. ustad说道：
      
      2026-01-07
      
      我宁愿听到“我们的架构设计存在缺陷，正在努力修复”，也不愿听“偶尔会有疏漏，发现问题请反馈”。前者既诚实又表明他们认识到问题，后者则将设计缺陷视为可接受的常态。
      
      坦诚承认发布缺陷是好事。但坦承设计出会反复出现同类缺陷的系统？这值得批评，而非因诚实而获得赞扬。
      
      回复
6. egorfine说道：
  
  2026-01-07
  
  能否考虑添加“chat.disableAIFeaturesMadeForShareholdersOnly”开关？
  
  这样我们就能保留真正有价值的功能(副驾驶、聊天)，同时屏蔽那些明显为虚增指标而强行制造需求的冗余功能？
  
  回复
  1. never_inline说道：
    
    2026-01-07
    
    这个问题或许可以这样表述：
    
    * 能否通过切换chat.disableAIfeatures开关，仅选择性启用Copilot和聊天功能？
    
    回复
7. Abishek_Muthian说道：
  
  2026-01-07
  
  我转投Zed正是看中其AI功能，Claude集成无缝流畅，IDE运行迅捷如飞。我能按需自由选用各类智能助手，而非被迫使用Copilot。
  
  除少数语言相关扩展外，我在Zed上未安装其他扩展。这意味着我无需担忧哪些扩展会被转售给恶意软件开发者。
  
  相比在VSCode上遭遇官方扩展问题(比如Flutter扩展)，我更倾向于在Zed上不依赖扩展而使用终端(其系统交互体验远比VSCode更直接)。
  
  回复
  1. barrenko说道：
    
    2026-01-07
    
    能否详细说明你如何使用这些AI功能？
    
    回复
    1. Abishek_Muthian说道：
      
      2026-01-07
      
      我的配置极简：
      配置项 –
      外部代理包含：Calude Code、Codex CLI、Gemini CLI，以及通过Llama.cpp实现的Qwen Coder自定义代理[1]
      
      MCP配置：fetch、brave-search、puppeteer
      
      LLM提供商：已配置Llama.cpp、LMStudio和OpenAI(Zed Agent可访问这些提供商的模型)
      
      工作流 –
      
      需要LLM辅助时，我主要使用Claude Code完成特定任务，并建立完善的框架。在Zed中使用外部代理的主要缺陷是它们不支持历史记录[2]，但对我影响不大，因为我仅将Claude用于单次任务。对于需要“vibecode”整个项目的用户，Zed的适用性尚不明确。
      
      [1] https://zed.dev/docs/ai/external-agents
      
      [2] https://github.com/zed-industries/zed/issues/37074
      
      回复
      1. barrenko说道：
        
        2026-01-07
        
        谢谢！
        
        回复
8. mort96说道：
  
  2026-01-07
  
  我实在对那种把“AI代码编辑器”当作核心卖点的文本编辑器毫无兴趣。
  
  回复
9. artdigital说道：
  
  2026-01-07
  
  顺便说，Zed也有类似设置可以关闭所有AI功能 🙂
  
  回复
  1. NordSteve说道：
    
    2026-01-07
    
    但我敢肯定他们永远不会忘记给它添加AI功能。
    
    回复
10. nottorp说道：
  
  2026-01-07
  
  > 偶尔可能会有不遵守该设置的新AI功能悄然加入
  
  你是说市场部门逼着你们“不小心”塞进去？就怕这次能成功？
  
  回复
  1. compounding_it说道：
    
    2026-01-07
    
    营销部门我不清楚，但如果代码审查到位，真想知道“AI功能”这类东西怎么会悄无声息地混进去。
    
    回复
    1. blks说道：
      
      2026-01-07
      
      或许那些推送AI垃圾功能的人，其实并不擅长做好代码审查；这实在令人遗憾。
      
      回复
    2. nottorp说道：
      
      2026-01-07
      
      代码看起来没问题，何乐不为？
      
      回复
11. vbezhenar说道：
  
  2026-01-07
  
  感谢这个设置！说实话我更希望VSCode不预装任何AI功能，让用户自行安装扩展，但管理者可能不乐意。至少这个设置能让人保持清醒。
  
  回复
12. kyrofa说道：
  
  2026-01-07
  
  谢谢Ben，我之前不知道这个功能。
  
  回复
13. joshAg说道：
  
  2026-01-07
  
  只想告诉你，这条评论是我时隔九个月重新启用VSCode的唯一原因。
  
  回复
14. madbbb说道：
  
  2026-01-07
  
  看到很多人讨厌VSCode的AI功能。想说还有像我这样真心喜爱这些功能的人，作为Copilot Pro用户，在此致谢！
  
  回复
15. kgwxd说道：
  
  2026-01-07
  
  干脆做个独立版本，彻底移除所有AI代码——因为开关根本不可靠。尤其考虑到更新后重置开关的先例。
  
  回复
16. fingerlocks说道：
  
  2026-01-07
  
  真想知道微软员工在绩效考核时，开启这个开关会面临什么后果。
  
  回复
  1. intern4tional说道：
    
    2026-01-07
    
    没有。这甚至不是被追踪的数据项。AI使用显然受到鼓励，但人力资源部门有更重要的事要做，不会去收集这类数据。
    
    内部而言，不同团队根据所开发的产品，拥有不同的开发流程和AI使用场景。对于VSCode这类工具，团队完全可以自由决定使用方式。
    
    回复
    1. fingerlocks说道：
      
      2026-01-07
      
      这并非全公司通行的做法。我本人就因GitHub Copilot使用率过低受到部门领导(而非HR)的正式警告。
      
      回复
17. jdejean说道：
  
  2026-01-07
  
  哎呀！！又出纰漏了。某AI功能再次绕过了用户禁用设置。现在该如何处理这些数据呢？？
  
  回复
18. pshirshov说道：
  
  2026-01-07
  
  [已删除]
  
  回复
  1. steve_adams_86说道：
    
    2026-01-07
    
    难道不能在GitHub问题跟踪中更委婉地提出吗？
    
    回复
japhyr说道：

2026-01-07

VS Code内置的AI工具推送让我深感困扰，但我选择了另一种改变。与其彻底更换编辑器，我开始使用VS Codium。若您不熟悉，它本质是VS Code的开源核心，去除了构成VS Code的微软品牌功能。

我认为微软是通过构建VS Codium，再添加自有品牌功能(包括所有AI推送)来发布VS Code版本的。若您喜欢VS Code但排斥微软元素，不妨考虑VS Codium及其他现代选择。

https://vscodium.com

回复
1. weikju说道：
  
  2026-01-07
  
  > 我认为微软是通过构建VS Codium来发布VS Code版本
  
  VSCodium不正是严格基于开源VS Code代码构建的独立产品吗？它与微软并无关联，双方只是基于相同底层进行不同方向的定制化开发。
  
  这与我对Chromium/Chrome的理解有所不同，后者更接近你描述的情形。
  
  回复
  1. japhyr说道：
    
    2026-01-07
    
    最清晰的解释见VSCodium的“为何选择”页面：
    
    https://vscodium.com/#why
    
    回复
    1. bityard说道：
      
      2026-01-07
      
      你可能存在误解，你在评论中提到：
      
      我认为微软是通过构建VS Codium，再添加自有品牌功能来发布VS Code
      
      这部分并不准确。微软和VSCodium都基于https://github.com/microsoft/vscode构建发布版本，但微软从未参与VSCodium的开发。
      
      回复
2. r4victor说道：
  
  2026-01-07
  
  这个建议不错。我曾考虑过VSCodium，但问题在于我使用了VSCode的专有扩展(如Pylance)。这意味着需要切换到开源替代方案，于是我决定尝试Zed——它不基于Electron框架，使用体验更佳。
  
  若需要Zed不支持的扩展，VSCodium仍是不错的选择。
  
  回复
  1. krabizzwainch说道：
    
    2026-01-07
    
    若能接受轻微卡顿，我成功实现了将VSCode的扩展目录直接迁移至VSCodium目录。我常用的Oracle SQL Developer插件就能这样运行。虽然可能违反扩展条款，但我不在乎。
    
    回复
    1. Timon3说道：
      
      2026-01-07
      
      此法对Pylance等扩展无效。微软已添加检测机制，确保扩展仅在VS Code环境运行，需手动修改捆绑扩展代码中的检测逻辑(例如[0]所示方法，但当前版本可能已失效)。
      
      [0]: https://github.com/VSCodium/vscodium/discussions/1641#discus…
      
      回复
  2. seabrookmx说道：
    
    2026-01-07
    
    Basedpyright 和 ty 在 vscodium 环境下均可正常运行。
    
    回复
    1. tristan957说道：
      
      2026-01-07
      
      Basedpyright 确实出色，我在 neovim 中使用已久。目前正在评估 ty，虽然它远不及前者优秀，但毕竟是全新推出的工具。
      
      我们能拥有 pylance 的优质替代方案令人欣慰。尽管 pylance 性能优异，但其闭源性质实属遗憾。
      
      回复
  3. bobajeff说道：
    
    2026-01-07
    
    我一直在VSCodium中使用Basedpyright，原以为它是Pylance的开源版本。不得不说它的类型错误提示很烦人，即使降低严格度设置后依然令人困扰，甚至开始在代码里乱插# ignore _____ 这样的注释。
    
    很高兴文章提到了ty，今天就要试试看。
    
    在zed上试用时，字体渲染刺眼，界面似乎有故障，而且不支持我常用的markdown拖放插入链接功能*。
    
    * https://code.visualstudio.com/Docs/languages/markdown#_inser…
    
    回复
3. aspbee555说道：
  
  2026-01-07
  
  多年来我一直使用vscodium，直到最近才遇到问题(Rust分析器无法检测到修改，不确定是Rust还是VSCode的问题)。我曾尝试过zed，但当时它无法满足我的基本需求。看来得重新试用它了
  
  编辑：zed现在运行得更顺畅了，且不存在vscodioum的问题(如不识别修改/需手动触发重建才能检查代码)。
  
  回复
4. tuwtuwtuwtuw说道：
  
  2026-01-07
  
  那些不断提示使用AI工具的行为是怎么回事？听起来有点奇怪。
  
  回复
5. ErroneousBosh说道：
  
  2026-01-07
  
  我倒没注意到VS Code里有任何“提示”要用AI工具。之前看到过Copilot的提示框，但我关掉了，之后也没再出现。
  
  我可能还没完全挖掘出它的潜力，但作为代码编辑器它表现出色——这是我第一次遇到真正契合思维方式的代码补全功能。虽然日常使用的几种语言缺少格式化工具，但这属于个人问题：IDE用户与汇编程序员的重叠群体本就稀少。
  
  是否存在值得关注的微软特色功能(无论正反面)？
  
  回复
  1. japhyr说道：
    
    2026-01-07
    
    身为教师，我经常协助他人搭建编程环境。若在未预装编程工具的新系统上安装VS Code，会看到大量关于AI功能的引导提示。我不希望在指导安装编辑器后，又不得不告诉用户必须禁用一堆“功能”。
    
    这并非反AI立场——我日常就使用AI工具。之所以将“功能”加引号，是因为其中部分内容并非真正意义上的功能，而是诱导用户订阅特定微软AI服务的营销手段。我希望自主决定何时采用AI工具、选用哪些工具，而非让它们像未启用广告拦截器的移动新闻网站般频繁弹出。
    
    回复
ashvardanian说道：

2026-01-07

目前我混合使用Zed、Sublime和VS Code。

Zed目前最缺失的功能是并排代码对比，相关讨论帖虽存在但近期鲜有更新：https://github.com/zed-industries/zed/discussions/26770

若能加强GDB/LLDB支持并扩展C/C++工具链，也将是重大进步。

当今软件普遍臃肿的现状实在令人咋舌。衷心感谢Zed和Sublime团队坚持反其道而行之的开发理念！

回复
1. j1elo说道：
  
  2026-01-07
  
  > 目前Zed对我工作流程最大的缺失是并排差异对比功能。
  
  > 当今多数软件变得如此臃肿，实在令人咋舌。
  
  将这两点放在同条消息中略显讽刺，但我认为这恰恰说明了软件臃肿化的根源。总有人提出“但如果能实现X功能就太棒了”，这种需求看似相关，实则会衍生出全新的复杂系统。
  
  例如文本差异比较，所需工具和技术与普通文本编辑器截然不同。正因如此才诞生了Meld和优秀的Beyond Compare这类独立产品；它们往往远胜于通才型编辑器(至少我始终更青睐Meld的差异界面和BC的定制功能，而非VSCode的差异界面)。
  
  版本控制集成等周边功能亦是如此：VSCode虽有基础支持，但专业工具在易用性和功能性上遥遥领先。
  
  最终，编辑器开发者不得不耗费大量精力添加补充性功能，而非专注于打造最优秀的核心产品。用户期望值高得离谱，仿佛天花板根本不存在。每个人都执着于自己的小众功能(“番茄钟何时集成？”)。
  
  回复
  1. sabellito说道：
    
    2026-01-07
    
    完全赞同。
    
    人们将不需要的功能称为“臃肿”，却把除文本编辑外缺失的特性当作“致命缺陷”。
    
    回复
2. __jonas说道：
  
  2026-01-07
  
  我完全赞同那条关于IntelliJ差异视图的评论链
  
   https://github.com/zed-industries/zed/discussions/26770#disc…
  
  我甚至不需要它内置在编辑器里——只要有速度快、独立运行的Git界面工具，性能能媲美IntelliJ的，我都愿意付费。目前用Sublime Merge勉强凑合，但确实不在同一水平线上
  
  回复
  1. sushisource说道：
    
    2026-01-07
    不知你是否注意到，其实可以单独使用diff/merge工具。送你一份礼物：
    
    [mergetool “intellij”] cmd = ‘intellij-idea-ultimate-edition’ merge “$LOCAL” “$REMOTE” “$BASE” “$MERGED” trustExitCode = true
    回复
  2. hoistbypetard说道：
    
    2026-01-07
    
    我主要通过终端操作Git，但IntelliJ界面在挑选变更时的便捷性，正是我持续订阅工具箱服务的原因之一。此外，IdeaVim作为Vim实现方案，在我看来相当可靠。
    
    回复
    1. __jonas说道：
      
      2026-01-07
      
      如果他们能将版本控制系统界面拆分出来，做成一个独立于IDE的独立产品——启动运行速度比IDE稍快，且不依赖项目配置——我甚至愿意为此付费订阅。
      
      回复
3. criemen说道：
  
  2026-01-07
  
  > 我目前混合使用Zed、Sublime和VS Code。
  
  能否详细说明你何时使用哪个编辑器？我原本以为深入学习和使用一个编辑器更有价值，而不是根据使用场景频繁切换，因此很想了解你的具体做法。
  
  回复
  1. oneeyedpigeon说道：
    
    2026-01-07
    
    虽然用户不同，但我倾向于根据场景选择编辑器：
    
    – 项目开发：需图形界面、多文件协同、LSP集成(Zed)
    – 快速编辑：终端操作、轻量高效、功能需求低(Vim)
    
    – 非编码写作：需图形界面、浅色主题、优质Markdown支持(coteditor)
    
    我不喜欢庞杂的软件，因此避开集成开发环境；理想情况下希望用更简洁的编辑器替代zed，且不带AI功能，但尚未找到自动格式化效果同等的替代品。
    
    回复
  2. ashvardanian说道：
    
    2026-01-07
    
    我的工作流程较为特殊。通常在本地机器上同时运行3-5个项目，并维护两个云实例——x86架构和Arm架构。每个项目包含多种编程语言的文件(主要为C/C++/CUDA、Python和Rust)，平均文件规模轻松突破1000行代码，有时甚至超过10000行。
    
    即使禁用大部分扩展，VS Code仍频繁出现卡顿。每天需多次重启程序，否则界面会闪烁异常。差异视图响应也极其迟缓。Zed能流畅处理常规源文件，但功能有限。当打开超大型代码库和数GB数据集文件时，Sublime便成为首选。
    
    回复
  3. tripflag说道：
    
    2026-01-07
    
    我的使用场景是：几乎所有工作都用 Zed，仅用 vscodium 处理三件事：
    
    跨文件搜索；侧边栏匹配行列表便于导航，通过光标上下移动浏览结果，提供完整上下文
    
    Git 操作；支持并排差异对比，更优的暂存管理，且不会自动换行提交信息 (我更喜欢手动处理)
    
    编辑与Zed配置缩进类型不符的文件，因Zed尚未支持自动检测
    
    回复
4. eviks说道：
  
  2026-01-07
  
  最近看过Zed二进制文件的体积吗？它如何应对臃肿问题，尤其与Sublime相比？
  
  回复
mark_l_watson说道：

2026-01-07

这篇文章触动了我的心弦：一周前我买了新MacBook，只安装了最精简的软件——特别是刻意未装VSCode，如今也毫无缺憾。

新笔记本上我只用Emacs。拥有近40年Emacs使用经验，除treemacs自动化工具外，其余配置均沿用常规方案。

VSCode虽是优秀项目，但使用时我始终感受不到“愉悦感”。Emacs能带给我愉悦体验，我仅在极少数情况下使用其LLM集成功能，更倾向于单独运行gemini-cli，或通过单次提示调用各类LLM(尤其偏好性能强劲的本地模型)。

回复
1. dleslie说道：
  
  2026-01-07
  
  同样地，Emacs能带给我其他编辑器无法企及的愉悦感。它诞生于不同的开发时代，对高效编程有着截然不同的理解。Rider、VSCode等编辑器都属于后NetBeans时代产物，其设计理念已然不同——它们更侧重项目重构而非文本编辑，而智能体AI开发恰好能无缝融入这种重构流程。而Emacs让人感受到强烈的目的性、手动操作感，甚至可以说，它蕴含着匠人精神。
  
  回复
2. tacker2000说道：
  
  2026-01-07
  
  几个月前我也开始使用Emacs(注：此处“doom”为作者自嘲式表达)，因为意识到JetBrains和VSCode注定会被AI功能充斥，且无法回头。
  
  此刻我要向每位有实力的程序员推荐：直接跳槽到vim/neovim或emacs吧。这些编辑器未来千年都将屹立不倒，你既不必对抗那些垃圾功能，也永远不必再换工具。一两个月的学习成本绝对值得！
  
  回复
  1. oefrha说道：
    
    2026-01-07
    
    我曾是Emacs的长期用户，在~/.emacs.d/init.el里耗费了太多光阴。如今除了Magit，我再也没用过它。最近重拾Emacs，先通过package.el升级包。当然，执行package-menu-execute升级时界面依然卡死。估计千年之后它仍会是单线程架构，几乎每次操作都会锁死UI线程。
    
    回复
  2. ericyd说道：
    
    2026-01-07
    
    我已设置千年后的日历提醒来验证此说法
    
    回复
3. Robdel12说道：
  
  2026-01-07
  
  如今能让大型语言模型优化配置，我重新爱上了Emacs。我爱Emacs，但不爱Lisp。或许大型语言模型也在帮我克服这点。
  
  但现在的配置让我无比满意——简洁又现代化。
  
  回复
  1. alfiedotwtf说道：
    
    2026-01-07
    
    哈哈！我的elisp几乎为零，所以用ChatGPT和Claude重写了完美配置——简直太棒了！
    
    回复
4. onehair说道：
  
  2026-01-07
  
  并非人人都拥有：
  
  – 40年的Emacs使用经验
  – 预见自己会在入门20年后爱上Emacs的能力
  – 将Emacs这个“工具包”级文本编辑器打造成完美编辑器的坚韧意志
  
  回复
  1. justinhj说道：
    
    2026-01-07
    
    你或许会惊讶于通往完美Emacs配置的路竟如此短暂。
    
    回复
    1. onehair说道：
      
      2026-01-07
      
      相信我，我尝试过。配置已然完成。耗费数周心血，却仍远不及Helix开箱即用的体验。
      
      更糟的是它在Windows上运行极其缓慢。
      
      但总有一天，总有一天我会转投它怀抱
      
      回复
    2. chuckadams说道：
      
      2026-01-07
      
      无人能抵达完美的Emacs配置之巅，那只是条渐近线。
      
      回复
5. _sinelaw_说道：
  
  2026-01-07
  
  作为资深Emacs用户(>15年)，我也厌倦了无休止的配置调试：某些包在版本升级时失效，曾经酷炫的插件逐渐过时，迫使我不断切换类似功能的替代方案。最痛苦的是每次更换新电脑或连接新虚拟机时，都得重新恢复配置。
  
  我正在构建替代方案，现在已经一个月没打开Emacs了
  
  回复
6. Trattue说道：
  
  2026-01-07
  
  我在Linux上愉快地用Doom Emacs替代VSCode。但切换到macOS后，发现体验相当卡顿，输入延迟明显。(没错，我确实用了原生编译。)这方面有改进吗？还是你只能接受现状？
  
  回复
  1. hallmason17说道：
    
    2026-01-07
    
    我遇到同样问题。Linux机上用Doom很流畅，但Mac上慢得令人分心。d12frosted/homebrew-emacs-plus似乎能缓解延迟，但又出现其他问题，最终我还是回到了vim。
    
    回复
  2. bitwize说道：
    
    2026-01-07
    
    我工作用的Mac上很多Emacs功能都很卡顿，后来发现是思科终端安全软件在每次运行二进制文件时都会拦截检查——每次都检查，该死的！这导致需要调用外部程序的操作明显变慢，比如M-x compile和Magit里的任何功能。
    
    回复
7. barrenko说道：
  
  2026-01-07
  
  去年购入一台基础款新笔记本，内存充足，谁知VS Code在新设备上竟毫无提速感。上周发现Zed for Windows已达“稳定版”，便卸载了VSC。
  
  VS Code仍是更优工具(个人观点)，但我实在忍无可忍。
  
  回复
8. cmrdporcupine说道：
  
  2026-01-07
  
  我使用Emacs已逾三十载，但其在21世纪的表现令人沮丧。
  
  此处指双重问题：启动速度(是的，我明白真正的Emacs用户永不离开编辑器——但我不属于那类人)以及单线程架构导致的卡顿——尤其在配合eglot+rust-analyzer等工具时，阻塞延迟简直痛苦不堪。
  
  回复
9. bitwize说道：
  
  2026-01-07
  
  尽管全世界都在说现在人人都用VS Code，我坚持用Emacs的决定果然没错。Emacs兄弟们团结起来！
  
  回复
10. dbacar说道：
  
  2026-01-07
  
  Emacs什么？？来场编辑器骂战吧，虽然这完全是另一场编辑器战争 :)) 是的我是VI党。
  
  开玩笑的，其实我真的很怀念org-mode。
  
  回复
adonese说道：

2026-01-07

Sublime确实很棒。我一直用它快速编辑、记录笔记等。但最近更欣赏它作为轻量级IDE的价值。除了包管理器和项目管理功能，我还用Go(LSP和插件)和ST(SQL工具)。我喜欢它的运行速度，喜欢编辑器打磨得如此精良。通常我使用的所有插件都能完美配合。Claude也帮了大忙(比如为我常用的特定场景编写快捷键)。

并非贬低Zed。但Sublime搭配Claude一次会话，就能帮你打造专属定制化的IDE。

回复
1. 克苏鲁_说道：
  
  2026-01-07
  
  我曾深爱Sublime，它至今仍会不定期更新，但遗憾的是其生态系统约五年前已式微，包库里充斥着“最后更新于十年前”的项目。它仍是可用编辑器，但缺乏社区支持终难持久。
  
  话虽如此，ST(及其前身，忘了名字)确立了“轻量级”(比集成开发环境更轻便)编辑器的标准——Atom、VS Code乃至如今的Zed，其核心设计模式皆可追溯至ST。
  
  回复
  1. debugnik说道：
    
    2026-01-07
    
    > 及其前身(忘了名字)
    
    TextMate？作为一款我从未见人使用的编辑器，它的影响力令人惊讶；或许在美国——那里人们确实会购买Mac——情况不同。
    
    回复
    1. biztos说道：
      
      2026-01-07
      
      我曾是TextMate重度用户，最终转投ST是因为需要更丰富的社区集成等功能…而这些如今正成为ST的软肋。
      
      我仍在使用SublimeText，因为无法忍受VS Code的迟滞感，且愿意为最新版付费，但开始担忧这款优秀编辑器的未来。尤其Rust编程体验堪称噩梦。
      
      可悲的是，这两款产品都源于我热切支持并期待更多出现的商业模式：独立开发者(TM)和小企业(ST)，或者说独立开发者伪装成小企业？我实在难以分辨。
      
      回复
      1. ben-schaaf说道：
        
        2026-01-07
        
        > 或者说独立开发者假装成小企业？我实在分辨不清。
        
        肯定是小企业啦 🙂
        
        回复
    2. hyperjeff说道：
      
      2026-01-07
      
      我没注意到它自21年(TM2)后就再未更新，但至今仍每天使用。它只是个可靠、简约、完全原生的编辑器(不含Electron等框架)，却足够灵活以持续添加新插件。虽遗憾它已停止开发，但欣慰它成为人工智能编程浪潮中的一片绿洲。
      
      回复
  2. RadiozRadioz说道：
    
    2026-01-07
    
    > 最后更新于10年前
    
    除非软件在此期间已损坏，否则不成问题
    
    回复
  3. xvector说道：
    
    2026-01-07
    
    > Atom、VS Code乃至Zed，其设计理念皆可追溯至ST。
    
    确实如此，但在我看来Zed才是真正的精神继承者。Atom和VSCode都不注重运行速度与响应灵敏度——而这恰恰是Sublime Text最打动我的特质。
    
    回复
  4. sgc说道：
    
    2026-01-07
    
    我依然钟爱Notepad++。这是我怀念Windows时代为数不多的应用之一。它比TextMate早发布约一年，于我而言才是真正的元老级存在。
    
    回复
  5. bigstrat2003说道：
    
    2026-01-07
    
    呃，我倒不觉得这是问题。备受吹捧的VSCode生态系统其实没那么实用，所以没人开发大量Sublime插件也无所谓。有个LSP插件就足够满足基本需求了。
    
    回复
2. james2doyle说道：
  
  2026-01-07
  
  人们似乎低估了Sublime插件的开发门槛。一个简单的.py文件就能实现功能，无需依赖项安装步骤，无需元数据文件，更无需繁琐流程——直接将.py文件放入正确目录即可。我用Gemini开发过3-4个复杂程度各异的插件，全都运行良好
  
  回复
  1. oneeyedpigeon说道：
    
    2026-01-07
    
    > 只需将.py文件放入正确目录即可。
    
    如果放错目录，ST能否自动识别？我偏好文件组织尽可能灵活的应用。
    
    回复
3. kevinfiol说道：
  
  2026-01-07
  
  同感，我仍在使用Sublime搭配SublimeLSP，这能满足95%的使用场景——毕竟其他操作我习惯依赖终端。不过我确实希望最终能转用Zed，毕竟它内置调试器且支持在弹出窗口中选中复制文本(难以置信Sublime在2026年仍不支持此功能) ——上次试用Zed时它仍有不少瑕疵，而Sublime的性能表现依然更胜一筹。
  
  回复
4. butz说道：
  
  2026-01-07
  
  Sublime Text处理巨型文件时丝毫不卡顿的表现令人惊叹，多数编辑器在此处都力不从心。其整体速度与响应效率更是难以置信。真想看看有哪款编辑器能在这些指标上超越Sublime Text。
  
  回复
  1. fdg4t说道：
    
    2026-01-07
    
    可将ST与CudaText进行速度对比。
    
    回复
  2. IshKebab说道：
    
    2026-01-07
    
    VSCode实为处理大型文件的佼佼者。虽不及Sublime Text，但能轻松编辑百万行文件，而其他编辑器中竟有如此多无法胜任者，着实令人惊讶。Zed直到最近才支持(不确定现在是否仍不支持；我近期未测试)。
    
    遗憾的是，当文件量达到GB级别时，能流畅编辑的编辑器寥寥无几。
    
    回复
    1. mwest217说道：
      
      2026-01-07
      
      Vim、neovim和helix都能完美处理数GB级文件！
      
      回复
      1. maleldil说道：
        
        2026-01-07
        
        > neovim
        
        处理大型文件(如数GB的JSON文件)时，我必须关闭配置(-u NONE)，否则操作会变得极其缓慢。我从未进行性能分析来确定具体原因，可能是treesitter插件导致的。
        
        回复
        
        cyberpunk说道：
        
        2026-01-07
        
        我发现常规Vim中粘贴或管道传输大块json时，语法高亮通常是罪魁祸首
        
        回复
      2. IshKebab说道：
        
        2026-01-07
        
        是啊，但这样就得用Vim式编辑了，我讨厌那种操作。
        
        回复
5. lexoj说道：
  
  2026-01-07
  
  能否分享Sublime中Go插件的名称/配置？现有方案太多，很难找到能媲美VSCode的配置。
  
  回复
6. baby说道：
  
  2026-01-07
  
  我用emacs当终端里的“轻量级”IDE，结果一点都不轻。每次新服务器安装都占空间，启动还慢得要命。真该当初学vim的。
  
  回复
7. sixothree说道：
  
  2026-01-07
  
  你们如何重构代码？
  
  回复
foxylad说道：

2026-01-07

这篇文章(加上假期空闲)促使我重新更新并测试zed。几个月前试用时我非常喜欢它，但在处理远程代码时彻底失败了。它会卡死，而我找不到任何诊断工具来调试它相当复杂的远程代理程序，以找出问题所在。

但现在它运行良好！远程工作明显比挂载远程服务器为驱动器更流畅，远程Git似乎也运行良好。这是份非常棒的圣诞礼物——谢谢你，Zed！

干得漂亮，Zed！

回复
1. roywiggins说道：
  
  2026-01-07
  
  有趣的是，我正是因为VS Code远程功能频繁卡死才转投Zed的怀抱！
  
  回复
throwfaraway135说道：

2026-01-07

我尝试过从VScode切换到Zed，可惜它不支持Jupyter笔记本和图像/视频预览功能，这对我是致命缺陷。

其他痛点：

– 默认启用保存格式化：https://github.com/zed-industries/zed/discussions/29395
– VSCode调试器用户体验明显更优

回复
1. mostlyk说道：
  
  2026-01-07
  
  我已为Zed添加了Jupyter支持和平移/缩放功能，正在等待合并。但我手头有个可用的版本，如果你愿意可以自己构建！相关PR：https://github.com/zed-industries/zed/pull/43553， https://github.com/zed-industries/zed/pull/43944
  
  包含两项功能的My-Zed分支：https://github.com/MostlyKIGuess/zed/tree/my-zed
  
  回复
2. emilbratt说道：
  
  2026-01-07
  
  等等，你对代码编辑器的需求里居然包含视频预览功能？我甚至不知道有这种功能。回家得开个VSCode试试看。
  
  回复
3. ahurmazda说道：
  
  2026-01-07
  
  我用过一次糟透了。连识别Python解释器这种基础操作都搞不定！如今IDE多如牛毛——速度够快的大多没问题。但常用工作流必须万无一失。
  
  回复
4. Cthulhu_说道：
  
  2026-01-07
  
  问题在于你的预期：当年Sublime Text问世，后来VS Code出现时，它们刻意没有搭载Eclipse和IntelliJ IDEA这类IDE的全部功能。后者的生态系统固然强大丰富，但对多数任务而言功能过剩，性能代价也过高。
  
  X年后的今天，VS Code拥有最庞大的生态系统，因此也承载着最多且最复杂的插件。
  
  Zed 则选择从零开始，依赖开发者创建扩展。但我认为，由于 Zed 基于 Rust 语言而非 Code 采用的 Web 技术，要打造出与 Code 相当的庞大生态系统将更为困难。同理，某些大型 IDE 插件背后都有企业支持者出资开发维护。
  
  回复
5. r4victor说道：
  
  2026-01-07
  
  没错！我在处理格式混乱的旧项目时也曾被format_on_save功能坑过。从其他讨论可见，维护者似乎没充分考虑这种场景——他们会质疑“为什么不希望保持规范格式？”。虽然现在可以手动关闭该功能，但不确定他们是否会修改默认设置。
  
  回复
  1. bluecalm说道：
    
    2026-01-07
    
    这就像Excel在打开.csv文件后擅自修改格式，导致简单的加载/保存循环就能破坏文件，原始副本彻底消失。虽然自动格式化造成的破坏可能较小，但程序在“打开文件-关闭程序”的简单操作中擅自篡改用户文件，这种行为仍超出我的预期。
    
    回复
6. fnordlord说道：
  
  2026-01-07
  
  VSCode调试器是我在工作机上保留它的唯一理由。不过最近我都在Helix里编辑代码，调试时才切换到Xcode。它比VSCode更稳定，后者偶尔会内存泄漏甚至崩溃。虽然还没时间深入学习lldb命令行操作，但这可能就是下一步要做的。唯一怀念的还有VSCode的“全局查找/全局替换”功能，因为它能保留包含/排除路径，而Helix(据我所知)不支持此功能。
  
  回复
  1. NSPG911说道：
    
    2026-01-07
    
    Helix难道不支持通过调试适配器协议(DAP)连接调试器吗？
    
    回复
7. ThisNameIsTaken说道：
  
  2026-01-07
  
  Zed内置了多种语言的REPL功能，确实支持图像预览[0]
  
  至少Python部分采用Jupytext格式[1]，坦白说比笔记本格式更友好地支持版本控制。
  
  我同意“保存时自动格式化”不该设为默认选项，但关闭该功能只需轻点开关即可。
  
  [0]: https://zed.dev/docs/repl [1]: https://jupytext.readthedocs.io/en/latest/
  
  回复
8. dcchuck说道：
  
  2026-01-07
  
  我发现自己常在“这类场景”使用VS Code(看重其可视化扩展生态)。
  
  我已习惯Git差异化视图，因此主要用它审阅PR(尤其大型PR——近期GitHub界面处理这类操作时常卡顿)。
  
  其余代码均在Vim或Claude中编写。
  
  回复
9. stellalo说道：
  
  2026-01-07
  
  Jupyter笔记本不支持也让我失望：最终我几乎不再使用Jupyter笔记本，偶尔需要时直接在Jupyter中运行。
  
  回复
r4victor说道：

2026-01-07

大家好，我是本文作者。希望这篇文章能引起许多厌倦VSCode而转向Zed用户的共鸣。

此外还想补充，Zed里有许多我未在文中提及的小功能让我怀念，比如自动检测并保留文件缩进(https://github.com/zed-industries/zed/issues/4681)。不过我注意到Zed正在积极补全这些缺失功能，相信未来一年内会显著改进。

回复
1. delichon说道：
  
  2026-01-07
  
  你的博客似乎被拥抱致死。期待有天能读到它。
  
  回复
  1. e12e说道：
    
    2026-01-07
    
    https://archive.is/aaJh4
    
    回复
2. SnowingXIV说道：
  
  2026-01-07
  
  你试过用vim吗？或者说nvim？若你热衷折腾，大可自行定制环境，但默认的lazyvim已相当合理，可能无需太多调整就能满足需求。
  
  但它能轻松扩展或修改以适应你的工作流程，这点非常棒。我只是好奇大家从zed中获得的功能，似乎vim也具备。
  
  回复
  1. oneeyedpigeon说道：
    
    2026-01-07
    
    我同时使用zed和vim，但前者专用于“大型”项目，原因在于：
    
    a) 文件树功能——我特别喜欢能将视图“定位”到某个目录，探索层级结构，并轻松打开其中任意文件
    b) LSP(代码补全)——zed的自动格式化功能对我而言是其最突出的优势
    
    虽然我通常喜欢GUI提供的诸多便利，但若能在vi中实现这两项功能(或至少接近其效果)，我可能会放弃zed。
    
    回复
  2. benji8000说道：
    
    2026-01-07
    
    +1 支持 lazyvim。我多次尝试从 vscode 切换到 nvim，但 lazyvim 终于让过程毫无痛感。也超爱 lazygit。nvim 里的调试功能同样顺畅无比。
    
    回复
cjk说道：

2026-01-07

Zed 是我近年来开发工具中最重大的变革之一。日常使用中明显比 VS Code 更快(启动速度、输入延迟等)，资源占用更少，且拥有我用过所有 GUI 编辑器中最出色的 Vim 模式。

回复
1. steve_adams_86说道：
  
  2026-01-07
  
  深表赞同。使用体验令人愉悦，能感受到开发者倾注的心血。
  
  回复
2. verdverm说道：
  
  2026-01-07
  
  等功能更完善时再看吧。功能越少，运行速度自然越快
  
  回复
  1. WD-42说道：
    
    2026-01-07
    
    Zed根本不需要运行网页浏览器，我怀疑它永远达不到“功能繁复”的程度
    
    回复
    1. verdverm说道：
      
      2026-01-07
      
      Zed仍需实现渲染引擎，若不同平台不共享渲染引擎反而会造成多重功能缺失
      但这里用户呼吁的缺失功能，确实需要消耗CPU周期和内存资源
      
      回复
      1. mi_lk说道：
        
        2026-01-07
        
        具体需要哪种渲染引擎？为何Zed必须自行开发？
        
        回复
        
        verdverm说道：
        
        2026-01-07
        
        不确定具体类型，但肯定涉及GPU操作。毕竟没有渲染引擎，屏幕上怎么可能显示任何内容？他们的代码库中必然存在多层抽象结构，涵盖渲染、绘制和布局逻辑。这些内容在其他评论和GitHub上都能看到，无需直接阅读代码。
        
        浏览器引擎本身就是双方都认可的抽象层。对于我们这些不排斥Chromium/Codium/Electron技术的人而言，更倾向于视其为实用且赋能的存在。
        
        在我看来，Chromium/Codium/Electron共享核心引擎，就像众多系统使用Linux内核那样。在我看来，代码拥有越多审阅者、开发者和使用者，长期来看就越能提升质量。
        
        回复
        
        Etherlord87说道：
        
        2026-01-07
        
        没错，关键在于浏览器本身就是极其昂贵的抽象层。这就像用通用机器人建造汽车工厂——虽然灵活多变，但显然专用机械组装线效率更高。
        
        回复
        
        verdverm说道：
        
        2026-01-07
        
        但你必须先自建工厂和装配线，这本身耗时耗力。Zed在字体渲染、GPU调度等基础功能上仍存在问题，过度重绘导致性能不佳。
        
        而Chromium能在数十亿台形态各异的设备上稳定运行。
        
        回复
        
        Etherlord87说道：
        
        2026-01-07
        
        这正是Electron广受欢迎的原因。建造完整工厂成本极其高昂。
        
        回复
joelthelion说道：

2026-01-07

我使用vim已有二十年。它陪伴我经历了编程领域的所有变革——从ctags到语言服务器，再到Copilot的人工智能辅助。

拥有一款可靠的免费软件编辑器，能在所有系统上使用，无需因新潮流涌现或风投决定盈利时机而频繁更换——这种体验令人无比满足。

回复
1. keyle说道：
  
  2026-01-07
  
  我从IntelliJ转用Emacs，再到Zed/VSCode，最终回归Vim…连Neovim都让我烦躁不已。
  
  不知为何，在Vim里我感到自在。我能理解大部分操作机制，虽说不清具体缘由。
  
  调试时我仍用VSCode(断点等功能)，毕竟它最便捷。或许存在某种结合lldb的工作流，能在Vim内部实现调试…
  
  回复
2. the_duke说道：
  
  2026-01-07
  
  更高级的AI相关工作流正是我最终放弃Neovim作为主力编码IDE的原因——至少目前如此。
  
  现有Neovim的AI插件表现欠佳。
  
  回复
julik说道：

2026-01-07

若Zed能完善低DPI字体渲染，我本会毫不犹豫切换。目前效果实在糟糕。

回复
1. veidr说道：
  
  2026-01-07
  
  这点让我很感兴趣，因为几乎每篇Zed相关帖子都能看到类似评论。
  
  我大概…不确定具体年数，但肯定超过十年没用过低DPI显示器了。对我来说，Zed最致命的缺陷是那个"天啊你居然没有GPU!!!! 这下可糟了！"的警告(我通过RDP运行大量Incus容器，它们大多没有可用GPU)。
  
  但你们这些低DPI用户到底用的是什么显示器？是经典的索尼Trinitron显像管电视机之类的吗？我确实很好奇。或者说问题不在显示器本身，而是某种操作系统层面的问题？
  
  回复
  1. Octoth0rpe说道：
    
    2026-01-07
    
    根据定义，我自己不算低DPI用户，但在朋友圈里，似乎只有我在意>160 dpi的显示效果——很多人用的是1440p显示器，或是>34英寸的4K显示器。在苹果的标准里，高DPI(如视网膜屏)需超过218 DPI，所以我的34英寸5120×2160显示器根本达不到他们的门槛。但它确实超过了160 DPI——这才是我个人认定的高清阈值。
    
    市场上符合苹果高DPI定义的20英寸以上显示器本就不多，而符合我宽松标准的也寥寥无几。
    
    回复
    1. drcongo说道：
      
      2026-01-07
      
      我原本想象72dpi就像老式CRT显示器，不过确实认同160是个合理的门槛。
      
      回复
  2. burlesona说道：
    
    2026-01-07
    
    我用的是一台4-5年前的超宽屏显示器，像素密度虽高但DPI值低。虽然喜欢单屏容纳双屏像素的体验，但真希望它能支持高DPI。当年市面上几乎没有高DPI超宽屏可选，如今这类产品依然价格不菲，升级对我而言并非当务之急……不过迟早会换的。
    
    回复
  3. julik说道：
    
    2026-01-07
    
    我的显示器分辨率是2560×1440，算是相当理想的“黄金尺寸”。同等规格的5K至6K显示器价格依然高昂，而且考虑到我在两个地点工作，需要配备两台。我当前使用的显示器(3×2的明基)也存在一定程度的子采样问题，因为在2x模式(“原生视网膜HiDPI”)下运行时，所有UI控件都变得过于巨大，而屏幕空间又不够用。而1倍分辨率模式下(所有元素微小得离谱)既伤眼睛又难以操作——更何况Zed同样遭遇了系统抗锯齿光栅化器的缺陷。
    
    这并非操作系统的问题。系统本身能完美渲染亚像素抗锯齿字体，但Zed使用专属字体光栅化引擎，面对“标准可接受分辨率”的屏幕时便彻底崩溃——字母变得模糊不清，仿佛被粗暴地涂抹过。
    
    回复
    1. kristianp说道：
      
      2026-01-07
      
      当人们在HN上说“我的屏幕是2560×1440”时，指的是Mac缩放后的分辨率吗？感觉分辨率讨论总缺关键信息，这可是非技术人员也能参与的话题。
      
      回复
      1. indymike说道：
        
        2026-01-07
        
        2560×1440属于QHD分辨率，堪称黄金平衡点：足够清晰锐利，又无需像Mac视网膜屏那样进行缩放处理。自从视网膜屏Mac问世以来(我一直用得很满意)，过去五年里我的Linux笔记本始终搭载16英寸和17英寸QHD面板… 实际使用体验完全没问题。
        
        回复
    2. EnPissant说道：
      
      2026-01-07
      
      这取决于你的操作系统。
      
      Linux和Windows在1440p和4K显示器上表现明显更优。两者都支持1440p的子像素渲染和可配置字体提示功能，同时具备4K分辨率的分段缩放界面。而macOS只有在5K显示器上才能达到基本可接受的视觉效果。
      
      回复
  4. mr_toad说道：
    
    2026-01-07
    
    > 但你们这些低DPI用户到底用的是什么显示器？
    
    企业环境里这类显示器依然很常见。实在太便宜了。现在大多数办公桌的成本恐怕都超过了桌上的电脑。
    
    不过话说回来，企业可能还得应对那些无法良好处理高分辨率的古老应用程序。
    
    回复
  5. landtuna说道：
    
    2026-01-07
    
    我实在不明白自己错过了什么。我用着两台旧显示器：27英寸2560×1440和23.5英寸1920×1080(此外还有高DPI的Framework 13屏幕)。在缩放至可读字号(我今年49岁)后，如何才能实现至少4480像素的横向分辨率并覆盖如此大的屏幕尺寸？当前DPI约100，若要翻倍，难道不该是44英寸屏幕搭配8960像素横向分辨率？实在不愿为这点分辨率多花1500美元——毕竟这点提升我的眼睛恐怕也分辨不出来了。
    
    回复
    1. kccqzy说道：
      
      2026-01-07
      
      视力差异很正常。我个人偏好220DPI，但60Hz刷新率完全够用。不过公司里抱怨60Hz的人太多，所有显示器都被换成120Hz了。我完全感受不到额外的流畅度，对我来说纯属浪费。
      
      回复
  6. Gracana说道：
    
    2026-01-07
    
    常规高清液晶显示器才是办公室标配。
    
    回复
  7. jsheard说道：
    
    2026-01-07
    
    实际DPI仍因用户群体差异而参差不齐。Mac设备长期维持在_{200dpi，廉价PC多为}100dpi，而主流PC配置通常采用~150dpi显示屏——这种密度虽高却未达Mac视网膜屏标准。游戏玩家也强烈倾向于这种中间值，因为超高清的Mac式面板通常仅支持60Hz刷新率。
    
    Zed最初是Mac独占应用，这体现在其字体渲染机制上。
    
    回复
    1. veidr说道：
      
      2026-01-07
      
      这倒合乎情理。作为280ppi的拥趸，我对Mac用户颇感同情——我的31.5英寸8K显示器(顺便说一句，这破玩意儿可是2017年的古董)在Linux和Windows系统下完美运行，但Mac只能驱动6K分辨率，导致画面模糊。
      
      除非降到4K分辨率，但macOS在这种设置下根本无法正常使用(所有界面元素都小得离谱)。
      
      但没错，它只有60Hz。自从我意外拿到120Hz显示器后，60Hz就变得糟糕透顶，现在60Hz看起来就像以前的30Hz一样…
      
      显示器分辨率 PPI ───────────────────────────────────────────────────────── 31.5" 8K 7680 × 4320 280 27" 5K 5120 × 2880 218 31.5" 6K 5760 × 3240 210 23 英寸 4K 3840 × 2160 192 27 英寸 4K 3840 × 2160 163 34 英寸 5K 超宽屏 5120 × 2160 163 31.5英寸 4K 3840 × 2160 140 39.7英寸 5K超宽屏 5120 × 2160 140 44.5英寸 5K超宽屏 (LG 45GX950A-B) 5120 × 2160 125
      
      附言：
      
      前几天我在秋叶原的Yodobashi Camera试用了那台LG 45GX950A-B，发现…在必须放置的距离下，那可怜的125ppi可能反而表现得更好。不过话说回来，我50岁的眼睛开始抗议“老兄，你还是戴眼镜吧”，所以…效果因人而异。
      
      回复
      1. jsheard说道：
        
        2026-01-07
        
        实际上218ppi 180Hz面板即将面世，虽然头几年价格肯定贵得离谱。
        
        https://rog.asus.com/monitors/27-to-31-5-inches/rog-strix-5k…
        
        回复
        
        Octoth0rpe说道：
        
        2026-01-07
        
        整体看起来不错，但：
        
        > 支持15W功率传输的USB-C接口，实现最大兼容性
        
        我希望这是笔误。
        
        回复
        
        jsheard说道：
        
        2026-01-07
        
        是的，如果属实的话…这不太理想。LG版本支持90W PD。
        
        https://tftcentral.co.uk/news/lg-27gm950b-5k-monitor-announc…
        
        回复
        
        recursive说道：
        
        2026-01-07
        
        这意味着什么？如果显示器仅需15W即可运行，这应该是个好消息吧？除非显示器的预期功耗低于这个数值？我不太熟悉阅读显示器规格表。
        
        回复
        
        Octoth0rpe说道：
        
        2026-01-07
        
        补充jsheard的说法，要使该功能可用(即只需连接显示器即可为笔记本充电)，这个数值需要接近笔记本充电器功率。以15W的功率，即使是MacBook Air在连接显示器时也会慢慢耗尽电量，前提是你没有给笔记本电脑插入第二根充电线。对于这类功能，65W或90W才是更正常的功率值。
        
        回复
        
        recursive说道：
        
        2026-01-07
        
        这说得通。唯一让我困惑的是，这指的是功率输出。对于显示器而言，这似乎是个小众且微妙的附加功能。我为什么要从显示器获取电力呢？
        
        回复
        
        Octoth0rpe说道：
        
        2026-01-07
        
        > 我为什么要从显示器获取电力呢？
        
        无论在工作还是在家中，我都能用一根线缆将显示器连接到笔记本电脑上。这条线既能给笔记本充电，又能连接显示器，还能通过显示器内置的USB集线器连接键盘和网络摄像头。这简直太方便了。而且线缆也少很多。你可以把它看作是显示器内置的免费扩展坞。
        
        > 这似乎是个小众功能
        
        不同的工作流程/圈子。这种功能不太可能用于台式机，主要适用于笔记本电脑。而且只有使用雷电接口才能发挥其真正作用。在我工作的环境中，这种功能相当普遍，但可能并非主流——90%的开发机都是Mac。
        
        recursive说道：
        
        2026-01-07
        
        充电和视频传输共用一条线缆非常酷。我收回之前的话。
        
        jsheard说道：
        
        2026-01-07
        
        这是输出功率。USB-C显示器通过单根线缆连接时，可为笔记本电脑充电。
        
        回复
  8. karmakaze说道：
    
    2026-01-07
    
    我的42.5英寸4k LG显示器分辨率为104 DPI，按macOS标准属于低分辨率。
    
    回复
2. r4victor说道：
  
  2026-01-07
  
  这是在 Linux 上吗？
  
  回复
  1. ed_blackburn说道：
    
    2026-01-07
    
    是的。还有 Windows。
    
    https://zed.dev/docs/linux
    
    回复
3. EnPissant说道：
  
  2026-01-07
  
  我以前也有同样的抱怨，最近换成了 4k 显示器。我以为这能解决 Zed 字体的问题，但文本显示效果仍然很差。在 Zed 中，每行之间的间距似乎比 VSCode(或其他文本编辑器)明显更大。
  
  回复
4. drcongo说道：
  
  2026-01-07
  
  能解释一下你为什么使用低 DPI 显示器吗？我大概十年都没见过这种显示器了。
  
  回复
  1. gkbrk说道：
    
    2026-01-07
    
    1080p是目前最主流的屏幕分辨率，在普通显示器上1080p属于“低DPI”。
    
    https://store.steampowered.com/hwsurvey
    
    回复
    1. evanjrowley说道：
      
      2026-01-07
      
      全球最普遍的电脑屏幕分辨率竟被 Zed 项目视为小众需求而不予支持，这让我感到难以置信。希望 2026 年情况能有所改变？
      
      回复
      1. Octoth0rpe说道：
        
        2026-01-07
        
        游戏玩家市场与开发者市场虽有重叠，但并非完全一致。而在重叠领域，开发者使用的显示器往往与游戏玩家不同。
        
        回复
      2. freehorse说道：
        
        2026-01-07
        
        我并不否认有些人会遇到某些问题，但我长期在macOS系统上使用zed搭配1080p和1440p的24英寸显示器，从未遇到过字体渲染问题。说“zed在低dpi显示器上无法良好渲染字体”有些言过其实。
        
        回复
      3. stouset说道：
        
        2026-01-07
        
        或许你该把震惊留给那些连像素数量和像素密度都分不清的GP(注：原文GP疑似指某软件或概念，此处未明确)的场合。
        
        Zed对1080p显示器的“支持”毫无问题。之所以加引号，是因为它根本无需处理屏幕上的像素数量，也完全不在意这些数字。
        
        回复
        
        gkbrk说道：
        
        2026-01-07
        
        若左图[1]也能称作“支持1080p”，那Zed确实算支持。但VS Code等编辑器似乎能更清晰地呈现，不会出现模糊现象。
        
        需知Zed开发者[2]将低DPI显示器字体模糊视为一级优先级问题，且这是个可复现的常见缺陷。
        
        我确信若Zed不存在字体模糊问题，他们早就关闭这个错误报告了。
        
        [1]: https://ibb.co/zVS0Qz6z
        
        [2]: https://github.com/zed-industries/zed/issues/7992
        
        回复
        
        stouset说道：
        
        2026-01-07
        
        低DPI字体与1080p分辨率是两个独立的问题。像素数量与像素密度并非同一概念。
        
        回复
    2. stouset说道：
      
      2026-01-07
      
      1080p既非高DPI也非低DPI(每英寸点数)。DPI需结合屏幕物理尺寸计算，而非单纯像素数量。
      
      回复
      1. mkl说道：
        
        2026-01-07
        
        试着找块足够小却算高DPI的1080p屏幕吧——这样的屏幕寥寥无几！若采用本帖其他讨论提出的218ppi阈值，则需10英寸1920×1080屏幕才能达到，因此1080p电脑屏幕几乎必然属于低DPI范畴。
        
        回复
    3. drcongo说道：
      
      2026-01-07
      
      “1080p是目前最主流的屏幕分辨率”——这仅适用于使用Steam的用户(可能为优化帧率或连接电视而选择)，但若不了解屏幕物理尺寸，此说法毫无意义。1080p是屏幕分辨率，DPI则是屏幕密度——手机上的1080p屏幕DPI其实相当高。
      
      回复
  2. freehorse说道：
    
    2026-01-07
    
    如今许多人将1080p/24英寸屏幕称为“低DPI”。不过不清楚楼主实际使用的是哪种配置。
    
    回复
  3. Octoth0rpe说道：
    
    2026-01-07
    
    先定义低DPI。苹果标准是>218dpi，远高于4k@27英寸显示器——这已是市售最小尺寸的4k显示器(15英寸便携屏除外)。
    
    回复
  4. aldanor说道：
    
    2026-01-07
    
    或许你用的是49英寸屏幕？
    
    回复
ach11235说道：

2026-01-07

Zed很不错。我日常用neovim写代码，但需要私密且界面友好的AI代码编辑器时就会切换到Zed，它自带的vim模式也相当不错。

回复
the__alchemist说道：

2026-01-07

完全同意它是VSCode的绝佳替代品！关于作者提到的键位映射相似性：其实你也能轻松切换成其他常用编辑器的键位布局，这对迁移体验至关重要。更欣赏他们用高效语言实现的“正确”设计理念——这体现在始终如一的超低延迟上。

但在我看来，它无法替代Jetbrains系列IDE(如PyCharm、Rustrover)。我确实偶尔会在平板上用它替代那些运行迟缓的IDE。除非我遗漏了某些必装插件，否则在代码检查、重构、导入添加与移动、实时错误检查以及整体理解代码库等方面，它仍与这些IDE不在同一水平。

因此我的方案是：高性能PC用Jetbrains(尽管它仍能让9950x处理器吃不消…)，低配设备用Zed。

单文件编辑则用Sublime，因为JB和Zed都是面向项目的。

回复
Surac说道：

2026-01-07

可惜我无法摆脱VSCode的束缚。如今多数芯片厂商都采用VSCode+插件的方案，为你提供微控制器编程工具链。他们(谢天谢地)放弃了专有IDE的尝试，重新专注于芯片和编译器。他们发现了VSCode，现在你就必须使用它。我对现状非常不满，正在跳槽寻求从嵌入式转向应用程序开发

回复
1. the__alchemist说道：
  
  2026-01-07
  
  具体是哪些微控制器？我主要编程对象是STM32、ESP32(Risc-V架构)和Nordic芯片，所有工作都在RustRover中完成。编译过程与编辑器解耦。(通过cargo run构建并调试烧录，或点击运行IDE按钮；操作逻辑与普通程序无异)编辑器本应服务于代码结构而非芯片特性。Cube IDE虽可辅助配置时钟、内存布局及外设信息(作为参考手册的补充)，但编写代码时并非必需。
  
  回复
  1. sampullman说道：
    
    2026-01-07
    
    您是在专业环境中这样操作吗？我很好奇，因为大约十年前我做过嵌入式/微控制器开发，考虑到当时C/C++ SDK(及IDE支持)的现状，我本以为Rust需要数十年才能站稳脚跟。
    
    回复
    1. the__alchemist说道：
      
      2026-01-07
      
      没错；我在工作中(为国防承包商做安全相关传感器)和自己的小公司都这么干。它还没站稳脚跟，可能永远都站不稳；走着瞧吧。我觉得网上看到的很多Rust嵌入式内容，都是些热衷于玩所有权系统和异步操作花招的创客。所以我是个例外，但…尽管它不流行，我还是推荐这种工作流！
      
      我纯粹欣赏Rust的整体语言特性和工具链(比如上述工作流)，对常被强调的内存安全特性倒没那么在意。
      
      最大缺点是需要大量基础工作，用C或C++就不会有这些麻烦。例如根据数据手册和参考手册实现硬件接口。虽然有时能找到现成的Rust库，但根据我的经验，它们很少能直接使用。
      
      回复
      1. inferiorhuman说道：
        
        2026-01-07
        
        作为开发过多个异步HAL的业余爱好者，我认为Rust非常适合嵌入式开发，但确实存在门槛。该语言尚不成熟，虽然像Embassy这样的工具令人愉悦，但它们缺少许多(有时看似基础的)功能。
        
        回复
  2. Surac说道：
    
    2026-01-07
    
    主要涉及采用德州仪器CMSIS的Arm系统。
    
    回复
    1. inferiorhuman说道：
      
      2026-01-07
      
      因此我认为你和前文回复者讨论的是两个不同概念：有HAL支持与无HAL支持的软件开发。
      
      ARM架构的普及推动了标准化进程。开发者不再受限于厂商专属编译器和工具链。只要愿意重新实现大部分HAL功能，就能自建开发环境。当然这一切也取决于厂商提供的CMSIS软件包和文档质量。
      
      Rust同样具备此特性，且在Cortex-M架构领域(Xtensa和RISC-V支持稍逊)已相当成熟且支持完善。用于创建寄存器轻量封装层(即外设访问库——PACs)的工具链现已相当完善。
      
      若寻求类似官方HAL(如CubeMX、Atmel Studio)的解决方案，Rust在此领域尚显稚嫩，这主要源于其发展周期较短。Rust生态中存在多种HAL框架，实际应用中往往需要组合使用。Embassy(融合异步框架与HAL组件的解决方案)若能满足需求，其设计相当精妙。
      
      回复
2. Neywiny说道：
  
  2026-01-07
  
  笑死，厂商要么不做要么做错，我只能自己动手移植。看到同行离开嵌入式领域真令人惋惜，我们本该团结协作。
  
  回复
3. webdevver说道：
  
  2026-01-07
  
  我可能脑子有问题，居然喜欢他们推出的Eclipse IDE，至少STM32版本还行
  
  回复
  1. Surac说道：
    
    2026-01-07
    
    强烈推荐smt32cubeMX。
    
    回复
Lramseyer说道：

2026-01-07

尽管我热爱Zed，但我认为VScode(及其衍生版本)仍将在很长一段时间内主导自建IDE领域——除非Zed能支持基于Web的扩展。我曾为芯片设计师开发过VSCode扩展，很想移植到Zed平台，但由于该扩展基于自定义WebView实现可视化功能，目前无法实现。

我深知其中的讽刺之处——Zed的快速运行恰恰源于其非Web架构，但我仍坚持认为：可选Web界面显示功能将极具价值，它将为众多扩展开发打开大门。

回复
bjackman说道：

2026-01-07

Zed比VSCode更快更顺手，我迟早会永久转用它。

目前唯一的硬性障碍是缺少调用图导航组件。在VSCode中，函数调用者可展开成可折叠的树状结构。不知为何，我解读复杂代码时竟完全依赖这个微小功能！

更恼人的是：有人会问“加个扩展不就行了？”不行，Zed的扩展受限太多——它不是网页浏览器。我喜欢这种纯粹的设计！但…我的小工具啊…

搜索大型远程仓库时还存在性能问题，不过我确信这会得到修复。

回复
1. gabeidx说道：
  
  2026-01-07
  
  “查找所有引用”(Opt+Shift+F12)功能能否缓解你的问题？它会打开可导航的缓冲区，这是内置功能而非扩展。
  
  还是说你需要更直观的树形视图？
  
  回复
  1. bjackman说道：
    
    2026-01-07
    
    确实需要树形视图。要能查找所有引用，以及引用的引用，以此类推。
    
    回复
koito17说道：

2026-01-07

我曾是Emacs的日常用户(工作和个人项目都用)。一年多前尝试Zed后，现在只用Emacs处理Magit和偶尔通过内置ERC客户端发送IRC消息。

VS Code用户其实有个特殊功能：部分VS Code设置可迁移至Zed设置。虽无法保证稳定性，但功能确实存在。

非常怀念Lisp语言的REPL功能，但对于Rust和TypeScript这类静态类型语言，Zed的表现相当出色。尤其欣赏它能与Nix和Direnv无缝协作，即使处理远程项目也流畅自如。不过协作功能确实需要更多优化——感觉这部分功能正逐渐蜕变，每当Linux端的朋友无法共享屏幕时，总令人遗憾。此外还有些小问题，比如连接外接显示器的MacBook音频位深度错误——实验性的Rodio后端确实修复了这个问题，但我不确定它是否已稳定。

不过AI相关功能相当稳定，不到一年就取得如此进展令人惊叹。调试器界面等功能同样如此。

回复
1. insane_dreamer说道：
  
  2026-01-07
  
  > 现在我只用Emacs来操作Magit
  
  试过lazygit吗？这是我的首选工具，甚至能在Zed的面板里运行。
  
  回复
awfulneutral说道：

2026-01-07

我走在潮流前沿，我的升级路径是VSCode→Zed→Helix。Helix的续航是Zed的两倍，从4小时提升到8小时。我认为Zed的发展轨迹也不妙，他们总在疯狂推送大量更新。

回复
1. theappsecguy说道：
  
  2026-01-07
  
  发展轨迹具体哪里不好？他们持续添加功能却毫无臃肿感，只是作为新生代编辑器迭代速度快罢了。比起Jetbrains那庞然大物般的臃肿，我反而乐见这种迭代速度。
  
  回复
  1. awfulneutral说道：
    
    2026-01-07
    
    确实，这让我想起VS Code的早期阶段——功能持续迭代初期令人兴奋，但开发者毫无节制地堆砌功能，最终导致编辑器变得迟缓臃肿。有时我不得不花时间修复或重新配置某些设置，仅仅因为打开编辑器时每日自动更新搞出了烦人的问题。Zed或许不会这样，但其开发思路似乎如出一辙。
    
    回复
traceroute66说道：

2026-01-07

Zed是否具备类似VSCode开发容器的功能？

这正是我坚持使用VSCode的少数理由之一。

例如我经常编写Ansible剧本。VSCode能直接启动Ansible提供的开发容器，包含所有依赖项，这样就不用在本地系统里堆满这些东西了。

回复
1. pacha3000说道：
  
  2026-01-07
  
  开发容器功能将在未来几周内上线，目前处于测试阶段
  
  回复
2. stusmall说道：
  
  2026-01-07
  
  这属于“类似功能”范畴，但其direnv支持非常出色https://zed.dev/docs/configuring-zed#direnv-integration
  
  虽然无法完全替代Ansible配置文件，但我发现按项目编写Nix开发环境配置成本低且收益高。若仅需特定版本Ansible，几行代码即可实现
  
  回复
  1. verdverm说道：
    
    2026-01-07
    
    用户想要的是容器，而非Nix、Ansible或开发环境
    
    为何不采用真正的可移植方案——使用 OCI？
    
    回复
3. crabmusket说道：
  
  2026-01-07
  
  他们似乎在推进此事，但目前仅限于预览版构建？https://zed.dev/docs/dev-containers
  
  回复
  1. traceroute66说道：
    
    2026-01-07
    
    感谢链接，看起来很有前景，尽管初始版本已知限制中“不支持独立扩展”这点或许稍显遗憾。
    
    回复
childintime说道：

2026-01-07

似乎很少有人记得微软正在加速TSC(TypeScript编译器)，进而提升VSCode性能：https://devblogs.microsoft.com/typescript/typescript-native-…

回复
1. presentation说道：
  
  2026-01-07
  
  若您是TypeScript开发者，请注意此处指的是类型推断和编译性能，而非运行时编译代码的表现。
  
  回复
callumprentice说道：

2026-01-07

我曾尝试使用Zed数月，但始终无法让JavaScript/Python语法检查和Prettier类型重排功能稳定运行。每次折腾几小时勉强搞定，几天后又莫名失效。

现在转用VSCode后，这部分功能稳定性明显提升，但总体而言我更偏爱Zed的操作手感。

已收藏这篇文章，希望能找到让设置持久化的方法。

回复
1. aratahikaru5说道：
  
  2026-01-07
  几个月前我遇到同样的TSX文件问题，最终回到了Sublime。刚通过你的评论和搜索发现Zed其实有全局强制Prettier的设置：
```
  “prettier”: {
    “allowed”: true
  },
```
  回复
  1. callumprentice说道：
    
    2026-01-07
    
    我会试试看——谢谢。
    
    回复
2. dminik说道：
  
  2026-01-07
  
  挺有意思的，但我经历了完全相反的情况。我无法让VSCode在多个项目中稳定格式化TypeScript/React代码——有时能成功，有时失败，有时虽然格式化了但设置错误。
  
  无奈之下我转用Zed，此后再未遇到这个问题。
  
  回复
  1. callumprentice说道：
    
    2026-01-07
    
    真有意思。能分享你公开的Zed配置吗？我换用Zed前用的配置还留着，想对比看看。
    
    回复
emilecantin说道：

2026-01-07

我从tmux/nvim环境转用Zed。这是我用过的首个Vim模式足够完善的编辑器，让我能保留原有的肌肉记忆。

回复
1. cpt_sobel说道：
  
  2026-01-07
  
  我尝试从vim/Idea Suite搭配IdeaVim转用Zed，但遗憾的是无法直接使用我的.vimrc配置。这个问题修复了吗？目前这仍是阻碍我转用的唯一因素。
  
  回复
guiambros说道：

2026-01-07

被Slashdot报道了 🙂

附文链接：https://web.archive.org/web/20260105144155/https://tenthousa…

回复
1. r4victor说道：
  
  2026-01-07
  
  现在能用吗？这是台1核/1G内存的VPS——可能太小了，扛不住HN的拥抱。
  
  网站代码库是公开的，所以GitHub上也有：https://github.com/r4victor/tenthousandmeters/blob/master/we…
  
  回复
2. cube00说道：
  
  2026-01-07
  
  奇怪，明明是静态网站却仍被流量淹没。
  
  回复
  1. cube00说道：
    
    2026-01-07
    情况不对劲，20小时后我这边依然超时。
    
    curl https://tenthousandmeters.com curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
    回复
rahen说道：

2026-01-07

我对Zed编辑器的唯一不满是无法将两个侧边栏面板上下并排显示。不仅无法同时显示，切换时还得点击状态栏里微小的按钮。更糟的是，执行搜索时符号和树状视图都会被隐藏。

所以目前我还是坚持用Emacs。

回复
ddoolin说道：

2026-01-07

Zed是我近两个月唯一使用的编辑器。但其扩展生态仍严重匮乏，API也尚未完善。尽管如此，我依然钟爱它的设计理念、内置AI功能以及诸多独特差异点。

回复
dejw说道：

2026-01-07

Zed、VSCode、Antigravity、Sublime Text…它们的工作流程如出一辙。手写代码推荐Helix，功能齐全且高效。AI辅助开发则无特定首选，若追求最佳体验需每四个月更换一次工具。

回复
1. heybales说道：
  
  2026-01-07
  
  终端文本编辑已全面迁移至Helix，强烈推荐。除主题调整外基本无需配置。
  
  遗憾的是我仍在摸索AI工作流。目前混合使用Cursor、Claude Code和JetBrains Rider：主要用Cursor完成AI重型任务，再切换到Rider和Claude Code进行调试微调。若Cursor对.NET调试不那么糟糕，或许就能独立完成所有工作。
  
  回复
plqbfbv说道：

2026-01-07

过去几周愉快地使用Zed编辑器。最初选择它是因为其主要采用Rust语言开发，预期能获得更优性能和稳定性(相较VSCode，界面重绘速度快得离谱)，同时我也希望迁移基于代理的代码流程。

令人惊喜的是AI部分基本实现即配即用：GitHub Copilot登录使用、MCP服务器配置、自定义MCP服务器部署都轻松搞定。VSCode在这方面简直令人抓狂：Copilot时常崩溃，MCP服务器自动启动功能尚未实现(需要依赖扩展，且十次只能成功八次)，自定义服务器配置我甚至懒得尝试。而在Zed中，我只需将建议的自定义服务器启动命令复制粘贴到其提供的JSON数组中，它便能在独立线程中启动MCP服务器，毫无麻烦。每次重启编辑器时，自动启动功能都可靠运行。

回复
zmk5说道：

2026-01-07

我真心喜爱Zed，唯一问题是其默认的Emacs键绑定似乎不如VSCode的Emacs扩展好用。希望后续更新能解决这个问题。

回复
1. cpt_sobel说道：
  
  2026-01-07
  
  我在Vim支持方面遇到类似问题，虽然内置支持很贴心，但目前无法指向自定义的.vimrc文件。这对我而言实在是个致命缺陷。
  
  回复
2. necubi说道：
  
  2026-01-07
  
  同感。我每隔几个月就会尝试使用，但每次都因Emacs模式不够完善而放弃。不过它确实正在缓慢改进。
  
  回复
3. xpe说道：
  
  2026-01-07
  
  这可是来自Emacs用户的高度评价 🙂 我过去也曾愉快地使用Emacs，但现在对Zed更满意。
  
  Zed目前存在诸多待解决问题，或许这些信息对你有帮助？以下是标记为“area:parity/emacs”的已提交问题列表。部分问题还标注了“state:needs repro”(需复现)。不知是否存在您遇到的痛点？您的反馈或许能加速解决这些问题？
  
  https://github.com/zed-industries/zed/issues?q=is%3Aissue%20…
  
  回复
_sinelaw_说道：

2026-01-07

我也厌倦了臃肿的软件，更喜欢在终端中工作。

我正在开发Fresh [0] [1]作为VSCode的替代方案，它能在终端中运行，核心目标是实现开箱即用的便捷性(而非vi克隆的模态编辑器)，例如原生支持鼠标操作、菜单、命令面板等功能，同时兼容LSP。我致力于实现最小化甚至零配置的便捷使用体验。

[0] https://github.com/sinelaw/fresh [1] https://sinelaw.github.io/fresh/

回复
1. reflog说道：
  
  2026-01-07
  
  最近刚发现Fresh。太棒了！完全复刻了Sublime+Turbo Pascal的操作体验。所有快捷键都完美兼容。感谢！
  
  回复
avanwyk说道：

2026-01-07

其他人也有同感，但我不仅从VSCode转用Zed，还下定决心认真学习Neovim(Lazyvim)，从此再未回头。编写代码的激情又回来了。推荐使用https://github.com/adomokos/Vim-Katas这类工具加速肌肉记忆训练。浏览器端的Vimium插件也相当出色。

回复
jaredcwhite说道：

2026-01-07

我通过code-server自建服务器运行“VSCode”，这样就能在包括iPad在内的任何设备上启动IDE。虽然仍在使用code-server，但当我在Mac/Linux桌面端(没错我两台都有！)时，越来越倾向于使用Zed——它的体验已经变得非常出色。唯一缺失的重要功能是可视化Git图谱，不过需要时仍可加载code-server，倒也无妨。

真正让我惊喜的是Zed能远程连接服务器，且完美兼容Solargraph LSP和Rubocop等Ruby工具链。界面设计极简清爽，响应速度极快，实属佳作。

回复
mirawelner说道：

2026-01-07

我真心喜欢Zed，因为它运行迅捷且不会擅自执行代码。我极度厌恶IDE的“运行”功能——当年在Eclipse学Java时，花了大量时间才学会终端运行命令。Zed兼具完整IDE的编辑与高亮功能，却强制用户通过终端执行代码。若配置了Zellij或其他多路复用器，它会自动在Zed终端运行。

回复
andreldm说道：

2026-01-07

这个周末我再次尝试Zed，这次没在一小时内就卸载它。它变得更成熟了，虽然还有些瑕疵，但整体终于变得顺手了。令人惊讶的是VSCode的肌肉记忆竟如此适用，开发者们避免重复造轮子而优化迁移体验值得称赞。我期待终能摆脱VSCode——这种不惜代价的AI无处不在，正将编辑器(它本想成为IDE)变成大多数用户不需要也不想要的东西。

回复
temporallobe说道：

2026-01-07

我尝试过切换到Zed，甚至能让它使用与VSC中我偏好的主题和键位映射完全一致的设置，但最终还是因缺少我依赖的插件而回退，更不用说某些关键功能差异了。在性能方面，我并未感受到相较VSC的显著提升(毕竟我使用的是配备32GB内存的M4设备)，因此这次转换终究得不偿失。我真心希望喜欢Zed，今后仍会关注其新版本发布。顺带一提，在老款英特尔架构的MacBook Pro上，Zed确实比VSC快得多！

回复
habosa说道：

2026-01-07

我也注意到。原本只是好奇速度提升是否明显……哇，确实如此。使用体验非常棒。

VSCode仍更成熟，我会保留安装，但使用Zed一个月后已深深喜爱它。

回复
meander_water说道：

2026-01-07

若需更优质的Python语言服务器，推荐ruff。v0.4.5版本已完全采用Rust编写，速度远超pylance。

安装ruff插件后默认会启用该服务，Zed编辑器同样支持使用。

回复
bargainbin说道：

2026-01-07

我转用Helix和ZelliJ后，发现ZelliJ能实现多种IDE功能，而Helix如同Vi的界面层。

二者结合后成为极具威力的工作流！

回复
1. nbf_1995说道：
  
  2026-01-07
  
  能否详细说明Zellij的使用方式？我试用过，知道它能实现类似tmux的分屏和标签功能。但若它能与Helix配合实现类似IDE的工作流，我可能会重新考虑使用。
  
  回复
artur-gawlik说道：

2026-01-07

我使用vscode已有数年。通过禁用“chat.disableAIFeatures”选项关闭所有AI功能后，实际体验非常理想。但这篇文章让我决定尝试zed——主要被其性能优势所吸引，毕竟它是原生语言编写的而非基于javascript。测试时我打开了 https://github.com/microsoft/TypeScript/blob/main/src/compil…文件，执行“ctrl + o”命令后zed直接卡死。此外在zed中滚动该文件时帧率明显下降，而vscode打开checker.ts文件时的滚动非常流畅。看来我还是继续用vscode吧 🙂

回复
1. artur-gawlik说道：
  
  2026-01-07
  
  此外，目前正在努力让主编辑器通过WebGPU而非DOM节点进行渲染，我对此充满期待。
  
  回复
  1. artur-gawlik说道：
    
    2026-01-07
    
    该功能进展可通过此问题跟踪：https://github.com/microsoft/vscode/issues/221145
    
    回复
jeorb说道：

2026-01-07

Zed 非常出色，几乎要成为我最爱的文本编辑器(超越 Vim)，但仍存在诸多未完善之处。

本周末我耗费大量时间排查项目中的错误——Zed 的保存格式化功能偶尔会删除 Python 类的第一行代码。

关闭保存格式化后问题解决，但文本编辑器出现这类数据丢失的 bug 实在令人困扰。

回复
kopirgan说道：

2026-01-07

我并非专业程序员，只是偶尔为娱乐或赚点外快写写代码。Helix作为编码工具表现出色——相比Neovim，它能轻松实现Go和C语言的LSP功能。唯一不足是我尚未掌握调试技巧，这对于严肃程序员而言恐怕是必备技能。我最爱printf，它足以满足我在Go、awk、C、Excel VBA宏和JS中的需求！

回复
kristianp说道：

2026-01-07

我已许久未尝试zed和vscode，但向来不喜欢vscode那些干扰元素，比如方法信息提示。

我试用Zed时遇到的问题是：我在Linux/KDE环境下使用时，Zed显示的是汉堡菜单，而在Mac上却是标准的应用程序菜单。它也没有我预期的菜单快捷键，比如Alt+F打开文件菜单——这是许多应用程序从Windows移植到Linux时保留的专属规范。我依然更喜欢Sublime Text的用户界面。

回复
kneel25说道：

2026-01-07

我痴迷Zed编辑器，从Windows版发布当天开始使用就再未回头。主题完美契合我的需求，开发团队极其勤奋，每次安装他们频繁推送的更新仅需一秒多，这种流畅体验令人愉悦。

回复
dgllghr说道：

2026-01-07

我渴望转换平台，但Mac的电池消耗实在太高！我习惯在家中不同角落工作，因此电池续航能力对我至关重要(更不用说偶尔出差的需求了)

回复
1. r4victor说道：
  
  2026-01-07
  
  嗯，我在M1版MacBook Pro上发现Zed的耗电量低于VSCode。活动监视器显示平均12小时耗电量约100与约200。你是否也对比过VSCode？
  
  回复
  1. dgllghr说道：
    
    2026-01-07
    
    没错，我的机器上VSCode耗电量远低于Zed。我认为这可能与以下问题有关：
    
    https://github.com/zed-industries/zed/issues/21146 https://github.com/zed-industries/zed/issues/8043
    
    回复
gdotdesign说道：

2026-01-07

我仍在观望Zed的评估时机，因为我使用的编程语言支持LSP语义高亮功能，而Zed尚未实现https://github.com/zed-industries/zed/pull/39539等该功能合并后我会尝试，毕竟它看起来像现代版的Sublime Text(我仍在使用)。只希望开发者专注基础编辑器功能，别总添加AI等无关特性。

回复
1. tortilla说道：
  
  2026-01-07
  
  我已从Sublime Text转用Zed(但仍保留Sublime处理超大文件)。
  
  不过我欣赏Zed的设计理念，界面美观度对我而言很重要。
  
  虽然不常用其AI功能，但当需要快速获取替代方案或新视角时确实实用。我会在独立终端中使用Claude Code。
  
  回复
jackhuman说道：

2026-01-07

Zed最吸引我的功能是精妙的键盘快捷键和窗口管理。终端可作为普通标签页存在，能轻松在编辑器、文件浏览器间切换。

但正如开发者所言，某些行为可能令人困扰。我最介意的是Zed保存文件时自动添加换行符。以前能在设置中禁用此功能，但很久以前的更新破坏了这个选项。或许有人能告诉我这个功能已修复，但看来我得去GitHub问题跟踪页寻找解决方案了——之前查过没找到。

回复
capitanazo77说道：

2026-01-07

真想读到这样的文章：“我没换编辑器是因为我的编辑器完美无缺，顺便说下我用的是Neovim”

回复
xutopia说道：

2026-01-07

Zed的响应速度远胜VSCode，Vim模式也深得我心。

回复
RamblingCTO说道：

2026-01-07

我也做了同样的切换，非常满意。偶尔Zed会占用过多CPU(可能是Claude代码库导致？)，但完全可以接受。整体运行流畅，目前仅因CC引发过一次崩溃。

回复
Koshkin说道：

2026-01-07

不支持CMake(VSCode、emacs、nvim都支持)。

回复
dv_dt说道：

2026-01-07

我从VSCode切回Sublime Text了哈哈。需要AI辅助时直接在终端用Claude-code或其他命令行工具，这样更专注少干扰

回复
hliyan说道：

2026-01-07

首次试用发现其“大纲面板”(Ctrl+Shift+B)功能相当实用，至少在测试的C++代码库中表现出色。

回复
克苏鲁_说道：

2026-01-07

Zed 当初也大力推广其 AI 功能。刚推出时宣传口号是“你的编辑器，但基于 Rust / 非 Electron 架构，因此速度极快”，但大约两年前他们开始强力转型为 AI 编辑器。如今所幸 AI 功能虽存在但不显突兀。

作者还提到怀念侧边文件栏，其实它只是左下角图标之一。

回复
1. honeycrispy说道：
  
  2026-01-07
  
  配置文件中添加“disable_ai”: true即可禁用所有AI功能。
  
  回复
  1. mrgoldenbrown说道：
    
    2026-01-07
    
    Visual Studio Code也有类似的全局AI禁用选项。
    
    回复
  2. Cthulhu_说道：
    
    2026-01-07
    
    我猜他们是因用户反响才添加这个功能…或者我把它和Warp搞混了——那个同样基于Rust的超快终端应用，最初需要登录，后来才推送AI功能。
    
    回复
    1. jasonjmcghee说道：
      
      2026-01-07
      
      不，你第一次说得对——那是Zed。我认为Warp的核心用户群是AI用户，以及传统意义上低/非终端用户。
      
      回复
replete说道：

2026-01-07

对个人而言切换很简单，但对组织来说生态系统通常难以割舍。希望几年后情况能改变。

回复
1. jonkoops说道：
  
  2026-01-07
  
  组织由个体构成，若整个组织运作依赖特定IDE才能运转，这本身就是个大问题。
  
  回复
  1. replete说道：
    
    2026-01-07
    
    生态系统。
    
    回复
    1. spiderice说道：
      
      2026-01-07
      
      若组织“生态系统”被特定编辑器捆绑，说明该组织存在重大问题。
      
      回复
2. the__alchemist说道：
  
  2026-01-07
  
  是否存在强制规定编辑器的公司/机构？通常是大企业吗？涉及哪些国家？
  
  回复
Matl说道：

2026-01-07

我想从JetBrains的编辑器转用Zed，但已习惯[1]功能，除JetBrainsIDE外似乎没有其他编辑器愿意以JetBrains的方式实现该功能。

1 – https://github.com/zed-industries/zed/issues/7721

回复
1. jasonjmcghee说道：
  
  2026-01-07
  
  JetBrains在功能设计上考虑周全。
  
  某些核心功能开箱即用的体验远胜其他编辑器最优秀的插件。
  
  例如：带搜索功能的本地历史记录(甚至支持选区历史记录)、堆叠剪贴板、最近位置记录、卓越的搜索能力(文本/符号/操作等)、模态缓冲区机制、调试体验、版本控制合并体验等等
  
  已修复的旧问题：
  
  – 插件管理曾极其糟糕
  
  – 曾经不支持LSP
  
  (开发ron-lsp[1]插件时令人惊喜地发现已修复)
  
  长期存在的问题：
  
  – 体积庞大且运行迟缓
  
  – 存在诡异的崩溃模式
  
  尽管如此，它仍是我的主力IDE，同时频繁使用精心配置的Neovim。
  
  —
  
  [1]: https://github.com/jasonjmcghee/ron-lsp/tree/main/jetbrains-…
  
  回复
  1. rrgok说道：
    
    2026-01-07
    
    没错，当这些想当编辑器的IDE能提供JetBrains级别的调试器和全局搜索(真正跨文件、跨操作的搜索)时，我或许会考虑更换。
    
    令人惊讶的是它们都把调试功能当作次要功能。难道这些开发者还在用printf调试？
    
    回复
dmix说道：

2026-01-07

我尝试从Cursor转用Zed，但其LLM集成仍显稚嫩。Cursor在开发体验上遥遥领先，且其各类模型/令牌的定价相当合理。对于习惯终端LLM命令行界面、更偏好结构化操作而非深度IDE集成的用户，Zed或许是个不错的折中选择。

回复
tigerlily说道：

2026-01-07

Zed用Zed开发本身的设计理念深得我心。正因如此，我认为它有望成为Rust开发的首选编辑器。

回复
wateralien说道：

2026-01-07

我最近也从Cursor切换到Zed编辑器，并迁移了自定义主题：https://zed-themes.com/themes/ldw3jOWS7edS-gifHtZg9?name=Dar…

回复
btbuildem说道：

2026-01-07

Zed轻量又出色，唯一阻碍它成为我日常编辑器的因素是git集成不足(特别是缺少历史树功能)。据我所知，这些功能最终会实现。

回复
1. onehair说道：
  
  2026-01-07
  
  接触Zed之前，我曾深陷Helix的魅力。那款编辑器甚至没有插件功能xD。习惯将Wezterm拆分并启动lazygit在第二面板操作后，我几乎忘记了在使用Helix之前对JetBrains git集成的依赖：P
  
  回复
2. WA说道：
  
  2026-01-07
  
  Zed的内联Git差异显示让我困惑。我需要整文件的并排对比功能，这目前是我的硬性需求。
  
  回复
  1. putna说道：
    
    2026-01-07
    
    同感。完全看不懂Zed的Git差异功能
    
    回复
3. insane_dreamer说道：
  
  2026-01-07
  
  我也这么觉得。PyCharm在这方面仍遥遥领先。我用lazygit弥补了这个缺陷(尽管PyCharm仍是目前用过最好的)。
  
  回复
bestest说道：

2026-01-07

从Webstorm转用Zed。唯一问题是Zed不支持垂直制表符。虽然提交了PR但被拒，理由是与开发里程碑不符。目前只能通过在上游同步后对开发版进行猴子补丁来使用。

回复
1. xpe说道：
  
  2026-01-07
  
  我必须承认对垂直制表符的工作流程知之甚少。很好奇：你是什么时候突然开窍的？是 VS Code 让你入坑的？还是某个网页浏览器？
  
  回复
  1. adhamsalama说道：
    
    2026-01-07
    
    这是我第一次看到有人讨论编辑器里的垂直标签页，不过以前我也总嘲笑别人用浏览器里的垂直标签页，直到我自己试用后就习惯了——看来我该试试编辑器的垂直标签页了…
    
    回复
wseqyrku说道：

2026-01-07

为此我得先转投Rust语言，这意味着要彻底改变职业方向。现在很想切换到Linux桌面，但得先腾出时间。这大概意味着我该退休了？

回复
tlhunter说道：

2026-01-07

遗憾的是Zed在Linux上不支持惯性滚动。这正是我迟迟不跳槽的主要原因。

这也是我至今仍用Firefox系浏览器而非Chromium系的原因。

回复
lvl155说道：

2026-01-07

Zed作为如此不完善的产品，在开发者中却颇受欢迎。看来他们乐于浪费时间使用功能缺失的工具。这些我都能原谅，但Zed拥有我近年用过最糟糕的界面设计。

回复
1. _sinelaw_说道：
  
  2026-01-07
  
  Zed具体缺少哪些功能？(非Zed用户，纯粹好奇)
  
  回复
drcongo说道：

2026-01-07

我超爱Zed。八个月前我从Sublime全职转用Zed，全程使用预览版，每次更新都非常稳定。其界面设计堪称完美，细节处理更是顶级水准——使用体验舒适得如同穿着真正符合人体工学的拖鞋。

回复
shantara说道：

2026-01-07

Zed窗口标题栏里那个无法移除的登录按钮还在吗？上次试用时它简直是视觉污染。

回复
1. ChrisSD说道：
  
  2026-01-07
  
  咦，我用Zed好久了居然没注意到，幸好有设置能移除它。
  
  回复
2. TiredOfLife说道：
  
  2026-01-07
  
  https://github.com/zed-industries/zed
  
  回复
coopykins说道：

2026-01-07

在MacBook Pro M4上，VSCode处理中等规模单仓库时已无法正常使用，这令人担忧。Zed运行流畅得多，尽管缺少几个扩展功能。

回复
1. dmix说道：
  
  2026-01-07
  
  听起来像是扩展问题。否则代码库大小怎么会影响性能？
  
  回复
KnlnKS说道：

2026-01-07

我最近也在个人笔记本上从VSCode转用Zed。虽然从未觉得VSCode慢，但确实欣赏Zed的响应速度。

回复
_mrinalwadhwa_说道：

2026-01-07

我钟爱Zed的极简主义与速度。Zed Agent堪称卓越！

它虽不像Claude Code那样支持终端中的并行工作，但在单次会话中表现同样出色，且能轻松切换模型。在处理大型单仓库时它也极具价值——极简高效的界面让我能轻松调用文件夹、文件、代码片段等上下文信息辅助Agent工作。

回复
Gimpei说道：

2026-01-07

我喜欢Zed，只希望它能支持同时运行多个Agent并保留聊天记录。若能实现，我愿意付费支持。

回复
bovermyer说道：

2026-01-07

Zed总部位于哪个国家？

回复
aitchnyu说道：

2026-01-07

我仅用Zed处理百万行JSON日志转储。其他编辑器滚动或Ctrl+F都卡顿，但在Zed里瞬间完成。

回复
1. stellalo说道：
  
  2026-01-07
  
  这也是我转投它的原因。它轻量又迅捷，文本编辑器本就该如此。
  
  回复
a-dub说道：

2026-01-07

我始终不解为何有人偏爱VSCode。当年Visual Studio之所以出色，在于其精心设计与完美集成。VSCode总像拼凑的杂烩，各种功能和扩展根本无法和谐共存。

回复
1. CuriouslyC说道：
  
  2026-01-07
  
  若你是TypeScript开发者，VS Code体验确实出色，其插件生态也很丰富。但其他语言领域，JetBrains产品仍占据优势。
  
  回复
achayala说道：

2026-01-07

Zed很不错。需要AI功能时我会用它，其他时候则使用Neovim。

回复
giancarlostoro说道：

2026-01-07

没错，我正从JetBrains转向Zed——用了他们近十年。既然直接用Claude Code就能实现AI功能，我实在没理由继续支付JetBrains的年度订阅费。至少Zed的Claude Code集成比JetBrains更完善。除非他们推出真正值得我续费的功能，否则我不会续订。

回复
jrm4说道：

2026-01-07

我发现AI辅助编程正极大削弱我对“IDE”类功能的兴趣和依赖。

如今通过Gemini进行交互式“对话”，配合Geany(相对简单的编辑器)进行大量复制粘贴和执行操作，效率已远超以往在emacs、vim和IDE间切换的模式。

回复
1. patrickmcnamara说道：
  
  2026-01-07
  
  但愿AI能接管更多IDE功能，比如重命名或将方法移至其他类。Claude在这方面常出错，因为它缺乏IntelliJ那种复杂的工具链和索引机制。
  
  回复
  1. phito说道：
    
    2026-01-07
    
    Claude最近已集成LSP插件
    
    回复
    1. patrickmcnamara说道：
      
      2026-01-07
      
      啊，谢谢提醒。圣诞假期期间我错过了这个更新。
      
      https://news.ycombinator.com/item?id=46355165
      
      回复
2. onehair说道：
  
  2026-01-07
  
  我根本没开启那些功能，谢谢你提醒我注意！其实你还可以直接禁用AI！
  
  回复
delduca说道：

2026-01-07

我把Zed切换到neovim后，速度和效率都提升了好多。

回复
brianzelip说道：

2026-01-07

这里有篇不错的访谈播客，是1.5年前对Zed创始人的专访，https://shows.acast.com/software-unscripted/episodes/664fde4…。

回复
sabareesh说道：

2026-01-07

我已转用终端操作

回复
1. xpe说道：
  
  2026-01-07
  
  您指的是终端编辑器吗？比如emacs、vim、neovim或helix？(我试用过前几款后，对helix颇有好感。)
  
  还是指行编辑器？这类工具如今已相当出色。例如rustyline(基于linenoise)和reedline(非笔误；由Nushell团队开发)，其表现远超预期！
  
  [1]: https://github.com/kkawakam/rustyline
  
  [2]: https://github.com/antirez/linenoise
  
  [3]: https://github.com/nushell/reedline
  
  回复
  1. sabareesh说道：
    
    2026-01-07
    
    抱歉让大家失望了。但纯粹是codex和claude代码
    
    回复
2. vegabook说道：
  
  2026-01-07
  
  难道只有我对neovim很满意吗？
  
  回复
  1. bluecalm说道：
    
    2026-01-07
    
    我超爱它。此刻打开40个文件——多数是运行着LSP和Treesitter的.c源文件，内存仅占250MB。所有操作瞬时响应，Telescope堪称文件导航新标杆(更涵盖grep、符号搜索乃至Neovim快捷键)。Git集成也堪称绝妙。
    
    虽然花了不少时间配置，未来支持更多语言时可能还要投入更多精力，但我认为绝对值得。你可以自由定制所有设置，但运行Kickstarter(或更完整的Neovim“发行版”)也能获得非常出色的默认配置。
    
    微软在LSP(语言支持插件)方面做得非常出色——现在我能同时享受出色的导航/自动补全/代码格式化/内联错误提示，以及Neovim的轻量级特性和强大的工具/扩展。
    
    目前尚未集成调试器(终端的gdb对我已足够)，这或许是Neovim用户普遍缺失的功能？
    
    回复
    1. adhamsalama说道：
      
      2026-01-07
      
      我使用Astronvim，其调试器支持还算不错——只要能正常工作的话…
      
      回复
Octoth0rpe说道：

2026-01-07

我是Zed的早期用户，过去半年对其信心倍增，主要源于他们的AI发展规划。需要说明的是，我如此积极的评价其实与AI功能的_实用性_关系不大，更在于它似乎是一种可持续的融资模式。

自从开始使用Zed(再次强调我是早期用户)以来，我最大的担忧就是它终将需要盈利化，很可能因此变得糟糕。我向来不喜欢订阅制软件，但若能一次性支付20-50美元购买(或20美元购买主版本，三年后再付20美元升级)，我本会欣然接受。

过去一年间，Zed转型为AI转售商。用户可购买其“专业版”套餐，获取限定数量的OpenAI/Anthropic/Gemini代币，并设定最高预算。

对我而言，这种商业模式在抵御服务低质化方面堪称上策。Zed乐得从中抽成，用户能预览多种服务，若对AI毫无兴趣，核心编辑器仍可免费使用。我唯一担忧的是，雇主可能更倾向于为 Copilot 付费而非 Zed Pro，因此该方案在企业用户变现方面或有难度。

无论如何，看到如此明显且相对无害的可持续开发模式，我感到如释重负(相信 Zed 开发者们也是如此)。

在我看来，其最大缺陷仍是扩展生态圈规模有限，但这或许只是发展动能不足的问题。他们完全可以提供更丰富的VSCode扩展移植示例，这并非无法解决的难题。

我对聊天/协同编辑系统的安全性仍存疑虑，目前自建服务器似乎困难重重(甚至不可能？)，但或许未来会有所改进。

回复
astrea说道：

2026-01-07

这篇文章将VSCode描绘成被过多AI工具拖累的形象，而Zed官网首页却高调展示其与Sonnet 4.5的创新整合，并推出AI功能订阅计划——这种反差颇为耐人寻味。

回复
Heidaradar说道：

2026-01-07

你是否使用过Claude Code等AI工具？若未使用，原因何在？

回复
drannex说道：

2026-01-07

Zed本质上就是新版Sublime。

回复
1. bigstrat2003说道：
  
  2026-01-07
  
  Sublime永远是Sublime。它依然如昔般出色。
  
  回复
throw-12-16说道：

2026-01-07

VSCode的插件架构堪称安全噩梦，是供应链攻击的绝佳目标。

Zed是否对此有实质性改进？

回复
bborud说道：

2026-01-07

微软硬塞给我Copilot的行为，恰恰会让我去寻找替代方案。这和那些烦人的Cookie弹窗如出一辙——它们让我越来越频繁地想“去他妈的，我其实对这内容没兴趣”，直接关掉浏览器。

真希望微软能开发尊重用户意愿的软件，别再把VSCode搞得越来越糟糕了。

回复
worik说道：

2026-01-07

天哪

我从1989年就开始用Emacs了。见过太多编辑器兴衰更替，Emacs虽非最佳，却始终可靠。它始终坚守着自己的(极其宽泛的)本分。

虽然能将AI工具集成到Emacs中，或许哪天我会尝试。但选择太多反而令人困扰

这类文章让我明白为何始终忠诚……

回复
CuriouslyC说道：

2026-01-07

智能助手终将取代集成开发环境。优秀的编辑器才是根本所需。

回复
unethical_ban说道：

2026-01-07

还有人觉得VSCode的界面和配置难以适应吗？还是说这反映出我已脱离IDE工作模式，毕竟过去习惯用Vim独立编码并运行脚本？

界面单调乏味，所有功能都像附加组件，设置项分散在奇怪位置，呈现为json或网页风格。

上次用“真正”的IDE还是2008年，问题可能出在我身上。

回复
1. verdverm说道：
  
  2026-01-07
  
  你可以调整布局和主题来适应自己。标题栏有按钮，面板也能随意拖动。
  
  回复
submeta说道：

2026-01-07

NeoVim、Yazi和Tmux是我的主力工具。需要AI和智能助手时，我会创建多个Claude Code或Codex实例。但若无需使用，绝不让它们干扰我的工作流程。

回复
whalesalad说道：

2026-01-07

如今让我继续使用VSCode的唯一原因是远程SSH开发。所有开发工作都在家中高性能Linux工作站完成。即便不在书桌前(沙发、后院、咖啡馆、旅途)，我仍通过 Tailscale + VSCode SSH 远程连接该设备进行开发。遗憾的是 vscodium 等开源方案不支持此功能，它属于 Copilot 式的“特权”扩展。

近期 VSCode 使用体验堪称噩梦，我正积极寻求替代方案。最近遭遇了奇怪的数据损坏，迫使我彻底清空了Mac上的VSCode安装。从零开始重建本应轻而易举——只需一个配置文件就能恢复状态(类似Bundler或Node的锁定文件)，但涉及远程SSH时却变得一团糟。这个扩展本地安装了但远程没装，那个远程有但本地缺…拜托搞定这破事，统一管理行不行？

不过微软搞这套我早该料到。活该自己吃苦头。

重新考虑Zed…看到它支持SSH真让人欣慰！今天就来好好试试。但他们居然没有提供一流的Debian/Ubuntu apt仓库，这简直荒谬至极。这个问题已经存在很久了。

回复
globalnode说道：

2026-01-07

vscode变得卡顿不堪(虽然承认只有在后台开两个游戏时才这样，但这也太夸张了！)。我要试试zed了。

回复
lifetimerubyist说道：

2026-01-07

我从VSCode切换到Zed后，直接点击了“禁用AI”按钮——瞬间流畅如飞。太美妙了。

回复
gigatexal说道：

2026-01-07

同感。我早就在用Zed了，绝不回头。

回复
HackerThemAll说道：

2026-01-07

祝你好运。它连重启后保存未保存文件都做不到。https://github.com/zed-industries/zed/issues/15098

回复
hit8run说道：

2026-01-07

别跟我哥提SublimeText

回复
babu_mick说道：

2026-01-07

我也是兄弟

回复
css_apologist说道：

2026-01-07

Visual Studio Code的CSS语法高亮功能已经崩溃好几年了。

这可是网页开发专用编辑器啊，怎么可能出现这种情况？

回复
1. adzm说道：
  
  2026-01-07
  
  怎么崩溃了？我现在用着好好的啊。
  
  回复
  1. publicdebates说道：
    
    2026-01-07
    
    虽然不是GP说的，但他完全正确，这功能让我烦了好几年。我能立刻想到的就是嵌套选择器至今仍无法正确高亮。几个月前他们只做了部分修复。现在我们只能等着GHCP优先处理并修复了吧？
    
    回复
    1. css_apologist说道：
      
      2026-01-07
      
      嵌套问题最严重，但我记得有规则无法解析导致整份文件报错的情况
      
      这简直可悲，充分暴露当前CSS工具链有多垃圾
      
      回复
      1. jtbaker说道：
        
        2026-01-07
        
        插入讨厌的tailwind评论
        
        回复
  2. jazzyjackson说道：
    
    2026-01-07
    
    虽然不是楼主，但记得曾和团队共事时，大家只能忍受无法高亮显示且毫无智能性的CSS——只因它嵌在Handlebars模板里。当然有扩展号称能修复，但它既不稳定又频繁崩溃。最简单的解决法是将CSS移至独立文件导入，但对这群人而言已是巨大变革。
    
    回复
alimbada说道：

2026-01-07

必备的Zed收受偏执狂的钱财：https://github.com/zed-industries/zed/discussions/36604

回复
1. duskdozer说道：
  
  2026-01-07
  
  感谢指出。别理那些道德警察。
  
  回复
2. spiderice说道：
  
  2026-01-07
  
  不错。刚订了他们的专业版。
  
  回复
rcleveng说道：

2026-01-07

很想试试Zed，但它在MacOS上根本无法使用(问题似乎出在https://github.com/zed-industries/zed/issues/20806这个库)。

若能修复这个问题，我会考虑用它替代Sublime(目前仍是我的快速编辑首选)，再看看它能否胜任更复杂的编码需求(这方面现在由各种VSCode分支轮流承担)。

回复
1. presbyterian说道：
  
  2026-01-07
  
  最近试过BBEdit吗？它配置自由度极高，AI功能完全可选，现在还支持LSPs。如今它已成为我处理所有文本编辑的首选工具。
  
  回复
2. Shywim说道：
  
  2026-01-07
  
  我每日使用Zed已满一年，期间从未遇到此类问题或其他故障，运行始终流畅，从未发生过崩溃或错误。
  
  我处理的是大型单仓库项目(虽然一切都是相对的)，可能正好触发了这个限制。记得几年前在这台设备上就用过本文讨论的“变通方案”。当默认文件限制因语言不同而如此之低时，很难归咎于软件本身。
  
  总之，若你遇到此问题，其他工具也必然存在同样情况，否则说明当前状态完全正常。
  
  回复
  1. rcleveng说道：
    
    2026-01-07
    
    我使用其他工具(Sublime、VSCode、Cursor、Antigravity、Emacs)均未遇到此问题。
    
    回复
gethly说道：

2026-01-07

我日常使用JetBrains系列。我向来不喜欢VS Code，或者说VS Codium。我仅将其作为文本编辑器使用，且仅限于打开无关紧要的目录(如陈旧或外部代码)或确实需要语法高亮时。尽管内置AI功能令人诟病，我曾对Zed寄予厚望，但实际使用后发现仍无法像JetBrains那样配置语法高亮主题，且标准库的定义跳转功能莫名失效(经Odin测试)。我向来不欣赏JetBrains的定价策略和新版界面改动。正因如此，我正在开发自己的编辑器/IDE，而Zed的体验正是促使我付诸行动的最后推力。

回复

我从VSCode转投Zed

告别VSCode

Zed：初体验

让Zed支持Python

总结

共有{401}条精彩评论

发表回复取消回复

你也许感兴趣的：

我从VSCode转投Zed

告别VSCode

Zed：初体验

让Zed支持Python

总结

共有{401}条精彩评论

发表回复 取消回复

你对本文的反应是：

看样子你已经点过这个了！

抱歉，你最多只能点三个！

你也许感兴趣的：

发表回复取消回复