开发者趋势观察中转查编辑部5 分钟阅读
SWE-Gate 把代码审查约束纳入评测，Agent 通过测试也未必能被合并
SWE-Gate 从真实 Pull Request 评论提取审查约束，构建 303 个仓库级修复任务，检验代码 Agent 是否同时满足功能与评审要求。
核心判断Agent 通过测试，也可能因为代码审查约束无法合并
#SWE-Gate#303 任务#审查约束
测试通过不等于可合并中转查编辑部的判断
代码 Agent 的验收标准需要从“测试通过”扩展到可维护性、接口约定和审查意见，团队应把评审规则转成可重复的自动检查。
通过功能测试只是第一道门
现有代码 Agent 基准通常把测试是否通过作为主要结果，但真实 Pull Request 还会受到命名、接口兼容、错误处理和变更范围等约束。SWE-Gate 将这些约束从历史审查评论中整理出来，再为同一个修复任务分别设置功能检查和评审检查，让两类能力可以被单独观察。
这类拆分揭示了一个常见误区：代码能运行，不代表它符合仓库维护者的预期。Agent 可能用大范围重构解决一个小问题，或绕过既有抽象导致后续维护成本上升，这些问题往往不会被传统单元测试捕捉。
审查评论可以变成可执行约束
SWE-Gate 的做法是把自然语言评审意见转成单独的约束测试，并保留不合规补丁与参考补丁。开发团队可以借鉴这一思路，将高频审查规则沉淀为静态检查、类型约束或回归测试，减少同一类问题在不同任务中重复出现。
对 Agent 来说，约束测试也提供了更清晰的反馈信号。系统不必只收到一个“失败”结果，而是能知道功能已经修好、但接口或变更范围仍不符合要求，从而在下一轮修正时减少盲目重写。
企业评测要覆盖完整交付条件
仓库级开发还涉及安全边界、依赖升级、日志质量和回滚策略。单一基准不可能覆盖所有团队规范，但至少应该把关键审查规则显式化，并记录 Agent 为满足约束增加了多少修改和人工介入。
中转查认为，SWE-Gate 的价值在于提醒团队重新定义成功：功能正确是底线，能否在既有架构中以可审查、可维护的方式完成，才更接近生产交付。