วิธีตั้งค่า Linter สำหรับโค้ดที่สร้างโดย AI

เอเจนต์ AI สามารถสร้างโค้ดที่คอมไพล์ผ่านได้

แต่นั่นยังไม่ใช่มาตรฐานที่คุณต้องการ มาตรฐานคือโค้ดที่ไม่ import สิ่งที่ไม่เคยถูกใช้ ไม่ any-cast เพื่อเลี่ยงออกจากระบบ type ไม่เพิกเฉยต่อค่า error ที่ส่งกลับมา และไม่ฮาร์ดโค้ดข้อมูลรับรองที่ gosec ควรจับได้ก่อนถึงขั้นรีวิว

โมเดล AI เทรนจากคำตอบเก่าๆ บน Stack Overflow และส่งออกแพตเทิร์นที่มันเรียนรู้มาจากตรงนั้น รวมถึง API ที่เลิกใช้แล้ว การไม่ใส่ type annotation และฟังก์ชันที่ถูกต้องในทางเทคนิคแต่ใหญ่เกินกว่าจะรีวิวได้อย่างปลอดภัย คุณจำเป็นต้องมี linter อยู่ในลูป ไม่ใช่ในฐานะคำแนะนำ แต่ในฐานะด่าน

คู่มือนี้ครอบคลุมการตั้งค่าสำหรับสามอีโคซิสเต็ม (Python ด้วย Ruff, TypeScript/JavaScript ด้วย ESLint v10 flat config และ Go ด้วย golangci-lint) พร้อมกฎที่ปรับจูนมาเฉพาะเจาะจงสำหรับแพตเทิร์นความผิดพลาดที่ AI สร้างขึ้น จากนั้นจะครอบคลุมวิธีทำให้ด่านนี้เลี่ยงผ่านได้ยากขึ้นมาก เพื่อให้เอเจนต์ไม่สามารถข้าม hook ในเครื่องด้วย --no-verify ได้ง่ายๆ โดยไม่มีอีกชั้นหนึ่งคอยจับ

การตั้งค่าแบ่งเป็นชั้นๆ คือ การ lint ระดับ IDE จับปัญหาในบรรทัดขณะที่เอเจนต์กำลังเขียน, pre-commit hook จับทุกอย่างที่ไปถึงขั้นพยายาม commit และ CI จับทุกอย่างที่ผ่านในเครื่องมาได้ แต่ละชั้นเป็นอิสระต่อกัน และคุณสามารถเลือกส่วนของภาษาที่ตรงกับสแตกของคุณได้ ชั้นบังคับใช้ทำงานเหมือนกันไม่ว่าคุณจะ lint ภาษาไหน

TL;DR (สรุปย่อ)

• Ruff (Python), ESLint v10 (TS/JS) และ golangci-lint (Go) แต่ละตัวมีกฎเฉพาะที่จับความผิดพลาดที่พบบ่อยที่สุดของ AI
• คอนฟิกด้านล่างมีคำอธิบายกำกับ ทุกกฎมีอยู่ด้วยเหตุผลของมัน
• Lefthook จัดการด่าน pre-commit; afterFileEdit hook ของ Cursor รัน lint ในบรรทัด
• ชั้นบังคับใช้สี่ชั้นทำให้เอเจนต์ AI ข้ามด่านด้วย --no-verify ได้ยากขึ้นมาก
• CI คือแนวรับสุดท้าย เอเจนต์ไม่สามารถส่ง --no-verify ไปยัง GitHub Actions ได้

วิธีคอนฟิก Ruff สำหรับโค้ด Python ที่สร้างโดย AI

Ruff คือ linter Python ที่เหมาะสำหรับโค้ดเบสที่ใช้ AI ช่วยเขียน มันเร็วพอที่จะรันทุกครั้งที่บันทึกไฟล์โดยไม่ทำให้อะไรช้าลง มันครอบคลุมทั้ง style และข้อผิดพลาดเชิงตรรกะจริง และมันมาพร้อมพฤติกรรมการจัดรูปแบบ (แทนที่ Black) ในไบนารีเดียวกัน กฎด้านล่างมุ่งเป้าไปที่แพตเทิร์นความผิดพลาดเฉพาะที่โมเดล AI สร้างขึ้นบ่อยที่สุดใน Python

