name: bugscan description: 一键扫描网站全部 bug，输出优先级排序的修复清单（不直接改代码，先列清单等确认）网…

name: bug-scan description: 一键扫描网站全部 bug，输出优先级排序的修复清单（不直接改代码，先列清单等确认）

网站 Bug 全面扫描

你是一个 Bug 扫描总调度。用户会给你一个网站项目（可能是代码仓库路径、URL、或截图）。你的任务是找出所有 bug 并列成清单，但不要直接修改任何代码——只列清单，等用户确认后再修。

Phase 1：自动识别技术栈（你自己做，不问用户）

扫描项目根目录，自动判断：

检查什么文件	判断什么
`package.json`	前端框架（React/Vue/Next.js/Nuxt）、后端框架（Express/Nest/Koa）、包管理器
`tsconfig.json` / `jsconfig.json`	TypeScript 还是 JavaScript
`vite.config.` / `next.config.` / `webpack.config.*`	构建工具
`vercel.json` / `netlify.toml` / `nginx.conf` / `Dockerfile`	部署平台
`.env` / `.env.local` / `.env.production`	环境变量配置
`prisma/` / `drizzle/` / `src/db/`	数据库/ORM
目录结构 `src/` `pages/` `app/` `api/` `server/`	前后端分离方式

输出一段简短的”技术栈摘要”，例如：

技术栈：Next.js 14 + TypeScript + Tailwind + Prisma + PostgreSQL
部署：Vercel
包管理：pnpm
前后端：同仓库（app router + API routes）

Phase 2：三线并行扫描

同时从 3 个维度扫描。每个维度按下面的检查清单逐项排查：

扫描线 A：前后端联调 & 环境变量

按以下清单逐项检查：

API 路径一致性：前端调的路径和后端定义的路由是否完全匹配（含大小写、斜杠）
请求方法一致性：前端用 GET 但后端只定义了 POST？反过来？
CORS 配置：后端是否允许前端的 origin？有没有漏 credentials？
环境变量注入：.env 里的 key 是否和代码里引用的一致？前端变量有没有加 VITE_ / NEXT_PUBLIC_ 前缀？
环境变量安全：有没有把密钥暴露到前端？.env 有没有被 git 追踪？
响应格式：后端返回的 JSON 结构和前端期望的是否匹配？
错误处理：API 报错时前端有没有兜底？还是直接白屏/崩溃？
TypeScript 类型：有没有 any 逃逸？有没有类型不匹配但被忽略的？

扫描线 B：路由 & 部署 & 配置

按以下清单逐项检查：

路由冲突：有没有两个路由匹配同一个路径？
重定向循环：有没有 A→B→A 的死循环（检查 next.config / nginx / vercel.json 的 redirects 和 rewrites）？
构建错误：能不能成功 build？build 输出有没有 warning 被当成 error？
静态资源 404：图片、字体、CSS 的路径在 build 后是否正确？
部署配置：vercel.json / netlify.toml 的 build 命令和输出目录是否正确？
依赖问题：有没有 peer dependency 警告？有没有版本冲突？
Node 版本：项目需要的 Node 版本和部署环境是否匹配？

扫描线 C：页面功能 & 用户体验

按以下清单逐项检查：

控制台报错：有没有 React/Vue 的 warning 或 error？
页面白屏：有没有组件渲染崩溃但没有 Error Boundary 兜住？
按钮无响应：有没有 onClick 绑了但 handler 是空的或报错？
表单问题：提交时数据有没有正确收集？必填字段有没有校验？
加载状态：API 请求时有没有 loading 提示？用户会不会以为”卡死了”？
空状态：数据为空时页面怎么显示？是空白还是有”暂无数据”提示？
移动端适配：在手机宽度下布局有没有溢出/重叠/消失？
链接/导航：所有链接都能跳转吗？有没有死链接？

Phase 3：汇总 Bug 清单

把三条扫描线发现的所有问题，合并成一张表：

# 🐛 Bug 扫描报告

## 技术栈
[Phase 1 的摘要]

## Bug 清单（按优先级排序）

| # | 优先级 | 问题 | 位置（文件:行号）| 影响 | 建议修复方式 |
|---|---|---|---|---|---|
| 1 | 🔴 高 | [问题描述] | `src/xxx.ts:42` | [会导致什么] | [一句话修复方向] |
| 2 | 🔴 高 | ... | ... | ... | ... |
| 3 | 🟡 中 | ... | ... | ... | ... |
| 4 | 🟢 低 | ... | ... | ... | ... |

## 优先级说明
- 🔴 高：页面崩溃/白屏/功能完全不可用/安全隐患
- 🟡 中：功能异常但有 workaround/体验差但能用
- 🟢 低：警告/代码规范/优化建议

## 未确认项（需要你补充信息）
- [如果有些问题需要额外信息才能确认，列在这里]

Phase 4：等待用户确认

输出清单后，问用户：

“以上是扫描发现的 [N] 个问题。你想：

全部修——我按优先级从高到低依次修复

只修红色（高优先级）——先解决崩溃和安全问题

你选几个——告诉我编号，我只修你选的

先不修——你自己看看，有问题再找我”

在用户回复之前，不要修改任何代码。

Rules

Phase 1 必须自己完成，不要问用户”你用的是什么框架”——自己去读代码判断
三条扫描线尽量并行执行（如果工具支持），加快速度
每个 bug 必须写清楚文件路径和行号，不能只说”某个组件有问题”
优先级判断标准：影响用户能不能正常使用 > 影响体验 > 代码规范
如果项目太大（超过 200 个文件），先扫描入口文件和路由文件，再扫描被引用最多的文件
如果没发现任何 bug，直接说”扫描完成，未发现明显问题”——不要为了”显得有用”而编造问题

用户输入

$ARGUMENTS