Back to all posts

我們還能與 AI 保持距離嗎?

我們還能與 AI 保持距離嗎?

2026 年初,一群試圖衡量 AI 對開發者生產力影響的研究人員遇到了一個非常人性化的問題:部分開發者已不願接受可能需要在沒有 AI 輔助的情況下完成的任務。

研究人員將此稱為「選擇效應」。我卻一直把它看作一種小小的坦白。

不久前,AI 還只是側邊欄裡的一個實驗。我們在自動補全失靈、或正規表達式寫得令人難堪時才會打開它。如今,對許多開發者而言,它已然成為工作環境的一部分。早上打開編輯器時它在,接手一個多年無人碰觸的程式庫時它在,深夜測試亮起紅燈時它也在。

我們可以關掉那個面板,可以停用那個代理程式,我們依然知道怎麼寫程式。

那為什麼少了它,工作起來已經像是少了一隻手?

AI 接管了那些停頓

AI 進入軟體開發,並非宣告要取代我們,而是一次次帶來微小的解脫。

它補完了我們正要寫的那行程式碼,起草了我們一直拖延的測試,解釋了陌生的函式,把堆疊追蹤翻譯成白話英文,找出了埋在我們不想再讀一遍的文件裡的設定旗標。

這一切都不像是依賴,更像是動力。

但想想上次助理離線時的感受。令人不安的,或許不是你忘了程式語言,而是第一步之前的那片沉默。你必須自己決定從哪裡下手,必須獨自承受那份不確定,必須盯著錯誤訊息足夠久,直到一個假設浮現。

那些停頓曾經是再平常不過的事,如今卻感覺像是阻力。

或許這才是 AI 改變最深的地方。它不只改變了我們產出答案的方式,也改變了我們願意獨自面對一個問題的時間長度。

那份解脫是真實的

談論 AI 依賴,很容易讓人以為開發者是在用紀律換取懶惰。但這種說法忽略了從工作內部感受這個工具的真實體驗。

軟體開發包含著出乎意料多的私下羞愧。有資深工程師忘記了基本指令的語法;有新進員工害怕再多問一個問題,就會坐實所有人的疑慮;有用第二語言工作的開發者,明明知道哪裡出了問題,卻無法快速組織出解釋;有人加入一個有十年歷史的程式庫,所有重要決策都活在別人的記憶裡。

AI 對他們所有人都很有耐心。

它不會在問題重複時嘆氣,不會說「這你早該知道了」。它在凌晨兩點依然可用,能把空白的畫面變成一個可以與之爭論的起點。即使答案並不完美,有個答案本身就改變了開始的情緒重量。

這很重要。有時候看起來像生產力的東西,其實是解脫:少一點卡關的恐懼,少一點尷尬,少一點在一台拒絕自我解釋的機器前的孤獨感。

對許多開發者而言,AI 也把精力還給了他們真正在乎的工作部分。它可以承擔樣板程式碼、重複性測試、遷移腳手架,以及 API 客戶端的第一百種變體。當心智抵達有趣的問題時,已不那麼疲憊。

我們不應該把這視為走捷徑。一個讓人更有勇氣探索的工具,正在做一件真正有價值的事。

困難在於,舒適與依賴生長自同一個根。

我們使用著自己並不完全信任的東西

開發者調查一再發現同樣奇特的關係:我們持續使用 AI,同時對它給出的內容保持懷疑。

這種張力,對任何曾看著一個自信的答案在某個邊界案例下崩潰的人來說,都不陌生。程式碼看起來正確,命名乾淨,解釋沉穩。直到第三個測試失敗,我們才發現模型憑空捏造了一個方法、誤解了業務規則,或者解決的是一個比我們實際面對的更簡單的問題。

然而,下次卡住時,我們還是會再問。

這不是偽善,信任不是單一的東西。

我們或許不信任 AI 做最終決定,但信任它給我們一個初始方向。我們或許不信任那個修補程式,但信任這段對話能鬆開我們思維中的結。我們或許不相信那個答案,但相信螢幕上會出現些什麼,而不是一片空白。

AI 已成為那個我們絕不會允許直接合併到主分支的同事,卻又在它離開房間的那一刻感到若有所失。

我們移動得更快,因為下一步很快就會出現。但我們仍然有責任確認它是否能承受我們的重量。

當掙扎消失,什麼也跟著消失

有一種知識,只有在卡住的時候才會到來。

在 AI 出現之前,一個陌生的錯誤可能會帶著我們穿越堆疊追蹤、進入呼叫端、翻遍文件,最終觸及一個我們不知道自己曾做過的假設。這條路徑效率低落,卻也是程式庫從一堆檔案變成一個真實場所的方式。

我們記得那些曾經抵抗過我們的系統。

花了一個下午才找到的 bug,教會我們狀態真正存在於哪裡。那次生產事故,教會我們某個無聊的防護措施為何存在。那個被誤解了三次的函式庫,後來成了我們能夠向別人解釋的函式庫。

當 AI 移除了阻力,它或許也移除了讓教訓得以留存的故事。

一項早期研究針對學習陌生函式庫的開發者,發現了一個直覺上感覺正確的結果:把任務全部委託給 AI 的人,學到的比那些用 AI 提問概念性問題、並測試自身理解的人要少。重要的區別不在於「用 AI 還是不用 AI」,而在於這個工具是取代了思考,還是參與了思考。

