ESLint 是什麼？2026 年 Vibe Coder 不可不知的程式碼檢查工具

前言：Vibe Coding 時代的程式品質挑戰

2026 年的開發世界已經跟幾年前大不相同。隨著 AI 編程助手的普及,越來越多開發者進入了「Vibe Coding」的時代——我們用自然語言描述需求,AI 快速生成程式碼,然後我們稍作調整就能運行。這種開發方式極大地提升了效率,讓許多原本對編程望而卻步的人也能快速上手。

但是,這種快速開發模式也帶來了新的挑戰。當你用 AI 生成了一大段程式碼,或是從不同來源拼湊了多個程式片段,你如何確保這些程式碼的品質?如何知道它們是否遵循了最佳實踐?更重要的是,當專案逐漸變大,如何維持程式碼的一致性和可讀性?

這就是 ESLint 發揮作用的地方。作為 JavaScript 生態系統中最強大的程式碼檢查工具,ESLint 就像是你的程式碼品質守門員,在你提交程式碼之前幫你抓出潛在的問題。無論你是剛開始 Vibe Coding 的新手,還是已經用 AI 工具開發了好幾個專案的老手,ESLint 都能成為你不可或缺的開發夥伴。

ESLint 到底是什麼?

核心概念

ESLint 是一個開源的 JavaScript 程式碼檢查工具,它的名字來自「ES」(ECMAScript,也就是 JavaScript 的標準化名稱)和「Lint」(程式碼檢查的通用術語)。簡單來說,ESLint 會分析你的 JavaScript 程式碼,找出其中的問題,並根據你設定的規則給出警告或錯誤提示。

在 Vibe Coding 的情境下,你可以把 ESLint 想像成一位經驗豐富的程式導師,隨時在旁邊檢視你和 AI 一起寫的程式碼,提醒你哪裡可能有問題,哪裡不符合最佳實踐。它不會阻止你寫程式碼,但會在適當的時候給你建議。

ESLint 能做什麼?

ESLint 的功能遠比你想像的豐富。它可以幫你檢查各種程式碼問題,從最基本的語法錯誤到複雜的邏輯問題,從程式碼風格到潛在的效能隱憂。具體來說,ESLint 能夠:

抓出語法錯誤和邏輯問題。比如你可能不小心使用了未宣告的變數,或是在比較時誤用了單個等號而不是雙等號或三等號。這些問題在執行時可能會造成程式崩潰或產生難以追蹤的 bug,ESLint 能在你執行程式碼之前就發現它們。

統一程式碼風格。當你和 AI 一起寫程式碼,或是參考了網路上各種不同來源的程式碼片段時,很容易出現風格不一致的情況——有些地方用單引號,有些地方用雙引號;有些地方縮排是兩個空格,有些是四個。ESLint 可以幫你統一這些風格,讓整個專案看起來像是同一個人寫的。

強制執行最佳實踐。JavaScript 是一門非常靈活的語言,同一件事情往往有很多種寫法。但不是所有寫法都是好的。ESLint 可以根據社群多年累積的經驗,引導你使用更安全、更易維護的寫法。

預防常見的錯誤模式。某些程式碼乍看之下沒問題,但實際上藏有隱患。比如在 switch 語句中忘記寫 break,或是不小心覆寫了內建的全域變數。ESLint 能識別這些危險的模式並提醒你。

為什麼 Vibe Coder 特別需要 ESLint?

在 AI 輔助編程的時代,ESLint 的重要性反而更加凸顯了。原因有幾個:

首先,AI 生成的程式碼雖然通常能夠運行,但不一定遵循最佳實踐或你專案的特定規範。不同的 AI 模型可能有不同的「寫程式風格」,而 ESLint 可以幫你把這些程式碼統一起來。

其次,當你快速迭代開發時,很容易忽略一些細節問題。你可能急著實現功能,沒注意到某個變數名打錯了,或是某個條件判斷邏輯有問題。ESLint 就像是第二雙眼睛,幫你檢查這些容易遺漏的地方。

