越來越多的程序員可能都變成了這樣：IDE 還開著，手卻越來越少敲鍵盤；PR 還在提，真正從零開始推敲設計的時刻卻越來越少。效率曲線一路向上，發(fā)布節(jié)奏越來越快，團隊里關于 AI 的討論也從“要不要用”變成了“為什么你用得不夠多”。一切看起來都在進步。

但有時候，在深夜合上電腦之后，會冒出一個不那么 KPI 的問題：我們到底是在變強，還是在變依賴？

下面這篇文章沒有站在反 AI 的立場，也不是技術布道。它更像是一種自我審視——當 AI 深入到編碼、評審、架構甚至決策層面，我們究竟獲得了什么，又可能在不知不覺中失去了什么。

原文鏈接：https://tomwojcik.com/posts/2026-02-15/finding-the-right-amount-of-ai/

作者 | Tom Wojcik 責編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

我認識的每一個開發(fā)者，現在都在用 AI 寫代碼。效率提升確實很明顯，但代價往往不會出現在任何儀表盤上。

不妨想象一條光譜。最左邊，是人類自己敲鍵盤，在 IDE 里逐行閱讀和編寫代碼。最右邊，是 AGI，它能夠獨立完成一切，成本極低、幾乎零失誤、能力超過任何人類，而且不需要人類監(jiān)督。

在這兩個極端之間的某個位置，就是今天正在使用 AI 的你。這個分界線每周都在向右移動：模型更強了，工具更成熟了，工作流也在不斷優(yōu)化。

最近我在 HN 上看到了一個名為 daxfohl 網友寫的一條評論，寫得非常精彩：

“用 AI 過多，和用 AI 過少，哪種風險更高？”

這句話讓我重新思考 LLM 在編程中的角色。尤其是在讀到其他開發(fā)者分享各自團隊引入 AI 的經驗之后，我意識到問題并不只是“要不要用”。兩個方向都可能走偏。但隨著模型不斷進化，在工作中“合適”的 AI 使用比例，是不是也在悄悄變化？

我們是怎么走到這一步的？

不久前，第一批 AI 編程工具開始出現，比如 2022 年的 Copilot 和 2023 年的 Cursor。它們可以通過 RAG 快速索引整個代碼庫，因此掌握了本地上下文。同時，它們背后的大模型本身就帶著對互聯網的“外部知識”。從那以后，普通用戶不再需要頻繁使用 Google、刷 StackOverflow。

Cursor 甚至直接提供了一套定制 IDE，把 AI 自動補全、內置聊天等能力整合進去，讓整個體驗變得連貫，而不是零散地拼插件。

接著，“智能體”的概念應運而生。

MCP、自動化工作流、可以通宵運行的 Agent，層出不窮。這是與 Cursor 等 AI 應用方式完全不同的用法。它不再是“AI 輔助人類寫代碼”，而是變成了“人類輔助 AI 寫代碼”。

很多開發(fā)者試過，然后踩了坑。Agent 會犯大量細碎的小錯誤。所謂 AI-first 的流程，要求你從根本上改變對編程的理解方式，否則很難產出好結果。更麻煩的是，Agent 經常陷入循環(huán)，憑空“幻想”出不存在的依賴，或者生成“看起來差不多對了”的代碼——可惜就是不對。你得學習一整套新技術，而這種技術又被因害怕錯過機會的心理所驅動。而且，這套閃閃發(fā)光的新工具，幾乎從來不會第一次就給出 100% 正確的結果。

軟件原本是確定性的。你用 if/else 分支控制邏輯，用明確狀態(tài)機管理流程，一切都清清楚楚。現在卻變成用 Prompt、系統(tǒng)指令、CLAUDE.md 文件去“引導”模型，然后祈禱它輸出你想要的結果。

后來，Claude Opus 4.5 發(fā)布了。

那些之前只存在于討論中的工作流，開始真正“開箱即用”地跑起來——當然也不是每次都成功，但成功的次數明顯多了。工程師的角色也在變化，越來越像“前線部署工程師”，負責的事情遠不止寫代碼。有時甚至不再親手寫代碼。

最近，Spotify 聯合 CEO Gustav S?derstr?m 提到：

“一名 Spotify 的工程師，在早晨通勤路上，通過手機上的 Slack，就可以讓 Claude 修一個 bug，或者給 iOS 應用加個新功能。等 Claude 完成后，新版本會直接通過 Slack 推送到他的手機上。他甚至還沒到辦公室，就可以把改動合并到生產環(huán)境。”

當然，我希望他們至少在合并前會審一下代碼。

