---
title: "真实项目任务选择"
description: "基于官方能力边界判断哪些任务适合交给 Antigravity，哪些任务需要拆分、人工确认或暂不交给 Agent。"
verifiedAt: "2026-05-06"
---

Antigravity 适合的不是“让 AI 随便写点代码”，而是目标明确、边界清楚、能用 artifacts 和测试验证的开发任务。Google Developers Blog 对 Antigravity 的定位是：让 agents autonomously plan、execute、verify complex tasks，并通过 Editor、Terminal、Browser 和 Artifacts 沟通进展。

所以选择任务时，先问一个问题：这个任务能不能用 plan、diff、test、screenshot、recording、walkthrough 证明完成？

> [!NOTE]
> **阅读目标**：读完本章，你应该能把真实项目任务分成“适合直接交给 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：

```text
请使用 Planning 模式修复当前页面 mobile 断点下的按钮换行问题。
范围只限这个组件和样式文件。
先给 implementation plan，不要立即修改。
确认后运行本地页面，并提供 390px、768px、1440px 截图。
```

## 2. 需要拆分后再交给 Antigravity 的任务

这些任务可以用 Antigravity 做，但不能一次全交。

| 任务 | 拆分方式 |
| --- | --- |
| 跨模块重构 | 先只读分析，再按模块分批改 |
| 依赖升级 | 先列影响范围，再升级一个包，再跑测试 |
| 多页面 UI 改版 | 先建立视觉基线，再按页面批次验收 |
| MCP 接入 | 先审 server / tools，再只读连接，最后放开写操作 |
| Firebase 迁移 | 先保留原始导出，再迁移，再本地预览，再发布 |
| 团队规范沉淀 | 先跑一次人工流程，再写 Rules / Workflows / Skills |

```mermaid
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 |

> [!IMPORTANT]
> “Agent 可以操作”不等于“应该让它自动操作”。真实项目先看副作用，再决定权限。

## 4. 用证据链判断任务质量

一个合格的 Antigravity 任务至少要有下面几类证据中的一部分：

| 证据 | 适用任务 |
| --- | --- |
| Task List | 长任务、并行任务 |
| Implementation Plan | 跨文件、复杂修改 |
| Code Diff | 所有写文件任务 |
| Terminal Output | build、test、lint、排障 |
| Screenshot | UI、布局、断点、主题 |
| Browser Recording | 用户路径、交互流程 |
| Walkthrough | 任务完成后汇总 |

<details>
<summary>深读：为什么“复杂任务”不是越大越适合 Agent</summary>

官方产品定位强调 autonomously plan、execute、verify complex tasks，但这里的 complex 不是“无限大、无边界”。复杂任务适合 agent 的前提是能拆成可审查单元，能通过 artifacts 沟通进展，也能用测试或浏览器证据验证。

如果任务范围大到 diff 无法审、测试无法跑、浏览器路径无法复现，那么它就不再是 agentic development 的优势区，而是风险区。正确做法是先用 Antigravity 做分析和计划，再把实现拆成小批次。
</details>

## 5. 一个真实项目启动模板

```text
请先只读分析当前任务，不要修改文件。

请输出：
1. 任务是否适合 Antigravity 直接执行。
2. 建议使用 Editor、Agent Manager 还是 Browser Subagent。
3. 需要哪些权限和工具。
4. 最小可执行批次。
5. 验收证据：diff / test / screenshot / recording / walkthrough。
6. 哪些动作必须等我确认。
```

## 本章自检

完成本章后，用这 3 个问题检查自己是否真正理解：

1. 哪类任务可以直接交给 Antigravity，哪类必须拆分？
2. 为什么生产数据库、密钥、付款和真实后台操作不能自动放权？
3. 一个前端 UI 任务至少应该交付哪些证据？

通过标准：你能拿到一个真实任务后，先判断任务类型、拆分方式、权限边界和验收证据，而不是直接让 agent 开始改。

## 官方来源

- [Build with Google Antigravity](https://developers.googleblog.com/build-with-google-antigravity-our-new-agentic-development-platform/) —— 官方发布文说明 Antigravity 面向 agentic development，结合 Editor、Manager Surface、Terminal、Browser 和 Artifacts。
- [Google Antigravity Artifacts](https://antigravity.google/docs/artifacts) —— 官方说明 artifacts 作为异步沟通和反馈机制。
- [Google Antigravity Browser](https://antigravity.google/docs/browser) —— 官方说明浏览器可用于测试开发网站、读取数据源和自动化浏览器任务。
- [Google Antigravity Strict Mode](https://antigravity.google/docs/strict-mode) —— 官方说明 strict mode 对副作用能力的安全约束。

## 接下来去哪

<Cards>
  <Card title="排障与官方参考" description="继续整理安装、权限、浏览器、模型额度和反馈入口的排障顺序。" href="/docs/antigravity/official/07-use-cases-reference/01-troubleshooting-reference" />
  <Card title="Browser Subagent 与视觉证据" description="如果你的任务涉及 UI 或断点，回到浏览器证据章节。" href="/docs/antigravity/official/03-browser-artifacts/01-browser-subagent-evidence" />
</Cards>
