变更摘要

本 PR 是纯 E2E 测试规格调整，不涉及产品代码：由于模型注册表的「添加 Provider」独立入口已并入连接卡片（连接向导），test/journey-provider-model-catalog.spec.ts（J7）原先点击该按钮的创建流程会让整条旅程超时，因此将其改为通过 POST /api/providers API 预置服务商再进入编辑器；同时把「选了预设 → 创建请求带着该厂商 baseUrl / apiVariant / modelDiscovery」这一预设落地性质迁入 test/journey-model-connect-wizard.spec.ts，并补齐连接向导旅程的空实例前提与布局断言容差。

主要改动

• 预设落地断言迁入连接向导旅程: 在 test/journey-model-connect-wizard.spec.ts 新增「预设落地」步骤，对 MiniMax（api.minimaxi.com）与智谱（open.bigmodel.cn）分别选择 #wizard-provider-select、只填令牌并提交，通过 page.route("**/api/providers") 捕获原始请求体后再改写到本地 stub，断言 apiProtocol、apiVariant、baseUrl、modelDiscovery: "openai-models"、presetId 与 apiToken 原样进入创建请求。
• 连接向导旅程建立空实例前提: 引入 requireFirstRunState(page, testInfo)，在运行自己拥有的栈上清理上次残留，否则记为前置未满足，避免共享栈上已有模型时「系统首个模型设为全局默认」被产品正确返回「保持不变」而误判失败。
• 提交按钮与底栏布局断言加入亚像素容差: 将原来严格的 submitBox.y + height < footerBox.y 改为计算 overlap 并断言 overlap < 1（1 个 CSS 像素容差），以区分渲染取整差异与真实布局回归。
• J7 改为 API 预置 provider: 删除 openAddPanel、choosePreset、addCustomProvider 等依赖已删除「添加 Provider」面板的辅助函数，新增 openConnectCard、providerSelect、seedProvider、openProviderEditor，用 page.request.fetch 直接创建 MiniMax、智谱、自定义与草稿宿主等服务商，并携带 presetId 供目录按厂商选取区域价。
• J7 中依赖界面新建的断言改写与文案对齐: 预设入口断言改为连接卡片 #wizard-provider-select 的 option 列表（末项为「自定义服务商」/Custom provider），删除 MiniMax、智谱两步界面创建流程；刷新失败提示由「无法刷新模型目录，仍在使用上一次的目录数据」改为「刷新模型目录失败」；草稿填写改为在已有服务商编辑器中展开对应 .provider-row 后进行。

已按要求仅输出「变更摘要」与「主要改动」两节。

代码审查

审查结论

变更文件逐一确认

• test/journey-model-connect-wizard.spec.ts：已完整审查（新增 requireFirstRunState 前置闸、预设落地步骤、布局重叠容差断言）。发现问题 1 个（P2，见下）；布局断言由严格浮点先后改为 < 1px 容差属于合理修正（真实回归是几十像素级），不另报。
• test/journey-provider-model-catalog.spec.ts：已完整审查（新增 openConnectCard/providerSelect/seedProvider/openProviderEditor 辅助、删除 openAddPanel/addCustomProvider/choosePreset 及两步界面创建流程、J7 改为 API 预置、DeepSeek 行改为按新名字锚定、英文界面下拉断言迁移）。发现问题 2 个（P2 × 1、P3 × 1）。

发现清单（按优先级）

• P2 × 2
  1. test/journey-provider-model-catalog.spec.ts:565 — 预置 MiniMax 的 baseUrl 指向 ${stub.origin}/minimax/v1，该路径不在 providerStub 的列表白名单（仅 /v1、/slow/v1、/fast/v1、/zhipu/v1）内，落到 404 分支；listAuth/listPaths 不记录该请求，导致“每个服务商列表请求都带自己的令牌”的断言被静默削弱，且后续按文本过滤 role=alert 的 403 断言有 strict mode 命中多元素的风险。
  2. test/journey-model-connect-wizard.spec.ts:453-456 — 新增预设步骤通过界面真实创建两个 Provider（名称来自产品预设，不带 E2E 向导测试 前缀），而 cleanupProviders() 只清理该前缀的记录，这两个指向已关闭 stub 端口的 Provider 会残留在共享栈上，污染后续旅程的注册表列表。