再者,對於新手 Vibe Coder 來說,你可能還不熟悉 JavaScript 的所有陷阱和最佳實踐。ESLint 的錯誤提示本身就是一種學習資源——每當它指出一個問題,你就有機會了解為什麼那樣寫不好,應該怎麼改進。

如何開始使用 ESLint

安裝 ESLint

開始使用 ESLint 非常簡單。如果你已經有一個 Node.js 專案,只需要在專案目錄中執行以下指令:

npm init @eslint/config@latest

這個指令會啟動一個互動式的設定精靈,詢問你一些問題來了解你的專案需求。它會問你專案使用什麼框架(React、Vue、或純 JavaScript)、是否使用 TypeScript、程式碼風格偏好等等。根據你的回答,它會自動安裝必要的套件並生成設定檔。

整個過程非常友善,即使是完全沒用過 ESLint 的新手也能輕鬆完成。設定精靈會處理所有複雜的細節,你只需要回答問題就好。

基本設定檔結構

完成安裝後,你會在專案根目錄看到一個名為 eslint.config.js 的設定檔(在 ESLint 9.0 之後採用的新格式)。這個檔案定義了 ESLint 該如何檢查你的程式碼。

一個基本的設定檔可能長這樣:

import js from '@eslint/js';

export default [
  js.configs.recommended,
  {
    rules: {
      'no-unused-vars': 'warn',
      'no-console': 'off',
      'semi': ['error', 'always']
    }
  }
];

這個設定檔做了幾件事:首先它載入了 ESLint 推薦的基本規則集,然後針對特定規則做了客製化調整。no-unused-vars 設為警告等級,意思是如果你宣告了變數但沒使用,ESLint 會給出警告但不會阻止程式運行。no-console 設為關閉,表示允許使用 console.log 等除錯語句。semi 規則要求每個語句結尾必須有分號,違反這個規則會產生錯誤。

執行 ESLint

設定好之後,你可以用以下指令來檢查程式碼:

npx eslint .

這會檢查當前目錄及子目錄中的所有 JavaScript 檔案。如果只想檢查特定檔案或目錄,可以明確指定:

npx eslint src/

ESLint 會輸出所有發現的問題,包括檔案位置、行號、問題描述,以及對應的規則名稱。輸出結果清晰易讀,你可以快速定位到需要修正的地方。

更方便的是,許多問題 ESLint 可以自動修復。加上 --fix 參數:

npx eslint . --fix

ESLint 就會自動修正那些可以安全自動處理的問題,比如調整縮排、加上缺少的分號、統一引號風格等等。這對於清理 AI 生成的程式碼特別有用——你可以快速讓程式碼符合專案規範,而不需要手動一行一行調整。

常用規則配置解析

理解規則的嚴重程度

ESLint 的每條規則都可以設定三種嚴重程度:

• 'off' 或 0:完全關閉這條規則
• 'warn' 或 1:違反規則時顯示警告,但不會導致程式檢查失敗
• 'error' 或 2:違反規則時顯示錯誤,會導致檢查失敗

選擇適當的嚴重程度很重要。對於可能導致 bug 的問題,應該設為錯誤等級,強制修正。對於風格相關或次要的問題,可以設為警告等級,提醒但不強制。而對於某些在特定情境下不適用的規則,就可以關閉它。

新手 Vibe Coder 應該注意的重要規則

以下是一些對新手特別重要的規則,它們能幫你避免常見的錯誤:

no-undef 檢查未定義的變數使用。這能防止你因為變數名拼錯或忘記宣告而產生的錯誤。當你從 AI 複製程式碼時,有時可能會缺少某些變數的宣告,這條規則能幫你抓出來。

no-unused-vars 找出宣告但未使用的變數。這能幫你清理程式碼,移除不必要的變數,讓程式更簡潔。在 Vibe Coding 時,你可能試過幾種不同的實作方式,留下了一些用不到的變數,這條規則能提醒你清理它們。

eqeqeq 強制使用嚴格相等運算子(=== 和 !==)而非寬鬆相等(== 和 !=)。JavaScript 的類型轉換規則很複雜,使用嚴格相等能避免許多意外的行為。這是一個非常重要的最佳實踐。

