产品PRD原型制作

产品 PRD 原型

使用此手动工作流来连接产品意图、运行中的 UI 证据、原型状态、带标注的截图、源代码关键位置以及一份可被 AI 实施的 PRD。

除非用户明确要求实现，否则不要修改用户的应用程序源代码。在隔离的工作区文件夹中构建原型产物，并将最终交付物保存在 outputs/ 下。

首先要求选择交付模式

将交付模式的选择视为一个阻塞性的首要关卡。在进行页面发现、源码阅读、产品问题、原型制作或 PRD 工作之前：

1. 检测用户是否已明确选择了以下模式之一；
2. 如果没有，则展示模式选项并等待用户做出选择；
3. 不要静默地选择默认值，也不要在模式确认之前继续进行工作流；
4. 将确认的模式记录在 page-map.md、manifest.md 以及任何 PRD 或审计报告中。

使用以下选择提示：

开始前请选择本次交付模式：

A. 原页面交互原型
适合还没有明确新增/修改需求时；先高保真复刻当前页面及边界内的原有交互，不设计新需求。

B. 局部需求原型
适合已经有明确需求；高保真还原完整页面 UI，只完整设计和验证本次新增/修改流程。

C. 全量高保真原型
适合需要原页面及需求相关交互全部按定义边界完整复刻和验证。

D. 仅输出 PRD
完成页面分析、需求规则、连线标注图和 AI 可实施文档，不制作可点击原型。

E. 保真度审计
检查现有实现或原型与运行页面的差异，输出带连线的差异标注图，不主动设计或实现。

当用户没有提供新的或更改的需求时，推荐 A. 原页面交互原型，但仍需明确确认。

路由可选的产品设计增强

在用户确认交付模式之后、页面发现之前，阅读 references/product-design-integration.md。将产品设计视为一个可选的、自动选择的增强，而不是运行时依赖。

• 仅从当前会话中暴露的技能中检测产品设计。不要检查或依赖安装路径、插件缓存或版本。
• 在评论中简要宣布一个自动选择的增强，并继续，无需在增强不改变范围或外部状态时请求确认。
• 如果适用的产品设计技能不可用、不兼容或失败，则通过原生回退继续。它的缺失不是错误，也不是降低交付门槛的理由。
• 在操作会扩大范围、发布或对外分享、修改应用程序源代码或引入重大不同的设计方向时，必须询问。除非用户明确要求该插件，否则不要安装或建议安装产品设计。
• 保持此技能在交付模式、边界、稳定ID、标注、PRD、输出契约、验证状态和最终验证方面的权威性。

原页面交互原型

• 当用户识别了一个页面但未定义新的或更改的需求时使用。
• 复刻当前页面、其可见状态以及声明的页面边界内的每个现有交互。
• 不要发明产品目标、提议的状态、更改规则或实施需求。
• 交付高保真交互基准原型、交互清单、保真度证据、带连线标注的截图、标注地图和清单。
• 在原页面原型交付后停止。仅在用户之后提供需求并选择面向需求的模式后，才开始需求设计。

局部需求原型

• 以与其他模式相同的高保真标准复刻整个目标页面 UI。
• 完整复刻并验证范围内的新的或更改的交互流程。
• 记录请求流程之外现有交互，并保留其可见控件；模拟或记录其边界，而无需克隆不相关的下游页面。
• 交付交互原型、带连线标注的截图、PRD 和 AI 交接文档。

全量高保真原型

• 仅当用户明确要求完整页面复刻、所有交互或 1:1 保真度时使用。
• 复刻并验证已定义的页面边界内的每个现有交互。
• 交付与局部需求原型相同的产物，并附带全面覆盖的证据。

仅输出 PRD

• 定位并理解页面，定义更改，并编写一份决策完整的 PRD。
• 除非需要解决歧义，否则不要构建可点击原型。
• 仍然交付高保真带标注的截图，并带有指向 PRD 使用的每个需求位置或结果状态的可见连接线。

保真度审计