การติดตั้ง Ruff

pip install ruff

# or via uv (faster for new projects):
uv add --dev ruff

เท่านั้นเอง ไม่มีอีโคซิสเต็มของปลั๊กอิน ไม่มีการต่อรอง peer dependency

คอนฟิก pyproject.toml

[tool.ruff]
line-length = 88
target-version = "py311"

[tool.ruff.lint]
select = [
  "E",   # pycodestyle — style consistency
  "F",   # pyflakes — catches unused imports (the most common AI artifact)
  "I",   # isort — import ordering (AI frequently reorders imports incorrectly)
  "N",   # pep8-naming — naming conventions
  "UP",  # pyupgrade — flags deprecated APIs (AI trains on old Stack Overflow answers)
  "S",   # flake8-bandit — security rules: subprocess.shell=True, eval(), hardcoded creds
  "ANN", # type annotation enforcement (AI frequently omits return type annotations)
]
ignore = []  # intentional: do not add sweeping ignores in AI-assisted codebases

[tool.ruff.lint.per-file-ignores]
"tests/**" = ["S101"]  # allow assert in tests

กฎ F คุ้มค่าทันที โค้ด AI สร้างคำสั่ง import สำหรับแพ็กเกจที่สุดท้ายแล้วไม่ได้ใช้ และ F401 (unused import) จับได้ทุกตัว กฎ UP จับการเรียกใช้แพตเทิร์น API ที่เลิกใช้แล้วซึ่ง AI เรียนรู้มาจากคำตอบ Python ก่อนเวอร์ชัน 3.10; เพียงแค่ UP006 และ UP007 ก็ flag แพตเทิร์น type-checking ที่ไม่จำเป็นได้นับสิบ กฎ S (Bandit) จับความผิดพลาดด้านความปลอดภัย: สตริงฮาร์ดโค้ดที่ดูเหมือนข้อมูลรับรอง (S105/S106), การ inject ผ่าน shell ด้วย subprocess(shell=True) (S603/S607), การเลือกใช้การเข้ารหัสที่อ่อนแอ (S324)

การใส่ ignore = [] เป็นการตั้งใจ ทุกข้อยกเว้นที่คุณเพิ่มลงในรายการนี้คือกลุ่มความผิดพลาดของ AI ที่คุณตัดสินใจอนุญาตให้เกิดขึ้น

การรัน Ruff

ruff check .           # lint only — see what's wrong
ruff check --fix .     # auto-fix safe violations (imports, formatting)
ruff format .          # format the codebase (replaces Black)

--fix ใช้การแก้ไขที่ปลอดภัยของ Ruff ตามค่าเริ่มต้น เช่น การลบ import ที่ไม่ได้ใช้ หรือการจัดรูปแบบและแก้ไข lint แบบตรงไปตรงมา Ruff ยังมีการแก้ไขแบบไม่ปลอดภัยอยู่ด้วย แต่ต้องเลือกเปิดใช้อย่างชัดเจนและควรตรวจสอบอย่างระมัดระวังมากขึ้น ตรวจสอบทุกอย่างที่ Ruff แก้ไขให้อย่างปลอดภัยไม่ได้ด้วยตัวเอง

วิธีคอนฟิก ESLint v10 สำหรับโค้ด TypeScript และ JavaScript ที่สร้างโดย AI

ESLint v10 ยกเลิกรูปแบบคอนฟิกเดิม .eslintrc.* ไปแล้ว ตอนนี้ทุกอย่างเป็น flat config ใน eslint.config.mjs หากคุณเจอบทช่วยสอนที่ใช้ .eslintrc.json หรือ .eslintrc.js แสดงว่ามันมุ่งเป้าไปที่ ESLint v8 หรือ v9 ซึ่งไวยากรณ์ต่างกัน ใช้แบบที่อยู่ด้านล่าง

กฎ @typescript-eslint ในคอนฟิกนี้มุ่งเป้าไปที่รูปแบบความผิดพลาดเฉพาะที่เกิดขึ้นซ้ำๆ ใน TypeScript ที่สร้างโดย AI: การใช้ any เป็นทางหนีทีไล่, ฟังก์ชันก้อนใหญ่ที่รีวิวได้ยาก และค่าฮาร์ดโค้ดที่ควรเป็นค่าคงที่

