Google Antigravity

为什么选择 Google Antigravity？

当开发工作流正在从单次 prompts 转向协同式 agent work 时，Google Antigravity 最有吸引力。它的核心思路是，AI coding tool 不应该只是停留在聊天侧边栏里，而应该有专门的操作界面，让 agents 可以规划、构建、测试、验证并汇报进度，同时由开发者监督结果。

这让 Antigravity 不同于传统 AI IDE。Editor 只是产品的一部分。独立 desktop app、Manager surface、artifacts、browser control、terminal access、CLI、SDK，以及 Google 生态集成，都围绕同一种模式设计：委派任务级工作、观察进度、审查证据，并在需要时介入。

核心工作流

实用的 Antigravity 工作流，应该从可验证的任务开始。不要要求模糊的改进，而是定义想要的行为、目标文件或 app 区域、acceptance criteria、test command，以及 agent 是否可以使用 browser 或 terminal。然后 agent 可以创建计划、修改 codebase、执行 commands、测试结果，并生成 artifacts 来总结发生了什么。

对于长时间运行的工作，Manager surface 是关键差异。开发者可以把 agents 分配到不同 workspaces，让它们并行运行，并通过 deliverables 而不是 raw logs 来审查每个任务。这很有用，但也会改变开发者角色。开发者更像 reviewer、task designer 和 safety gatekeeper，而不只是手动输入每个修改的人。

使用场景

Antigravity 适合 code、terminal 和 browser verification 都很重要的多步骤软件任务。例如添加功能、修复 UI bug、复现 issue、生成 test case、测试 web flow、集成 Firebase、从 Google AI Studio 导出到本地开发，或从 prompt 创建 Android prototype。

它也适合 background maintenance。Scheduled Tasks 和 parallel agents 可以帮助处理周期性 cleanup、dependency work、triage、documentation updates 和 issue reproduction。不过，这些工作流应该逐步引入，因为自主工具访问一旦应用在重要 repositories 或本地文件上，可能带来真实风险。

与替代工具对比

与 Cursor 和 Windsurf 相比，Antigravity 更明确地偏向 agent-first。Cursor 和 Windsurf 是适合交互式 coding、inline changes 和 codebase chat 的强大 AI editors。Antigravity 则更强调 orchestration：multiple agents、Manager surface、artifacts、browser recordings，以及 Google-native agent harness。

与 Claude Code、Codex CLI、OpenCode 或 Aider 相比，Antigravity 不是 terminal-minimal，而是更 platform-oriented。CLI agents 适合希望本地、直接、provider-flexible 控制的开发者。当工作流受益于图形化 command center、verification artifacts、browser control 和 Google 生态集成时，Antigravity 更有吸引力。

与 Replit AI、Bolt.new 或 Lovable 相比，Antigravity 不只是简单的 prompt-to-app builder，而更像 agentic development environment。它可以帮助把想法变成 app，但更强的定位是监督在现有开发流程中工作的 agents。

最佳配置

最安全的配置从 project isolation 开始。使用独立 workspaces、干净的 Git branches、backups，以及范围收窄的 file access settings。对敏感项目启用更严格的 security controls，谨慎配置 outside-folder access，并在 agents 需要 web access 时使用 browser allowlists 或 denylists。

模型选择方面，iteration 和 debugging 可以使用更快的 Gemini models；当 quota 和 plan access 允许时，把更强或 third-party models 留给更难的 reasoning tasks。团队应标准化 agents 什么时候可以运行 terminal commands、什么时候可以触碰 project 外的 files、什么算 acceptable evidence，以及在 merge 或 deploy changes 前由谁审查 artifacts。

迁移注意事项

从 Gemini CLI 迁移的开发者应先评估 Antigravity CLI，再判断 desktop Manager surface 是否带来足够价值。从 Cursor 或 Windsurf 迁移的开发者，应该在需要 browser verification 和 parallel background tasks 的工作流上测试 Antigravity，而不只是测试 inline edits。那里才是产品最有差异化的地方。

团队采用方面，最佳路径是 controlled pilot。使用一个非关键 repository，定义安全任务，要求人工审查 diffs 和 artifacts，并记录 agent 成功和越界的情况。在 production usage 之前，团队应先确定 backup practices、permission rules、sandbox defaults、project isolation、rate-limit expectations，以及 Google Cloud 或 enterprise account terms。