• 将现有实现或原型与运行中的页面进行比较。
• 报告证据、差异、交互覆盖率、确切阻塞点以及高保真带连线标注的对比截图；除非被要求，否则不要重新设计或实现。

应用通用视觉交付门槛

将这些门槛应用于每个模式。交付模式改变交互覆盖范围和文档范围；它永远不会降低 UI 保真度或标注质量。

高保真 UI 是强制性的

• 使用指定目标视口下的运行页面作为现有 UI 的视觉真相来源。
• 匹配所选模式需要的所有可见页面几何形状、排版、颜色、资源、间距、边框、圆角、叠加层、固定区域、滚动和内容换行。
• 在“原页面交互原型”、“局部需求原型”和“全量高保真原型”模式下，复刻整个目标页面 UI；不要将原型裁剪到仅包含更改的组件。
• 在“仅输出 PRD”模式下，即使不需要可点击原型，也要使用运行页面或经过验证的高保真复刻作为带标注的需求截图的基础。
• 在“保真度审计”模式下，使用相同视口的运行页面和实现证据；不要用近似的重绘替代证据。
• 将未标注的参考和差异截图保存在 work/<slug>/evidence/ 下；它们是验证证据，而不是最终的交接截图。
• 当现有页面基线仅为“源自代码”、“源自截图”或“仅概念”时，不要将交付物标记为最终版本。报告“高保真验证受阻”并请求缺失的运行时、数据、字体、资源或平台先决条件。

连线标注是强制性的

• 在 outputs/<slug>/ 下交付的每个最终截图必须包含标注卡片以及连接到确切 UI 触发器、更改区域、结果状态或审计差异的可见连接线。
• 没有可见连接线的分离侧边列表不是带标注的截图，不得交付。
• 使用单独的、非交互式叠加层中的 SVG line、polyline 或 path。每个连接线必须以填充的或高对比度的圆形标记结束，其中包含其可见的序号。纯点、空心圆、箭头或未编号的端点均无效。
• 每个截图中的标注从 1 开始编号。数字必须是正整数、唯一且连续，没有间隙或重复。
• 将编号圆圈放在确切的 UI 目标上——而不是标注卡片旁边、连接线的中途或附近空白处。
• 在需求模式 B、C 和 D 中，目标必须是正在添加或修改的实际 UI 控件、区域或结果状态。在模式 A 中，目标是确切的现有交互触发器或结果。在模式 E 中，目标是确切的审计差异。
• 当一个标注描述多个相关目标时，在每个与该卡片关联的连接线端点处重复相同的序号，或将独立的目标拆分为单独的编号标注。
• 当覆盖层隐藏了原始触发器时，连接到可见结果或主要操作，并在标注中解释转换过程。
• 保持连接线在导出的 PNG 中可见，而不仅仅在未捕获的 DOM 层中。
• 保存 outputs/<slug>/annotation-map.json，将每个最终截图和标注 ID 映射到其序号、编号圆圈端点、目标角色以及目标坐标、选择器或命名区域。
• 不要强加强制性的标注数量、连接线数量或字符限制；通过布局、分组、连接线路由和附加截图来解决密度问题。

定义页面和交互边界

除非用户扩展，否则使用此默认边界：

• 包含目标页面及其可滚动内容、固定区域、条件状态以及直接从目标页面打开的第一层覆盖层；
• 包含范围内覆盖层内的嵌套控件；
• 对于导航到另一个业务页面，验证触发器、路由/参数和可见转换，但不要克隆目标，除非它属于请求的流程；
• 将支付、地图、媒体选择器、键盘、客服、权限和其他平台能力视为显式能力边界，当它们无法在独立原型中运行时；
• 绝不允许导航链静默地将任务扩展到复刻产品的其余部分。

将边界和任何明确包含的下游流程记录在 work/<slug>/page-map.md 中。

使用稳定的需求 ID

分配稳定的标识符，并在页面地图、原型状态 URL、标注、PRD、实施说明和验收标准中重复使用它们：

• REQ-01：产品需求或目标；
• INT-01：交互或行为；
• STATE-01A：交互的可观察状态；
• AC-01-01：可测试的验收标准。

