Prototype Over PRD

資料來源#

• Designing with Claude: From prompt to production
• OpenAI Codex lead on the new shape of product work

摘要#

Dan Carey 分享了 Claude Design 團隊在 Anthropic Labs 進行為期十週的開發期間，如何以原型取代產品需求文件。核心論點是：文件不精確；原型具體明確。 兩個人讀同一份 PRD，腦中會想像出兩種不同的產品，而且通常兩者都不符合作者的原意。原型消除了這種模糊性——它直接而具體，可以親手操作，讓你直接感受體驗。Carey 是一位 PM，他說自己「寫 PRD 寫了快二十年」，而原型「實際上已取代 PRD，成為我的工作方式」。這是 wiki 上 PRD 懷疑光譜中最極端的一端：不是較精簡的 PRD（AI Native Product Cadence），也不是將 PRD 視為對齊後產物（Design Concept Grilling），而是完全不寫 PRD——原型就是規格。

方法（可重複使用的部分）#

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

1. 和隊友聊透問題——並錄下對話。
2. 討論為什麼，而不是是什麼。 明確來說：不要描述功能、按鈕或畫面。要談的是問題為何重要，以及好的解決方案應具備哪些特質。
3. 轉錄對話（使用任何轉錄工具）。
4. 把逐字稿交給 Claude / Claude Design，請它提供「幾個選項」——三種可能解決問題的原型變體。
5. 親自操作這些變體並給予回饋。

「談為什麼，而非談是什麼」這條規則是整個方法的關鍵：它把是什麼留給模型處理，讓原型有機會帶來驚喜，而不是只把你先前的假設照搬到 UI 上。這和 HTML as the New Markdown 將同樣的「少加規範，讓能力補足」做法用在計畫上相同（The Bitter Lesson 也將之表述為一項原則）。

為什麼原型勝過文件#

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

文件不精確；原型具體明確、直接可感，也讓你「真正親自感受體驗」。產物承載的資訊比對它的描述更多——Fiona Fung 在 Building Is Cheap, Arguing Is Expensive 中也將同樣的邏輯用於技術辯論（「產生三個 PR 並比較」，而不是在白板上討論）。Carey 的貢獻，是把這套邏輯從在不同實作間做決定往前推到撰寫規格本身。

團隊刻意沒有做的事#

Carey 列出團隊略過的規劃產物，因為「如果你確切知道要打造什麼，這些東西都很棒」——但他們並不知道：

• 事先不寫 PRD
• 完全不寫願景文件
• 完全不開 OKR 會議
• 不訂上半年年度人力配置計畫
• 不訂兩年計畫
• 不事先寫新聞稿

「我們只知道自己有一點火花。」省下這些工作，Compounding Loop Optimization 讓團隊有時間投入更多迭代；這也是 AI Native Product Cadence 精簡規劃的另一半。

Pitch-offs：證明方法有效#

團隊的「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 → 三種原型變體取代 PRD
選擇媒介	Implementation Abundance Inverts Product Work（Andrew Ambrosino）	「PRD 並未消亡」——實作變得豐富，讓選擇媒介成為關鍵能力；產品方向明確時適合用文件，壓力測試互動時適合用原型；原型是選項之一，並非預設做法

wiki 已經提出的調和觀點（出自 Building Is Cheap, Arguing Is Expensive）是：便宜地建構並不會消除設計思考——而是把設計思考移到建成的產物裡。Carey 把這種轉移推到了最遠。持續存在的張力來自 Design Concept Grilling 的提醒：開始建構前仍需先有共同的設計概念。Carey 的回答是，以「為什麼」為核心的對話（錄下來並交給模型）就是發生對齊的地方，而原型是對齊後的第一個呈現。

另一面的補充觀點：「PRD 沒有消亡——選擇媒介」（Ambrosino）#

