用途
本技能针对 AI 辅助开发中的回归测试，解决一个具体问题：当同一个模型既写代码又审查代码时，会把相同的假设带入两个环节，形成系统性盲区。资料给出的失败模式为：AI 写修复 → AI 审查修复 → AI 说「看起来正确」→ Bug 依然存在。
何时启用
资料列出以下触发条件：AI 智能体（Claude Code、Cursor、Codex）修改了 API 路由或后端逻辑；发现并修复了一个 Bug，需要防止其再次引入；项目具备可用于免数据库测试的沙箱/模拟模式；在代码变更后运行 /bug-check 或类似审查命令；存在多条代码路径（沙箱与生产、功能开关等）。
核心问题
资料给出一个真实案例：某字段的修复过程共经历 4 次。第 1 次在 API 响应中加入了 notification_settings，但忘记加入 SELECT 查询，AI 审查时因同样的盲区而未发现；第 2 次加入 SELECT 查询后触发 TypeScript 构建错误（该列不在生成的类型中）；第 3 次改用 SELECT *，修好了生产路径却忘记沙箱路径，AI 审查再次漏过，这是第 4 次出现；第 4 次由测试在首次运行时立即捕获并通过。资料指出，沙箱与生产路径不一致是排名第一的 AI 引入型回归。
沙箱模式 API 测试
资料认为，具备 AI 友好架构的项目大多有沙箱/模拟模式，这是实现快速、免数据库 API 测试的关键。文中提供了 Vitest + Next.js App Router 的配置示例，在 setup 文件中强制开启沙箱模式并清空 Supabase 相关环境变量；同时给出 createTestRequest 与 parseResponse 两个测试辅助函数，用于构造 NextRequest、支持 sandboxUserId 请求头、序列化请求体并解析响应状态与 JSON。
编写回归测试
关键原则是：为已经发现的 Bug 写测试，而不是为能正常工作的代码写测试。资料提供了一份 profile API 测试示例，先定义响应必须包含的字段契约列表（其中 notification_settings 标注为「在 Bug 发现其缺失后加入」），再断言状态码为 200、所有必需字段存在，并单独编写一条针对该 Bug 的回归测试，断言 notification_settings 不是 undefined。
测试沙箱与生产一致性
资料给出会话列表接口的测试示例，在沙箱模式下逐条断言响应中的会话对象包含 partner_name 字段。注释说明该测试曾捕获一个 Bug：partner_name 只被加入了生产路径，未加入沙箱路径。
集成到 Bug-Check 工作流
资料定义的 bug-check 命令分为三步。第一步为强制且不可跳过的自动化测试，先运行 npm run test 与 npm run build；测试失败则作为最高优先级 Bug 上报，构建失败则将类型错误作为最高优先级上报，两者均通过才进入第二步。第二步为 AI 代码审查，检查点包括沙箱与生产路径一致性、API 响应结构是否符合前端预期、SELECT 子句完整性、带回滚的错误处理、乐观更新的竞态条件。第三步要求为每个被修复的 Bug 提出一条回归测试。资料还给出流程图：测试失败即机械地发现 Bug（无需 AI 判断），通过则继续；构建同理；之后进行带已知盲区意识的 AI 代码审查并上报发现；最后为每个修复编写回归测试，以便下一次 bug-check 能捕获修复是否失效。
常见 AI 回归模式
资料总结四类模式。模式一为沙箱与生产路径不一致，出现频率最高（4 次回归中占 3 次），修复方式是两条路径返回相同结构，测试方式是在沙箱模式下断言必需字段齐全。模式二为 SELECT 子句遗漏，在使用 Supabase/Prisma 新增列时常见，表现为新列加入响应却未加入 SELECT，导致该字段始终为 undefined，修复方式是使用 SELECT * 或显式包含新列。模式三为错误状态泄漏，即设置错误状态但未清除旧数据，修复方式是在错误分支中清空相关状态。模式四为乐观更新缺少回滚，删除操作失败后 UI 已移除但数据库仍有记录，修复方式是预先保存上一份状态并在失败时回滚。
策略与快查
资料主张不要追求 100% 覆盖率，而是在发现 Bug 的位置写测试：某个 API 出现 Bug 就为该 API 写测试，未出现过 Bug 的接口暂不写。理由是 AI 容易重复同类错误、Bug 聚集在复杂区域（鉴权、多路径逻辑、状态管理），一旦测试覆盖，同类回归便不会再次发生，测试数量随修复自然增长。快查表将沙箱/生产不一致与 SELECT 遗漏列为高优先级，错误状态泄漏与缺少回滚列为中优先级，类型转换掩盖 null 亦为中优先级。
DO / DON'T
资料建议：发现 Bug 后立即写测试（如有可能在修复前写）；测试 API 响应结构而非实现；每次 bug-check 第一步就运行测试；借助沙箱模式让测试保持快速（总计 1 秒以内）；以所预防的 Bug 命名测试（如 BUG-R1 regression）。不建议：为从未出现过 Bug 的代码写测试；把 AI 自审当作自动化测试的替代；因为「只是模拟数据」而跳过沙箱路径测试；在单元测试足够时写集成测试；以覆盖率百分比为目标，而应以防止回归为目标。
限制
资料未说明该技能的适用技术栈范围之外的通用性，未提及收费标准、价格或商业授权信息，也未提供平台支持列表、性能基准或团队规模要求，这些事实暂未提供。