测试工程师最该补的AI Coding能力：不看它写了多少代码，只看真实请求能不能跑通

摘要：NVIDIA新发布的SWE-Serve用真实推理服务任务证明：本地检查通过，不等于补丁能加载真实模型并通过公开接口。本文把论文数据翻译成测试团队可落地的端到端门禁。

一个AI Coding Agent修改了模型服务代码。单元测试通过，静态扫描通过，仓库回归也通过。研发准备合并时，测试只问了一句：真实模型能加载吗？

服务器启动后，答案变成了不能。

9月23日，NVIDIA发布SWE-Serve。它不是再考AI会不会修一个函数，而是把53个任务放进真实推理工程：模型注册、权重加载、解码、缓存、调度、OpenAI兼容接口、批量请求与分布式执行。

最值得测试团队注意的不是排行榜，而是一组差距：在19个包含真实服务检查的任务里，627个补丁如果拿掉E2E服务测试，通过率是69.4%；放回完整验证器后只剩45.9%。共有147个补丁从“通过”变成“失败”。

这不是说所有AI补丁都有同样失败率。它是NVIDIA研究团队在SGLang任务集和指定硬件上的作者实验结果。但它非常准确地暴露了一个工程盲区：仓库内部正确，不等于生产接口正确。

为什么本地测试接不住真实服务

模型服务不是一个普通函数。一次请求会穿过配置解析、模型注册、权重加载、显存分配、Tokenizer、批处理、KV Cache、专家路由、结果排序和API序列化。

Agent可能只修对了它看得见的局部：

• 配置类能实例化，但真实权重键名对不上；
• 单请求返回正确，批量请求顺序错位；
• 文本模型能加载，图像输入路径失败；
• 本地Mock有logprobs字段，真实接口却漏掉；
• 功能能跑，显存峰值或延迟超过发布门槛。

这些错误无法靠增加几个Mock完全解决，因为Mock恰好绕开了最容易出错的整条链路。

从Outcome Evaluation升级到生产正确性

传统AI Coding评测通常把“补丁能否通过测试”作为Outcome。但如果测试集没有启动真实服务，这个Outcome本身就不完整。

生产级评测至少要回答五个问题：

1. Build：代码能否安装、导入和编译。
2. Regression：旧行为是否保持。
3. Live Serving：真实模型是否能启动并从公开接口返回正确结果。
4. Behavior：Agent是否修改了允许的文件，是否通过删测试、降断言逃过检查。
5. Performance：延迟、吞吐、显存有没有越过校准门槛。

用一个订单推荐服务理解E2E门禁

假设Agent为推荐模型新增批量推理。单元测试只验证内部函数返回两个结果，但真实HTTP接口还要保证订单与结果不串位。

def assert_serving_contract(client):
    request = {
        "orders": [
            {"order_id": "A100", "items": ["phone"]},
            {"order_id": "B200", "items": ["coffee"]},
        ]
    }
    response = client.post("/v1/recommend", json=request)
    assert response.status_code == 200

    rows = response.json()["data"]
    assert [x["order_id"] for x in rows] == ["A100", "B200"]
    assert all(x["recommendations"] for x in rows)
    assert response.headers["x-model-version"]

这段断言承担的是业务质量判断：不是“服务返回200”就结束，而是身份、顺序、内容和版本证据必须同时成立。

进一步还要检查Trace：

def assert_patch_behavior(change):
    assert not change["deleted_tests"]
    assert not change["weakened_assertions"]
    assert change["files_changed"] <= change["allowed_files"]
    assert change["live_server_started"] is True
    assert change["model_loaded"] is True

隐藏验证器为什么重要

SWE-Serve不会把Agent补丁与参考实现逐行比较，而是用隐藏的功能与回归测试判断行为。这一点值得企业内部照搬。

如果AI能看到所有验收用例，它可能过度拟合测试，甚至修改测试来让自己通过。更稳妥的做法是把评测集分成三层：

• 开发可见：帮助Agent完成基本修改；
• CI隐藏：覆盖关键业务边界和负向路径；
• 发布前真实环境：加载真实模型、真实协议和受控流量。

每个任务还要做两个控制：旧代码必须在“新增行为”测试上失败，参考补丁必须通过完整验证。否则测试可能根本没有区分能力。

性能门不能只写“比以前快”

SWE-Serve首版中有3个任务在H100上执行校准性能门禁。这里的关键词是“校准”：性能阈值必须绑定硬件、模型、输入长度、并发数与预热方式。

企业里可以把门禁写成：

def quality_gate(metrics, baseline):
    assert metrics["correctness"] == 1.0
    assert metrics["p95_ms"] <= baseline["p95_ms"] * 1.10
    assert metrics["peak_vram_gb"] <= baseline["peak_vram_gb"] + 1.0
    assert metrics["error_rate"] <= 0.001

不要把厂商Benchmark数字直接搬进自己的CI。真正有效的是固定自己的硬件、数据集与基线，观察同一条件下的回归。

把这套方法接入CI/CD

一次AI补丁进入流水线后，可以按成本由低到高执行：静态检查与单元测试；历史回归；容器内启动服务；加载小模型跑接口契约；在目标GPU上跑关键模型；最后用影子流量验证延迟和稳定性。

低成本检查失败就尽早停止。真实服务测试可以只覆盖高风险变更，例如模型注册、缓存、调度、批处理和协议层。普通文档修改不需要占GPU。

同时保留五类证据：任务说明、Agent Trace、代码Diff、完整测试报告、硬件与模型版本。事故发生时，团队才能回答“为什么当时允许它合并”。

对测试工程师意味着什么

过去我们把端到端测试理解成“从页面点到数据库”。到了AI推理服务，端到端变成“从公开API进入，经过真实模型加载和运行时，再验证结果、顺序、性能与资源”。

接口自动化、环境构建、日志分析、性能测试和CI/CD经验都没有过时，只是测试对象变了。

如果你准备转AI测试开发，最有说服力的项目不是“让AI写了多少代码”，而是设计一个故意会在真实服务中失败、却能通过Mock测试的补丁，然后用E2E门禁把它拦住。这个项目比一张Agent Loop架构图，更能证明你理解生产质量。