no-var 禁止使用 var 宣告變數,強制使用 let 或 const。現代 JavaScript 應該避免使用 var,因為它的作用域規則容易造成混淆。AI 有時會生成使用 var 的舊式程式碼,這條規則能幫你現代化它。

prefer-const 建議對不會重新賦值的變數使用 const。這讓程式碼的意圖更清楚——你一眼就能看出哪些變數是不變的,哪些可能會改變。這也能預防意外修改變數的錯誤。

no-console 通常設為警告或關閉。在開發時使用 console.log 很正常,但在生產環境的程式碼中最好移除它們。你可以在開發時關閉這條規則,在準備發布時再開啟。

程式碼風格規則

除了預防錯誤,ESLint 也能統一程式碼風格。以下是一些常用的風格規則:

規則名稱	說明	建議設定
indent	控制縮排空格數	['error', 2] 使用 2 個空格
quotes	統一引號風格	['error', 'single'] 使用單引號
semi	要求或禁止分號	['error', 'always'] 總是使用分號
comma-dangle	尾隨逗號	['error', 'always-multiline']
arrow-spacing	箭頭函數間距	['error', { before: true, after: true }]
object-curly-spacing	物件大括號內的空格	['error', 'always']

這些規則沒有絕對的對錯,重點是在整個專案中保持一致。選擇一種你喜歡的風格,然後讓 ESLint 幫你強制執行。

針對 React/Vue 的特殊規則

如果你在用 React 或 Vue 進行 Vibe Coding,還有一些框架特定的規則需要注意。這些規則通常來自專門的 ESLint 插件。

對於 React,eslint-plugin-react 提供了許多有用的規則:

• react/jsx-uses-react 和 react/jsx-uses-vars:確保 React 相關的導入和變數被正確識別為已使用
• react/prop-types:檢查元件的 prop 類型定義(如果不用 TypeScript 的話)
• react/jsx-key:確保列表渲染時每個元素都有 key 屬性
• react-hooks/rules-of-hooks:確保 Hooks 的使用符合規則
• react-hooks/exhaustive-deps:檢查 useEffect 等 Hooks 的依賴陣列是否完整

對於 Vue,eslint-plugin-vue 提供了類似的功能:

• vue/multi-word-component-names:要求元件名稱使用多個單字,避免與原生 HTML 元素衝突
• vue/no-unused-components:找出註冊但未使用的元件
• vue/require-v-for-key:確保 v-for 迴圈有 key 綁定
• vue/no-mutating-props:防止直接修改 props

這些框架特定的規則對於保持應用程式的穩定性和效能非常重要。

進階技巧:讓 ESLint 更好用

與編輯器整合

ESLint 最強大的用法是與你的編輯器整合。這樣你在寫程式碼的當下就能看到問題,而不是等到執行檢查時才發現。

如果你用 VS Code(目前最受 Vibe Coder 歡迎的編輯器之一),只需要安裝 ESLint 擴充功能。安裝後,它會自動讀取專案的 ESLint 設定,並在你寫程式碼時即時顯示警告和錯誤。有問題的程式碼會被標示底線,滑鼠移過去就能看到詳細的說明。

更棒的是,VS Code 可以在你存檔時自動執行 --fix,修正所有可以自動處理的問題。只需要在 VS Code 的設定檔中加入:

{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
}

這樣每次按下儲存,ESLint 就會自動整理你的程式碼。對於從 AI 貼上大段程式碼後快速清理格式特別有用。

忽略特定檔案或程式碼

有時候你可能想讓 ESLint 跳過某些檔案。比如第三方函式庫、自動生成的檔案、或是一些測試用的臨時程式碼。你可以建立 .eslintignore 檔案來指定要忽略的內容:

node_modules/
dist/
build/
*.min.js

這個語法跟 .gitignore 很類似。你也可以在程式碼中用註解來暫時停用某些規則:

// eslint-disable-next-line no-console
console.log('這行不會被檢查');

/* eslint-disable */
// 這個區塊內的所有程式碼都不會被檢查
function legacyCode() {
  var x = 1; // 即使用了 var 也不會報錯
}
/* eslint-enable */