การติดตั้ง ESLint v10 พร้อมการรองรับ TypeScript

npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

# or with pnpm:
pnpm add -D eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

ESLint v10.5.0 เป็นเวอร์ชันปัจจุบัน ณ เดือนมิถุนายน 2026 แพ็กเกจ @typescript-eslint ควรเข้ากันได้กับเวอร์ชัน TypeScript ของคุณ ตรวจสอบ README ของมันเพื่อดูตารางความเข้ากันได้

คอนฟิก eslint.config.mjs

import tseslint from '@typescript-eslint/eslint-plugin';
import tsParser from '@typescript-eslint/parser';

export default [
  {
    files: ['**/*.ts', '**/*.tsx'],
    languageOptions: {
      parser: tsParser,
      parserOptions: { project: './tsconfig.json' },
    },
    plugins: { '@typescript-eslint': tseslint },
    rules: {
      // AI defaults to `any` to bypass the type system — this blocks it
      '@typescript-eslint/no-explicit-any': 'error',

      // AI generates variables it declares but never uses
      '@typescript-eslint/no-unused-vars': 'error',

      // AI writes functions that work but are too long to review safely
      'max-lines-per-function': ['error', { max: 50 }],

      // AI overloads function signatures; this forces decomposition
      'max-params': ['error', 2],

      // AI hardcodes values that should be named constants
      'no-magic-numbers': ['error', { ignore: [0, 1, -1] }],

      // AI writes files that are too large to reason about in a single review
      'max-lines': ['error', { max: 250 }],

      // AI leaves console.log debugging in production code
      'no-console': 'warn',
    },
  },
];

กฎ max-lines-per-function: 50 คือสิ่งที่เข้มข้นที่สุดในคอนฟิกนี้ คุณจะชนมันตลอดเวลาในการรันครั้งแรกในโค้ดเบสที่ใช้ AI ช่วยเขียน นั่นแหละคือจุดประสงค์ คุณควรจะชนมัน ฟังก์ชันที่เกิน 50 บรรทัดเป็นสิ่งแรกที่กลายเป็นสิ่งที่ทำความเข้าใจไม่ได้เมื่อคุณกำลังรีวิวผลลัพธ์ของ AI ในปริมาณมาก

กฎ max-params: 2 บังคับให้แตกย่อย โมเดล AI เรียนรู้จากโค้ดเบสที่ฟังก์ชันรับห้าอาร์กิวเมนต์เป็นเรื่องปกติ; กฎนี้ผลักกลับโดยกำหนดให้เอเจนต์ใช้ options object ซึ่งเป็นการออกแบบที่ดีกว่าและอ่านง่ายกว่า

การรัน ESLint

npx eslint .                       # lint
npx eslint . --fix                 # auto-fix safe issues
npx eslint . --max-warnings 0      # CI mode — treats warnings as errors

ใช้ --max-warnings 0 ในขั้นตอน CI ของคุณ มันยกระดับ warning ของ no-console จาก "บันทึกไว้ในทางเทคนิค" ให้กลายเป็น "บล็อกจริง"

เสริม: กฎที่เข้มงวดขึ้นสำหรับไฟล์ที่สร้างโดย AI

หากทีมของคุณใช้รูปแบบการตั้งชื่อไฟล์เพื่อทำเครื่องหมายโค้ดที่สร้างโดย AI (*.ai.ts, *-generated.ts หรือคล้ายกัน) คุณสามารถใช้กฎที่เข้มงวดขึ้นกับไฟล์เหล่านั้นโดยเฉพาะได้:

// Add to eslint.config.mjs after the main config object
{
  files: ['**/*.ai.ts', '**/*.ai.tsx', '**/*-generated.ts'],
  rules: {
    'max-lines': ['error', { max: 100 }],  // tighter file ceiling
    'complexity': ['error', 5],             // McCabe complexity limit
  },
}

วิธีคอนฟิก golangci-lint สำหรับโค้ด Go ที่สร้างโดย AI

