为什么代码生成的输出总带语法错误
代码生成场景近几年非常普遍，无论是基于大模型的智能补全，还是低代码平台的模板渲染，最终产出的代码都不可能保证百分之百正确。常见的错误类型包括括号或引号不配对、缩进层级错乱、变量声明残缺、模板变量替换后留下的多余符号等。这些问题在字符串层面看起来五花八门，但从语法角度看，大多可以归结为有限的几类模式。
很多团队的第一反应是用正则表达式做字符串修补，比如检测到奇数个引号就补一个引号，检测到花括号数量不平衡就往末尾追加右括号。这种做法在简单场景下有效，但极易引入新的错误。比如一段代码里同时存在字符串和注释，字符串中的引号会干扰计数，补丁打上去反而让原本正确的部分变得错误。字符串层面处理语法问题的根本缺陷在于：它不理解代码的结构。
AST解析提供了另一种思路。抽象语法树是编译器前端对源代码结构的完整表达，一个能通过解析的代码必然对应一棵合法的语法树；反过来，解析失败的报错信息里往往带着出错的具体位置和错误类型。利用这些信息，我们可以把修复动作从盲目的文本替换，升级为有针对性的结构级修复。
基于AST解析定位错误的具体实现
以Python为例，标准库中的ast模块和第三方的parso库都提供了容错解析能力。ast模块遇到语法错误会抛出SyntaxError，其中lineno和offset属性直接给出行号和列号，msg给出错误描述。下面是一个定位错误的基础函数：
import ast
def locate_syntax_error(code: str):
"""解析代码，若有语法错误则返回错误信息字典"""
try:
ast.parse(code)
return None # 代码完全合法
except SyntaxError as e:
return {
"line": e.lineno, # 出错的行号
"column": e.offset, # 出错的列号
"message": e.msg, # 错误描述
"text": (e.text or "").strip() # 出错行的源码
}
sample = "def add(a, b):\n return a + b\n"
print(locate_syntax_error(sample))拿到错误位置之后，第二步是根据错误类型决定修复策略。实践经验中，以下几类错误占了绝大多数：未闭合的括号对应unexpected EOF或'}' was never closed类消息；缺失冒号对应expected ':'；缩进错误对应unexpected indent或expected an indented block。为这些高频错误各写一条修复规则，就能覆盖大部分实际问题。
对于JavaScript，可以使用esprima或支持容错的babel-parser。Babel的解析器在出错时同样抛出带loc位置信息的异常，配合recast库还能在修改AST后保留原有代码格式，这一点后面会展开。下面是一个JavaScript端的检测示例：
const parser = require("@babel/parser");
function locateError(code) {
try {
parser.parse(code, { sourceType: "module" });
return null;
} catch (e) {
return {
line: e.loc ? e.loc.line : null,
column: e.loc ? e.loc.column : null,
message: e.message,
};
}
}
console.log(locateError("const arr = [1, 2, 3;"));
// 输出缺失右方括号的错误位置规则驱动的自动修复流水线
错误定位只是开始，真正的修复需要一个规则库加循环重试的流水线。基本流程是：解析代码，若有错误则根据错误消息匹配修复规则，应用规则后重新解析，直到代码合法或达到重试上限。重试上限非常重要，一般设为3到5次，因为某些错误组合可能陷入循环修复的死循环，比如补了一个括号又导致新的不配对。
下面给出一个简化的Python修复器实现，涵盖缺冒号和未闭合括号两类高频错误：
import ast
import re
MAX_RETRY = 5
def fix_missing_colon(lines, line_no):
"""在指定行末尾补冒号"""
idx = line_no - 1
if 0 <= idx < len(lines):
lines[idx] = lines[idx].rstrip() + ":"
return lines
def fix_unclosed_brackets(code):
"""统计并补齐缺失的右括号"""
pairs = {"(": ")", "[": "]", "{": "}"}
stack = []
in_str = None
for ch in code:
if in_str:
if ch == in_str:
in_str = None
elif ch in ("'", '"'):
in_str = ch
elif ch in pairs:
stack.append(pairs[ch])
elif ch in pairs.values():
if stack and stack[-1] == ch:
stack.pop()
return code + "".join(reversed(stack))
def auto_fix(code: str) -> str:
for _ in range(MAX_RETRY):
try:
ast.parse(code)
return code # 修复成功
except SyntaxError as e:
lines = code.split("\n")
msg = e.msg or ""
if "expected ':'" in msg:
lines = fix_missing_colon(lines, e.lineno)
code = "\n".join(lines)
elif "EOF" in msg or "was never closed" in msg:
code = fix_unclosed_brackets(code)
else:
break # 无匹配规则，交由上层处理
return code这个实现的几个细节值得强调。首先，括号统计时必须跳过字符串字面量，否则字符串里的括号会被误计数，这也是朴素正则方案容易失败的地方。其次，每应用一次修复都要立即重新解析，而不是把所有规则一次跑完再验证，这样能避免规则之间相互冲突。最后，没有匹配规则的情况要显式跳出并上报，让调用方决定是丢弃这段代码、交给大模型重新生成，还是转入人工审核。
格式保留与工程化落地的考量
修复后的代码还有一个容易被忽视的问题：格式。如果直接把AST重新序列化成代码，原有的注释、空行、缩进风格都会丢失，在多人协作项目里会产生大量无意义的diff。recast的解决方式是记录每个节点的原始源码范围，重打印时尽量复用原文；Python侧可以借助libcst，它天生支持保留注释和格式的无损转换。如果你的修复只涉及插入缺失字符这类局部改动，直接在字符串上做最小化编辑、配合AST验证结果，反而是更稳妥的做法。
在工程化落地时，建议把修复流水线设计成可插拔的多级结构。第一级是轻量规则修复，成本低、速度快，解决大部分确定性错误；第二级是局部重生成，把出错行及其上下文喂给大模型，要求只输出修正后的片段，控制token消耗；第三级是整段重新生成并再次校验。每级之间都由AST解析把关，任何一级通过就立即返回。同时要把修复日志落库，统计各类错误的出现频率，这些数据既能帮你发现生成模型的系统性弱点，也能指导规则库的持续补充。
总结来看，AST解析把代码修复从字符串猜谜变成了结构化的确定性操作，配合规则库、重试上限和格式保留策略，可以构建出稳定可靠的自动修复管线。对于正在做代码生成产品的团队，这套方案投入不大，却能显著提升产出代码的可用率，是值得优先落地的基础设施。