下一階段，是（幾乎）完全自動化。這正是許多高管所追求的目標：一個永不睡覺、不會疲倦、隨時待命、生產力無限的“員工”。聽上去像是資本主義的終極幻想。

可歷史提醒我們，時間表往往比愿景慢得多。2016 年，Geoffrey Hinton 預測，五年內深度學習將在醫(yī)學影像分析上超越放射科醫(yī)生。Anthropic 的 CEO 也曾預測，到 2025 年 3 月之后的 3-6 個月內，AI 將編寫 90% 的代碼。

這些都沒有按原計劃發(fā)生。

趨勢是真的。但時間線，總是在往后推。

AI 如何影響你的大腦？

2012 年，神經科學家 Manfred Spitzer 出版了《Digital Dementia》一書。他在書中提出，當我們把原本需要自己完成的心智任務外包給數字設備時，負責這些任務的大腦通路會逐漸退化。用進廢退。雖然書中的部分觀點仍存在爭議，但神經可塑性研究確實表明：經常使用的神經通路會被強化，而長期不用的會變弱。書的核心觀點很簡單——你停止練習的認知能力，會慢慢下降。

軟件工程研究者 Margaret-Anne Storey 最近給這種現象起了一個更精確的名字：認知債務（cognitive debt）。技術債務存在于代碼里，認知債務存在于開發(fā)者的大腦中。它指的是那種在高速構建系統(tǒng)、卻沒有真正理解所構建內容時逐漸積累的理解流失。

她的觀點建立在 Peter Naur 1985 年提出的理論之上：程序本質上是一種存在于開發(fā)者心中的“理論”，它包含程序做什么、設計意圖如何映射到實現，以及未來如何演化。當這種“理論”在開發(fā)者頭腦中碎裂時，系統(tǒng)就會變成一個黑箱。

把這一點直接套用到完全 Agent 化的編程模式上。如果你停止寫代碼，只負責審查 AI 的輸出，你推理代碼的能力就會開始退化。這個過程緩慢、隱蔽，但不可避免。你無法真正深入審查那些你已經無法深入理解的內容。

這不僅僅是紙上談兵。2026 年，Shen 和 Tamkin 做了一項隨機對照研究：他們讓 52 名專業(yè)開發(fā)者學習一個新的異步庫，并分成使用 AI 輔助和不使用 AI 兩組。結果顯示，AI 組在概念理解、調試能力和代碼閱讀方面的得分低了 17%。差距最大的是調試能力——恰恰是發(fā)現 AI 錯誤所最需要的技能。僅僅一小時被動依賴 AI 輔助工作，就已經可以測量到技能衰退。

更隱蔽的部分在于：你幾乎察覺不到這種下降，因為工具在替你彌補。你感覺自己很高效。PR 在持續(xù)合并。心理學家 Mihaly Csikszentmihalyi 關于“心流”的研究指出，心流狀態(tài)依賴于挑戰(zhàn)與技能之間的平衡。大腦需要被恰到好處地拉伸。真正的心流會帶來成長。

研究者 Rachel Thomas 則把 AI 輔助工作帶來的狀態(tài)稱為“黑暗心流”（dark flow）。這個詞源自賭博研究，用來描述老虎機刻意制造的那種恍惚沉浸狀態(tài)。你感到投入，但挑戰(zhàn)與技能之間的平衡已經消失，因為 AI 承擔了挑戰(zhàn)部分。它看起來像深度工作的心流狀態(tài)，但反饋循環(huán)已經斷裂。你并沒有變得更強，而是在變得依賴。

沒有寫代碼，只有審查

HN 評論區(qū)里有個反復出現的觀察：如果 AI 寫了所有代碼，而你只負責審查，那么審查所需的能力從哪里來？兩者不可分割。你不會通過讀教科書或 PR 學會辨別好代碼。你是通過寫出糟糕的代碼、被審查者拆得體無完膚、在多年實踐中逐漸建立直覺，才學會的。

這形成了我所說的“審查悖論”：AI 寫得越多，人類就越不具備審查它的能力。Shen–Tamkin 的研究為此提供了數據支持。完全把任務交給 AI 的開發(fā)者完成速度最快，但評估得分最低。最能從 AI 提升效率中受益的新手，恰恰是最需要調試能力來監(jiān)督 AI 的人，而 AI 又最先侵蝕的正是這種能力。

Storey 提出的解決方案很直接：“在部署前，要求人類理解每一項 AI 生成的改動。”這是正確答案。但在以“速度”為核心指標的環(huán)境里，這往往也是第一個被跳過的環(huán)節(jié)。

資歷塌縮