但要謹慎使用這些忽略機制。過度使用會削弱 ESLint 的效果,讓它失去原本的保護作用。只有在確實有充分理由時才使用。

使用共享配置

與其從零開始設定所有規則,更常見的做法是使用社群維護的共享配置。這些配置是由經驗豐富的開發者精心調校的規則集,能讓你快速獲得一套完善的檢查規則。

一些熱門的共享配置包括:

Airbnb Style Guide 是最受歡迎的 JavaScript 風格指南之一。它的規則相對嚴格,但廣受認可。如果你不確定該採用什麼風格,Airbnb 是一個很好的起點。

Standard 提供了一套「無須配置」的規則集。它的理念是減少選擇的負擔,讓你專注在寫程式碼上。規則相對寬鬆,適合快速開發。

Google Style Guide 是 Google 內部使用的風格指南的開源版本。它在嚴格度上介於 Airbnb 和 Standard 之間。

使用這些共享配置很簡單,只需要安裝對應的套件並在設定檔中引用即可。這能讓你的程式碼符合業界標準,也讓其他開發者更容易理解你的程式碼。

在持續整合(CI)中使用 ESLint

如果你的專案有使用 Git 和持續整合服務(如 GitHub Actions),你可以設定在每次推送程式碼時自動執行 ESLint 檢查。這確保了所有進入專案的程式碼都符合標準。

在 package.json 中加入 script:

{
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix"
  }
}

然後在 CI 設定中執行 npm run lint。如果檢查失敗,整個 CI 流程就會被標記為失敗,防止有問題的程式碼被合併。

這種做法在團隊協作時特別有用,但即使你是單人開發,它也能作為最後一道防線,確保你提交的程式碼品質。

ESLint 的限制與替代方案

ESLint 的能力邊界

雖然 ESLint 非常強大,但它也有其限制。理解這些限制能幫你更合理地使用它,也能讓你知道什麼時候需要其他工具。

ESLint 主要關注的是程式碼的靜態分析——它檢查程式碼的結構和寫法,但不會實際執行程式碼。這意味著它能抓出許多問題,但對於需要執行時資訊的問題(比如執行效能、記憶體洩漏等)就無能為力了。

ESLint 也無法深入理解程式碼的業務邏輯。它能告訴你某個變數沒有被使用,但無法判斷你的演算法邏輯是否正確,或是使用者體驗是否良好。這些需要人類開發者的判斷。

對於類型檢查,ESLint 的能力有限。雖然它有一些基本的類型相關規則,但如果你需要嚴格的類型系統,TypeScript 會是更好的選擇。不過好消息是,ESLint 和 TypeScript 可以很好地配合使用。

TypeScript + ESLint

如果你在 Vibe Coding 時使用 TypeScript,你應該同時使用 TypeScript 編譯器和 ESLint。它們各有所長:TypeScript 負責類型檢查,ESLint 負責程式碼風格和最佳實踐。

@typescript-eslint/parser 和 @typescript-eslint/eslint-plugin 讓 ESLint 能夠理解 TypeScript 語法,並提供了一系列 TypeScript 專用的規則。設定也很簡單,安裝精靈會在你選擇 TypeScript 時自動處理這些。

這樣的組合給你提供了最全面的程式碼檢查——類型安全加上程式碼品質保證。

Prettier:程式碼格式化的好夥伴

Prettier 是另一個在 Vibe Coding 時很有用的工具。與 ESLint 不同,Prettier 專注於程式碼格式化,而且是「opinionated」的——它有一套固定的格式規則,很少讓你客製化。

Prettier 可以和 ESLint 一起使用。一般的做法是讓 Prettier 處理所有格式相關的問題(縮排、換行、空格等),讓 ESLint 專注於程式碼品質問題。eslint-config-prettier 這個套件可以關閉 ESLint 中與 Prettier 衝突的格式規則。

這樣的分工很明確:Prettier 讓程式碼看起來一致,ESLint 讓程式碼運作正確。兩者搭配使用效果最好。

實戰案例:清理 AI 生成的程式碼

場景設定

