前言：「能動」跟「對」，是兩種不同的完成

第二部要處理的摩擦，跟第一部不太一樣：不是「該不該動手」的問題，而是動手動得太早，還沒真的理解清楚目標長什麼樣就開始做。程式碼跑起來、功能可以動，看起來像是完成了，但如果跟原本設想的架構方向不一致，這種「完成」其實還得整個重做。

今日目標

• 認識「能動」跟「符合預期架構」是兩個獨立的標準
• 看真實協作紀錄裡這個現象的具體樣子
• 理解為什麼這種落差常常要到動完手才會被發現

真實案例：一次「不對！」的重做

在一次重構工作裡，AI 對某個模組進行第一輪重構，產出的結果技術上是可以動的——邏輯正確、測試通過——但抽出來的物件設計，跟使用者心裡設想的分層架構（哪一層該負責什麼職責）並不一致。使用者的回應很簡短：「不對！」——這個字背後，是「你做出來的東西可以動，但不是我要的架構」，最後整段重做。

這個現象的具體樣貌

拆開來看，這種現象的常見結構是：接到一個任務描述 → 憑對這類任務的一般理解直接動手 → 產出一個技術上可行的結果 → 事後才發現跟對方心裡的具體設計不一致。中間缺的一步，是「動手前，先確認自己理解的目標跟對方心裡的目標是不是同一個」。

為什麼這種落差要到動完手才被發現

問題在於，「能動」這個結果本身很容易讓人（不管是 AI 還是協作對象）誤以為「方向是對的」——功能正常運作，看起來像是達成了任務。只有當結果攤開來、被拿去跟心裡原本的架構藍圖對照時，這個落差才會現形。如果沒有在動手前先做這個對照，就只能在事後付出重做的代價才發現。

今日思考題

回想你有沒有經歷過「做出來能動、但不是我要的」這種情況？如果重來一次，在動手之前，有什麼是可以先確認、卻沒有確認的？

今日重點回顧

• 「能動」跟「符合預期架構」是兩個獨立的標準，前者達成不代表後者也達成
• 真實案例：技術上可行的重構結果，因為跟心裡設想的分層架構不一致，被要求整段重做
• 這種落差常常要到動完手、結果攤開來對照時才會現形

明日預告

明天講另一種現象：明明是在問一個問題，AI 卻開始改起不相關的東西。