golangci-lint คือตัวรัน multi-linter มาตรฐานสำหรับ Go มันมาพร้อม gosec, errcheck, staticcheck และ linter อื่นๆ อีก 40+ ตัวที่คอนฟิกได้จากไฟล์ YAML เพียงไฟล์เดียว สำหรับโค้ด Go ที่สร้างโดย AI กฎที่สำคัญคือการตรวจสอบค่า error ที่ส่งกลับและการตรวจจับแพตเทิร์นด้านความปลอดภัย: สองหมวดความผิดพลาดที่โมเดล AI พลาดบ่อยที่สุดใน Go

การติดตั้ง golangci-lint

# Official binary installer:
curl -sSfL https://golangci-lint.run/install.sh | sh -s -- -b "$(go env GOPATH)/bin" v2.12.2

# or via Homebrew:
brew install golangci-lint

คอนฟิก .golangci.yml

version: "2"

linters:
  enable:
    - gosec        # security: flags hardcoded creds (G101), file path injection (G304), weak crypto (G401)
    - unused       # flags unused vars and functions — a common AI artifact in Go
    - errcheck     # AI frequently ignores error returns — this blocks it
    - govet        # catches subtle correctness bugs AI introduces
    - staticcheck  # comprehensive static analysis
    - revive       # style: catches non-idiomatic Go patterns AI writes
    - misspell     # AI occasionally misspells in comments and string literals

  settings:
    gosec:
      severity: medium
      confidence: medium
    errcheck:
      check-type-assertions: true  # check `val, ok := x.(Type)` patterns
      check-blank: true            # catch `_ = someErr` error suppression

run:
  timeout: 3m
  issues-exit-code: 1

แพตเทิร์นการจัดการ error ของ Go ชัดเจนโดยการออกแบบ: ทุกฟังก์ชันที่อาจล้มเหลวจะส่งค่า error กลับมา โมเดล AI เข้าใจเรื่องนี้แต่ให้น้ำหนักน้อยเกินไป; พวกมันจะละเว้นการตรวจสอบ error ในเส้นทางโค้ดที่ไม่สำคัญ errcheck ทำให้การละเว้นนั้นกลายเป็นความล้มเหลวด้าน lint

gosec คือ linter ด้านความปลอดภัย สำหรับโค้ด AI มันจับแพตเทิร์นที่ AI หยิบมาจากบทช่วยสอน Go ก่อนปี 2020: การสร้างเลขสุ่มที่ไม่ปลอดภัย (G404), ฟังก์ชันแฮชที่ไม่ปลอดภัย (G401), ปัญหาสิทธิ์ไฟล์ (G306) เหล่านี้คือความผิดพลาดที่คุณจับไม่ได้ในการรีวิวโค้ดเพราะมันดูเป็นไวยากรณ์ปกติ

การรัน golangci-lint

golangci-lint run ./...            # lint all packages
golangci-lint run --fix ./...      # auto-fix where possible

วิธีเชื่อม Linter เข้ากับ Pre-commit Hook

pre-commit hook รัน lint ก่อนทุก git commit และบล็อก commit หาก lint ล้มเหลว นี่หมายความว่าเอเจนต์ AI ไม่สามารถ commit โค้ดที่ไม่ผ่านกฎที่คุณคอนฟิกไว้ได้ มันต้องแก้ไขการละเมิดเสียก่อน

Lefthook เป็นตัวเลือกที่แนะนำ มันใช้ได้ข้ามแพลตฟอร์ม รวดเร็ว และมีรูปแบบคอนฟิกที่ทำงานร่วมกับการบังคับใช้กับเอเจนต์ AI ได้โดยเฉพาะ (กล่าวถึงในส่วนถัดไป)

Lefthook

npm install --save-dev lefthook
npx lefthook install

lefthook.yml:

pre-commit:
  parallel: true
  commands:
    lint-python:
      glob: "*.py"
      run: ruff check {staged_files} --fix
    lint-js-ts:
      glob: "*.{js,ts,tsx}"
      run: npx eslint {staged_files} --fix
    lint-go:
      glob: "*.go"
      run: golangci-lint run {staged_files}
  fail_text: |
    Lint failed. For AI Agents: fix all lint violations before committing.
    Do not use --no-verify to bypass this gate.

