Editor Surface 与工作分层
基于官方 Editor 文档理解 Antigravity Editor 的 VS Code 基础、AI 入口、扩展能力和适用任务边界。
Antigravity 的 Editor 是主要入口,也是最像传统 IDE 的界面。Google 官方 Editor 文档说明,它基于 VS Code codebase,同时加入 Tab、Command、Agent side panel、Review Changes 和 Source Control 等 AI-enabled features。
这意味着学习 Editor 时不要走两个极端:不要把它当成普通 VS Code,也不要把所有任务都扔给 Agent Manager。Editor 最适合“代码现场明确、上下文可控、diff 可以快速审查”的任务。
阅读目标:读完本章,你应该能判断哪些任务留在 Editor 里处理,哪些任务应该上升到 Agent Manager 或 Planning 模式。
1. Editor 是熟悉的 IDE,不是普通 IDE
官方文档强调,Antigravity Editor 保留了熟悉的编辑器体验:打开文件、在文件间切换、直接编辑、使用扩展、接入 source control。
差异在于这些传统入口都能接到 AI 工作流:
| Editor 能力 | 官方含义 | 实操价值 |
|---|---|---|
| Tab | 在当前文件附近给代码建议和导航 | 局部加速,不打断编码流 |
| Command | 在编辑器或终端里输入自然语言指令 | 小范围生成、改写、解释 |
| Agent side panel | 在右侧面板直接和 agent 协作 | 当前 workspace 内的任务协作 |
| Review Changes | 查看本 conversation 里产生的改动 | 把 AI 输出拉回 diff 审查 |
| Open VSX extensions | 继续安装语法、source control 等扩展 | 保留传统 IDE 生态 |
2. Editor 与 Agent Manager 的边界
先用任务范围判断入口,不要按个人习惯乱切。
flowchart TD
Task["新任务"] --> Known{"是否知道主要文件或错误位置"}
Known -->|知道| Editor["留在 Editor"]
Known -->|不知道| Manager["进入 Agent Manager / Planning"]
Editor --> Small{"是否局部、可快速读完 diff"}
Small -->|是| TabCommand["Tab / Command / Side Panel"]
Small -->|否| Manager
Manager --> Artifacts["要求 plan、artifacts、walkthrough"]
TabCommand --> Review["Review Changes + Source Control"]
简单说:
- 你知道要改哪一小块,留在 Editor。
- 你需要跨文件规划、浏览器验证、长任务追踪,切到 Agent Manager。
- 你让 AI 写了代码,就必须回到 Review Changes 或 Source Control。
3. 什么时候留在 Editor
Editor 适合这些任务:
| 任务 | 推荐入口 | 原因 |
|---|---|---|
| 补一个函数体 | Tab 或 Command | 上下文局部,结果可快速审查 |
| 修一个明确报错 | Command 或 Agent side panel | 错误位置清楚 |
| 解释当前文件逻辑 | Agent side panel | 不需要跨 workspace 编排 |
| 生成 terminal 命令 | Terminal Command | 靠近 shell,但仍需审查 |
| 审查 AI 改动 | Review Changes | diff 是验收入口 |
不适合只留在 Editor 的任务:
- 需要同时读多个目录。
- 需要先产出 implementation plan。
- 需要浏览器截图、录屏或 walkthrough。
- 会运行高副作用 terminal 命令。
- 涉及部署、账号后台、数据库或生产环境。
Editor 不是低风险区域。只要 agent 开始写文件或生成 terminal 命令,就要把它当成真实工程改动审查。
4. 扩展生态的正确位置
官方 Editor 文档提到可以继续从 Open VSX marketplace 下载扩展,用于语法高亮、source control integrations 或其他补充能力。
扩展可以增强开发体验,但不要把扩展当成 agent 安全边界。真正的边界仍然在:
- workspace 范围。
- terminal command review。
- file access policy。
- Browser URL allowlist。
- Git diff 和 source control。
深读:为什么 Editor 任务也要写验收条件
很多人会把 Editor 里的 AI 入口当成“局部辅助”,于是放松审查。但官方 Editor 文档把 Tab、Command、Agent side panel、Review Changes 和 Source Control 放在同一个工作面里,说明局部生成最终仍然会落到代码改动。
所以即使是一个小改动,也建议在 prompt 里写明“只改这个文件”“完成后给 diff”“不要运行部署命令”。这样可以把 Editor 的便利性和工程审查习惯接起来。
5. 第一天的 Editor 使用顺序
第一次用 Editor,不要直接把复杂需求交给 agent。按这个顺序熟悉:
- 打开测试 workspace。
- 手动浏览文件树,确认项目结构。
- 用 Tab 接受一个局部建议。
- 用 Command 生成或解释一小段代码。
- 用 Agent side panel 做只读解释。
- 让 agent 做一个单文件小改。
- 打开 Review Changes 审查 diff。
- 回到 Source Control 决定是否保留。
本章自检
完成本章后,用这 3 个问题检查自己是否真正理解:
- Editor 和 Agent Manager 的任务边界是什么?
- 为什么 Editor 里的 AI 改动也必须看 Review Changes 或 Source Control?
- Open VSX 扩展能增强什么,不能替代什么?
通过标准:你能把一个小任务安排在 Editor 内完成,并清楚说明用 Tab、Command、side panel 还是 Review Changes。
官方来源
- Google Antigravity Editor —— 官方说明 Editor 基于 VS Code codebase,并整合 Tab、Command、Agent side panel、Review Changes、Source Control 和 Open VSX 扩展。