我已經不只一次經歷這種對話了，而且次數多到我不太想承認。
我在討論串、會議或設計審查中提出一個技術問題，結果有人回了一段又長、又有條理、而且平衡得可疑的回答。即使不是格式上，精神上也像有標題；它涵蓋了三個取捨，最後還給了一個整齊的建議。
我對其中一點提出反駁。沉默了一分鐘，那種你幾乎聽得見瀏覽器分頁切換的沉默。接著又出現另一段同樣精緻的文字，回應我的反駁。
到了某個時候，這種感覺就很明顯了：我不是在跟同事說話。我是在跟一個聊天視窗講話，而那個視窗上還貼著一個人形的複製貼上按鈕。
拜託別再這樣做了，我幾乎是在哀求你。
我也會開瀏覽器
先說最明顯的事。如果我想跟 AI 辯論，我就會直接跟 AI 辯論。我可以把問題打進 ChatGPT、Claude，或是這週流行的其他工具裡。只要 10 秒，我就能省掉中間人。現在的你與其說是同事，不如說是帶著 LinkedIn 個人檔案的載入中轉圈圈。
當我把技術問題拿來問你時，我是在向你請教判斷力。哪些做法你見過有效，哪些你看過失敗，以及是什麼讓你知道兩者的差別。我想知道你會接受哪些取捨、會質疑哪些假設，以及原因是什麼。我想聽的就是這種經驗。
一旦你變成傳話筒，我就失去這一切了。我拿到的是掛著你名字的通用輸出，而且你只是讓對話變慢，沒有增加任何東西。恭喜，你發明了全世界最慢的 API 包裝器。
「可是我是做決策的人」
這個說法真的最讓我受不了。
論點大概是這樣：在 AI 時代，開發者的工作是當「架構師」。AI 產生選項，人類做決定。你像是護欄，像是有品味的那個人。
好吧，這個模型不差。我確實認為，這很可能就是這份工作越來越接近的樣子。
但如果一個做決策的人 99% 的時候都同意 AI 的建議，那他其實沒有在做決策。那只是掛著職稱的蓋章機器。如果你的「決策」和模型的預設輸出沒有區別，那你不是多加了一層判斷，你只是多加了一層延遲。
所以這裡有個很簡單的測試：你能不能說出最近一次你和 AI 意見不合的時候，以及原因？ 不是「我只是調整了一下格式」。而是真正的分歧，且是建立在模型不可能知道的事情上，例如限制條件、過往事故，或團隊偏好。
如果你說不出來，你就不是護欄。你只是乘客，而且連播放清單都不是你選的。
我有一個很好的真實例子：
有人在 LinkedIn 私訊我，說他有興趣了解我如何思考分散式系統的問題。老實說，這種訊息會讓我心情很好。有人想聊專業，而且想聽的是「我的」想法。
所以我就回應了。我跟他分享了我是如何推理失敗模式的，以及當系統開始不一致時，我通常從哪裡著手，我們來回聊了好一陣子。
後來我才發現，對方全程都在用 AI 跟我辯論。他根本不是來向我學習的，而是透過一個代理人在跟我吵架。
重點是：我每天都在跟 AI 辯論。是我自己選的，按照我自己的規則，想什麼時候辯就什麼時候辯。這件事很容易做到。真正罕見的是，另一個人真的願意坐在對話裡，邊想邊說，當著我的面承認自己可能錯了，並且用自己的腦袋來反駁我。
如果他只是把自己半成形的問題直接問我，我會整天都回答他。
「AI 說的就是我同意的」
當我接著問：「如果不是你的腦袋在參與，那討論這件事還有什麼意義？」時，我常得到這種回應：
「喔，那也就是我同意的內容啊。」
你居然能這麼熱烈地同意一個不是你自己形成的立場，還真有膽識。
不了解的同意，不等於真正的同意。如果我問你為什麼同意，而你老實的答案是「因為它這麼說，而且聽起來很對」，那你持有的就不是一個立場，而是一個借來的立場。
而借來的立場，遇到第一個真正的問題就會崩塌，就像在小地震裡的 Jenga 塔一樣。我之前寫過這件事：讀懂一段內容、點頭稱是，跟能夠產出或 دفاع它，根本不是同一種能力。討論正是最能揭露這個落差的場景，所以它才重要。
至於「我是在驗證輸出」這個辯解：驗證確實是工作。它代表你要把主張拿去對照現實、測試假設，並找出那些細微但錯誤的地方。如果你的驗證只是看著答案想「嗯，聽起來對」，那那不是護欄，那只是閱讀而已。從來沒抓到任何問題的護欄，只是個裝飾用泳池浮條。
「我沒時間，我很忙」
經典說法。「我就是沒時間深入看這個，所以我問了 AI。」
對對對，你很忙，但大家都忙。我也很忙。跟你說話的人也很忙。幫你做燕麥拿鐵的咖啡師也很忙。忙不是一種人格特質。你並沒有獨享「忙」這個特殊狀態，它也不能成為你不參與自己選擇加入的討論的藉口。
但注意這個藉口背後藏著的安靜邏輯：如果你沒時間參與，那你其實也沒時間待在這場對話裡。這裡有一個乾淨、體面的選項，而且就是直接說出來：
「我現在沒有足夠的餘裕把這件事想清楚。我不想隨便給你半吊子的回答。我們可以晚點再回來談嗎？」
這很值得尊重，很誠實，也尊重我的時間，而且不裝模作樣。真正不值得尊重的，是把未經檢驗的輸出直接丟進討論串，然後把它包裝成你的貢獻。
公平的反方觀點
在這變成純抱怨之前，讓我先替另一邊講得更完整一點；因為人們在討論中倚賴 AI，確實有一些正當理由：
- 語言。 如果英文不是你的母語，用 AI 潤飾措辭是完全合理的用途。重點是，想法得是你的。老實說，你的拼字或文法就算不夠完美，我也不在意。我是軟體工程師，不是英美文學教授。語言的目的就是傳達想法。如果我能理解你想說什麼——而且 99% 的時候我都能理解——那就可以了。
- 事前準備。 在討論前先用 AI 探索主題、找反方論點、或檢查自己的想法是否合理，這很好。那叫研究。
- 初階工程師學習。 剛入門的人可能會先依賴 AI，因為他們還沒有足夠經驗形成自己的觀點。這可以理解，而真正的解法是帶領與指導，不是羞辱。
我不是反對 AI 參與過程；我反對的是 AI 取代了過程中的人。
我認為界線是這樣：你有沒有把模型的輸出變成你自己的？ 你有沒有對它提出質疑、反駁某些部分，並根據你真實情境重寫它？還是你只是轉述它？
你可以這樣做
我認為 AI 應該這樣參與技術討論：
- 在對話前用，不是在對話中用。 請它幫你壓力測試想法。請它提出最強的反對意見。然後自己想一想答案。
- 先形成一個你能獨立 دفاع的立場。 如果別人質疑你，而你得回去找聊天視窗才能回答，那你其實還沒準備好回答。
- 清楚說明哪些是你的、哪些不是。 「我有問 AI 幾個選項，我傾向選 B，因為 X」這樣很好。而「因為 X」這一段，才是真正證明有人的腦袋參與了。
- 偶爾刻意不同意它。 如果你從來不覆寫模型，請問自己：你是在評估它，還是在只是照單全收？
- 當你不知道時，就直接說不知道。 「我不知道，我去查一下」從來不會讓任何人顯得無能。假裝知道，最後才真的會出事。
為什麼這不只是禮貌問題
很容易把這一切歸類成「很煩的社交禮儀」，但我認為它的意義更大。
技術討論是團隊建立共同心智模型的方式。它能把假設攤開，讓一個人的經驗補上另一個人的盲點，也能把決策背後真正的推理建立並記錄下來。如果對話的一方是空洞的，那團隊最後帶走的就是一個「其實沒有人真的推理過」的決定。
這跟我一直在寫的認知債務問題是同一件事，只是從程式碼搬到了對話裡。而且像所有債務一樣，它通常會在糟糕的時機到期，往往就是當決策證明是錯的時候，然後有人問：「我們為什麼會選這個？」而誠實的答案是：「AI 說的，我們就差不多點頭了。」
結論
用 AI 吧。如果它能讓你更好，就一直用。但當你坐下來和另一個人談一個困難問題時，請真正現身。
帶上你自己的觀點，即使不完美也沒關係；帶上你自己的疑惑；帶上那個模型不知道、但你知道的東西。這才是我來這場對話真正想要的。
因為如果我想要的是整個網路平均意見，我早就直接問網路了。人類的互動現在已經夠稀有了，所以拜託，不要成為讓它變得更稀有的原因。
原文出處：https://dev.to/adamthedeveloper/dont-be-a-proxy-between-me-and-your-ai-mcn
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
