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 的自動生成、檢視和使用方式。