title: “AI 應該提升你的思維，而不是取代它：工程師的分水嶺時刻來了”
date: “2026-04-28”
category: “每日AI”
tags: [“AI”, “工程思維”, “開發者”, “生產力”]

「我把我的問題貼進對話框，AI 給出一個漂亮答案，然後我把它當成我的想法交給主管——這算不算生產力？」

這個問題在 HackerNews 上一篇文章底下，引發了超過 500 條討論。作者 John Koshy 不是來歌頌 AI 的，而是來拆一個很多工程師不願面對的真相：AI 正在悄悄把人們分成兩個陣營。

第一個陣營用 AI 來擺脫繁瑣工作，把時間花在真正重要的事——定義問題、權衡取捨、發現風險、創造洞察。

第二個陣營用 AI 來避免思考。他們把提示貼進框裡，收集漂亮的輸出，然後假裝那是自己的思考成果。短期內看起來像生產力，甚至像天賦——但作者說，那是一條死路。

這不是一篇你該快速滑過的 AI 教學。這是一面鏡子。

外包思考——新的失敗模式

AI 已經能生成程式碼、總結會議、解釋概念、產出設計草稿、撰寫狀態更新——全都在幾秒內完成。很有用，同時也很危險。

危險的不是「AI 會讓人變懶」這種道德說教。真正的危險是：它讓人很容易模擬能力，而不培養能力。

現在有一個非常真實的誘惑：把問題丟給模型，收到一個合理的答案，然後複述它，假裝是你自己的理解。

這在某種程度上比抄襲還糟糕。至少學生抄另一個人的答案時，背後還有一個真實的人類來源。但在這裡，人們可以呈現他們自己根本不懂、無法捍衛、也無法獨立重現的機器推理。

作者用了一個精準的詞：這是披著槓桿外衣的智識依賴。

而這種依賴有代價。每一次你用 AI 產出代替自己的理解，你就跳過了建立判斷力的練習。你在用長期的能力換取短期的表面光鮮。

為什麼這個問題對早期工程師尤其致命

這是整篇文章裡最值得深思的一段。

初入行的幾年之所以重要，是因為那是基礎能力形成的時期——除錯直覺、系統直覺、精準度、品味、懷疑精神、拆解問題的能力、解釋事物運作機制的能力。

這些能力來自 摩擦。來自掙扎。來自犯錯然後修正。來自追蹤失敗到根因。來自寫出一個東西，然後發現它在現實面前不堪一擊。

這個過程不是可選的。它是工程師獲取和提升能力的必經之路。

有工程師在 HackerNews 底下分享了自己的親身經歷：「我開始用 AI 寫 code review 回覆，因為太方便了。三個月後我發現，我已經說不出『為什麼這段程式碼有問題』——我只能複製貼上 AI 的分析，但我自己看不懂。」

這種現象在心理學上有個名稱叫「認知卸載」（cognitive offloading）：當你太習慣把思考交給外部工具，你的大腦會逐步削弱那些不再使用的神經連結。書寫能力會退化，地圖閱讀能力會退化，記憶力會退化。現在，輪到推理能力了。

而這個問題在軟體工程領域特別嚴重，因為工程判斷力不是可以「補習」的東西。它不是一個技能點，而是一個體系——由無數次的錯誤、除錯、系統設計取捨堆疊而成的神經網絡。一旦錯過了建立它的黃金期，就很難回頭。

如果你用 AI 把學習過程中的所有掙扎都去掉，你其實正在傷害自己的發展。一個用 AI 回答每個難題的人，可能在一兩個季度內看起來很高效——但他也在悄悄摧毀未來賴以生存的能力。

「這就像在大學裡抄答案，然後去應徵一個需要獨立思考的工作。」作者說。「就像用計算機做每一道算術題，卻從不培養數感。就像還沒學會開車就依賴自動駕駛。輔助系統可能讓你看起來能勝任，但它不會讓你真正有能力。」

而最終，真正的能力是唯一重要的東西。沒有捷徑。

頂尖工程師的做法完全不同

這不是一篇反對用 AI 的文章。恰恰相反。

作者認為，最好的工程師會 更多 使用 AI，而不是更少。但他們使用 AI 的姿態完全不同。

他們讓 AI 起草樣板、總結文件、生成測試框架、建議重構、發現可能的故障模式——把機械性的部分外包出去。

但同時，他們會在日常工作中做幾件 AI 做不到的事：

問出更尖銳的問題。 如果你的問題只能問到「幫我生成一個 REST API」，那你的天花板就是那個 API。好的工程師問的是：「這個系統為什麼需要 REST API？有沒有更好的通訊方式？」

定義真正的問題。 很多時候團隊花一週解決的問題，其實根本不是問題。真正有價值的工程師能看出「我們在解決一個不存在的假議題」，然後把方向轉回來。

