某次架構討論，資深工程師C提出一個做法，說後台的演算法這樣設計比較有效率，講得頭頭是道。我聽著覺得有道理，正想點頭，另一位負責後端的工程師卻皺著眉說：「這樣寫對我來說很麻煩，而且我覺得不一定是對的。」兩邊各有各的理由，我心裡有點慌，雖然我是技術出身，但系統架構怎麼設計、後台演算法怎麼寫這種更深一層的技術決策，其實很難靠自己獨立判斷誰對誰錯。

資深或專業不代表百分之百是對的

C很資深，講出來的東西聽起來很有邏輯，也很有自信，如果只聽他一個人講，我大概會照單全收。但另一位工程師提出不同意見之後，我才意識到，一個人講得再頭頭是道，也不代表那就是對的答案，尤其當這件事已經超出我自己能獨立判斷的範圍。

遇到這種狀況，我後來習慣的做法是，請兩邊各自把pros and cons列出來，好好討論，先搞清楚他們做這個決定背後真正的原因，而不是只看誰講得比較有自信、比較大聲，再做判斷。

更難處理的，是他根本沒打算讓我知道

另一種情況更棘手。有位比較資淺的工程師D，spec明明只寫了一個功能，他覺得多做一點對使用者更有幫助，就自己延伸做了額外的東西。有時候真的有幫助，但很多時候不一定，甚至可能讓原本的使用者體驗變得更差。比起做錯這件事本身，更讓我在意的是，他往往是做完了才想著要怎麼跟我說，有時候連他自己都沒完全意識到，延伸出去的東西已經改變了什麼，甚至也會耽誤開發期程，一片好意，時常變成慘不忍睹的悲劇。

遇到這種主動延伸的狀況，我都會盡量表現得鼓勵，讓他知道敢講出來是件好事，而不是每次多做一點就要提心吊膽，怕被罵，再逐步思考是否對使用者有幫助，也願意來場實驗；同時，我也會考量「當壞事發生」時的處理情境，因為，好事壞事只是原則落實的一體兩面，關於壞事，我會維持一個一直以來的習慣：不管錯誤是誰造成的，只要裡面有我的責任（通常絕對會有我的責任，因為我和工程師是一個團隊），我一定會自己先承認，而且用一個很結構化的方式講出來，不會把錯都推給別人。我自己講錯誤的順序通常是，先看這個錯誤現在造成的影響是什麼，影響的範圍有多大，現在能不能先止血，最後才去找出真正的root cause，再去解決root cause本身。

AI也一樣，它「覺得」自己做對的事，未必是對的

AI在生成內容的時候，某種意義上也「覺得」自己是在做對的事，給出一篇結構完整、邏輯通順、看起來很有道理的答案，但整段推論可能是錯的。截至2026年9月，研究者已追蹤到至少1,395 起美國州與聯邦法院案件，出現 AI 生成的假案例、錯誤引註或其他虛構內容。IBM 2026 年一份調查發現，71% 的 CHRO 認為「監督、驗證，以及必要時推翻 AI 輸出」是 AI 時代最關鍵的工作能力之一；相較之下，只有 29% 的員工把 judgment 視為重要能力。

前面提到的pros and cons和有架構梳理錯誤的方法，面對AI一樣管用。AI給出一篇看起來很完整的答案時，具體可以做的是：把答案丟給另一個AI，請它專門找反證、標出哪些是有證據的、哪些是推論；回頭查證AI引用的原始資料，看它講的到底是「相關」還是「因果」；把自己判斷不了的部分列成pros and cons，而不是照單全收。

今天驗證的習慣有了，但如果一開始要解決的問題根本就搞錯了呢？

參考資料：
AI error-ridden court filings surge despite three years of court sanctions
New IBM CHRO Study: AI Puts Critical Thinking at the Center of Workforce Priorities