基于Playwright的E2E测试体系搭建：用例设计、稳定性与CI集成实践-北京尧图网络

做测试的朋友应该都听过 e2e 这个概念也就是端到端测试。我前段时间正好给自己负责的一个前后端分离管理系统从零搭了一套完整的 e2e 测试体系从选型、框架搭建、用例编写到稳定性和 CI 集成中间踩了不少坑也沉淀了一套比较可复用的打法。今天把整个落地过程掰开揉碎讲清楚包括为什么选型选到 Playwright、用例怎么规划才不会变成维护噩梦、稳定性和排查怎么系统性解决。如果你正准备给项目上端到端测试或者已经被“测试不稳定”折磨到怀疑人生这篇应该能帮你省掉不少时间。先说清楚一个容易被误解的点e2e 不是万能的也绝对不是“代替单测和接口测试”的银弹。它解决的核心问题是“多模块拼在一起之后用户主流程能不能走通”。像登录状态串不串、前端本地缓存过期后会不会把人踢下线、搜索条件重置时 URL 参数是否同步清空、审批流跨服务调用会不会在某一步卡死这些跨模块、跨服务、跨浏览器行为的问题只有 e2e 能真实覆盖到。1. 项目背景与整体方案设计1.1 被测系统长什么样e2e 能覆盖什么场景我手头这个项目是一套典型的 B 端管理系统Vue 3 前端搭配 Spring Boot 后端前端跑在 Nginx 后面后端依赖 MySQL 和 Redis另外还接了消息队列做审批通知。业务上主要有几条核心链路账号登录、立项申请、审批流转、数据报表导出、用户权限管理。先说明这套系统原本是有测试的。单元测试覆盖率大约 60%接口测试也覆盖了主要业务接口但问题在于前端交互逻辑多状态都在浏览器里接口测试根本管不到。举个真实例子审批流里有一个“撤回重提”操作后端只负责更新状态但前端要根据状态动态渲染不同按钮。结果有一次后端状态字段多了一个枚举值前端没适配功能肉眼可见地变成了“审批单消失”。这种 bug 接口测试完全发现不了手工回归又要等业务人员配合录入数据一套走完至少 40 分钟。所以 e2e 不是为了追热点是被实际业务逼出来的。在设计用例的时候我没有一上来就铺开去写“每个页面都要有点击验证”。那样很快会变成一万行没人维护的死代码。我走了另一条路先把用户主链路画出来按“频次 × 影响范围”打分只挑最核心的 20% 流程做覆盖但每条链路都做到极致稳定。比如登录、创建申请、审批通过、导出报表这四个动作组合起来能覆盖用户日常 80% 以上的操作路径。1.2 为什么最终选择了 Playwright 而不是 Cypress 或 Selenium选型阶段我就对比了三套方案当时还列了一张表方案自动等待多浏览器支持调试体验并行能力生态维护Selenium弱需要自己封装强WebDriver 标准一般依赖 Grid 配置老牌但慢Cypress强内置自动重试弱只专注 Chrome 系好有限制社区活跃Playwright强Actionability 检查强Chromium/Firefox/WebKit极好有 Trace Viewer原生多进程并行微软维护更新快我最后选了 Playwright核心原因有三个第一自动等待机制真的是为真实用户行为设计的。Playwright 的每个 Action 都自带 Actionability 检测比如点击前会等元素可见、可编辑、不受遮挡、不抖动。这直接消灭了一大批“元素还没加载出来就点击导致失败”的 flaky 问题。在它之前我写 Selenium 还要自己封装waitForElementVisible这种样板代码不仅难写还经常因为等待条件不准确而误报失败。第二多浏览器支持是刚需。我们系统虽然不是面向消费者的大流量产品但领导特别看重兼容性Firefox 和 Safari 一旦出问题经常是线上才暴露。Playwright 用同一个 API 直接跑三套内核省掉了单独维护 WebDriver 的头发脱落过程。第三调试体验太关键了。跑失败的用例会自动生成 Trace 文件能看到页面一步步的 DOM 快照、网络请求、控制台日志和鼠标操作轨迹。这个问题排查效率比看截图强一个数量级。后面我也会展开讲 Trace 的使用细节。有人会问为什么不用 Cypress。Cypress 本身很优秀但它的架构基于浏览器内注入执行对多标签页、iframe 和浏览器原生事件的支持天然受限还不太好原生并行。我们系统正好有几个场景要处理 iframe这就一票否决了。2. 测试用例的规划与核心设计思路2.1 用例分层的原则先画主链路再补充分支我没有直接创建一堆测试文件而是先花了半天时间把“用户视角的主链路”梳理出来。用大白话说就是把系统拆成几个用户故事比如用户登录后能正确进入工作台且能看到自己的待办事项用户能走完“新建立项申请 → 提交审批 → 审批人通过 → 申请状态变更为已通过”用户在列表页能用多个条件组合筛选筛选后 URL 参数、列表结果一致用户能导出当前筛选条件下的数据且导出文件格式正确、内容不串数据管理员能停用某个用户账户该账户立即无法登录我把这些整理成一张场景矩阵表横向列“主链路、分支链路、异常链路”纵向列“优先级 P0/P1/P2”。P0 就是任何一次发布回归都必须跑的P1 是重要但允许手动兜底的P2 是锦上添花的。最后实际写代码的只有 P0 和少量 P1因为 P2 的维护成本远高于收益不如让接口测试去补。这里有个关键经验e2e 用例数不是越多越好而是越准越好。我在项目里见过别人恨不得给每个输入框写一条用例结果一周跑下来全是“因为文案变了所以断言失败”的空报浪费了大量排查时间。用例的粒度应该对齐“用户意图”而不是对齐“页面元素”。一个用户意图就是一个用例比如“用过期链接访问审批单会被拦截”这一条就能覆盖鉴权、路由守卫、错误提示三个层面。2.2 Page Object 模型怎么组织才不啰嗦结构上我用了标准的 Page Object ModelPOM但做了一些裁剪避免出现那种“一个方法只有一行代码”的过度封装。我的目录长这样e2e/ ├─ tests/ │ ├─ login.spec.js │ ├─ project-apply.spec.js │ └─ approval.spec.js ├─ pages/ │ ├─ login.page.js │ ├─ dashboard.page.js │ └─ apply.page.js ├─ fixtures/ │ └─ auth.fixture.js ├─ utils/ │ ├─ db.clean.js │ └─ file.helper.js └─ playwright.config.jsPage Object 的核心价值不是“为了好看”而是把元素定位和业务操作集中管理。比如登录页的submitLogin(username, password)方法内部把输入用户名、输入密码、点登录按钮这几步封装好业务用例里永远只关心“我要登录”不用关心登录按钮长什么样。后端一改前端模板我只需要改 Page Object 一个地方而不是搜索几十个用例。但我也见过反面教材有人把await page.click(#submit)这样一行也包成一个clickSubmit()这种过度封装除了多一层跳转没有任何价值反而让代码可读性变差。我的原则是至少包含两步以上动作、或者一个业务意图的动作才值得封装。比如submitLogin是三个动作加一个登录意图值得封装单纯的获取输入框值就不值得。2.3 数据怎么准备怎么隔离e2e 最怕的是“测试数据污染”上次跑完留下的脏数据会直接影响下次结果。我之前的方案是每个用例自成一体比如创建一个立项申请就假设这条数据只会被本用例读取如果要做列表筛选就构造一条带唯一标识的记录用时间戳做后缀。代码里我封装了一个unique()函数function unique(prefix e2e) { return ${prefix}_${Date.now()}_${Math.floor(Math.random() * 10000)}; }然后用这个函数生成项目名称const projectName unique(自动化立项);筛选用例里只要输入这个唯一名称进行搜索结果必然只包含这条记录断言非常干净根本不需要清空历史数据。这个方案简单、有效比“跑测试前清库”稳定得多。因为清库脚本经常会误删线上数据而且如果每条用例都依赖“数据库必须是空白的”一旦有人手动在测试环境点了两下整套用例全挂。至于登录状态我一开始走的是 UI 登录再做登出每个用例都走一遍完整登录流程稳定是稳定但非常慢。后来我改成了“一次登录通过 storageState 复用登录状态”。用playwright codegen或手动跑一次登录并保存 Cookie 和 localStorage// 首次登录保存状态 test(保存登录态, async ({ page }) { await page.goto(/login); await page.getByLabel(用户名).fill(admin); await page.getByLabel(密码).fill(密码); await page.getByRole(button, { name: 登录 }).click(); await page.waitForURL(/dashboard); await page.context().storageState({ path: fixtures/storageState.json }); });之后配置里直接引用use: { storageState: fixtures/storageState.json }这样一个用例从登录到打开页面耗时从 8 秒降到 1 秒。当然这种方式需要注意 token 有效期问题如果 token 过期要重新生成 storageState。CI 里我会安排一个“预跑登录”的 job保证每天第一次跑的是最新状态。3. 核心用例的实操实现3.1 环境准备与初始化我用的 Node 版本是 18安装方式直接走官方 npm 包npm init -y npm i -D playwright/test npx playwright install chromium --with-deps如果想在本地跑三个内核就npx playwright install --with-deps。注意--with-deps会自动安装系统依赖库Linux 环境必备否则 chromium 会起不来报一堆.so缺失错误。这里我遇到过最典型的问题是CentOS 服务器上缺少libnss3、libatk系列库不加--with-deps连浏览器都启动不了。然后写配置文件。这个配置就是后面一切稳定的基础我把关键注释放在里面const { defineConfig, devices } require(playwright/test); module.exports defineConfig({ testDir: ./tests, timeout: 30_000, expect: { timeout: 5_000 }, fullyParallel: true, retries: process.env.CI ? 2 : 0, workers: process.env.CI ? 4 : undefined, reporter: [ [list], [html, { outputFolder: playwright-report }] ], use: { baseURL: process.env.BASE_URL || http://localhost:5173, trace: on-first-retry, video: retain-on-failure, screenshot: only-on-failure, }, projects: [ { name: chromium, use: { ...devices[Desktop Chrome] } }, { name: firefox, use: { ...devices[Desktop Firefox] } }, { name: webkit, use: { ...devices[Desktop Safari] } } ] });retries: 2这个配置要特别解释一下。很多刚写 e2e 的人觉得重试是“掩盖问题”但这是我刻意选择的。E2e 本质上是“真实环境模拟用户操作”网络抖动、字体加载慢、接口偶发超时这些不是代码逻辑问题的干扰因素客观存在。CI 上跑一次失败就全红会让大家失去对测试结果的信任反而更严重。配合 Trace 就能区分“真失败”和“环境抖动”。3.2 登录链路用例正向、反向、边界一起覆盖登录是所有链路的地基所以我单独建了login.spec.js。一个正向用例一个反向用例一个 redirect 用例const { test, expect } require(playwright/test); const { LoginPage } require(../pages/login.page); test(正确账号密码可以登录并进入工作台, async ({ page }) { const login new LoginPage(page); await login.goto(); await login.submitLogin(admin, Test123); await expect(page).toHaveURL(/dashboard/); await expect(page.getByRole(heading, { name: 工作台 })).toBeVisible(); }); test(错误密码会显示错误提示且停留在登录页, async ({ page }) { const login new LoginPage(page); await login.goto(); await login.submitLogin(admin, wrong-password); await expect(page.getByText(用户名或密码错误)).toBeVisible(); await expect(page).toHaveURL(/login/); });第三个用例其实是很多团队忽略的边界场景已登录用户直接访问登录页系统应自动跳转到工作台而不是又让用户输一遍账号。这个场景能抓到一种典型的逻辑漏洞路由守卫只做了“未登录拦截”没做“已登录反向拦截”。写这段时我踩过一个坑错误提示的文本是“用户名或密码错误”但登录接口在后端同时会发一个告警日志前端在接口返回前先弹了 loading 遮罩。断言时如果直接getByText(用户名或密码错误)而没等 loading 消失可能拿到的是缓存的上一轮提示。所以我在submitLogin内部加了await expect(page.getByText(用户名或密码错误)).toBeVisible()的调用把这个时序问题锁死。3.3 审批主链路用例跨页面操作与状态断言审批链路是跨页面的核心场景申请人创建申请审批人在待办列表看到该申请点击通过再回到申请人视角看到状态变更。这里最大的难点是“同一系统里的角色切换”。我先用 API 或者直接用同一个浏览器开两个上下文context来模拟两个角色。Playwright 支持多个 context 并行互不干扰比“登录登出切换”高效很多const { test, expect } require(playwright/test); test(申请人提交后审批人可审批通过状态流转正确, async ({ browser }) { const applicantCtx await browser.newContext({ storageState: fixtures/storageState_applicant.json }); const approverCtx await browser.newContext({ storageState: fixtures/storageState_approver.json }); const applicantPage await applicantCtx.newPage(); const projectName unique(自动化审批项目); // 申请人创建申请 await applicantPage.goto(/apply/new); await applicantPage.getByLabel(项目名称).fill(projectName); await applicantPage.getByLabel(预算金额).fill(100000); await applicantPage.getByRole(button, { name: 提交审批 }).click(); await expect(applicantPage.getByText(提交成功)).toBeVisible(); // 审批人打开待办处理该申请 const approverPage await approverCtx.newPage(); await approverPage.goto(/todo); await approverPage.getByRole(row, { name: projectName }).first().click(); await approverPage.getByRole(button, { name: 通过 }).click(); await expect(approverPage.getByText(审批完成)).toBeVisible(); // 申请人视角确认状态变化 await applicantPage.goto(/apply/list); await expect(applicantPage.getByRole(row, { name: projectName })).toContainText(已通过); });这里有几个很实际的细节。第一getByRole(row, { name: projectName })比用 CSS 定位稳得多它直接匹配整行内容不需要关心标签结构。但要注意如果表格有分页加载行元素可能在懒加载后才出现必须先确保列表已经渲染。第二两个角色如果用同一个 storageState 文件会导致串登录我这里是分别生成的。第三这个用例里所有数据都是运行时创建的不依赖初始化数据保证了可重复执行。3.4 文件导出的断言怎么做导出文件这类用例最容易写成“点到触发下载就结束”但下载成功不代表数据正确。我这里的方案是监听下载事件保存文件再用代码解析文件内容做精确断言。比如系统支持导出 CSV 格式的报销列表我是这样做的const { test, expect } require(playwright/test); const fs require(fs); test(导出Excel包含当前筛选数据, async ({ page }) { await page.goto(/expense/list); await page.getByLabel(状态).selectOption(已通过); await page.getByRole(button, { name: 筛选 }).click(); const downloadPromise page.waitForEvent(download); await page.getByRole(button, { name: 导出 }).click(); const download await downloadPromise; const filePath downloads/ download.suggestedFilename(); await download.saveAs(filePath); const content fs.readFileSync(filePath, utf-8); expect(content).toContain(已通过); expect(content).not.toContain(草稿); });这里需要说明一个容易踩坑的点download.suggestedFilename()在跨浏览器下表现不完全一致Firefox 和 Chromium 对中文文件名的编码就不同。稳妥做法是统一重命名为固定名称再解析内容。另外CSV 编码如果不是 UTF-8 而是 GBK读取会乱码所以我在后端让导出接口统一返回 UTF-8 with BOM避免 Excel 打开乱码的隐患。4. 稳定性工程等待策略、Trace 调试与常见问题排查4.1 自动等待机制怎么用才不会写错我之前写 Selenium 时代养成的习惯是到处sleep(2000)Playwright 最让我舒服的是它可以不写 sleep。它的每个定位器操作都会自动等待“元素可见且稳定”所以我推荐的原则只有一个永远不要主动 sleep永远使用断言来同步。但这里有个细节要多说一句。page.goto()执行后会等页面load事件触发但这个“load”不代表前端框架已经完成渲染。Vue 和 React 单页应用经常出现的情况是HTML 已经就绪但 JS bundle 还在执行页面还是白屏。所以goto之后如果你想立即找元素必须用await page.waitForSelector或await expect(...).toBeVisible()这种会重试的断言不要天真地以为 goto 结束页面就可用。我另外会在一些关键流程里用waitForResponse来等待特定接口返回这个比“等元素出现”更可靠const apiRespPromise page.waitForResponse(resp resp.url().includes(/api/approval/todo) resp.status() 200 ); await page.getByRole(button, { name: 刷新 }).click(); await apiRespPromise;这样既确认了前端事件被触发也确认了后端接口成功响应双保险。4.2 Trace Viewer 与失败现场还原哪怕用了上面的方法测试也还是会失败。以前我排查失败是靠截图和看日志现在全靠 Trace Viewer。配置里我开的trace: on-first-retry意思是第一次失败不录第二次重试时录整个操作过程。这样既不影响正常跑的效率又能在最终失败时拿到现场。打开 trace 文件npx playwright show-trace playwright-report/trace.zip可以看到每一步操作前后的 DOM 快照、发了什么网络请求、拿到什么响应、控制台有没有报错、计算样式是什么。有一次一个用例在 CI 上成功、本地失败我打开 trace 发现失败瞬间页面有个toast提示“网络连接丢失”而 Nginx 日志里确实有一条超时请求。这种跨组件问题用截图根本无法定位Trace 直接帮我省了半天时间。我在实际排查还发现一个规律很多 e2e 失败不是“断言值不对”而是“操作根本发生不了”。比如按钮被 loading 遮罩挡着、下拉选项没展开、canvas 组件点击坐标不对。Trace 里能逐帧看到这些状态比肉眼盯截图强得多。4.3 我整理的 e2e 常见问题速查表下面这些是我在项目里实际踩过、也帮同事排查过的高频问题整理成表方便你直接对照着解决。现象直接原因解决方式用例本地全绿CI 上却随机失败CI 机器性能差接口响应慢增加 expect timeout对关键请求用 waitForResponse必要时 retries 1 次点击按钮报 “element is not stable”前端动画、元素抖动Playwright 自动重试都失败考虑用expect(locator).toBeStable()先等动画结束登录保存的 storageState 失效Token 过期或 Cookie 有 Domain 限制定期重新生成 storageState或用 API 直接获取 token 后注入弹出的下载框遮挡后续操作下载自动触发但浏览器默认弹窗用page.waitForEvent(download)捕获不要等弹出框出现多个用例并行时同账号冲突同一账号 token 被覆盖每个 worker 使用不同测试账号或使用 storageState 隔离iframe 里的元素找不到主 frame 定位不到子 frame用page.frameLocator(selector)定位 iframe 内元素前端数据有列表懒加载滚动才能加载更多先mouse.wheel滚到底部或调整接口 limit断言数据唯一名称4.4 并行执行与 CI 集成在本地跑完所有用例后我又把整套东西接到了 CI 流水线。先讲并行Playwright 的fullyParallel默认会跑满所有可用 worker但要注意你的后端测试环境能不能扛住。我第一次全并行的时候测试环境 Redis 被压到 OOM一堆用例开始互相踢下线全红。后来我给 worker 数量设了一个合理上限并在代码里给几个高频接口做了限流才稳定下来。CI 集成的关键点是“要有一个可复现的干净环境”。我的流水线大致是代码构建 → 启动后端服务前端静态资源 → 跑接口测试 → 跑 e2e → 上传 report artifact。启动后端服务这一步用 Docker Compose 最省心把 MySQL、Redis、Nginx 一次性支棱起来。流水线里 e2e 的 jobe2e-test: stage: test script: - npm ci - npx playwright install --with-deps chromium - docker compose up -d - sleep 20 - BASE_URLhttp://localhost:8080 npx playwright test artifacts: when: always paths: - playwright-report/这里有个容易被坑的地方CI 机器上跑 e2e很容易遇到浏览器沙箱权限问题需要加--no-sandbox。如果你在 Docker 容器里跑测试启动命令建议写成npx playwright test --workers4并且容器里要装好libnss3、libatk1.0-0、libatk-bridge2.0-0这些依赖。我用的是官方mcr.microsoft.com/playwright镜像省去了一堆手动环境兼容的麻烦。5. 多环境 profile 体系设计与扩展经验5.1 一套用例怎么跑通 dev、staging、production 环境随着项目推进我又发现一个需求同一套 e2e 用例不仅要跑本地 dev还要能跑 staging 和预发布环境。不同环境的 baseURL、测试账号、数据清理策略不一样如果每次手动改配置很容易漏改或者误改。我最后做了一个 profile 体系用环境变量控制const envConfig { dev: { baseURL: http://localhost:5173, adminUser: admin, adminPass: Test123, }, staging: { baseURL: https://staging.example.com, adminUser: staging_admin, adminPass: Staging123, }, production: { baseURL: https://www.example.com, adminUser: prod_checker, adminPass: Prod123, }, }; const activeEnv process.env.E2E_ENV || dev; module.exports defineConfig({ use: { baseURL: envConfig[activeEnv].baseURL, storageState: fixtures/storageState_${activeEnv}.json } });这样 CI 里跑预发布就是一行命令E2E_ENVstaging npx playwright test这个做法帮团队解决了一个很痛的场景预发布环境与生产环境配置不一致每次发版前手工回归都要逐个环境点一遍。现在只要跑一遍 e2e就能自动验证预发布环境的关键链路。5.2 测试数据按环境隔离接着上面的 profile 体系我又把测试数据也按环境做了隔离。核心思路是所有用例需要的数据都通过唯一后缀保证不冲突。例如const suffix process.env.E2E_ENV ? _${process.env.E2E_ENV} : ; function unique(prefix e2e) { return ${prefix}${suffix}_${Date.now()}_${Math.floor(Math.random() * 10000)}; }这样做之后即使 staging 环境同时有多个人在手工录入数据自动化用例也不会撞车。我甚至遇到过 staging 环境被其他人手工造了一条同名项目导致我们的搜索断言匹配到两行、用例失败的情况。加上环境后缀后这个问题彻底消失了。5.3 从 e2e 回归到测试金字塔的反思做完这套体系我还想分享一个可能被忽略的经验e2e 数量不要失控。很多团队上一个“全链路自动化”项目恨不得把每个页面每个按钮都自动化结果用例数上千每天修复失败用例的时间远超手工回归时间最后整个项目被喊着“放弃”。我的建议是拿“测试金字塔”重新审视自己的用例组合。如果底层单测和接口测试已经覆盖大部分业务那么 e2e 只需要守住最核心的几条主链路即可。如果你发现自己写的 e2e 用例里有大量“重复点击同一个按钮只为了验证跳转”那大概率是在用 e2e 做接口测试应该做的事这是在浪费资源和稳定性。从我当前项目的统计来看最终只有 38 条 e2e 用例但每次发版前跑一遍耗时不到 6 分钟却能在每次回归中至少发现 1 到 2 个被手工回归遗漏的问题。这个性价比远比“跑 800 条用例但全红没人看”高得多。6. 未来可以扩展的方向最后一小块内容不是纯总结而是我在这个项目跑稳定后想到的后续扩展。第一接入视觉回归。现有 e2e 只验证功能逻辑样式错乱、布局错位是覆盖不到的。我可以每个页面留一张基准截图每次跑完自动对比截图差异把样式类回归也兜住。这个方向可以和 Playwright 的toHaveScreenshot()结合但需要注意动态内容如当前时间对截图的影响。第二补上异常链路。我目前重点覆盖了用户主链路和主要分支但类似“接口网关超时”“数据库连接失败”这类异常场景虽然不常见一旦出现对用户影响极大。e2e 可以用page.route()拦截请求人为返回 500 或者超时验证前端有没有展示友好的错误页。这比让后端故意挂掉一个节点容易控制得多。第三把 e2e 结果和线上监控打通。既然 e2e 已经能在几小时内跑完主链路后续完全可以把关键链路做成定时 job每天凌晨自动跑一次 staging 环境的 check。一旦早上进来看到红点就意味着当天发版前必须优先排查而不是等用户反馈才被动发现。如果你也正准备搭 e2e 体系我最后再提醒一句开始阶段不要追求覆盖率和用例数先把“登录一条核心业务主链路”跑通让它稳定跑一周再说。一个能每天稳定运行、失败时能快速定位问题的核心用例比一百个总是误报的用例有价值得多。这套东西后续扩展其实很快但地基稳不稳往往在第一天就决定了。

基于Playwright的E2E测试体系搭建：用例设计、稳定性与CI集成实践

相关推荐

大模型优化核心技术：计算图重构与量化实践

工业路由器R40在隧道通风控制与环境监测中的边缘网关方案

从零开始使用block/goose实现数据库迁移

更多资讯

降维与度量学习：高维数据处理的核心技术解析

Sublime Text 3 3211 完美配置指南：解决卡顿、乱码与插件失效

Docker Compose编排Spring Boot与Redis通信实战

营销人完整技能框架：洞察、策略、内容、渠道与数据实战指南

HDFS核心架构与大数据存储优化实践

IDA Pro逆向入门：PE装载、F5伪代码与异或校验解密

今日更新

Agent-Reach：打通大模型触达外部系统的最后一公里

深度学习图像隐写分析实战：从CNN原理到毕设源码全解析

AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？