原型逆向需求文档生成器（proto-to-prd）

从原型工程的 Vue/HTML 代码文件中逆向提取结构化需求，生成专业级 PRD 文档，并可嵌入原型工程实现需求与代码的交互式对照查阅。

核心价值

原型工程是"做了什么"的直接体现，但缺乏"为什么这样做"和"应该怎样用"的需求说明。本技能将代码中隐含的产品决策、交互逻辑、数据流显性化，补齐原型工程最缺的需求文档层。

工作流程

总览

输入（zip/目录）
  → 二次更新前置检查（指纹状态、outputs完整性、组件备份）
  → 代码扫描 + 指纹计算
  → 首次：全量解析 / 增量：diff指纹 + 变更影响报告
  → PM评审 → 需求确认清单
  → 用户确认/修正
  → 结构化PRD生成（Markdown + JSON双格式）
  → 一致性校验 → 有问题则生成补充项 → 用户补充
  → 交互视图组件生成 + Vue模板语法验证（强制） + 工程集成脚本
  → 交付

阶段1：代码扫描与PM评审

步骤1：接收输入

用户可提供两种输入形式：
- zip 包：用户上传的原型工程压缩包，先解压到临时目录再处理
- 目录路径：沙箱中已有的原型工程目录路径

收到输入后，先确认目录结构是否可识别（是否包含 .vue / .html 文件）。如果目录结构非标准，提示用户指定入口目录。

步骤2：代码扫描与指纹计算

主方案：运行 scripts/scan.py 对工程目录进行扫描，产出：
- 文件清单（.vue / .html / .js / .ts 文件）
- 目录结构树
- 代码指纹（每个文件的内容 hash，用于增量更新）
- 基础统计信息（文件数、代码行数等）

> ⚠️ 重要：scan.py 的 --output 参数接收目录路径（如 outputs），而非文件路径。传入文件路径（如 outputs/fingerprint.json）会导致 os.makedirs 将其创建为同名目录，后续写入文件时报 PermissionError。始终传入 --output outputs。

备选方案（fallback）：当 scan.py 无法运行（如 Python 环境缺失、编码兼容性问题）时，使用 AI 内置文件搜索能力完成等效扫描：
- 使用 search_file 工具扫描 **/*.vue、**/*.html、**/*.js、**/*.ts 文件
- 使用 list_dir 工具生成目录结构树
- 逐文件读取内容计算 MD5 hash 生成指纹（使用 crypto.createHash('md5')）
- 统计文件数和代码行数

> 指纹时序说明：首次运行时，在步骤2生成指纹并暂存；二次运行时，先检查 outputs/fingerprint.json 是否存在，存在则读取旧指纹对比差异。指纹文件的最终写入在步骤9（交付）完成，覆盖旧指纹。这样确保：首次运行步骤2可判断为全量模式；二次运行步骤2可判断为增量模式；交付后指纹更新为最新基线。

> 🔧 二次更新指纹兼容处理：在读取旧指纹前，必须先检查 outputs/fingerprint.json 是文件还是目录。若为目录（由上次 scan.py --output 参数错误导致），执行以下自修复流程：
> 1. 检查是否存在 outputs/fingerprint_v2.json 等备份指纹文件，如有则读取作为旧指纹
> 2. 尝试用 rmdir / Remove-Item 删除该目录；若删除失败（Windows 下可能因权限问题失败），忽略错误
> 3. 以全量模式运行本次扫描（不依赖旧指纹的增量对比）
> 4. 在步骤9交付时，使用新文件名（如 fingerprint.json）写入，确保不与旧目录冲突

步骤3：代码解析（L1+L2+L3 默认，L4 可选增强）

逐文件读取代码内容，按以下层级提取信息：

L1 结构层（必须）：
- 路由配置（router.js / router.ts 中的路由表）
- 页面层级关系（父页面 → 子页面 → 弹窗/抽屉）
- 组件树（import 关系、组件嵌套）

