Antigravity 这个 AI IDE 我用了有一阵子了。先亮观点它的 AI 能力确实猛尤其是把整个项目上下文交给它之后很多跨文件的改动、重构、报错修复都能自动完成体验比传统 VS Code 加插件的方式要激进不少。但如果你和我一样是 VS Code 老用户第一次打开 Antigravity 十有八九会有点别扭——默认主题不一样、个别快捷键对不上、编辑器行为也有差别平时靠肌肉记忆的操作全乱了。这篇就是我的“调校笔记”记录我怎么把 Antigravity 配置成一台更像 VS Code、但 AI 能力不缩水的 AI IDE。适合从 VS Code 迁过来、又希望保留 AI 效率的开发者参考照着抄配置就行。1. 先搞清楚Antigravity 和 VS Code 到底差在哪1.1 Antigravity 的定位与核心优势Antigravity 不是一个“套壳 VS Code”它的核心是 agent 式的工作流。你可以把它理解成一个在 IDE 里常驻了一位会读代码、会跑命令、会自己改文件的协作者。打开项目后它会把整个项目的目录结构、依赖关系、现有代码风格都吃进去然后你提一个需求它能自己拆解步骤逐个文件去改改完还会自动跑测试验证。这个能力和传统的“AI 补全 问答面板”完全不是一个层级。这也决定了它的定位适合任务型开发比如“把登录模块从 session 改成 JWT”“这个接口报错帮我查一下并修复”。在 VS Code 里这些事情要拆成很多步手动做在 Antigravity 里基本可以一句话驱动它完成大部分。所以它不是来替代 VS Code 的而是把 VS Code 里那些“重复劳动”进一步压缩掉。1.2 为什么默认手感不如 VS Code 顺手Antigravity 底层其实继承自 Code OSS 那一套架构所以配置文件体系、扩展机制和 VS Code 是相通的设置逻辑大部分能沿用。但它的默认 UI 和默认行为是围绕 AI 工作流设计的而不是围绕“传统编辑习惯”设计的。比如它默认会突出 AI 对话区域、自动补全触发更频繁、快捷键在个别地方有改动菜单组织也不完全一样。对从 VS Code 迁移过来的用户来说这种“默认值”就会带来第一次打开时的错位感。我建议不要急着否定它先把关键配置对齐到自己习惯的状态再用一段时间感受 AI 部分的价值。很多差评其实只是“配置没花时间调”导致的调完之后它一样能当主力 IDE 用。2. 第一步把外观先调成 VS Code 的“脸”2.1 主题、字体与渲染设置外观是第一个要解决的因为每天盯着看不顺手会很难受。打开设置面板搜索颜色主题把主题切成 VS Code 经典的 Dark 或 Light 即可。如果列表里没有直接去扩展市场装一个官方的 Dark 主题包本质上是同一个东西。图标主题也建议同步一下File Icon Theme 选成 Seti 或 vscode-icons侧边栏里的文件类型一眼就能认出来。字体这块可以直接用 VS Code 的经典组合editor.fontFamily: Cascadia Code, Consolas, Courier New, monospace, editor.fontSize: 14, editor.lineHeight: 1.6, editor.fontLigatures: trueCascadia Code是 Windows 上观感比较现代的字体也支持连字macOS 上可以换成JetBrains Mono或SF Mono。行高 1.6 适合长时间阅读代码字体大小 14 在多数高分屏上比较舒服。如果你要的是“和 VS Code 一模一样”把这几行抄过去基本就对了。2.2 布局与侧边栏管理布局上的差距主要在于侧边栏默认位置、AI 面板是否常驻、底下面板是否自动展开。我习惯把侧边栏放在左边和 VS Code 保持一致workbench.sideBar.location: left, workbench.activityBar.visible: true, editor.minimap.enabled: true, breadcrumbs.enabled: trueAI 对话面板建议不要常驻做成按需打开快捷键触发即可。不然右侧一大块区域被聊天窗口占着写代码的时候视野会非常小。底下面板终端、输出、问题日常可以收起来用 Ctrl 或 CtrlJ 呼出。这一步配完之后界面观感已经和 VS Code 非常接近了剩下的就是快捷键和编辑器行为。3. 第二步快捷键映射解决肌肉记忆问题3.1 高频快捷键对照表快捷键不完全一致是迁移过程中最容易被搞疯的点。我整理了日常最高频的快捷键对照可以直接对着调功能VS Code 习惯Antigravity 下建议命令面板CtrlShiftPCtrlShiftP如果被 AI 占用改回这个快速打开文件CtrlPCtrlP切换侧边栏CtrlBCtrlB打开集成终端CtrlCtrl全局搜索CtrlShiftFCtrlShiftF多光标/列选择AltClickAltClick 或 CtrlAltDown重命名符号F2F2快速修复Ctrl.Ctrl.格式化文档ShiftAltFShiftAltF大部分默认应该和 VS Code 一致不一致的通常在 Keyboard Shortcuts 里搜中文名或命令 ID 就能重新绑定。重点确认workbench.action.showCommands、workbench.action.quickOpen、workbench.action.terminal.new这三个命令的键位它们是平时使用频率最高的。3.2 自定义键位绑定的实操方法打开快捷键设置CtrlK CtrlS或者命令面板里搜 “Open Keyboard Shortcuts”。在界面里可以搜命令也可以直接编辑 keybindings.json。我一般把关键调整项写进 keybindings.json方便多台设备同步[ { key: ctrlshiftp, command: workbench.action.showCommands }, { key: ctrl, command: workbench.action.terminal.new }, { key: alta, command: antigravity.chat.focus } ]第三个是我自己加的习惯用 AltA 快速聚焦 AI 对话。你可以根据自己的习惯改。注意如果某个键位和扩展冲突命令面板里输入命令名后能看到当前冲突项解决冲突再保存不然会出现按了没反应的情况。4. 第三步编辑器行为向 VS Code 对齐4.1 自动保存、缩进格式与光标行为默认行为差异里最影响日常的是自动保存和格式化。VS Code 用户一般习惯afterDelay自动保存避免一直手动 CtrlSfiles.autoSave: afterDelay, files.autoSaveDelay: 1000, editor.formatOnSave: true, editor.formatOnPaste: true, editor.tabSize: 4, editor.insertSpaces: true, editor.detectIndentation: true, files.trimTrailingWhitespace: trueformatOnSave这行最值钱保存瞬间自动格式化很多左右对齐的细节问题直接就没了。但要注意如果项目用的是 ESLint 或 Prettier最好把默认格式化器设置成对应的扩展否则会用 IDE 内置的格式化器导致格式不统一。光标行为可以按个人口味调editor.cursorBlinking: smooth、editor.cursorSmoothCaretAnimation: on看起来比较跟手写代码也更有行云流水的感觉。4.2 文件关联与多光标编辑文件关联是很多人忽略的设置。比如 Qt 项目里的.qss样式文件默认可能被识别成纯文本没有高亮和补全.ini、.conf之类也一样。在 settings.json 里加files.associations: { *.qss: css, *.conf: ini, *.svelte: html }多光标操作是 VS Code 用户离不开的能力把editor.multiCursorModifier设为ctrlCmd以后用 Ctrl点击 添加光标、Alt点击 选择词这套组合和 VS Code 完全一致。editor.wordWrap按项目决定Markdown 和文档类代码建议on源代码保持off避免长代码自动换行破坏缩进结构。4.3 AI 功能的开关与提示交互Antigravity 的 AI 默认比较“主动”体现在代码补全提示出现频繁有时候你还没想好怎么写它就弹一大段。这个是可以调的在 AI 设置里把自动补全模式改成按需触发或者修改触发延迟就能减少打断感。我自己的设置是保留行内补全但关闭“自动展开完成列表”这样既不干扰输入又能在需要时看建议。还有一点很重要Agent 自动执行业务命令时默认有确认机制我建议你把确认级别调到“需要确认”而不是“自动接受”。现在网上讨论 Claude Code 自动点 yes 这类话题很多实际项目里自动确认非常危险——一条rm或git push --force被 AI 直接执行后果很严重。宁可每次多点一下确认也不要让 AI 变成失控的自动化脚本。5. 第四步终端、调试与运行能力的补齐5.1 集成终端与默认 Shell 配置Antigravity 的集成终端和 VS Code 基本一致但默认 shell 可能不是你常用的。我在 Windows 上习惯 Git BashLinux 上用 zshmacOS 上默认 zsh。通过下面的配置固定terminal.integrated.defaultProfile.windows: Git Bash, terminal.integrated.defaultProfile.linux: zsh, terminal.integrated.fontFamily: Cascadia Mono, Consolas, monospace, terminal.integrated.fontSize: 13, terminal.integrated.cursorBlinking: true如果你在多个开发环境里切换把终端默认 shell 固定下来会少很多认知负担。终端是最容易和 VS Code 体验拉开差距的地方配置文件写好之后以后打开终端就是熟悉的那套 shell 环境。5.2 Python 调试与代码运行的实战配置Python 项目迁移到 Antigravity 时最常见的问题就是无法识别 conda 环境。原因很简单IDE 没有把解释器路径指到 conda 的虚拟环境。解决方法是手动选择CtrlShiftP-Python: Select Interpreter- 选择 conda 环境路径下的 python.exe通常是~/miniconda3/envs/项目名/bin/python或.../python.exe。然后调试配置写进.vscode/launch.json{ version: 0.2.0, configurations: [ { name: Python: 当前文件, type: debugpy, request: launch, program: ${file}, console: integratedTerminal, justMyCode: true, envFile: ${workspaceFolder}/.env } ] }justMyCode建议先开 true调试时跳过第三方库内部省很多时间。如果项目需要调试 pytest把request改成test然后在测试面板里选择测试函数。觉得调试配置麻烦的话也可以用 Code Runner 这类扩展直接跑单个脚本但要先把解释器选对不然跑出来的环境和预期不一致。5.3 对 Qt / C / 远程开发等场景的补充建议Qt 项目在 VS Code 里的套路在 Antigravity 里基本可以照搬用 CMake 组织构建、装 C 扩展和 Qt Tools、配置调试器。有个细节C 标准版本一定要在 C/C 插件设置里的cppStandard指定比如c17不然代码跳转和智能提示可能拿到错误的标准。如果你用的是 clangd则需要在.clangd配置文件里写Standard: c17。远程开发方面Antigravity 也支持 Remote-SSH 那套。我最常遇到的问题是远程主机可能不符合 glibc 和 libstdc 的 VS Code 服务器先决条件本质是远程服务器系统库太老。遇到它先检查ldd --version strings /usr/lib64/libstdc.so.6 | grep GLIBCXX如果版本确实过低优先给远程主机升级基础库或者换新一点的系统镜像容器别想着绕过检查因为 vscode-server 是用新版本 Node 编译的老库跑不起来。还有一点远程开发时 vscode-server 下载经常报localdownloadfailed多数是网络或权限问题可以先确认服务器上有写入权限再手动下载对应版本的服务端压缩包放到~/.vscode-server/bin/下。6. 插件生态把 VS Code 习惯迁移到 Antigravity6.1 内置 AI 能力与扩展的取舍Antigravity 内置的 AI 覆盖了对话、补全、自动改代码已经占掉了很多插件该做的事。所以插件迁移的第一原则是不要全量照搬 VS Code 的那堆 AI 插件先看看内置功能够不够。我实际迁移后的必须装清单并不长扩展用途Python PylancePython 语言服务、跳转、类型检查Prettier / ESLint前端格式化与 lintGitLens代码历史、blame、git 操作增强Remote-SSH远程开发CMake clangdC / CMake 项目支持Code Runner快速跑单文件脚本装完之后感觉就是语言能力、工程能力由扩展负责AI 能力交给内置两者不冲突。装扩展要注意如果扩展市场里搜不到某些扩展可能和版本分支有关可以考虑手动下载 VSIX 再安装装完记得确认扩展是否真的启用有些扩展依赖特定 API 在 Antigravity 里会灰掉。6.2 使用 CLI 与本地工具链衔接Antigravity 提供 CLI 工具用来在终端里触发 agent 任务、管理登录态、在 CI 里跑项目级检查。第一次使用的流程一般是从官网下载对应平台的 CLI 压缩包解压后把可执行文件路径加到 PATH然后执行一次登录命令把 IDE 的登录态和 CLI 关联起来。如果下载后提示命令找不到大概率是 PATH 没生效检查一下which antigravity或antigravity --version能不能输出。如果你已经在 VS Code 里用了 codex、Claude Code 这类外部 AI 工具也可以继续保留因为它们解决的是“终端里的 AI”场景和 Antigravity 的 IDE 内 AI 不冲突。但注意别同时让两个 agent 操作同一个 git 工作区我踩过一次两个 agent 同时改文件最后 git 状态乱成一团回滚了半天。建议同一时间只开一个 agent让它在当前工作目录里全权负责另一个关掉或换个目录。7. 高频问题排查登录、下载、连接失败的实录7.1 Antigravity 登录不上的常见排查思路Antigravity 登录不上是新手最常遇到的问题。我实际遇到的情况多半不是账号问题而是环境问题。先按顺序排查确认本地网络能正常访问官网和 IDE 的登录域名检查系统时间是否准确误差超过几分钟HTTPS 握手就会失败清掉浏览器里的历史登录缓存重新走一遍授权流程在 IDE 的设置里找到登出或清除登录信息把本地认证缓存重置后重新登录如果刚换了设备先在旧设备上主动登出一次避免多端认证状态冲突。整个过程都不要去动 hosts 或装来路不明的工具优先走官方渠道。官方支持渠道能查账号状态比折腾本地配置靠谱得多。7.2 CLI 下载失败与本地服务异常处理CLI 下载失败报错比如error: localdownloadfailed时我一般先做三件事确认磁盘空间和目录写权限、确认杀毒软件或防火墙没有拦截下载进程、换一个网络环境重试。企业网络环境下这类下载经常会被拦手动到官网下载压缩包再部署到本地是更稳的路径。下载解压后记得校验文件完整性跑一下--version确认能正常执行。还有一种情况IDE 启动时报本地服务端口被占用。这通常是因为上一次没有正常退出残留进程还占着端口。在系统进程管理里把名称带 antigravity 的进程全部结束再重启 IDE通常就好了。日志一般在用户目录下的配置文件目录里真查不出来时可以翻日志看具体端口和报错堆栈。7.3 远程开发环境的预检与修复远程开发前建议先做一次预检不要直接连上去才发现一堆问题。重点检查三点远程主机的系统库版本、vscode-server 能否正常下载、工作区目录有没有写权限。系统库版本可以这样看ldd --version strings /usr/lib64/libstdc.so.6 | grep GLIBCXX | tail -5如果ldd版本低于远程服务器要求通常只能升级系统包或换新镜像。localdownloadfailed的问题在远程场景也常见确认远程主机能访问下载地址或者手动上传 vscode-server 压缩包到~/.vscode-server/bin/对应版本目录。另外远程开发尽量用 devcontainer 方式把依赖都固化在容器里这样换机器、换远程主机都不会再踩系统库的坑。8. 一点不成熟的个人体会配置这套流程花了我大半天但用下来觉得值。Antigravity 值得投入时间配置但我的建议是别追求 100% 变成 VS Code。它和 VS Code 最大的区别恰恰在“不像”的部分agent 模式、项目级上下文、自动修复循环这些是传统 IDE 给不了的。你花 20 分钟把外观和快捷键对齐剩下的时间应该花在核心开发上而不是纠结界面。最后分享一个小技巧Antigravity 里对项目规范文件很敏感你把项目的编码规范、目录约定、命令习惯写成一个项目级别的说明文档AI 生成的代码会明显更贴近团队风格比我之前关掉自动补全、疯狂写提示词有效得多。这个发现比任何 IDE 配置都值钱建议你先试试。