vibe coding 之前不要忘了寫好 PRD
整理版優先睇
vibe coding前寫好PRD，先釐清產品認知，先慢後快更省時
呢篇文章係一個iOS App開發者記錄佢做App嘅過程。佢開頭跟風vibe coding，諗住一句話叫AI生成App，點知出嚟嘅結果係UI亂、bug多，仲只係一個單頁面應用。之後佢改用傳統流程：先寫好PRD，再用Stitch做設計稿，最後先叫Codex寫代碼。佢發現，決定項目質量嘅關鍵，並唔係後面代碼寫得幾好，而係最開始份PRD夠唔夠清楚。
作者認為，vibe coding反而更加需要PRD。因為傳統開發團隊可以邊做邊對齊，但AI唔同，你畀佢一句模糊說話，佢會自動補齊平均答案，結果功能優先級混亂、頁面邏輯唔連貫、商業化路徑缺失。PRD嘅價值就係將你嘅判斷提前寫出嚟。佢分享咗一套寫PRD嘅方法：先講清楚產品一句話定位、再寫用戶場景、明確優先級、要求細節規則、同埋反覆追問。經過呢五步，PRD質量會明顯提升。
除此之外，PRD要覆蓋產品層、功能層、體驗層、商業層、技術層同數據層，先算係一張完整嘅施工藍圖。將PRD畀Stitch同Codex用，可以大幅減少返工，令設計稿同代碼更貼近真實產品。總括嚟講，vibe coding係用低成本快速實現想法，但前提係你真係知道自己想做咩。PRD就係幫你想清楚，所以唔好一開波就叫AI寫代碼，先花半日時間打磨PRD，後面省下嘅時間同焦慮會多好多。
- 一句話讓AI生成App會變成一坨，證明模糊需求只會換嚟平均答案。
- vibe coding更需要PRD，因為AI唔會自動理解你嘅判斷同優先級。
- 寫PRD嘅方法：先講定位，再寫場景，明確做咩唔做咩，補細節規則，反覆追問。
- PRD要覆蓋產品、功能、體驗、商業、技術、數據等層面，先係完整藍圖。
- PRD喺Stitch同Codex中發揮減少返工嘅作用，令設計同代碼更加貼近真實產品。
vibe coding 嘅陷阱：一句話搞唔掂
好多人都話vibe coding好爽，一句話描述需求，AI就幫你寫曬界面同代碼。但作者試過之後發現，生成出嚟嘅東西UI亂、bug多，仲要係個單頁面應用，完全唔合乎心意。
一句話讓AI生成App，結果係一坨
作者後來改用標準流程：先打磨PRD，再用Stitch出設計稿，最後先叫Codex落代碼。佢嘅體會係：決定項目質量嘅唔係後期代碼，而係最開始份PRD夠唔夠清楚。
決定項目質量嘅係PRD
標準流程先寫PRD
寫PRD嘅方法：五步打造高質量文檔
作者總結咗一套方法，唔好畀AI憑空寫PRD，而係好似產品經理咁一步步餵上下文。
五步方法：定位、場景、優先級、細節、追問
- 1 先講清楚產品一句話定位：畀邊個用、咩場景、解決咩問題、點解用戶要用你而唔係競爭對手。
- 2 讓AI先寫用戶場景，唔係功能列表：問用戶咩時候打開、最想見到咩、單手定雙手操作、用十秒定十分鐘。
- 3 明確優先級：做咩同唔做咩。首發版本做咩、明確唔做咩、放後續版本、高風險需求暫時避開。
- 4 要求寫細節規則：默認狀態、首次引導、權限彈出時機、異常處理、用戶失敗時嘅反饋。
- 5 反覆追問：邊界條件、新用戶順暢度、商業化衝突、平台審核規則、有冇可以刪掉嘅複雜功能。
先講定位再寫場景
PRD要覆蓋啲咩？一張完整嘅施工藍圖
作者分享咗佢生成嘅PRD覆蓋嘅層面，唔只係功能列表，而係涵蓋產品由0到1嘅關鍵部分。
- 產品層：產品定位、核心價值、用戶畫像、使用場景、差異化策略。
- 功能層：P0/P1/P2優先級、MVP範圍、路線圖規劃。
- 體驗層：頁面結構、Tab設計、首次啟動流程、關鍵交互細節、UI風格關鍵詞。
- 商業層：免費版能力、訂閲版能力、定價建議、轉化路徑。
- 技術層：平台能力邊界、權限需求、本地存儲策略、審核風險點。
- 數據層：埋點事件、核心指標、留存觀察維度。
唔係功能列表，而係施工藍圖
六層覆蓋：產品、功能、體驗、商業、技術、數據
PRD喺設計同代碼中嘅威力
將PRD畀Stitch後，佢可以理解頁面嘅信息架構、產品氣質、主次層級同用戶核心路徑，設計稿出嚟調整成本低好多。
Stitch理解信息架構
PRD令Stitch理解產品氣質，唔係得個靚字
喺Codex寫代碼時，PRD幫佢確定大方向、模塊邊界、頁面流程同優先級，減少返工。例如首次引導、訂閲頁邏輯、權限時機呢啲問題提前寫清楚，一次生成接近成品嘅概率高好多。
PRD幫Codex減少返工，一次生成更準確
之前講過會寫一個系列嘅文章嚟記錄我做 iOS App 嘅過程，今日先講下我寫 PRD 嘅一啲感受，因為呢個係項目落地嘅第一步。
呢排好多人講 vibe coding：一句話描述需求，AI 幫你寫介面、寫 code、改 bug，效率高到嚇人。
但係一句話真係可以令 AI 寫出完全符合你心意，而且考慮周全冇邏輯漏洞嘅項目咩？
答案一定係唔得。我自己做上一個 App 嘅時候，就有呢種感覺。
之前我試咗一下，同 Codex 講一句話：幫我生成一個 xxx 嘅 App。結果，生成出嚟嘅就係一 pat 嘢，UI 亂七八糟，bug 一大堆，仲係一個單頁面應用。
後來，我決定用標準嘅流程嚟搞掂呢個項目。先完善 PRD，再用 Stitch 出設計稿，然後叫 Codex 寫 code。
返轉頭睇，真正決定項目質素嘅，唔係後面 code 寫得幾好，反而係最開始嗰份 PRD 夠唔夠清楚。
好多人將 vibe coding 理解成少寫文件、直接開波。但係我嘅體驗啱啱相反：
越想令 AI 發揮價值，就越要先將需求講清楚。
如果唔係，AI 只會高速產出一堆睇落完整、但實際方向錯咗嘅嘢。
vibe coding 更需要 PRD
傳統開發入面，需求模糊少少，團隊仲可以邊做邊對齊。
但 AI 唔同，你畀佢一句模糊嘅話，例如做一個靚嘅 App，佢的確可以生成一套頁面，甚至 code 都行得通。
但你會發現：功能優先次序混亂，頁面邏輯唔連貫，商業化路徑缺失，權限申請時機唔合理，文案空泛，體驗細節冇人執生。
因為 AI 默認補齊嘅係平均答案，而產品真正需要嘅，係你嘅判斷。
PRD 嘅價值，就係將呢啲判斷提前寫出嚟。
寫 PRD 嘅方法
好多人叫 AI 寫 PRD，結果似模板拼湊，唔係 AI 唔得，而係輸入嘅方式唔太啱。
我歸納咗一套方法：唔好叫 AI 憑空寫 PRD，而係等佢似產品經理咁，被你一步步餵上下文。
1. 先講清楚產品一句話定位
唔好一開始就話「幫我寫 PRD」。
先話畀 AI 知：呢個係畀邊個用，喺咩場景下用，解決咩問題，點解用戶願意用你，而唔係其他產品。
一句話定位越清楚，成份 PRD 就越有方向感。
2. 叫 AI 先寫用戶場景，唔係功能列表
好多人習慣問呢個 App 應該有咩功能，咁樣得到嘅通常係功能堆砌。
更好嘅問法係：用戶幾時打開佢，最想睇到嘅係咩，係單手操作定雙手操作，使用時間係十秒定係十分鐘。
場景清楚之後，功能自然會出現。
3. 清晰優先次序：做咩，唔做咩
呢步係 AI 最容易忽略，但係最重要嘅一步。
一定要叫 AI 輸出：第一個版本做咩，講清楚唔做咩，邊啲放後續版本，邊啲需求風險太高所以先避開。
呢一步可以極大減低項目失控嘅機會率。
4. 要求佢寫細節規則
真正有價值嘅 PRD，唔係支援某功能。
而係：預設狀態係咩，第一次啟動點樣引導，權限幾時彈出，異常狀態點樣處理，用戶失敗時畀咩回饋。
呢啲規則，後面會直接影響設計稿同 code 嘅實現。
5. 不斷追問，令 PRD 越來越深入
高質素 PRD 好少係一次生成出嚟嘅。
我自己嘅做法係持續追問：有冇漏咗嘅邊界條件，新用戶第一次用係咪順暢，有冇商業化衝突，係咪符合平台審核規則，有冇可以刪除嘅複雜功能，等等。
經過幾輪改進，PRD 質素會明顯提升。
PRD 需要涵蓋啲咩內容
我嗰次生成嘅 PRD，大致上將一個產品由 0 到 1 嘅關鍵部分都寫曬，包括：
產品層
產品定位，核心價值，用戶畫像，使用場景，差異化策略。
功能層
P0 / P1 / P2 優先次序，MVP 範圍，路線圖規劃。
體驗層
頁面結構，Tab 設計，第一次啟動流程，關鍵交互細節，UI 風格關鍵詞。
商業層
免費版能力，訂閲版能力，定價建議，轉化路徑。
技術層
平台能力邊界，權限需求，本地儲存策略，審核風險點。
數據層
埋點事件，核心指標，留存觀察維度。
講白啲，佢唔係一份文件，而係一張施工藍圖。
PRD 喺 Stitch 中發揮嘅作用
好多人用 AI 做設計稿嘅時候，會發現結果幾靚，但內容邏輯對唔上，原因通常係冇結構化輸入。
我將 PRD 畀 Stitch 之後，佢明顯理解到：
頁面唔係孤立嘅，而係有完整資訊架構。
知道產品整體氣質，而唔係淨係做靚圖。
知道主次層級，邊個按鈕最大，邊個資訊最重要。
知道用戶核心路徑，頁面更似真實產品。
所以設計稿出咗之後，調整成本低好多。
PRD 喺 Codex 中發揮嘅作用
呢個 PRD 喺寫 code 嘅時候發揮嘅作用更明顯。
因為 AI 寫 code 最驚三件事：大方向模糊，需求成日變，頁面邏輯唔清。
PRD 啱好解決呢啲事，大方向確定，模塊邊界清晰，頁面流程清楚，優先次序一致，減少返工。
例如首次引導、訂閲頁邏輯、權限時機呢啲問題，提早寫清楚之後，Codex 一次生成接近完成品嘅機會率高好多。
最後
返轉頭睇，PRD 最重要嘅作用到底係咩？
我自己嘅理解係：vibe coding 係用更低嘅成本，將你嘅想法快速實現，而前提係，你真係知道自己想做乜，PRD 就係幫你想清楚呢件事。
所以如果你準備做 App、網站、SaaS，唔好一開始就急住叫 AI 寫 code，先花半日時間，用 Superpowers 呢類工具陪你將 PRD 搞掂出嚟。
你會發現，之後慳返嘅，唔止係時間，仲有大量返工、焦慮，同埋做咗半個月先發現方向唔啱嘅成本。
code 可以重寫，頁面可以重做，但係產品認知模糊，項目就會一直兜路。
所以就算喺 vibe coding 嘅時代，都唔好唔記得先寫好 PRD。
以上，就係呢篇文章所有內容，歡迎畀個 like、推薦、轉發三連，亦歡迎關注我，一個普通嘅創業者。
特別推薦
1. 三個系列文章
系統咁記錄咗我嘅創業週報，同埋喺 Shopify App 開發過程中嘅一啲知識點，歡迎大家睇下。
2. Shopify 開發交流社羣
目前內地 Shopify 開發資料稀缺，基本上冇交流社羣，所以我創建咗一個專注討論 Shopify 開發相關嘅各種技術問題嘅交流圈子。喺呢度你可以得到：
• 學習 Shopify App 開發由入門到上架嘅流程。 • 學習 Shopify 主題開發。 • 同其他 Shopify 開發者諮詢開發遇到嘅問題，交流經驗。 • 同大家一齊交流副業、創業嘅經驗同心得。 • 星主會不定期分享 Shopify 開發 & 建站、web 開發、移動端開發相關嘅私單，有需要嘅同學可以接。
歡迎你嚟加入，我哋知識星球見 🤝
前面說過會寫一個系列的文章來記錄我做 iOS App 的過程，今天先來講講我寫 PRD 的一些感受，因為這是項目落地的第一步。
這段時間很多人在聊 vibe coding：一句話描述需求，AI 幫你寫界面、寫代碼、改 Bug，效率高得驚人。
但是一句話真的能讓 AI 寫出完全符合你的心意，且考慮周到沒有邏輯漏洞的項目嗎？
答案肯定是不能。我自己在做上一個 App 的時候，就有這種感覺。
之前我試了一下，告訴 Codex 一句話：幫我生成一個 xxx 的 App。結果，生成的就是一坨，UI 亂七八糟，bug 一大堆，而且還是一個單頁面應用。
後來，我還是使用了標準的流程來落地的這個項目。先打磨 PRD，再用 Stitch 出設計稿，再讓 Codex 落代碼。
回頭看，真正決定項目質量的，不是後面代碼寫得有多好，反而是最開始那份 PRD 寫得夠不夠清楚。
很多人把 vibe coding 理解成少寫文檔、直接開幹。但我的體驗恰恰相反：
越想讓 AI 發揮價值，越要先把需求講清楚。
否則 AI 只會高速產出一堆看起來完整、實際上方向跑偏的東西。
vibe coding 更需要 PRD
傳統開發裏，需求模糊一點，團隊還能邊做邊對齊。
但 AI 不一樣，你給它一句模糊的話，比如做一個好看的 App，它確實能生成一套頁面，甚至代碼也能跑。
但你會發現：功能優先級混亂，頁面邏輯不連貫，商業化路徑缺失，權限申請時機不合理，文案空泛，體驗細節沒人兜底。
因為 AI 默認補全的是平均答案，而產品真正需要的，是你的判斷。
PRD 的價值，就是把這些判斷提前寫出來。
寫 PRD 的方法
很多人讓 AI 寫 PRD，結果像模板拼接，不是 AI 不行，而是輸入的方式不太對。
我總結了一套方法：不要讓 AI 憑空寫 PRD，而是讓它像產品經理一樣，被你一步步喂上下文。
1. 先講清楚產品一句話定位
不要上來就說幫我寫 PRD。
先告訴 AI：這是給誰用的，在什麼場景下使用，解決什麼問題，為什麼用戶願意用你，而不是別的產品。
一句話定位越清楚，整份 PRD 越有方向感。
2. 讓 AI 先寫用戶場景，不是功能列表
很多人習慣問，這個 App 該有什麼功能，這樣得到的通常是功能堆砌。
更好的問法是：用戶什麼時候打開它，最想看到的是什麼，是單手操作還是雙手操作，使用時長是十秒還是十分鐘。
場景清楚後，功能自然會長出來。
3. 明確優先級：做什麼，不做什麼
這是 AI 最容易忽略，但最重要的一步。
一定讓 AI 輸出：首發版本做什麼，明確不做什麼，哪些放後續版本，哪些需求風險太高先避開。
這一步能極大降低項目失控概率。
4. 要求它寫細節規則
真正有價值的 PRD，不是支持某功能。
而是：默認狀態是什麼，首次啓動怎麼引導，權限什麼時候彈，異常狀態怎麼處理，用戶失敗時給什麼反饋。
這些規則，後面會直接影響設計稿和代碼實現。
5. 反覆追問，讓 PRD 越來越深
高質量 PRD 很少是一輪生成出來的。
我自己的做法是持續追問：有沒有遺漏的邊界條件，新用戶首次使用是否順暢，是否有商業化衝突，是否符合平台審核規則，有沒有可以刪掉的複雜功能。等等。
經過幾輪打磨，PRD 質量會明顯提升。
PRD需要覆蓋哪些內容
我那次生成的 PRD，基本把一個產品從 0 到 1 的關鍵部分都寫到了，包括：
產品層
產品定位，核心價值，用戶畫像，使用場景，差異化策略。
功能層
P0 / P1 / P2 優先級，MVP 範圍，路線圖規劃。
體驗層
頁面結構，Tab 設計，首次啓動流程，關鍵交互細節，UI 風格關鍵詞。
商業層
免費版能力，訂閲版能力，定價建議，轉化路徑。
技術層
平台能力邊界，權限需求，本地存儲策略，審核風險點。
數據層
埋點事件，核心指標，留存觀察維度。
說白了，它不是一份文檔，而是一張施工藍圖。
PRD 在 Stitch 中發揮的作用
很多人用 AI 做設計稿時，會發現結果挺漂亮，但內容邏輯對不上，原因通常是沒有結構化輸入。
我把 PRD 給 Stitch 後，它能明顯理解：
頁面不是孤立的，而是有完整信息架構。
知道產品整體氣質，而不是隻做漂亮圖。
知道主次層級，哪個按鈕最大，哪個信息最重要。
知道用戶核心路徑，頁面更像真實產品。
所以設計稿出來後，調整成本低很多。
PRD 在 Codex 中發揮的作用
這個 PRD 在寫代碼的時候發揮的作用更明顯。
因為 AI 寫代碼最怕三件事：大方向模糊，需求反覆變，頁面邏輯不清。
PRD 剛好解決這些事，大方向確定，模塊邊界清晰，頁面流程明確，優先級一致，減少返工。
例如首次引導、訂閲頁邏輯、權限時機這些問題，提前寫清楚後，Codex 一次生成接近成品的概率會高很多。
最後
回頭看，PRD 最重要的作用到底是什麼？
我自己的理解是：vibe coding 是用更低成本，把你的想法快速實現，而前提是，你真的知道自己想做什麼，PRD 就是在幫你想清楚這件事。
所以如果你準備做 App、網站、SaaS，不要一上來就急着讓 AI 開始寫代碼，先花半天時間，讓 Superpowers 這類工具陪你把 PRD 打磨出來。
你會發現，後面省下來的，不止是時間，還有大量返工、焦慮，以及做了半個月才發現方向不對的成本。
代碼可以重寫，頁面可以重做，但產品認知模糊，項目就會一直繞路。
所以哪怕在 vibe coding 的時代，也別忘了先寫好 PRD。
以上，就是本篇文章所有內容，歡迎點個贊、推薦、轉發三連，也歡迎關注我，一個普通的創業者。
特別推薦
1. 三個系列文章
系統地記錄了我的創業週報，以及在Shopify App開發過程中的一些知識點，歡迎大家查看。
2. Shopify 開發交流社羣
目前國內Shopify開發資料稀缺，基本沒有交流社區，所以我創建了一個專注討論Shopify開發相關的各種技術問題的交流圈子。在這裏你可以獲得：
• 學習Shopify App開發從入門到上架的流程。 • 學習 Shopify 主題開發。 • 和其他Shopify開發者諮詢開發遇到的問題，交流經驗。 • 和大家一起交流副業、創業的經驗和心得。 • 星主會不定期分享Shopify開發&建站、web開發、移動端開發相關的私活，有需要的同學可以接。
歡迎你來加入，我們知識星球見 🤝