產品 PRD 原型是做什麼的？

使用此手動工作流程，將產品意圖、運行的 UI 證據、原型狀態、註釋螢幕截圖、原始碼地標以及 AI 可實作的 PRD 連接起來。

除非使用者明確要求實作，否則請勿修改使用者的應用程式原始碼。在隔離的工作區資料夾中建立原型工件，並將最終交付項目儲存在 outputs/ 下。

首先要求選擇交付模式

將交付模式的選擇視為阻塞性的第一個關卡。在進行頁面探索、原始碼閱讀、產品提問、原型工作或 PRD 工作之前：

偵測使用者是否已明確選擇以下模式之一；
如果沒有，呈現模式選項並等待使用者選擇；
不要無聲地選擇預設值，並且在模式確認之前不要繼續工作流程；
將確認的模式記錄在 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 中，而不是要求每個細節都適合螢幕截圖。

誠實地使用驗證狀態

對每個相關狀態的證據進行分類：

已驗證 (Verified)：針對運行的目標進行了演練，並在目標視埠進行了比較；
從原始碼衍生 (Source-derived)：從程式碼、樣式和資源衍生，但未經執行時期比較；
從螢幕截圖衍生 (Screenshot-derived)：從提供的螢幕截圖重建；行為來自程式碼或產品決策；
僅概念 (Concept-only)：在沒有足夠的執行時期、螢幕截圖或原始碼證據的情況下提出。

僅當一個現有狀態是已驗證且通過保真度閘道時，才稱其為 1:1。缺少執行時期不會阻止草稿或工作中的 PRD，但它會在每種模式下阻止最終交付，並且輸出必須攜帶正確的狀態。

上下文預算模式

當儲存庫很大、目標檔案超過 800 行，或頁面有許多元件/互動時，閱讀 references/large-project-mode.md 並遵循其分層探索工作流程。從路由、元數據和 rg 開始；在確認目標之前，不要加載大型檔案。

工作流程

1. 通過模式關卡

在採取任何探索或生產行動之前確認交付模式。如果模式不明確，請詢問並等待。如果使用者沒有定義的需求，建議使用「原始頁面互動原型」，但不要自動選擇它。

確認後，使用 references/product-design-integration.md 選擇並記錄可選的增強路由。在此之前不要檢查目標頁面。

2. 定位並確認目標頁面

接受頁面標題、業務描述、螢幕截圖、瀏覽器狀態、URL、路由、mini-program 路徑或檔案路徑。在詢問使用者之前，先搜尋路由清單、頁面註冊表、標題、可見文字和可能的檔案名。

當仍然有幾個候選項時，顯示一個簡潔的候選卡片，包含路徑、匹配證據和建議。如果有一個候選項壓倒性地正確，將其命名為工作目標並繼續進行，除非被糾正。

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。

使用此優先級：

明確的產品偏好；
當前專案 UI 風格；
當專案風格不是必需或不可用時，一個適合業務的現代方向。

如果風格未知，詢問是否遵循當前專案。如果使用者沒有回答，則預設為專案風格並記錄此假設。

6. 建立原型

在複製現有運行頁面之前，閱讀 `references/pixel-pe

…

[為翻譯而截斷]

產品 PRD 原型