Google Antigravity 适合哪些开发任务：代理式开发平台的权限、验证与回退边界

Google 在 I/O 2026 开发者公告中把 Antigravity 定义为面向代理式开发的平台：开发者可以让代理参与从想法到应用的推进。真正落地时，关键不在于“能不能自动写代码”，而在于任务边界是否清楚、权限是否够小、结果能不能被独立验收。

先把代理任务收窄到可验收的动作

“做一个完整应用”适合作为探索目标，不适合作为一次性执行指令。任务越大，代理越容易在依赖选择、目录结构和默认配置上连续做出未经确认的决定，最后很难判断问题出在哪一步。

更实用的拆法是给每个任务写清输入、允许改动的目录、完成条件和禁止事项。例如先生成一个独立的 API 客户端，再让它补测试，最后由人检查依赖和错误处理。每一步都能单独提交或撤销，出了问题不会把整个工作区变成黑盒。

适合交给代理的三类工作

• 边界明确的样板代码、数据转换和测试用例补全。
• 已有规范约束下的重命名、格式迁移和文档初稿。
• 可以在临时分支中运行、检查并回滚的实验性改动。

权限设计决定了它能造成多大影响

代理能调用什么，比它会不会写代码更值得先确认。默认让它拥有生产数据库写权限、云资源管理权限或全量密钥读取权限，出了误判就不是代码评审能补救的事情。

建议把权限分成三层：只读检索、沙箱内写入、需要人工批准的外部动作。开发任务先停留在前两层；发布、删除、迁移和发送外部消息等动作，应当产生明确的待确认结果，而不是顺手执行。

一个可执行的任务描述

目标：为 /internal/report 增加参数校验
允许修改：cmd/report、internal/report、对应测试目录
禁止操作：生产环境、数据库迁移、读取 .env
验收：go test ./internal/report ./cmd/report 全部通过
回退：只提交当前分支，失败时恢复本次提交

这段约束看起来朴素，却把“完成”从一句模糊要求变成了可检查的证据。任务结束后，先看改动范围，再看测试输出，最后才考虑是否合并。

不要把代理自己的反馈当成验收结果

代理说“测试通过”只说明它报告了一个结果。工程师仍要在干净环境复跑关键命令，检查新增依赖、配置差异和边界输入。尤其是能修改构建脚本或测试配置的代理，必须确认测试没有被意外绕开。

验证至少分两次：第一次在代理工作区快速反馈，第二次在独立环境或干净分支复核。两次结果不一致时不要急着重试，让差异先留下来，通常比再生成一版代码更容易定位原因。

失败时怎样回到稳定版本

回退路径要在开始前就存在。最小做法是每个代理任务对应一个独立分支或提交点，记录运行命令和变更摘要；涉及配置的任务还要保存改动前后的有效配置。没有这些信息，所谓“撤销”往往只能手工猜测。

如果任务改动跨越多个目录，先按功能拆成小提交，再逐个验证。出现构建失败、权限越界或数据结果异常时，回到最近一个通过验收的提交，保留失败日志用于复盘，不要让代理继续在错误状态上叠加修改。

常见误区与复盘清单

把产品能力介绍当成生产承诺

官方公告说明的是产品方向和可用能力，不等于特定团队的安全、性能或合规结论。上线前仍要根据自己的仓库、密钥策略、审计要求和数据等级做验证。

只给目标，不给停止条件

“把接口做好”没有明确终点。应补充允许目录、命令、测试、禁止操作和人工确认点，让代理在遇到不确定依赖或失败测试时停下来。

复盘时只看最终代码

还要看它使用过的工具、访问过的文件、失败过的命令和被人工否决的方案。下一轮改进的常常不是提示词，而是权限和验收脚本。

相关问题

代理式开发能替代代码评审吗？

不能。它可以减少机械检查和样板编写，但权限、业务约束、异常处理和上线风险仍需要独立的人或自动化门禁确认。

什么时候应该直接停止代理任务？

当它要求扩大权限、修改未授权目录、连续失败却改变测试条件，或任务结果涉及不可逆外部动作时，应停止并回到人工判断。

总结

Antigravity 这类平台的价值，在于把开发者从一部分重复操作中解放出来，而不是替开发者承担最终责任。把任务切小、权限收窄、验证独立、回退可执行，才是把代理放进真实工程流程的最低安全线。