大模型接入CI流水线：pytest失败自动归因与飞书推送实战

1. 为什么我要把大模型塞进 CI 流水线

做后端和测试的同学大概都有这种体验：CI 跑完，pytest 报告里红了一片，几十条失败用例堆在一起，日志几千行，你一条条点开看，最后发现一半是环境抖动、三分之一是断言写死了时间戳，真正需要修的 bug 可能就两三个。这个"从一堆红色里找出真正问题"的过程，消耗的时间往往比修 bug 本身还多。

我所在的团队每周要跑上百次流水线，失败用例的归因基本靠人肉。后来我想，既然大模型在文本理解和归纳上已经够用了，为什么不把它接进 CI，让它在流水线跑完的那一刻，自动把失败用例读一遍、归类、给出可能原因，然后直接把报告推到飞书群里？这样大家早上到工位，群里已经躺着一份"今天挂了哪些、大概为什么挂、谁该去看"的清单。

这篇东西就是我把这个想法落地的完整记录。核心链路是pytest 产出结构化结果 → 大模型做失败归因 → 飞书机器人推送报告。涉及的关键词有 CI、大模型、飞书、pytest、归因。适合已经有 pytest 和 CI 基础、想进一步做自动化的同学，也适合只是想看看"大模型落地到工程里到底长什么样"的朋友。我会把选型理由、踩过的坑、参数怎么定、prompt 怎么写都摊开讲，你照着抄基本能跑通。

先说结论：这套东西上线后，我们团队平均每次流水线失败的排查时间从 20 多分钟压到了 5 分钟以内，而且因为报告是结构化的，谁负责哪块一目了然，扯皮都少了。下面进入正题。

2. 整体链路的拆解与关键选型

2.1 三个环节各自解决什么问题

整条链路其实就三段，我把它拆得很清楚，因为每一段的失败模式完全不同，混在一起排查会很痛苦。

第一段是结果采集。pytest 默认输出的是给人看的文本，但我要喂给大模型，最好是结构化的 JSON。pytest 自带--json-report插件，能输出每个用例的 nodeid、outcome、耗时、失败时的长文本（call 阶段的 crash message）。这一步的目标是把"哪些用例挂了、挂在哪一行、报了什么错"变成机器可读的数据。

第二段是归因分析。把失败用例的报错信息、堆栈、相关代码片段拼成 prompt，交给大模型，让它输出结构化的归因结果：失败类型（环境问题/断言问题/真实 bug/数据问题）、可能原因、建议动作、置信度。这一步是整个方案的核心价值所在。

第三段是报告推送。把归因结果渲染成飞书能识别的消息卡片或者表格，通过飞书自定义机器人 webhook 推送到群里。飞书机器人支持富文本和交互卡片，展示效果比纯文本好很多。

2.2 为什么选 pytest 而不是别的框架

我们团队本来就用 pytest，这是最直接的原因。但更实际的是，pytest 的插件生态让"结构化输出"这件事几乎零成本。pytest-json-report一个参数就能拿到完整结果，不用自己写 conftest 去 hook。如果你用的是 unittest 或者别的框架，思路一样，只是采集那一步要自己多写点代码。

另外 pytest 的 nodeid 命名规范（test_file.py::TestClass::test_method）天然适合做归因的粒度控制。我可以按文件、按类、按单个用例三个层级去聚合，大模型处理起来也清晰。

2.3 大模型怎么选：本地还是 API

这是最多人纠结的点。我的建议是分场景：

我们内部代码有一定敏感性，所以最终选的是本地部署。本地部署这块，Ollama 是最省事的，一条命令拉起模型，暴露一个兼容 OpenAI 格式的接口，代码里改个 base_url 就能用。模型我试过几个，7B 级别的做归因够用，但如果失败日志特别长、堆栈特别深，建议上更大的模型，或者至少选上下文长度够的，不然日志被截断，归因质量断崖式下跌。

提示：本地部署时一定要确认模型的上下文长度。很多失败日志加上代码片段轻松超过 8k token，上下文不够的模型会把关键堆栈截掉，归因就变成了瞎猜。

2.4 飞书机器人：webhook 还是应用

飞书推送有两条路。一条是群自定义机器人 webhook，配置最简单，一个 URL 搞定，支持文本、富文本、消息卡片。另一条是自建应用，能力更全（能读通讯录、能发到个人），但要走审批、配权限，重。

我的场景只是"往固定群推报告"，webhook 完全够用，而且不需要任何审批，五分钟就能配好。所以选 webhook。唯一要注意的是 webhook 有频率限制，别在循环里一条条发，要合并成一条消息发。

