AI寫代碼，讓你付出的代價(jià)是什么？

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

但有時(shí)候，在深夜合上電腦之后，會(huì)冒出一個(gè)不那么 KPI 的問題：我們到底是在變強(qiáng)，還是在變依賴？

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

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

作者 | Tom Wojcik 責(zé)編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

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

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

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

最近我在 HN 上看到了一個(gè)名為 daxfohl 網(wǎng)友寫的一條評(píng)論，寫得非常精彩：

“用 AI 過多，和用 AI 過少，哪種風(fēng)險(xiǎn)更高？”

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

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

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

Cursor 甚至直接提供了一套定制 IDE，把 AI 自動(dòng)補(bǔ)全、內(nèi)置聊天等能力整合進(jìn)去，讓整個(gè)體驗(yàn)變得連貫，而不是零散地拼插件。

接著，“智能體”的概念應(yīng)運(yùn)而生。

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

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

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

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

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

最近，Spotify 聯(lián)合 CEO Gustav S?derstr?m 提到：

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

當(dāng)然，我希望他們至少在合并前會(huì)審一下代碼。

下一階段，是（幾乎）完全自動(dòng)化。這正是許多高管所追求的目標(biāo)：一個(gè)永不睡覺、不會(huì)疲倦、隨時(shí)待命、生產(chǎn)力無限的“員工”。聽上去像是資本主義的終極幻想。

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

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

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

AI 如何影響你的大腦？

2012 年，神經(jīng)科學(xué)家 Manfred Spitzer 出版了《Digital Dementia》一書。他在書中提出，當(dāng)我們把原本需要自己完成的心智任務(wù)外包給數(shù)字設(shè)備時(shí)，負(fù)責(zé)這些任務(wù)的大腦通路會(huì)逐漸退化。用進(jìn)廢退。雖然書中的部分觀點(diǎn)仍存在爭議，但神經(jīng)可塑性研究確實(shí)表明：經(jīng)常使用的神經(jīng)通路會(huì)被強(qiáng)化，而長期不用的會(huì)變?nèi)酢暮诵挠^點(diǎn)很簡單——你停止練習(xí)的認(rèn)知能力，會(huì)慢慢下降。

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

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

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

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

更隱蔽的部分在于：你幾乎察覺不到這種下降，因?yàn)楣ぞ咴谔婺銖浹a(bǔ)。你感覺自己很高效。PR 在持續(xù)合并。心理學(xué)家 Mihaly Csikszentmihalyi 關(guān)于“心流”的研究指出，心流狀態(tài)依賴于挑戰(zhàn)與技能之間的平衡。大腦需要被恰到好處地拉伸。真正的心流會(huì)帶來成長。

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

沒有寫代碼，只有審查

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

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

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

資歷塌縮

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

除非你用 AI。

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

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

C-Level 們說對(duì)了什么，又說錯(cuò)了什么

看看每周擺在高管桌上的內(nèi)容：

• 微軟 AI 負(fù)責(zé)人 Mustafa Suleyman 表示，18 個(gè)月內(nèi)所有白領(lǐng)工作都會(huì)被自動(dòng)化。

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

• Sundar Pichai 則透露，2024 年底谷歌新增代碼中有 25% 是 AI 生成的。幾個(gè)月后，Google Research 報(bào)告這個(gè)數(shù)字已經(jīng)達(dá)到 50% 的代碼字符。

如果你是一位 CTO，看著這樣的曲線走勢，當(dāng)然會(huì)推動(dòng)團(tuán)隊(duì)全面擁抱 AI。

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

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

當(dāng)你強(qiáng)制推廣 AI 使用時(shí)，現(xiàn)實(shí)會(huì)變成什么樣？

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

結(jié)果那個(gè)帖子里有很多工程師抱怨，AI 讓代碼審查“難度無限上升，因?yàn)閳F(tuán)隊(duì)負(fù)責(zé)人長時(shí)間脫離實(shí)際編碼后，用 AI 生成了大量垃圾代碼?！?/p>