L2 交互层（必须）：
- 事件绑定（@click / @submit / @change 等）
- 条件渲染（v-if / v-show / v-else）
- 表单校验规则（rules 对象、required / pattern / validator）
- 弹窗/抽屉触发条件（dialog visible 控制变量）
- 导航跳转（router.push / router.replace）
- 加载状态（v-loading / loading 变量）

功能点粒度原则（按钮/操作级别拆分）：
> 功能点必须以用户可感知的独立操作/按钮为最小粒度拆分，而非按页面整体功能聚合。

• 每个独立的按钮点击操作（如「新增」「编辑」「删除」「搜索」「导出」「审核通过」等）应拆分为独立功能点
• 弹窗/对话框中的每个表单提交操作应拆分为独立功能点
• 列表操作列的每个操作按钮（编辑/删除/详情/启用禁用等）应拆分为独立功能点
• 同一页面上的「查询列表」「新增数据」「编辑数据」「删除数据」应分别作为独立功能点，而非合并为一个「数据管理」
• 功能点之间的前后依赖关系（如必须先新增数据才能编辑）在 relatedFunctions 字段中标注，并在「需求规则」中说明

字段说明增强原则：
> 参照《需求字段规则标配识别点》中定义的字段需求规则体系，对每个字段进行完整维度的描述。

字段说明必须覆盖以下维度（按字段类型选择适用维度）：

L3 数据层（必须）：
- API 调用（axios / fetch 请求，提取 URL、方法、参数）
- Store 状态（Vuex/Pinia 的 state / getters / actions）
- 计算属性（computed，推断业务规则）
- 字段映射（data 中的字段定义、props、表单 v-model 绑定）
- Mock 数据实体解析（纯前端原型场景，src/mock/ 或内联 mock 数据）：
- 提取 mock 数据中的实体对象结构（字段名、类型、示例值）
- 识别实体间的引用关系（如 trackId 指向赛道实体）
- 从 mock 数据推断数据字典（如状态枚举值、等级列表）
- 当工程无真实 API 调用时，基于 mock 数据结构推断 API 请求/响应格式

L4 框架层（可选增强）：
- UI库组件识别（Element Plus / Ant Design / Vant 等组件语义映射）
- 自定义指令语义
- Mixin / Composable 复用逻辑

用户未明确要求时不启用 L4。当原型工程大量使用 UI 库组件且组件语义对功能推断有重要价值时，主动建议用户启用 L4。

UI交互模式识别（不依赖具体UI库版本，始终执行）：

form + 表单项 → 数据录入 → 映射到「字段说明」
table + 列定义 → 列表展示 → 映射到「数据需求说明」
dialog/modal → 弹窗交互 → 映射到「备选事件流」
loading 状态 → 异步加载 → 映射到「异常事件流」
tab/step → 流程步骤 → 映射到「核心业务流程」

步骤4：PM评审

以专业产品经理视角，对提取的结构化信息做评审分析：

1. 功能点识别：将代码中的交互逻辑按按钮/操作级别拆分为独立功能点
   - 每个 @click 事件绑定的按钮/操作 → 对应一个独立功能点
   - 弹窗/对话框中的每个表单提交 → 对应一个独立功能点
   - 列表操作列的每个操作按钮（编辑/删除/详情/启用禁用等）→ 各自独立功能点
   - 拆分后标注功能点之间的关联关系（relatedFunctions）：
   • before：前置依赖（如编辑操作依赖数据已存在）
   • after：后续影响（如新增操作会影响列表查询结果）
2. 隐含决策推断：识别代码中隐含的产品决策
   - 例：提交后自动跳转 = 暗示无需二次确认
   - 例：列表默认按时间倒序 = 暗示最新数据优先
   - 例：删除操作无二次确认弹窗 = 暗示低风险操作或需补充确认
3. 矛盾与缺失检测：识别逻辑矛盾或缺失环节
   - 例：A页面表单必填字段在B页面未校验
   - 例：错误处理只有 toast 提示无具体恢复路径
