SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场code-to-prd

code-to-prd

写作与研究

查看项目

更新于 10-15 12:40

技能介绍

用途

Code → PRD 用于把任意前端、后端或全栈代码库逆向工程为一份完整的产品需求文档（PRD）。它分析路由、组件、模型、API 和用户交互，产出业务可读、且详细到足以让工程师或 AI 智能体完整重建每个页面和接口的文档。

主要能力

  • 三阶段工作流：全局扫描 → 逐页分析 → 结构化文档生成。
  • 前端支持：React、Vue、Angular、Svelte、Next.js（App + Pages Router）、Nuxt、SvelteKit、Remix、Astro。
  • 后端支持：NestJS、Express、Fastify、Django、Django REST Framework、FastAPI、Flask。
  • 全栈支持：前后端联合分析，输出统一的 PRD。
  • Mock 检测：自动区分真实 API 集成与 mock/fixture 数据。
  • 枚举提取：穷尽列出所有状态码、类型映射和常量。
  • 模型提取：解析 Django models、NestJS entities、Pydantic schemas。
  • 自动化脚本：codebase_analyzer.py 用于扫描，prd_scaffolder.py 用于目录生成。
  • 质量检查清单：用于完整性、准确性和可读性的验证清单。

使用方式

分析项目并生成 PRD 骨架：

python3 scripts/codebase_analyzer.py /path/to/project -o analysis.json
python3 scripts/prd_scaffolder.py analysis.json -o prd/ -n "My App"

或使用斜杠命令：

/code-to-prd /path/to/project

示例：

# 前端（React）
/code-to-prd ./src
# → 扫描组件、路由、API 调用、状态管理
# → 生成 prd/，含逐页文档、枚举字典、API 清单

# 后端（Django）
/code-to-prd ./myproject
# → 通过 manage.py 识别 Django，扫描 urls.py、views.py、models.py
# → 记录接口、模型 schema、admin 配置、权限

# 全栈（Next.js）
/code-to-prd .
# → 同时分析 app/ 页面与 api/ 路由
# → 生成覆盖 UI 页面和 API 接口的统一 PRD

角色与受众

该技能的角色设定为资深产品分析师与技术架构师，目标是阅读代码库、理解每个页面的业务目的，并用产品经理友好的语言产出完整 PRD。文档面向双重受众：产品经理/业务相关方需要理解系统做什么而非怎么做；工程师/AI 智能体需要足够细节以完整重建每个页面的字段、交互与关系。文档须用非技术语言描述功能，同时不遗漏任何业务细节。后端专属项目中，「页面」概念映射为 API 资源组或管理视图，同一套三阶段工作流依然适用——路由变为接口，组件变为控制器/视图，交互变为请求/响应流程。

工作流

阶段一：项目全局扫描

先建立全局上下文再深入页面。识别项目结构（前端目录如 pages/routes、components、路由配置、API/service 层、状态管理、i18n 文件；NestJS 的 modules、controllers、services、DTOs、entities、guards/pipes/interceptors；Django 的 apps、urls、views、models、serializers、forms、templates、admin），并依据 package.json 或项目文件（Django 的 manage.py、Python 的 requirements.txt/pyproject.toml）识别框架。随后建立路由与页面清单（路由路径、页面标题、模块/菜单层级、组件文件路径），文件系统路由（Next.js、Nuxt）则从目录结构推断；后端项目中清单变为接口/资源清单（接口路径、HTTP 方法、控制器/视图、模块/app、是否需要鉴权）。最后映射全局上下文：全局状态、共享组件、枚举与常量、API 基础配置、数据库模型、中间件、DTO/序列化器。

阶段二：逐页深度分析

对清单中每个页面进行分析，每个页面产出独立 Markdown 文件。分析维度包括：页面概览、布局与区域、字段清单（核心，须穷尽——表单页面列出每个字段的名称/类型/必填/默认值/校验/业务描述，列表页面列出搜索筛选字段、表格列、行操作按钮）、交互逻辑（以「用户动作 → 系统响应」描述，覆盖页面加载、搜索筛选重置、CRUD、分页排序行选择批量操作、表单提交校验、状态流转、导入导出、字段联动、权限控制、轮询/自动刷新）、API 依赖（集成情况与 Mock 情况分别记录）、页面关系（入站、出站、数据耦合）。

阶段三：生成文档

在项目根目录（或用户指定目录）创建 prd/ 结构，包含 README.md 系统概览、pages/ 逐页文件、appendix/（enum-dictionary.md 枚举字典、page-relationships.md 页面关系图、api-inventory.md API 完整参考）。

关键原则

  1. 业务语言优先：不写「调用 useState 管理 loading 状态」，而写「搜索按钮显示加载提示以防止重复提交」。
  2. 不遗漏隐藏逻辑：字段联动、按钮条件可见性、数据格式化、默认排序与分页大小、防抖/节流影响、轮询/自动刷新间隔。
  3. 穷尽列出枚举：状态码、类型码、角色类型等每个值及其含义。
  4. 标记不确定项——不猜测：业务含义无法从代码判断时标记 [TBC] 并说明观察与不确定原因，绝不编造业务含义。
  5. 保持页面文件自包含：单独阅读任一文件即可获得完整理解。

适用场景

需要从既有代码反向梳理产品需求、生成产品文档、协助 PM 理解系统行为，或为 AI 智能体提供重建依据的团队与个人。

工具与脚本

  • scripts/codebase_analyzer.py：扫描代码库 → 提取路由、API、模型、枚举、结构。用法：python3 codebase_analyzer.py /path/to/project。
  • scripts/prd_scaffolder.py：从分析 JSON 生成 PRD 目录骨架。用法：python3 prd_scaffolder.py analysis.json。

限制

关于收费、价格、平台可用性、效果保证等信息，资料中暂未提供。