AI 编程教程中文版
官方教程中文版03 · Browser & Artifacts

Artifacts 与审查反馈

基于官方 Artifacts、Task List、Implementation Plan、Walkthrough 与 Knowledge 文档,建立 Antigravity 任务证据和反馈审查流程。

📖 本篇术语速查表
英文 / 缩写中文一句话解释
Artifacts review工件审查用 agent 产出的工件做审查。
工件类型types计划 / diff / 截图 / 日志。
证据链evidence串成可追溯证据。

不想读完?把下面这段提示词丢给 AI 帮你跑完——帮你用 Antigravity 的工件审查流系统判断 agent 的工作。

你是 Antigravity 工件审查顾问。

【角色】
Antigravity 工件审查顾问,按最小够用、安全优先的原则给可落地方案,每条结论都落到能照做的具体步骤或示例,不停留在「建议」「考虑一下」这类空泛表述。

【输入】
- 这次产出了哪些工件:___
- 我最担心的影响面:___
- 是否有测试 / 截图:___
- 项目关键路径:___
- 经验水平:___

【工作流程】
1. 梳理工件类型和作用
2. 教我按工件审查
3. 标出重点核查项
4. 用工件验证改动
5. 给收尾

【输出规范】
▌一、工件类型
▌二、按工件审查
▌三、重点核查
▌四、验证 + 收尾

【硬约束】
- 靠工件审查不盲信
- 关键路径额外核查
- 工件不足要求补证据
- 不要替我臆测情况或编造不存在的功能,信息不全先问清
- 不确定的配置或接口一律以官方文档为准,禁止照搬过时写法
- 给的每条结论都要落到具体可照做的步骤或示例,不停留在「建议」「考虑一下」这类没法直接执行的空泛表述

Antigravity 的 Artifacts 不是附件,而是 agentic development 的信任层。Google 官方文档把 Artifact 定义为 agent 为了完成工作或向用户沟通工作和思考而创建的任何内容,包括 rich markdown、diff views、architecture diagrams、images、browser recordings、code diffs 等。

换成实操语言:只要任务超过几分钟,或者 agent 不是一步就完成,你就不应该只盯聊天回复,而要看它留下了哪些 artifacts。

阅读目标:读完本章,你应该能用 Task List(任务清单)、Implementation Plan(实现计划)、Walkthrough(任务总结)、diff(代码差异)和 Knowledge(长期记忆)判断 agent 是否真的按目标推进。

1. Artifacts 解决什么问题

官方 Artifacts 文档说明,随着 agents 更自主、运行时间更长,Artifacts 让 agent 可以异步向用户沟通工作,而不是要求用户同步盯住每一步。

这背后的问题很现实:

没有 Artifacts有 Artifacts
你只能看聊天文本你能看任务、计划、diff、截图、录屏
长任务中途容易丢上下文任务状态能沉淀成可回看对象
反馈只能重新发 prompt可以在 artifact 上针对具体内容评论
“完成了”缺少证据结果可以被逐项审查

2. 关键 artifact 类型

官方当前文档里,入门阶段最重要的是这些:

Artifact官方用途审查重点
Task Listagent 处理复杂任务和跟踪进度的 markdown list是否覆盖 research、implementation、verification
Implementation Plan架构和代码修改方案,通常需要用户 review文件范围、技术路线、风险和回退点
Walkthrough任务完成后的简要变更总结是否说明改了什么、怎么验证
Screenshot浏览器页面或元素状态截图UI 是否符合预期,是否可评论反馈
Browser Recording浏览器 subagent 行为录屏操作路径是否真实发生
Knowledge Item自动捕捉和组织会话中的模式、方案、指令是否把长期项目事实写对
flowchart TD
  Goal["用户目标"] --> TaskList["Task List"]
  TaskList --> Plan["Implementation Plan"]
  Plan --> Review{"用户 review"}
  Review -->|评论| Iterate["Agent 迭代计划"]
  Review -->|Proceed| Work["执行实现"]
  Work --> Evidence["Diff / Screenshot / Recording"]
  Evidence --> Walkthrough["Walkthrough"]
  Walkthrough --> Knowledge["Knowledge Item"]

3. Implementation Plan 要认真审

官方 Implementation Plan 文档说明,Agent 会用 plan artifact 架构代码库变更,里面包含必要技术细节,并且通常会在修改前请求用户 review,除非 Artifact Review Policy 设成 Always Proceed。

你审 plan 时不要只看“它写得像不像”。要看这些硬点:

  • 是否说清楚要改哪些文件或模块。
  • 是否解释为什么这样改。
  • 是否有验证方式。
  • 是否漏掉数据、权限、浏览器、部署、回滚风险。
  • 是否把任务范围扩大到你没授权的区域。

如果不满意,官方支持在 artifact 上评论。评论要具体:

这个计划范围太大。请不要改公共配置,只允许改 docs 目录。
请重新生成 implementation plan,并把验证步骤限制为 quality audit 和 build。

Proceed 不是“看起来差不多”。点击前要确认 plan 的范围、风险和验证方式都能接受。

4. Task List 不一定要改,但一定要看

官方 Task List 文档说,它通常用来让 agent 跟踪复杂任务进度,用户一般不需要直接交互。

不需要直接交互,不等于不用审。你至少要看:

观察点风险信号
research 是否独立没查清就直接实现
implementation 是否拆阶段一步大改多个模块
verification 是否具体只写“test”但没有命令
scope 是否稳定中途新增无关目标

5. Walkthrough 是完成后的索引,不是最终验收

官方 Walkthrough 文档说明,Agent 完成任务实现后会创建 walkthrough artifact,用简洁 summary 帮用户回到代码库当前状态;浏览器任务里,它常包含截图和录屏。

Walkthrough 很适合快速理解任务结尾,但不能替代你看 diff、截图和测试输出。

可以把完成验收分成三层:

  1. Walkthrough:快速知道 agent 自称做了什么。
  2. Diff / screenshot / recording:检查证据是否成立。
  3. Build / tests / manual path:确认项目真的能用。
深读:Knowledge 为什么既有价值也要审

官方 Knowledge 文档说明,Knowledge Items 会自动从会话中提取重要 insights、patterns 和 solutions,并在后续 conversation 中被 agent 使用。它能减少长期项目重复解释,但也可能把过时或错误理解带到后续任务。

所以每次发现 agent 引用旧结论时,要检查它是否来自 Knowledge Item。项目规范、路径、命令、权限策略这类长期事实值得沉淀;临时实验、一次性 workaround、未验证假设不应该被当成长期知识。

6. 一套 artifact 审查清单

真实项目可以按这个顺序审:

  1. 先看 Task List 是否拆成 research、implementation、verification。
  2. 再看 Implementation Plan 是否值得 Proceed。
  3. 执行后看 Review Changes / diff。
  4. UI 任务看 screenshot。
  5. 交互任务看 browser recording。
  6. 完成后读 walkthrough。
  7. 长期项目检查 Knowledge 是否写入了正确事实。

本章自检

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

  1. Artifacts 为什么比聊天回复更适合作为长任务验收依据?
  2. Implementation Plan 点 Proceed 前必须检查哪些内容?
  3. Walkthrough 和最终验收有什么区别?

通过标准:你能拿到一个 Agent 任务结果后,按 Task List、Plan、Diff、Screenshot、Recording、Walkthrough 的顺序完成审查。

官方来源

接下来去哪

本页目录