• P3 × 1
  3. test/journey-provider-model-catalog.spec.ts:192-195 — E2E-META 的 Steps 第 3/4/6 条仍描述本 PR 已删除的界面创建路径（MiniMax 仅填令牌、智谱预设连接、自定义 Provider 草稿保护），与迁移后的 API 预置实现不一致，journey-report.ts 会直接读取该块生成场景报告头，属可维护性/审计问题（可选修正）。

总体风险判断

本 PR 只改两个 Playwright 规格、不动产品代码，无安全、并发或数据一致性风险，构建层面无语法/类型隐患（导入、辅助函数、被删函数的残留引用均已核对干净）。主要风险集中在测试自身的保真度与隔离性：一处 stub 路由缺口使新增的令牌配对断言覆盖变薄，一处清理缺口会在共享栈上留下脏数据；两者都不会让用例立刻失败，但会削弱这批 E2E 的判别力，建议一并修掉。

💬 仅评论

欢迎来到 openJiuwen 社区

Hey @wang_cheng_zhao , 感谢你对社区的贡献.

机器人使用手册

有关指令的使用，可以点击 此处 查看详情。开发人员可以在每个PR或Issue下方评论特定指令来触发机器人任务。

CLA 签署成功

wang_cheng_zhao, 感谢您的代码贡献。 所有的代码贡献者都已完成了 CLA 签署。 👍

The pipeline(pipeline number:168) is running. Please wait a moment...

AI 自动检视，仅供参考，问题都需要人工评估分析.

本 PR 相对最新 origin/main（0a0403ae，behind_main=0，ahead=2）只动两个 Playwright 旅程：journey-model-connect-wizard 与 journey-provider-model-catalog（J7），无产品代码。merge-tree 干净。

连接向导旅程补上了它实际依赖的首启空态闸（requireFirstRunState），并把原先挂在 J7「添加 Provider」创建路径上的预设落地断言迁进来：选 MiniMax / 智谱后只填令牌，在浏览器边界捕获创建 body，核对厂商 baseUrl / apiVariant / modelDiscovery 原样进请求，再改写到本地 stub 转发。末段布局断言对「提交按钮压底栏」放宽到 1 CSS 像素容差，避免亚像素渲染把布局测成渲染器差异。J7 侧去掉已不存在的独立添加面板驱动，改为 API seedProvider 预置记录、编辑器只服务已有服务商，预设入口改断言连接卡片下拉；目录刷新失败文案也跟到当前产品文案。职责拆分清楚——创建与预设契约归向导，目录/令牌配对/编辑草稿归 J7——和「新建已并入连接卡片」的产品现状对齐。

可合

✅ 流水线 87a893c351aa4aee850a4ade3ed1e6ce 执行成功。

可在 https://gitcode.com/openJiuwen/sciencediscovery/pull/168/check 查看完整构建日志。

在 PR 评论中发送 rerun 可重新触发 CI 流水线。

AtomGit AI 助手使用指南

在 PR 评论中使用命令即可触发。支持在普通评论和代码行评论中使用。

免责声明

AI 助手可能存在误判，请结合自身判断。可以对评论点 👍 或 👎 帮助我们改进。

评审意见（基于 main 分支实测核查）

一句话结论

测试-only 修复方向正确、事实核查全部成立：J7 确实点了产品里已删除的「添加 Provider」入口，预设落地断言迁入向导旅程后比原来更强（真实拦截创建请求）；仅两处测试数据卫生小瑕疵，不阻断合入。

描述核查

