AI-Native Speed 下的 PRD 取代光譜

問題#

Wiki 中的產品開發概念——Prototype Over PRD、Building Is Cheap, Arguing Is Expensive、Design Concept Grilling，以及 AI Native Product Cadence 中的精簡版 PRD 作法——如何整合成一條在 AI-native speed 下取代 PRD 的光譜？

簡答#

這不是四種互相競爭的方法，而是一條依照建置前規格說明多寡排列的光譜。它們之所以看起來像是對手，是因為 PRD 原本就同時負責三項工作：

建立共識——讓所有人對同一個想法有共同理解（Frederick Brooks 的 design concept）。
規格說明——精確定義要建置什麼，讓人能據此實作。
記錄理由——留下決策背後的原因，供日後讀者參考。

當代理程式編碼讓生成幾乎不花成本時，每項工作受到的影響都不一樣：

規格說明逐漸消失。 原型比文字更精確地呈現規格（「文件不精確；原型具體明確」——Prototype Over PRD），而建置成本低到可以透過建置本身來說明規格（Building Is Cheap, Arguing Is Expensive）。這才是光譜真正探討的工作。
共識建立重新安置，而非消失。 它會移到更早的階段（產出任何文件前先深度討論——Design Concept Grilling），或是放進產物裡（比較三個真實 PR／三個原型）。Matt Pocock 堅持一項不可妥協的原則：這是唯一不能省略的工作。
決策理由失去歸屬。 光譜上沒有任何一種立場能妥善保存「為什麼選了變體 B」。這是真正尚未解決的部分——Building Is Cheap, Arguing Is Expensive 和 Prototype Over PRD 都將它列為待解問題。

因此，這條光譜探討的是：在有可信方式建立共識的前提下，各種立場多大程度地讓規格說明這項工作消失？

光譜#

依照建置前規格說明由多到少排列：

立場	來源	建置前規格	共識建立的位置	持久產物
先深度討論再寫 PRD	Design Concept Grilling（Matt Pocock）	最多——持續訪談 → 目標 PRD	深度討論的過程中，任何產物出現之前	PRD + Kanban；實作後刪除 PRD
精簡版 PRD	AI Native Product Cadence（Cat Wu）	依模糊程度調整——一頁文件 ↔ 完整 PRD	團隊原則 + 每週指標檢視，促進共同理解	一頁文件，或什麼都沒有
先建置再決策	Building Is Cheap, Arguing Is Expensive（Fiona Fung）	預先說明最少——生成三個真實 PR	比較已建置的產物（以及它們對被呼叫端的影響）時	選中的 PR；討論留在 PR 中
原型即規格	Prototype Over PRD（Dan Carey）	完全沒有——跳過 PRD	記錄下來的為什麼，而非做什麼對話和原型本身	原型

從左到右看，持久產物從描述事物的文字移向事物本身；共識建立的時機則從建置之前移向透過建置來建立。Cat Wu 的「精簡版 PRD」和 Carey 的「不寫 PRD」是同一種作法，只是設定不同——AI Native Product Cadence 明確指出：「Cat Wu 讓 PRD 更精簡，Carey 則完全移除 PRD——把這種節奏推到極限。」

調和兩者：重新安置，而非廢除#

表面上的矛盾——Pocock 堅持先確立 design concept 再開始建置；Fung 和 Carey 則透過建置來做出決策——只要把三項工作拆開看就會消失。Wiki 在三個地方已經調和了這些觀點，而且彼此一致：

Building Is Cheap, Arguing Is Expensive：「便宜的建置不會廢除設計思考——只是把它重新安置到已建置的產物中。」
Prototype Over PRD：Carey「把共識建立納入記錄下來的『為什麼』對話，原型則是它的第一個呈現形式。」
Design Concept Grilling：調和後的說法是：「原型是呈現 design concept 的媒介，而非取代建立 design concept 的過程。」

所以，沒有人真的反對建立共識（工作 #1）——他們爭論的是哪種產物承載共識。Pocock 透過建置前的對話來承載；Fung 和 Carey 則透過建置來承載。改變的不是是否需要共同想法，而是規格說明這項工作（#2）成本已低到可以併入共識建立，而不必另外寫一份下游文件。

讓光譜右端成立的關鍵，是「說明為什麼，而非做什麼」／「為這個問題設計理想介面」——人類說明問題，讓模型能力填補要做什麼。這與 Prototype Over PRD、Disposable Micro-Apps 和 bitter lesson 所採用的「規格不必寫滿，讓能力補上」原則相同。

第二個軸：更精簡的規格 vs. 更豐富的產物#

上面的光譜朝一個方向移動——文字減少。但面對相同壓力，也有另一種垂直方向的回應：讓面向人類的產物變得更豐富，而不是更精簡。HTML as the New Markdown 和 Disposable Micro-Apps（Thariq Shihipar）保留完整計畫，但以互動式 HTML 呈現（並啟動臨時微型應用程式來編輯計畫），因為模型能力提升後，瓶頸變成人類的注意力，而不是模型的理解力。

因此，這組概念描繪的是一個平面，而非一條線：

面向模型的規格會隨能力提升而縮減（Harness Shrinkage as Models Improve）——這是 Carey 邁向「不寫 PRD」的軸線。
面向人類的 harness可以擴充，讓人類持續保持共識——這是 Thariq 邁向「更豐富的 HTML 計畫」的軸線。

