Day 20 認識了 Antigravity，第三週的三個工具到這裡都碰過一輪。但它們散在不同天的筆記裡，看起來像三個各自獨立的新工具。今天不學新東西，把它們放在同一張圖上，確認各自站在哪一層。

今天做三件事：

1. 盤點第三週每天碰了什麼
2. 把 Genkit、Stitch、Antigravity 放進 DevPulse 的流程，確認各自的位置
3. 整理這週觀念上的轉變，為 Day 22 開始組裝做準備

一、第三週盤點

三個工具乍看都在做同一件事：

「讓 AI 幫工程師開發軟體。」

實際用過一輪就會發現：它們不在同一層。 下面逐個拆開。

二、Genkit：AI 的流程控制器

Day 15 剛接觸時，Genkit 看起來只是多一個要學的框架。到了 Day 16、17，Developer UI、Trace、Flow 一個個出現，它的價值才浮現。

它處理的不只是「呼叫 Gemini」，而是把整個過程整理成一條有順序的線：

輸入
 ↓
AI 處理
 ↓
結構化輸出
 ↓
錯誤處理
 ↓
結果驗證

用上 defineFlow() 之後，AI 不再是一次性的 API 呼叫，而是一個有規則的流程。

這對 DevPulse 特別重要。程式碼分析不能只是「把程式丟給 Gemini，然後祈禱它回答得不錯」，它要逐漸變成：

可以重複執行
可以觀察過程
可以驗證結果

三、Stitch：先把成果畫出來

Genkit 偏後端，Stitch 解決的是另一件事：成果長什麼樣子。

Day 18 直接用自然語言描述需求：

我想要一個可以查看程式碼健康狀態的儀表板。

Stitch 據此產生 UI。Day 19 再把結果取回本機，實際修改 HTML 與 Tailwind CSS。

AI 不只能幫忙寫邏輯，也能先把「想法長什麼樣子」做出來。

以前想到一個功能，流程通常是：

想需求
 ↓
畫 Wireframe
 ↓
切 HTML
 ↓
調 CSS
 ↓
慢慢修改

現在至少可以先把「我想要什麼」，快速轉成「它大概會長什麼樣子」。

對 DevPulse 來說，這是必要的一步。核心功能慢慢完成之後，最後不能只剩一堆終端機裡的 JSON，至少要有一個一眼就能看懂結果的介面。

四、Antigravity：第一次碰到 Agent

前面的 AI 工具，大多是協助完成某一個步驟：

我下指令
 ↓
AI 給答案
 ↓
我自己執行

Agent 的流程不一樣：

我描述任務
 ↓
AI 自己規劃
 ↓
執行工具
 ↓
檢查結果
 ↓
繼續處理
 ↓
最後回報

差異不小。以前 AI 像副駕駛，現在開始像一個可以幫忙跑腿的工程師。

使用守則： 把任務交給 Agent，不等於可以完全不管。Agent 能做的事越多，下面三件事越要先想清楚：

1. 要讓它做什麼
2. 它可以碰哪些東西
3. 怎麼驗證結果

這也是這幾年大家一直在談 Agentic Development 的原因。

五、三個工具放在一起

分層之後，三個工具就不是競爭關係，因為它們沒有在搶同一個位置。把 DevPulse 當成一個完整的小產品，流程大概是：

使用者提出需求
        ↓
      Genkit
   AI 分析與流程
        ↓
   產生修復建議
        ↓
   Antigravity
   執行修改與測試
        ↓
      Stitch
   呈現最後結果

第三週學的東西，到這裡可以接成一條線。

六、這週真正的收穫

從「學工具」，轉向「思考工具該放在哪裡」。

提醒： 如果只把這週當成「今天學 Genkit、明天學 Stitch、後天學 Antigravity」，學完很容易全部忘掉。重點是每個工具在流程裡的位置，而不是它的功能清單。

七、手上的零件

前 21 天一直在收集零件：

從明天開始，這些零件要動手組裝了。

明日預告

Day 22：確定 DevPulse 的輪廓。 不再只是「今天學了一個新工具」，而是回答一個更實際的問題：

如果真的每天都在寫程式，希望 DevPulse 幫我完成什麼？

參考資料

• Genkit Flows 官方文件
• Agent permissions｜Antigravity Docs