1. 为什么要在 AI 编辑器里加"质量闸门"
AI 代码编辑器现在几乎成了开发者的标配工具，从补全单行代码到生成整个模块，效率提升是肉眼可见的。但用久了你会发现一个很尴尬的问题：AI 写代码很快，但它写完的代码能不能跑、逻辑对不对、边界情况有没有处理，它自己是不负责的。你让它写一个函数，它给你返回一段看起来语法没问题的代码，结果一运行就报错，或者单元测试根本过不了。
我最初用 AI 编辑器的时候，基本流程就是"生成—复制—粘贴—手动跑测试—发现报错—再回去问 AI—再复制粘贴"，来回折腾几轮才能把一段代码真正落地。这个过程中最耗时的不是写代码，而是验证和修复的循环。后来我就在想，能不能让 AI 自己完成这个循环？它写完代码之后，自己检查语法、自己跑单元测试、自己根据报错修复，直到全部通过才把结果交给我。
这就是"四层质量闸门"的由来。所谓四层，指的是代码从 AI 生成到最终交付，中间要经过四道检查关卡：语法检查、静态分析、单元测试、自动修复。每一层闸门都会拦截不合格的代码，只有四层全部通过，代码才算"交付合格"。这套机制的核心思路是把质量验证的责任从人转移给 AI 自身，让 AI 从一个"代码生成器"变成一个"能对自己产出负责的工程助手"。
这套方案适合谁？如果你日常用 AI 编辑器写代码，尤其是写业务逻辑、工具函数、接口封装这类需要保证正确性的场景，那这套闸门机制能帮你省掉大量手动验证的时间。如果你只是用 AI 写写注释、改改变量名，那可能用不上这么重的流程。另外，如果你团队里有人在用 AI 辅助开发，这套机制也可以作为代码提交前的自动化检查环节，降低 AI 生成代码引入 bug 的概率。
需要说明的是，这套方案不是某个现成工具的自带功能，而是需要你自己在 AI 编辑器的工作流里搭建的一套自动化流程。不同编辑器的扩展能力不一样，但核心思路是通用的：让 AI 生成代码后，自动触发检查命令，捕获结果，再把结果反馈给 AI 进行修复。下面我会把这四层闸门逐一拆开讲清楚。
2. 四层质量闸门的整体设计与选型考量
2.1 为什么是四层而不是三层或五层
先说清楚这四层分别是什么，以及为什么这样分层。
第一层是语法检查，也叫解析层。这一层做的事情最基础：检查 AI 生成的代码能不能被编译器或解释器正确解析。比如 Python 代码有没有缩进错误、括号有没有配对，JavaScript 有没有缺少分号或者花括号不匹配。这一层的工具通常是语言自带的解析器，比如 Python 的ast.parse、Node.js 的node --check，或者 ESLint 的 parser 部分。
第二层是静态分析，也就是 lint 层。语法没问题不代表代码质量没问题。静态分析会检查未使用的变量、未定义的引用、类型不匹配、潜在的逻辑错误等。这一层的工具包括 ESLint、Pylint、Flake8、TypeScript 的tsc --noEmit等。静态分析能在不运行代码的情况下发现很多低级错误，而且速度很快。
第三层是单元测试，这是最核心的一层。语法和静态分析只能保证代码"看起来对"，单元测试才能验证代码"实际对不对"。AI 生成的代码经常在边界条件、异常处理、类型转换这些地方出问题，单元测试能把这些都暴露出来。这一层需要你提前准备好测试用例，或者让 AI 根据函数签名和注释自动生成测试用例。
第四层是自动修复，这是把前三层的检查结果反馈给 AI，让它根据报错信息修改代码，然后重新走一遍前三层。这一层是循环的，直到所有检查通过或者达到最大重试次数。
为什么是四层？因为这三类检查的粒度和目的不同，不能合并。语法检查最快但最浅，静态分析稍慢但能发现更多问题，单元测试最慢但最接近真实运行环境。如果只有语法检查和单元测试，中间会漏掉很多静态分析能发现的低级错误；如果只有静态分析和单元测试，语法错误会导致测试根本无法运行。四层是一个比较平衡的划分，既不会太轻导致漏检，也不会太重导致流程过于复杂。
2.2 工具选型：不同语言栈的搭配方案
这套闸门机制不绑定特定语言，但不同语言栈的工具选型差别很大。我按常见的几种场景列一下。
对于JavaScript/TypeScript项目，语法检查可以用node --check或者直接让 ESLint 的 parser 报错。静态分析用 ESLint 加@typescript-eslint插件，配置no-unused-vars、no-undef、@typescript-eslint/no-explicit-any这些规则。单元测试用 Jest 或 Vitest，这两个对 AI 生成的代码比较友好，因为它们的报错信息很详细，方便反馈给 AI 修复。
对于Python项目，语法检查用python -m py_compile或者ast.parse。静态分析用 Flake8 或 Ruff，Ruff 速度更快，适合在循环里频繁调用。单元测试用 pytest，它的断言重写机制能让报错信息更清晰，AI 更容易理解哪里出了问题。
对于Java项目，语法检查用javac的编译过程，静态分析用 Checkstyle 或 SpotBugs，单元测试用 JUnit。这里有个细节：Java 的编译和测试是分开的，编译不通过就没法跑测试，所以语法检查和静态分析要放在编译阶段一起做。
对于Go项目，语法检查用gofmt -e或者go vet，静态分析用staticcheck，单元测试用go test。Go 的工具链比较统一，配置起来相对简单。
选型的时候有一个原则：每一层的工具都要能输出结构化的错误信息，最好是 JSON 格式或者至少是行号加错误描述的格式。因为后面要把这些信息反馈给 AI，如果错误信息是一大段自然语言，AI 解析起来容易出错；如果是结构化的，AI 能更准确地定位问题。
2.3 闸门之间的衔接逻辑
四层闸门不是简单串行执行的，中间有一些衔接逻辑需要设计。
第一，短路机制。如果第一层语法检查没通过，就没必要跑第二层和第三层了，直接进入第四层修复。因为语法错误的代码根本没法做静态分析和单元测试。同理，如果第二层静态分析发现了严重错误（比如未定义的引用），也可以直接跳到修复层，不用跑单元测试。
第二，错误聚合。每一层可能会报多个错误，不要一个一个反馈给 AI，而是把同一层的所有错误聚合在一起，一次性反馈。这样 AI 修复的时候能通盘考虑，避免改了一个又引入另一个。
第三，修复后的重试策略。AI 修复完代码后，要从第一层重新开始跑，而不是从出错的那一层继续。因为 AI 的修改可能会引入新的语法错误，或者影响之前通过的检查。重试次数建议限制在 3 到 5 次，超过之后就把问题抛给人，避免无限循环浪费资源。
第四，上下文保留。每次反馈给 AI 的时候，除了错误信息，还要把原始需求、当前代码、之前的修复记录一起带上。这样 AI 能理解自己之前改了什么，避免重复犯同样的错误。
3. 核心细节解析与实操要点
3.1 语法检查层的实现细节
语法检查看起来简单，但实际做的时候有几个坑。
第一个坑是不同语言的语法检查命令不一样，返回码含义也不一样。比如 Python 的py_compile在语法错误时返回非零退出码，但错误信息输出到 stderr；Node.js 的node --check也是非零退出码，但错误信息格式和 Python 完全不同。你需要为每种语言写一个适配器，把不同格式的错误信息统一成{line, column, message}的结构。
第二个坑是有些语法错误是"软错误"。比如 JavaScript 在非严格模式下，某些写法不会报语法错误，但运行时会出问题。这种情况下，语法检查层可能放行，但静态分析层会拦截。所以语法检查层不要追求覆盖所有问题，它的职责就是"能不能解析"，其他的交给后面几层。
第三个坑是临时文件的处理。AI 生成的代码可能是一段片段，不是完整文件。你需要把它写入一个临时文件，加上必要的 import 或 require，才能跑语法检查。临时文件的命名和清理要做好，避免污染项目目录。我一般是在项目根目录下建一个.ai-gate/tmp目录，每次检查前清空，检查完删除。
实操上，我建议把语法检查封装成一个函数，输入是代码字符串和语言类型，输出是{passed: boolean, errors: []}。这样后面几层可以复用这个结构。
3.2 静态分析层的规则配置
静态分析层的核心是规则配置。规则太松，拦不住问题；规则太严，AI 会被大量风格问题淹没，修复效率很低。
我的经验是只开与正确性相关的规则，关掉所有风格类规则。比如 ESLint 里，no-unused-vars、no-undef、no-dupe-keys、no-unreachable这些要开，但indent、quotes、semi这些风格规则全部关掉。因为 AI 生成的代码风格不一致是常态，如果因为缩进问题就让 AI 反复修复，纯属浪费时间。
对于 TypeScript 项目，tsc --noEmit是必须跑的，它能发现类型不匹配的问题。但要注意，如果项目本身类型定义不完整，tsc可能会报大量与 AI 生成代码无关的错误。这时候可以用--skipLibCheck跳过第三方库的类型检查，或者只对 AI 生成的文件做检查。
Python 项目里，Ruff 的配置建议开E9（语法错误）、F（Pyflakes 规则，包括未使用变量、未定义名称等），关掉E1、E2、E3、E4、E5这些格式类规则。Ruff 的速度非常快，适合在循环里频繁调用。
有一个细节要注意：静态分析的错误信息要包含足够的上下文。比如"第 15 行使用了未定义的变量foo"，比"undefined variable"要有用得多。如果工具本身输出的信息不够详细，你可能需要自己解析输出并补充上下文。
3.3 单元测试层的用例准备
单元测试层是四层里最重的一层，也是最需要提前准备的一层。
首先，测试用例从哪来？有两种方式。一种是你自己提前写好测试文件，AI 生成的代码必须通过这些测试。这种方式适合核心业务逻辑，因为你对正确行为的定义最清楚。另一种是让 AI 根据函数签名和注释自动生成测试用例，然后跑这些用例。这种方式适合工具函数、辅助函数，因为它们的预期行为比较直观。
我一般混合使用：核心模块用手写测试，辅助模块用 AI 生成测试。AI 生成测试的时候，提示词里要明确要求覆盖边界条件，比如空输入、超长输入、类型错误输入等。否则 AI 倾向于只生成"正常路径"的测试，覆盖不到容易出问题的地方。
其次，测试运行环境要隔离。AI 生成的代码可能会修改全局状态、写文件、发网络请求，如果直接在项目环境里跑测试，可能会污染数据。我建议用 Docker 容器或者虚拟环境来跑测试，每次测试前重置环境。如果项目本身有测试隔离机制（比如 pytest 的 fixture、Jest 的beforeEach），要确保 AI 生成的代码也遵守这些机制。
第三，测试超时要设置。AI 生成的代码有可能进入死循环，如果没有超时机制，测试会一直卡住。Jest 默认超时是 5 秒，pytest 可以用--timeout参数设置。超时后要捕获异常，把"测试超时"作为错误信息反馈给 AI。
第四，测试覆盖率不是目标。这套闸门机制的目的是"验证 AI 生成的代码能跑通"，不是"达到 100% 覆盖率"。所以不要追求覆盖所有分支，只要覆盖核心路径和关键边界条件就行。覆盖率太高会导致测试运行时间过长，影响修复循环的效率。
3.4 自动修复层的提示词设计
自动修复层是整套机制里最"AI"的一层，它的效果很大程度上取决于提示词的质量。
我试过很多种提示词写法，最后总结出一个比较稳定的结构：
你之前生成的代码没有通过检查，请根据以下错误信息修复代码。 原始需求： {原始需求描述} 当前代码： {当前代码} 检查结果： {结构化错误信息} 修复要求： 1. 只修改与错误相关的部分，不要重写整个代码 2. 修复后确保不引入新的语法错误 3. 如果错误信息中有多个问题，逐一修复 4. 输出完整的修复后代码，不要只输出差异部分这个结构里有几个关键点。第一，明确告诉 AI 只修改相关部分，否则它可能会把整个代码重写一遍，引入新的问题。第二，要求输出完整代码，因为后续检查需要完整文件，如果只输出差异，还需要额外做合并操作。第三，强调不引入新错误，虽然 AI 不一定能完全做到，但这个约束能减少修复引入新问题的概率。
还有一个技巧：把之前的修复记录也带上。比如"你之前已经尝试修复过两次，第一次的问题是 X，第二次的问题是 Y，这次请避免重复这些错误"。这样 AI 能从前几次失败中学习，而不是反复犯同样的错误。
修复层的重试次数我一般设为 3 次。超过 3 次还没修好，说明要么是原始需求有问题，要么是 AI 能力不够，这时候把问题抛给人处理更高效。
4. 实操过程与核心环节实现
4.1 整体流程的代码骨架
先给一个整体流程的伪代码骨架，让你看清楚四层闸门是怎么串起来的。
def ai_code_with_gates(requirement, language, max_retries=3): code = ai_generate(requirement, language) for attempt in range(max_retries): # 第一层：语法检查 syntax_result = check_syntax(code, language) if not syntax_result.passed: code = ai_fix(code, requirement, syntax_result.errors) continue # 第二层：静态分析 lint_result = check_lint(code, language) if not lint_result.passed: code = ai_fix(code, requirement, lint_result.errors) continue # 第三层：单元测试 test_result = run_tests(code, language) if not test_result.passed: code = ai_fix(code, requirement, test_result.errors) continue # 四层全部通过 return {"status": "success", "code": code, "attempts": attempt + 1} return {"status": "failed", "code": code, "attempts": max_retries}这个骨架里，ai_generate是初始生成，ai_fix是根据错误信息修复。每一层检查返回一个结构化的结果，包含passed和errors。如果某一层没通过，就调用ai_fix修复，然后continue重新从第一层开始。
实际实现的时候，check_syntax、check_lint、run_tests这三个函数需要根据语言类型做适配。下面我分别说一下每个函数的实现要点。
4.2 语法检查函数的具体实现
以 Python 为例，语法检查可以用ast.parse实现，不需要起子进程，速度最快。
import ast def check_syntax_python(code): try: ast.parse(code) return {"passed": True, "errors": []} except SyntaxError as e: return { "passed": False, "errors": [{ "line": e.lineno, "column": e.offset, "message": e.msg, "text": e.text }] }对于 JavaScript，可以用node --check起子进程：
import subprocess import tempfile import os def check_syntax_javascript(code): with tempfile.NamedTemporaryFile(mode='w', suffix='.js', delete=False) as f: f.write(code) tmp_path = f.name try: result = subprocess.run( ['node', '--check', tmp_path], capture_output=True, text=True, timeout=10 ) if result.returncode == 0: return {"passed": True, "errors": []} else: return { "passed": False, "errors": parse_node_error(result.stderr) } finally: os.unlink(tmp_path)这里有几个细节。第一，timeout=10是必须的，防止子进程卡死。第二，临时文件用delete=False创建，然后在finally里手动删除，这样即使检查过程中抛异常也能清理。第三，parse_node_error需要自己实现，把 Node.js 的错误输出解析成结构化格式。
Node.js 的语法错误输出格式大概是这样的：
/path/to/file.js:3 const x = ; ^ SyntaxError: Unexpected token ';'解析的时候可以用正则提取行号和错误信息。不同版本的 Node.js 输出格式可能略有差异，建议先打印几组实际输出，再写解析逻辑。
4.3 静态分析函数的实现
静态分析以 ESLint 为例。ESLint 支持--format json输出结构化结果，非常适合程序化处理。
import subprocess import json import tempfile import os def check_lint_javascript(code): with tempfile.NamedTemporaryFile(mode='w', suffix='.js', delete=False) as f: f.write(code) tmp_path = f.name try: result = subprocess.run( ['npx', 'eslint', '--format', 'json', tmp_path], capture_output=True, text=True, timeout=30 ) output = json.loads(result.stdout) errors = [] for file_result in output: for msg in file_result.get('messages', []): errors.append({ "line": msg.get('line'), "column": msg.get('column'), "message": msg.get('message'), "ruleId": msg.get('ruleId') }) return {"passed": len(errors) == 0, "errors": errors} finally: os.unlink(tmp_path)这里要注意，ESLint 在没有配置文件的情况下可能不会报任何错误。你需要确保项目根目录有.eslintrc或者eslint.config.js，或者在命令里用--config指定配置文件。另外，npx eslint第一次运行可能会提示安装，建议提前在项目里装好 ESLint。
对于 TypeScript，静态分析要跑两次：一次 ESLint，一次tsc --noEmit。tsc的输出格式是file(line,col): error TSxxxx: message，可以用正则解析。
Python 的静态分析用 Ruff：
def check_lint_python(code): with tempfile.NamedTemporaryFile(mode='w', suffix='.py', delete=False) as f: f.write(code) tmp_path = f.name try: result = subprocess.run( ['ruff', 'check', '--output-format', 'json', tmp_path], capture_output=True, text=True, timeout=30 ) if result.returncode == 0: return {"passed": True, "errors": []} errors = json.loads(result.stdout) return { "passed": False, "errors": [{ "line": e.get('location', {}).get('row'), "column": e.get('location', {}).get('column'), "message": e.get('message'), "code": e.get('code') } for e in errors] } finally: os.unlink(tmp_path)Ruff 的--output-format json输出的是一个数组，每个元素包含code、message、location等字段。注意 Ruff 的退出码：0 表示没有错误，1 表示有错误，2 表示配置或内部错误。如果返回 2，说明 Ruff 本身出了问题，不是代码的问题，这时候应该把错误信息记录下来，但不要反馈给 AI 修复。
4.4 单元测试函数的实现
单元测试层需要把 AI 生成的代码和测试文件放在一起运行。以 Jest 为例：
import subprocess import json import os import shutil def run_tests_javascript(code, test_code, work_dir): # 准备工作目录 if os.path.exists(work_dir): shutil.rmtree(work_dir) os.makedirs(work_dir) # 写入代码和测试文件 with open(os.path.join(work_dir, 'solution.js'), 'w') as f: f.write(code) with open(os.path.join(work_dir, 'solution.test.js'), 'w') as f: f.write(test_code) # 写入 Jest 配置 with open(os.path.join(work_dir, 'jest.config.js'), 'w') as f: f.write("module.exports = { testEnvironment: 'node' };") try: result = subprocess.run( ['npx', 'jest', '--json', '--outputFile', 'result.json'], cwd=work_dir, capture_output=True, text=True, timeout=60 ) result_path = os.path.join(work_dir, 'result.json') if not os.path.exists(result_path): return { "passed": False, "errors": [{"message": "Jest 未生成结果文件", "raw": result.stderr}] } with open(result_path) as f: jest_result = json.load(f) if jest_result.get('success'): return {"passed": True, "errors": []} errors = [] for test_result in jest_result.get('testResults', []): for assertion in test_result.get('assertionResults', []): if assertion.get('status') == 'failed': errors.append({ "testName": assertion.get('title'), "message": ' '.join(assertion.get('failureMessages', [])) }) return {"passed": False, "errors": errors} finally: pass # 保留工作目录用于调试，正式环境可以清理这里有几个实操要点。第一，工作目录要独立，不要和项目源码混在一起，避免测试文件被项目构建工具扫描到。第二，Jest 的--json输出到文件，因为 Jest 的 JSON 输出可能很大，直接输出到 stdout 可能会被截断。第三，超时设为 60 秒，单元测试比语法检查和静态分析慢得多，超时时间要放宽。第四，失败信息要包含测试名称，这样 AI 能知道是哪个测试用例失败了，修复的时候更有针对性。
对于 pytest，可以用--json-report插件输出 JSON 格式的结果，或者用--tb=short输出简短的错误信息，然后自己解析。
4.5 自动修复函数的实现
自动修复函数的核心是构造提示词，然后调用 AI 接口。这里以通用的方式说明：
def ai_fix(code, requirement, errors, previous_attempts=None): error_text = format_errors(errors) prompt = f"""你之前生成的代码没有通过检查，请根据以下错误信息修复代码。 原始需求： {requirement} 当前代码：{code}
检查结果： {error_text} 修复要求： 1. 只修改与错误相关的部分，不要重写整个代码 2. 修复后确保不引入新的语法错误 3. 如果错误信息中有多个问题，逐一修复 4. 输出完整的修复后代码，不要只输出差异部分 """ if previous_attempts: prompt += f"\n之前的修复记录：\n{previous_attempts}\n请避免重复之前的错误。" response = call_ai_api(prompt) return extract_code_from_response(response)format_errors函数把结构化的错误信息转成可读的文本。比如：
def format_errors(errors): lines = [] for i, err in enumerate(errors, 1): if 'line' in err: lines.append(f"{i}. 第 {err['line']} 行：{err['message']}") elif 'testName' in err: lines.append(f"{i}. 测试 '{err['testName']}' 失败：{err['message']}") else: lines.append(f"{i}. {err['message']}") return '\n'.join(lines)extract_code_from_response从 AI 的回复里提取代码块。AI 通常会用包裹代码，用正则提取即可。但要注意，AI 有时候会输出多个代码块，或者代码块里包含嵌套的，这时候需要更复杂的解析逻辑。我的做法是取最后一个完整的代码块，因为 AI 通常把最终代码放在最后。
5. 常见问题与排查技巧实录
5.1 检查工具报错但 AI 修不好怎么办
这是最常见的问题。AI 修复了两三次还是过不了检查，原因通常有几类。
第一类是错误信息不够具体。比如 ESLint 报"Parsing error: Unexpected token"，但没说是哪个 token、在哪一行。这种情况下 AI 只能猜，修复效果很差。解决办法是在反馈给 AI 之前，把错误信息补充完整。比如从 ESLint 的 JSON 输出里提取line、column、message，甚至把出错行的代码也带上。
第二类是错误涉及项目上下文。比如 AI 生成的代码引用了项目里不存在的模块，或者使用了未安装的依赖。这种错误 AI 自己修不了，因为它不知道项目里有什么。解决办法是在提示词里把项目的依赖列表、可用的模块路径一起告诉 AI。
第三类是需求本身有歧义。AI 生成的代码在它理解的需求下是对的，但检查工具按另一种理解去检查，自然过不了。这种情况下要回到需求描述，把需求写得更明确。比如"写一个排序函数"太模糊，要写成"写一个对整数数组升序排序的函数，使用快速排序算法，处理空数组和单元素数组"。
第四类是AI 陷入了局部修复循环。它每次只改一点点，但改的地方不对，导致错误在几个位置之间来回跳。解决办法是在提示词里加上"如果连续两次修复同一类错误仍未通过，请重新审视整体逻辑，必要时重写相关部分"。
5.2 单元测试跑得太慢影响效率
单元测试层是四层里最慢的，如果测试用例很多，每次修复循环都要跑一遍全部测试，时间成本很高。
我的优化策略是分层跑测试。第一轮只跑与修改文件相关的测试，用 Jest 的--findRelatedTests或者 pytest 的-k参数过滤。如果相关测试通过了，再跑全量测试。这样大部分修复循环只需要跑少量测试，速度能快很多。
另一个策略是缓存测试结果。如果 AI 只修改了某个函数，其他函数的测试结果可以复用。不过这需要比较复杂的依赖分析，实现成本较高，适合测试规模很大的项目。
还有一个细节：测试超时要合理设置。有些测试本身就需要几秒钟（比如涉及文件 IO 或网络请求的测试），如果超时设得太短，会误报超时。建议先手动跑一遍测试，看看正常情况下的耗时，然后把超时设为正常耗时的 3 到 5 倍。
5.3 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决思路 |
|---|---|---|---|
| 语法检查一直不通过 | 代码片段不完整，缺少 import 或上下文 | 检查临时文件是否包含必要的 import | 在写入临时文件时自动补充常用 import |
| 静态分析报大量风格错误 | 开启了风格类规则 | 查看 ESLint/Ruff 配置 | 关闭 indent、quotes、semi 等风格规则 |
| 单元测试报模块找不到 | 测试文件路径或模块解析配置不对 | 检查 Jest 的 moduleDirectories 配置 | 在测试配置里加上源码目录 |
| AI 修复后引入新错误 | 提示词要求不够明确 | 查看 AI 的修复输出 | 在提示词里强调"只修改相关部分" |
| 修复循环超过 3 次仍未通过 | 需求歧义或 AI 能力不足 | 检查需求描述是否明确 | 补充需求细节，或人工介入 |
| 测试超时 | 代码进入死循环或测试本身耗时过长 | 查看超时时的测试名称 | 调整超时时间，或检查代码逻辑 |
| 检查工具本身报错 | 工具配置错误或版本不兼容 | 查看工具的错误输出 | 检查工具版本和配置文件 |
5.4 几个我踩过的坑
第一个坑是临时文件污染项目。最开始我把临时文件写在项目根目录，结果 ESLint 扫描了整个项目，把临时文件也扫进去了，报了一堆无关错误。后来改成在.ai-gate/tmp目录下操作，并且在 ESLint 配置里忽略这个目录。
第二个坑是AI 修复时把测试文件也改了。有一次 AI 修复代码的时候，顺手把测试文件里的断言也改了，导致测试"通过"了但实际逻辑是错的。后来我在提示词里明确要求"不要修改测试文件"，并且在修复后校验测试文件的哈希值，确保没被改动。
第三个坑是不同 Node.js 版本的错误格式不一样。我在本地开发时用的是 Node 18，错误格式解析正常；部署到 CI 环境时用的是 Node 16，错误格式略有差异，解析失败了。后来我把错误解析逻辑写得更有容错性，用正则匹配关键信息，而不是依赖固定格式。
第四个坑是AI 生成的代码包含中文注释导致编码问题。有些检查工具默认用 ASCII 编码读取文件，遇到中文注释会报编码错误。解决办法是在写入临时文件时明确指定 UTF-8 编码，并且在工具配置里设置正确的编码。
6. 把这套机制用起来的几个建议
如果你打算在自己的 AI 编辑器里搭这套闸门机制，我的建议是从简到繁，不要一上来就四层全上。
先搭第一层和第二层，也就是语法检查和静态分析。这两层实现简单、速度快，能拦截大部分低级错误。跑一段时间，看看 AI 生成的代码主要在哪类问题上出错，再决定要不要加单元测试层。
单元测试层建议从核心模块开始，不要全项目覆盖。选几个最常让 AI 生成的函数，给它们写好测试用例，跑通这套流程。等流程稳定了，再逐步扩大测试范围。
自动修复层的提示词需要反复调优。我建议把每次修复的提示词、AI 的回复、修复结果都记录下来，定期回顾，看看哪些提示词效果好，哪些需要改进。这个记录本身也是很好的经验积累。
还有一点：这套机制不是替代人工审查，而是减少人工审查的工作量。四层闸门全部通过，只代表代码在语法、静态分析、单元测试这三个维度上没问题，不代表代码的业务逻辑完全正确、性能达标、安全无漏洞。最终交付前，人工审查还是必要的，只是审查的重点可以从"找低级错误"转移到"看业务逻辑和架构设计"。
最后分享一个小技巧：如果你用的是支持自定义脚本的 AI 编辑器，可以把这套闸门机制封装成一个命令，比如/verify，在 AI 生成代码后自动触发。这样你不需要手动跑每一层检查，整个流程对你是透明的，你只需要看最终结果就行。我用下来，这套机制能把 AI 生成代码的可用率从大概六成提升到九成以上，剩下的那一成基本是需求本身有问题，需要人工重新描述。