4. 跨页面交叉校验（提前执行，补充到确认清单中）：
   - 同一字段在不同页面的校验规则是否一致
   - 状态变更操作的确认弹窗策略是否统一（如：删除有确认 vs 启用无确认）
   - 同一数据实体在不同页面的字段来源是否一致（如：岗位数据来自预设字典 vs 用户数据提取）
   - 关联功能点的数据流是否闭环（如：任务配置积分 → 审核结算积分 是否联动）
   - 将交叉校验发现的问题作为独立条目加入确认清单的「存疑项」章节
5. 置信度评估：对每个功能点的推断可靠性做三级评估
   - 🟢 高：代码逻辑明确，无歧义
   - 🟡 中：可推断但存在其他合理解释
   - 🔴 低：依赖推测，需用户确认

步骤5：生成需求确认清单

参考 references/checklist-template.md 模板，生成确认清单。清单以功能点为粒度，每个功能点包含：

将确认清单保存到 outputs/confirmation-checklist.md，展示给用户等待确认。

确认反馈闭环机制：

生成确认清单后，必须严格执行以下闭环：

1. 展示确认清单：以清晰格式展示给用户，特别标注：
   - 🔴 低置信度功能点（需重点关注）
   - 跨页面交叉校验发现的存疑项
2. 等待用户逐条确认：用户需对每个功能点标注状态（✅已确认 / 🔄需修改 / ❌不属此功能 / ➕遗漏补充）
3. 确认状态追踪：
   - 只有当所有功能点状态为「已确认」时，PRD 文档头部标注 确认状态：全部N个功能点已确认 ✅
   - 如果存在未确认功能点，PRD 文档头部必须标注 确认状态：X个已确认 / Y个待确认 / Z个需修改 ⚠️
   - 未确认的功能点在 PRD 中必须用 ⚠️ 待确认 标记，并在功能说明中保留原始的 PRD建议 内容
4. 禁止假确认：如果用户未逐条确认而是直接说"继续"或"开始生成"，不得将所有功能点标记为已确认。此时应：
   - 将置信度 🟢 的功能点标记为「已确认」
   - 将置信度 🟡/🔴 的功能点标记为「待确认」
   - 在 PRD 文档头部如实标注确认状态
   - 提醒用户在后续任何阶段仍可逐条确认

阶段2：结构化PRD生成

步骤6：生成PRD文档

用户确认清单后，参考 references/prd-template.md 模板，生成完整PRD文档。PRD结构如下：

📋 需求说明文档
├── 1. 文档背景
│   ├── 项目背景
│   ├── 文档目的
│   └── 适用范围
├── 2. 目标用户
│   ├── 用户角色定义
│   └── 使用场景
├── 3. 核心业务流程
│   ├── 流程概述
│   └── 主流程步骤描述
├── 4. 功能清单
│   ├── 功能模块树
│   ├── 优先级
│   └── 关联页面
├── 5. 功能说明（按功能点展开）
│   └── 5.x 功能名称
│       ├── 基本事件流（主流程 1→2→3...）
│       ├── 备选事件流（分支路径）
│       ├── 异常事件流（错误处理、边界情况）
│       ├── 关联功能点（前置/后置依赖功能点）
│       ├── 需求规则（业务规则、校验规则、权限规则）
│       ├── 字段说明（字段名、中文名、类型、控件类型、必填、可编辑、数据唯一性、长度限制、输入格式、默认值、选项列表、单选/多选、可拉宽、占位提示、校验规则、校验触点、验证提示语、自动取值逻辑、隐藏字段）
│       ├── 数据需求说明（数据实体、状态流转、存储要求）
│       └── 代码溯源（对应代码文件路径 + 关键行号范围）
├── 6. 接口需求
│   ├── API清单
│   ├── 请求/响应结构
│   └── 依赖关系
└── 7. 安全需求
    ├── 权限控制
    ├── 数据脱敏
    └── 输入防护

