今天試用了 Google 剛發布的 Gemini 3，搭配他們新推出的 agentic IDE —— Antigravity。號稱是最強的模型，在 LMArena 排行榜上拿下 1501 分的歷史新高，在 Humanity's Last Exam 測試中得分 37.5%，遠超前代的 21.6%。各種基準測試都顯示它的推理能力有質的飛躍。

結果第一次實戰就出包了。

事情是這樣的

我需要做 git reset，把專案回到某個時間點。這是個很常見的操作，對於號稱「最佳 vibe coding 模型」的 Gemini 3 來說應該可以輕鬆處理。

但重點來了：它不是隨便猜的。身為 agentic IDE，Antigravity 確實執行了正確的查詢流程：

  1. 執行 git log --oneline 取得 commit 歷史
  2. 分析每個 commit 的 message 和時間戳記
  3. 在內部的思維過程（thinking）中進行推理
  4. 得出結論：「這個時間點肯定對」
  5. 執行 git reset --hard <hash>

問題是，在它的 thinking 過程中，它對這個判斷非常有把握。不是那種「我覺得可能是這個」的猜測，而是「經過分析，這就是正確的時間點」的確定感。

結果 reset 太過頭，時間點完全不對。

問題出在哪？推理能力 vs. 推理正確性

這次出包讓我意識到一個關鍵問題：工具使用能力和推理正確性是兩回事。

它做對了什麼

從流程上看，Antigravity + Gemini 3 的表現其實很標準：

# 第一步：取得資訊
$ git log --oneline -20
a1b2c3d (HEAD -> main) 修復登入問題
d4e5f6g 更新 API 端點
h7i8j9k 重構用戶驗證
...

# 第二步：分析判斷
[在 thinking 中]
"根據 commit message 和時間序列，
用戶想回到『重構用戶驗證』之前的狀態，
應該 reset 到 h7i8j9k"

# 第三步：執行操作
$ git reset --hard h7i8j9k

這個流程沒問題，有查詢、有分析、有執行。問題在於中間那層推理出錯了。

它錯在哪裡

我事後檢查 commit 歷史才發現，它對「時間點」的理解有偏差。可能的原因：

  1. Commit message 的語義理解錯誤 它可能把某個 commit 的 message 理解成「這之前的狀態」，但實際上那個 message 是在描述「這次改了什麼」。這是自然語言理解的典型陷阱。

  2. 時間序列的相對判斷失準 當 commit 之間的時間很近（比如幾分鐘內連續 commit），AI 可能無法準確判斷「before/after」的相對關係。特別是當需求描述模糊時（「回到那個時間點」而不是「回到 commit abc123」）。

  3. 缺乏二次確認機制 人類開發者在做 reset 前，通常會先用 git log -p 看一下那個 commit 的實際改動，或者用 git show <hash> 確認內容。AI 直接跳過了這個驗證步驟。

更深層的問題：過度自信

最危險的不是推理錯誤本身，而是錯誤伴隨著高度自信。

在 Antigravity 的 thinking 過程中，我看到它的推理鏈是這樣的：

1. 分析需求 → "用戶想回到某個時間點"
2. 檢視 commit → "這些是最近的 commits"
3. 模式匹配 → "這個 message 符合描述"
4. 得出結論 → "就是這個，確定無誤"
5. 執行操作 → git reset --hard

注意第 4 步的「確定無誤」。這種確定感是從推理鏈的「內部一致性」來的 —— 每一步在邏輯上都說得通，所以整體結論就被標記為「高可信度」。

但問題是，邏輯一致不等於事實正確。

這讓我想起經典的 AI 對齊問題：一個 AI 可以有完美的內部邏輯，但如果它對外部世界的理解有偏差，那再嚴謹的推理也會得出錯誤的結論。

Git Reflog 救了我：版本控制的「後悔藥」機制

當我意識到 reset 錯了，第一反應是：「呼，還好是 Git。」

Reflog 的運作原理

很多人以為 git reset --hard 會永久刪除 commit，其實不是。Git 的設計哲學是：除非你明確要求，否則不會真的刪除任何東西。

# 查看完整的操作歷史
$ git reflog
a1b2c3d HEAD@{0}: reset: moving to a1b2c3d
h7i8j9k HEAD@{1}: reset: moving to h7i8j9k  # ← 這是 AI 做的錯誤 reset
m9n8o7p HEAD@{2}: commit: 原本的最新 commit
k6l5m4n HEAD@{3}: commit: 前一個 commit
...

