產品經理前端高保真原型 Skill

一、目標

在已有前端專案的原始碼基礎上，建立高保真、可點擊且與正式業務入口隔離的原型，讓產品經理能夠快速查看、演示和討論產品方案。

優先保證：

與現有專案風格一致。
頁面像真實產品，而不是臨時 Demo。
使用符合業務的模擬資料。
核心流程可以點擊。
互動可以用於需求評審。
頁面容易繼續修改。
可以立即在本地執行和預覽。
預設不影響正在使用的業務頁面和路由。

除非用戶明確要求，否則不要把任務當成從零重做整套系統。

當前目標是高保真原型時，不優先開發後端介面、生產資料鏈路或複雜架構。

預設隔離約定： 先復用現有專案的原始碼、佈局、元件和視覺規則，再在獨立的原型頁面、原型路由或功能目錄中實現。不得預設修改正在使用的業務頁面、生產入口或現有介面呼叫；只有用戶明確要求「直接在原頁面演示」或「將原型覆蓋到現有頁面」時才可以這樣做。

二、適用場景

當用戶提出以下需求時，使用本 Skill：

基於已有 React、Vue、HTML 或其他前端專案原始碼建立獨立原型頁面或路由。
用戶明確要求時，在已有產品頁面中演示原型互動。
增加後台管理頁面、CRM 頁面、SaaS 頁面、營運後台或業務工作台。
將靜態頁面改成可點擊原型。
增加真實感較強的模擬資料和互動狀態。
增加或最佳化表格、表單、篩選、Tab、抽屜、彈窗、圖表、詳情頁或業務流程。
按照現有專案風格擴展新功能。
不開發後端，先完成用於評審的高保真 Demo。
最佳化視覺層級、資訊密度、響應式或互動回饋。

常見表達：

在現有後台中增加一個客戶列表頁面。
根據當前專案風格增加一個經營資料看板。
在現有詳情頁中增加跟進記錄模組。
把這個頁面補成可以點擊的原型。
增加搜尋、篩選、狀態切換、抽屜和彈窗互動。
最佳化這個現有頁面，但不要改變整個系統風格。

三、不適用場景

以下情況不預設使用本 Skill：

用戶希望從空白目錄開始建立一個全新產品。
用戶只需要行銷官網或落地頁。
用戶要求開發後端介面、資料庫或生產服務。
用戶需要技術架構文件，而不是原型。
用戶只要求生成視覺圖片或靜態截圖。
當前任務主要是需求分析或 PRD 編寫。

如果當前目錄為空，應說明本 Skill 主要面向已有專案，並優先使用「從零生成 HTML 高保真原型 Skill」。

四、核心原則

1. 先檢查專案，再開始設計

不要收到需求後立即寫程式碼。

先查找 docs/product/ 中與當前專案、當前前端（c-end/ 或 admin/）對應的產品體驗基線。基線存在時，讀取其中的產品術語、導航、頁面模式、視覺與互動規則；它補充專案原始碼的技術約定，但不能取代元件庫、路由和資料架構。

如果用戶正在啟動首版需求，或當前功能暴露出跨頁面反覆出現但尚未定義的產品規則，建議先使用 product-experience-foundation。普通單功能原型不得擅自建立或重寫全域產品基線。

先檢查現有專案中的：

相鄰頁面。
頁面佈局框架。
路由結構。
元件目錄。
公共 Hook 和工具函數。
CSS 變數。
主題檔案。
設計 Token。
圖示使用方式。
表格樣式。
表單樣式。
彈窗和抽屜樣式。
訊息和通知樣式。
當前狀態管理方式。

需要理解現有專案的：

資訊密度。
頁面間距。
字型層級。
圓角大小。
顏色使用方式。
導航結構。
元件呼叫方式。
響應式策略。

新增內容應該像現有系統自然擴展出來的，而不是重新做一套系統。

2. 優先復用，不重新造輪子

優先復用專案已有的：

