對印度工程師 R 的一段對話，真正暴露的是 AI Agent 時代的認知轉換
帶一個工程師用 AI，最難的不是教他用工具，而是判斷一件更根本的事：
要幫他修補舊框架，還是挑戰舊框架？
這兩個選擇表面上差不多，長期效果完全不同。前者讓對方更舒服地待在原地；後者讓對方有機會真正移動。
最近和一位印度工程師 R 的一段對話，讓這個判斷變得很清晰。
此為深度內容 — 這篇文章深度分析 AI Agent 時代的認知框架轉換，探討舊思維如何阻礙工程師發揮協作優勢。
事情的起點：一個很具體的存檔錯誤
R 在處理 database dump 時，把要輸出的 .sql 檔案指向了一個錯誤的路徑，並傳來截圖，表示系統提示需要 root permission 才能存檔。他展示這張截圖的同時，帶著一個潛台詞：自己是照著 Claude 的步驟去做的。
表面上這像是一個權限問題，但仔細看那個路徑，問題更基本：檔案要被存入的是一般使用者本來就沒有寫入權限的位置。
R 把 Claude 提供的範例直接當成可以原封不動執行的指令，少了一層對實際環境的再判斷。截圖的潛台詞是「問題可能不在我」，但真正需要回頭問的是：我一開始把目的地設對了嗎？
這種反應在早期 AI 使用者中很常見：把 AI 當成權威步驟來源，照做之後若出現阻礙，就傾向先證明自己有照做，而不是先回頭檢查任務定義是否合理。
介面不是問題，使用模式才是
我向 R 說明，我可以直接要求 Claude dump database 成 SQL 檔案、再搬到本機 Downloads folder，整件事十秒內完成。R 的回覆落在：這個截圖是 Claude Code CLI 的畫面、他自己是 VS Code Claude、所以兩者不同。
這是一個典型的舊框架反應——把介面差異當成本質差異。
我真正想說的是：就算介面不同，Claude 的使用模式其實是一樣的。 真正的差異不是 UI，而是你把 Claude 當成什麼：
- 當成 chatbot：「How do I dump the database to SQL?」
- 當成 executor：「Dump the database to SQL and move it to my Downloads folder.」
表面上只差一句英文，背後是整個工作邏輯的切換。
那句話，暴露的不是對錯，而是思維位置
R 後來問了一句值得細看的話：
So both me and the screenshot I sent are wrong, right?
這句話的問題不是 defensive，而是它暴露了三件事同時發生：
他在尋找二元判決。 把複雜問題壓縮成最容易求解的是非題，是還沒理解 abstraction layer 時的典型反應。真正的問題不是「你對還是錯」，而是：你看到了哪一層、忽略了哪一層。
他還在用舊工具時代的語法。 傳統工具世界裡的典型反應是「我哪一步錯了、正確步驟是什麼」。但在 agent world，問題不再是步驟，而是：任務是否清楚、邊界是否清楚、結果是否可驗證。
他把判斷工作外包給對方。 更高解析度的問法應該是：「So the problem is not CLI vs VS Code, but whether I’m treating Claude like an executor. Correct?」這是在驗證自己的理解，而不是在等人宣判。
為什麼我沒有直接回答 yes 或 no
我回的是：
What do you think yourself?
這不是在把球丟回去，而是一個刻意的判斷：如果我直接給答案，我幫的是他的舒適感，不是他的思維。
舊框架回覆讓對方以為問題只是資訊不足、步驟不清。但如果真正的瓶頸是 mental model 沒轉過來，給他再多步驟，也只是讓他更熟練地待在舊框架裡。
新框架回覆的目的是改變對方產生答案的方式：
Wrong way: “How do I dump the database to SQL?” Right way: “Dump the database to SQL and move it to my Downloads folder.”
這不是修 prompt wording，而是在切換工作的基本單位——從「問問題」到「定義任務」。
珠算與 Excel：認知介面的切換問題
一個習慣打算盤的人，第一次拿到 Excel，可能會先問：珠子在哪邊？
這個比喻說的是所有工具切換的共同障礙：人們不是看不懂新工具，而是先去找舊世界熟悉的零件。珠算的人找珠子、打字機的人找回車桿、傳統工程師找 step-by-step 教學、把 AI 當搜尋框的人找「how」。
R 在面對 Claude 時也在找他的珠子：明確的按鈕對應、介面差異、教學式邏輯、對錯判定式的回饋。
Stack Overflow 2024 年的調查顯示，超過六萬名開發者中，76% 正在使用或計劃使用 AI 工具，實際使用率從 44% 升至 62%；但只有 43% 的人對 AI 輸出的準確性表示有信心。工具採用率在快速上升，但真正知道怎麼協作的人，仍是少數。
認知介面（cognitive interface） 還沒切換的人，就算拿到最好的工具，用的仍然是舊世界的方式。
裁員背景讓這個判斷變得更重
這段對話還有一個重要背景：公司已經把印度開發團隊削減到只剩原本的五分之一，R 是留下來的少數成員之一。
這個背景改變了判斷的重量。
在人力充裕的環境裡，框架切換可以慢慢來；在只剩 1/5 的團隊裡，每個人能不能完成思維升級，直接影響整個團隊的產能上限。這不是抽象的說法——連 Fremont 的老闆都已經親自下場，用 Claude 開發新的行銷工具，取代傳統行銷方式。當組織裡最高層的人都在直接使用 AI 工具，還在等待標準答案的工程師，位置會變得非常尷尬。GitHub 2024 年的研究發現，懂得把任務清楚交給 AI 的工程師，完成時間從平均 2 小時 41 分縮短至 1 小時 11 分。這不是邊際差異，是一倍以上的槓桿。
如果我用舊框架回覆 R——告訴他哪一步錯了、CLI 和 VS Code 有什麼差異——短期上他會感覺問題解決了。但我其實是在讓他更舒服地留在一個即將無法適應的工作模式裡。
這才是這段對話真正的問題所在：不是 R 懂不懂 Claude，而是我要選擇幫他維持現狀，還是給他一個機會移動。
真正的善意，不一定讓人舒服
工程師文化裡的善意常常被誤解成「直接給他答案」「不要讓他挫折」。
但在某些情境下，真正的善意是：不要繼續幫對方穩固一個即將過時的工作方式。
- 修補舊框架：讓對方更舒服地延續舊模式
- 挑戰舊框架：讓對方有機會不被未來淘汰
我對 R 的回覆不是冷淡，而是一個長線判斷——在一個已經高度收縮的團隊裡，短期友善有時候是長期的代價。
結論
這整件事表面上只是 Claude Code CLI 與 VS Code Claude 的介面討論，但它真正測試的是一件更根本的事：
一個人遇到阻礙時，會先看表面訊號，還是先回到任務結構本身？
這個反應模式，在 AI Agent 時代正在快速成為工程師能不能真正發揮槓桿的分水嶺。
工具採用不等於思維切換。而管理者能做的，是判斷什麼時候該幫人修補、什麼時候該讓人重新定位——然後做出那個選擇，即使短期上比較不舒服。
認知的改變，才能真正驅動 AI Agent。
數據來源
想看更多作品、服務與主站整理，請前往 stanwu.org。