codebase-to-prdlisted

## 何时使用 当你拿到一个**已有源码**的前端、后端或全栈项目，需要把它逆向成一份**业务可读、又足够细到能让工程师或 AI 完整重建每个页面/接口**的 PRD（产品需求文档）时使用。典型场景：给祖传项目补需求文档、从代码抽取产品规格、整理页面字段与交互清单、梳理 API 接口与枚举字典。 支持栈： - **前端**：React、Vue、Angular、Svelte、Next.js（App/Pages Router）、Nuxt、SvelteKit、Remix、Astro。 - **后端**：NestJS、Express、Fastify、Django、Django REST Framework、FastAPI、Flask。 - **全栈**：Next.js（API routes + pages）、Nuxt（server/ + pages/）、Django（views + templates）。 > 后端项目里，「页面」概念映射为 **API 资源组 / admin 视图**：路由→接口，组件→控制器/视图，交互→请求/响应流。同一套三阶段流程仍然适用。 **不该用的边界：** - 没有可读源码、纯凭口述做需求规划 → 这是从 0 写 PRD，不是逆向。 - 只想做 UI 视觉走查、可用性评估或代码质量审查 → 用对应专门方法，本技能聚焦「业务功能复原」。 - 只要一句话接口说明、不需要完整结构化文档时，杀鸡用牛刀。 ## 步骤 采用**三阶段**工作流：全局扫描 → 逐页深析 → 结构化文档生成。 ### 阶段一 · 项目全局扫描 先建立全局上下文再钻页面。 1. **识别项目结构**：扫根目录，定位 - 前端：页面/路由（`pages/ views/ routes/ app/ src/pages/`）、组件（`components/ modules/`）、路由配置（`router.ts routes.ts`）、API/service 层（`services/ api/ requests/`）、状态管理（`store/ models/ context/`）、i18n（`locales/ i18n/`，字段显示名常在此）。 - 后端(NestJS)：模块 `*.module.ts`、控制器 `*.controller.ts`、服务 `*.service.ts`、`dto/`、实体 `*.entity.ts`、guards/pipes/interceptors。 - 后端(Django)：apps、`urls.py`、`views.py/viewsets.py`、`models.py`、`serializers.py`、`forms.py`、`templates/`、`admin.py`。 2. **判定框架**：从 `package.json`（Node 系）或项目文件（`manage.py`→Django，`requirements.txt/pyproject.toml`→Python）识别。框架不同，路由/组件/状态写法差异极大，先判定才能准确解析。 3. **构建路由/页面清单**：从路由配置抽出全部页面 → 字段为「路由路径｜页面标题｜模块/菜单层级｜组件文件路径」。文件路由（Next.js/Nuxt）按目录结构推断。后端则产出**接口/资源清单**：「接口路径｜HTTP 方法｜控制器/视图｜所属模块/app｜是否鉴权」。NestJS 从 `@Controller` + `@Get/@Post/...`