問題不只是個人技能衰退。過去，我們有初級工程師、中級、高級、Staff、架構師。這是一條建立在多年實踐之上的成長路徑。初級工程師會花很多年寫出在代碼審查中被拒絕的代碼，不是因為不認真，而是因為經驗不足。正是這些經歷，構建了判斷力——區(qū)分“能寫函數的人”和“能設計系統(tǒng)的人”。你不可能一夜之間成為高級工程師。

除非你用 AI。

現在，一個初級工程師配上 Claude Code（Opus 4.5+），就能提交看起來像高級工程師寫的 PR。從整體效率看，這是好事。但這是否意味著高級工程師的“帽子”可以從第一天就戴在每個人頭上？帽子在，腦子卻沒變。那位初級工程師并不知道為什么選擇這種架構。以我的經驗來看，Claude Code 有時會漏掉本該存在的數據庫事務；有時會因為各種原因給本不該加鎖的資源加鎖。我可以為自己的決策辯護，也樂于在代碼被質疑時展開討論。但一個初級工程師會怎么做？去問 Claude。

這是雙向的崩潰。停止親自寫代碼、只審查 AI 輸出的高級工程師，會失去自身的深度。跳過掙扎階段的初級工程師，也從未真正建立起這種深度。組織每天花費大量高級工程師的時間在代碼審查上，卻同時破壞了培養(yǎng)高級工程師的機制。那條通過寫糟糕代碼、被審查、在失敗中建立直覺的成長管道，正在被完全繞開。等這條管道徹底干涸時，會發(fā)生什么？幾乎沒人討論這個問題。

C-Level 們說對了什么，又說錯了什么

看看每周擺在高管桌上的內容：

• 微軟 AI 負責人 Mustafa Suleyman 表示，18 個月內所有白領工作都會被自動化。

• Anthropic 的 CEO Dario Amodei 預測，6–12 個月內 AI 就會取代軟件工程師，還引用自家工程師的話說，他們已經不寫代碼了，只是讓模型寫，然后自己編輯輸出。

• Sundar Pichai 則透露，2024 年底谷歌新增代碼中有 25% 是 AI 生成的。幾個月后，Google Research 報告這個數字已經達到 50% 的代碼字符。

如果你是一位 CTO，看著這樣的曲線走勢，當然會推動團隊全面擁抱 AI。

問題在于，這些預測往往來自正在銷售 AI 的人，或者試圖用 AI 概念支撐股價的人。他們有充分動機加速 AI 的普及，卻幾乎不需要為時間表失準負責。而歷史告訴我們，時間表幾乎總會失準。更何況，“50% 的代碼字符”出自一家從模型、工具鏈到基礎設施全部自研的公司，對你下周一用現成 Agent 能做到什么，參考意義并不大。

AI 的采用不是一個可以一鍵切換的開關，而是一項需要校準的能力。事情遠不止“強制使用某個工具”、“制定 AI-first 政策”、“用 AI 使用量來衡量開發(fā)者表現”這么簡單（/r/ExperiencedDevs 上有大量類似故事）。很多原本良好的實踐——設計模式、完整測試覆蓋、合并前的人工測試——正在被跳過，因為它們會拖慢節(jié)奏。AI 弄壞的？AI 會修好。需要 review？AI 來做。甚至不需要 Greptile 或 CodeRabbit。直接把 PR 丟給 Claude Code reviewer agent，或者 Gemini，或者 Codex。任選一種“毒藥”。

當你強制推廣 AI 使用時，現實會變成什么樣？

一位開發(fā)者在 r/ExperiencedDevs 論壇上分享了他們公司開始按人統(tǒng)計 AI 使用量：“我干脆讓我的機器人去做一些我根本不在乎的隨機任務。有一天我讓 Claude 去隨便翻目錄‘找 bug’，或者回答我早就知道答案的問題?！?/p>

結果那個帖子里有很多工程師抱怨，AI 讓代碼審查“難度無限上升，因為團隊負責人長時間脫離實際編碼后，用 AI 生成了大量垃圾代碼?！?/p>

這其實很令人惋惜。熟練使用 AI 工具本應是開發(fā)者的福利。它確實能提速，也是管理層想要的東西。那些“刷指標”的人，如果被管理層發(fā)現真實情況，很可能會當場被解雇（這也公平）。但他們之所以刷指標，是因為害怕被解雇。

那么，公司里誰該決定 AI 使用的“閾值”？如果你最優(yōu)秀的工程師拒絕用 AI 怎么辦？如果新招的初級工程師全天候用 AI 又怎么辦？管理層正在尋找答案，但答案絕不只是“統(tǒng)計 AI 使用量”這么簡單。

