原型優於 PRD

資料來源#

Designing with Claude: From prompt to production

摘要#

Dan Carey 講述 Claude Design 團隊如何在 Anthropic Labs 內部一場為期十週的開發中，以原型取代了產品需求文件（PRD）。其論點是：文件不精確；原型很具體。 兩個人讀同一份 PRD，腦中各自建出兩種不同的產品，而通常兩者都不是作者原本想要的那一個。原型消除了這種模糊——它直觀、可動手操作，你能直接感受到那個體驗。Carey 是一位「寫 [PRDs] 已經將近二十年」的產品經理，他說原型「對我而言已實質取代了 PRDs」。這是本 wiki 的 PRD 懷疑光譜上最極端的一點：不是更輕量的 PRD（AI Native Product Cadence），也不是把 PRD 視為對齊的下游產物（Design Concept Grilling），而是完全不要 PRD——原型就是規格。

機制（可複用的部分）#

Carey 可重複的流程，讓團隊的原型迭代週期「縮短到幾分鐘」：

和隊友一起把問題談一遍——談的是問題——並錄下對話。
談為什麼，而不是做什麼。 明確地說：不要描述功能、按鈕、畫面。要談這個問題為什麼重要，以及一個好的解法該具備哪些特質。
轉錄對話（任何轉錄工具皆可）。
把逐字稿交給 Claude／Claude Design，請它給「幾個選項」——三種可能解決問題的原型變體。
動手操作這些變體並做出反應。

「談為什麼而非做什麼」這條規則是關鍵承重點：它把做什麼留給模型，所以原型能讓你驚喜，而不只是把你既有的假設原封不動地搬進 UI。這正是 HTML as the New Markdown 套用在計畫上的同一套「刻意少規定、讓能力來填補」的手法（也是 the bitter lesson 所闡述的原則）。

為何原型勝過文件#

「兩個人看同一份文件，腦中卻浮現兩種不同的產品，這太容易發生了……而且通常那兩個想法都不是作者原本的那個想法。」

文件不精確；原型則具體、直觀，能讓你「真正親自感受那個體驗」。產物所承載的資訊比對它的描述更多——這正是 Fiona Fung 在 Building Is Cheap, Arguing Is Expensive 中套用在技術爭論上的同一套邏輯（「生成三個 PR 來對比」而非用白板）。Carey 的貢獻在於把這套邏輯從在多個實作之間做決定往上游推進到編寫規格本身。

團隊刻意沒有做的事#

Carey 列出了團隊跳過的那些計畫產物，因為「如果你完全清楚自己要建什麼，那些東西很棒」——而他們並不清楚：

事先不寫 PRD
零願景文件
零 OKR 會議
沒有 H1 年度人力配置計畫
沒有兩年計畫
沒有預先寫好的新聞稿

「我們唯一知道的，就是我們有一個火花。」拿掉這些，正是 Compounding Loop Optimization 所騰出、可再投入迭代的時間，也是 AI Native Product Cadence 中「計畫極小化」的那一半。

Pitch-off：實證點#

團隊的「pitch-off」儀式（一種腦力激盪會議，人們試圖招募協作者一起押注某個賭注）成為「原型即規格」這套做法奏效的證據。他們第一次用 Claude Design 跑這個儀式時，「100% 的提案都是用 Claude Design 做出來的原型或投影片……都是在會議當下即時做出來的。」當這個編寫規格的工具快到可以在腦力激盪中即時使用，原型就不再是下游交付物，而成為思考本身的媒介。

這在本 wiki 的 PRD 諸立場中位於何處#

立場	來源	對 PRD 的態度
更輕量的 PRD	AI Native Product Cadence（Cat Wu）	模糊的功能用一頁式文件；只有重型基礎設施才寫完整 PRD
PRD 作為終點文件	Design Concept Grilling（Matt Pocock）	先透過拷問抵達設計概念；PRD 是對齊的下游產物，之後便刪除
建出來再決定	Building Is Cheap, Arguing Is Expensive（Fiona Fung）	生成三個真實的 PR 來對比；減少設計文件
原型即規格	本頁（Dan Carey）	完全跳過 PRD；一場「為什麼」對話 → Claude → 3 個原型變體即可取代之

本 wiki 已持有的調和（出自 Building Is Cheap, Arguing Is Expensive）：低成本的建造並未廢除設計思考——而是把它重新安置到建出來的產物之中。Carey 把這種重新安置推到了極致。仍然存在的張力是 Design Concept Grilling 的警告：你在建造前仍需要一個共享的設計概念；Carey 的回答是，那場聚焦於「為什麼」的對話（被錄下、餵給模型）正是對齊發生之處，而原型則是它的第一次表達。

開放問題#

原型優於 PRD 在哪裡會失效？Carey 的領域是視覺設計工具，在那裡原型就是產品介面；對於後端／基礎設施／資料相關的工作，原型可能無法捕捉規格（參見 AI Native Product Cadence 的「重型基礎設施功能才寫完整 PRD」）。
如果沒有 PRD，那麼理由（「我們為何選了變體 B」）對未來的讀者而言存在於何處？這與 Building Is Cheap, Arguing Is Expensive 所指出的同一個「理由難以保存」的缺口相同。
「原型即規格」絕不能變成 Problem-Solution Fit Discipline 所警告的「原型即驗證」陷阱：一個快速做出的原型只證明了這東西做得出來，而非證明問題真實存在。

衍生內容#

The PRD-Replacement Spectrum at AI-Native Speed — 光譜的右極：原型就是規格；本頁的兩個開放問題（無依歸的理由、原型即證據）正是該光譜尚未解決的兩筆債務
Where Does the Why Live? — 對本頁「理由」開放問題的聚焦回答：那個「為什麼」在被錄下的「為什麼」對話中有了好歸宿，卻對未來的讀者無所依歸

資料來源#

Designing with Claude: From prompt to production

原型優於 PRD

資料來源#

摘要#

機制（可複用的部分）#

為何原型勝過文件#

團隊刻意沒有做的事#

Pitch-off：實證點#

這在本 wiki 的 PRD 諸立場中位於何處#

相關連結#

開放問題#

衍生內容#

資料來源#