AI Native Product Cadence 把兩者描述為「對高速開發中 PRD 的相反押注：Cat 讓它們更精簡，Thariq 讓它們更豐富——兩者都是為了在不拖慢速度的情況下，讓人類維持共識。」取代 PRD 的光譜是精簡軸；HTML／微型應用程式作法則是豐富軸。兩者都行得通，因為它們服務的是規格的不同使用者。

如何選擇立場：前提條件#

只有在前提成立時，各種立場才安全。這條光譜不是「越往右越進步」的成熟度階梯，而是依情況選擇合適作法。

前提條件	適合採取的方向
高風險／需求說明模糊／犯錯代價高	先深度討論（Design Concept Grilling：「功能越大、需求越模糊、代價越高 → 討論越深入」）
範圍明確且改動簡短（「在整個程式碼庫中重新命名這個項目」）	跳過深度討論，直接建置——額外流程只會浪費時間
原型呈現面 == 產品呈現面（視覺／UI 工作）	原型即規格（Prototype Over PRD：Carey 的領域是設計工具，原型就是產品）
後端／基礎設施／資料工作	使用較完整的規格——原型可能無法呈現完整規格（AI Native Product Cadence：「大型基礎設施功能使用完整 PRD」）
決策取決於對其他程式碼的影響	先建置再決策——三個真實 PR 能揭示文件無法呈現的被呼叫端影響（Building Is Cheap, Arguing Is Expensive）
有可驗證的成功標準	深度討論之後的任何位置——先建置再決策假設你能驗證哪個建置版本較好（Verification as the New Bottleneck）

整個光譜右半部背後的關鍵前提是 Verification as the New Bottleneck：「生成三個再比較」只有在比較成本低於爭論成本時才算進步。生成變得便宜後，原本為了保護稀缺工程產能而進行的繁重前期規劃，便失去存在理由——這正是光譜得以展開的原因。

兩個尚未解決的問題#

沿光譜往右移可以提升速度，但也會留下來源文章提出、卻都未完全解答的兩筆債務：

失去歸屬的決策理由（工作 #3）。 如果設計留在 PR 和原型中，PRD 又在實作後刪除，下一位讀者要去哪裡找到「為什麼我們選 B 而不是 A」？ Building Is Cheap, Arguing Is Expensive 和 Prototype Over PRD 都把這列為待解問題；它也有 Code as Source of Truth 面臨的內容過時問題。更豐富產物的軸線（HTML as the New Markdown）部分解答了這一點——持久的互動式產物可以保存已刪除 PRD 無法保存的決策理由——這也是兩個軸線互補而非互相競爭的另一個原因。
把原型當成證據的陷阱。 快速製作原型即規格，證明的是建置可行，不是問題確實存在。Problem-Solution Fit Discipline 直接指出：「原型只能驗證建置任務可以解決，不能驗證問題確實存在或解決方案適用。」光譜右端最容易遇到這個陷阱，因為原型快速完成帶來的進展感會取代實際驗證。AI 並未改變用來補足落差的紀律：原型是「用來和潛在使用者對話的壓力測試道具……這些對話才是真正的證據。」另外，Build for the Next Model 提醒：「幾乎能用了」是對能力的押注，不是問題值得解決的證據。

結論#

PRD 沒有單一正確的長度。光譜是依照每項任務的三個判斷來調整的刻度盤：需求有多模糊（越模糊 → 越要深入討論，往左）、原型呈現面是否就是產品呈現面（是 → 原型即規格，往右），以及你能否驗證哪個建置選項較好（能 → 先建置再決策）。往右移可以讓規格說明這項工作消失；但你仍須在某處建立共識（透過說明原因的對話、深入討論或比較），也仍須保存決策理由並進行真實使用者驗證，而這些都不會因調整刻度而自動免費取得。便宜的建置把設計思考重新安置到產物中，並未廢除思考。

補記（2026-09-02）：超越右端的新立場，以及左端失效的報告#

Spec-Driven Development as the New Waterfall 從工藝傳統而非產品領域帶來第五種立場：Robert C. Martin（2026-08-19，practitioner-opinion）完全不保留任何規格——「規格是暫時的，會消失……我看著最終成果，然後說，好吧，那就是規格。」這讓表格裡往右移動的持久產物比 Carey 更進一步：持久產物甚至不是原型，而是檢查工具（CRAP 分數、變異測試、依賴規則），用來說明系統必須符合什麼條件。它有兩點不同於前述四種立場。首先，它首次帶來親身報告，指出在代理程式參與下，光譜左端會失效——先規劃再執行「總是一場災難」，因為代理程式會照著有缺陷的計畫繼續做，超過人類實作者原本會停下來的時點。其次，它點出整個往右移動所依賴的經濟前提：變更成本接近零；Martin 本人也指出，這是他預期會錯的預測。另一方面，The Committed-Artifact Chain（Anthropic Applied AI，vendor-claim，2026-08-21）則朝相反方向移動，把 PRD 拆成三項已提交的產物，而非將它刪除——因此，現在兩個端點之外都各多了一個新立場，但兩者都沒有附上衡量方式。

資料來源#

Design Concept Grilling——Matt Pocock，深度討論／以 PRD 為目標
AI Native Product Cadence——Cat Wu，精簡版 PRD（另有 Dan Carey 的佐證）
Building Is Cheap, Arguing Is Expensive——Fiona Fung，生成三個 PR
Prototype Over PRD——Dan Carey，原型即規格
HTML as the New Markdown／Disposable Micro-Apps——Thariq Shihipar，更豐富產物軸線
Problem-Solution Fit Discipline——創辦人手冊中的驗證紀律
Verification as the New Bottleneck——開啟光譜的瓶頸轉移
Build for the Next Model——對能力押注的提醒