code-to-prd

name	code-to-prd
description	Use when 需要分析 Egret/EUI 模板或页面代码、布局皮肤、资源文件，输出以原模板功能描述为主、支持“场景独立还原”和“场景内独立功能拆分还原”的 PRD/逻辑分析文档。适用于分析模板交互逻辑、题目数据影响、组件层级与状态机、定位源文件/皮肤/图集路径、检查现有 PRD 是否足以驱动生成、多场景按场景拆分，以及按需载入文档整理。

代码转 PRD 技能

将现有页面代码、布局文件、组件、皮肤和资源事实转化为结构化、可复用的分析文档。

规则

• PRD 主体以描述原模板功能为首要目标，所有拆分和目录设计都应服务于“更稳定地还原模板功能”，而不是把文档机械切碎。
• 场景是默认的最小还原单元：每个 page-scene 都应能脱离整份 PRD 被单独理解和实现；若某个场景内部还包含相对独立、可单独实现的功能块，应继续在该场景下拆出功能单元，使实现者无需通读整个模板也能复刻该部分。
• 严格基于代码与资源事实输出，不得臆造功能；不确定的内容标记为 Assumption，无法充分证明的部分直接指出缺口。PRD 必须显式输出模板相关文件、直接使用到的资源路径及其作用；默认只列实际使用到的标准 1x 资源路径。若项目没有独立常量文件，要说明布局常量分散在哪些 controller / component 中。
• 保持简洁，但不能牺牲可实施性：优先写实现事实，不只写概述；每条关键需求都应能翻译为结构、状态和行为要求，并消除数据、组件、状态切换、动画阻塞和外部系统范围上的实现歧义。
• serialize/unserialize 属于多人课堂实时同步框架机制，不纳入单页面交互 PRD；原始框架坐标只用于推断相对布局关系，不得直接写入 HTML 定位；所有模板都必须显式区分 page-scene、overlay-scene、substate，并判断场景内部是否还存在可独立还原的功能单元。
• feature 只用于单一宿主场景内的功能单元；若某项能力跨多个场景复用，或脱离宿主场景后仍可独立复用，应提升到 PRD/shared/，场景中只保留使用点、依赖时序和输入输出。
• 若用户目标是“让 PRD 驱动新系统生成模板”，必须继续补齐 scenes.md、必要的生成附录与共享能力文档；若是在审查现有 PRD 的生成充分性，应优先从 index.md 和现有子文件建立判断，只在缺少证据时最小回源到源码。
• index.md 必须写清入口身份、读取顺序、文件职责和跳过风险；PRD 超过 300 行或用户要求"按需载入"时，应按 references/output-format.md 中定义的多文件格式输出。多文件模式下，index.md 负责入口与阅读顺序，files.md 负责证据与定位，scenes.md 负责场景导航与主链，不得在三者之间重复铺写同一批摘要正文。若某个场景被继续拆成功能单元，还必须写清宿主场景、触发条件、依赖状态、输出结果和状态回流。

目标

• 输出结果应优先回答“旧模板实际上如何工作”，并支撑模板功能还原、页面重建、逻辑复刻或后续重构。
• 输出结果至少应支持两种还原粒度：场景级独立还原；场景内部相对独立功能的拆分还原。
• 如果源码事实与现有 PRD、口头描述或命名直觉冲突，以源码事实为准。

---

Workflow

1. 整理证据范围

• 列出本次分析实际使用到的文件，并按逻辑、布局、组件、皮肤/样式、资源清单分类。
• 区分模板本地事实与公共框架行为；凡不能由模板本地代码直接证明的部分，标记为 Assumption。
• 若是 Egret/EUI 教学模版，还应补齐模板 key、代码目录、皮肤目录、入口文件、template.json 与资源清单定位。

模板文件快速定位规则

• 先根据模板 key 锚定 tools/template.json、代码目录、皮肤目录、主题映射、资源清单与图集来源，不得直接猜目录。
• 对组件与皮肤绑定、图集引用、布局常量等信息，按需补查对应文件并回写到 PRD。
• 详细定位规则见 references/file-location.md。

2. 分析 UI 布局与视觉资源