• 「添加 Provider」独立入口确实已从产品消失：apps/、packages/ 全量 grep 无 provider-add-panel/添加 Provider/Add provider 残留；旧 J7 第 1 步的 getByRole("button", {name: /添加 Provider|…/}).first().click() 必然等满 240s（config timeout: 240000），诊断可信。
• 预设断言是真网络拦截而非 UI 状态：page.route("**/api/providers") 捕获浏览器实际 POST body，toMatchObject 校验 baseUrl/apiVariant/modelDiscovery/presetId/apiProtocol/apiToken，再改写 baseUrl 为 loopback stub 转发，服务端不触厂商网络。断言值与 packages/schema/src/model-provider-presets.ts（MiniMax api.minimaxi.com/v1+minimax 变种、智谱 open.bigmodel.cn/api/paas/v4+deepseek 变种、均 openai-models）及 ModelConnectWizard.providerInput() 逐字段吻合。
• requireFirstRunState 闸门正确：models+providers+projects 三项判定空态；仅当 E2E_ALLOW_STACK_RESET=1 且 loopback 且非 trial 端口（.ci/run-e2e.sh:200 由自有栈导出）才清理，否则 testInfo.skip → 报告标 BLOCKED；workers:1、fullyParallel:false 无并发互踩；清理顺序（projects → 清 modelId/reviewModelId → providers → 残留 models）确实建立 listModels() 为空，与向导 hadModels（ModelConnectWizard.tsx:346-391）语义对齐。
• 亚像素容差是严格 <1 CSS px（head 710-715 行），注释讲明 580.234 vs 580 的取整差异与「真回归是几十像素级」，不是松动棘轮。
• 确认零产品代码：仅 2 个 spec（93+3 / 129+182 = +222/−185）；删除的 openAddPanel/choosePreset/addCustomProvider 及两个创建步骤无任何残留引用（补丁可干净套用）。

问题清单

• [次要] test/journey-provider-model-catalog.spec.ts:565（注释 652-653 行）：MiniMax 预置指向 ${stub.origin}/minimax/v1，但 stub（61 行）只服务 /v1、/slow、/fast、/zhipu 四条 models 路径——/minimax/v1/models 落入 404 分支，永不进 listAuth；注释却称三家「都各自打过一次列表接口（端点分别指向 stub 的 /minimax 与 /zhipu）」。现有断言（智谱配对、custom 令牌）不破，CI 已绿，但注释失实且 MiniMax 一侧的令牌配对证据悄悄消失。修复：改指 stub.baseUrl（同被删步骤）或在 stub 路径表加 /minimax/v1/models 并比照智谱断言配对。
• [次要] test/journey-model-connect-wizard.spec.ts:402-473：新「预设落地」步骤创建名为 "MiniMax"/“智谱 GLM” 的 provider，而 cleanupProviders（135-142 行）只删名字含「E2E 向导测试」的记录——这两个及其登记模型逃过 finally。自有栈上下一个带闸旅程（journey-model-settings，按字母序在后）会清；但指向式空栈（拒绝重置却 total=0 → 不 skip 直接跑）会留下无 E2E 标记的残留。修复：记录创建返回的 id 或扩大 victims 过滤，finally 一并删除。
• [建议] test/journey-model-connect-wizard.spec.ts:226-228：步骤 1 仍用严格浮点先后（submitBox.y+height < footerBox.y），与 PR 自己在 710-715 行论证的「测渲染器而非布局」同理，存在同类亚像素抖动风险；建议统一套用 <1px 容差。

亮点

• 预设落地断言迁移即加强：两个厂商、浏览器边界捕获真实请求体、令牌进 body 亦断言，且证明厂商网络不可达。
• 闸门复用纪律好：与 first-run/model-settings 同一套「自有栈才清、否则 BLOCKED」治理，前置说明写明了 hadModels 依赖。
• J7 重写忠实于现行 UI：刷新失败文案更新为实际字符串「刷新模型目录失败」（messages.ts:3353），编辑器路径（provider-row-summary→「编辑」→「服务商编辑器」）与 ProviderModelSettings.tsx 吻合，所有预置 id 均入 providerIds 逆序清理。

VERDICT: approve-with-nits