AI 回归测试
专为 AI 辅助开发设计的测试模式，其中同一模型编写代码并审查代码——这会形成系统性的盲点，只有自动化测试才能发现。
何时激活
- AI 代理（Claude Code、Cursor、Codex）已修改 API 路由或后端逻辑
- 发现并修复了一个 bug——需要防止重新引入
- 项目具有沙盒/模拟模式，可用于无需数据库的测试
- 在代码更改后运行
/bug-check或类似的审查命令 - 存在多个代码路径（沙盒与生产环境、功能开关等）
核心问题
当 AI 编写代码然后审查其自身工作时，它会将相同的假设带入这两个步骤。这会形成一个可预测的失败模式：
AI 编写修复 → AI 审查修复 → AI 表示“看起来正确” → 漏洞依然存在
实际示例（在生产环境中观察到）：
修复 1：向 API 响应添加了 notification_settings
→ 忘记将其添加到 SELECT 查询中
→ AI 审核时遗漏了（相同的盲点）
修复 2：将其添加到 SELECT 查询中
→ TypeScript 构建错误（列不在生成的类型中）
→ AI 审核了修复 1，但未发现 SELECT 问题
修复 3：改为 SELECT *
→ 修复了生产路径，忘记了沙箱路径
→ AI 审核时再次遗漏（第 4 次出现）
修复 4：测试在首次运行时立即捕获了问题 PASS:
模式：沙盒/生产环境路径不一致是 AI 引入的 #1 回归问题。
沙盒模式 API 测试
大多数具有 AI 友好架构的项目都有一个沙盒/模拟模式。这是实现快速、无需数据库的 API 测试的关键。
设置（Vitest + Next.js App Router）
// vitest.config.ts
import { defineConfig } from "vitest/config";
import path from "path";
export default defineConfig({
test: {
environment: "node",
globals: true,
include: ["__tests__/**/*.test.ts"],
setupFiles: ["__tests__/setup.ts"],
},
resolve: {
alias: {
"@": path.resolve(__dirname, "."),
},
},
});
// __tests__/setup.ts
// Force sandb…