Reflog（reference log）記錄的是 HEAD 指標的移動歷史，而不只是 commit 歷史。每次你做 commit、checkout、reset、merge，Git 都會在 reflog 中留下記錄。

預設保留期限：

  • 未被引用的 commit：30 天
  • 被引用過的 commit：90 天

這意味著即使你 reset 掉某個 commit，只要在 90 天內，它的實體資料（blob、tree、commit object）都還在 .git/objects/ 裡面，只是沒有分支或 tag 指向它而已。

實際救援過程

# 1. 找到正確的 commit
$ git reflog
# 仔細看每個 HEAD@{n} 的操作和 hash

# 2. 確認那個 commit 的內容
$ git show m9n8o7p
# 檢查 commit message 和 diff，確認這才是我要的

# 3. 還原
$ git reset --hard m9n8o7p
HEAD is now at m9n8o7p 原本的最新 commit

# 4. 保險起見，建立一個備份分支指向它
$ git branch recovery-backup m9n8o7p

救回來了。

Reflog 的局限性

值得注意的是，reflog 是本地的。如果你的 .git 目錄損毀，或者你是在另一台機器上重新 clone，reflog 就沒用了。

這也是為什麼：

  1. 經常 push 到遠端：遠端倉庫是最可靠的備份
  2. 重要分支打 tag：tag 是永久引用，不會被 gc 清理
  3. 危險操作前先建分支：git branch backup-$(date +%Y%m%d)

Git 給了你後悔的機會，但不是無限期的。

學到什麼？從這次出包中得到的深刻教訓

1. AI 的自信不等於正確：認知校準問題

再強的模型都會錯，但 Gemini 3 這次的錯誤方式特別值得警惕。

傳統程式錯誤通常很明顯：要麼 crash、要麼回傳錯誤訊息。但 AI 的錯誤是無聲的：它會給你一個看起來合理的答案，伴隨著高度自信，然後你就執行了。

這在認知科學中叫做「校準問題」（calibration problem）：一個系統的主觀信心和客觀準確度之間的對應關係。理想狀態下：

  • 當 AI 說「我 90% 確定」時，應該有 90% 的正確率
  • 當它說「我不太確定」時，正確率應該明顯下降

但現實是，大型語言模型的校準很差。它們經常在錯誤的答案上表現出高度自信，因為：

  1. MoE 架構的路由決策：Gemini 3 使用 sparse Mixture of Experts 架構，將問題路由到特定的專家網路。但當路由決策本身有偏差時，即使選中的專家很有信心，整體判斷仍可能出錯
  2. 思維鏈增強自信：當模型生成一個邏輯鏈時，每個步驟都強化了最終結論的可信度，即使起點就錯了
  3. 訓練目標與實際需求的落差：雖然使用了 RLHCF（人類和批評反饋的強化學習），但訓練資料中可能缺乏「承認不確定性」的範例

實踐建議：

  • 把 AI 的「確定」當成「它認為邏輯通順」，而不是「事實正確」
  • 對破壞性操作，永遠執行二次驗證
  • 建立自己的檢查清單，不要依賴 AI 的自我檢查

2. 人機協作的邊界：什麼該交給 AI，什麼不該

用一根手指打字的我，確實很依賴自動化。但這次證明了：打字成本高不代表可以跳過確認步驟。

我重新思考了人機協作的邊界：

AI 適合處理的任務

  • 高重複性、低風險：格式轉換、批次處理、樣板程式碼生成
  • 探索性、可逆的：原型開發、方案比較、重構建議
  • 輔助性、提供選項：「這裡有三種做法，你覺得哪個好？」

人類必須把關的任務

  • 破壞性操作：git reset、資料庫 DROP、檔案刪除
  • 需要脈絡的判斷：「這個改動是否符合專案目標？」
  • 安全性檢查：權限設定、加密金鑰、敏感資料處理

關鍵是最終決策權。AI 可以做前 99% 的工作，但最後那 1% 的「確定執行」應該在你手上。

實作建議：Agentic IDE 的「安全模式」

理想的 agentic IDE 應該有分層授權機制：

# 假設的設定檔
agent_permissions:
  auto_execute:
    - file_read
    - search
    - lint
    - test

  require_confirmation:
    - file_write
    - git_commit
    - package_install

  always_manual:
    - git_reset
    - git_push --force
    - database_migration
    - system_command