“原页面交互原型”模式需要当前行为的 INT 和 STATE ID，但不需要编造的 REQ 或 AC ID。面向需求的模式使用所有适用的 ID 类型。

一个标注可以描述一个交互或多个相关交互。不要强加强制性的标注数量、连接线数量或字符限制。通过布局、分组、层级和在需要时添加附加状态图像来保持截图的可读性。将实现细节放在 PRD 中，而不是要求每个细节都适合截图。

诚实地使用验证状态

为每个相关状态对证据进行分类：

• 已验证：针对运行目标进行过演练，并在目标视口下进行了比较；
• 源自代码：来自代码、样式和资源，但未进行运行时比较；
• 源自截图：从提供的截图中重建；行为来自代码或产品决策；
• 仅概念：在没有足够的运行时、截图或源代码证据的情况下提出的。

仅当现有状态为已验证且通过保真度门槛时，才能称之为 1:1。缺少运行时不会妨碍草稿或工作中的 PRD，但它会阻止在所有模式下的最终交付，并且输出必须带有正确的状态。

上下文预算模式

当仓库很大、目标文件超过 800 行或页面包含许多组件/交互时，阅读 references/large-project-mode.md 并遵循其分层发现工作流。从路由、元数据和 rg 开始；在确认目标之前不要加载大文件。

工作流

1. 通过模式关卡

在采取任何发现或生产操作之前确认交付模式。如果模式不明确，询问并等待。如果用户没有定义的需求，推荐“原页面交互原型”而不要自动选择它。

确认后，使用 references/product-design-integration.md 选择并记录可选增强路径。在此点之前不要检查目标页面。

2. 定位并确认目标页面

接受页面标题、业务描述、截图、浏览器状态、URL、路由、小程序路径或文件路径。在询问用户之前搜索路由清单、页面注册表、标题、可见文本和可能的文件名。

当仍有多个候选时，显示简洁的候选卡片，其中包含路径、匹配证据和建议。如果有一个候选明显正确，则将其命名为工作目标并继续，除非被纠正。

3. 构建页面地图

阅读已确认的页面、相关样式、路由配置、导入的子组件和参与的覆盖层。记录：

• 信息架构和业务模块；
• 可见和条件元素；
• 交互清单和页面边界；
• 当前处理程序、状态字段、组件、API 和路由参数（当可见时）；
• 默认、加载、成功、失败、空、验证、权限、禁用、关闭和边界状态（如果适用）；
• 验证状态和未解决的事实。

创建：

work/<slug>/page-map.md
work/<slug>/interaction-matrix.md

将所选执行路径和增强决策记录在 page-map.md 中。将产品设计证据保留在同一声明的页面边界内。

不要将未解决的事实与提议的产品决策混淆。尽可能从运行时或源代码中解决事实；仅提出无法推导的高影响力产品问题。

4. 定义产品意图、范围和更改

在“原页面交互原型”模式下，仅描述当前行为，不要推断新需求。对于面向需求的模式，确认或推断目标、用户、场景、所需动作、所需状态和所选交付模式。区分：

• 当前行为；
• 目标行为；
• 必须保持不变的行为；
• 范围之外的行为；
• 数据/API 假设和依赖关系。

随着范围变得稳定，分配 REQ、INT、STATE 和 AC ID。对于“局部需求原型”模式，明确识别哪些交互需要完整的实现和验证。

5. 确认 UI 方向

阅读 references/ui-design-guidance.md。在每个模式下，高保真复刻完整的现有页面是强制性的。在“原页面交互原型”模式下，跳过提议的设计方向问题，并复刻当前的运行 UI，而不要重新设计它。

使用此优先级：

1. 明确的产品偏好；
2. 当前项目 UI 风格；
3. 当项目风格不是必需或不可用时，采用适合业务方向的现代风格。

如果风格未知，询问是否遵循当前项目。如果用户没有回答，则默认为项目风格并记录此假设。

6. 构建原型

在复刻现有的运行页面之前，阅读 `references/pixel-pe…

[已截断，用户原文已截断]