Opik E2E 测试失败调查指南从红色 CI 到回归 / 抖动分类与修复提案【免费下载链接】comet-llmDebug, evaluate, and monitor your LLM applications, RAG systems, and agentic workflows with comprehensive tracing, automated evaluations, and production-ready dashboards.项目地址: https://gitcode.com/GitHub_Trending/co/comet-llm导读在 Opik 项目中当 Playwright 驱动的端到端测试位于tests_end_to_end/e2e/在 CI、Allure TestOps 或本地运行时变红你需要一套可复现、有证据支撑的调查流程而不是凭直觉改选择器。本文基于仓库中的investigate-e2e-failure命令及其背后的debugging-e2e-tests技能完整讲解这条只读诊断链路如何从四种失败入口定位证据、如何把失败判定为真实回归regression、抖动flake或环境 / 选择器漂移environment / selector drift以及如何输出带证据引用的修复提案。读完你将掌握一套可立即投入使用的 E2E 排障方法论并能与writing-e2e-tests技能衔接完成修复落地。一、命令定位investigate-e2e-failure 是什么在仓库的.agents/commands/comet/investigate-e2e-failure.md中定义了一个面向 AI Agent 的命令级工作流其核心定位可以概括为三句话调查一次失败的 Opik E2E 测试并提出修复方案证据驱动命令负责收集证据trace、error、history并将失败分类为真实回归、抖动或环境 / 选择器漂移只读原则它只做诊断和提案绝不修改测试代码。该命令并不自包含全部逻辑而是明确要求Invoke thedebugging-e2e-testsskill and follow it exactly.也就是说命令是入口真正承载调查循环的是.agents/skills/debugging-e2e-tests/SKILL.md这份技能文档。技能里完整定义了证据来源allure-testopsMCP、gh构件、npx playwright show-trace、分类启发式与五步循环。本文将以这份技能为主体展开。完成标准Success criteria命令定义的验收标准正好构成一次调查的产出清单也是你判断一次排障是否完成的检查表给出判定结论regression / flake / environment-or-selector 三选一并附带置信度引用证据失败的 trace 步骤、错误信息、历史模式以及如果存在相关联的代码变更给出具体的修复提案若判定为已知抖动则给出轮询poll/ 隔离quarantine/ 不修复no-fix的建议零修改本次调查不做任何编辑修复落地需移交给writing-e2e-tests技能。二、先理解证据在哪里Opik E2E 套件的结构要调查失败首先要清楚失败现场存放在哪里。.agents/skills/debugging-e2e-tests/SKILL.md明确给出了三类证据位置与tests_end_to_end/e2e/目录结构一一对应。2.1 本地运行证据本地执行 Playwright 测试时失败现场默认保留在当前目录下Playwright tracestests_end_to_end/e2e/test-results/失败时保留Allure 结果tests_end_to_end/e2e/allure-results/。这些路径由 playwright.config.ts 中的 reporter 与 use 配置决定trace: retain-on-failure、screenshot: only-on-failure、video: retain-on-failure同时 Allure 插件输出到allure-results目录。2.2 CI 运行证据CI 上每次运行会产出三个构件保留期 7 天构件名内容test-results-v2Playwright traces 视频playwright-report-v2HTML 格式报告allure-results-v2Allure 结果下载方式技能原文命令gh run download run-id -n test-results-v2 -D dir2.3 Allure TestOpsAllure TestOpscomet.testops.cloudproject id1在 CI 期间实时接收测试结果流。launch 命名规则为Opik v2 … tier - run_id其中尾部数字是 GitHub Actions 的 run id中间的 env 段会变化E2E、Post-Merge、Local、staging、production。利用 launch 中的jobRun.url可以直接反查到对应的 GitHub Actions 运行。2.4 套件的技术底座佐证E2E 套件的运行方式对理解失败现场有帮助Playwright 的webServer指令会自动拉起两个服务——services/opik-sdk-driver一个用uv运行的 FastAPI 应用包装 Python SDK 为 TypeScript 客户端提供 seeding 路由见 playwright.config.ts 中uv run uvicorn opik_sdk_driver.main:app --port 5175services/mock-token-authMock OAuth2 token 服务用于动态 token 认证的 specOPIK-7940封闭式设计不依赖外部密钥。套件还通过global-setup.ts打上每次运行的runIdglobal-teardown.ts负责清理本次运行创建的所有cuj-{runId}-*项目见 tests_end_to_end/e2e/README.md。理解这些基础设施能帮助你在失败是否由环境引起这一分类维度上做出更准确的判断。三、工具链一张排障工具箱清单技能文档定义了四个核心工具调查过程基本就是这四个工具的轮流使用allure-testopsMCP已配置连接—— 信息最丰富的证据源。技能文档给出了三个验证过的调用list_launches(projectId: 1, search: run_id or name fragment, sort: [createdDate,DESC])或search_launches(rql: …)定位 launchlist_test_results(launchId)获取每个测试的name、fullNamespec 路径 行号例如datasets/dataset-crud-smoke.spec.ts:8:7、status、TestOps 计算的flaky标记、muted/known、tags、jobRun.url对应 GitHub Actions 运行以及 result 的id可用search过滤到失败的测试get_test_result_history(id)该测试在最近多次 launch 中的通过 / 失败时间线 —— 这是抖动flake判定的核心信号。ghCLI——gh run view run-id定位失败 jobgh run download run-id -n test-results-v2 -D dir拉取 trace 构件。npx playwright show-trace trace.zip—— 在tests_end_to_end/e2e/目录下打开 trace查看精确失败的步骤、当时的 DOM 快照以及该时刻的 console / network。git—— 对比可疑变更与失败测试的代码路径用于相关性分析。四、调查五步循环核心章节技能的骨架是一条五步流水线用 DOT 图表示为1. Resolve entry point → 2. Gather evidence → 3. Classify → 4. Diagnose → 5. Report propose (no edits)Step 1 —— 解析入口点Resolve the entry point无论失败从哪来第一步都是把它归一化为一个失败的测试 它的证据在哪里。四种入口的归一化方式红色 CI check / Actions run取 run id。gh run view run-id找失败 job用list_launches(projectId: 1, search: run-id)找匹配 launchtrace 在test-results-v2构件中用gh run download拉取。TestOps launch直接查询list_test_results(launchId)过滤出失败结果。测试名例如dataset-crud-smoke在最近的 launch 上用list_test_results加search找到 resultid再拉取其历史。本地失败直接使用本地的test-results/trace 和allure-results/对于未提交的本地运行TestOps 里可能没有对应记录这很正常无需强求。Step 2 —— 收集证据Gather evidence证据收集的四个要点失败断言与错误消息来自 trace、报告或 TestOps resulttrace对保留 / 下载的.zip执行npx playwright show-trace重点读失败步骤、该时刻的 DOM 快照及其前后的 console / network截图 / 视频存在则一并使用配置为only-on-failure/retain-on-failure测试历史通过get_test_result_history(id)获取并结合 TestOps result 上的flaky标记。优雅降级当 TestOps 不可达例如纯本地运行时跳过历史收集退回到 trace diff 推理。Step 3 —— 分类Classify这是整个调查的核心决策点判定为真实回归real regression、抖动flake还是环境 / 选择器漂移environment / selector drift。技能给出的三条启发式历史信号优先一条干净的连续通过记录、在某个相关变更之后立刻断裂 → 倾向 regression间歇性通过 / 失败且无相关变更或 TestOpsflaky: true→ 倾向 flakeDiff 相关性最近的变更是否触及失败断言所经过的代码路径页面 / 组件、POM 方法、fixture触及 → 大概率 regression失败区域完全未被触碰 → 大概率 flake 或环境问题默认保守当历史呈现间歇性且不存在相关 diff 时默认判为 flake / uncertain——没有证据就不要轻易扣上 regression 的帽子。Step 4 —— 诊断Diagnose在分类基础上定位根因且必须基于引用的证据具体 trace 步骤、错误、历史模式而不是猜测。技能提供了四个针对 Opik 套件的诊断透镜按优先级应用先验证测试渲染再怪罪后端一条 X didnt appear 的失败往往不是后端回归而是 DOM 竞态loading spinner 还在转、最终一致性写入尚未落盘。检查失败步骤处的 DOM 快照即可确认选择器漂移前端改了 accessible name 或删除了data-testid导致 locator 无法再解析最终一致性状态异步打分 / 摄入scoring / ingestion需要轮询poll而不是固定等待Fixture 种子形状不匹配页面渲染出空 / 部分状态是因为种子数据与断言期望的形状不一致。这些透镜与.agents/skills/writing-e2e-tests/conventions.md中Verify the test render before blaming the backend的约定一脉相承——说明诊断准则与编写准则在设计上是对齐的。Step 5 —— 报告 提案Report propose不编辑输出三件套判定Verdict分类regression / flake / environment-or-selector 置信度证据Evidencetrace 步骤、错误、历史模式、关联变更如有逐项引用修复提案Proposed fix必须具体。回归 → 指明要改的代码 / 选择器 / 轮询点抖动 → 用expect.poll替代固定等待、隔离quarantine或无需改代码——已知抖动重试。最后重申边界不编辑任何东西。开发者要应用修复时移交给writing-e2e-tests技能。五、分类启发式背后的工程逻辑为什么技能在分类上如此强调证据与保守默认从仓库约定可以还原出它的工程动机失败信息密度被刻意放大.agents/skills/writing-e2e-tests/conventions.md强制每个 POM 方法体和测试逻辑阶段用test.step()包裹并经由回调返回。这使得 Playwright trace viewer 和 Allure timeline 可读——一次失败不再是一堵没有叙事的操作墙而是一个个语义化的阶段。没有这个约定Step 2 的 trace 阅读会寸步难行。选择器优先级是抖动治理的第一道防线约定规定选择器优先级为getByTestIdgetByRolegetByLabelgetByText CSS/XPath并明令结构型 CSS 选择器如tbody tr:nth-child(2)是抖动的主要来源——一旦出现就应给前端组件补data-testid。这条约定直接支撑了 Step 4 中selector drift透镜的判断标准。expect.soft是例外而非默认约定指出默认应使用硬断言expect(...)让 trace 精确停在假设断裂之处只有像workspace-roles-permissions.spec.ts这种一次性审计大量独立事实的场景才用expect.soft。这解释了为什么技能要求失败的断言 精确的错误消息作为首要证据——套件本身被设计成一次失败信息最清晰。fixture 与 teardown 所有权清晰teardown 归 fixture 管无论通过、失败还是超时都会执行destructive 测试需要 bystander 实体。这让测试本身是否污染了环境这类环境归因问题在调查时有章可循。六、边界与后续衔接6.1 只读边界技能文档用两段话锁死了边界只读不做测试编辑也不为调查而重跑套件四种入口全部覆盖CI、TestOps launch、测试名、本地失败没有 TestOps 时优雅降级本地失败仅靠 trace diff。6.2 与 writing-e2e-tests 的分工调查与编写是两条截然不同的流水线技能文档明确区分debugging-e2e-tests解释一条红色的测试diagnose an existing red onewriting-e2e-tests新增一条测试author a new one并自带run-until-green循环。因此修复落地不是本命令的职责调查结束后把提案移交给writing-e2e-tests位于 .agents/skills/writing-e2e-tests/SKILL.md由后者执行包括 POM spec 修改、data-testid补充、tag_lint.py校验、tsc --noEmit类型检查在内的完整改动循环。二者合起来构成 Opik E2E 维护的闭环新增测试走 writing 循环失败测试走 investigating 循环修复再回到 writing 循环。七、实战速查表环节关键动作 / 命令证据来源定位 rungh run view run-idGitHub Actions找 launchlist_launches(projectId: 1, search: run-id)Allure TestOps查失败结果list_test_results(launchId)过滤 statusAllure TestOps拉历史get_test_result_history(id)flaky标记Allure TestOps下载 tracegh run download run-id -n test-results-v2 -D dirCI 构件阅读失败现场npx playwright show-trace trace.zipPlaywright相关性分析git diff对比失败代码路径git分类决策历史连续断裂→regression间歇无相关diff→flake默认保守证据综合诊断透镜渲染竞态 → 选择器漂移 → 最终一致性 → fixture 形状trace DOM 快照输出判定 置信度 逐项引用证据 具体修复提案零编辑—结语Opik 的 E2E 失败调查不是打开 trace 看运气而是一条被明确固化的方法论从investigate-e2e-failure命令入口进入经由debugging-e2e-tests技能的五步循环解析入口 → 收集证据 → 分类 → 诊断 → 报告提案最终产出一份带证据引用、带置信度、带具体修复方向的诊断报告且全程只读。这套流程的价值在于把排障从个人经验变成了可复用、可审计、可交接的工程能力——而它的根基正是仓库中 E2E 套件本身对test.step()、选择器优先级、fixture 所有权和标签体系的一系列强制性约定。【免费下载链接】comet-llmDebug, evaluate, and monitor your LLM applications, RAG systems, and agentic workflows with comprehensive tracing, automated evaluations, and production-ready dashboards.项目地址: https://gitcode.com/GitHub_Trending/co/comet-llm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Opik E2E 测试失败调查指南：从红色 CI 到回归 / 抖动分类与修复提案
Opik E2E 测试失败调查指南从红色 CI 到回归 / 抖动分类与修复提案【免费下载链接】comet-llmDebug, evaluate, and monitor your LLM applications, RAG systems, and agentic workflows with comprehensive tracing, automated evaluations, and production-ready dashboards.项目地址: https://gitcode.com/GitHub_Trending/co/comet-llm导读在 Opik 项目中当 Playwright 驱动的端到端测试位于tests_end_to_end/e2e/在 CI、Allure TestOps 或本地运行时变红你需要一套可复现、有证据支撑的调查流程而不是凭直觉改选择器。本文基于仓库中的investigate-e2e-failure命令及其背后的debugging-e2e-tests技能完整讲解这条只读诊断链路如何从四种失败入口定位证据、如何把失败判定为真实回归regression、抖动flake或环境 / 选择器漂移environment / selector drift以及如何输出带证据引用的修复提案。读完你将掌握一套可立即投入使用的 E2E 排障方法论并能与writing-e2e-tests技能衔接完成修复落地。一、命令定位investigate-e2e-failure 是什么在仓库的.agents/commands/comet/investigate-e2e-failure.md中定义了一个面向 AI Agent 的命令级工作流其核心定位可以概括为三句话调查一次失败的 Opik E2E 测试并提出修复方案证据驱动命令负责收集证据trace、error、history并将失败分类为真实回归、抖动或环境 / 选择器漂移只读原则它只做诊断和提案绝不修改测试代码。该命令并不自包含全部逻辑而是明确要求Invoke thedebugging-e2e-testsskill and follow it exactly.也就是说命令是入口真正承载调查循环的是.agents/skills/debugging-e2e-tests/SKILL.md这份技能文档。技能里完整定义了证据来源allure-testopsMCP、gh构件、npx playwright show-trace、分类启发式与五步循环。本文将以这份技能为主体展开。完成标准Success criteria命令定义的验收标准正好构成一次调查的产出清单也是你判断一次排障是否完成的检查表给出判定结论regression / flake / environment-or-selector 三选一并附带置信度引用证据失败的 trace 步骤、错误信息、历史模式以及如果存在相关联的代码变更给出具体的修复提案若判定为已知抖动则给出轮询poll/ 隔离quarantine/ 不修复no-fix的建议零修改本次调查不做任何编辑修复落地需移交给writing-e2e-tests技能。二、先理解证据在哪里Opik E2E 套件的结构要调查失败首先要清楚失败现场存放在哪里。.agents/skills/debugging-e2e-tests/SKILL.md明确给出了三类证据位置与tests_end_to_end/e2e/目录结构一一对应。2.1 本地运行证据本地执行 Playwright 测试时失败现场默认保留在当前目录下Playwright tracestests_end_to_end/e2e/test-results/失败时保留Allure 结果tests_end_to_end/e2e/allure-results/。这些路径由 playwright.config.ts 中的 reporter 与 use 配置决定trace: retain-on-failure、screenshot: only-on-failure、video: retain-on-failure同时 Allure 插件输出到allure-results目录。2.2 CI 运行证据CI 上每次运行会产出三个构件保留期 7 天构件名内容test-results-v2Playwright traces 视频playwright-report-v2HTML 格式报告allure-results-v2Allure 结果下载方式技能原文命令gh run download run-id -n test-results-v2 -D dir2.3 Allure TestOpsAllure TestOpscomet.testops.cloudproject id1在 CI 期间实时接收测试结果流。launch 命名规则为Opik v2 … tier - run_id其中尾部数字是 GitHub Actions 的 run id中间的 env 段会变化E2E、Post-Merge、Local、staging、production。利用 launch 中的jobRun.url可以直接反查到对应的 GitHub Actions 运行。2.4 套件的技术底座佐证E2E 套件的运行方式对理解失败现场有帮助Playwright 的webServer指令会自动拉起两个服务——services/opik-sdk-driver一个用uv运行的 FastAPI 应用包装 Python SDK 为 TypeScript 客户端提供 seeding 路由见 playwright.config.ts 中uv run uvicorn opik_sdk_driver.main:app --port 5175services/mock-token-authMock OAuth2 token 服务用于动态 token 认证的 specOPIK-7940封闭式设计不依赖外部密钥。套件还通过global-setup.ts打上每次运行的runIdglobal-teardown.ts负责清理本次运行创建的所有cuj-{runId}-*项目见 tests_end_to_end/e2e/README.md。理解这些基础设施能帮助你在失败是否由环境引起这一分类维度上做出更准确的判断。三、工具链一张排障工具箱清单技能文档定义了四个核心工具调查过程基本就是这四个工具的轮流使用allure-testopsMCP已配置连接—— 信息最丰富的证据源。技能文档给出了三个验证过的调用list_launches(projectId: 1, search: run_id or name fragment, sort: [createdDate,DESC])或search_launches(rql: …)定位 launchlist_test_results(launchId)获取每个测试的name、fullNamespec 路径 行号例如datasets/dataset-crud-smoke.spec.ts:8:7、status、TestOps 计算的flaky标记、muted/known、tags、jobRun.url对应 GitHub Actions 运行以及 result 的id可用search过滤到失败的测试get_test_result_history(id)该测试在最近多次 launch 中的通过 / 失败时间线 —— 这是抖动flake判定的核心信号。ghCLI——gh run view run-id定位失败 jobgh run download run-id -n test-results-v2 -D dir拉取 trace 构件。npx playwright show-trace trace.zip—— 在tests_end_to_end/e2e/目录下打开 trace查看精确失败的步骤、当时的 DOM 快照以及该时刻的 console / network。git—— 对比可疑变更与失败测试的代码路径用于相关性分析。四、调查五步循环核心章节技能的骨架是一条五步流水线用 DOT 图表示为1. Resolve entry point → 2. Gather evidence → 3. Classify → 4. Diagnose → 5. Report propose (no edits)Step 1 —— 解析入口点Resolve the entry point无论失败从哪来第一步都是把它归一化为一个失败的测试 它的证据在哪里。四种入口的归一化方式红色 CI check / Actions run取 run id。gh run view run-id找失败 job用list_launches(projectId: 1, search: run-id)找匹配 launchtrace 在test-results-v2构件中用gh run download拉取。TestOps launch直接查询list_test_results(launchId)过滤出失败结果。测试名例如dataset-crud-smoke在最近的 launch 上用list_test_results加search找到 resultid再拉取其历史。本地失败直接使用本地的test-results/trace 和allure-results/对于未提交的本地运行TestOps 里可能没有对应记录这很正常无需强求。Step 2 —— 收集证据Gather evidence证据收集的四个要点失败断言与错误消息来自 trace、报告或 TestOps resulttrace对保留 / 下载的.zip执行npx playwright show-trace重点读失败步骤、该时刻的 DOM 快照及其前后的 console / network截图 / 视频存在则一并使用配置为only-on-failure/retain-on-failure测试历史通过get_test_result_history(id)获取并结合 TestOps result 上的flaky标记。优雅降级当 TestOps 不可达例如纯本地运行时跳过历史收集退回到 trace diff 推理。Step 3 —— 分类Classify这是整个调查的核心决策点判定为真实回归real regression、抖动flake还是环境 / 选择器漂移environment / selector drift。技能给出的三条启发式历史信号优先一条干净的连续通过记录、在某个相关变更之后立刻断裂 → 倾向 regression间歇性通过 / 失败且无相关变更或 TestOpsflaky: true→ 倾向 flakeDiff 相关性最近的变更是否触及失败断言所经过的代码路径页面 / 组件、POM 方法、fixture触及 → 大概率 regression失败区域完全未被触碰 → 大概率 flake 或环境问题默认保守当历史呈现间歇性且不存在相关 diff 时默认判为 flake / uncertain——没有证据就不要轻易扣上 regression 的帽子。Step 4 —— 诊断Diagnose在分类基础上定位根因且必须基于引用的证据具体 trace 步骤、错误、历史模式而不是猜测。技能提供了四个针对 Opik 套件的诊断透镜按优先级应用先验证测试渲染再怪罪后端一条 X didnt appear 的失败往往不是后端回归而是 DOM 竞态loading spinner 还在转、最终一致性写入尚未落盘。检查失败步骤处的 DOM 快照即可确认选择器漂移前端改了 accessible name 或删除了data-testid导致 locator 无法再解析最终一致性状态异步打分 / 摄入scoring / ingestion需要轮询poll而不是固定等待Fixture 种子形状不匹配页面渲染出空 / 部分状态是因为种子数据与断言期望的形状不一致。这些透镜与.agents/skills/writing-e2e-tests/conventions.md中Verify the test render before blaming the backend的约定一脉相承——说明诊断准则与编写准则在设计上是对齐的。Step 5 —— 报告 提案Report propose不编辑输出三件套判定Verdict分类regression / flake / environment-or-selector 置信度证据Evidencetrace 步骤、错误、历史模式、关联变更如有逐项引用修复提案Proposed fix必须具体。回归 → 指明要改的代码 / 选择器 / 轮询点抖动 → 用expect.poll替代固定等待、隔离quarantine或无需改代码——已知抖动重试。最后重申边界不编辑任何东西。开发者要应用修复时移交给writing-e2e-tests技能。五、分类启发式背后的工程逻辑为什么技能在分类上如此强调证据与保守默认从仓库约定可以还原出它的工程动机失败信息密度被刻意放大.agents/skills/writing-e2e-tests/conventions.md强制每个 POM 方法体和测试逻辑阶段用test.step()包裹并经由回调返回。这使得 Playwright trace viewer 和 Allure timeline 可读——一次失败不再是一堵没有叙事的操作墙而是一个个语义化的阶段。没有这个约定Step 2 的 trace 阅读会寸步难行。选择器优先级是抖动治理的第一道防线约定规定选择器优先级为getByTestIdgetByRolegetByLabelgetByText CSS/XPath并明令结构型 CSS 选择器如tbody tr:nth-child(2)是抖动的主要来源——一旦出现就应给前端组件补data-testid。这条约定直接支撑了 Step 4 中selector drift透镜的判断标准。expect.soft是例外而非默认约定指出默认应使用硬断言expect(...)让 trace 精确停在假设断裂之处只有像workspace-roles-permissions.spec.ts这种一次性审计大量独立事实的场景才用expect.soft。这解释了为什么技能要求失败的断言 精确的错误消息作为首要证据——套件本身被设计成一次失败信息最清晰。fixture 与 teardown 所有权清晰teardown 归 fixture 管无论通过、失败还是超时都会执行destructive 测试需要 bystander 实体。这让测试本身是否污染了环境这类环境归因问题在调查时有章可循。六、边界与后续衔接6.1 只读边界技能文档用两段话锁死了边界只读不做测试编辑也不为调查而重跑套件四种入口全部覆盖CI、TestOps launch、测试名、本地失败没有 TestOps 时优雅降级本地失败仅靠 trace diff。6.2 与 writing-e2e-tests 的分工调查与编写是两条截然不同的流水线技能文档明确区分debugging-e2e-tests解释一条红色的测试diagnose an existing red onewriting-e2e-tests新增一条测试author a new one并自带run-until-green循环。因此修复落地不是本命令的职责调查结束后把提案移交给writing-e2e-tests位于 .agents/skills/writing-e2e-tests/SKILL.md由后者执行包括 POM spec 修改、data-testid补充、tag_lint.py校验、tsc --noEmit类型检查在内的完整改动循环。二者合起来构成 Opik E2E 维护的闭环新增测试走 writing 循环失败测试走 investigating 循环修复再回到 writing 循环。七、实战速查表环节关键动作 / 命令证据来源定位 rungh run view run-idGitHub Actions找 launchlist_launches(projectId: 1, search: run-id)Allure TestOps查失败结果list_test_results(launchId)过滤 statusAllure TestOps拉历史get_test_result_history(id)flaky标记Allure TestOps下载 tracegh run download run-id -n test-results-v2 -D dirCI 构件阅读失败现场npx playwright show-trace trace.zipPlaywright相关性分析git diff对比失败代码路径git分类决策历史连续断裂→regression间歇无相关diff→flake默认保守证据综合诊断透镜渲染竞态 → 选择器漂移 → 最终一致性 → fixture 形状trace DOM 快照输出判定 置信度 逐项引用证据 具体修复提案零编辑—结语Opik 的 E2E 失败调查不是打开 trace 看运气而是一条被明确固化的方法论从investigate-e2e-failure命令入口进入经由debugging-e2e-tests技能的五步循环解析入口 → 收集证据 → 分类 → 诊断 → 报告提案最终产出一份带证据引用、带置信度、带具体修复方向的诊断报告且全程只读。这套流程的价值在于把排障从个人经验变成了可复用、可审计、可交接的工程能力——而它的根基正是仓库中 E2E 套件本身对test.step()、选择器优先级、fixture 所有权和标签体系的一系列强制性约定。【免费下载链接】comet-llmDebug, evaluate, and monitor your LLM applications, RAG systems, and agentic workflows with comprehensive tracing, automated evaluations, and production-ready dashboards.项目地址: https://gitcode.com/GitHub_Trending/co/comet-llm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考