這樣既保留了自動化的效率，又在關鍵點加入人類把關。

3. Git 設計的智慧：為犯錯而設計

這次經驗讓我重新認識 Git 的設計哲學。

很多人抱怨 Git 難用、指令複雜、概念抽象。但這些「複雜性」背後有一個核心理念：假設使用者會犯錯，並為此設計安全網。

Git 的多層保護機制

  1. Working Directory / Staging / Repository 三層結構 讓你可以在 commit 前反悔（git restore）

  2. 分支的輕量化 建立分支幾乎零成本，鼓勵你在實驗前先 branch

  3. Reflog 的自動記錄 不需要你手動「存檔」，每個操作都被記錄

  4. Detached HEAD 的警告 當你進入危險狀態，Git 會明確警告你

  5. Force push 需要明確的 flag git push --force 而不是預設行為，強迫你意識到這是危險操作

這些設計都在說：我知道你會犯錯，我幫你留了後路。

對比：為什麼其他工具沒這麼做？

很多現代工具追求「簡單」，把複雜性藏起來：

  • 一鍵部署
  • 自動同步
  • 智慧判斷

這在 99% 的情況下很方便，但在那 1% 出錯時，你連救援的機會都沒有。

Git 的「複雜」是一種誠實：它不假裝能理解你的所有意圖，所以給你完整的控制權和救援工具。

4. 實務建議：與 Agentic 工具共存的最佳實踐

基於這次經驗，我整理了一套實務原則：

使用前

# 危險操作前永遠先備份
git branch backup-$(date +%Y%m%d-%H%M)

# 或者用 stash 保存當前狀態
git stash push -m "before AI operation"

使用中

  1. 讀懂 AI 的推理過程 如果工具有 thinking 輸出，花 10 秒看一下邏輯鏈

  2. 建立檢查清單

    [ ] 確認操作對象正確
[ ] 確認參數合理
[ ] 確認可回溯

  3. 分段執行 複雜任務拆成小步驟，每步驗證後再繼續

  4. 保持懷疑 AI 越確定，你越要小心（這聽起來很諷刺，但確實有效）

使用後

# 驗證結果
git status
git log --oneline -5
git diff HEAD@{1}

# 確認符合預期再繼續

這些步驟不會花太多時間，但能避免大部分災難。

結論：Agentic 時代的生存指南

這次出包給我最大的啟示是：我們正處於一個過渡期。

Agentic 工具的願景很美好：讓 AI 像同事一樣自主完成任務，你只需要描述需求，剩下的交給它。但現實是，這些工具還在學習「什麼時候該自主，什麼時候該求助」。

Antigravity 代表的挑戰

Google 推出 Antigravity 的速度很快 —— Gemini 3 發布當天就整合進 IDE。這種積極度反映了業界對 agentic 開發的期待，但也暴露了一個問題：工具的成熟度跟不上發布速度。

這不是 Google 獨有的問題。整個 AI 產業都在快速疊代：

  • Cursor 的 Agent Mode
  • Windsurf 的 agentic 工作流程
  • Replit Agent
  • GitHub Copilot Workspace

每家都在搶「agentic 開發」的灘頭堡，但沒有人真正解決「如何在自主性和安全性之間找平衡」這個核心問題。

使用者的責任

在這個過渡期，責任落在使用者身上：

  1. 不要盲目信任 即使工具看起來很聰明，它還是會犯錯

  2. 建立自己的安全網 工具沒提供的保護機制，你自己要建（備份、驗證、回溯點）

  3. 給反饋 這些工具還在進化，你的使用經驗（包括出包經驗）對改進很重要

  4. 保持學習 了解底層機制（像 Git 這樣的工具）讓你在 AI 出錯時有能力救援

長遠來看

我依然看好 agentic 工具的未來。畢竟，用一根手指打字的我，如果沒有 AI 輔助，根本不可能維護生產環境的系統、開發全端應用。

但這個未來需要時間。需要更好的：

  • 風險評估機制：AI 知道這個操作有多危險
  • 不確定性量化：AI 能誠實表達「我不確定」
  • 可解釋性：讓你理解它為什麼這樣做
  • 快速回溯：出錯時一鍵回到安全狀態

在那之前，記住這個 Lesson learned：

再聰明的 AI，都比不上你多看一眼。