关键要求：
- 每个功能说明必须包含「代码溯源」小节，标注对应的代码文件路径和关键行号范围
- 字段说明必须覆盖 UI 中出现的所有表单字段和展示字段，按字段类型覆盖完整的规则维度（详见步骤3的「字段说明增强原则」）
- 事件流必须闭环，不存在走不通的路径
- 需求规则必须包含从代码中提取的具体校验规则值（如最大长度50、手机号正则等）
- 字段联动关系：在 prd-data.json 中，对于存在跨功能点关联的字段，增加 relatedFields 属性标注联动关系：
- 例：F-023 任务的 points 字段 → relatedFields: ["F-031.settledPoints"]（审核结算时读取任务配置积分）
- 例：F-008 的岗位数据 → relatedFields: ["F-014.positions", "F-018.positions", "F-026.positions"]（多处使用岗位字段，标注数据来源一致性）
- 在 prd.md 的字段说明表格中，对有联动关系的字段增加「关联字段」列
- 功能点关联关系：在 prd-data.json 中，每个功能点增加 relatedFunctions 数组标注前后依赖：
- 格式：[{ "id": "F-xxx", "name": "功能名", "relation": "before|after", "note": "说明" }]
- 在 prd.md 的功能说明中增加「关联功能点」小节
- 路由映射数据：在 prd-data.json 顶层增加 routeMappings 对象，供 RequirementViewer.vue 从数据中读取而非硬编码路由映射：
- routeToPageId：精确路由到页面ID的映射，如 {"/dashboard": "P-001"}
- hiddenRoutePrefixMap：隐藏路由（带参数详情页）的前缀匹配，如 [{ "prefix": "/practice-scenes/", "pageId": "P-009" }]
- menuTree：菜单树结构（与 MainLayout 侧边栏一级分组对齐），包含 label/icon/pageIds/childMappings

输出双格式文件：
- outputs/prd.md — 人读版 Markdown 文档
- outputs/prd-data.json — 机器消费版结构化 JSON（供交互视图和其他AI工具使用）

步骤7：一致性校验

PRD 生成后自动执行一致性校验：

AI 手动校验（主方案）：

对 PRD 与代码执行以下四维校验：

1. 字段覆盖校验：代码中出现的表单字段是否都在字段说明中有对应条目
2. 事件流闭环校验：每个事件流的终点是否有明确的结果状态（成功/失败/中止）
3. 功能点间一致性：
   - 同一字段在不同功能点的规则是否矛盾（如A处必填、B处可空）
   - 同一操作的异常处理方式是否一致
   - 字段联动关系是否完整（对照步骤6的 relatedFields）
4. API覆盖校验：代码中调用的API是否都在接口需求中有对应说明

自动化校验（可选增强）：

当环境支持 Python 时，可运行 scripts/validate.py 进行量化校验：
- 输入：outputs/prd-data.json + 步骤3收集的代码字段/Action清单
- 输出：覆盖率报告（字段覆盖率%、API覆盖率%、事件流闭环率%）
- 自动检测可量化的问题（如字段缺失、API遗漏、事件流断点）
- 注意：validate.py 为可选脚本，如未实现则跳过，不影响主流程

校验报告分级：

生成 outputs/review-items.md 时，对问题按严重程度分级：
- 🔴 高：阻断性问题（如积分结算硬编码、数据流断裂），必须处理
- 🟡 中：一致性问题（如确认弹窗不统一），建议处理
- 🟢 低：信息补充项（如数据来源说明缺失），可后续处理
- ℹ️ 信息：无问题的发现记录（如"原型为纯Mock数据"）

校验无问题时跳过 review-items.md 的生成。有高优先级问题时，建议用户先处理再进入步骤8。

步骤8：生成交互视图组件

主方案：运行 scripts/generate_viewer.py，基于 outputs/prd-data.json 生成基础骨架。

