真实项目任务选择
基于官方能力边界判断哪些任务适合交给 Antigravity，哪些任务需要拆分、人工确认或暂不交给 Agent。
Antigravity 适合的不是“让 AI 随便写点代码”，而是目标明确、边界清楚、能用 artifacts 和测试验证的开发任务。Google Developers Blog 对 Antigravity 的定位是：让 agents autonomously plan、execute、verify complex tasks，并通过 Editor、Terminal、Browser 和 Artifacts 沟通进展。
所以选择任务时，先问一个问题：这个任务能不能用 plan、diff、test、screenshot、recording、walkthrough 证明完成？
阅读目标：读完本章，你应该能把真实项目任务分成“适合直接交给 Antigravity”“需要拆分后交给 Antigravity”“必须人工控制”的三类。
1. 适合直接交给 Antigravity 的任务
这些任务通常目标清晰、风险可控、证据链完整。
| 任务 | 为什么适合 | 要求的证据 |
|---|---|---|
| 修复明确 UI bug | 可改代码、打开浏览器、截图验证 | diff + screenshot + console |
| 给已有逻辑补测试 | 可读代码、生成测试、跑命令 | diff + test output |
| 文档重组 | 文件范围清楚，容易审查 | task list + diff + walkthrough |
| 小范围重构 | 可以先 plan，再分组修改 | implementation plan + tests |
| 本地页面断点检查 | browser subagent 能看不同 viewport | screenshots + recording |
| 终端报错排查 | 可以保留日志并最小修复 | terminal output + diff |
示例 prompt：
请使用 Planning 模式修复当前页面 mobile 断点下的按钮换行问题。
范围只限这个组件和样式文件。
先给 implementation plan，不要立即修改。
确认后运行本地页面，并提供 390px、768px、1440px 截图。2. 需要拆分后再交给 Antigravity 的任务
这些任务可以用 Antigravity 做，但不能一次全交。
| 任务 | 拆分方式 |
|---|---|
| 跨模块重构 | 先只读分析，再按模块分批改 |
| 依赖升级 | 先列影响范围，再升级一个包，再跑测试 |
| 多页面 UI 改版 | 先建立视觉基线，再按页面批次验收 |
| MCP 接入 | 先审 server / tools，再只读连接，最后放开写操作 |
| Firebase 迁移 | 先保留原始导出，再迁移，再本地预览，再发布 |
| 团队规范沉淀 | 先跑一次人工流程，再写 Rules / Workflows / Skills |
flowchart TD
Big["大任务"] --> Readonly["只读分析"]
Readonly --> Plan["Implementation Plan"]
Plan --> Batch["拆成批次"]
Batch --> Execute["执行第一批"]
Execute --> Verify["验证和截图"]
Verify --> Next{"是否继续下一批"}
Next -->|是| Batch
Next -->|否| Stop["汇总 walkthrough"]3. 不应该直接交给 Agent 的任务
这些任务不是 Antigravity 完全不能参与，而是不能让 agent 直接执行副作用动作。
| 任务 | 风险 | 更稳做法 |
|---|---|---|
| 生产数据库改动 | 不可逆，影响真实用户 | agent 写计划，人工执行 |
| 密钥轮换 | 凭据泄露风险 | 人工按内部 SOP 操作 |
| 付款、订阅、广告投放 | 金钱和合规风险 | agent 只读分析，人工确认 |
| 真实账号后台点击 | 登录态和权限风险 | 先只读，必要时屏幕人工操作 |
| 大范围删除或迁移文件 | 回退成本高 | 先 inventory 和 dry run |
| 未审计 MCP 写操作 | 外部系统副作用 | disabledTools + Request Review |
“Agent 可以操作”不等于“应该让它自动操作”。真实项目先看副作用，再决定权限。
4. 用证据链判断任务质量
一个合格的 Antigravity 任务至少要有下面几类证据中的一部分：
| 证据 | 适用任务 |
|---|---|
| Task List | 长任务、并行任务 |
| Implementation Plan | 跨文件、复杂修改 |
| Code Diff | 所有写文件任务 |
| Terminal Output | build、test、lint、排障 |
| Screenshot | UI、布局、断点、主题 |
| Browser Recording | 用户路径、交互流程 |
| Walkthrough | 任务完成后汇总 |
深读：为什么“复杂任务”不是越大越适合 Agent
官方产品定位强调 autonomously plan、execute、verify complex tasks，但这里的 complex 不是“无限大、无边界”。复杂任务适合 agent 的前提是能拆成可审查单元，能通过 artifacts 沟通进展，也能用测试或浏览器证据验证。
如果任务范围大到 diff 无法审、测试无法跑、浏览器路径无法复现，那么它就不再是 agentic development 的优势区，而是风险区。正确做法是先用 Antigravity 做分析和计划，再把实现拆成小批次。
5. 一个真实项目启动模板
请先只读分析当前任务，不要修改文件。
请输出：
1. 任务是否适合 Antigravity 直接执行。
2. 建议使用 Editor、Agent Manager 还是 Browser Subagent。
3. 需要哪些权限和工具。
4. 最小可执行批次。
5. 验收证据：diff / test / screenshot / recording / walkthrough。
6. 哪些动作必须等我确认。本章自检
完成本章后，用这 3 个问题检查自己是否真正理解：
- 哪类任务可以直接交给 Antigravity，哪类必须拆分？
- 为什么生产数据库、密钥、付款和真实后台操作不能自动放权？
- 一个前端 UI 任务至少应该交付哪些证据？
通过标准：你能拿到一个真实任务后，先判断任务类型、拆分方式、权限边界和验收证据，而不是直接让 agent 开始改。
官方来源
- Build with Google Antigravity —— 官方发布文说明 Antigravity 面向 agentic development，结合 Editor、Manager Surface、Terminal、Browser 和 Artifacts。
- Google Antigravity Artifacts —— 官方说明 artifacts 作为异步沟通和反馈机制。
- Google Antigravity Browser —— 官方说明浏览器可用于测试开发网站、读取数据源和自动化浏览器任务。
- Google Antigravity Strict Mode —— 官方说明 strict mode 对副作用能力的安全约束。