這對初階開發者而言尤其困難。有經驗的工程師能辨識出可疑的抽象,因為他們曾經建構過錯誤的抽象。他們能感覺到一個整齊的修補程式不屬於這個系統,因為他們記得系統的傷疤。但如果每一個粗糙的邊緣在下一代碰觸之前就被磨平,他們的直覺將從何而來?

師徒制從來不只是答案的傳遞,而是品味的緩慢傳承:什麼值得擔心、何時該停下、哪個妥協將來會付出代價,以及為什麼一個可以運作的解法仍然還沒準備好。

AI 可以解釋所有這些概念,但它還無法重現另一個人選擇在你學習時留在你身旁的那種感覺。

捷徑或許是真實的,但理解仍然必須跨越那段距離。

程式碼曾經留有指紋

還有另一種變化更難衡量,因為它存在於人與人之間。

人類寫的程式碼往往帶有作者的痕跡。一個奇怪的輔助函式,可能附帶著當初需要它的那次事故的記憶。一段彆扭的註解,可能精確地揭示了某人當時的不確定。在程式碼審查時,我們不只是檢查變更,也在重建它背後的思路。我們提問,另一個人從他們走過的路徑回答。

AI 生成的程式碼可能在沒有那條路徑的情況下抵達。

它可能打磨精良、技術上合理,卻感覺奇怪地無主。作者能描述他們要求了什麼,但不總是能說清楚為什麼結果採取了這種形式。審查者於是必須承擔原本部分屬於作者的工作:重建意圖、核查假設,以及發現一個沒有人記得做過的決定的隱藏邊界。

這正是許多社群討論中對 AI 生成的 pull request 感到不安的根源。抱怨不只是程式碼寫得不好,爛程式碼大家都見過。更深層的不適在於社會契約已經改變。

一個人現在可以在幾分鐘內製造出一個大型變更,另一個人卻仍然必須花費人類的注意力去理解它。在鍵盤上節省的時間,可能悄悄地重新出現在程式碼審查、維護、安全工作,或是系統故障的那個夜晚——當有人必須解釋那個生成的修補程式究竟想做什麼。

程式碼一直都是溝通。當生成幾乎變得免費,注意力就成了稀缺的部分——而注意力屬於人。

或許,技藝正在移動

對某些開發者而言,這一切都不像是失去,而像是終於被允許在他們一直想要的層次上工作。

他們寫更少的程式碼,花更多時間塑造問題。他們在確定方向之前比較幾種設計,思考使用者、架構、失敗模式,以及代理程式不得跨越的邊界。技藝從生產每一個零件,移向指揮整體。

這可以是真正的演進。當組譯器取代機器碼,當框架取代手工搭建的基礎設施,我們並沒有因此停止成為開發者。軟體一直在透過抽象向上移動。

但每一層抽象,都依賴著有人理解其下的東西。

指揮 AI 的開發者仍然需要品味。審查者仍然需要心智模型。架構師仍然需要知道,當整潔的圖表遇上緩慢的網路、損毀的訊息、精疲力竭的團隊,或是驚慌失措的使用者時,會發生什麼事。

如果 AI 寫了更多實作,人類的判斷不會變得不那麼重要,而是變得更容易被忽視、更難以培養。

這個未來樂觀的版本,不是開發者變得不那麼重要的版本,而是我們對只有人才能承擔的事情變得更加審慎的版本:脈絡、關懷、懷疑、責任,以及辨識出一個技術上正確的答案對這個特定系統和這些特定的人而言仍然是錯的能力。

留下來,但不消失

我們還能與 AI 保持距離嗎?

就個人而言,可以。我們明天就能關掉那個面板。就職業而言,這個問題已經更加複雜。期望正在改變,程式庫正在被生成的程式碼填滿,新進開發者在職涯的起點就遇見了 AI,而不是在中途。即使是從不使用助理的人,也將越來越多地審查和維護來自助理的程式碼。

沒有一條私人的路,能回到 AI 出現之前的產業。

但或許,離開並不是衡量自由的正確標準。更有意義的問題是:當工具留下時,我們能否保持在場?

保持在場,意味著即使所有測試都是綠燈,也要讀那個修補程式。意味著在答案有效之後,還要問為什麼。意味著拒絕合併自己無法解釋的東西。意味著給初階開發者時間去掙扎,而不把那段時間視為浪費;也意味著給審查者應有的肯定,讓他們看不見的工作——保護系統免於看似合理的錯誤——得到承認。

這也意味著保留那些沒有助理立即回應的時刻——不是作為一種純粹主義的儀式,而是作為一種再次聆聽自己思考的方式。

我們大多數人會繼續使用 AI。那份解脫是真實的,那些可能性是真實的,那份不安、那種依賴,以及對工作中某些我們曾深愛之物正在悄然流逝的隱隱恐懼,也同樣是真實的。

我們不必在否認與投降之間二選一。

軟體的未來,不會由 AI 寫了多少比例的程式碼來決定,而會在更微小的時刻中被決定:我們是否在接受之前先理解,我們是否選擇教導而非只是轉發一個答案,我們是否保護另一個人的注意力,以及當生成的程式碼抵達真實世界時,我們是否仍然承擔責任。

AI 可以留下來。

我們必須確保,我們也是。

Stay in the loop

// Get the latest insights on AI teammates and collaboration.