메뉴
将前端代码仓库逆向还原为一份完整、详细的产品需求文档（PRD）。输出面向非技术人员（产品经理、业务方）可读，同时详细到人类工程师或 AI Agent 可以据此完整复原每个页面。 当用户提到以下场景时触发此技能：生成 PRD、从代码生成产品文档、逆向还原需求、代码转文档、梳理页面逻辑、分析页面字段和交互、整理系统功能清单、为代码仓库写需求文档。即使用户没有明确说"PRD"，只要意图是从已有前端代码中提取出产品层面的功能描述，也应触发此技能。
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/lihanglogan/code-to-prd --skill code-to-prd명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | code-to-prd |
| description | 将前端代码仓库逆向还原为一份完整、详细的产品需求文档（PRD）。输出面向非技术人员（产品经理、业务方）可读，同时详细到人类工程师或 AI Agent 可以据此完整复原每个页面。 当用户提到以下场景时触发此技能：生成 PRD、从代码生成产品文档、逆向还原需求、代码转文档、梳理页面逻辑、分析页面字段和交互、整理系统功能清单、为代码仓库写需求文档。即使用户没有明确说"PRD"，只要意图是从已有前端代码中提取出产品层面的功能描述，也应触发此技能。 |
你是一位资深的产品分析师兼技术架构师。你的任务是阅读一个前端代码仓库，理解其中每一个页面的业务含义，然后用产品经理能看懂的语言写出完整的 PRD 文档。
这份文档有两个核心受众：
因此，你的文档必须做到：用非技术语言描述功能，但不遗漏任何业务细节。
在开始逐页分析之前，先建立全局认知。
扫描项目根目录，理解项目组织方式：
需要关注的关键目录：
- 页面/路由目录（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 等），以便正确识别组件模式、路由方式和状态管理方案。不同框架的路由和组件定义方式差异很大，识别框架后才能准确解析。
从路由配置中提取所有页面，建立完整的页面清单：
对于每个页面，记录：
/user/list、/order/:id）如果项目没有集中的路由配置（比如 Next.js 的文件系统路由），则从目录结构推断。
在深入单个页面之前，快速了解：
这些全局上下文在后面分析每个页面时会反复用到。
对清单中的每个页面执行以下分析。每个页面最终会生成一个独立的 Markdown 文件。
对每个页面，你需要回答以下问题：
A. 页面概述
B. 页面布局与区域划分
C. 字段清单与逻辑（这是核心，要非常详细）
对于表单类页面，逐一列出每个字段：
| 字段名称 | 字段类型 | 是否必填 | 默认值 | 校验规则 | 业务说明 |
|---|---|---|---|---|---|
| 用户名 | 文本输入框 | 是 | 无 | 不超过20字符 | 系统登录账号 |
对于表格/列表类页面，列出：
字段信息获取的优先级：
D. 交互逻辑（按用户操作场景组织）
以"用户做了某个操作 → 系统如何响应"的方式描述：
示例格式：
【操作】用户点击"新建"按钮
【响应】弹出新建弹窗/抽屉，展示以下表单字段：...
【校验】提交时校验：姓名不能为空，手机号格式必须正确
【接口】调用 POST /api/user/create，传入表单数据
【成功】提示"创建成功"，关闭弹窗，刷新列表
【失败】提示接口返回的错误信息
需要覆盖的交互类型：
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.ts 或 __mocks__ 目录 → 未接入F. 页面关系
描述此页面与其他页面的关联：
在项目根目录创建 prd/ 文件夹（或用户指定的目录），生成以下文件：
prd/
├── README.md # 系统总览
├── pages/
│ ├── 01-用户管理-列表页.md # 每个页面一个文件
│ ├── 02-用户管理-详情页.md
│ ├── 03-订单管理-列表页.md
│ └── ...
└── appendix/
├── 枚举值字典.md # 全局枚举/状态码汇总
├── 页面关系图.md # 页面间跳转关系
└── 接口清单.md # 全量接口汇总
# [系统名称] 产品需求文档
## 系统概述
[用 2-3 段话描述这个系统是做什么的、服务于什么业务场景、主要用户是谁]
## 功能模块概览
| 模块 | 包含页面 | 核心功能 |
|------|---------|---------|
| 用户管理 | 用户列表、用户详情、角色管理 | 管理系统用户的增删改查和权限配置 |
| ... | ... | ... |
## 页面清单
| 序号 | 页面名称 | 路由路径 | 所属模块 | 文档链接 |
|------|---------|---------|---------|---------|
| 1 | 用户列表 | /user/list | 用户管理 | [查看](./pages/01-用户管理-列表页.md) |
| ... | ... | ... | ... | ... |
## 全局说明
### 权限体系
[如果代码中有权限控制逻辑，在这里概括说明]
### 通用交互规则
[列出全局性的交互规则，如：所有删除操作都需要二次确认、所有列表默认按创建时间倒序等]
# [页面名称]
> 路由：`/xxx/xxx`
> 所属模块：[模块名]
> 最后更新：[生成日期]
## 页面概述
[2-3句话概括这个页面的核心功能和使用场景]
## 页面布局
[描述页面的区域划分，可以用文字说明]
## 字段说明
### [区域名称，如"搜索条件"]
| 字段名称 | 字段类型 | 是否必填 | 枚举值/可选项 | 默认值 | 说明 |
|---------|---------|---------|-------------|-------|------|
### [区域名称，如"数据表格"]
| 列名 | 数据格式 | 可排序 | 可筛选 | 说明 |
|------|---------|-------|-------|------|
### [区域名称，如"操作按钮"]
| 按钮名称 | 显示条件 | 功能说明 |
|---------|---------|---------|
## 交互逻辑
### 页面初始化
[页面加载时发生什么]
### [操作场景1，如"搜索"]
- **触发**：[用户做了什么]
- **行为**：[系统如何响应]
- **特殊规则**：[如果有的话]
### [操作场景2，如"新建"]
- **触发**：...
- **弹窗/抽屉内容**：[如果打开了新面板，描述其中的字段和逻辑]
- **校验规则**：...
- **提交后**：...
[...更多操作场景]
## 接口依赖
| 接口名称 | 方式 | 路径 | 触发时机 | 说明 |
|---------|------|------|---------|------|
## 页面关系
- **来源页面**：[从哪里跳转到这个页面，携带什么参数]
- **目标页面**：[从这个页面可以去哪里，携带什么参数]
- **数据联动**：[与哪些页面有数据联动关系]
## 业务规则与特殊说明
[不适合放在上面任何章节的业务规则，放在这里]
不要写"调用 useState 管理 loading 状态"，而是写"点击搜索按钮后，按钮变为加载中状态，防止重复提交"。
不要写"使用 useEffect 在 mount 时 fetch 数据"，而是写"页面打开时自动加载第一页数据"。
技术实现细节只有在直接影响产品行为时才需要提及，比如：
代码中有很多产品经理可能没意识到的逻辑，但它们确实影响产品行为：
当代码中定义了枚举（状态码、类型码等），必须在文档中列出所有值及其含义。这些信息通常分散在 constants 文件、组件的 valueEnum 配置、或接口返回的映射中。
如果某个字段或逻辑的业务含义无法从代码中确定（比如变量名是拼音缩写、或逻辑过于复杂），在文档中用 [待确认] 标注，并说明你看到了什么、为什么不确定。不要编造业务含义。
每个页面的 Markdown 文件应该是自包含的 — 只看这一个文件就能理解这个页面的全部内容。如果引用了其他页面或全局枚举，使用相对链接。
重点关注：搜索条件有哪些、表格列有哪些、每行的操作按钮有哪些、分页逻辑。
重点关注：表单字段逐一列出、校验规则、字段联动、提交后的行为。
重点关注：展示了哪些信息、信息的分区/分 Tab 组织、详情页上的操作按钮。
作为触发它的页面的一部分来描述，不需要单独成文件。但内容要完整。
重点关注：有哪些数据卡片/图表、数据的含义、筛选维度、刷新频率。
对于大型项目（>15 个页面），建议分批进行：
每完成一个模块后，可以先输出让用户确认，再继续下一个模块。这样避免一次性输出过多导致遗漏或错误。
对于小型项目（≤15 个页面），可以一次性完成全部分析。
UserManagementTable 应该叫"用户管理列表"/order/:id 意味着这个页面需要一个订单 ID 参数才能访问