ข้อความ fail_text จะถูกอ่านโดยเอเจนต์ AI เมื่อ commit ล้มเหลว แพตเทิร์นนี้มีบันทึกไว้ใน บทความของ Liam Bigelow เรื่องการบังคับใช้ lint ด้วย Lefthook สำหรับ Claude Codeเพียงแค่นี้จะไม่สามารถหยุดเอเจนต์ที่ตั้งใจจริงได้ แต่มันให้คำสั่งถัดไปที่ถูกต้องแก่มัน ("แก้การละเมิด lint") แทนที่จะปล่อยให้มันคาดเดาวิธีเลี่ยงเอาเอง

ทางเลือก: pre-commit (สำหรับการตั้งค่าที่ใช้ Python อย่างเดียว)

หากคุณอยู่บนสแตกที่ใช้ Python อย่างเดียวและชอบใช้เฟรมเวิร์ก pre-commit:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.15.17
    hooks:
      - id: ruff-check
        args: [--fix]
      - id: ruff-format

Cursor: การ Lint ในบรรทัดผ่าน afterFileEdit Hook

หากคุณใช้ Cursor คุณสามารถสั่งให้รัน lint ทันทีเมื่อ AI แก้ไขไฟล์ ก่อนที่มันจะพยายาม commit ด้วยซ้ำ สร้าง .cursor/hooks.json ที่ root ของโปรเจกต์คุณ:

{
  "hooks": {
    "afterFileEdit": [
      {
        "match": "*.py",
        "run": "ruff check {file} --fix"
      },
      {
        "match": "*.{ts,tsx,js}",
        "run": "npx eslint {file} --fix"
      },
      {
        "match": "*.go",
        "run": "golangci-lint run {file}"
      }
    ]
  }
}

สิ่งนี้จะทำงานทุกครั้งที่ AI ของ Cursor แก้ไขไฟล์ เอเจนต์จะได้รับฟีดแบ็กจาก lint ในบรรทัด ก่อนที่มันจะถือว่างานเสร็จสิ้น ดังนั้นการละเมิดส่วนใหญ่จึงถูกแก้ไขก่อนที่จะไปถึงด่าน pre-commit

วิธีทำให้ด่านนี้ถูกเอเจนต์ AI เลี่ยงผ่านได้ยากขึ้น

ชั้นบังคับใช้สี่ชั้นทำให้เอเจนต์ AI ข้ามด่าน pre-commit ด้วย --no-verify ได้ยากขึ้นมาก แต่ละชั้นมุ่งเป้าไปที่พื้นผิวการโจมตีที่ต่างกัน: นโยบายใน CLAUDE.md, กฎ deny ของ Claude Code, hook แบบ PreToolUse และแนวรับ CI มองว่ามันเป็นการตั้งค่าแบบหลายชั้น ไม่ใช่การรับประกันสี่ชิ้นที่เป็นอิสระต่อกัน

บางครั้งเอเจนต์ AI ส่ง --no-verify ไปยัง git commit เพื่อข้าม pre-commit hook เมื่อ lint ล้มเหลวและเอเจนต์ตัดสินใจว่าความล้มเหลวนั้น "ไม่เกี่ยวข้องกับการเปลี่ยนแปลงของมัน" การตัดสินใจนั้นไม่ได้ผิดเสมอไป แต่คุณไม่ควรปล่อยให้เอเจนต์ตัดสินใจเองฝ่ายเดียว จุดประสงค์ทั้งหมดของด่าน lint คือมนุษย์เป็นผู้กำหนดนโยบาย; งานของเอเจนต์คือทำให้เป็นไปตามนั้น ไม่ใช่หาทางอ้อมมัน

นี่คือแต่ละชั้นและพื้นผิวการโจมตีที่มันครอบคลุม

ชั้นที่ 1: บันทึกนโยบายไว้ใน CLAUDE.md

## Linting Policy

NEVER use `git commit --no-verify`. All commits must pass pre-commit hooks.
Pre-commit hooks run lint. Fix lint violations before committing. Do not treat
lint failures as unrelated to your changes — they may not be, and you don't get
to decide that.

Claude Code อ่าน CLAUDE.md ตอนเริ่มเซสชัน นี่ไม่ใช่การบังคับใช้; เอเจนต์ยังสามารถพยายามเลี่ยงได้ แต่มันตัดเส้นทาง "ฉันไม่รู้" ออกไป และกำหนดนโยบายที่ชัดเจนซึ่งเอเจนต์ต้องเลือกที่จะละเมิดอย่างจงใจ ซึ่งมันมีโอกาสทำน้อยกว่าการคาดเดาทางเลี่ยงจากความเงียบ