按鈕。
表格。
表單。
下拉選擇。
日期選擇器。
Tab。
彈窗。
抽屜。
分頁。
狀態標籤。
訊息提示。
頁面佈局元件。
圖示。
工具函數。
Hook。
設計 Token。

如果現有專案已經具備相應能力，不要重新建立第二套元件系統。

3. 預設隔離原型入口

原型必須基於現有原始碼實現，而不是複製出一套脫離專案的靜態網站；同時預設與正式業務入口隔離。

優先選擇專案現有約定支援的以下方式之一：

獨立原型路由，例如 /__prototype/<feature> 或專案已有的 demo 路由約定。
獨立原型頁面或功能目錄，並僅在開發/預覽環境暴露入口。
不改變原頁面預設行為的明確原型入口，例如查詢參數、開發選單或臨時導航項。

原型入口要能復用真實頁面外殼和元件，但不得預設替換線上入口、修改既有業務資料或影響其他功能。專案已有原型約定時必須優先遵循；沒有約定時，選擇對生產程式碼影響最小且易於移除的方式，並在最終回覆中說明入口位置。

4. 把任務當成產品原型，而不是正式重構

優先服務：

產品評審。
業務演示。
需求討論。
設計與研發對齊。
快速迭代。

優先使用直接、容易修改的實現方式。

除非現有專案本身已經採用相應模式，否則不要引入：

大範圍全域重構。
新的架構層。
重型依賴。
過度抽象。
複雜狀態機。

5. 使用模擬資料，不急著開發後端

除非用戶明確要求，否則不要：

接入真實介面。
設計後端 API。
建立服務層。
處理生產資料鏈路。

模擬資料盡量放在頁面或當前功能附近，方便產品經理調整。

使用本地狀態模擬：

新增。
編輯。
刪除。
搜尋。
篩選。
排序。
Tab 切換。
選擇。
狀態變化。
抽屜開啟。
彈窗開啟。
表單提交。
二次確認。
成功提示。
錯誤提示。

6. 原型必須可以點擊

除了核心主流程，還應根據需求補充產品經理評審時需要查看的狀態：

搜尋。
篩選。
Tab。
選擇。
詳情查看。
空狀態。
載入狀態。
表單校驗。
禁用狀態。
二次確認。
成功回饋。
錯誤回饋。
返回路徑。
多步驟導航。

如果需求包含多個步驟，應讓流程可以完整跳轉，而不是留下多個互不關聯的靜態頁面。

7. 不要把業務系統做成行銷官網

當用戶需要的是應用、工具、後台、CRM、營運系統或業務工作台時：

不要製作超大首屏標題。
不要優先使用行銷式視覺構圖。
不要用大量裝飾性漸變和背景作為主視覺。
不要為了視覺效果大幅降低資訊密度。
不要用行銷卡片替代真實業務控制項。

五、編碼前需要完成的分析

開始寫程式碼前，先從需求和專案中提取：

產品目標。
目標用戶或角色。
用戶需要完成的核心任務。
需要新增或修改的頁面。
現有相似頁面。
頁面入口。
主要用戶流程。
必要欄位。
必要狀態。
不同角色的權限差異。
必須實現的互動。
模擬資料需求。
產品假設。
尚未明確的業務規則。

用戶已經提供的資訊不要重複詢問。

如果只是展示層細節缺失，可以使用合理假設。

不能擅自補充會改變產品範圍的核心業務規則。

六、專案檢查流程

第一步：識別技術棧

確認：

前端框架。
建置工具。
路由方式。
UI 元件庫。
圖示庫。
樣式方案。
狀態管理方式。
資料請求約定。
測試或預覽方式。

第二步：尋找相似頁面

優先查找：

同類型列表頁。
同類型詳情頁。
同類型表單。
同類型資料看板。
同類型彈窗或抽屜。
同類型業務流程。
同類型空、載入和錯誤狀態。

以這些頁面作為新頁面的實現參考。

第三步：識別可復用內容

列出本次應復用的：

元件。
Hook。
設計 Token。
工具函數。
頁面佈局。
互動方式。

避免重複實現已有能力。

