型別標得越清楚，AI 生成的程式碼越不會歪：一篇全棧筆記把 TypeScript 重新排回了必修課

2026 年 10 月 2 日，掘金上一篇標題為「前端轉全棧筆記：講框架之前，先把 TypeScript 這關過了」的長文開始流傳。作者 Timmy 在「前端轉全棧 · Agent 研發實踐」系列專欄的第二章，記錄了自己在 Node.js 之後、NestJS 之前卡住的那一關：TypeScript。

這篇筆記值得停下來看的原因，不在於它教了什麼新語法，而在於它點出了一個正在發生的位移：TypeScript 從「加分技能」變成了人與 AI 協作時的基礎設施。

先記住一句話：型別會被擦掉

整篇筆記有一條主線，作者自己把它濃縮成一句話：TS 的型別在編譯後會被全部擦除，執行期一點都不剩。

用一個貼近日常的比喻來說，型別系統像搬家前用的保麗龍填充材。搬家的路上（編譯期）它穩穩固定住每個物品的位置，貨車一到新家（執行期），填充材就拆掉丟了，屋裡只剩實際的傢俱。指望填充材在入住後還能擋住東西摔落，是搞錯了它的工作階段。

這個認知直接解釋了幾件工程師常困惑的事。as 斷言在執行期什麼都不做，它只是對編譯器說「這件事我比你清楚」的口頭聲明。JSON.parse 回來的資料就算標成 User，執行期也不會因此多一層檢查，編譯器只是選擇相信你的標註。而凡是需要在執行期使用型別資訊的功能，都必須有編譯後還活著的載體，這一條正是後面理解依賴注入的鑰匙。

為什麼是現在：AI 寫程式改變了型別的用途

筆記裡最核心的主張是：TypeScript 是 AI Coding 時代的一等公民。

理由並不玄。現在的寫碼方式變了，大量程式碼由 AI 生成，人負責描述意圖和驗收。在這種分工裡，型別標註變成人和 AI 之間最精確的契約。一個函式把入參出參標清楚，AI 生成的實作就歪不到哪裡去；專案的型別覆蓋越完整，AI 拿到的上下文就越準確，程式碼一次通過的機率越高。反過來說，滿屏 any 的專案，AI 也只能跟著猜。

這個觀點與我們先前討論過的DHH 宣告「放下鉛筆」後工程師價值的位移可以對照著看。當手寫程式碼不再是預設工作模式，工程師的價值往描述意圖、定義邊界與驗收的那一層移動，而型別標註正是這一層最具體的語言。寫得越認真，機器做得越漂亮，這在整個開發工具鏈裡是少數成立的正向循環。

裝飾器與依賴注入：為什麼 NestJS 讓前端「滿臉問號」

筆記的後半段處理三塊為框架打底的能力：class、依賴注入這個設計模式，以及裝飾器。

作者形容第一次打開 NestJS 程式碼時「人是懵的」：裝飾器、依賴注入、constructor 裡奇怪的 private，撲面而來的 Java 味，用的全是 TS 裡前端「知道但不用」的那一半能力。這段描述對許多只寫過 React 或 Vue 元件的前端工程師來說應該不陌生。

這裡剛好接上前述「型別會被擦掉」的主線。裝飾器和依賴注入之所以在 NestJS 裡長成那個樣子，正是因為框架需要在執行期拿到「編譯後還活著」的型別資訊，而純粹的型別標註擦除後什麼都不剩，所以框架得靠裝飾器這種會留在產物裡的語法，把後設資料帶過編譯這一關。

對照來看，想往 Agent 開發方向轉的前端工程師，這條路徑上的關卡分布和我們在前端轉 AI 這條路的分析裡整理的結構類似：真正的門檻往往不是框架本身，而是框架預設你已經具備的底層知識。NestJS 預設你懂裝飾器與依賴注入，這些恰好是純前端日常較少碰的部分。

筆記裡幾個實用的提醒

除了主線論證，筆記的基礎語法複習部分有幾個值得留下的要點。

推斷能省就省，但三個地方要顯式標註：函式回傳值、複雜物件、空陣列。空陣列尤其容易踩坑，[] 會被推斷成 any[]，之後 push 什麼都不檢查。

strict 模式下 null 與 undefined 不能隨便塞進別的型別，得用 string | null 這種寫法明確宣告「可能為空」。這正是 strictNullChecks 的價值：把 Cannot read properties of undefined 這類線上事故提前到編譯期現形。作者的建議很直接，新專案沒有理由不開 strict。

元組有一個已知的型別不健全點：push 不受元組長度限制，編譯不會報錯。元組只保證讀取和解構時的型別。在 AI 大量生成程式碼的現在，這種邊界要特別留意，避免生成的程式碼依賴元組的長度安全。

物件字面量直接傳參會觸發多餘屬性檢查，先賦給變數再傳就跳過了。readonly 是編譯期約束，執行期照常能改，這又回到「型別會被擦掉」那條主線。

所以呢

這篇筆記的價值不在於複習語法，而在於它把學習路線重排了：以前是「先學框架，遇到不懂的 TS 語法再回頭查」，現在是「先把手牌理清楚，框架讀起來才通」。對照 AI 生成程式碼成為日常工作模式的現在，這個重排的理由又多了一層：型別標註已經不是寫給編譯器看的註解，而是寫給協作對象看的規格書。

前端工程師若正考慮往全棧或 Agent 開發移動，這篇筆記給的檢查點很具體：strict 是否開了、any 出現的密度、以及有沒有實際寫過裝飾器。這三項大概就是框架之路前最後一段需要自己走的路。