3. pytest 结果采集：把红色变成结构化数据

3.1 安装与最小可用配置

先装插件：

pip install pytest-json-report

跑测试的时候加参数：

pytest --json-report --json-report-file=report.json

跑完你会得到一个report.json，结构大致是这样：顶层有summary（通过/失败/错误计数）、tests（每个用例的详情）、duration。每个 test 对象里有nodeid、outcome、setup/call/teardown三个阶段，失败信息主要在call阶段的crash字段里，包含message和traceback。

这里有个坑我踩过：默认的 traceback 是带 ANSI 颜色码的，直接喂给大模型会浪费 token 还干扰理解。要么在 pytest 配置里关掉颜色（--color=no），要么在代码里用正则把\x1b\[[0-9;]*m这类转义序列清掉。我是在采集阶段统一清洗的，后面所有环节都受益。

3.2 只挑失败用例，别把通过的一起喂

report.json 里通过用例占大头，全喂给大模型纯属浪费。我的做法是先过滤：

import json def load_failures(path): with open(path, encoding="utf-8") as f: data = json.load(f) failures = [] for t in data.get("tests", []): if t.get("outcome") in ("failed", "error"): call = t.get("call", {}) crash = call.get("crash", {}) or {} failures.append({ "nodeid": t.get("nodeid"), "outcome": t.get("outcome"), "message": crash.get("message", ""), "traceback": crash.get("traceback", []), "duration": t.get("duration"), }) return failures

注意outcome有failed和error两种。failed是断言失败，error是 fixture 或 setup 阶段就炸了。这两种归因逻辑不一样，后面 prompt 里要区别对待。

3.3 日志清洗与截断策略

失败日志动辄几千行，直接塞给模型不现实。我的清洗流程是三步：

1. 去 ANSI 转义：正则清掉颜色码。
2. 去重复堆栈：pytest 的 traceback 经常把同一段框架代码重复打印，用集合去重。
3. 按重要性截断：保留最后的异常类型和消息（最关键），保留最靠近业务代码的那几帧堆栈，中间的框架帧可以砍掉。

截断这块我定了个规则：单条失败用例的文本上限 2000 字符，超了就保留"异常消息 + 最后 15 帧堆栈"。实测下来这个量级足够模型判断原因，再长边际收益很低。

注意：截断一定要保留异常类型那一行（比如AssertionError、TimeoutError、KeyError），这是模型判断失败类型的最强信号，砍了它归因准确率会明显下降。

3.4 把失败用例按文件聚合

如果一次挂了 50 个用例，逐条喂给模型既慢又贵。我的优化是先按测试文件聚合：同一个文件里的失败往往同源（比如某个 fixture 挂了导致整个文件全红）。聚合后先让模型判断"这个文件的失败是不是同一个根因"，如果是，就只输出一条归因，覆盖该文件下所有用例。

这一步能把大模型调用次数砍掉一大半。实现上就是按nodeid里::前面的文件路径分组，每组拼一个 prompt。

4. 归因 prompt 的设计：让模型说人话、给结论

4.1 归因结果要长什么样

在写 prompt 之前，先想清楚你要模型输出什么。我定义了一个固定的 JSON schema，这样后面渲染飞书报告时不用再解析自然语言：

{ "category": "env | assertion | real_bug | data | flaky", "root_cause": "一句话说清可能原因", "evidence": "从日志里摘出的关键证据", "suggestion": "建议的下一步动作", "confidence": "high | medium | low" }

category是枚举值，方便统计和路由。confidence很重要，低置信度的归因我会在报告里标灰，提醒人别全信。

4.2 prompt 模板与 few-shot 示例

我的 prompt 分三部分：角色设定、任务说明、输出格式约束，再加两个 few-shot 例子。核心是约束输出必须是 JSON，否则模型很容易给你写一段散文。

你是一名资深测试工程师，擅长分析 pytest 失败用例的根因。 下面给你一个测试文件的失败信息，请判断失败类型并给出归因。 失败类型定义： - env：环境问题（网络、依赖服务、端口占用、超时） - assertion：断言本身写得不合理（如硬编码时间、浮点数比较） - real_bug：被测代码存在真实缺陷 - data：测试数据问题（脏数据、数据缺失） - flaky：偶发、不稳定，重跑可能通过 只输出 JSON，不要任何额外文字。格式： {"category": "...", "root_cause": "...", "evidence": "...", "suggestion": "...", "confidence": "..."} 失败信息： {payload}

few-shot 我放了两个：一个是TimeoutError判成 env，一个是AssertionError里比较时间戳判成 assertion。有了例子，模型输出的稳定性明显提升。

4.3 温度、超时与重试

归因是确定性任务，温度设 0 或接近 0，别让它发挥创造力。超时我设了 30 秒，本地小模型偶尔会卡，超时就降级到规则兜底（比如看到TimeoutError直接判 env）。

重试策略：JSON 解析失败时重试一次，并在 prompt 里追加一句"上次输出不是合法 JSON，请只输出 JSON"。实测这一招能救回大部分格式错误。

4.4 规则兜底：别让大模型成为单点

大模型会抽风，网络会断，本地服务会挂。所以我加了一层规则兜底：用关键词匹配先做一轮粗分类，大模型失败时用规则结果顶上。规则很简单：

• 含TimeoutError/ConnectionError→ env
• 含AssertionError且含datetime/timestamp→ assertion
• 含KeyError/IndexError且堆栈指向业务代码 → real_bug

规则准确率不如模型，但胜在永远可用。这套"模型优先、规则兜底"的组合，让整条链路的可用性上了一个台阶。

5. 飞书报告推送：把 JSON 变成人愿意看的东西

5.1 webhook 机器人的最小配置

在飞书群里添加自定义机器人，拿到 webhook URL。发一条最简单的文本消息验证连通：

curl -X POST -H "Content-Type: application/json" \ -d '{"msg_type":"text","content":{"text":"CI 归因报告测试"}}' \ https://open.feishu.cn/open-apis/bot/v2/hook/你的token

能收到就说明通了。注意 webhook 有安全设置，可以配关键词、IP 白名单或签名校验。生产环境建议至少配签名，防止 URL 泄露被人乱发。

5.2 用消息卡片展示归因结果

纯文本太丑，我用的是飞书的消息卡片（interactive card）。卡片支持标题、分栏、字段、按钮，展示归因结果很合适。结构上我这样组织：

• 卡片标题：CI 失败归因 | 分支 xxx | 共 N 条失败
• 按 category 分组，每组一个小节
• 每条归因显示：用例名、根因、建议、置信度标签
• 底部放一个"查看完整报告"的链接按钮

飞书卡片 JSON 有点长，但结构清晰。核心是elements数组，每个元素可以是div（文本块）、hr（分割线）、action（按钮）。字段用fields做两列布局，比纯文本紧凑。

5.3 表格消息：适合批量展示

如果失败用例特别多，卡片会很长，飞书对单条消息有大小限制。这时候可以用飞书的表格消息（msg_type: "post"里的富文本，或者专门的表格组件）。我一般超过 15 条就切表格模式，一行一个用例，列是"用例/类型/根因/置信度"，扫一眼就清楚。

提示：飞书单条消息有大小上限，卡片内容太长会被截断或直接发送失败。我的经验是控制在 30KB 以内，超了就分页或者切表格。

5.4 频率限制与合并发送

飞书 webhook 有频率限制（一般每分钟若干条）。千万别在循环里一条条发，一定要先在内存里把所有归因结果合并成一条消息再发。我见过有人每个失败用例发一条，结果被限流，报告发一半就断了。

另外，如果一次流水线失败用例特别多，我会在报告开头加一句汇总："本次共 47 条失败，其中 env 类 30 条（疑似同一环境问题），real_bug 5 条，建议优先看 real_bug。" 这句话是让模型对整体再做一次归纳生成的，能帮人快速抓住重点。

6. 接进 CI：触发时机与流水线编排

6.1 什么时候触发归因

归因任务应该在 pytest 跑完之后、且只在有失败时触发。全绿的时候没必要浪费模型调用。在 CI 配置里加个判断：report.json里summary.failed > 0才跑归因脚本。

触发时机还有个细节：是每个 PR 都跑，还是只在主分支跑？我的做法是 PR 和主分支都跑，但 PR 的报告只发给提交者（通过飞书 @ 或者私聊），主分支的报告发到公共群。这样既不影响个人开发节奏，又能让团队看到主干健康度。

6.2 流水线里的步骤编排

以常见的 CI 配置为例，步骤大致是：

steps: - name: run tests run: pytest --json-report --json-report-file=report.json --color=no continue-on-error: true - name: analyze failures run: python analyze.py report.json if: failure() - name: notify feishu run: python notify.py result.json if: failure()

continue-on-error: true很关键，否则测试一挂流水线就中断，后面的归因步骤根本不会执行。归因和通知步骤用if: failure()保证只在失败时跑。

6.3 超时与失败隔离

大模型调用可能慢，CI 步骤要设超时，别让归因把整条流水线拖死。我给归因步骤设了 3 分钟超时，超时就跳过，发一条"归因超时，请手动查看报告"的降级消息。

失败隔离的意思是：归因脚本自己挂了，不能影响测试结果的记录。所以归因脚本要 try/except 包住，出错就记日志、发降级通知，绝不抛异常中断流水线。

6.4 缓存与增量：别重复分析

同一个失败用例，如果连续几次流水线都是同样的报错，没必要每次都调模型。我加了个简单的缓存：用nodeid + 报错消息的 hash做 key，命中缓存就直接用上次的归因结果。缓存有效期设 24 小时，避免代码改了还用旧结论。

这一招在"某个环境问题持续挂一整天"的场景下特别省，模型调用量能降 70% 以上。

7. 实测踩过的坑与调优经验

7.1 归因准确率上不去的三个原因

上线初期归因准确率大概只有六成，我排查后发现三个主因：

第一，日志截断把关键信息砍了。之前我按字符数粗暴截断，结果异常类型那行被砍掉，模型只能瞎猜。改成"保留异常消息 + 尾部堆栈"后，准确率明显回升。

第二，prompt 里没给代码上下文。光看报错，模型不知道这行代码是干嘛的。我后来在 prompt 里附上失败行前后各 10 行代码，模型判断"这是断言写死了时间"就准多了。

第三，few-shot 例子太少。加到 4 个覆盖主要失败类型后，输出格式和分类都稳定了。

7.2 模型把 flaky 判成 real_bug 怎么办

flaky（偶发失败）和 real_bug 最难区分，因为报错长得一样。我的解法是引入历史数据：如果同一个用例最近 10 次里失败过又通过过，就在 prompt 里告诉模型"该用例历史上有偶发通过记录"，模型就会倾向判 flaky。

这个历史数据从哪来？我是每次流水线把结果写进一个小数据库（SQLite 就够），归因时查一下。成本很低，但对 flaky 判断帮助巨大。

7.3 成本与耗时的真实数据

本地部署的话，单次归因（聚合后约 5-10 个 prompt）耗时在 20-40 秒，基本可以忽略。如果用云端 API，按 token 算，一次流水线失败归因大概几分钱到几毛钱，看失败量和日志长度。

真正耗时的是日志清洗和聚合，如果失败用例上百条，光处理 JSON 就要几秒。所以我在采集阶段就做了过滤，只保留失败用例，减少后续处理量。

7.4 让报告"可执行"而不是"可读"

最开始我的报告只是把归因结果列出来，大家看完还是不知道该干嘛。后来我加了两样东西：一是建议动作（比如"检查 xxx 服务是否启动"、"重跑该用例确认是否 flaky"），二是责任人路由（根据测试文件路径映射到负责的同事，在飞书里 @ 他）。

加了这两样之后，报告从"信息展示"变成了"行动指令"，团队反馈好了很多。这也是我觉得这套方案真正的价值点——不是省了看日志的时间，而是把"发现问题"和"分配任务"合并成了一步。

8. 几个容易被忽略的工程细节

8.1 敏感信息脱敏

失败日志里可能带 token、密码、内网地址。喂给大模型之前一定要脱敏，尤其是用云端 API 的时候。我写了个正则列表，匹配常见的password=、token=、Authorization:等模式，替换成***。本地部署虽然数据不出域，但脱敏也是好习惯，万一日志被转发呢。

8.2 归因结果的可追溯

每条归因结果我都存了一份原始日志和模型输出，方便事后复盘"模型这次判得对不对"。这些数据积累起来，还能用来评估模型效果、迭代 prompt。别小看这个，没有反馈闭环，prompt 优化就是盲调。

8.3 别让机器人变成噪音源

如果每次失败都往群里推，时间长了大家就麻木了，直接屏蔽。我的做法是分级推送：只有包含 real_bug 的报告才 @ 全员，纯 env 问题的报告静默发送（不 @），flaky 的直接不推只记录。这样群里的消息都是"值得看的"，信噪比高。

8.4 本地模型服务的稳定性

本地部署的模型服务偶尔会 OOM 或者响应慢。我在归因脚本里加了健康检查：调用前先 ping 一下服务，不通就直接走规则兜底，别傻等超时。另外模型服务最好配个进程守护，挂了自动重启。

这套东西我从想法到上线大概花了两周，其中一半时间在调 prompt 和清洗日志。真正写代码的部分反而不多。如果你也想做，建议先用免费 API 把链路跑通，验证价值之后再考虑本地部署。链路本身不复杂，难的是把每个环节的边界情况处理好——而这恰恰是决定它能不能真正用起来的关键。