這正是古德哈特定律（Goodhart’s Law）的現實版：“當一個指標成為目標，它就不再是一個好指標。”

如果你按人追蹤 AI 使用率，得到的不會是更好的工程質量，而是合規(guī)表演。開發(fā)者會對工具產生抵觸情緒，而 AI 本可以帶來的真實生產力提升，則會被組織層面的失調掩蓋。

那些沒人談的成本

經濟成本很明顯。讓 Agent 處理一個非平凡功能，往往需要按小時計費，這些時間并不便宜。

更嚴重的是人的成本，而這幾乎沒人討論。

上文也提到過，寫代碼能讓人進入心流狀態(tài)。在這種狀態(tài)下，你會全神貫注、深入思考、創(chuàng)造性地去解決問題，時間仿佛飛逝，最后你會得到一個自己構建的成果，并為此感到自豪。有人在你的 PR 下留言“Good job!”并點了贊表示認可。那種滿足感是真實的。

審查 AI 生成的代碼不會帶來這種體驗。它恰恰相反，是一種精神消耗。

開發(fā)者需要創(chuàng)造帶來的多巴胺刺激。這不是額外福利，而是保持優(yōu)秀工程師持續(xù)投入、持續(xù)學習、避免倦怠的關鍵。很多人成為資深開發(fā)者，正是因為熱愛編碼本身。把創(chuàng)造替換為監(jiān)督，你得到的不是更快交付，而是更快的倦怠。工程這項創(chuàng)造性工作，被變成了最糟糕版本的 QA。AI 負責創(chuàng)作，人類負責“疊衣服”。

找到屬于你的閾值

我每天都在用 AI。工作用，業(yè)余項目也用，而且不想回到沒有它的時代。我真的很喜歡它。

正因如此，我才擔心。我害怕自己已經上癮，已經依賴。我實現了無數自定義命令、Skill 和 Agent。每天都會看 Claude Code 的更新日志。我知道很多人處在類似狀態(tài)，我們都在想未來會怎樣。我們會被 AI 取代嗎？還是會負責清理 AI 生成的“代碼殘渣”？對我來說，合適的 AI 使用比例到底是多少？

AI 只是工具。極其強大的工具，但終究是工具。你不會強制每個工程師都用同一個 IDE，也不會用“每天寫多少行代碼”來考核人（希望如此）。你會讓他們選擇最有效的工具，并衡量真正重要的東西——能否交付。

合適的 AI 使用量，不是零，也不是最大化。

Shen–Tamkin 的研究識別出六種開發(fā)者與 AI 的互動模式。其中三種會導致學習效果變差：完全委托、逐步依賴、把調試外包給 AI。另三種則在完全可訪問 AI 的情況下仍能保持學習效果：請求解釋、提出概念性問題、獨立寫代碼并把 AI 作為澄清工具。區(qū)別不在于是否使用 AI，而在于是否保持認知參與。

軟件工程從來不只是敲代碼。它包括定義問題、真正理解問題、把業(yè)務語言轉化為產品語言再轉化為代碼、澄清模糊點、做權衡、理解改動會帶來什么連鎖反應。在 AGI 到來之前，總要有人做這些事，而 AGI 離那一步還很遠（所幸如此）。凌晨三點電話響起，你能在沒有 Agent 的情況下排查問題嗎？如果不能，你可能已經把 AI 編程用得太過了。如果 AI 使用率變成開發(fā)者績效指標，也許“用得太多”同樣應該被約束。不是因為工具不好，而是因為編碼能力值得維護。

用得太少的風險（經驗觀察）

如果在 2026 年你完全不用 AI，那確實是在錯失實實在在的收益：

• 搜索與上下文理解：AI 在瀏覽陌生代碼庫、理解遺留系統(tǒng)、尋找相關模式方面，確實比 Google 更高效。這一點本身就足以讓它成為工作流的一部分（自 2023 年 Cursor 等工具出現以來）。
  

• 樣板代碼與腳手架：當 Agent 幾秒鐘就能生成 CRUD 接口、配置文件或測試模板時，你還手寫第 100 個類似模塊，不是工匠精神，而是固執(zhí)。直接用 AI。現在的開發(fā)者都身兼數職，早已不是單純的 CRUD 工程師了（尤其在 2025 年 Sonnet 之后）。
  

• 工作流本身：調查、規(guī)劃、實現、測試、驗證——配合定制 Agent，這套流程確實讓功能交付變快。原本幾天的工作縮短為幾小時。沒有達到宣傳中的 10 倍提升，但在成熟代碼庫上實現 2 倍或 4 倍并不難。當然，你必須真正理解輸出，以及 AI 做出的每一個決策（2025 年 Opus 4.5 之后尤為明顯）。
  