Andrew Ambrosino（OpenAI Codex）明確反對 Carey 所體現的口號。他提到「PRD 已死，原型當道」這種說法，並表示*「我其實完全不認同。」*他的推理讓整個觀點更嚴謹，而非與之矛盾：因為實作在所有媒介中都變得便宜（Implementation Abundance Inverts Product Work），關鍵能力已不再是「用原型取代寫作」，而是依照你要表達的重點，選擇合適的格式：

• 直接跳進原型製作是非工程師容易受到的誘惑（「我一直不會寫程式——讓我直接展示我的意思。」）。
• 寫一大堆文件是工程師容易受到的誘惑——「很多根本不值得讀的文件。」
• 應有的紀律是：「如果實作變得豐富，選擇正確的格式就非常重要。如果要釐清模糊領域中的產品方向，文件可能比較合適。如果要讓大家實際操作某個東西，以壓力測試一種互動模式，原型就比較合適。」

因此，Ambrosino 與 Carey 是並列互補，而非彼此對立：原型即規格是正確的媒介選擇之一（適用於視覺或互動問題），但若把它提升為普遍替代方案，就會再次引入 Carey 想避開的模糊性——這次表現為沒人讀的文件或讓團隊過度受限的原型（Polish No Longer Signals Readiness）。wiki 的 PRD 光譜最好理解為「依照風險選擇媒介」：Carey 位於原型這一端，Ambrosino 則說明了選擇規則。

相關連結#

• Dan Carey — 闡述這套方法
• Design by Selection — 將相同循環擴大到一組選項：「產生 15 個流程版本，蒐集同事的回饋」讓被傳閱的產物成為規格；Nate Parrott 點出其價值——隨著模型更擅長建構正式軟體，重要工作會往前移到想法、對齊與早期回饋
• Claude Design — 讓原型製作週期快到足以取代 PRD 的工具
• Compounding Loop Optimization — 略過規劃產物是團隊設法精簡掉的其中一個環節；這篇則是規格撰寫方面的對應做法
• Build for the Next Model — 原型展示的是差一點就能運作的事物；prototype-over-PRD 則是快速寫下這項押注的方法
• Building Is Cheap, Arguing Is Expensive — 同樣主張「建成的產物勝過抽象辯論」，但應用在辯論而非規格上
• Code as Source of Truth — 從另一端探討同一個理由留存缺口：Fung 因為程式碼才是真相而刪掉文件；Carey 則因為原型就是規格而刪掉文件；兩者都讓「為什麼」無處安放
• Design Concept Grilling — 有益的張力：反覆追問先找出設計概念再開始建構；Carey 則把對齊融入錄下來的「為什麼」對話
• AI Native Product Cadence — 精簡 PRD 的節奏；Carey 是極限案例（完全沒有 PRD）
• HTML as the New Markdown — 方向相反的押注：Thariq 讓計畫產物更豐富（互動式 HTML）；Carey 則以原型取代計畫產物；兩者都讓人不必面對一大堆散文，仍能投入其中
• Evals as Product Spec — 將同樣的轉移方式用在撰寫 eval：在 Google 的飛輪中，程式碼代理程式撰寫 eval，由人提出疑慮並核准；就像原型在此取代了 PRD 撰寫
• Implementation Abundance Inverts Product Work — Ambrosino 提出的觀點：關鍵能力是選擇媒介並做好整理，而非預設採用原型；這是對原型作為通用規格的補充觀點
• Polish No Longer Signals Readiness — 說明「直接做原型就好」為何會適得其反：原型看起來像是可直接發布，讓團隊過度受其影響
• Andrew Ambrosino — 表達「PRD 並未消亡」的反對意見
• Unknowns as the Agentic Bottleneck — 同一種產物的第三種用途：Thariq Shihipar 將原型做為引出需求的工具（提供幾個截然不同的方向，以找出「看到就知道」的標準），而非作為規格
• Prototype Fidelity After Cheap Polish — 這套方法留下的保真度問題：若原型就是規格，它應該完成到什麼程度？潤飾又會如何影響它原本要蒐集的回饋？
• The Committed-Artifact Chain — 對同一份文件的另一種替代方案。兩者都刪除 PRD；Carey 以一個表面就是規格的產物取代 PRD；Anthropic 的 Applied AI playbook（vendor-claim，2026-08-21）則以三份較小、已提交的文件（intent.md、spec.md、plan.md）取代，每份文件都有指定的接受者，合併後觸發下一個階段。根據 playbook 自己的說法，兩者互補而非對立——其中的 Design 流程會由產品負責人依據已接受的 intent.md，在 Claude Design 中製作前端雛形，再匯出至 Claude Code——而界線正是本頁早已指出的：原型呈現可觀察到的行為，因此沒有可見介面的限制（intent.md 的限制區塊寫著「入口網站工作階段不得新增 PII」）仍需用文字寫明。
• Spec-Driven Development as the New Waterfall — 從實作角度得出相同結論：「產物就是規格」。Robert C. Martin 保持規格短暫存在，從不提交規格文件，並補上這套方法隱含的論點——當變更成本趨近於零，事先制定完美計畫的理由也就不復存在