第四步：理解現有視覺系統

檢查：

頁面寬度。
內容區內邊距。
模組間距。
字型層級。
按鈕樣式。
表單密度。
表格密度。
狀態顏色。
邊框樣式。
陰影使用。
響應式斷點。

第五步：確定原型範圍

明確：

原型入口放在哪裡，以及它與正式入口如何隔離。
需要新增的原型頁面或模組。
用戶是否明確要求修改既有業務頁面。
哪些互動必須可點擊。
哪些資料使用模擬資料。
哪些狀態必須體現。
哪些產品假設是必要的。
當前功能復用了哪些產品級頁面模式。
哪些新模式僅限當前功能，哪些可作為後續晉升候選。

七、模擬資料標準

模擬資料應使用真實業務語言。

避免使用：

Test User。
Lorem ipsum。
Company A。
Sample Data。
User 001。

模擬資料應盡量覆蓋：

不同狀態。
長文本。
缺失值。
警告資訊。
邊界資料。
不同用戶決策。
不同業務階段。
空結果。
禁用操作。

模擬資料的作用不是填滿頁面，而是幫助產品經理發現頁面和互動問題。

八、產品假設規則

AI 可以合理補充展示層細節，例如：

範例姓名。
範例日期。
範例列表資料。
空狀態文案。
成功和錯誤提示。
常見篩選條件。
符合現有專案習慣的互動方式。

AI 不得默默補充以下核心業務邏輯：

新的業務狀態。
新的角色權限。
新的審批規則。
新的業務計算方式。
新的管理模組。
新的產品範圍。
新的外部系統依賴。

如果為了演示必須做出假設，應在最終回覆中集中說明。

如果新互動與產品體驗基線衝突，不得靜默覆蓋。應遵循已確認基線，或將偏離原因和「是否需要回寫基線」列為待確認項。

九、UI 與互動標準

1. 資訊架構

優先保證：

層級清晰。
分組合理。
欄位選擇有效。
主操作明顯。
資訊密度穩定。
頁面容易掃描。

2. 控制項選擇

優先使用用戶熟悉的控制項：

工具操作使用圖示按鈕。
模式切換使用分段控制。
二元設定使用開關或核取方塊。
數值設定使用輸入框、滑桿或步進器。
多選項使用選單或下拉。
同級檢視使用 Tab。
次級任務使用抽屜或彈窗。

3. 卡片使用

不要出現卡片嵌套卡片。

卡片適合用於：

重複列表項。
彈窗。
抽屜。
獨立工具。
需要明確框定的資料組。

不要把頁面每一個區塊都包成卡片。

4. 控制裝飾

避免：

裝飾性漸變光團。
漂浮圓球。
散景效果。
無意義 SVG 裝飾。
純氛圍背景。
行銷式首屏。
單一色調佔滿頁面。

實現後檢查 CSS，如果頁面幾乎只剩一種色系，應適當調整。

特別注意避免：

大面積紫色或藍紫漸變。
大面積米色或沙色。
大面積深藍或灰藍。
大面積棕色或橙色。

5. 文字與佈局穩定性

確保文字能夠適應：

按鈕。
表格儲存格。
卡片。
側邊欄。
抽屜。
彈窗。
行動端容器。

根據需要使用：

自動換行。
文字截斷。
最小和最大寬度。
穩定網格。
aspect-ratio。
容器相對尺寸。

不要根據視口寬度動態縮放字型。

除非現有設計系統要求，否則字間距保持為 0。

6. 不在產品介面裡解釋原型

不要在頁面中展示以下說明：

這個原型是如何製作的。
使用了哪些臨時方案。
評審者應該如何理解頁面。
哪些互動是模擬的。

只有產品本身確實需要幫助內容時，才在介面內增加說明。

十、響應式範圍

桌面後台系統

如果專案明顯是桌面後台：

優先將桌面端做好。
保持穩定的資訊密度。
確保小螢幕下不會完全崩壞。
避免關鍵操作不可訪問。
盡量避免不必要的橫向捲動。

