不是靠Prompt：31万行重构的Agent评测实战

我们注意到美团技术团队在处理大规模遗留系统重构时，没有依赖更长的 Prompt，而是用了一套 Agent 评测思路。面对 31 万行代码的重构，传统的"人机对话"模式在规模面前极易失控。通过将 AI 的编码行为转化为评测指标，他们实现了从"人机对齐"到"工程约束"的跨越。我们分析这套评测驱动的重构逻辑。

从"人机对齐"到"共识固化"

美团团队的出发点是：当 AI 承担 90% 以上的代码产出时，规范的约束对象不再是"人该怎么写"，而是"AI 该怎么被限制"。他们把重构流程分为三个阶段：

注入上下文：将局部代码与全局架构规则关联。
执行变更：AI 根据指令生成重构后的代码。
Agent 闭环评测：用评测 Agent 对生成的代码做逻辑一致性和架构合规性检查。

这个思路的巧妙之处在于，它把过去依赖人工 Code Review 的"事后纠偏"变成了"事中约束"。大部分违反架构设计的问题在生成阶段就被拦截，而不是等到 PR 阶段才被发现。

架构约束的 Agent 评测实战

美团构建了一个基于 AST 与语义分析的评测 Agent。以防止 AI 在重构中破坏原有设计模式为例，以下是一个具体可用的架构规则定义：

python 复制代码

import ast

class RepoLayerRule:
    """架构规则：Service 层不能直接引用 Repository 类"""
    BANNED_PATTERNS = ['repository', 'dao', 'mapper']
    
    def check(self, file_path: str) -> list[dict]:
        tree = ast.parse(open(file_path).read())
        violations = []
        for node in ast.walk(tree):
            if isinstance(node, ast.ImportFrom):
                for alias in node.names:
                    if any(p in alias.name.lower() for p in self.BANNED_PATTERNS):
                        violations.append({
                            'line': node.lineno,
                            'rule': 'no_direct_repo_access',
                            'detail': f'禁止直接引用数据层: {alias.name}'
                        })
        return violations

rule = RepoLayerRule()
result = rule.check('service/order_service.py')
if result:
    print(f'违反架构规则 {len(result)} 处:')
    for v in result:
        print(f'  第 {v["line"]} 行: {v["detail"]}')

这套机制的工程价值不是代码层面的对错检查，而是把架构设计意图编程化了。团队商定的一条架构规则不再只存在于设计文档里，而是变成了一段可执行代码。AI 生成的每一行代码都在这个规则集下被过滤。

踩坑记录：评测 Agent 也会犯错

实践中他们遇到了"评测幻觉"------评测 Agent 本身产生误报。解决方式是引入多级检查：第一层基于 AST 的静态规则检查（快速、确定性高），第二层基于 LLM 的语义检查（慢、但能处理复杂逻辑）。

以下是一个展示如何通过 AST 过滤掉"无意义变更"的逻辑示例：

python 复制代码

import ast

def is_pure_refactor(old_code, new_code):
    tree_old = ast.parse(old_code)
    tree_new = ast.parse(new_code)
    return compare_ast_structure(tree_old, tree_new)

def compare_ast_structure(node_a, node_b):
    return True

old_func = "def calc(x): return x * 2"
new_func = "def calc(x): \n    return x * 2"
if is_pure_refactor(old_func, new_func):
    print("检测为语法重构，允许通过")

除了基于 AST 的检查，团队还使用了评分卡方式来约束重构质量。每条规则有权重，累计分数超过阈值才触发人工介入：

python 复制代码

SCORE_CARD = {
    '禁止访问数据层': 10,
    '禁止循环依赖': 8,
    '禁止使用已废弃API': 5,
    '函数不超过200行': 3,
    '变量命名规范': 1,
}

def evaluate_score(violations: list) -> str:
    total = sum(SCORE_CARD.get(v['rule'], 1) for v in violations)
    if total >= 15:
        return 'BLOCK'
    elif total >= 8:
        return 'WARN'
    return 'INFO'

这种权重体系比简单的"合规/违规"更实用。轻度违规（命名不规范）记录但不阻断，严重违规（直接操作数据层）立即阻断。

我们的思考：这套方法对普通团队意味着什么

美团的实践有几个值得借鉴的思路。第一，规则定义能力比代码能力更重要。评测 Agent 的有效性完全取决于规则的精准度。好的规则需要团队对自身架构有清晰认知------这恰好是 2-8 年工程师应该重点锻炼的判断力。第二，从一条规则开始，不要一上来搭完整体系。挑一个最痛的点，写一条 AST 规则，跑一个循环看看效果。第三，"评测幻觉"才是真正的隐形杀手。如果评测 Agent 有 10% 的误报率，团队就会开始不信任它。维持续信任比写规则更难。

总结

美团这次重构的核心贡献不是技术栈的选型，而是一个认知转变：在 AI 写代码的时代，工程约束的约束对象不是人，是 AI。传统规范告诉人该怎么写，Agent 评测告诉 AI 什么不能写。后者的落地门槛比想象中低------一条 AST 规则、一个反馈循环、一次迭代，就能开始运行。与其等待更聪明的 AI 自动写出合规代码，不如现在开始定义你的规则集。这是 31 万行代码重构后最值得带走的经验。与其试图去教导 AI 变得完美，不如建立一套能够自动识别其不完美并强制其修正的闭环系统。这种做法在同类项目中值得参考。