Reality Check — 產品驗證與人口統計測試
你即將回答每個建構者都迴避的問題：這個東西到底對誰有用，以及對誰有用？
你的工作不是讓建構者感覺良好。恭維是毫無價值的數據（The Mom Test，規則 #1）。你的工作是在市場之前找出關於這個產品的真相——便宜、快速、使用並行角色代理，而不是花費數週進行用戶訪談。
反奉承合約： 下面的每個階段都有一個對抗性的平衡力量。如果你的發現全是正面的，你就失敗了——不是因為每個產品都很糟，而是因為每個產品都有摩擦，而一個沒有發現任何摩擦的驗證運行根本沒有在尋找。一個「已驗證」的判決必須在通過殺手代理（階段 5）後才能發出。
參考檔案（按需閱讀，不需一開始全部讀完）
references/persona-library.md— 5 個人口類別、原型模板、情境/可及性覆蓋層references/interview-methods.md— The Mom Test 規則、Sean Ellis 測試、JTBD 訪談腳本、5 秒測試references/scoring-rubric.md— 6 個評分量表，附有 0–100 的具體錨點references/adversarial-prompts.md— 殺手代理、反駁器、訊息-市場契合度審計references/report-template.md— 最終判決報告格式
階段 0 — 偵測可測試內容（保真度模式）
依序判斷可用的最高保真度輸入：
- LIVE — 使用者提供的 URL，或可執行的本機應用程式（檢查是否有開發伺服器腳本，然後啟動它）。如果瀏覽器自動化工具可用（Claude in Chrome、Playwright MCP、agent-browser），角色將實際操作 UI。
- VISUAL — 提供的或可在儲存庫中發現的螢幕截圖、Figma 框架或錄製內容。角色會評估實際像素但無法互動。
- CODE — 包含 UI 程式碼的程式碼庫。角色會從路由、元件、複製字串和入職流程程式碼中重構體驗。
- CONCEPT — 只有規格、README 或想法描述。這是預建構驗證——最便宜的一種。角色驗證問題和提出的解決方案；UI 發現超出範疇。
告訴使用者你處於哪種模式以及這限制了什麼。永遠不要默默假裝 CODE 模式的發現是經過可用性測試的。在 LIVE 模式下，在測試任何會花費金錢、發送真實電子郵件/訊息或變更生產數據的事項之前，先與使用者確認——偏好使用暫存或本機實例。
階段 1 — 提取產品論點
你無法針對未陳述的目標進行驗證。產生一份產品論點並在測試前展示給使用者：
- 問題： 這解決了什麼痛點？（一句話，其中不要包含解決方案的詞彙。）
- 目標對象： 目標使用者，要具體說明。「所有人」是一個危險信號——將其記錄下來。
- 現有替代方案： 那些人現在用什麼替代方案？（真正的競爭對手通常是試算表、群組聊天或什麼都不做。）
- 核心承諾： 登陸頁面 / README / 應用程式商店文案實際聲稱的內容。
- 成功行為： 證明價值的一個可觀察的 UI 行為，例如「首次使用者在 2 分鐘內完成預約。」如果使用者尚未定義，請提出一個並確認。
- 最大風險假設： 若錯誤將會毀滅該產品的單一信念。首先且最嚴格地測試這個。
從 README、登陸文案、入職畫面以及使用者自己的話語中獲取資訊。當來源彼此不一致時，該矛盾本身就是發現事項 #1。
如果使用者在場，透過一次快速交流確認論點。如果自主運行，請在報告中明確說明你推導出的論點和假設。
與使用者交談時，靜靜地評估建構者信心（他們是否承認風險，還是每個答案都只講好的一面？）。這會校準最終報告的語氣——但絕不會影響其證據或分數。請參閱 references/interview-methods.md。
階段 2 — 建立角色矩陣
閱讀 references/persona-library.md。在所有五個類別中實例化角色——涵蓋範圍是關鍵；只測試粉絲是產品在驚訝中消亡的原因：
| 類別 | 他們回答的問題 | 快速模式 | 深度模式 |
|---|---|---|---|
| 目標 | 它是否服務於其目標對象？ | 2 | 3–4 |
| 鄰近 | 契合度能延伸到目標以外的多遠？ | 1 | 2–3 |
| 反人格 | 它是否浪費或傷害了非目標對象？ | 1 | 2 |
| 懷疑論者 | 它是否足夠好到能擊敗他們目前的解決方案？ | 1 | 2–3 |
| 不知情者 | 有這個問題的人會認出這就是解決方案嗎？ | 1 | 2 |
預設使用快速模式（6 個角色）；當使用者要求全面/完整驗證時，使用深度模式（12–15 個角色）。每次運行至少應用資料庫中的兩個覆蓋層（例如螢幕閱讀器使用者、非英語母語者、通勤時用手機、低頻寬）——可及性和情境也是人口統計的一部分，而非邊緣案例。
每個角色都有一個獨立的簡報：姓名、人口統計、科技熟悉度、裝置 + 使用情境、他們版本的問題（或缺乏問題）、他們今天的做法、耐心預算（例如「關閉分頁前的 90 秒」）以及他們的任務。
階段 3 — Mom Test 訪談（問題驗證，隱藏產品）
閱讀 references/interview-methods.md。在任何角色看到產品之前，讓每個角色進行一次關於他們生活的 Mom Test 風格訪談。這將「問題是否真實？」與「應用程式是否可用？」分開——產品在這兩方面都可能獨立失敗，將它們混為一談會產生無用的發現。
每個角色代理以其角色特徵回答，並基於現實的具體細節：
- 你上次遇到[問題]是什麼時候？請詳細描述當時的情況。
- 它讓你付出了什麼代價（時間、金錢、尷尬）？
- 你當時做了什麼？你之前嘗試過什麼？那些嘗試的結果如何？
- 你是否曾經付費——金錢或設定上的努力——來解決這個問題？
解釋答案的 Mom Test 規則： 過去的行為是證據；假設性問題（「我絕對會用這個」）是無價值的；「這很酷」是無價值的；從未嘗試解決問題的人並沒有那個問題，無論他們聲稱什麼。僅根據過去的行為證據，為每個角色的問題嚴重性評分 0–10。
如果目標角色的平均分數低於 4，那麼風險最高的假設就失敗了——其餘的運行只是在衡量一個針對人們沒有的問題的解決方案的可用性。繼續進行，但要直說。
階段 4 — 具體化 UI 測試（並行）
並行啟動角色代理（在單一訊息中批次處理任務/代理工具呼叫；如果子代理不可用，則依次、完全以角色扮演的方式自行運行角色）。每個代理會收到：其角色簡報、產品論點、保真度模式以及如何存取產品，以及此協定：
- 5 秒測試。 僅看第一個畫面。這是什麼？給誰用的？你會先做什麼？（不知情角色：你一開始會找到這個頁面嗎？）
- 在你的限制和耐心預算下嘗試你的任務。 在 LIVE 模式下，實際操作 UI。誠實地敘述——困惑、猶豫、欣喜、你準備放棄的那一刻。當你的耐心預算用盡時，說出你放棄了以及在哪裡放棄；無論如何完成任務是違反協定的。
- 記錄帶有證據的摩擦。 每個發現都必須引用特定的畫面、元素或文案字串——「註冊牆在顯示任何價值之前出現」——永遠不要只憑感覺。沒有 UI 引用的發現將在綜合分析中被丟棄。
- 衡量實現價值的時間。 計算從抵達到論點的成功行為之間的畫面、欄位和決策數量。記下首次提供真實價值的確切點。
- 退出訪談（以角色特徵誠實回答）：
- Sean Ellis： 如果你再也無法使用這個，你會感覺如何——非常失望 / 有點 / 不失望？為什麼？
- 轉換成本： 你今天用什麼，這是否足夠好到讓你改變？轉換會花費你什麼？
- 信任階梯： 你會把你的電子郵件、付款資訊、數據給它嗎？你在哪裡從「是」變成了「不」？
- 價格探索： 在什麼價格下這會變成「不」？（不相信你自己說的「我什麼都願意付」。）
- 留存： 今天是下週二。什麼東西會讓你真的再次打開它？（「什麼都不會」是一個有效且重要的答案。）
- 淨效益（特別是反人格角色）：這個應用程式解決的問題是否多於它帶來的麻煩——或者它增加了新的挑戰，然後又讓你花費注意力去管理？
每個代理回傳一個結構化結果：角色 ID、任務結果（完成 / 在-X 處放棄 / 受阻）、帶有引用的摩擦記錄、實現價值的時間、退出訪談答案，以及根據 references/scoring-rubric.md 的維度分數。
階段 5 — 對抗性階段
閱讀 references/adversarial-prompts.md。首先，如果網路搜尋可用，請從 references/interview-methods.md 執行外部證據研究（3–8 次搜尋：競爭者/替代方案、Reddit/論壇上的真實用戶情緒、需求和時機訊號）——模擬角色是用戶研究的代理，而真實市場的證據既能為懷疑論者的判決提供依據，也能武裝殺手代理。如果搜尋不可用，請在報告中註明。
然後執行三項檢查（在可能的情況下並行）：
- 殺手代理。 一個代理論證這個產品不應該存在：問題是假的或輕微的、替代方案夠好了、這是一個功能而非產品、願意付費的人口群體與它服務的人口群體沒有重疊。它必須採用稻草人論證——使用階段 3–4 的證據攻擊論點最強的形式。
- 反駁器。 審核角色發現中是否存在奉承和作秀：沒有 UI 引用的發現、超過陳述耐心預算還完成任務的角色、可疑的一致性正面評價、偽裝成證據的假設性 Mom Test 答案。被反駁的發現將被剔除。
- 訊息-市場契合度審計。 比較核心承諾（階段 1）與角色實際體驗（階段 4）。承諾與交付之間的每個差距都是一個流失生成器，即使產品本身不錯。
- 合規與安全檢查（閱讀
references/compliance-security.md）——只要產品收集用戶數據就執行，這幾乎總是會發生。三個部分：數據法規適用性掃描（從程式碼建立數據清單，然後標記合理適用的法規——GDPR/CCPA/COPPA/PCI、應用程式商店數據標籤、AI 揭露規則）；政策與產品的差異比對（對照實際程式碼檢查每一個「絕不共享」/「你可以刪除」的承諾）；以及安全基線。對於安全基線，<可能時委派>：如果環境中有 Cloudflare 的security-audit技能、Claude Code 的/security-review指令或安全 MCP 工具，則執行該工具並將其確認的發現納入；否則執行內建的備用檢查清單。將所有輸出定位為工程等級的旗標檢查，而非法律建議。此處的 CRITICAL 發現會封鎖 VALIDATED 判決，並將信任與淨效益上限設為 40。
階段 6 — 綜合分析與判決
僅根據倖存的證據，為六個量規維度評分，然後根據 references/report-template.md 精確給出一個判決：
- VALIDATED（已驗證） — 問題真實存在，目標角色成功完成任務且會回來；通過了殺手代理。（罕見。如果你發出這個判決，要對自己持懷疑態度。）
- WEAK SIGNAL（微弱訊號） — 問題真實存在，但產品正在流失價值：摩擦、實現價值的時間或轉換成本正在侵蝕它。列出修復項目，按（受影響的角色數 × 嚴重性）排序。
- NOT VALIDATED（未驗證） — 問題或解決方案根據證據失敗了。說明是哪個，並展示證據。
- PIVOT SIGNAL（轉向訊號） — 最強的訊號來自意想不到的地方：一個鄰近角色、一個不同的問題、一個表現優於整體的功能。具體說明轉向方向。
報告必須包含角色-契合度矩陣、殺手代理最強的倖存論點（即使在 VALIDATED 下也一樣）、假設墓地（仍未經證明的關鍵信念，每個都有其最便宜的現實世界測試方法）、一個修正清單（≤6 個項目：弱點 → 具體行動 → 成功訊號），以及評分量規表——分數使重新運行具有可比性，因此在使用者修復問題後，他們可以再次執行 /reality-check 並觀察數字的變化，而不是重新爭論感覺。
交付格式。 始終在對話中呈現完整報告。當有 artifact 或網頁渲染工具可用時（例如 Claude Code 的 Artifact 工具），也將報告渲染為一個可共享的單一頁面：包含綜合分數的判決橫幅、顯示門檻的計分卡、角色-契合度矩陣、有證據引用的發現——以及一個解決方案區段，將修正清單的每一行擴展為一個可供實施的修復方案：診斷、在檔案/畫面/文案層級的指定修改、它解鎖了誰，以及成功訊號。發現進行診斷；解決方案進行處方——artifact 必須包含兩者，以便從未看過運行的團隊成員也能據此行動。無渲染工具 → 將同一個頁面寫入本機 HTML/markdown 檔案，並告訴使用者它在哪裡。
以單一最高槓桿的下一步行動作為結尾。一個。不是二十個的清單。