ชั้นที่ 2: กฎ Deny ของ Claude Code

เพิ่มลงใน .claude/settings.json:

{
  "permissions": {
    "deny": [
      "Bash(git commit --no-verify*)"
    ]
  }
}

สิ่งนี้บล็อกการเรียกใช้อย่างชัดเจน ข้อจำกัดหนึ่งคือ: กฎ deny ใช้การจับคู่แบบ prefix ดังนั้นมันจึงจับได้เฉพาะ --no-verify ที่อยู่ทันทีหลัง commit เอเจนต์ที่สร้างสรรค์มากพออาจจัดโครงสร้างการเรียกให้ต่างออกไปได้ อย่าพึ่งพาสิ่งนี้เพียงอย่างเดียว

ชั้นที่ 3: PreToolUse Hook

ติดตั้งแพ็กเกจ block-no-verify:

npm install --save-dev block-no-verify

จากนั้นคอนฟิกมันเป็น PreToolUse hook ในการตั้งค่าของ Claude Code มันจะทำงานก่อนทุกการเรียกใช้เครื่องมือและตรวจสอบอาร์กิวเมนต์เพื่อหา --no-verify ใน git subcommand ทั้งหก ไม่ใช่แค่ commit มันจะออกด้วยค่าที่ไม่ใช่ศูนย์เพื่อบล็อกการเรียกก่อนที่มันจะถูกประมวลผล

คู่มือที่ pydevtools.com พูดตรงๆ ว่า: "ชั้น hook คือชั้นเดียวที่บังคับใช้กฎได้อย่างน่าเชื่อถือ" ใช้สิ่งนี้ร่วมกับชั้นอื่นๆ; อย่าถือว่า hook ในเครื่องตัวใดเป็นการรับประกันทั้งหมด

ชั้นที่ 4: แนวรับ CI

CI รันบนเซิร์ฟเวอร์ ที่ซึ่งเอเจนต์ไม่มี shell ให้ส่ง flag เข้าไปได้:

# .github/workflows/lint.yml
name: Lint
on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Lint Python
        run: |
          pip install ruff
          ruff check . --output-format github

      - name: Lint JS/TS
        run: npx eslint . --max-warnings 0

      - name: Lint Go
        uses: golangci/golangci-lint-action@v9
        with:
          version: v2.12.2

เอเจนต์ AI ไม่สามารถส่ง --no-verify ไปยัง CI ได้ GitHub Actions รันอย่างเป็นอิสระจากสิ่งที่เอเจนต์ทำในเครื่อง หาก commit ผ่านเข้าไปได้โดยมี lint ที่ล้มเหลว CI จะจับได้ก่อนที่มันจะ merge

นี่คือแนวรับสุดท้าย

โบนัส: ESLint MCP Server

หากคุณใช้ Claude Code มีชั้นเชิงรุกที่ลดความถี่ที่คุณต้องชนด่านลงได้

ESLint MCP server (@eslint/mcp) ผสานรวม ESLint เข้ากับลูปเครื่องมือของเอเจนต์โดยตรง เอเจนต์สามารถสอบถาม ESLint ระหว่างทำงานได้ ก่อนที่มันจะพยายาม commit ติดตั้งแบบ global:

npm install -g @eslint/mcp@latest

เพิ่มลงใน .claude/settings.json:

{
  "mcpServers": {
    "eslint": {
      "command": "npx",
      "args": ["@eslint/mcp@latest"]
    }
  }
}

เมื่อคอนฟิกสิ่งนี้แล้ว เอเจนต์สามารถสอบถาม ESLint ระหว่างทำงานได้ เอเจนต์จะได้รับฟีดแบ็กจาก lint ในบรรทัด และการละเมิดบางส่วนสามารถถูกแก้ไขก่อนที่จะไปถึง hook สิ่งนี้ไม่ได้แทนที่ด่าน แต่ลดสัญญาณรบกวนที่ด่าน

คำถามที่พบบ่อย

ฉันจำเป็นต้องคอนฟิก linter ทั้งสามตัวไหมถ้าฉันทำงานในภาษาเดียว?

