前端新范式：用 AI 提效开发，用 E2E 保证迭代质量

第一步需求来了先让 AI 拆任务产品经理给了这样一段需求用户从企业系统跳转过来URL 里带有加密凭证 encryptedData我们用这个凭证换取登录 token。如果接口返回用户未绑定手机号就跳转到绑定页让用户填写手机号和验证码完成绑定。把这段话给 AI让它把需求拆成具体的技术任务。AI 输出的结果大致是1. 调用 SSO 登录接口pid: 102229入参 encryptedData 2. 登录成功保存 token跳转到目标页面home/flight/hotel 等 3. 接口返回错误码 10811未绑定跳转到 /login/sso/bind 4. 绑定页输入手机号发送验证码pid: 102024 5. 绑定页提交手机号 验证码pid: 102304 6. 绑定成功跳转到目标页面这一步人工要做的事确认拆解是否合理有没有漏掉的边界情况。比如 encryptedData 为空怎么处理、网络异常有没有兜底提示。第二步AI 编写代码任务清单确认后让 AI 按任务写代码。以sso/index.vue的登录逻辑为例AI 生成的代码是这样的login() { const { encryptedData, to } this.$route.query return request({ url: /gateway/api/user, data: { encryptedData }, }) .then(r { const data r.data if (data) { auth.set(data) this.doRedirect(to) } else { this.$dialog.alert({ message: 数据错误 }) } }) .catch(e { const { code } get(e, data) || {} if (code 10811) { return this.$router.push({ path: /login/sso/bind, query: { to } }) } this.$dialog.alert({ message: e.message || 网络异常 }) }) }第三步AI 分析代码生成 E2E 测试代码写完后把代码给 AI让它提取功能点并生成 E2E 测试用例。基于上面的登录逻辑AI 列出的功能点是功能点测试用例描述SSO 登录成功模拟接口返回 token验证页面跳转到 /home未绑定跳转绑定页模拟接口返回 10811验证跳转到 /login/sso/bind绑定完整流程填手机号、发短信、提交验证跳转成功未勾选协议不勾选直接提交验证提示文案出现手机号格式校验输入错误手机号验证错误提示绑定失败弹窗模拟接口返错验证弹窗内容跨目标页跳转传入 toflight验证最终跳到 /flight生成的测试代码核心设计是用一个 Mock Map 按 pid 拦截接口测试完全不依赖真实后端const mocks new Map() const registerMock (pid, response) { mocks.set(String(pid), response) } // 测试SSO 登录成功后跳首页 test(should redirect to home on successful SSO login, async ({ page }) { registerMock(102229, { res: { hd: { code: 1 }, bd: { data: { token: test_token } } } }) await page.goto(login/sso?encryptedDatavalid_token) await expect(page).toHaveURL(/.*home/) }) // 测试返回 10811 跳绑定页 test(should redirect to binding page on error 10811, async ({ page }) { registerMock(102229, { res: { hd: { code: 10811, desc: Need binding }, bd: {} } }) await page.goto(login/sso?encryptedDataneeds_bind) await expect(page).toHaveURL(/.*login\/sso\/bind/) })这里有个值得关注的细节测试本身就是功能的文字说明。test(should redirect to home on successful SSO login)这一行不需要注释直接读就能理解这个测试在验证什么。第四步人工审阅测试用例这一步是整个流程里最重要的人工环节不能跳过。拿到 AI 生成的测试列表需要从业务角度做审阅主要看三件事覆盖的场景是否合理——AI 生成的 7 个用例基本合理登录成功、失败、绑定流程都有。有没有漏掉的场景——比如用户连续点击发送验证码怎么处理encryptedData 为空时的提示是否友好这些细节 AI 不一定能自动想到。有没有不必要的用例——有些极端场景测试成本高、价值低可以先跳过保持测试套件轻量。审阅完给 AI 一个指令测试用例没问题帮我跑一下。第五步AI 执行测试给出结果npx playwright test tests/e2e/login/sso/sso.spec.js执行结果7 passed (12.3s) should redirect to home on successful SSO login should redirect to binding page on error 10811 should complete binding flow successfully should show error when agreement is not accepted should show error for invalid phone format should show dialog on binding failure should redirect to flight when toflight7 个用例全部通过。这意味着这个功能的主要业务流程已经被自动化保护起来了。之后不管谁改这块代码跑一次测试就能知道有没有改坏。这套方式的实际收益问题以前怎么做现在怎么做需求理解偏差开发自己理解容易漏细节AI 拆任务人确认遗漏更少代码覆盖边界靠经验容易漏错误分支AI 按任务写边界更完整质量保障靠人工回归测试E2E 自动跑每次迭代都有保障新人上手要读代码才能懂业务读测试用例就能懂功能