連手寫一個 HTTP 請求都不會了：兩個資深工程師談 AI 時代的技能萎縮
TL;DR
- 有聽眾投書說自己的專案裡八到九成程式碼是 AI 生成的，結果連最基本的 HTTP 請求都不會自己寫了。主持人的回答是：這不是錯覺，大腦真的會把不用的神經通路關掉
- 記不住語法沒關係，搞不懂「一個請求怎麼在你的系統裡跑完一圈」才是真的完蛋
- 心流狀態被 AI 的等待時間殺光了。一個主持人同時開了十三個專案，他自嘲注意力已經被打得稀爛
- 只能訂一個 AI 訂閱的話，兩人都偏向 OpenAI Codex，理由是可以搭配別家的工具，不會被鎖死
- 真正該投資的是「讓你的設定可以搬家」，而不是把時間全押在某一個工具上
- 什麼時候該換掉一個還能用的舊工具？經驗法則是：聽到有人說「這東西已經死了」之後，再等三年
這集是什麼
這集是 Syntax.fm 在 2026 年 8 月 19 日播出的第 1031 集，標題就叫「My Coding Skills Are Atrophying」（我的寫程式能力正在萎縮）。Syntax 是網頁開發圈子裡最老牌的 podcast 之一，從 2017 年做到現在超過一千集，兩位主持人是 Wes Bos 和 Scott Tolinski。Wes Bos 是加拿大的獨立開發者，靠賣線上課程起家，在前端圈是那種你搜任何 JavaScript 教學都會撞到他的人物。Scott Tolinski 則是 Level Up Tutorials 的創辦人，後來整間被錯誤監控公司 Sentry 收購，他現在在 Sentry 掛 Executive Producer，等於是被買去專職做內容。
這集的形式叫 potluck，就是聽眾丟問題、他們現場回答。看起來很鬆，但這集丟出來的幾個問題，其實是現在每個用 AI 工作的人心裡都在想但不太好意思問出口的。
「我連 HTTP 請求都不會寫了」
第一個問題來自一位叫 the Fox 的聽眾，他寫得很誠實：每次開新專案都讓 AI 自動補完或直接生成，久了之後 code base 裡有八到九成是 AI 寫的，然後他發現自己忘了最基本的東西，連一個 HTTP 請求都沒辦法徒手寫出來。他問：我該重新學一遍嗎？
Scott 的回答沒有安慰他。他說這件事不只是「感覺」，是生理上真的在發生。你不重複做那些動作，大腦就不會維持那些神經通路，那些路徑不是消失就是變得存取不到。這跟那些腦力訓練 App 的行銷話術很像，但這次是真的：不用就會退化。
Wes 補了一個很重要的分界。他說有兩件事要分開看。
第一件是語法。reduce 的 callback 到底吃哪幾個參數，這種東西記不記得住，他覺得沒那麼要緊。他自己也承認，十年前在 IE 上修 PNG 透明度的那套 hack，他現在完全寫不出來，但那沒差，因為整個環境早就變了。
第二件是機制。一個請求怎麼在你的應用程式裡流動、一個 API 呼叫實際上發生了什麼事，這種東西你不懂，遲早會撞上效能問題，而且撞上的時候你連從哪裡開始查都不知道。
Wes 的原話大概是這個意思：很多人現在寫程式已經變成「不看 code 了」，反正輸出來能跑就好。而那個「不在乎」才是危險的地方。你一開始只是懶得看，然後你就真的不懂了，然後有一天你發現自己手上什麼技能都沒剩下。
我覺得這段值得停下來想一下。之前在「No one cares anymore?」當寫程式的快樂被 AI 一刀切走那篇聊過類似的焦慮，但那時候談的比較是「快樂」被拿走。這集談的更冷酷：能力本身正在被拿走，而且拿走的過程是無感的。
他們給的解方其實不複雜：當一個主動參與者。不要接受 AI 吐出來的第一個版本，多問一句「這樣為什麼會動」。Wes 舉了 Zed 團隊的例子，說那些現在做 AI 工具做得最好的人，都不是隨便 vibe code 出一個助理然後兩個月後放著爛掉的人，他們是真的把「這套東西該怎麼組起來」想得非常深的人。
心流死了，兇手是等待
有個叫 Nick 的聽眾問了一個更痛的問題：以前徒手寫程式的時候，會進入那種深度專注的心流狀態，寫起來很爽甚至有點療癒。但用 AI 之後，這個狀態就再也回不來了。你們也這樣嗎？
Scott 直接投降。他說他的心流狀態已經被徹底摧毀了，然後他做了一個很妙的自嘲：他說自己現在像電影裡那隻看到松鼠就分心的狗。接著他跟 Wes 花了整整一分鐘在考據那部電影是不是《Air Bud》（台灣叫《飛狗巴迪》），扯了一堆有的沒的，扯完之後 Scott 才回過神說：各位觀眾，我剛剛在講我有多容易分心，然後我就真的被 Air Bud 帶走了一分鐘。這段不是設計過的，是真的當場發生。
回到正題，他的診斷是：AI 回應之間的那段延遲，剛好長到足以讓你的注意力飄走。飄走之後你就去開另一個東西，然後再一個。他當場報數，說他現在的視窗管理器裡開著十三個專案。不是十三個都有 agent 在跑，但它們都開著。
他觀察到，那些還維持得住專注的人有一個共同點：一次只做一件事。
Wes 的補充比較細一點。他說要看你在做什麼。如果是刻一個小的 UI 元件，跟模型來回的等待其實沒長到需要你去找事做；但如果你丟出去的是一個要跑十五分鐘的大任務，那你確實很難乾坐著。
然後他講了一件我覺得蠻真實的事：他現在的心流不在寫 code，在研究和架構。做那些「開個輸入框、更新一下資料庫」的例行工作，他早就沒感覺了，因為賭注太低。但當問題變成「這個東西該怎麼設計、該選哪些技術、這東西到底怎麼運作」，尤其是踏進他自己也還沒摸過的領域，跟 AI 一起把它搞懂的過程，那個爽感才回來。
換句話說，心流沒有死，它往上搬了一層樓。這跟之前寫過的Design Engineer 正在崛起是同一條線：當生產動作被自動化，價值就往判斷和品味那端跑。
只能訂一個，你訂哪個
有人問：如果預算只夠訂一個 AI，訂哪個？
Scott 先抱怨這是對他來說最難的問題，因為他就是那種每天都想換新玩具的人。但硬要選，他會選 OpenAI 的 Codex 方案。理由蠻具體的：他覺得 Claude 在設計和 CSS 上明顯比較強，但 OpenAI 的模型給他的程式碼「更可靠地照他想要的方式運作」。
Wes 的理由不太一樣，也是我覺得更值得抄下來的那個：他選 Codex，因為它可以搭配別家的工具用，例如 OpenCode。而 Anthropic 現在的策略是把訂閱綁死在自家的 Claude Code 上，你想用別的殼就得回頭買 API。
這帶出一個很有意思的觀察。兩人聊到，現在這些 AI 公司的切換成本低到不像話。你今天可以在 A 家開一個對話，明天換 B 家的模型接著聊，中間幾乎沒有摩擦。唯一稍微綁得住你的東西，是你過去的聊天紀錄留在原本那家。Wes 半開玩笑說，這大概就是他們接下來會用的鎖：你不敢走，因為你的對話都在裡面。然後他自己吐槽：可是我每次都開新對話，因為對話拖久了品質就變差，所以我根本沒被鎖到。
他們也預言了一件我覺得會成真的事：這東西會開始被搭售。Wes 說如果你付了 X 的高階訂閱，就會送你一定額度的 Grok；某些電信方案裡會附贈額度。Scott 接得更荒謬：他說去 Costco 買個雞肉捲搞不好都會送你 token。這段是玩笑，但方向不像玩笑。當一個東西開始被當贈品送，它的定價權就已經在崩解了。
真正的答案：讓你的設定可以搬家
這集最實用的一段，是 Wes 給的建議：與其糾結選哪一家，不如把心力花在「讓你的設定可以搬家」。
他的做法是把 skills、agent 設定檔那些東西集中放好，用 symlink（符號連結，等於幫檔案建一個捷徑，讓不同工具都指到同一份）串到各個工具去。這樣你想試一個月的 Claude Code 就試，試完覺得不行就換回來，成本趨近於零。
Scott 也分享了他在用的 swamp.club，做的是「AI agent 的確定性自動化」。概念是把那些常做的流程寫成程式碼而不是交給 AI 每次現場即興。他舉例，他要在 Cloudflare 上開一個網域，這個流程已經被寫成腳本放在裡面，不管是哪個 AI 工具去呼叫它，執行結果都一模一樣，因為執行的是程式碼而不是模型。
Wes 則提到 executor.sh 這個工具，解決的是另一個他天天在痛的問題：他同時用 VS Code、Claude Code、Cursor、Codex 等等，每一個的設定格式都不一樣，光是把同一組 MCP 伺服器（一種讓 AI 連上外部工具的協定）在每個工具裡各設定一次、各登入一次，就足夠煩死人。
他們的共識可以濃縮成一句話：把你的行李打包好，隨時能走。
什麼時候該換掉一個還能用的工具
一位瑞典聽眾問了一個很成熟的問題：什麼時候該放棄一個還能跑、也還有人維護的工具？壓力到底是來自工具本身變差，還是來自周邊生態（招不到人、函式庫斷更、CI 整合變麻煩、兩年後還有沒有人接得住）？
Wes 給了自己的案例。他抱著 Express 這個 Node.js 後端框架比大多數人多撐了三四年。壓垮他的不是 Express 壞掉，是周邊：TypeScript 支援很爛、想用的新東西都不吃它那套 middleware 格式，逼他每次都要手寫轉接層。撐到某一天，維護那些膠水的痛超過了「老朋友很穩」的價值，他就搬去 Hono 了。他還補了一刀：你今天請一個年輕工程師來，他可能根本沒聽過這個東西。
Scott 的回答則是整集最誠實的一段。他說他後悔的遷移一大堆。後悔搬去 GraphQL。更後悔把 Level Up Tutorials 從 Meteor 搬走，因為搬走之後換了 React、換了 GraphQL、換了一堆東西，每一版都沒有原本的 Meteor 版本好用，直到很多年後搬到 SvelteKit 才勉強追平。而且他說如果再往前推，最早那個 Drupal 版本其實留著就好，換個外觀、做個自訂介面，到今天也還是能用。
他自己下的結論很重：那些老頭是對的，為了邊際的一點點改善去換掉能跑的東西，通常不划算，有時候還是負的。
Wes 給了一個可以直接抄走的經驗法則：從你第一次聽到有人說「這東西已經死了」開始算，再等三年。等到「很多人真的都在用新的那個」，而不是「新的那個很讓人興奮」，那才是時候。他順手用這條規則判了 Sass 一個死刑：這個 CSS 預處理器我們大概三年前就在節目上問過「Sass 死了嗎」，如果你現在還在用，可以換了，因為原生 CSS 該有的都有了，而且已經有些新語法是 Sass 反而不相容的。
一個沒人買單的好主意
還有一段題外話蠻值得記一下。有聽眾問，Tim Berners-Lee（全球資訊網的發明人）推的 Solid 專案，跟 Dan Abramov 前陣子在節目上聊的 AT Protocol 比起來如何？
Wes 故意沒先給 Scott 看，讓他當場打開官網。結果 Scott 逛了整整三分鐘，一邊逛一邊碎念：所以這到底是資料庫還是儲存空間？是雲端主機嗎？我到底拿到什麼東西？網站上寫著「有點像把你的資料裝在一個後背包裡」，Scott 忍不住吐槽：那你就直接說背包啊，大家都知道背包是什麼。
繞了半天他才拼出來：Solid 給你一個叫 pod 的個人資料儲存空間，你的資料放在自己的 pod 裡，App 來跟你借。概念上跟 AT Protocol 想解決的問題有點像，這在Dan Abramov 談 AT Protocol那篇有更完整的拆解。
但 Scott 的判斷很悲觀，理由是他拿 passkey 當對照。他說前陣子看到一支關於「我不想再記任何密碼」的短影片，底下留言清一色是：passkey 是三小、我討厭 passkey、passkey 從來沒成功過。他說看到的時候真的有點難過，因為 passkey 明明是好東西，那是我們的機會，然後我們搞砸了。
一般人根本不想管自己的資料放哪、也管不好。連密碼都管不好的人，你要他管一個 pod？他最後補了一句給所有做技術產品的人：技術人常常有很好的想法，然後完全不管好不好用、好不好看。
這句話跟前面那段「別急著換工具」其實是同一件事的兩面。技術圈很容易被「這個概念多漂亮」牽著走，但真正決定一個東西活不活得下來的，從來是有沒有人願意每天用它。
回到開頭那位聽眾的問題。我自己的答案是：你不需要回去背 HTTP 請求怎麼寫，但你需要至少有一次，把 AI 寫給你的東西從頭到尾看懂一遍，看到你能解釋「為什麼這樣就會動」。這件事每個禮拜做一次就夠了，成本很低，但它是你跟「哪天什麼都不剩」之間唯一的那道牆。
這類產業第一線的觀察我會持續整理，訂閱 wilsonhuang.xyz 就不會漏掉。
Sources:
推薦閱讀
喜歡這篇文章嗎？
訂閱電子報，每週收到精選技術文章與產業洞察，直送你的信箱。
💌 隨時可以取消訂閱，不會收到垃圾郵件