# 策展 · X (Twitter) 🔥🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Addy Osmani (@addyosmani) · 平台：X (Twitter) · 日期：2026-05-18

> 原始來源：https://x.com/addyosmani/status/2056078124346228860

## 中文摘要

過度依賴AI寫程式將導致工程師能力退化。

目前開發者普遍陷入一種「預設迴圈」：將規格或錯誤訊息貼給 AI，直接採用其提供的修復方案。這種模式雖然能快速完成任務，卻跳過了問題與解決方案之間必要的「掙扎過程」。這種認知上的投降，會讓工程師在不知不覺中將判斷權交給 AI，長期下來，離開 AI 輔助後的獨立開發能力將會顯著減弱。

**研究顯示認知能力正隨依賴度下降**
多項研究已證實，缺乏主動學習意圖的 AI 使用方式會損害專業技能：
- Anthropic 於 2026 年初進行的隨機試驗顯示，AI 組與手動組在完成任務的速度上並無差異，但 AI 組在後續的理解測驗中表現較差。其中，透過 AI 詢問概念的工程師得分超過 65%，而單純複製貼上 AI 程式碼的工程師得分則低於 40%。
- 麻省理工學院（MIT）的「Your Brain on ChatGPT」研究透過腦電圖（EEG）測量發現，隨著外部支援層級增加，大腦連結性會下降。使用 LLM 的組別連結性最弱，且 83% 的使用者在完成寫作後，無法引用自己產出的任何內容，研究人員稱此為「認知債」。
- 2026 年的 CHI 研究指出，若在任務初期就使用 LLM，AI 會直接定義問題框架，即便後續由人類完成，這種初始錨定效應仍會導致決策品質顯著下降。

**工具設計優先考量交付而非教學**
目前的開發工具與產品團隊多以「合併變更」與「縮短週期」為核心指標，這導致工具介面消除了所有摩擦力。然而，學習往往就發生在這些摩擦之中。雖然 Anthropic 的「Learning Mode」、OpenAI 與 Google 的類似功能試圖透過蘇格拉底式提問引導使用者，但大多數開發者仍將其視為「學生專用」而忽略，這是一個嚴重的錯誤。無論是資深工程師學習新語言，還是初學者練習基礎，這些教學功能同樣適用。

**為何必須保持理解能力**
雖然對於瑣碎的樣板程式碼或一次性腳本可以委派給 AI，但在關鍵領域，純粹的委派將面臨巨大風險：
- **除錯需求**：AI 產出的程式碼同樣會崩潰，若團隊成員不理解架構，將無法處理系統性問題。
- **幻覺風險**：面對 AI 自信滿滿的錯誤回答，唯一的防禦手段就是具備足夠的專業知識來識別謬誤。
- **系統演進**：程式碼是暫時的，系統是永久的。當框架更新或出現安全審查問題時，無法僅靠重新提示（re-prompt）來解決，必須具備深層理解才能進行遷移。
- **邊緣案例**：AI 在處理 GitHub 上常見的解決方案時表現優異，但面對困難且無文件記載的專案時，仍需依賴資深工程師的深度專業。

**透過調整提示策略來強化學習**
要避免累積認知債，工程師必須改變與 AI 的互動姿勢：
- **先建立假設**：在要求 AI 修復前，先寫下兩三句對問題的理解，將 AI 的回答視為驗證理論的工具，而非取代思考的來源。
- **先解釋後程式碼**：在不熟悉的領域，先要求 AI 解釋原理、替代方案與權衡取捨，理解概念後再索取程式碼。
- **視 AI 為初級工程師**：將 AI 產出視為初級工程師提交的 PR，必須進行閱讀、批判與反駁，不要因為測試通過就盲目合併。
- **手動重現**：偶爾嘗試將 AI 寫的程式碼從零開始重寫一遍，這是檢視自己技能是否退化的最佳校準方式。
- **要求教學**：在 AI 寫出巧妙的函式後，詢問它使用了哪些概念，以及需要閱讀什麼資料才能理解該設計決策。

**建立雙重指標以維持專業成長**
工程師應將「交付任務」與「學習新知」視為兩個獨立的指標。如果連續數月只關注交付而忽略學習，認知債將會持續累積。在職涯長度上，選擇一個能同時兼顧交付與學習的工作流程至關重要，因為預設的工具選項並不會主動引導你學習。下一次面對瑣碎任務時，就是開始練習主動學習的最佳時機。

## 標籤

產業趨勢, 研究論文, 其他, Anthropic