AI總把PRD寫崩？資深PM都在交付前的30分鐘做這5件事
整理版優先睇
PM喺AI寫code前審task，避免PRD翻譯走樣，呢5個步驟要喺30分鐘內做完
呢篇文章係由有經驗嘅PM分享，佢哋發現好多時PRD寫完交俾AI Agent IDE之後，code係行到，但業務logic錯曬。問題唔係PRD唔夠清楚，而係AI會將PRD翻譯成技術方案、task清單，再變成code，中間最容易漏審嘅係task清單。PM唔使睇code，但一定要審task。作者引用咗SDD（Spec-Driven Development）嘅做法，例如GitHub Spec Kit嘅流程：/.specify → /.plan → /.tasks → /.implement，強調先諗清楚先寫code。佢整理咗5個步驟，俾PM喺交完PRD後、AI寫code前嘅30分鐘入面做，確保業務冇走樣。
整體結論係：PM嘅角色要由淨係寫清楚「要做乜」，擴展到審清楚「AI理解成乜」。呢5個步驟包括拆task、掃紅燈詞、逐條task指向PRD、反查PRD有冇漏接，同埋最後做交叉對賬。咁樣可以慳返好多後期改嘢嘅時間，而且係PM自己可以控制嘅資產。
- PM唔使審code，但一定要審task，因為AI翻譯鏈路最易出錯喺task清單。
- 先叫AI拆task，每條task要滿足細改動、有驗收、指向PRD、單一模塊、可回滾五個條件。
- 用「順便、同時、一齊、兼顧、支持」五個紅燈詞檢查AI有冇擴範圍，確保「本期唔做」真係冇做。
- 逐條task反向對應PRD，揾唔到對應就係AI腦補或PRD漏寫，要處理先做。
- 最後做交叉對賬，只盯業務鐵律、狀態邊界、順序依賴三類問題，其他交俾工程師。
AI翻譯鏈路嘅陷阱：PRD點樣變咗走樣嘅code
好多PM將PRD交俾Agent IDE後，發現code行到，但業務logic錯曬，例如PRD寫咗「本期唔做導出」，AI順手留咗導出入口；或者PRD寫「邀請7日過期」，AI只做咗邀請成功。呢啲情況唔一定係PRD唔夠清楚，而係AI翻譯鏈路出事。
AI會做三次翻譯：PRD → 技術方案 → task清單 → code
code層有review，技術方案有工程師睇，但最容易漏審嘅係中間嗰份task清單。PM唔審code，必須審task，呢個係SDD嘅經典做法。
第1同第2件事：拆task同掃紅燈詞
- 1 第1件事：先拆task，唔好急住寫code。叫AI基於PRD拆成5-10條可獨立完成嘅task，每條包括：做啲乜、對應PRD邊段、可驗收標誌。唔好寫code。合格task要滿足5點：改動少過200行、有測試或驗收方式、能回引PRD要求、只改一個模塊或鏈路、失敗時可單獨回滾。如果AI將接口、頁面、郵件、權限、異常、審計日誌揉埋一條task，直接叫佢重拆。
- 2 第2件事：掃5個紅燈詞——「順便、同時、一齊、兼顧、支持」。呢啲詞係AI擴範圍嘅信號，例如「順便支持後續導出」可能撞正PRD嘅「本期唔做」。動作：標出PRD所有「唔做、暫唔、本期唔」，整成NON-GOALS清單，反查task有冇掂到呢啲邊界。
合格task至少滿足5點：改動量小於200行、有測試或驗收方式、能回引PRD要求、只改一個模塊或鏈路、失敗時能單獨回滾
紅燈詞包括『順便、同時、一齊、兼顧、支持』，係AI擴範圍嘅信號
第3同第4件事：雙向核查task同PRD
第3件事：逐條task都要指返PRD。問一條問題：呢條task嚟自PRD邊段？答得到就過，答唔到先唔好做。得兩種情況：AI腦補，直接砍咗；PRD漏寫，補返先再判斷。可以叫AI自己暴露問題：「請為每條task補充字段：對應PRD條款。揾唔到對應條款嘅task，請單獨列出，唔好自行補充理由。」
task嚟自PRD邊段？答唔到就先唔好做
第4件事：反過嚟查PRD有冇被漏接。重點睇三類：
- 異常同邊界：邀請7日過期、撤回邀請、寫審計日誌、審批失敗後狀態回滾。
- 隱性業務規則：免費版最多3個成員、管理員唔可以被普通成員邀請、審批通過後唔可以改關鍵字段。
- NON-GOALS：PRD明確唔做嘅，要確認task真係冇做，尤其小心大task入面嘅隱性溢出。
呢步最值錢，因為業務直覺係PM自己嘅資產，你唔審就冇人審
第5件事同總結：交叉對賬同PM新角色
第5件事：叫AI做一次一致性檢查，將PRD、技術方案、task清單放埋一齊，只列問題：
- 1 業務鐵律有冇俾task漏咗？
- 2 狀態、異常、邊界有冇task承接？
- 3 task之間有冇順序依賴衝突？
- 4 task之間有冇互相矛盾？
PM淨係盯三類：業務鐵律、狀態邊界、順序依賴。命名規範、目錄結構、依賴版本呢啲交俾工程師。
PRD交咗唔代表PM收工。AI寫code之前嗰30分鐘，先至係項目最易走樣嘅地方。
好多PM將PRD交俾Agent IDE之後，會遇到尷尬嘅結果：
Code行得鬱，頁面出咗嚟，但係業務就係唔啱。
• PRD寫咗「本期唔做導出」，AI順手留咗導出入口 • PRD寫咗「邀請7日過期」，AI淨係做咗邀請成功 • PRD寫咗「必須寫審計日誌」，AI做咗普通狀態更新
呢個時候最易誤判成：係咪PRD仲唔夠清楚？唔一定。
問題通常係出喺PRD同code之間嘅翻譯鏈路。AI會做三次翻譯：
PRD → 技術方案 → task清單 → 代碼Code層有review，技術方案有工程師。容易漏審嘅，係中間嗰份task清單。
PM唔審code，一定要審task。
呢個唔係個人經驗，係SDD嘅經典做法
Spec-Driven Development 嘅核心，係將「先諗清楚再寫code」工程化。
GitHub Spec Kit 嘅官方流程係：
/.specify → /.plan → /.tasks → /.implement順序好關鍵：先spec，再plan，再tasks，最後先implement。Kiro 都類似：需求、設計、任務分開管理；執行前先分析task同依賴。
Spec Kit、OpenSpec 對產品經理嚟講，如果組織冇主動推，個人要用起上嚟嘅門檻都仲有啲高。我哋將佢嘅工作原理攞出嚟拆開睇下：
Coding開始前嘅30分鐘唔係儀式感，而係將SDD最關鍵嘅一步攞返嚟：
喺AI寫code之前，先審嚇佢準備點做。
第1件事：先拆task，唔好急住寫code
唔好對AI講「幫我實現一下」。先俾佢輸出task：
請根據呢份PRD，拆成5-10條可以獨立完成嘅task。每條包含：要做啲咩、對應PRD邊一段、可驗收標誌。唔好寫code。
合格task至少要滿足5點：
1. 改動量小於200行2. 有測試或驗收方式3. 能回引PRD要求4. 只改一個模塊或鏈路5. 失敗時能單獨回滾如果AI將「接口、頁面、郵件、權限、異常、審計日誌」揉埋一條task，直接重拆。嗰個唔係task，係需求團塊。
第2件事：掃5個紅燈詞
拎到task清單之後，先搜5個詞：
• 順便 • 同時 • 一起 • 兼顧 • 支持
呢啲詞經常用嚟係AI擴範圍嘅信號。「順便支持後續導出」聽落體貼，但導出可能就係PRD裏面寫咗「本期唔做」嘅嘢。
動作：
1. 標出PRD裏面所有「唔做、暫唔做、本期唔做」 2. 做成 NON-GOALS清單3. 反查task有冇碰到呢啲邊界
邊界一旦入咗task，後面就會越做越真。
第3件事：每條task都要指返PRD
逐條睇task，淨係問一個問題：
呢條task嚟自PRD邊一段？
答得到，通過。答唔到，暫時唔好做。得兩種情況：AI腦補，斬咗佢；PRD漏寫，補返之後再判斷。
可以俾AI自己暴露問題：
請為每條task補充字段：對應PRD條款。揾唔到對應條款嘅task，請單獨列出，唔好自行補充理由。
第4件事：反轉頭查PRD有冇被漏接
第3步係task → PRD，呢一步反轉頭做PRD → task。
重點睇三類：
1. 異常同邊界
邀請7日過期、撤回邀請寫審計日誌、審批失敗後狀態回滾。
2. 隱性業務規則
免費版最多3個成員、管理員唔可以被普通成員邀請、審批通過後唔可以改關鍵字段。
3. NON-GOALS
PRD裏面明確唔做嘅，要確認task裏面真係冇做，尤其小心大task裏面嘅隱性溢出。
呢一步最值錢，因為業務直覺係PM自己嘅資產。你唔審，就冇人審。
第5件事：俾AI做一次交叉對賬
最後，俾AI做一致性檢查：
請將PRD、技術方案、task清單擺埋一齊檢查，淨係列出問題：
1. 業務鐵律有冇被task漏咗 2. 狀態、異常、邊界有冇task承接 3. task之間有冇順序依賴衝突 4. task之間有冇互相矛盾
PM淨係盯三類：業務鐵律、狀態邊界、順序依賴。命名規範、目錄結構、依賴版本，可以交俾工程師。
最後記住一句話
以前，PM主要寫清楚「要做啲咩」。
而家，PM仲要審清楚「AI將佢理解成咗啲咩」。
下次交付PRD之後，唔好即刻俾AI寫code。先俾佢拆task，然後用呢張Checklist過一次。
PM唔審code，一定要審task。
PRD交完不等於PM下班。AI寫代碼前那30分鐘，才是項目最容易跑偏的地方。
很多PM把PRD交給Agent IDE後，會遇到尷尬結果：
代碼能跑，頁面出來了，但業務就是不對。
• PRD寫了"本期不做導出"，AI順手留了導出入口 • PRD寫了"邀請7天過期"，AI只做了邀請成功 • PRD寫了"必須寫審計日誌"，AI做成了普通狀態更新
這時最容易誤判成：是不是PRD還不夠清楚？不一定。
問題往往出在PRD到代碼之間的翻譯鏈路。AI會做三次翻譯：
PRD → 技術方案 → task清單 → 代碼代碼層有review，技術方案有工程師。容易漏審的，是中間那份task清單。
PM不審代碼，必須審task。
這不是個人經驗，是SDD的經典做法
Spec-Driven Development 的核心，是把"先想清楚再寫代碼"工程化。
GitHub Spec Kit 的官方流程是：
/.specify → /.plan → /.tasks → /.implement順序很關鍵：先spec，再plan，再tasks，最後才implement。Kiro 也類似：需求、設計、任務分開管理；執行前先分析task和依賴。
Spec Kit、OpenSpec 對產品經理來說，如果組織沒有主動推，個人要用起來的門檻還是有點高的。我們把它的工作原理拿出來拆開看看：
Coding開始前的30分鐘不是儀式感，而是把SDD最關鍵的一步拿回來：
在AI寫代碼前，先審它準備怎麼做。
第1件事：先拆task，別急着寫代碼
不要對AI說"幫我實現一下"。先讓它輸出task：
請基於這份PRD，拆成5-10條可獨立完成的task。每條包含：要做什麼、對應PRD哪一段、可驗收標誌。不要寫代碼。
合格task至少滿足5點：
1. 改動量小於200行2. 有測試或驗收方式3. 能回引PRD要求4. 只改一個模塊或鏈路5. 失敗時能單獨回滾如果AI把"接口、頁面、郵件、權限、異常、審計日誌"揉進一條task，直接重拆。那不是task，是需求團塊。
第2件事：掃5個紅燈詞
拿到task清單後，先搜5個詞：
• 順便 • 同時 • 一起 • 兼顧 • 支持
這些詞經常是AI擴範圍的信號。"順便支持後續導出"聽着體貼，但導出可能正是PRD裏寫了"本期不做"的東西。
動作：
1. 標出PRD裏所有"不做、暫不、本期不" 2. 做成 NON-GOALS清單3. 反查task有沒有碰到這些邊界
邊界一旦進入task，後面就會越做越真。
第3件事：每條task都要指回PRD
逐條看task，只問一個問題：
這條task來自PRD哪一段？
答得上，通過。答不上，先別做。只有兩種：AI腦補，砍掉；PRD漏寫，補回後再判斷。
可以讓AI自己暴露問題：
請為每條task補充字段：對應PRD條款。找不到對應條款的task，請單獨列出，不要自行補充理由。
第4件事：反過來查PRD有沒有被漏接
第3步是task → PRD，這一步反過來做PRD → task。
重點看三類：
1. 異常和邊界
邀請7天過期、撤回邀請寫審計日誌、審批失敗後狀態回滾。
2. 隱性業務規則
免費版最多3個成員、管理員不能被普通成員邀請、審批通過後不能改關鍵字段。
3. NON-GOALS
PRD裏明確不做的，要確認task裏真的沒做，尤其小心大task裏的隱性溢出。
這一步最值錢，因為業務直覺是PM自己的資產。你不審，就沒人審。
第5件事：讓AI做一次交叉對賬
最後，讓AI做一致性檢查：
請把PRD、技術方案、task清單放在一起檢查，只列問題：
1. 業務鐵律有沒有被task漏掉 2. 狀態、異常、邊界有沒有task承接 3. task之間有沒有順序依賴衝突 4. task之間有沒有互相矛盾
PM只盯三類：業務鐵律、狀態邊界、順序依賴。命名規範、目錄結構、依賴版本，可以交給工程師。
最後記住一句話
過去，PM主要寫清楚"要做什麼"。
現在，PM還要審清楚"AI把它理解成了什麼"。
下次交付PRD後，不要立刻讓AI寫代碼。先讓它拆task，然後用這張Checklist過一遍。
PM不審代碼，必須審task。