> ⚠️ 重要：generate_viewer.py 生成的是基础骨架版本，包含完整的模板结构、flexbox 面板布局、可拖拽调整宽度、路由联动、菜单树、增强字段卡片等核心特性。脚本会从 prd-data.json 的 routeMappings 字段读取菜单树和路由映射数据，避免在 Vue 组件中硬编码。生成后 AI 需检查并根据实际工程情况微调（如菜单分组标签、图标等）。

备选方案（fallback）：当脚本无法运行时，手动生成以下5个文件。

生成前强制环境检测（无论主方案还是备选方案，都必须执行）：

1. 读取工程 package.json，确认以下信息：
   - Vue 版本（vue: "^2.x" 或 "^3.x"）
   - 路由库（vue-router: "^3.x" = Vue2 / "^4.x" = Vue3）
   - UI 库（Element Plus / Ant Design / Vant / Naive UI 等）
   - 构建工具（Vite / Webpack / Vue CLI）
2. 读取路由配置文件（src/router/index.js），确认：
   - 路由模式（createWebHashHistory = hash / createWebHistory = history）
   - 路由表结构
3. 版本适配规则：
   - Vue 3：生成 <script setup> + Composition API 组件
   - Vue 2：生成 Options API（export default { data(), methods: {} }）组件
   - 路由模式需与工程一致（hash 模式下路由注入使用 /#/path 格式）

生成 outputs/requirement-viewer/ 目录，包含：

1. RequirementViewer.vue — 需求查看主组件，根据检测到的 Vue 版本生成对应语法，路由映射从 prd-data.json 的 routeMappings 读取（避免硬编码）
2. requirement-data.js — PRD 结构化数据（从 JSON 转为 JS 模块导出）
3. router-inject.js — 路由注入脚本，根据检测到的路由模式适配
4. install.sh — 一键集成脚本（Unix/Linux/macOS）
5. install.ps1 — 一键集成脚本（Windows PowerShell）

