1. 为什么我要把大模型塞进 CI 流水线做过持续集成的朋友都懂一个场景凌晨两点流水线红了你打开报告一看三百个用例里挂了十七个。点进去逐个翻日志有的是断言失败有的是超时有的是环境问题还有几个是上游接口改了字段。等你把十七个用例的失败原因分门别类整理完天已经亮了而真正修复可能只需要改两行代码。这种排查两小时、修复五分钟的割裂感是我决定动手改造的直接原因。我所在的项目是一个中等规模的 Python 后端服务测试框架用的是pytestCI 跑在自建的流水线平台上团队日常沟通重度依赖飞书。每天流水线触发几十次失败用例的归因完全靠人肉看日志效率极低。我的目标很明确让大模型在流水线失败的那一刻介入自动读取失败用例的日志和上下文输出一份结构化的归因报告再通过飞书机器人把报告直接推到群里。整套东西跑通之后团队从看到红点就头疼变成了看到报告直接知道该找谁改。这篇文章我会把整套方案的选型逻辑、核心实现、踩过的坑全部摊开讲。适合两类人看一类是正在做 CI/CD 优化、想让流水线更聪明的工程同学另一类是想把大模型能力落地到具体工程场景、但不知道从哪下手的开发者。不需要你有大模型训练经验只要会写 Python、懂基本的 pytest 和 Webhook就能照着复现。先说清楚这套方案解决的核心问题把非结构化的失败日志转化成结构化的归因结论。传统做法是写正则匹配关键字但日志格式千变万化正则维护成本极高。大模型的价值在于它能理解语义——同样是ConnectionError它能区分是网络抖动、下游服务挂了、还是配置写错了地址。这是规则引擎做不到的。2. 整体架构设计与关键选型考量2.1 数据流转的完整链路整套系统的数据流是这样的pytest 跑完测试后生成 JUnit XML 或 JSON 格式的报告CI 脚本解析出失败用例列表对每个失败用例提取日志片段和堆栈信息组装成 Prompt 发给大模型大模型返回结构化的归因结果脚本把结果汇总成表格最后通过飞书机器人的 Webhook 推送。这里有个关键设计决策归因是逐用例做还是批量做。我一开始想的是把所有失败用例打包成一个 Prompt 一次性发给大模型省 token 也省调用次数。实测下来发现两个问题一是失败用例多的时候 Prompt 会超长触发上下文长度限制二是大模型在长上下文里容易串味把 A 用例的失败原因安到 B 用例头上。后来改成逐用例归因每个用例独立一次调用准确率明显提升。虽然调用次数多了但单次 Prompt 短、响应快总体耗时反而可控。提示如果你的失败用例经常超过 20 个建议加一层并发控制比如用线程池限制同时发起的请求数避免把大模型 API 的速率限制打爆。2.2 大模型选型为什么我不迷信最强模型选模型这块我踩过不少坑。一开始用的是某款参数很大的通用模型效果确实好但成本和延迟都高一次归因要等七八秒几十个用例下来光等待就几分钟。后来我换成了中等规模的模型专门针对日志归因这个任务调了 Prompt效果反而更稳。我的选型原则是三条响应速度优先于绝对能力、结构化输出稳定性优先于文采、成本可控优先于参数规模。归因这个任务本质上是分类摘要不需要模型有很强的推理能力它只要能准确识别日志里的关键信息、匹配到预定义的失败类型就行。具体来说我准备了几个候选本地部署的开源模型、云端 API 的中等模型、以及一些免费额度较大的 API。最终线上跑的是云端中等模型原因是延迟稳定在 1-2 秒而且支持 JSON 格式的强制输出。本地部署的方案我也试过用 Ollama 拉了一个 7B 的模型在开发机上跑没问题但放到 CI 服务器上没有 GPU推理一次要十几秒不实用。如果你们团队有 GPU 资源本地部署在数据安全上确实更放心这个后面会细说。方案类型延迟成本数据安全适用场景云端中等模型 API1-2秒低需评估大多数团队首选云端大参数模型 API5-10秒高需评估复杂归因场景本地部署 7B 模型10秒无GPU硬件成本最高有GPU、数据敏感本地部署 7B 模型2-3秒有GPU硬件成本最高有GPU资源2.3 飞书推送为什么选机器人 Webhook 而不是应用飞书这边有两种接入方式自建应用和群机器人 Webhook。我选的是群机器人 Webhook理由很简单——够用、够快、零审批。自建应用要走企业管理员审批、配置权限范围流程长而群机器人只需要在群里添加一个自定义机器人拿到 Webhook 地址就能推消息五分钟搞定。群机器人支持的消息类型里我最常用的是富文本post和交互式卡片interactive。纯文本太丑表格用富文本能勉强展示但真正好看的是交互式卡片。不过卡片的消息体结构比较复杂调试成本高。我的做法是日常归因报告用富文本包含一个简化的表格如果失败用例特别多或者需要重点提醒才用卡片。注意群机器人 Webhook 有频率限制默认每分钟最多 100 条消息。如果你把每个失败用例都单独推一条很容易触发限流。正确做法是汇总成一条消息推送。3. 核心实现细节与实操要点3.1 pytest 报告解析拿到干净的失败数据pytest 默认的输出是给人看的机器解析起来很痛苦。我强烈建议加上--junitxml参数生成 XML 报告或者用pytest-json-report插件生成 JSON。JSON 更好解析我选的是后者。安装插件pip install pytest-json-report跑测试时加上参数pytest --json-report --json-report-filereport.json生成的 JSON 里tests数组包含每个用例的结果失败的用例会有outcome: failed并且call字段里有longrepr完整的失败堆栈。这个longrepr就是我们要喂给大模型的核心素材。但直接把这个丢给大模型有个问题里面包含了大量路径、行号、无关的框架堆栈噪音太多。我写了一个清洗函数只保留关键部分import re def clean_traceback(longrepr: str) - str: # 去掉文件绝对路径只保留文件名和行号 longrepr re.sub(r/[\w/.-]/(\w\.py), r\1, longrepr) # 去掉内存地址 longrepr re.sub(r0x[0-9a-fA-F], 0xXXX, longrepr) # 截断过长的堆栈保留最后 50 行 lines longrepr.split(\n) if len(lines) 50: lines lines[-50:] return \n.join(lines)清洗这一步非常关键。我实测过不清洗直接发大模型经常被路径里的项目名干扰把模块名误判成失败原因。清洗之后归因准确率大概能提升两成。3.2 Prompt 设计让大模型稳定输出结构化结果Prompt 是整套系统的灵魂。我前后改了十几版总结出几个要点。第一明确角色和任务边界。开头就告诉它你是一个 CI 失败归因助手而不是让它自由发挥。第二给出固定的输出格式最好用 JSON Schema 约束。第三提供失败类型枚举让它从预定义类别里选而不是自己编。我最终的 Prompt 模板长这样你是一个 CI 失败归因助手。请分析下面这个 pytest 失败用例判断失败原因。 失败用例名{test_name} 失败堆栈 {traceback} 请从以下类型中选择最匹配的一项 - ASSERTION_FAILED断言失败实际值与预期值不符 - TIMEOUT超时 - CONNECTION_ERROR网络或下游服务连接问题 - ENV_ERROR环境配置问题 - DATA_ERROR测试数据问题 - CODE_BUG疑似被测代码的逻辑缺陷 - UNKNOWN无法判断 请严格按以下 JSON 格式输出不要输出任何其他内容 { category: 类型, reason: 一句话说明失败原因, suggestion: 一句话修复建议, confidence: high/medium/low }这里有个细节confidence 字段。让模型自己评估置信度低置信度的用例我会在报告里标黄提示人工复核。这个设计很实用因为大模型不是万能的有些日志它确实看不懂与其让它瞎猜不如让它承认不确定。提示如果你的模型 API 支持response_format参数强制 JSON 输出一定要开启。我遇到过模型在 JSON 前后加好的以下是分析结果这种废话导致解析失败。强制 JSON 能省掉一堆容错代码。3.3 飞书消息组装把归因结果变成好看的报告归因结果拿到后要组装成飞书能识别的消息格式。我用的是富文本 post 类型结构如下def build_feishu_post(results: list) - dict: content [] # 标题行 content.append([{tag: text, text: fCI 归因报告 | 失败 {len(results)} 个用例}]) # 每个用例一行 for r in results: line f[{r[category]}] {r[test_name]}{r[reason]} content.append([{tag: text, text: line}]) return { msg_type: post, content: { post: { zh_cn: { title: 流水线失败归因, content: content } } } }实际用的时候我会按 category 分组把同一类的用例聚在一起这样看起来更清晰。比如所有 CONNECTION_ERROR 的排在一起一眼就能看出哦是下游服务挂了不是我的代码问题。发送就是往 Webhook 地址 POST 这个 JSONimport requests def send_to_feishu(webhook_url: str, payload: dict): resp requests.post(webhook_url, jsonpayload, timeout10) resp.raise_for_status()3.4 并发与超时控制别让归因拖垮流水线归因本身要调大模型 API如果串行处理几十个用例光等待就能把流水线拖慢好几分钟。我用concurrent.futures.ThreadPoolExecutor做了并发同时限制最大并发数为 5避免触发 API 限流。from concurrent.futures import ThreadPoolExecutor, as_completed def batch_analyze(failures: list, max_workers: int 5): results [] with ThreadPoolExecutor(max_workersmax_workers) as executor: future_map { executor.submit(analyze_one, f): f for f in failures } for future in as_completed(future_map, timeout120): try: results.append(future.result()) except Exception as e: # 单个失败不影响整体 results.append({category: UNKNOWN, reason: str(e)}) return results这里有个坑一定要给整个批次设总超时。我有一次遇到大模型 API 抽风某个请求卡了五分钟不返回整个流水线就挂在那等。后来加了timeout120超时的用例直接标记为 UNKNOWN不阻塞主流程。4. 完整实操流程与关键环节实现4.1 环境准备与依赖清单先把依赖列清楚避免你到处找包pip install pytest pytest-json-report requests openai如果你用的是其他大模型厂商的 API把openai换成对应的 SDK 即可大多数厂商都兼容 OpenAI 的接口格式。飞书推送只需要requests不需要额外的 SDK。环境变量我建议这样管理别把密钥硬编码进代码export LLM_API_KEYyour_key export LLM_BASE_URLhttps://your-api-endpoint export FEISHU_WEBHOOKhttps://open.feishu.cn/open-apis/bot/v2/hook/xxxxx4.2 主流程脚本的完整实现我把整个流程封装成一个脚本ci_analyzer.pyCI 在测试步骤之后调用它。核心逻辑分四步读报告、清洗数据、并发归因、推送飞书。import os import json import re import requests from concurrent.futures import ThreadPoolExecutor, as_completed from openai import OpenAI client OpenAI( api_keyos.environ[LLM_API_KEY], base_urlos.environ[LLM_BASE_URL] ) def load_failures(report_path: str) - list: with open(report_path, encodingutf-8) as f: report json.load(f) failures [] for t in report.get(tests, []): if t.get(outcome) failed: failures.append({ name: t[nodeid], traceback: clean_traceback(t.get(call, {}).get(longrepr, )) }) return failures def analyze_one(failure: dict) - dict: prompt PROMPT_TEMPLATE.format( test_namefailure[name], tracebackfailure[traceback] ) resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], temperature0, response_format{type: json_object} ) result json.loads(resp.choices[0].message.content) result[test_name] failure[name] return result def main(): failures load_failures(report.json) if not failures: print(没有失败用例跳过归因) return results batch_analyze(failures) payload build_feishu_post(results) send_to_feishu(os.environ[FEISHU_WEBHOOK], payload) print(f已推送 {len(results)} 个用例的归因报告) if __name__ __main__: main()temperature0这个参数很重要它让模型的输出尽可能确定同样的日志每次归因结果一致避免今天说是超时、明天说是断言失败这种飘忽。4.3 接入 CI 的配置方式不同 CI 平台的配置语法不一样但思路一致在测试步骤之后加一个归因步骤并且设置成即使测试失败也要执行。以常见的 YAML 配置为例steps: - name: Run tests run: pytest --json-report --json-report-filereport.json continue-on-error: true - name: Analyze failures run: python ci_analyzer.py if: always()continue-on-error: true和if: always()是关键。如果不加测试一失败流水线就中断了归因步骤根本不会执行。这个坑我踩过当时调试了半天以为是脚本问题其实是流水线配置的问题。4.4 参数计算并发数和超时怎么定这两个参数不是拍脑袋定的我按下面的逻辑算过。并发数假设平均每个用例归因耗时 2 秒你有 30 个失败用例。串行需要 60 秒并发 5 路需要 12 秒。但并发太高会触发 API 限流我实测下来 5-8 路是比较稳的区间。如果你的 API 有明确的 QPS 限制用QPS × 单次耗时反推最大并发数。超时单次请求超时设 15 秒正常 2 秒留足余量批次总超时设用例数 / 并发数 × 单次超时 × 1.5。比如 30 个用例、5 并发就是30/5 × 15 × 1.5 135秒。我一般直接设 120-180 秒。提示如果你的流水线本身有总时长限制记得把归因步骤的耗时算进去。我见过有团队因为归因步骤超时导致整个流水线被强制终止的。5. 常见问题与排查技巧实录5.1 归因结果不准怎么办这是最高频的问题。我总结了几种典型情况和对应解法。第一种模型把环境问题误判成代码 bug。这种情况通常是日志里既有报错又有业务信息模型抓错了重点。解法是在 Prompt 里明确告诉它优先关注异常类型和错误码而不是业务日志。我还会在清洗阶段把明显的 INFO 级别日志过滤掉。第二种同类失败被归到不同类别。比如两个都是连接超时一个判成 TIMEOUT一个判成 CONNECTION_ERROR。这是类别边界模糊导致的。解法是把类别定义写得更细在 Prompt 里给每个类别配一个例子。第三种模型输出格式错误。前面提过用response_format强制 JSON 能解决大部分。如果还是出错加一层容错解析用正则从文本里抠出 JSON 部分。问题现象可能原因解决方向环境问题判成代码bug日志噪音干扰清洗日志、Prompt强调异常类型同类失败分类不一致类别边界模糊细化类别定义、补充示例输出格式错误模型未遵守格式强制JSON、容错解析归因结果为空日志被截断调整截断行数、保留关键段5.2 飞书消息发送失败排查飞书推送失败一般有三个原因Webhook 地址错了、消息体格式不对、触发限流。排查顺序我建议这样先用curl手动发一条最简单的文本消息确认 Webhook 通不通curl -X POST -H Content-Type: application/json \ -d {msg_type:text,content:{text:test}} \ YOUR_WEBHOOK_URL如果这条能通说明 Webhook 没问题那就是消息体格式的问题。富文本和卡片的格式很容易写错建议先用官方文档里的示例跑通再改成自己的内容。限流的话返回码里会有提示。解法就是前面说的汇总成一条消息别拆开发。5.3 成本和延迟的平衡有人会担心大模型调用成本。我算过一笔账每次归因的 Prompt 大概 500-1000 token输出 100 token 左右。按中等模型的定价一次归因成本不到一分钱。一天跑 50 次流水线每次平均 5 个失败用例一天也就 250 次调用成本几毛钱。这个投入换来的效率提升完全值得。延迟方面如果你们对流水线时长特别敏感可以做个开关只在主分支或者发布分支上开启归因feature 分支跳过。这样既保证了关键分支的排查效率又不影响日常开发的流水线速度。5.4 数据安全与脱敏把日志发给第三方 API有些团队会担心数据泄露。我的做法是加一层脱敏在清洗阶段把可能包含敏感信息的字段如用户 ID、手机号、内部 IP替换成占位符。def desensitize(text: str) - str: text re.sub(r\b1[3-9]\d{9}\b, [PHONE], text) text re.sub(r\b\d{1,3}(\.\d{1,3}){3}\b, [IP], text) text re.sub(r\b[A-Za-z0-9._%-][A-Za-z0-9.-]\.[A-Z|a-z]{2,}\b, [EMAIL], text) return text如果你们的数据敏感度极高那就只能走本地部署路线。用 Ollama 或者类似工具在本地跑一个模型虽然慢一点但数据不出内网。这个取舍要看团队的具体要求。6. 几个让我少走弯路的实操心得第一先跑通最小闭环再优化。我一开始想做得完美又是分类又是优先级又是自动建单结果卡在 Prompt 调优上好几天。后来砍掉所有花哨功能就做归因推送这一件事半天就跑通了。跑通之后再逐步加功能心态完全不一样。第二保留原始日志的存档。归因报告是给人看的摘要但真正修复的时候还是得看原始日志。我在推送报告的同时会把完整的归因结果含原始 traceback存一份到流水线的产物里方便回溯。第三定期 review 归因准确率。我每周会抽十分钟看看这周的归因报告统计一下有多少是判错的。判错的案例我会拿来改 Prompt。这个习惯坚持下来准确率从最初的六成提升到了九成以上。第四给团队一个反馈渠道。我在飞书报告里加了一句如归因有误请回复本条消息这样同事发现错误可以直接反馈我收集起来统一优化。比我自己闷头猜哪里不准高效多了。这套东西跑了大半年最大的感受是大模型在工程场景里的价值不在于它多聪明而在于它能把人从重复的、低价值的判断劳动里解放出来。CI 失败归因就是典型的例子——它不需要多深的推理只需要快速、稳定、不知疲倦地做分类和摘要。找对了场景中等模型也能发挥出超出预期的效果。