讓我們用一個實際例子來展示 ESLint 如何幫助 Vibe Coder。假設你用 AI 生成了一個簡單的待辦事項應用,但程式碼有些混亂:

var todos = []

function addTodo(text) {
  var newTodo = {
    id: Date.now(),
    text: text,
    completed: false
  }
  todos.push(newTodo)
  console.log("Added todo:", newTodo)
}

function completeTodo(id) {
  for (var i = 0; i < todos.length; i++) {
    if (todos[i].id == id) {
      todos[i].completed = true
    }
  }
}

var unusedVariable = "這個變數沒用到"

這段程式碼能夠運作,但有不少問題。讓我們看看 ESLint 會指出什麼。

ESLint 發現的問題

執行 npx eslint 後,你會看到類似這樣的輸出:

1:1   error  Unexpected var, use let or const instead  no-var
1:13  error  Missing semicolon                         semi
13:1  error  Unexpected var, use let or const instead  no-var
14:3  error  Unexpected var, use let or const instead  no-var
15:8  error  Expected '===' and instead saw '=='       eqeqeq
22:1  error  'unusedVariable' is assigned but never    no-unused-vars
              used
8:3   warn   Unexpected console statement              no-console

ESLint 清楚地列出了所有問題:使用了 var 而非 let/const,缺少分號,使用了寬鬆相等,有未使用的變數,還有 console 語句。

自動修復

執行 npx eslint --fix 後,許多問題會被自動修正:

const todos = [];

function addTodo(text) {
  const newTodo = {
    id: Date.now(),
    text: text,
    completed: false
  };
  todos.push(newTodo);
  console.log("Added todo:", newTodo);
}

function completeTodo(id) {
  for (let i = 0; i < todos.length; i++) {
    if (todos[i].id === id) {
      todos[i].completed = true;
    }
  }
}

注意到變化了嗎?var 都變成了 const 或 let,分號被加上了,== 變成了 ===。未使用的變數被移除了。Console 語句被保留(因為在開發時很有用),但如果你設定為錯誤等級,也會被標出來。

這就是 ESLint 的力量——它能快速把 AI 生成的「能用」的程式碼轉變成「好」的程式碼。

2026 年的 ESLint 生態系統

ESLint 9.0 的重大變化

2024 年發布的 ESLint 9.0 帶來了一些重大改變,到了 2026 年這些已經成為標準。最大的變化是新的「扁平配置」(Flat Config)系統,取代了舊的 .eslintrc 格式。

新的配置格式使用 eslint.config.js,採用 JavaScript 模組語法,更加靈活和強大。它允許更細緻的配置控制,也更容易與現代 JavaScript 工具鏈整合。

雖然有學習曲線,但新格式解決了舊系統的許多問題。當你現在開始使用 ESLint,你會直接接觸到這個新系統,這其實是件好事——你不需要學習舊的方式再重新學習新的。

與 AI 編程工具的整合

2026 年的 AI 編程助手已經深度整合了 ESLint。許多 AI 工具在生成程式碼時會參考你專案的 ESLint 配置,嘗試生成符合規範的程式碼。這大大減少了後續需要修正的問題。

一些先進的 AI 編輯器甚至能在你和 AI 對話時即時顯示 ESLint 警告,讓你在接受程式碼前就知道可能的問題。這種緊密整合讓 Vibe Coding 的體驗更加順暢。

不過,即使 AI 生成的程式碼已經相當乾淨,獨立執行 ESLint 檢查仍然是必要的。AI 也可能犯錯,而且不同的 AI 助手可能有不同的「習慣」。ESLint 提供了統一的品質標準。

社群資源與學習路徑

ESLint 有龐大的社群和豐富的資源。官方文檔非常詳細,每條規則都有清楚的說明和範例。當你遇到不理解的規則時,查閱文檔通常能得到答案。

GitHub 上有數千個 ESLint 插件和共享配置,涵蓋各種框架、函式庫和使用情境。無論你在做什麼類型的專案,很可能有人已經為你準備好了適合的 ESLint 配置。