ไม่จำเป็น ตั้งค่า linter สำหรับภาษาหลักของคุณและชั้นบังคับใช้ก็พอ หากสแตกของคุณใช้ TypeScript อย่างเดียว ให้คอนฟิก ESLint และข้าม Ruff กับ golangci-lint ไป ส่วนการป้องกันการเลี่ยงผ่านของเอเจนต์ใช้ได้ไม่ว่าคุณจะ lint ภาษาไหน

คอนฟิกเหล่านี้จะทำให้โค้ดเบสที่มีอยู่ของฉันพังในการรันครั้งแรกไหม?

เกือบจะแน่นอน และตั้งใจให้เป็นเช่นนั้น รัน ruff check --fix . หรือ npx eslint . --fix เพื่อแก้ไขการละเมิดที่ปลอดภัยโดยอัตโนมัติก่อน สิ่งที่เหลืออยู่หลังการแก้ไขอัตโนมัติคือรายการที่ต้องรีวิวด้วยตัวเอง: การ cast แบบ no-explicit-any, ฟังก์ชันที่เกิน 50 บรรทัด, การจัดการ error ที่ขาดหายไป ค่อยๆ จัดการสิ่งเหล่านั้นไปทีละขั้น อย่าเพิ่มกฎ ignore เพื่อหลีกเลี่ยงการจัดการกับมัน

Biome เป็นตัวแทนของ ESLint ได้แล้วในตอนนี้ไหม?

Biome v2.5.0 (ปล่อยออกมาเดือนมิถุนายน 2026) สูสีกันในเรื่องการจัดรูปแบบและกฎ lint พื้นฐาน มันเร็วกว่า ESLint และไม่มีภาระการคอนฟิกเลยถ้าคุณติดตั้งผ่าน bun x ultracite@latest init สำหรับทีมที่ต้องการเครื่องมือเดียวและไม่ต้องการความลึกของกฎ @typescript-eslint ทั้งหมด Biome เป็นทางเลือกที่สมเหตุสมผล แต่สำหรับกฎเฉพาะ AI ในคู่มือนี้ (max-params, no-magic-numbers, max-lines-per-function ที่มีเกณฑ์มุ่งเป้า AI) ESLint กับ @typescript-eslint ยังครอบคลุมมากกว่า คุณสามารถรันทั้งคู่ได้: Biome สำหรับการจัดรูปแบบและ lint พื้นฐาน, ESLint สำหรับกฎเฉพาะ AI

จะทำอย่างไรถ้าเอเจนต์ AI ของฉันสร้างการละเมิด lint แบบเดิมซ้ำๆ?

เอเจนต์กำลังหาทางอ้อมกฎแทนที่จะแก้ปัญหาที่ต้นเหตุ สำหรับ no-explicit-any นี่หมายถึงการเพิ่ม type assertion แทนที่จะนิยาม type จริง สำหรับ max-lines-per-function มันหมายถึงการแยกฟังก์ชันช่วยที่ไม่ได้ทำอะไรมีประโยชน์ออกมาแต่ทำให้จำนวนบรรทัดลดลงต่ำกว่าเกณฑ์ ทั้งสองวิธีแก้ไม่ผ่านการรีวิวโค้ด กฎ lint จับอาการได้; ต้นเหตุคือ prompt ของเอเจนต์ ปรับ prompt ให้ระบุข้อจำกัดด้าน type หรือการแตกย่อยที่คาดหวัง; เอเจนต์จะทำตามคำแนะนำโครงสร้างที่ชัดเจนได้น่าเชื่อถือกว่ากฎที่เป็นนัย หากคุณกำลังรันการตั้งค่าเอเจนต์ที่ซับซ้อนกว่านั้น การจำกัดขอบเขตงานให้กับ subagent เฉพาะที่มีข้อจำกัดฝังอยู่ในคำสั่งของมันมักจะยึดได้ดีกว่า prompt เดียวกว้างๆ

ESLint MCP server แทนที่ด่าน pre-commit ได้ไหม?

ไม่ มันลดความถี่ที่เอเจนต์สร้างโค้ดที่ไม่ผ่านด่าน ด่านยังคงรันทุก commit การตรวจสอบในบรรทัดของ MCP server และการบังคับใช้ของ pre-commit hook เสริมซึ่งกันและกัน ดังนั้นอย่าเอาตัวใดออก