傳統 PRD 的結構性缺陷是：它把大量篇幅花在描述「要做什麼」，只用很少篇幅（或完全不寫）交代「為什麼是這個做法」與「怎樣算做完」。這在需求提出者與實作者天天坐在一起時不構成問題——缺的資訊可以隨時口頭補齊。一旦交接變成非同步（跨時區、跨團隊、或接手者是 AI agent），這些缺口就會直接變成錯誤的實作。
Spec 是交接載體，不只是需求描述
Spec-Driven Development 的價值有一半來自它是一份好的交接物。 它把需求從「說明文件」變成「可執行契約」：有可測試的驗收標準、有明確的邊界（不做什麼）、有假設的顯性列舉。這些欄位不是為了流程完備，每一個都對應一種交接損耗——驗收標準對應「不知道怎樣算做完」，邊界對應「範圍蔓延」，假設列舉對應 隱性假設。
spec 的內容怎麼寫、四階段閘門怎麼設，Spec-Driven Development：規格先行 已經處理得很完整，這裡不重複。從交接的角度，只補三件那篇沒有強調的事。
第一，spec 必須包含「已否決的選項」。 一份只寫最終決定的 spec，交出去之後接手者會重新提案已被否決的方案，或在實作中「順手改得更好」而破壞當初的取捨。這一欄的成本極低（三行字），對抗的是最貴的一種失敗——決策漂移。
第二，Problem Framing 的產物本身也要一起交。 只交 spec 不交問題陳述，接手者會知道要建什麼，但不知道成功長什麼樣，於是在遇到 spec 沒覆蓋的細節時無從判斷。問題框定的方法見 Problem Framing：定義正確問題；從交接角度要記住的是：spec 回答 what／how，問題陳述回答 why，兩者缺一都會讓接手者在邊緣情況下亂猜。
第三，spec 的第一個讀者可能不是人。 當 spec 直接被拿去當 AI agent 的執行輸入時，它會被逐字執行而不是被合理解讀。這其實是好消息：它逼你把原本靠默契補齊的部分寫出來。壞消息是粒度問題——太粗 agent 無法執行，太細等於用自然語言重寫程式。目前沒有公認的判準，這也是 SDD 專欄 追蹤的待解問題之一。
驗收標準與 DoD 的分工
這兩個概念經常混用，但在交接裡各有位置。
驗收標準（Acceptance Criteria）是這一個需求的行為契約：在什麼情境、做什麼動作、預期什麼結果。它隨需求而變，寫在需求本身裡，最好寫成可以直接轉成測試的形式（Given / When / Then 或等價結構）。
Definition of Done 是團隊層級的一致門檻：不論做哪個需求，都必須通過的那組條件。典型的 DoD 包含測試已寫並通過、code review 已完成、可觀測性（log／metric）已加、無障礙已檢查、文件或 ADR 已更新、feature flag 與回滾路徑已確認。DoD 不需要每次重寫，它是團隊的常數。
分工的意義在交接時才顯現：AC 告訴接手者「這件事要做成什麼樣」，DoD 告訴接手者「在這個團隊裡，交出去之前還要做哪些事」。新人與 AI agent 缺的通常是後者——他們能做對功能，卻交出一個沒有測試、沒有 log、沒有回滾路徑的實作，因為沒有人告訴過他們這裡的門檻。
最容易掉落的一類：非功能需求
功能需求會被寫下來，因為它是需求提出者想要的東西。非功能需求常常不被寫下來，因為它是需求提出者預設會有的東西——這正是隱性假設的定義。
在交接時要主動點名的幾類：效能預算（首屏時間、p95 延遲、可接受的資料量級）、錯誤處理策略（重試幾次、退避策略、失敗後使用者看到什麼）、資料保存與刪除（保留多久、誰能刪、刪除是軟刪還是硬刪）、權限模型（誰能看、誰能改）、可觀測性（出事的時候要能回答哪些問題）、法規與隱私（個資落在哪個欄位、要不要遮罩）。
這些項目有一個共同特徵：事後補的成本遠高於事前寫的成本，而且多數涉及資料結構或介面形狀，一旦上線就很難回頭。所以它們值得放進 DoD 當固定檢查項，而不是指望每次需求都記得寫。
一個判準：spec 能不能撐過「作者消失」測試
檢驗需求交接品質有一個便宜的方法：假設寫這份 spec 的人今天起休假兩週，完全聯絡不到。接手者能不能只靠這份文件開工，並在遇到 spec 沒覆蓋的情況時，用文件裡的問題陳述與取捨紀錄自己判斷？
不能的話，缺的通常不是細節，而是 why。細節可以問，why 沒有人能替你回答。
延伸
- spec 的完整結構與寫法 → Spec-Driven Development：規格先行
- 通用 handoff doc 範本（含已否決選項欄位）→ 交接產物模板
- 需求交接給 agent 時的額外要求 → Agent 之間的 task handoff
- PM 端的需求撰寫脈絡 → 人人都是產品經理——由淺入深
- 回到全景 → Handoff 專欄首頁