Artifacts 与审查反馈
基于官方 Artifacts、Task List、Implementation Plan、Walkthrough 与 Knowledge 文档，建立 Antigravity 任务证据和反馈审查流程。
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 List | agent 处理复杂任务和跟踪进度的 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、截图和测试输出。
可以把完成验收分成三层：
- Walkthrough：快速知道 agent 自称做了什么。
- Diff / screenshot / recording：检查证据是否成立。
- Build / tests / manual path：确认项目真的能用。
深读：Knowledge 为什么既有价值也要审
官方 Knowledge 文档说明，Knowledge Items 会自动从会话中提取重要 insights、patterns 和 solutions，并在后续 conversation 中被 agent 使用。它能减少长期项目重复解释，但也可能把过时或错误理解带到后续任务。
所以每次发现 agent 引用旧结论时，要检查它是否来自 Knowledge Item。项目规范、路径、命令、权限策略这类长期事实值得沉淀；临时实验、一次性 workaround、未验证假设不应该被当成长期知识。
6. 一套 artifact 审查清单
真实项目可以按这个顺序审：
- 先看 Task List 是否拆成 research、implementation、verification。
- 再看 Implementation Plan 是否值得 Proceed。
- 执行后看 Review Changes / diff。
- UI 任务看 screenshot。
- 交互任务看 browser recording。
- 完成后读 walkthrough。
- 长期项目检查 Knowledge 是否写入了正确事实。
本章自检
完成本章后，用这 3 个问题检查自己是否真正理解：
- Artifacts 为什么比聊天回复更适合作为长任务验收依据？
- Implementation Plan 点 Proceed 前必须检查哪些内容？
- Walkthrough 和最终验收有什么区别？
通过标准：你能拿到一个 Agent 任务结果后，按 Task List、Plan、Diff、Screenshot、Recording、Walkthrough 的顺序完成审查。
官方来源
- Google Antigravity Artifacts —— 官方定义 Artifact，并说明异步沟通和反馈机制。
- Google Antigravity Task List —— 官方说明 Task List 用于复杂任务和进度跟踪。
- Google Antigravity Implementation Plan —— 官方说明 plan review、Proceed、评论和重新审查流程。
- Google Antigravity Walkthrough —— 官方说明任务完成后的 walkthrough summary 和浏览器证据。
- Google Antigravity Knowledge —— 官方说明 Knowledge Items 的自动生成、查看和使用方式。