• 探索能力：“這個模塊做什么？這個 API 怎么工作？如果我改這里會壞什么？”AI 在這些問題上表現出色。它不會替代閱讀代碼，但能幫你在正確的時間定位到正確的文件（自 2023 年起）。

出于原則拒絕 AI，與出于炒作盲目擁抱一樣不理性。

用得太多的風險（經驗與預測）

如果你全面押注自治 AI 編程，尤其在不了解其原理的情況下，風險可能比“效率下降”更糟——它是隱形的退化：

• 看起來像功能的 Bug：AI 生成的代碼通過 CI，類型檢查無誤，測試全綠。但內部埋著微妙的邏輯錯誤、幻覺式邊界情況、在高負載下會崩潰的模式。在金融或醫(yī)療領域，一個不會報錯的錯誤數字，比系統(tǒng)崩潰更糟。（重要性在下降，但依然存在）
  

• 沒人真正理解的代碼庫：當 Agent 寫下全部代碼，人類只做審查，半年后團隊里沒人能解釋系統(tǒng)為什么這樣設計。AI 做出了選擇，測試通過，于是無人質疑。Storey 曾描述一個學生團隊正是因此陷入困境：他們無法做簡單改動，因為沒人說得清當初的設計決策。她的結論很明確：“沒有理解的速度不可持續(xù)。”（在我看來，這永遠會是問題）
  

• 認知退化：前面“數字癡呆”部分提到的一切。停止練習的技能必然下降。（同樣會長期存在）

• 資深工程師培養(yǎng)管道干涸：上文已討論。這種問題需要多年才會顯現，也正因如此沒人提前規(guī)劃。（這是新問題，未來會怎樣還很難說）

• 倦怠：整天審查 AI 輸出，卻沒有創(chuàng)造帶來的多巴胺刺激，這種工作描述不可持續(xù)。（老問題，但可能來得更快？）

悄然衰退

讓我夜不能寐的是這個問題。按照每一個儀表盤上的指標來看，AI 輔助的人類開發(fā)和人類輔助的 AI 開發(fā)都在進步——PR 交付更多，功能迭代更快，周期時間縮短，圖表一片向上向右。

但這些指標捕捉不到下面正在發(fā)生的事情：整天審查你自己沒寫的代碼帶來的精神疲勞；盯著 Agent 看而不是解決實際問題的無聊感；那些讓你最初勝任這份工作的硬技能正在緩慢、悄無聲息地退化。你不再在腦中維護架構，因為 Agent 已經處理了；你不再思考邊界情況，因為測試都通過了；你不再想深入鉆研，因為 prompt 一下就能批準。你的內心不再有火花。

在這個梗里，開發(fā)者就像黃油機器人。那些沒有足夠認知去審查 AI 生成計劃和 PR 的人，只會點擊 “Accept”，而不會去做創(chuàng)造性、充滿挑戰(zhàn)的工作。諷刺的是，這正是整個問題的縮影。

我們這個時代最有野心的開發(fā)者之一 Simon Willison 承認，這已經在他身上發(fā)生了。在一些項目里，他通過 prompt 完成了整個功能，而沒有審查實現細節(jié)，他說：“我已經無法對這些功能能做什么以及它們如何工作形成清晰的心智模型?！?/p>

然后有一天，指標開始下滑……并不是因為工具變差，而是因為你變了。不是努力不夠，而是缺乏練習。這是一個反饋循環(huán)，看上去像是在進步，直到它不再進步為止。

沒有高管愿意去衡量這個問題?！癆I 使用對工程師認知能力在 18 個月內的影響是什么？”——這不是一個容易設定的 KPI，也不可能放進季度評審。它不被追蹤，而不被追蹤的東西就不會被管理，直到它以生產事故的形式顯現——團隊里沒有人能在沒有 Agent 的情況下調試，而 Agent 也調試不了。

我并不反對 AI，我很喜歡它。我對 prompt 上癮，從中獲得快感。我只是擔心，這種新的依賴會悄悄地削弱我們，而沒人去留意。

未來沒有前后端，只有 AI Agent 工程師。

這場十倍速的變革已至，你的下一步在哪？

4 月 17-18 日，由 CSDN 與奇點智能研究院聯合主辦「2026 奇點智能技術大會」將在上海隆重召開，大會聚焦 Agent 系統(tǒng)、世界模型、AI 原生研發(fā)等 12 大前沿專題，為你繪制通往未來的認知地圖。

成為時代的見證者，更要成為時代的先行者。

奇點智能技術大會上海站，我們不見不散！