這其實(shí)很令人惋惜。熟練使用 AI 工具本應(yīng)是開發(fā)者的福利。它確實(shí)能提速，也是管理層想要的東西。那些“刷指標(biāo)”的人，如果被管理層發(fā)現(xiàn)真實(shí)情況，很可能會(huì)當(dāng)場被解雇（這也公平）。但他們之所以刷指標(biāo)，是因?yàn)楹ε卤唤夤汀?/strong>

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

這正是古德哈特定律（Goodhart’s Law）的現(xiàn)實(shí)版：“當(dāng)一個(gè)指標(biāo)成為目標(biāo)，它就不再是一個(gè)好指標(biāo)。”

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

那些沒人談的成本

經(jīng)濟(jì)成本很明顯。讓 Agent 處理一個(gè)非平凡功能，往往需要按小時(shí)計(jì)費(fèi)，這些時(shí)間并不便宜。

更嚴(yán)重的是人的成本，而這幾乎沒人討論。

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

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

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

找到屬于你的閾值

我每天都在用 AI。工作用，業(yè)余項(xiàng)目也用，而且不想回到?jīng)]有它的時(shí)代。我真的很喜歡它。

正因如此，我才擔(dān)心。我害怕自己已經(jīng)上癮，已經(jīng)依賴。我實(shí)現(xiàn)了無數(shù)自定義命令、Skill 和 Agent。每天都會(huì)看 Claude Code 的更新日志。我知道很多人處在類似狀態(tài)，我們都在想未來會(huì)怎樣。我們會(huì)被 AI 取代嗎？還是會(huì)負(fù)責(zé)清理 AI 生成的“代碼殘?jiān)保繉?duì)我來說，合適的 AI 使用比例到底是多少？

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

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

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

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

用得太少的風(fēng)險(xiǎn)（經(jīng)驗(yàn)觀察）

如果在 2026 年你完全不用 AI，那確實(shí)是在錯(cuò)失實(shí)實(shí)在在的收益：

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

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

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

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

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

用得太多的風(fēng)險(xiǎn)（經(jīng)驗(yàn)與預(yù)測）

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

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

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

• 認(rèn)知退化：前面“數(shù)字癡呆”部分提到的一切。停止練習(xí)的技能必然下降。（同樣會(huì)長期存在）

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

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

悄然衰退

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

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

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

我們這個(gè)時(shí)代最有野心的開發(fā)者之一 Simon Willison 承認(rèn)，這已經(jīng)在他身上發(fā)生了。在一些項(xiàng)目里，他通過 prompt 完成了整個(gè)功能，而沒有審查實(shí)現(xiàn)細(xì)節(jié)，他說：“我已經(jīng)無法對(duì)這些功能能做什么以及它們?nèi)绾喂ぷ餍纬汕逦男闹悄Ｐ汀！?/p>

然后有一天，指標(biāo)開始下滑……并不是因?yàn)楣ぞ咦儾睿且驗(yàn)槟阕兞恕２皇桥Σ粔颍侨狈毩?xí)。這是一個(gè)反饋循環(huán)，看上去像是在進(jìn)步，直到它不再進(jìn)步為止。

沒有高管愿意去衡量這個(gè)問題。“AI 使用對(duì)工程師認(rèn)知能力在 18 個(gè)月內(nèi)的影響是什么？”——這不是一個(gè)容易設(shè)定的 KPI，也不可能放進(jìn)季度評(píng)審。它不被追蹤，而不被追蹤的東西就不會(huì)被管理，直到它以生產(chǎn)事故的形式顯現(xiàn)——團(tuán)隊(duì)里沒有人能在沒有 Agent 的情況下調(diào)試，而 Agent 也調(diào)試不了。

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

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

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

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

成為時(shí)代的見證者，更要成為時(shí)代的先行者。

奇點(diǎn)智能技術(shù)大會(huì)上海站，我們不見不散！