• 识别页面主分区、组件层级、页级容器与可复用组件。
• 归纳布局方式和区块相对关系；坐标、尺寸、锚点、缩放只作为相对布局证据，不得直接转写为 HTML 绝对定位事实。Egret / EUI 这类非 DOM 布局要翻译为 HTML 可理解的结构分区。
• 梳理组件到图片、动画、音频、皮肤、纹理集、字体等资源的映射，区分核心必需与辅助展示，并说明框架专有命名或资源组织方式与页面结构的对应关系。

3. 分析功能、交互与状态

• 基于代码归纳业务逻辑，不得假设代码中未出现的功能；优先说明原模板如何成立，包括页面目标、主玩法、关键分支、状态流转、外部依赖和用户可感知反馈。
• 梳理所有用户交互与动态行为，明确事件链路：触发条件 -> 处理器/控制器 -> 状态变化 -> UI 更新，并覆盖条件渲染、事件派发、资源切换和外部系统调用。
• 列出关键状态、迁移条件、约束关系、对应 UI 表现，以及动画时长、输入禁用窗口、视觉反馈和可点击状态。
• 对每个 page-scene，进一步判断是否存在“相对独立功能单元”：若某部分拥有较清晰的触发入口、内部状态、输入输出、完成/退出条件，并可在宿主场景内单独实现或替换，就应单独建模，而不是只混写在场景总述里。
• 对弹窗、结束窗口、设置窗口、奖励面板等结构，先判断它是 overlay-scene，还是宿主场景内部的功能单元；前者单列 overlay，后者放入场景下的功能目录，并写清二者边界。
• 如果是教学/答题模版，重点说明单题/分页/多轮结构、判题时机与 retry / reveal / reset / result 分支；序列化机制属于框架层多人同步，不分析。

4. 提取数据契约

• 识别页面渲染所需的最小数据结构，并列出各渲染对象的必填字段。
• 提取派生规则，例如排序、分页、过滤、资源选择、默认值策略，以及数量限制和字段取值带来的逻辑/界面分支；这些分支统一写入“题目数据影响说明”章节。
• 若页面接入外部系统，记录触发时机、最小 payload、必要字段与可选字段，并明确哪些字段缺失会导致页面无法正确运行。

5. 评估 PRD 是否足以驱动生成

当目标是“把 PRD 交给新系统生成模板”时，只检查 4 件事：

• 若用户已提供现有 PRD 并要求审查生成充分性，先读取 index.md 和相关子文件，再只对争议点最小回源到源码；不要重新做全量模板扫描。
• index.md 是否已被定义为唯一入口，并写清读取顺序、文件职责和跳过风险。
• 场景、功能单元与共享能力是否齐全：多场景模板要有 scenes.md 并区分 page-scene、overlay-scene、substate；若场景内部存在相对独立功能块，应继续拆成该场景下的功能单元；公共能力要抽到 PRD/shared/<能力名>/，模板层只保留使用点、时序和依赖关系。
• scenes.md 是否只承担导航与主链，而没有与 scene-<sceneId>/index.md、ui.md、interaction.md、data.md 重复写正文；files.md 是否承担了证据与定位，而不是让这部分散落回 index.md。
• 高优先级待确认项是否已明确分流为人工校验或生成附录；若目标是直接投喂生成系统，还需最小生成附录，写清默认策略、禁止误猜项与完成判定。

若上述任一项缺失，不能只回答“PRD 基本够用”，而要直接补文件或补规则。

6. 生成输出

• 按结构化 PRD 顺序用中文输出，先把原模板功能讲清楚，再组织实现映射、生成约束和拆分结构；详细章节模板见 references/output-format.md。
• 拆分优先级固定为：模板总层 -> 场景层 -> 场景内功能层 -> overlay / shared。不要因为某块内容较长，就跳过场景边界直接按“UI / 交互 / 数据”平铺全模板拆分。
• 输出时要保持文件边界稳定：模板入口看 index.md，证据与定位看 files.md，场景导航与主链看 scenes.md，场景正文看 scene-<sceneId>/，单宿主功能看 features/，跨场景复用能力看 PRD/shared/。
• 根据任务侧重点补强：逻辑分析侧重业务规则、事件链和状态迁移；页面重建侧重结构映射与实现约束。
• 必须先按“模板文件快速定位规则”完成查找，再把实际定位结果、关联资源和来源依据写入 PRD。
• 若输出目标包含“交给新系统生成模板”，还应补齐 scenes.md 和必要的生成附录，并与事实 PRD 分开。