軟體工程師的資訊焦慮（上）：FOMO、冒牌者與 AI 生產力

軟體工程師大概都經歷過這種循環：社群上冒出新框架或新模型、同事在討論陌生的開源專案，焦慮感瞬間湧上來。於是你一口氣開了十幾個瀏覽器分頁、在 GitHub 上替好幾個專案加星號，再把文章塞進稍後閱讀清單。最後，帶著一股「自己又落後了」的疲憊感關掉螢幕。

明明花了大把時間關注技術，為什麼心裡沒有更踏實，反而覺得要補的坑越來越多？

本系列上篇從這個現象出發，拆解工程師資訊焦慮的本質，以及 AI 與收藏習慣如何加深了這層焦慮。

一、焦慮源自「落差」：我以為自己應該懂更多

「資訊焦慮」不是網路時代才有的產物。早在 1989 年，美國資訊架構學者 Richard Saul Wurman 就在《Information Anxiety》中寫下這個定義：

資訊焦慮源自於「我們所理解的」與「我們認為自己應該理解的」之間持續擴大的落差；它是資料與知識之間的黑洞。

這個定義最精準的地方，在於「認為自己應該理解」。 技術領域的資訊本來就無窮無盡，真正的問題在於：我們常不自覺把「市面上出現的新技術」，全部畫進「我身為工程師應該要會」的範圍裡。一旦範圍畫得太大，就算每天都在進步，焦慮感也只會跟著放大。

這和單純的「資訊過載」不同。過載是輸入量塞爆了大腦頻寬——太多 Slack 通知、太密集的 PR 審查、看不完的規格文件。過載通常能靠減少輸入來緩解；焦慮則屬於心理壓力，即使你關掉所有分頁，心底那句「別人都懂，只有我還在原地打轉」的聲音依然不會消失。

科技評論家 Clay Shirky 在 2008 年 Web 2.0 Expo 的演講中一針見血指出：

這不是資訊過載，而是過濾失靈。（It’s Not Information Overload. It’s Filter Failure.）

這句話常被誤讀成「過載根本不存在」。Shirky 想強調的是：在資訊氾濫的環境下，重點在於建立清晰的過濾機制，而非全盤接收所有訊號。

對工程師來說，同樣是版更通知，正式環境正在跑的套件爆出安全性弱點，跟你從沒用過的語言推出新框架，處理的優先順序完全不同。如果只想靠「少讀一點」來減壓，可能連重要的安全性修補一起漏掉；反過來，如果只看社群熱度來排學習清單，等於把注意力全交給別人的演算法。

有效的過濾需要回歸自身：這則技術變更，跟我眼前正在維護的系統、準備解決的業務問題，到底有什麼關係？

如果回答不出來，它就只是背景雜訊，不需要變成你的待辦清單。

二、工程師的工作環境，如何放大這個落差？

為什麼工程師常覺得自己的焦慮感特別強烈？日常工作的生態環境是主要推手。

工程師每天接收的資訊，往往帶著急迫的行動提示：重大版本升級、安全性弱點修補、某個 API 棄用倒數。久而久之，大腦養成了「看到新訊息就得採取行動」的反射機制。當這套反射機制遇上社群媒體推播的各種熱門開源專案與新工具時，「工作上必須知道」和「社群正在熱議」的界線就模糊了。

別人的精選亮點，成了你的自我評判標準

軟體工程很難用單一標準衡量能力。有人擅長 Linux 核心與效能調校，有人專精分散式架構，也有人擅長前端使用者體驗。但在社群上，這些人的成果會同一時間堆到你眼前，看起來就像「厲害的工程師每一項都得精通」。

比較的基準也極不對稱：你眼見的是他人端出的成果——漂亮的開源架構、流暢的技術分享，或是順利上線的案例。拿來對照的，卻是自己每天試錯、卡關與踩雷的幕後日常。你記得自己花了一整天只為了解一個設定檔問題，卻看不到別人在寫出那篇架構文背後，到底推翻過幾次設計。

這種比較很容易誘發「冒牌者感」：即便做出了實質貢獻，依然把成果歸因於「運氣好」或「剛好查到解法」，深怕哪天被別人看穿底細；遇到不熟的技術，又急著將其解釋為自己能力不足。

坊間常傳言「高達 70% 的人有冒牌者症候群」，這項說法實際上沒有可靠的實證根據。Bravata 等人 2020 年的系統性回顧指出，各研究估算的盛行率從 9% 到 82% 都有，完全取決於採用哪套量表與評判門檻。

冒牌者感和資訊焦慮有一個共通的盲點：主觀的不足感，往往無法靠客觀累積的成果來抵消。 如果習慣把做到的事當成僥倖，把未知的領域當成缺陷，那學再多也只會越學越心虛。

害怕錯過，演變成頻繁刷新

FOMO（錯失恐懼）描述的是「擔心別人正在經歷自己錯過的精彩事物」。Przybylski 等人的研究指出，FOMO 與高頻率的社群媒體檢查行為顯著相關。

