三十天走完了。

今天只做三件事：

1. 把 30 天排成一張知識地圖
2. 老實列出 DevPulse 做到哪、還沒做到哪
3. 決定下一步往哪裡走

一、30 天知識地圖

第三週認識的三件工具，到了第四週各自找到了位置：

二、DevPulse 最後的樣子

有問題的程式
   ↓
codeReviewFlow（找問題）
   ↓
patchFlow（產生補丁）
   ↓
Jest（紅燈 → 綠燈）
   ↓
Antigravity（自動跑完修補與驗收）
   ↓
審查結果 → Stitch 儀表板

三、四個真正留下來的觀念

1. 先定規則，再問問題。
第一週最大的收穫。提問方式，和模型能力一樣重要。

2. 輸出是給程式用的，不是給人讀的。
從 Day 10 的 JSON，到 Day 11 的 Zod，再到 Flow 的 Schema，AI 的回答慢慢變成可以被驗證的資料。

3. 驗收比生成更重要。
Day 22 的 forEach 案例，第一次測試竟然是 PASS，因為測試本身沒抓到 Bug。Day 25 也提醒過：補丁寫進檔案，不等於修好了。

4. AI 的輸入與輸出，都要當成不可信的資料。
Day 28 看進去的字，Day 29 看出來的字。

四、DevPulse 還做不到的事

• 測過的只有四個很短的 .cjs 範例（三個 Bug 加一個注入案例），離真實專案還很遠。
• Gemini 每次的生成不一定相同，一次通過不代表次次通過。
• 提示注入只測了「藏在註解裡」這一種形式。
• AGENTS.md 只是請代理人遵守的規則，不是技術上的限制。
• 它是學習工具，不是資安稽核。

五、接下來想做的三件事

1. 擴充題庫。 每新增一個 Bug，先寫出會失敗的測試，再交給 AI。
2. 補強 Day 28。 把惡意文字放進字串常數、文件內容，並把同一個案例重跑多次。
3. 拿真正在寫的程式碼試跑一次。 DevPulse 最初的目標，就是下班寫程式時順手叫得出來。

系列總結

這個系列從一開始就不是為了名次，而是寫給未來自己的 Google AI 實戰筆記。

30 篇文章，加上一個能在終端機跑起來的 DevPulse，就是這 30 天交出來的作品。

謝謝每一位讀到這裡的朋友。

第一天，是為了破除 AI 焦慮。第三十天，是知道自己下一步要做什麼。

Day 30 完成

• ✅ 完成 30 天知識地圖
• ✅ 整理 DevPulse 的完整流程
• ✅ 誠實列出目前的限制
• ✅ 規劃接下來的三個方向