> 🔧 二次更新时 Vue 模板语法验证（强制）：无论是首次生成还是二次更新，在 RequirementViewer.vue 写入/修改后，必须执行以下验证步骤：
>
> 1. 模板插值语法检查：搜索 <template> 区域内的插值表达式，确保所有动态绑定使用 {{ }} 双花括号，而非 { } 单花括号。单花括号在 Vue 模板中不会被解析，会导致内容显示为纯文本。
> - ✅ 正确：<span>{{ page.name }}</span>
> - ❌ 错误：<span>{ page.name }</span>
> 2. 事件监听回调语法检查：搜索 onBeforeUnmount / onMounted / watch 等 Composition API 回调，确保花括号配对正确：
> - ✅ 正确：onBeforeUnmount(() => { ... })
> - ❌ 错误：onBeforeUnmount(() => {{ ... }})（多了花括号导致 JS 语法错误）
> 3. v-for/v-if 表达式语法检查：确认 v-for="item in list" 中的变量名合法，v-if 条件表达式完整
> 4. import 路径检查：确认 from "./requirement-data.js" 等相对路径正确指向同级文件
> 5. 执行验证：使用 search_content 工具在生成的 .vue 文件中搜索以下模式，若命中则必须修复：
> - 模式 \{ [a-zA-Z_]（模板中的单花括号插值）→ 改为 {{ ... }}
> - 模式 => \{\{（回调中多余花括号）→ 改为 => {

对照查阅交互设计：

核心设计原则：需求面板菜单树与原型工程侧边栏一级菜单分组对齐，路由联动自动定位。

1. 菜单树对齐：
   - 读取原型工程 MainLayout.vue 中的 menuGroups 结构
   - 需求面板左侧导航的一级分组（统计分析/场景任务管理/积分与等级/系统管理）与原型侧边栏完全一致
   - 一级分组下按页面展示，可展开查看功能点

2. 路由联动：
   - 通过 useRoute() 监听原型工程当前路由变化
   - 自动展开对应的一级菜单分组、定位到对应页面、选中第一个功能点
   - 面板顶部显示当前路由标签（如「当前：赛道管理」）

3. 隐藏页面展示：
   - 原型侧边栏只展示主路由页面
   - 需求面板的菜单树中，隐藏路由（如 /practice-scenes/:id、/reviews/:id）作为父页面的子页面展示
   - 当用户导航到隐藏路由时，需求面板自动展开父页面并显示详情页的功能点

4. 可拖拽调整宽度：
   - 侧边栏与内容区之间提供拖拽手柄（resize handle），鼠标悬停变色
   - 支持左右拖拽调整两侧宽度，侧边栏范围 200-500px，内容区自适应
   - 拖拽时 body 显示 col-resize 光标

5. 功能点展示：
   - 点击页面标题展开/折叠功能点列表
   - 每个功能点显示置信度标记（🟢🟡🔴）和优先级（P0/P1/P2）
   - 选中功能点后在右侧内容区展示完整需求说明
   - 展示功能点之间的前后关联关系（⬅前置/➡后置）

6. 增强字段说明：
   - 字段以卡片形式展示，按字段类型展示对应的完整规则维度
   - 输入框：控件类型、长度限制、输入格式
   - 下拉框：可选值列表、单选/多选标识
   - 文本域：字数限制、可拉宽标识
   - 通用：必填、可编辑及条件、数据唯一性、默认值、占位提示、校验规则、校验触点、验证提示语、自动取值逻辑、隐藏字段

7. 搜索：支持按功能点名称/描述模糊搜索

集成步骤：
1. 将 requirement-viewer/ 目录复制到工程 src/ 下
2. 在 App.vue 中引入 <RequirementViewer /> 全局组件（作为 <router-view /> 的兄弟节点）
3. 组件通过 useRoute() 自动获取当前路由，无需额外注入

步骤9：交付

交付前自动检查：

在向用户交付前，必须逐项确认以下检查项（全部通过后才可交付）：

向用户交付以下产物：

outputs/
├── confirmation-checklist.md    # 需求确认清单（阶段1产物）
├── prd.md                       # PRD文档（Markdown版）
├── prd-data.json                # PRD数据（结构化JSON版）
├── fingerprint.json             # 代码指纹（用于增量更新）
├── review-items.md              # 校验补充项（如有）
└── requirement-viewer/          # 交互视图组件
    ├── RequirementViewer.vue
    ├── requirement-data.js
    ├── router-inject.js
    ├── install.sh                # Unix/Linux/macOS 集成脚本
    └── install.ps1               # Windows PowerShell 集成脚本

交付摘要（向用户报告）：

增量更新

当用户对同一工程再次运行本技能时：

二次更新前置检查（必须先执行）

1. 指纹文件状态检查：
   - 检查 outputs/fingerprint.json 是文件还是目录
   - 若为目录（上次 scan.py --output 参数错误导致），执行以下恢复：
   • 搜索 outputs/fingerprint_v2.json、outputs/fingerprint_backup.json 等备份指纹
   • 尝试删除锁定的 fingerprint.json 目录（rmdir /s /q 或 Remove-Item -Recurse -Force）
   • 若删除失败（Windows 权限问题），跳过删除，以全量模式运行
2. outputs 目录完整性检查：
   - 确认 outputs/prd-data.json 存在且能通过 JSON.parse() 解析
   - 若 prd-data.json 损坏或缺失，标记为全量模式（从头生成）
3. requirement-viewer 组件状态检查：
   - 检查 src/requirement-viewer/ 或 outputs/requirement-viewer/ 中的 .vue 文件是否存在
   - 若存在，在生成新版本前先备份到 requirement-viewer.backup/

增量更新流程

1. 在步骤2中，检查 outputs/fingerprint.json 是否存在且为文件（非目录）
2. 存在且为文件 → 读取旧指纹，进入增量模式；不存在/为目录/损坏 → 全量模式
3. 增量模式：
   - 重新扫描计算新指纹（暂存内存，不立即覆盖文件）
   - 对比新旧指纹，识别变更/新增/删除的文件
   - 只重新解析变更文件，未变更的功能点保留原有PRD内容
   - 输出变更影响报告，标注受影响的PRD章节
   - 用户确认影响范围后，增量更新PRD文档和JSON数据
   - 更新交互视图组件：
   • 仅数据变更（功能点增减/修改，页面结构未变）：只更新 requirement-data.js
   • 页面结构变更（新增/删除页面、路由变更、菜单分组调整）：重新生成全部4个文件（RequirementViewer.vue、requirement-data.js、router-inject.js、install.sh）
   • 判断依据：对比新旧 prd-data.json 的 pages 数组，若 id/route/parentPage/children 有变化，视为结构变更
   • Vue 模板语法自动修复：在更新 RequirementViewer.vue 后，强制执行步骤8中的「Vue 模板语法验证」5项检查。若 generate_viewer.py 脚本重新运行，检查其输出的 .vue 文件模板插值是否正确（脚本的 f-string 中 {{ 转义为 { 的规则有时会产生意外输出）
   • 在步骤9交付时，用新指纹覆盖 outputs/fingerprint.json（更新基线）。写入前确认 fingerprint.json 不是目录（若是，先删除目录再写入文件）
4. 全量模式：按首次流程完整执行所有步骤
5. 无论哪种模式，指纹文件都在步骤9最终写入，确保中间步骤失败不会污染指纹基线

二次更新回退保护

若二次更新过程中遇到不可恢复的错误（如生成的文件内容异常），执行以下回退：

1. Vue 组件回退：若新生成的 RequirementViewer.vue 模板语法错误无法自动修复，回退到备份版本或重新运行 generate_viewer.py 生成干净骨架
2. PRD 数据回退：若 prd-data.json 更新后损坏，从步骤5重新生成（保留确认清单数据）
3. 指纹回退：若新指纹写入失败，保留旧指纹文件不变，下次运行时仍可正确识别为增量模式

边界与异常处理

通用异常

二次更新特有异常

使用指南

快速开始

1. 准备原型工程：确保你的原型工程包含 Vue（.vue）或 HTML（.html）文件
2. 触发技能：告诉我"解读这个原型"或"反向生成PRD"，并提供 zip 包或目录路径
3. 确认需求清单：审阅阶段1生成的需求确认清单，标注确认/修改/遗漏
4. 获取PRD：确认后自动生成结构化PRD和交互视图组件
5. 集成到工程：按 install.sh 说明将交互视图组件嵌入原型工程

推荐配套 AI 工具

本技能生成的结构化 PRD（特别是 prd-data.json）可作为下游 AI 工具的输入，用于在原型代码工程中生成可交互查看的需求说明。以下是国内外支持代码分析+需求文档生成的推荐工具：

🌍 国际工具

🇨🇳 国内工具

💡 工具选择建议

典型工作流组合

流程 A：原型 → PRD → 代码补全

原型工程 → 本技能(逆向PRD) → Trae SOLO模式(按PRD补全代码) → 可运行应用

流程 B：遗留系统 → 文档化 → 重构

遗留代码库 → 本技能(逆向PRD) → Codex $recipe-review(合规校验) → Codex $recipe-build(重构实施)

流程 C：设计稿 → 原型 → PRD → 企业交付

Figma设计稿 → CodeBuddy(生成原型) → 本技能(逆向PRD) → TAPD(需求入库) → 企业开发流程

输入规范

用户调用时需提供：
- 工程来源：zip 包上传 或 目录路径
- （可选）L4增强：是否启用框架层深度解析，默认关闭
- （可选）输出目录：默认为 outputs/

输出规范

详见步骤9的交付产物清单。所有输出文件使用 UTF-8 编码，Markdown 文件使用标准 GitHub Flavored Markdown 格式。