Agy CLI 跟以前的 Gemini CLI 差在哪？

如果大家之前用過舊版的 Gemini CLI，可能會覺得計畫模式（Plan Mode）有點煩。

每次請 Gemini CLI 做完規劃後，會在畫面中出現一個計劃框，還要特別按組合鍵展開才能看全部，有種多此一舉的感覺；所以 Agy CLI 完成計畫模式後，將計畫文件產出成檔案，先執行 /artifact 再把計劃文件檔案打開（open），沒問題就執行同意（approve），有問題就繼續跟他溝通

檔案的架構長怎樣？目錄都在哪裡？

在 Antigravity 系統中，產出的檔案絕非隨意寫入暫存區，而是有著嚴謹的目錄組織規範：

~/.gemini/antigravity-cli/brain/ (應用程式資料根目錄)
  └── <conversation-id>/ (目前對話專屬目錄)
        ├── architecture_report.md (Markdown 結構化檔案)
        ├── interactive_widget.html (Generative UI 互動檔案)
        ├── scratch/ (一次性除錯腳本與暫存資料)
        └── .system_generated/logs/
              └── transcript.jsonl (對話軌跡紀錄)

每當對話建立時，系統會自動分配一個唯一的對話識別碼（Conversation ID），所有由 AI 代理或使用者產生的檔案均會持久化保存在該目錄下。

檔案的運作流程怎麼跑？

┌────────────────────────────────────────────────────────┐
│ 1. 【開發者】在終端機輸入請求 (如：請產出系統架構報告)     │
└───────────────────────────┬────────────────────────────┘
                            ▼
┌────────────────────────────────────────────────────────┐
│ 2. 【Antigravity CLI】將提示詞與上下文傳送給 AI 代理      │
└───────────────────────────┬────────────────────────────┘
                            ▼
┌────────────────────────────────────────────────────────┐
│ 3. 【AI 代理】呼叫 write_to_file 將內容寫入本地專屬目錄   │
└───────────────────────────┬────────────────────────────┘
                            ▼
┌────────────────────────────────────────────────────────┐
│ 4. 【本地目錄】檔案建立成功，AI 回傳摘要與檔案超連結       │
└───────────────────────────┬────────────────────────────┘
                            ▼
┌────────────────────────────────────────────────────────┐
│ 5. 【終端機】顯示可開啟  plan.md 檢閱，Approve 同意執行   │
└────────────────────────────────────────────────────────┘

檔案支援多種進階表現形式：

1. 結構化 Markdown 與語意警示框：支援 > [!NOTE]、> [!IMPORTANT]、> [!WARNING] 等語意區塊，內容層次分明。
2. 終端機友善的等寬純文字圖表：可在產出檔案中直接編寫排版整齊的架構圖或時序圖，在純文字環境中完全不跑版。
3. 輪播圖（Carousel）：如果看到產出檔案帶有四個反引號的 ````carousel 語法，因為這是 Antigravity 體系為了 2.0 桌面版預覽器設計的輪播語法。在 Agy CLI 終端機中，它會以分頁程式碼對照區塊呈現。

/artifact 怎麼用？

假如我們要求代理對專案進行資料庫架構設計並產出產出檔案，在提示字元中輸入：

/Plan 請針對我們即將開發的電商系統，設計一個包含 User、Order、Product 的關聯模型，並輸出為結構化的架構報告產出檔案。

代理的實際動作與產出

代理會在背景呼叫檔案寫入工具，在產出檔案目錄中建立 ecommerce_schema.md：

# 電商系統資料庫架構設計報告

> [!NOTE]
> 本設計採用 PostgreSQL 關聯式架構，重點最佳化訂單查詢與庫存扣減之一致性。

## 資料實體關聯圖 (ER Diagram)

┌────────────────┐       1:N       ┌────────────────┐
│      USER      │◄───────────────┤     ORDER      │
├────────────────┤ places          ├────────────────┤
│ id (UUID, PK)  │                 │ id (UUID, PK)  │
│ email (UK)     │                 │ user_id (FK)   │
│ name           │                 │ total_amount   │
│ created_at     │                 │ status         │
└────────────────┘                 └───────┬────────┘
                                           │
                                       1:N │ contains
                                           ▼
┌────────────────┐       1:N       ┌────────────────┐
│    PRODUCT     │◄───────────────┤   ORDER_ITEM   │
├────────────────┤ ordered in      ├────────────────┤
│ id (UUID, PK)  │                 │ id (UUID, PK)  │
│ title          │                 │ order_id (FK)  │
│ price          │                 │ product_id (FK)│
│ stock          │                 │ quantity       │
└────────────────┘                 │ unit_price     │
                                   └────────────────┘

## 效能索引建議
1. `ORDER.user_id`：建立 B-Tree 索引以加速歷史訂單檢索。
2. `PRODUCT.stock`：搭配樂觀鎖定（Optimistic Locking）機制。

終端機上的簡潔呈現

這時終端機不會被數百行內容洗版，而是優雅地回覆：

已為您完成電商系統資料庫架構設計！詳細內容已儲存至產出檔案：
[ecommerce_schema.md]

您可以點擊開啟計畫檢視，確認無誤後請點擊 Approve，我立刻幫您實作電商系統資料庫架構設計