在技術學習上，這個機制會形成消耗能量的迴圈：每隔一陣子刷新社群或技術討論區，快速掃過標題，能讓大腦誤以為自己掌握了最新情報。然而，高頻率的檢查換來的只是「知道有這件事」，而不是「理解這項技術」。每一次刷新，只會提醒自己「世界上還有這麼多東西我不會」，反而讓落後感更加強烈。

若再加上技術圈常聽到的「學習跑步機」敘事——彷彿必須全力奔跑才能留在原地——學習就從「為了解決問題而探索」，退化成「免於被淘汰的生存焦慮」。但這本質上是一種文化氛圍，不是每項新技術都非學不可的客觀事實。

三、AI 確實改變了工作，但不代表每個新模型都得追

生成式 AI 的普及，讓追趕技術的壓力變得更加緊繃。大家除了擔心少學一項技術，更深層的焦慮是：「如果別人用 AI 快了十倍，我是不是要失業了？」

但如果把「不學 AI 就會被淘汰」這句口號放到實證資料前檢驗，情況比社群上的狂熱冷靜得多。

速度的代價：感覺變快，不等於真的變快

AI 能帶來多少生產力，很大程度取決於任務類型與使用情境，各項實證的結果甚至互相矛盾：

• 全新任務下的單純實作：Peng 等人（2023）的實驗顯示，開發者在撰寫 HTTP 伺服器這類從零開始的任務時，使用 Copilot 的組別速度提升了約 56%。
• 真實專案與資深維護者：METR（2025）的 RCT 實驗找來資深開源專案維護者處理真實 issue，實測結果使用 AI 反而慢了 19%。（雖然樣本數不大、工具也在迭代，METR 2026 年更新也提醒不宜過度推論，但這說明了 AI 在複雜現有架構中的侷限。）

最耐人尋味的是 METR 揭露的感知落差：參與實驗的工程師在做事前預期 AI 能讓自己快 24%，做完後即便實際變慢，主觀上仍覺得自己快了 20%。快速生成程式碼帶來的流暢感，跟真正把問題解完的時間，完全是兩回事。

寫得更快，不等於交付得更好

軟體開發從來不是只比「程式碼打字速度」。一行程式碼生成出來之後，後續的程式碼審查、單元測試、跨系統整合、正式環境部署與維運，才是真正考驗工程品質的地方。

Google 的 DORA 報告精準捕捉了這種落差：2024 年 DORA 報告發現，AI 採用率上升雖然伴隨文件品質提高，卻同時與交付吞吐量及軟體穩定性的下降相關；2025 年報告中吞吐量雖轉為正相關，但對穩定性的負面影響依然存在。

生成的速度變快了，但如果驗證與除錯的成本同步飆升，局部的速度提升，很難轉化為整體的交付成果。

說到底，這些生產力研究測量的是任務效率與交付表現，不是失業率。 它們既不能證明「不學 AI 馬上就會被淘汰」，也無法保證「完全忽略 AI 毫無風險」。

面對每個禮拜冒出的新模型和新 Agent 工具，務實的作法是回歸自身工作情境去衡量：這個工具在日常開發中能省下多少時間？它的輸出需要花多少力氣去驗證與除錯？把對的工具用在合適的問題上，並在不需要時果斷放下，遠比在社群上炫耀自己測過多少款模型更有價值。

四、收藏暫時安撫了焦慮，卻不等於學會

面對如潮水般湧來的技術資訊，工程師最常見的反射動作就是「存起來」：瀏覽器開滿分頁、GitHub 專案按星號、把文章加入稍後閱讀清單、訂閱好幾份不同主題的技術電子報。

東西留著了，心裡頓時有了底氣：至少我沒漏掉，改天有空就能讀。

收藏本身不是壞事，危險的是把「收藏」當成「進度」。

在心理學文獻中，這種行為與「數位囤積」（Digital Hoarding）的特徵高度重合。研究指出，人們按下儲存鍵的核心動機往往是「以防萬一」（Just-in-case），而按下「收藏」的瞬間能即時緩解錯失恐懼，給大腦一種「我已經處理這件事」的假性完成感。

筆記圈常將這種現象稱為「收集者謬誤」（Collector’s Fallacy）：誤把「資料存進硬碟」當成「知識裝進腦袋」。

收藏清單變長，不會自動提升你的技術判斷力。當一項技術真的出現在專案需求中時，你依然得花時間理解原理、動手實作、走過卡關與除錯的過程，才能將它轉化為能力。

這正是開場提到的惡性循環：刷動態讓你發現更多盲點，按收藏給了你短暫的心理安慰；但只要沒有真正花時間消化與實踐，「我應該懂更多」的焦慮黑洞就永遠補不滿。

資訊焦慮是真實的心理反應，但不必把它自動翻譯成永無止境的學習清單。下一篇接著談：如果我們選擇「不追最新熱點」，真實的代價到底是什麼？以及在 AI 寫程式的時代，究竟有哪些底層知識值得我們親自學透？