待解決的問題#

• 如果沒有 PRD，未來的讀者要去哪裡找理由（「為什麼我們選了變體 B」）？這和 Building Is Cheap, Arguing Is Expensive 提出的理由留存缺口相同。部分解答：Where Does the Why Live?——在撰寫時，「為什麼」有很好的歸屬（它就是錄下來的「談為什麼，而非談是什麼」對話），但在閱讀時卻無處可尋，因為承載理由的產物已經刪除。尚未解答的是：是否有耐久的閱讀時存放位置，又不會重新引入 PRD。
• 原型即規格，不應變成 Problem-Solution Fit Discipline 所警告的原型即驗證陷阱：快速做出原型只證明這項建構可行，不能證明問題真實存在。

Resolved Questions#

• 原型取代 PRD 的做法在哪裡會失效？Carey 的領域是視覺設計工具，原型就是產品介面；但對後端、基礎設施或資料工作而言，原型可能無法涵蓋規格（參見 AI Native Product Cadence 提到的「大型基礎設施功能需要完整 PRD」）。已解答：Playbook Boundary Conditions: the Devil's-Advocate Substrate and the Prototype's Edge——界線在於可觀察介面與不變條件，而非後端與前端：每個領域都有自己的示蹤產物（三個 PR、垂直切片、十個 eval、design_system.html）；因此後端失效的是可點擊的原型，而非「產物取代文件」的做法。當任何產物的介面都無法涵蓋風險時，PRD 才仍有必要——例如跨領域不變條件與跨團隊協調。

衍生內容#

• The PRD-Replacement Spectrum at AI-Native Speed — 光譜中最徹底的一端：原型就是規格；本頁的兩個未解問題（理由無處安放、原型作為證據）正是這個光譜上尚未解決的兩項債務
• Where Does the Why Live? — 直接回答本頁關於理由的未解問題：在記錄下來的「為什麼」對話中，理由有很好的歸屬，但未來的讀者卻無從得知
• Playbook Boundary Conditions: the Devil's-Advocate Substrate and the Prototype's Edge — 解答做法適用邊界的問題：界線在於可觀察介面與不變條件；非視覺領域以自己的示蹤產物取代 PRD，而非退回文件
• Is Persistence the Line Between Prompting and Spec-Driven Development? — 這套方法反例說明，不能以持久性界定規格驅動開發：Carey 的「為什麼」對話錄下後就丟棄，卻比它取代的 PRD 更精確；短暫存在的產物完成了整份規格的工作

資料來源#

• Designing with Claude: From prompt to production
• OpenAI Codex lead on the new shape of product work — Ambrosino：「PRD 已死，原型當道……我其實完全不認同」；應依照要表達的重點選擇媒介