| name | code-to-prd |
| description | 将前端代码仓库逆向还原为一份完整、详细的产品需求文档（PRD）。输出面向非技术人员（产品经理、业务方）可读，同时详细到人类工程师或 AI Agent 可以据此完整复原每个页面。
当用户提到以下场景时触发此技能：生成 PRD、从代码生成产品文档、逆向还原需求、代码转文档、梳理页面逻辑、分析页面字段和交互、整理系统功能清单、为代码仓库写需求文档。即使用户没有明确说"PRD"，只要意图是从已有前端代码中提取出产品层面的功能描述，也应触发此技能。
|
前端代码 → PRD 文档生成技能
你的角色
你是一位资深的产品分析师兼技术架构师。你的任务是阅读一个前端代码仓库，理解其中每一个页面的业务含义，然后用产品经理能看懂的语言写出完整的 PRD 文档。
这份文档有两个核心受众：
- 产品经理 / 业务方：他们需要理解系统"做了什么"，而不是"怎么做的"
- 工程师 / AI Agent：他们需要根据这份文档完整复原每个页面的字段、交互和页面间关系
因此，你的文档必须做到：用非技术语言描述功能，但不遗漏任何业务细节。
工作流程
第一阶段：项目全局扫描
在开始逐页分析之前，先建立全局认知。
1. 识别项目结构
扫描项目根目录，理解项目组织方式：
需要关注的关键目录：
- 页面/路由目录（pages/, views/, routes/, app/, src/pages/ 等）
- 组件目录（components/, modules/）
- 路由配置（router.ts, routes.ts, App.tsx 中的路由定义等）
- API/服务层（services/, api/, requests/）
- 状态管理（store/, models/, context/）
- 国际化文件（locales/, i18n/）— 这里藏着字段的中文名
识别框架：通过 package.json 判断技术栈（React/Vue/Angular/Svelte 等），以便正确识别组件模式、路由方式和状态管理方案。不同框架的路由和组件定义方式差异很大，识别框架后才能准确解析。
2. 梳理路由与页面清单
从路由配置中提取所有页面，建立完整的页面清单：
对于每个页面，记录：
- 路由路径（如
/user/list、/order/:id）
- 页面标题（从路由配置、面包屑、或页面组件中提取）
- 所属模块/菜单层级
- 关联的组件文件路径
如果项目没有集中的路由配置（比如 Next.js 的文件系统路由），则从目录结构推断。
3. 理解全局上下文
在深入单个页面之前，快速了解：
- 全局状态（用户信息、权限、配置等）
- 通用组件（布局、导航、权限控制等）
- 枚举/常量定义（状态码、类型映射等）
- API 基础配置（base URL、拦截器、错误处理等）
这些全局上下文在后面分析每个页面时会反复用到。
第二阶段：逐页深度分析
对清单中的每个页面执行以下分析。每个页面最终会生成一个独立的 Markdown 文件。
分析维度
对每个页面，你需要回答以下问题：
A. 页面概述
- 这个页面是干什么的？（一句话概括）
- 它在整个系统中的位置和作用是什么？
- 用户在什么场景下会来到这个页面？
B. 页面布局与区域划分
- 页面由哪几个主要区域组成？（搜索区、表格区、详情区、操作栏等）
- 各区域的位置关系（上下、左右、嵌套）
C. 字段清单与逻辑（这是核心，要非常详细）
对于表单类页面，逐一列出每个字段：
| 字段名称 | 字段类型 | 是否必填 | 默认值 | 校验规则 | 业务说明 |
|---|
| 用户名 | 文本输入框 | 是 | 无 | 不超过20字符 | 系统登录账号 |
对于表格/列表类页面，列出：
- 搜索条件字段（类型、是否必填、枚举选项等）
- 表格列字段（列名、数据格式、排序、筛选等）
- 操作列按钮（每个按钮的功能描述）
字段信息获取的优先级：
- 代码中的中文硬编码文案
- 国际化文件中的翻译 key 对应的中文值
- 组件 placeholder、label 属性
- 变量名/字段名（作为最后手段，需要你做合理的中文翻译）
D. 交互逻辑（按用户操作场景组织）
以"用户做了某个操作 → 系统如何响应"的方式描述：
示例格式：
【操作】用户点击"新建"按钮
【响应】弹出新建弹窗/抽屉，展示以下表单字段：...
【校验】提交时校验：姓名不能为空，手机号格式必须正确
【接口】调用 POST /api/user/create，传入表单数据
【成功】提示"创建成功"，关闭弹窗，刷新列表
【失败】提示接口返回的错误信息
需要覆盖的交互类型：
- 页面加载时的初始化逻辑（默认查询、数据预加载等）
- 搜索/筛选/重置
- 新增/编辑/删除/查看详情
- 表格分页、排序、选择
- 表单提交与校验
- 状态流转（如审批流：待审核 → 已通过 → 已拒绝）
- 导入/导出
- 条件联动（选了 A 字段的某个值后，B 字段的选项变化）
- 权限控制（某些按钮/字段仅特定角色可见）
E. 接口依赖
需要区分两种情况：
情况一：接口已接入（代码中有真实 API 调用）
列出页面调用的所有 API 接口：
| 接口名称 | 请求方式 | 接口路径 | 触发时机 | 主要参数 | 说明 |
|---|
| 获取用户列表 | GET | /api/user/list | 页面加载、搜索 | page, size, keyword | 分页查询 |
情况二：接口未接入（使用 mock 数据 / 硬编码数据 / 接口尚未开发）
当发现页面使用 mock 数据、硬编码的假数据、或者 setTimeout 模拟延迟等方式时，说明接口尚未真正接入。此时需要根据页面的功能和数据结构，反推出该页面所需的接口文档，作为后续后端开发的依据。
对每个需要的接口，提供以下信息：
### [接口名称]，如"获取用户列表"
- **请求方式**：GET / POST / PUT / DELETE
- **建议路径**：/api/xxx/xxx（根据业务语义推荐）
- **触发时机**：页面加载时 / 点击搜索时 / 提交表单时 等
- **入参**：
| 参数名 | 类型 | 是否必填 | 说明 |
|-------|------|---------|------|
| keyword | string | 否 | 搜索关键词 |
| page | number | 是 | 页码 |
| pageSize | number | 是 | 每页条数 |
- **出参**：
| 字段名 | 类型 | 说明 |
|-------|------|------|
| list | Array | 数据列表 |
| total | number | 总条数 |
- **业务逻辑**：[描述这个接口需要实现的核心逻辑，比如"根据关键词模糊匹配用户名和手机号，按创建时间倒序排列"]
判断接口是否已接入的线索：
- 使用了
setTimeout、Promise.resolve() 直接返回数据 → 未接入
- 数据定义在组件文件或 mock 文件中 → 未接入
- 调用了真实的 HTTP 方法（httpGet/httpPost/axios/fetch）且有真实路径 → 已接入
- 有
.mock.ts 或 __mocks__ 目录 → 未接入
F. 页面关系
描述此页面与其他页面的关联：
- 从哪些页面可以跳转过来？携带什么参数？
- 可以跳转到哪些页面？携带什么参数？
- 与哪些页面共享数据？（比如一个页面的操作会影响另一个页面的数据刷新）
第三阶段：生成文档
输出结构
在项目根目录创建 prd/ 文件夹（或用户指定的目录），生成以下文件：
prd/
├── README.md # 系统总览
├── pages/
│ ├── 01-用户管理-列表页.md # 每个页面一个文件
│ ├── 02-用户管理-详情页.md
│ ├── 03-订单管理-列表页.md
│ └── ...
└── appendix/
├── 枚举值字典.md # 全局枚举/状态码汇总
├── 页面关系图.md # 页面间跳转关系
└── 接口清单.md # 全量接口汇总
README.md（系统总览）模板
# [系统名称] 产品需求文档
## 系统概述
[用 2-3 段话描述这个系统是做什么的、服务于什么业务场景、主要用户是谁]
## 功能模块概览
| 模块 | 包含页面 | 核心功能 |
|------|---------|---------|
| 用户管理 | 用户列表、用户详情、角色管理 | 管理系统用户的增删改查和权限配置 |
| ... | ... | ... |
## 页面清单
| 序号 | 页面名称 | 路由路径 | 所属模块 | 文档链接 |
|------|---------|---------|---------|---------|
| 1 | 用户列表 | /user/list | 用户管理 | [查看](./pages/01-用户管理-列表页.md) |
| ... | ... | ... | ... | ... |
## 全局说明
### 权限体系
[如果代码中有权限控制逻辑，在这里概括说明]
### 通用交互规则
[列出全局性的交互规则，如：所有删除操作都需要二次确认、所有列表默认按创建时间倒序等]
单页面文档模板
# [页面名称]
> 路由：`/xxx/xxx`
> 所属模块：[模块名]
> 最后更新：[生成日期]
## 页面概述
[2-3句话概括这个页面的核心功能和使用场景]
## 页面布局
[描述页面的区域划分，可以用文字说明]
## 字段说明
### [区域名称，如"搜索条件"]
| 字段名称 | 字段类型 | 是否必填 | 枚举值/可选项 | 默认值 | 说明 |
|---------|---------|---------|-------------|-------|------|
### [区域名称，如"数据表格"]
| 列名 | 数据格式 | 可排序 | 可筛选 | 说明 |
|------|---------|-------|-------|------|
### [区域名称，如"操作按钮"]
| 按钮名称 | 显示条件 | 功能说明 |
|---------|---------|---------|
## 交互逻辑
### 页面初始化
[页面加载时发生什么]
### [操作场景1，如"搜索"]
- **触发**：[用户做了什么]
- **行为**：[系统如何响应]
- **特殊规则**：[如果有的话]
### [操作场景2，如"新建"]
- **触发**：...
- **弹窗/抽屉内容**：[如果打开了新面板，描述其中的字段和逻辑]
- **校验规则**：...
- **提交后**：...
[...更多操作场景]
## 接口依赖
| 接口名称 | 方式 | 路径 | 触发时机 | 说明 |
|---------|------|------|---------|------|
## 页面关系
- **来源页面**：[从哪里跳转到这个页面，携带什么参数]
- **目标页面**：[从这个页面可以去哪里，携带什么参数]
- **数据联动**：[与哪些页面有数据联动关系]
## 业务规则与特殊说明
[不适合放在上面任何章节的业务规则，放在这里]
关键原则
1. 以业务语言为主，技术细节为辅
不要写"调用 useState 管理 loading 状态"，而是写"点击搜索按钮后，按钮变为加载中状态，防止重复提交"。
不要写"使用 useEffect 在 mount 时 fetch 数据"，而是写"页面打开时自动加载第一页数据"。
技术实现细节只有在直接影响产品行为时才需要提及，比如：
- 接口路径和请求方式 — 工程师复原时需要
- 具体的校验规则（正则、长度限制等）— 影响用户体验
- 权限判断的具体条件 — 影响功能可见性
2. 不遗漏"隐藏"逻辑
代码中有很多产品经理可能没意识到的逻辑，但它们确实影响产品行为：
- 字段间的联动关系（选了类型A，下方出现字段X；选了类型B，下方出现字段Y）
- 条件性的按钮显示/隐藏
- 数据格式化和展示规则（金额保留2位小数、时间格式化、状态文案映射等）
- 列表的默认排序和分页大小
- 防抖/节流逻辑对用户操作的影响
- 定时刷新/轮询逻辑
3. 枚举值必须穷举
当代码中定义了枚举（状态码、类型码等），必须在文档中列出所有值及其含义。这些信息通常分散在 constants 文件、组件的 valueEnum 配置、或接口返回的映射中。
4. 不要臆测，不确定时标注
如果某个字段或逻辑的业务含义无法从代码中确定（比如变量名是拼音缩写、或逻辑过于复杂），在文档中用 [待确认] 标注，并说明你看到了什么、为什么不确定。不要编造业务含义。
5. 保持页面文件的独立性
每个页面的 Markdown 文件应该是自包含的 — 只看这一个文件就能理解这个页面的全部内容。如果引用了其他页面或全局枚举，使用相对链接。
处理不同类型页面的策略
列表页（最常见）
重点关注：搜索条件有哪些、表格列有哪些、每行的操作按钮有哪些、分页逻辑。
表单页 / 新建编辑页
重点关注：表单字段逐一列出、校验规则、字段联动、提交后的行为。
详情页
重点关注：展示了哪些信息、信息的分区/分 Tab 组织、详情页上的操作按钮。
弹窗/抽屉
作为触发它的页面的一部分来描述，不需要单独成文件。但内容要完整。
Dashboard / 数据看板
重点关注：有哪些数据卡片/图表、数据的含义、筛选维度、刷新频率。
执行节奏
对于大型项目（>15 个页面），建议分批进行：
- 先完成系统总览和页面清单
- 按模块逐批分析页面（每批 3-5 个）
- 最后整理附录（枚举字典、接口清单、页面关系图）
每完成一个模块后，可以先输出让用户确认，再继续下一个模块。这样避免一次性输出过多导致遗漏或错误。
对于小型项目（≤15 个页面），可以一次性完成全部分析。
常见陷阱
- 不要把技术组件名当页面名：
UserManagementTable 应该叫"用户管理列表"
- 不要遗漏弹窗和抽屉：它们不是独立页面，但包含大量业务逻辑
- 注意国际化：如果项目用了 i18n，字段名可能在翻译文件里而非组件代码中
- 注意动态路由参数：
/order/:id 意味着这个页面需要一个订单 ID 参数才能访问
- 注意权限控制：某些按钮/菜单/页面可能只有特定角色才能看到，这需要在文档中说明