產出新的、高價值的知識。 AI 擅長翻炒已有的資訊（這也是為什麼很多 AI 產出讀起來都很像——因為訓練資料就那些）。但真正有價值的工程師產出的是對組織、對領域而言新的理解。他們寫的設計文件不只是記錄決策，而是提煉出可以在下個專案複用的模式。

然後，他們把省下來的時間投入真正重要的地方。 這是最關鍵的差別——平庸的工程師把省下的時間用來休息；好的工程師用來問更好的問題。

價值真正的來源

多年來，人們把軟體工程和產出程式碼混為一談。這個混淆正在被 AI 徹底暴露。

如果這個工作的核心價值是產出語法正確的程式碼，那 AI 當然走在取代大部分工程師的路上。但這從來就不是這份工作的最高價值。

價值一直存在於判斷力中。

有價值的工程師是那個在故障發生前就看到隱藏限制的人。是那個注意到團隊在解決錯誤問題的人。是那個把模糊的辯論化為清晰的權衡取捨的人。是那個找出缺失的抽象層的人。是那個能除錯現實、而不只是讀程式碼的人。是那個能在所有人都看到雜訊時創造清晰的人。

AI 可以支持這些工作。但它無法擁有它們。

作者在文中用了一個巧妙的比喻：「當學徒還是學徒時，師傅的工具不會自動讓學徒變成師傅。工具只是工具——真正的傳承來自於做的過程。」

同樣的道理在今天依然成立。你可以給每個人最好的 AI 工具，但這不會讓所有人都變成頂尖工程師。真正拉開差距的，是你怎麼使用這些工具——是你自己的判斷力、直覺和經驗。

事實上，未來產出最高價值的工程師，往往是那些反過來產出讓 AI 變得更有用的知識的人。他們創造設計原則、領域理解、模式、上下文和決策框架——這些東西提升了 AI 的效益。

在那個世界裡，工程師不是被 AI 取代。工程師因為在更高層次運作而變得更有影響力。

沒有捷徑可以獲得判斷力

這可能是最難讓人接受的部分——但也是最重要的。

沒有任何 AI 生成的解釋可以把熟練轉移到你的大腦中，而你不用付出努力。沒有任何方法可以長期外包推理，然後仍然擁有強大的推理能力。

這就像健身。你可以找最好的教練、用最先進的器材、看無數的影片教學——但如果你自己不流汗、不使力、不感受肌肉的撕裂與修復，你不可能變強。

AI 是你的教練和器材。但它不能代替你流汗。

你可以外包機械性工作、加速研究、壓縮例行任務。你可以消除大量的低價值勞動。這些都很好，也應該去做。

但你不能跳過技能的養成，然後指望自己憑空擁有它。

這是那些最天真使用 AI 的方式背後的核心錯誤。人們以為在節省時間，實則在虧空自己的未來。

組織層面的影響

當一個團隊或公司鼓勵「能用 AI 就用 AI」，管理階層看到的是效率提升。但他們沒看到的是：

如果資深工程師用 AI 加速工作，他們只是把省下的時間投入到更高層次的問題——這是好事。

如果初階工程師用 AI 跳過學習，他們是在用短期的產出交換長期的能力退化。

這會造成一個隱形的技能斷層。公司看起來在高效運轉，但培養下一個世代資深工程師的管道正在萎縮。三年後，當需要有人做出那些只有經驗才能帶來的判斷時——會發現根本沒有人具備那種能力。

作者用了一個殘酷的詞來形容這種情況：「組織健忘症」（Organizational Amnesia）。當團隊的集體知識不是儲存在人的腦袋裡，而是分散在 AI 對話記錄、生成的程式碼片段、和沒人真正理解的設計文件中時——只要有人離開，知識就消失了。如果一個關鍵模組是 AI 生成的，而負責維護的人已經不在了——誰來救火？

這不是杞人憂天。已經有資深技術主管在 HackerNews 上分享：「我們最近有個工程師離職。他走了以後我們才發現，他過去半年提交的程式碼有一半是他自己都解釋不清楚的——AI 寫的，他 review 過，但他不記得為什麼那麼寫。現在 bug 來了，我們得重寫整個模組。」

這跟組織學習（organizational learning）的問題很像。當知識被嵌入到 AI 系統而不是人的頭腦中時，組織會失去那些「在關鍵時刻做出對的決定」的直覺。

HackerNews 那 500 多則討論裡，有一則留言說得很好：「AI 的出現不是問題。問題是我們用 AI 來逃避什麼——那些我們本來應該自己去學、去摔、去理解的東西。」

這不是在唱反調，也不是在呼籲回歸原始時代。AI 是工具，好工具。但工具的好壞，取決於使用工具的人。

問題不在於 AI，而在於我們如何看待它。如果你把它當成思考的拐杖，你會越走越慢。如果你把它當成支點，你會發現自己能撬動比想像中更多的東西。

但我們很少問自己一個問題：當我們習慣了讓 AI 替我們想答案之後，我們還能不能、還願不願意、還有沒有能力，自己問出對的問題？

這個問題，比任何技術突破都更重要。