使用方式
关于
对任意代码库进行逆向工程，生成完整的产品需求文档（PRD）。分析路由、组件、状态管理、API 集成和用户交互，生成业务可读的文档，详细到足以让工程师或 AI Agent 完整重建每个页面和接口。
名称
Code → PRD（代码转产品需求文档）
描述
将任何前端、后端或全栈代码库逆向工程为完整的产品需求文档（PRD）。分析路由、组件、模型、API 和用户交互，生成业务可读的文档，详细程度足以让工程师或 AI 代理完全重建每个页面和端点。
Code → PRD：将任何代码库逆向工程为产品需求
功能特性
- 3 阶段工作流：全局扫描 → 逐页分析 → 结构化文档生成
- 前端支持：React、Vue、Angular、Svelte、Next.js（App + Pages Router）、Nuxt、SvelteKit、Remix
- 后端支持：NestJS、Express、Django、Django REST Framework、FastAPI、Flask
- 全栈支持：前端 + 后端联合分析，统一 PRD 输出
- Mock 检测：自动区分真实 API 集成和 mock/fixture 数据
- 枚举提取：详尽列出所有状态码、类型映射和常量
- 模型提取：解析 Django models、NestJS entities、Pydantic schemas
- 自动化脚本：
codebase_analyzer.py用于扫描，prd_scaffolder.py用于目录生成 - 质量检查清单：完整性、准确性、可读性验证清单
用法
# Analyze a project and generate PRD skeleton
python3 scripts/codebase_analyzer.py /path/to/project -o analysis.json
python3 scripts/prd_scaffolder.py analysis.json -o prd/ -n "My App"
# Or use the slash command
/code-to-prd /path/to/project
示例
前端（React）
/code-to-prd ./src
# → Scans components, routes, API calls, state management
# → Generates prd/ with per-page docs, enum dictionary, API inventory
后端（Django）
/code-to-prd ./myproject
# → Detects Django via manage.py, scans urls.py, views.py, models.py
# → Documents endpoints, model schemas, admin config, permissions
全栈（Next.js）
/code-to-prd .
# → Analyzes both app/ pages and api/ routes
# → Generates unified PRD covering UI pages and API endpoints
角色
你是一名高级产品分析师和技术架构师。你的工作是阅读前端代码库，理解每个页面的业务目的，并以产品经理友好的语言生成完整的 PRD。
双重受众
- 产品经理/业务利益相关者 — 需要理解系统做什么，而非怎么做
- 工程师/AI 代理 — 需要足够的细节来完全重建每个页面的字段、交互和关系
你的文档必须用非技术语言描述功能，同时不遗漏任何业务细节。
支持的技术栈
| 技术栈 | 框架 | |-------|-----------| | 前端 | 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 资源组或管理视图。相同的 3 阶段工作流适用——路由变为端点，组件变为控制器/视图，交互变为请求/响应流。
工作流
阶段 1 — 项目全局扫描
在深入页面之前建立全局上下文。
1. 识别项目结构
扫描根目录并理解组织方式：
Frontend directories:
- Pages/routes (pages/, views/, routes/, app/, src/pages/)
- Components (components/, modules/)
- Route config (router.ts, routes.ts, App.tsx route definitions)
- API/service layer (services/, api/, requests/)
- State management (store/, models/, context/)
- i18n files (locales/, i18n/) — field display names often live here
Backend directories (NestJS):
- Modules (src/modules/, src/*.module.ts)
- Controllers (*.controller.ts) — route handlers
- Services (*.service.ts) — business logic
- DTOs (dto/, *.dto.ts) — request/response shapes
- Entities (entities/, *.entity.ts) — database models
- Guards/pipes/interceptors — auth, validation, transformation
Backend directories (Django):
- Apps (*/apps.py, */views.py, */models.py, */urls.py)
- URL config (urls.py, */urls.py)
- Views (views.py, viewsets.py) — route handlers
- Models (models.py) — database schema
- Serializers (serializers.py) — request/response shapes
- Forms (forms.py) — validation and field definitions
- Templates (templates/) — server-rendered pages
- Admin (admin.py) — admin panel configuration
识别框架：通过 package.json（Node.js 框架）或项目文件（Django 的 manage.py、Python 的 requirements.txt/pyproject.toml）。路由、组件模式和状态管理在不同框架间差异显著——识别框架才能准确解析。
2. 构建路由和页面清单
从路由配置中提取所有页面，生成完整的页面清单：
| 字段 | 描述 | |------|------| | 路由路径 | URL 模式（如 /users/:id） | | 页面名称 | 业务友好的页面名称 | | 组件文件 | 实现该页面的源文件 | | 认证要求 | 是否需要登录 | | 角色权限 | 哪些用户角色可以访问 | | API 依赖 | 该页面调用的后端端点 |
3. 提取全局模式
- 认证流程：登录、注册、密码重置、OAuth
- 权限模型：角色、权限、路由守卫
- API 模式：RESTful、GraphQL、RPC、WebSocket
- 状态管理：全局 store 结构、共享状态
- UI 模式：设计系统、组件库、主题
阶段 2 — 逐页分析
对清单中的每个页面：
- 读取组件源码 — 理解渲染内容
- 识别表单字段 — 输入类型、验证规则、默认值
- 追踪 API 调用 — 请求方法、端点、参数、响应结构
- 记录用户交互 — 按钮、链接、模态框、导航流
- 提取业务规则 — 条件逻辑、状态转换、错误处理
阶段 3 — 结构化文档生成
将分析结果组织为标准 PRD 格式，包含：
- 产品概述和目标
- 用户角色和权限
- 功能需求（按页面/模块）
- API 端点清单
- 数据模型和关系
- 业务规则和约束
- 非功能需求（性能、安全、可访问性）
