前幾天的連假，有一段跟朋友的對話大概是這樣的：
Ｘ的，我辛辛苦苦弄了半天，老闆說我這一定是ＡＩ做的。
Ｘ的，我review好幾遍還是有一些錯誤，老闆就說我都貼ＡＩ產生的都沒有確認。
聽完後自己心裡也是有一些小小的感觸，如果你過去這兩年有認真的使用ＡＩ來加速工作的產出，應該多少也都會經歷過成果被ＡＩ工具稀釋、責任卻被全盤放大的荒謬循環。
花兩天推敲出來的系統架構，主管瞄一眼說「現在有 Claude 真的很爽齁」，而正式環境的設定一個參數沒更新到ＣＩＣＤ上導致監控的telemetry 狂噴錯誤，「怎們有ＡＩ幫忙還連這個都沒處理好」。
我也不是什麼心理學家，但是過往好像也有過這樣的心理偏誤的情境，紀錄一下自己如果是「當事者」與「主管」的兩種角色，給出各自該如何應對、把關與自處的策略。
功勞歸因偏誤
人的大腦在評估產值時天生就有盲點，即便在沒有AI的狀況下在團隊管理也很常出現類似的狀況，而在導入ＡＩ後，這些ＡＩ成本因為更低廉，更容易讓這種認知偏差顯得放大，尤其是習慣將完美的系統產出全數歸因於底層演算法，卻把任何小瑕疵單方面歸咎於人類操作者的疏失與偷懶。
戴著自動化偏見的眼鏡下，我們也會在默默的將自動化工具介入的成果打折。
為什麼會這樣？因為非第一線操作的主管，看見的只有「下提示詞、3 秒噴出幾百行Code」的表面現象，沒看見你為了驗證輸出換了幾次 Prompt、多拉了幾份內部規格書，更沒看見你為了避免錯誤，而多試的驗證流程，而過去看你在白板上畫圖討論，整理規格書，那些「可見的掙扎」，現在都只在你跟ＡＩ的對話裡。
AI勞動的外顯化
如果你是第一線工程師，面對這種偏誤，生悶氣或直接開訐應該是最不理智的選擇，想想要怎麼讓你的智力勞動表現出你的決策成本比較實在一點。
1. 承認工具好用，但秒接工作
當主管看著成果微笑說「這功能寫得真快，現在有 AI 真的很方便」時，千萬別只回「對啊滿省事的」，也不用急著辯解。
初級大人的回應是大大方方承認使用工具，但順手帶出不可替代的情境：
「AI 確實幫忙省下大概 80% 寫 MVP 的 effort，不過架構上我有跟他說這是混合雲的架構，光是網路與gateway的串接機房的那兩台老機器，就花了超久，AI 給的第一版甚至會打爆connection pool，最後還是透過一些非同步的架構來完成，我有針對我們機房的硬體瓶頸手動調整，不然直接照它建議跑，肯定會ＧＧ。」
2. 定義特例規則
交付工作成果時，最忌諱就是說「AI 當時就是這樣給我的」。
這時候要把疏失定義成「未被制度化的內部特例」，並拿出具體防堵動作：
「這個後端ＡＰＩ在 4 種測試案例都 pass，這次漏掉的是因為藍牙裝置端偶爾會傳送空陣列，才會有Bug，這種在系統特有的非標準規格，AI 通常不會知道這樣的Context，我在 code review 時也只注意安全性上實作，漏了這個case，剛剛已經把這個規則補進驗證清單，順便加了單元測試，以後無論是人寫的還是 AI 寫的，只要打進來都會被擋掉。」
這樣既承認了review的疏漏，但也強調了特例的特殊性，最後用自動化測試收尾。
3. 拆分實作與驗證時程
「既然有 Copilot，這個功能原本要兩週，應該只要兩天就好了吧」，這就是典型的魔法幻想。
你要做的是把時間結構算給他看：
「生成第一版Code大概只佔開發流程的 15% 到 20%，後面還要花時間跟 API 的測試與整合，以及要綁定第三方簽章，後續還要做 mock 壓測，最快下週三能提供E2E驗證的RC版本。」
4. 在 PR 與文件留下決策存證
以前能在白板上看到你思考，現在請把思考過程搬到 PR 描述與架構文件裡。
在提交 PR 時，順手附上：
- 本次評估過 3 種由 AI 推薦的模式，排除前兩種的原因（例如記憶體Cost過高、現有資料無法migrate等）。
- 本地壓力測試數據驗證腳本。
當點開 PR時，看到的就不是單純幾百幾千行 Code，而是密密麻麻的架構思考與決策過程，自然就不敢嘴 評論「你只是在複製貼上」。
如果你是 Tech Lead、Engineering Manager 或帶小團隊的資深工程師，你的挑戰其實更大且完全反過來，還需要避免Junior 成員只拿瑞士刀剪指甲，或是盲目貼Code捅出簍子。
1. 校正心態
很多主管口頭禪是「有ＡＩ很簡單啊」，這句話其實滿傷團隊士氣的。它傳遞出來的信號是：你的專業跟經驗一文不值，我阿嬤都比你會寫 。
以前三大前端框架百花齊放時加上各種design system Component 隨便套時，有個前輩都是這樣稱讚Intern的，「這幾個component串成這個新的 Wizard，流程真的很順」，肯定同仁駕馭工具與判斷的眼光，而不是稱讚工具本身。
2. 建立防呆機制
Junior工程師最容易被 AI 迷惑，LLM 最危險的地方不在於寫出語法錯誤的Code，而在於寫出「看起來完美、本地端可以跑、但上了 Production 會崩潰」的完美系統。
不要建立路邊工地常見的隔音帆布，要建立真正的工程護欄：
- 修改 PR 規範：要求在 PR 裡註記「AI 生成」以及「人為驗證過的 Edge Case 清單」。
- 加強自動化閘門：把 CI/CD 的測試覆蓋率、資安掃描等驗證設為確認指標，十倍的程式碼產出，應該至少要加強五倍以上的DevSecOps驗證吧
3. 追查驗證鏈而非發洩情緒
當線上真的出 bug 時，如果脫口而出「你是不是都沒確認 AI 寫的」，除了引發防衛心理之外，基本上毫無建設性。
應該追問的是流程面向：
- 為什麼這個測試案例沒有被寫進單元測試？
- 我們的內部規格文件是不是缺少了這段說明情境？
- 未來如何讓 CI 流程自動攔截這種錯誤？
把焦點放在「驗證機制的缺陷」，團隊才會願意誠實回報 AI 產出的盲點，而不是為了怕被罵而掩蓋使用工具的事實。
4. 向上管理
面對更高層的處長、VP 或非技術老闆時，非技術高層最容易產生「有了 AI，今年人事預算可以砍半、產出翻倍」的幻覺。
在季度報告或專案總結時，幫忙顯現決策價值：
「我們團隊這次透過 AI 工具，在 3 天內跑完了過去需要 2 週的 5 種架構驗證，最後也符合相關的資安合規的驗證，成功的在時程內deliver了 MVP 到客戶端。」
把故事講成「M型化人才利用工具成倍放大決策品質」，而不是「工具正在取代我們」。
為系統負責的永遠是人類
雖然口頭上常開玩笑說，人類最後可以幫忙ＡＩ去坐牢 XD
拿著ＡＩ這把瑞士刀來修指甲的人，隨時可以被另一個拿著指甲刀的人取代，但能用它在荒島上削木造筏的人，他的價值從來就不在那幾片鋼質刀刃上，而是在他的經驗與思考的能力。
身為工程師，你的生存之道是把隱性思考外顯化，證明自己握著刀在荒島求生
身為主管，你的職責是建立制度與護欄，引導團隊把瑞士刀用在對的地方，並在狂風暴雨來時為各自分工組裝木筏。
Top comments (0)