AI 能很快写代码，但 Playwright 决定我敢不敢上线

AI 让代码变快，也让回归风险变高

在 AI 的辅助下，重构和开发 OpsKitPro 的速度发生了质变。我们用几天时间就能完成纯 MDX CMS 迁移、TLS 探针诊断功能、或是完整的 API 频控隔离设计——这在过去通常需要数周。

但速度也带来了一种全新的风险：副作用导致的回归错误（Regression by side effect）。

当 AI 重写一个布局组件来修复移动端间距时，它会不会不小心破坏了桌面端悬浮的 Knowledge Map 侧边栏？当它加上了 429 Too Many Requests 的 API 响应契约时，会不会意外导致原本期待 200 OK 的前端 React 组件崩溃？

AI 能很快写出代码。但如果没有边界限制，这种速度只是在给生产环境堆积随时可能爆炸的技术债。

为什么单元测试不够

单元测试（vitest）非常棒。它能证明我们的 LRUCache 频控计算是正确的，或者我们的 TLS checkServerIdentity 函数能精准识别 SAN 不匹配。

但单元测试无法真实反映用户体验。

单元测试不知道 Next.js 的 middleware.ts 是不是意外截断了多语言路由前缀。它也不知道某个未处理的 Hydration Mismatch 是不是导致了整个页面在客户端渲染时白屏。

要想真正放心地发布 AI 辅助编写的代码，我们需要像真实用户（和搜索引擎）那样去测试整个产品。这就是 Playwright 的用武之地。

OpsKitPro 的 Smoke Matrix 检查什么

我们没有为每一个按钮写上百个孤立的 UI 测试，而是建立了一个集中的“Smoke Matrix（冒烟矩阵）”。它的目标是抓住那些一旦发生就必须立刻回滚的灾难性结构错误。

我们的 smoke.spec.ts 重点检查：

关键路径（Critical Routes）： /tools/website-check 页面能否正常加载、接收输入，并在没有控制台报错的情况下提交诊断？
SEO 完整性（SEO Integrity）： /sitemap.xml 是否返回了预期的结构？已下线的语言路径（如 /ja/* → /en/*，/tw/* → /zh/*）是否仍然能正确执行 301 重定向？
多语言稳定性（i18n Stability）： 当你在英语和简体中文之间切换时，庞大的路由矩阵是否会抛出 404？

工具站最怕“页面能打开，但关键路径坏了”

对于一个诊断工具站来说，最可怕的 Bug 不是 500 报错页面——而是工具在后台悄悄失效，却不给用户任何反馈。

假设用户运行 Website Check，触发了后端的频控阀值（3 req/min）。测试脚本必须知道如何处理这种情况。在我们的架构里，频控行为通过控制测试路径或 mock 状态来覆盖，而生产环境的 smoke test 则负责验证公开的 429 契约。我们的 Playwright 设置不仅仅是简单断言 expect(page).toHaveTitle('...')；它还会断言复杂的诊断交互界面是否正确渲染了三态结论（🟢 Pass, 🔴 Fail, ⚪ Unknown），无论网络状态如何变化。

一个小插曲：当新增内容打破了测试

有趣的是，就在写这篇文章时，我们的 Playwright 测试挂了。

不是因为代码写错了，而是因为新增这篇文章改变了页面的 UI 语义。我们的 E2E 测试原本使用 page.getByRole('link', { name: /AI engineering/i }) 来定位 Knowledge Map 的导航栏。这在以前运行得很好，直到这篇文章出现在页面上，引入了一个带有相同文本的文章卡片！

Playwright 立即捕获了这个“严格模式冲突（Strict mode violation）”。它逼着我们意识到，随着内容的增长，我们的测试选择器需要变得更加精准。E2E 测试不仅能抓出代码 Bug，还能抓出那些随着产品扩张而失效的“隐性假设”。

我如何把 Playwright 放进发布前检查

现在我们的工作流被设计得非常严格：

向 AI 描述目标和上下文边界。
AI 生成代码实现。
运行 npm run verify:fast（包含单元测试、构建检查和静态分析）。
运行 npm run test:e2e（Playwright 冒烟矩阵）。

如果 Smoke Matrix 通过了，我们就可以部署上线。如果失败了，我会直接把 Playwright 的 Trace 抛给 AI，对它说：“你把多语言重定向搞坏了，修好它。”

目标不是覆盖率，而是上线信心

我们不追求 100% 的 E2E 测试覆盖率。为每一个微小交互写 Playwright 测试只会让维护变得非常脆弱，反而拖慢开发节奏。

相反，我们使用 Playwright 来确立一条信心底线。它向我们保证：核心的应用架构、本地化路由、API 边界以及 SEO 重定向都依然坚挺。

AI 负责快速写代码。而 Playwright 负责决定我们敢不敢把它推上生产环境。