2026 年，你的團隊準備好要建一個「AI 功能」了。估算六個月，三位工程師。投資人說好，老闆說衝。
但在你打開 IDE 之前，有一個問題你沒有答案：
| 「如果我們真的做出來了，會有人用嗎？」 |
這篇文章要告訴你一個 250 年前就被發明、卻在 AI Coding 時代才真正成熟的答案。
第一幕：1770 年的維也納騙局
1770 年，奧地利發明家沃爾夫岡·馮·肯佩倫在維也納宮廷展示了一台機器。
一個身穿土耳其服飾的木偶，坐在滿是齒輪的棋盤桌前。它打敗了所有挑戰者——包括拿破崙。
秘密？桌子裡藏著一位真正的西洋棋大師。 所謂的「機器智慧」，是人類智慧假扮的。
250 年後，Google 前研究員 Alberto Savoia 在《The Right It》中把這個邏輯命名為 Pretotyping（注意：不是 Prototype）：
| 「在問「我們能不能做到」之前，先問「如果做出來了，有人要嗎？」」 — Alberto Savoia，《The Right It》 |
Mechanical Turk（機械土耳其人）成為 Pretotyping 最經典的手法之一：用人力模擬還不存在的複雜系統，以最低成本驗證最核心的假設。 Amazon 的眾包平台也以此命名，致敬的正是這個概念。
第二幕：你要驗證的，是什麼假設？
Mechanical Turk 不是一個通用的「建假東西」手法，它針對的是一種特定類型的高風險假設。
三種假設，只有一種值得用 Turk 法
| 假設類型 技術假設 「我們的 AI 模型能達到 95% 精準度」 市場假設 「目標市場有一百萬潛在用戶」 行為假設 ← 這個！ 「用戶會真的使用這個功能，而不是舊方法」 |
行為假設是最難用「問卷」或「訪談」驗證的。人們說的和做的從來不一樣。
Mechanical Turk 的強大，在於它讓你直接觀察真實行為，而不是問用戶他們「會不會」使用。
如何寫出一個可驗證的行為假設？XYZ 公式
Alberto Savoia 在《The Right It》中提出了 XYZ 公式，讓「我覺得用戶會喜歡」變成一個可以被驗證、被推翻的科學陳述：
| XYZ 公式 至少 X% 的 Y，會做 Z X = 量化門檻。你預期的最低成功比例是多少？要在實驗前就定好，不能事後回推。 Y = 目標族群。要具體到可以找到這些人，不能只說「用戶」。 Z = 可觀察的具體行動。「喜歡」不算，「點擊按鈕」算。 |
XYZ 的厲害之處，是它強迫你面對三個你可能不想回答的問題：
• X 問你：多少才算成功？60% 採用率和 20% 採用率，對商業模式的意義天差地遠。
• Y 問你：你真的知道你的用戶是誰嗎？不同族群的行為假設可能完全不同。
• Z 問你：你要觀察什麼行為？「用戶覺得有用」無法在 48 小時實驗中被觀察到。
| 用 XYZ 公式寫林薇的假設 至少 60% 的客服專員（Y），在收到 AI 建議後，會直接點擊「採用建議」或僅做小幅修改後送出（Z） 為什麼是 60%？ 低於這個門檻，系統節省的人力成本不足以支撐開發投資。這個數字要在實驗前定義好，防止「結果出來再說」的自我欺騙。 |
「用戶喜歡 AI 功能」不是一個假設，因為它沒有 X（多少算喜歡？），Y 太模糊，Z 無法觀察。套用 XYZ 公式是寫假設的第一步，也是最難的一步。
第三幕：林薇的 48 小時實驗
讓我們用一個具體故事來示範整個流程。
情境： 林薇的團隊想開發 AI 自動回覆客服系統。工程估算六個月。
Step 1：用 XYZ 公式定義危險假設
林薇把「客服人員應該會喜歡 AI 建議」這個模糊念頭，套進 XYZ 公式，寫成一個可以被驗證的假設：
| XYZ 假設 至少 60%（X）的客服專員（Y），在處理退款申請時，會直接採用或小幅修改 AI 建議後送出，而不是自己重新撰寫（Z） X = 60% | Y = 客服專員（處理退款） | Z = 採用或小幅修改後送出 |
為什麼是「危險假設」？因為 X 設定了明確的失敗線：如果採用率低於 60%，ROI 就不成立，整個專案就不該做。這個數字要在實驗前定好，防止事後「調整標準」。
Step 2：用 AI Coding 建假裝介面
林薇用 Claude 寫了一個 prompt：
| 給 AI 的 Prompt 「幫我建一個客服回覆介面，顯示客戶訊息和一個『AI 建議回覆』的文字框。當客服人員點擊『採用 AI 建議』時，發一個通知到我的 Email，附上他們是否修改過內容。」 |
整個介面用 Cursor 在半天內完成。後端不是 AI，是林薇自己事先準備好的「罐頭回覆」，手動貼進系統。
Step 3：你就是那個「AI」
客服人員看到的是「AI 建議」，實際上是林薇根據情境手動選擇並輸入的標準回覆。這是 Mechanical Turk 的精髓：人在背後操作，觀察真實行為反應。
重點不是建立可擴展的系統，而是觀察，記錄，問問題：
• 他們在哪個步驟猶豫？
• 他們修改了 AI 建議的哪些部分？
• 他們在什麼情況下直接放棄 AI 建議、自己寫？
Step 4：找到你的「34%」
三天，47 筆客服互動後，林薇有了數據：
| 實驗結果 ✓ 78% 的回覆被直接採用或小幅修改 ✓ 34% 的案例需要查詢訂單資料庫才能給出建議 ✗ 12% 的案例，客服人員完全放棄建議，原因是情緒處理需求 |
那 34% 就是「真實洞察」——純 AI 系統若沒有整合訂單資料庫，有三分之一的工作根本做不了。
這個發現，讓林薇在任何工程師動手之前，就重新定義了整個系統的架構優先序。
第四幕：AI Coding 為何讓 Mechanical Turk 進化？
過去，建一個「假裝介面」需要工程師花數週時間。這讓 Pretotyping 只存在於書本和演講裡。
現在，任何人可以在幾小時內用 Claude、Cursor 或 v0 建出外表逼真的產品外殼，成本趨近於零。
| AI Coding 之前 建假裝介面需要 1-2 週工程時間 高成本 → 少做驗證實驗 Pretotyping 停留在理論層面 | AI Coding 時代 任何人用自然語言，數小時內建好外殼 低成本 → 每週可跑多個驗證實驗 Pretotyping 成為每個 PM 的基本技能 |
但不變的核心是：你仍然需要一個清晰的行為假設，和誠實面對數據的勇氣。
AI Coding 只是讓「建外殼」的成本消失了，它不能替你定義值得驗證的假設，也不能替你解讀那些讓人不舒服的結果。
第五幕：現代 Mechanical Turk Playbook（五步驟）
1. 用 XYZ 公式寫下你的危險假設
套入公式：「至少 X% 的 Y，會做 Z」。先定義 X（多少才算成功），再定義 Y（誰是你的目標族群），最後定義 Z（什麼行為可以被觀察記錄）。這三個問題若答不出來，就還沒準備好開始實驗。
2. 識別你的 Turk 機制
誰在桌子裡？你需要哪些「人力後端」來模擬系統運作？可以是你自己、你的團隊成員、或是招募的工讀生。明確定義觀察什麼行為，記錄什麼數據。
3. 用 AI Coding 建外殼（給 Claude 的 Prompt 範本）
| Prompt 範本 「幫我建一個 [功能名稱] 的介面，讓 [目標用戶] 可以 [核心行動]。當用戶 [關鍵互動行為] 時，發一個通知到 [聯絡方式]，記錄 [觀察數據]。視覺上要像一個真實產品，不需要後端邏輯。」 |
4. 執行：你是那個 AI
讓真實用戶與介面互動，你在後端手動操作。記錄每一次互動：卡在哪？問了什麼？放棄了嗎？設定明確的停止條件，例如「20 個用戶互動後停止」或「3 天後統計」。
5. 決策：建、轉、或放棄
以數據為基礎做三選一：
• 數據強力支持假設 → 全力建造，並帶著這些洞察重新設計架構
• 部分支持，發現新的關鍵變數 → 轉向，修正假設，再做一輪
• 數據否定假設 → 提早放棄，把六個月工期省下來
可以驗證哪些假設？三個真實場景範例
選擇 Mechanical Turk 場景有一個關鍵前提：用戶本來就不期待即時結果。 延遲是產品設計的一部分，不是缺陷。以下三個場景都符合這個條件。
場景一：AI 合約風險審查
法務人員或業務上傳合約後，隔天收到一份「AI 標示風險條款、建議修改方向」的報告。這是正常的專業服務節奏，沒有人期待合約審查是即時的。
| XYZ 假設 至少 55% 的法務／業務人員（Y），在收到 AI 合約審查報告後，會以報告中標示的風險點為基礎進行談判或修改，而不是忽略報告自己重看（Z） |
Turk 機制： 人工閱讀合約、標示條款、寫建議，透過介面呈現為「AI 報告」。用戶上傳後看到「分析中，預計 2-4 小時完成」，完全符合預期。X = 55%，低於此代表用戶不信任報告品質，產品沒有價值。
場景二：AI 競品分析報告
產品經理或行銷人員輸入競品名稱與自家產品定位，數小時後收到一份結構化的競品分析。這本來就是需要時間的任務，用戶預期的是「今天送出、明天看到」。
| XYZ 假設 至少 50% 的產品經理（Y），在收到 AI 競品分析報告後，會將其中至少一個洞察直接納入下一次的產品規劃會議（Z） |
Turk 機制： 人工搜集競品資料、整理成標準化報告格式，透過介面呈現為「AI 生成」。這裡的 Z 特別重要：不是「覺得有用」，而是「實際用進規劃會議」，這是可以追蹤的行為。
場景三：AI 個人化健身菜單
用戶填完健康狀況、目標、可用時間的問卷後，「AI 在 24 小時內生成你的專屬四週訓練計畫」。這個等待時間本身傳遞了「這是認真為你客製化的」的訊號。
| XYZ 假設 至少 45% 的用戶（Y），在收到個人化菜單後，會在第一週內按照計畫完成至少三次訓練（Z） |
Turk 機制： 人工根據用戶填寫的問卷，套用訓練原則組合出菜單，透過介面呈現為「AI 生成」。Z 不是「喜歡菜單」，而是「真的去做了」，這才是產品能否留存的關鍵指標。
什麼情境不適合 Turk 法？
Mechanical Turk 有一條明確的邊界：當用戶期待即時互動時，這個方法就失效了。
| 不適合的情境 ✗ 對話式 AI 助理 — 用戶不斷修改提示、期待即時回覆，人工根本跟不上 ✗ 即時推薦系統 — 用戶滑動頁面期待毫秒級個人化，人工無法模擬 ✗ 高頻重複操作 — 每天使用多次的功能，人力成本會快速失控 這些情境需要其他 Pretotyping 手法，例如 Pinocchio（純前端假裝有功能）或 Fake Door（只做入口，點擊後顯示「即將推出」）。 |
尾聲：土耳其人的遺產
1770 年，von Kempelen 用一個藏在桌子裡的棋手，讓世人相信機器智慧已經到來。
這不是欺騙，這是對自己誠實的最快路徑——在你宣告「機器可以做到」之前，先確認「人用這個方式做到」是否真的有價值。
在 AI Coding 讓建立外殼的成本趨近於零的今天，每一個 Product Builder 都可以成為 von Kempelen。
在投資六個月之前，先坐進那個桌子裡。
| 本文核心三問，給每位 Product Builder 1. 你最危險的行為假設是什麼？（如果它是錯的，整個產品就垮了） 2. 你需要誰坐在桌子裡，才能在一週內模擬這個系統？ 3. 你需要看到什麼數據，才能決定值得繼續投入？ |
發表迴響