Stack Overflow 和各種開發者論壇也有大量關於 ESLint 的討論。如果你遇到特殊情況不知道如何配置,搜尋一下通常能找到別人的解決方案。

對於想深入學習的開發者,跟隨一些知名開發者和技術部落格也很有幫助。他們經常分享 ESLint 的使用技巧和最佳實踐。

常見問題解答

ESLint 會讓開發速度變慢嗎?

這是新手 Vibe Coder 最常問的問題。短期來看,剛開始使用 ESLint 時確實需要一些調整時間。你需要修正一些以前沒注意到的問題,可能會覺得「麻煩」。

但從長期來看,ESLint 實際上會加快開發速度。它能在早期就發現問題,避免你在除錯上浪費時間。它能保持程式碼一致性,讓你在回來看舊程式碼時更容易理解。最重要的是,它能讓你從 AI 生成的程式碼中更有信心地學習——你知道 ESLint 會幫你把關品質。

而且,隨著與編輯器整合和自動修復功能的使用,很多檢查和修正都是自動發生的,幾乎不會影響你的工作流程。

我應該使用哪個共享配置?

這取決於你的專案類型和個人偏好。如果你在學習階段,建議從 ESLint 推薦配置開始,它包含了最基本和重要的規則。

如果你想採用業界標準,Airbnb 配置是很好的選擇,它被廣泛使用且文檔完善。如果你喜歡簡單快速,Standard 配置讓你不用做太多選擇。

重點不是選擇「最好」的配置,而是選擇一個適合你的,然後堅持使用。一致性比完美更重要。

ESLint 的規則太嚴格怎麼辦?

如果你覺得某些規則太嚴格或不適合你的專案,完全可以調整它們。ESLint 的設計就是為了讓你客製化。

但在關閉規則之前,建議先理解為什麼這個規則存在。查閱文檔,了解它要預防什麼問題。很多時候,看似「麻煩」的規則實際上是在保護你避免常見錯誤。

如果經過思考後仍然覺得某個規則不適合,那就調整它。可以把它從錯誤降級為警告,或是完全關閉。記住,工具是為你服務的,不是你為工具服務。

在團隊中推行 ESLint 的建議?

如果你想在團隊中推行 ESLint,建議採取漸進的方式。不要一開始就開啟所有規則,這會讓團隊成員感到挫折。

可以先從最基本的規則開始,特別是那些能防止明顯錯誤的規則。等大家習慣後,再逐步加入更多規則。

重要的是要讓團隊理解 ESLint 的價值,而不是把它當成一個「檢查作業」的工具。強調它如何幫助大家寫出更好的程式碼,如何減少 bug,如何讓程式碼審查更順暢。

同時,確保團隊對配置有共識。可以開會討論有爭議的規則,達成一致後再加入設定檔。這樣每個人都會更願意遵守。

結語:擁抱工具,專注創造

在 2026 年的 Vibe Coding 時代,我們擁有前所未有的生產力工具。AI 可以幫我們快速生成程式碼,各種框架和函式庫讓複雜的功能變得簡單。但隨著開發速度的提升,保持程式碼品質變得更加重要。

ESLint 不是用來限制你的創造力,而是用來解放它。當你知道有工具幫你把關基本的程式碼品質,你就可以更專注在解決真正的問題上,更大膽地嘗試新想法。你不需要擔心是否忘記加分號,是否用錯了變數名,是否違反了最佳實踐——ESLint 會提醒你。

對於新手 Vibe Coder 來說,ESLint 更是一個無聲的導師。每一次它指出問題,都是一次學習機會。你會逐漸理解什麼是好的程式碼,什麼是應該避免的模式。隨著時間推移,你會發現自己寫出的程式碼越來越乾淨,需要修正的問題越來越少。

開始使用 ESLint 很簡單,只需要一個指令。但它帶來的好處會持續整個開發旅程。無論你是在快速原型開發,還是在構建生產級應用,ESLint 都能成為你可靠的夥伴。

所以,如果你還沒開始使用 ESLint,現在就是最好的時機。打開終端,執行 npm init @eslint/config@latest,開始你的程式碼品質之旅。你的未來自己會感謝現在的你做出這個決定。