行動端或消費者產品

如果產品面向消費者、行動優先，或用戶明確要求行動端：

同樣認真設計行動端佈局和互動。
檢查點擊區域大小。
檢查控制項裁切。
檢查固定定位元素。
檢查安全間距。
根據需要檢查鍵盤和表單行為。

所有頁面都需要檢查

文字重疊。
控制項裁切。
操作入口隱藏。
頁面導航斷點。
橫向溢出。
表格不可讀。
抽屜或彈窗無法使用。

十一、實現流程

第一步：讀取現有專案

檢查相關專案結構和相似頁面。

第二步：明確原型入口與範圍

整理：

原型頁面、路由或功能目錄的位置。
與正式業務入口的隔離方式。
僅當用戶明確要求時修改的既有頁面或模組。
核心使用者流程。
必須實現的互動。
模擬資料狀態。
可復用元件。

第三步：沿用現有專案方式實現獨立原型

保持現有：

技術框架。
元件系統。
樣式方式。
路由方式。
圖示。
工具函數。
狀態管理習慣。

第四步：增加模擬資料和互動

使用本地狀態實現本次評審所需的完整流程。

第五步：補充必要狀態

只增加與當前功能相關的狀態：

空狀態。
載入狀態。
校驗狀態。
禁用狀態。
成功狀態。
錯誤狀態。
二次確認。
無權限狀態。
資料不可用狀態。

第六步：實際執行專案

需要時啟動現有本地開發服務。

專案無法預覽前，不要宣稱任務已經完成。

第七步：進行視覺和互動檢查

檢查：

頁面不是空白。
樣式正常載入。
圖示和資源正常顯示。
文字沒有明顯溢出。
佈局不會異常跳動。
核心互動可以使用。
導航沒有死路。
響應式表現可接受。

有條件時，使用瀏覽器檢查或截圖驗證。

十二、最終交付物

根據任務實際情況，最終應包括：

新增或修改的前端原始碼。
獨立原型頁面、功能目錄或路由，以及入口說明。
僅在用戶明確要求時修改的既有業務頁面。
復用的公共元件。
本地模擬資料。
可點擊的核心互動。
相關空、載入、校驗、禁用、成功和錯誤狀態。
可正常使用的頁面導航。
專案執行或預覽說明。
產品假設說明。
尚未明確的業務規則清單。
如建立 demo.md，記錄評審結論與待確認事項；它只做交接標記，不替代專案自己的工程工件。

除非對執行或評審有幫助，否則不要額外建立大量文件或架構檔案。

十三、完成標準

滿足以下條件後，原型才算完成：

原型頁面或模組已經存在於當前專案中，並與正式業務入口隔離（除非用戶明確要求覆蓋原入口）。
視覺風格與現有專案一致。
已合理復用現有元件和設計 Token。
核心使用者流程可以從開始走到結束。
每個主要操作都有明確回饋。
頁面導航沒有死路。
關鍵操作後模擬資料能夠更新。
相關頁面狀態已經體現。
文字沒有明顯溢出。
專案可以在本地正常執行，沒有阻塞錯誤。
沒有擅自擴大已經確認的產品範圍。
最終回覆明確說明了產品假設和待確認規則。

十四、最終回覆要求

完成後，使用產品經理容易理解的方式說明：

新增或修改了哪些頁面、模組和流程。
原型入口的位置，以及它如何與正式業務入口隔離。
哪些互動已經可以點擊。
增加了哪些模擬資料和頁面狀態。
復用了哪些現有元件和專案規範。
做出了哪些產品假設。
哪些業務規則仍待確認。
如何執行或預覽原型。
完成了哪些視覺和互動檢查。
復用了哪些產品體驗基線；如出現重複新模式，說明其是否只是候選，未確認前不將其抽成全域規則。
評審確認後由研發按原型實現；不在原型階段偽造工程工件，也不擅自實現生產程式碼。

最終回覆應簡潔，重點說明產品經理需要評審的內容。

在你喜歡的 AI 中提問

說明文件