我有一個舊的 Android TV 專案，想在維持所有功能的前提下，搬到新版的 Android TV template 上重做一次。這件事我決定交給模型做。

我把整包原始碼交給 Gemini 3.1 Pro——當前的旗艦——同時開了一個新目錄，放最新版的 Android TV template。給它的指令大意是：原來的程式碼舊了，要在新版本上、維持所有功能地復現出來；請你直接看程式碼，評估，給方案，過程中有問題都可以問。

它自行查閱之後，先講了一串它對這個專案的判讀——具體內容我已經記不得了——最後回我一句結論：

沒有問題。

接著它給了一份 spec。那份 spec 長得像大綱：

1. 復刻某某功能
2. 復刻某某功能
3. ……

每一條都是「復刻某個功能」，沒有更細的東西。

面對這份大綱，我的反應是：沒什麼意見好提的。不是因為它寫得好、我同意，而是它平滑到我連一個能質疑的點都抓不到——「復刻功能 A」「復刻功能 B」，你要我反對什麼？於是我讓它直接做。

做完，我打開來看——是一個 Android TV template 版本，像個初級版本：畫面跟原版完全不一樣，細部功能也不用說了。我當場傻眼，氣到沒有去深究它到底復刻了什麼、還是根本什麼都沒復刻。

重點不是復刻失敗

復刻失敗沒什麼好寫。我想搞清楚的是：我自己的審查，為什麼在它說「沒問題」的那一刻就被卸掉了。

這種「模型自信地交出空洞產出」的失敗，我不是第一次遇到。最早是 4.x 時代的 GPT——那是舊版本了，現在已經到 5.x，我沒回去驗證過。當時我靠它規劃過兩個專案，規劃階段都很漂亮，做到一半做不下去；回頭問它「當初為什麼覺得可行」，它給我一個編出來的理由把我打發掉。那次讓我第一次注意到一件事：一個模型規劃得再有樣子，那個樣子跟它實際做不做得得出來，可以是完全脫鉤的。

所以這次 Gemini 3.1 Pro 出事，我並不意外於「它做不出來」。我意外的是，明明見過同一種失敗，我的審查還是被繞過去了。問題出在兩個地方。

「沒問題」不是懂的證據

第一個，是「沒問題」這三個字。

它讀完程式碼、講一串判讀、然後說沒問題——這整個過程看起來像它看懂了。但「沒問題」不是它看懂的證據，只是它給出的一個結論。而這個結論的樣子——自信、肯定、像評估過——正好會卸掉我的警戒。

這正是 4.x 那個 GPT 教過我的教訓：模型的自信，跟它真的做不做得做到，是兩件事。差別在於，當年我是事後——兩個專案垮掉——才學會；這次我本該在它說「沒問題」的當下就警覺。

一份無從反駁的大綱，不是一份對的大綱

第二個失守點，是那份大綱。

它只寫到「復刻功能 A／B／C」，沒有任何具體內容。我說「沒什麼意見好提的」——這句話本身就是問題。一份只到大綱程度的 spec，平滑到我連抓手都沒有，當然提不出意見。它過了我的審查，不是因為它對，是因為它沒有形狀。在這裡，含糊變成一面擋住 review 的盾。

自信的評估，加上一份無從反駁的大綱，這兩個加起來，把我的 review 機制整個卸掉了。我一直到打開產出的那一刻，才發現裡面是空的。

我把它從這類任務上撤掉

我沒有回去要它修。我做的決定是：把 Gemini 3.1 Pro 從這類任務上撤掉。

這不是說它沒用。在我看來，它適合的是「明確要求的東西」——需求清楚、邊界明確、不需要它自己去評估「這整件事該怎麼做」的工作，這一類它能勝任。而「你自己看程式碼、評估、給方案、做出來」這種開放式任務，是它的地雷區：正是這種任務，把它的自信跟實際能力之間的 gap 撐到最大。在我的工作流程裡，這等於把它降到只跑需求明確的工作。

結論

這次之後，我對模型那句「沒問題、我做得到」多了一層戒心。它不像「我懂了」的訊號，比較像一個還沒被驗證的承諾。麻煩的是，當它配上一份看不出錯的大綱，會讓我以為已經過了審查——其實是審查被那份平滑繞過去了。

我自己抓到的判準是這樣：一個模型給出很自信的評估，卻只配得上一份大綱級的 spec，那個 gap 本身就是警訊。自信的份量，應該要跟它提出方案的具體程度相稱。自信而空洞，比明明白白說「我不確定」還危險——後者我會繼續盯著，前者會讓我放手。