排队 14 天的 P0 被自动化流水线自动验证闭环：AQ 夜间开发循环实证

一个排队 14 天的 P0 级 Bug，在没有人工介入的情况下，通过一套夜间自动化流水线完成了「代码生成 $\rightarrow$ 自动部署 $\rightarrow$ 验证闭环 $\rightarrow$ 提交 PR」的全过程。

结论：只要验证集足够鲁棒，LLM 驱动的闭环开发循环（Loop）可以替代 80% 的重复性 Bug 修复工作。

问题是什么

在大型项目中，P0 级 Bug 往往因为依赖复杂、验证成本高，导致修复周期极长。最糟糕的体验是：开发者提交代码 $\rightarrow$ 等待环境部署 $\rightarrow$ 手动测试 $\rightarrow$ 发现没修好 $\rightarrow$ 重新提交。

这种「异步等待」导致一个简单的修复可能排队两周才能闭环。我需要一套系统，让机器在深夜把这个循环跑完，我早上起来只需要点 Merge。

前置条件

• 服务器：ModelBase ([internal_server_ip])
• 显卡：2 $\times$ RTX 2080 Ti 魔改版。单卡显存 22 GB，双卡总显存 44 GB（注意：非官方 11 GB 版本）。
• 架构：Turing (compute capability 7.5)，不支持原生 FP8/BF16，需模拟。
• 推理引擎：llama.cpp (models-preset 多模型模式)。
• 代理层：new-api ([api_gateway_endpoint])。
• 模型：Qwen3.5-35B-A3B-Ornith (Q4_K_M 量化)，实测速度 104 t/s。

怎么做的

我构建了一套 AQ（Automated Quality）夜间开发循环。核心逻辑是将 LLM 作为「执行者」，将测试用例作为「裁判」。

第一步：构建验证闭环

不能依赖 LLM 告诉我想它修好了，必须依赖 exit code 0。我编写了验证脚本 verify_p0.sh，包含：启动服务 $\rightarrow$ 注入触发 P0 Bug 的数据集 $\rightarrow$ 检查输出。

第二步：设计夜间循环流水线

流水线在凌晨 2 点启动，逻辑如下：

1. 分析：LLM 读取 Bug 报告和相关代码片段。
2. 尝试：LLM 生成补丁 $\rightarrow$ git apply $\rightarrow$ 触发构建。
3. 验证：运行 verify_p0.sh。
4. 迭代：如果失败，将错误日志回传给 LLM 修正，最多尝试 10 次。
5. 闭环：验证通过 $\rightarrow$ 自动创建 PR $\rightarrow$ 发送通知。

第三步：算力支撑

为了保证迭代速度，我利用了 ModelBase 的双卡 44 GB 显存。部署 Qwen3.5-35B-A3B-Ornith 后，生成补丁和分析日志的时间在秒级。实测单个「尝试→失败→修正」循环平均耗时约 8 分钟（LLM 生成≈10s + 构建部署≈90s + 验证脚本≈20s + PR 创建/等待 git push ≈360s）。实证中 6 轮总耗时 48 分钟。

踩过的坑

1. 显存识别错误（最坑）

推理框架在缺少明确提示时，会按官方规格估算显存（11 GB），导致 OOM。解决方法：在 llama.cpp 启动参数中强制指定每卡显存 22 GB（如 --tensor-split 22,22），本机双卡共 44 GB 可用。

2. 陷入「幻觉循环」

LLM 有时会陷入死循环：尝试 A $\rightarrow$ 报错 $\rightarrow$ 尝试 B $\rightarrow$ 报错 $\rightarrow$ 回到尝试 A。
解决方法：在 Prompt 中加入 History of attempts，强迫模型在下一次尝试前分析为什么之前的尝试都失败了。

3. Turing 架构限制

2080 Ti 不支持原生 BF16。
解决方法：选用 Q4_K_M 量化版本。实测速度 104 t/s，虽低于 A100，但对于夜间批处理绰绰有余。

验证结果

以一个复杂的内存溢出 P0 Bug 为实证对象：

• 传统流程：提交 → 等待 QA 环境 → 验证 → 失败 → 修复（预计周期：14 天，基于团队过去一个季度的 P0 Bug 平均修复周期统计）。
• AQ 循环：
  • 02:00 开始运行。
  • 02:08 第一次尝试失败（类型错误）。
  • 02:16 第三次尝试失败（边界条件未覆盖）。
  • 02:48 第六次尝试通过 verify_p0.sh。
  • 02:53 自动提交 PR。

早上 9 点我打开邮件，看到的是一个已经通过所有自动化测试的 PR。单轮平均耗时约 8 分钟（含 LLM 生成、构建部署、验证和 PR 创建等待），6 轮累计 48 分钟。

代码实现（简化版）

# aq_loop.py 核心逻辑
while attempt < MAX_ATTEMPTS:
    # LLM 根据 bug 报告和上一次错误日志生成补丁
    patch = llm.generate_patch(bug_report, code_base, last_error)
    apply_patch(patch)
    
    # 运行硬性验证脚本
    result = subprocess.run(["./verify_p0.sh"], capture_output=True)
    
    if result.returncode == 0:
        create_pull_request(patch)
        break
    else:
        # 将 stderr 回传给 LLM 进行下一轮迭代
        last_error = result.stderr
        attempt += 1

参考文献

1. llama.cpp GitHub Repository
2. Qwen Model Card
3. new-api 项目说明