當AI能在兩小時內(nèi)跑出可點擊原型，傳統(tǒng)PRD的價值正在被顛覆。本文通過Anthropic、Zapier等公司案例，揭示產(chǎn)品開發(fā)正從'文檔驅(qū)動'轉(zhuǎn)向'驗證驅(qū)動'的范式遷移。

　　———— / BEGIN / ————

　　我們花了兩周寫的PRD，AI兩小時就能跑出一個能點擊的原型——這不是效率問題，是整個產(chǎn)品工作方式的結(jié)構(gòu)性崩塌

　　先說一件我們團隊真實發(fā)生的事

　　三個月前，我們在做一個用戶反饋聚合功能。

　　按照正常流程走：需求調(diào)研、競品分析、寫PRD、評審、排期、開發(fā)、測試、上線。整個周期預(yù)估六周。

　　PRD寫了將近二十頁。需求評審開了兩輪，第二輪因為某個交互邏輯的分歧又推了一周。

　　就在我們爭論”反饋標簽應(yīng)該由用戶自定義還是系統(tǒng)預(yù)設(shè)”的那個下午，我們團隊里一個做過一點點開發(fā)的運營同事，用Claude Code鼓搗了兩個多小時，跑出來一個能點擊的原型。

　　功能不完整，UI很粗糙，但核心流程是通的。

　　他拿著這個原型去問了五個目標用戶。兩小時后，他拿回來一個結(jié)論：用戶根本不在乎標簽是誰定的，他們最想要的是”反饋提交之后能看到處理進度”。

　　這個需求，在我們二十頁的PRD里，只有半句話。

　　那一刻我有點沉默。

　　不是因為”AI要搶走PM的工作”——這個話題我已經(jīng)聽了兩年，早就免疫了。

　　我沉默是因為我意識到：我們花了三周時間在爭論一個用戶根本不在乎的問題。而找到用戶真正在乎的東西，只需要一個粗糙原型加兩小時用戶訪談。

　　PRD沒有錯。排期沒有錯。評審也沒有錯。

　　錯的是：我們用一套為”執(zhí)行速度是瓶頸”而設(shè)計的工作方式，去應(yīng)對一個”執(zhí)行速度已經(jīng)不再是瓶頸”的新世界。

　　這不是個案，是整個行業(yè)正在發(fā)生的事

　　就在上周，Anthropic發(fā)了一篇文章，作者是他們Claude Code的產(chǎn)品主管Cat Wu。

　　她在文章里說，Anthropic的產(chǎn)品團隊已經(jīng)改變了工作方式。具體怎么改的？四句話：

　　用短期沖刺替代長期路線圖。

　　用演示替代文檔。

　　隨每次模型更新去精簡舊功能。

　　只做簡單有效的事，不為AI的局限打補丁。

　　注意，這不是一家初創(chuàng)公司在分享”敏捷開發(fā)的最佳實踐”。

　　這是目前全球增速最快的AI公司之一，在用自己做產(chǎn)品的真實經(jīng)驗，告訴你他們的PM是怎么工作的。Claude Code的年化收入已經(jīng)超過25億美元，他們不是在紙上談兵。

　　不止Anthropic。

　　Zapier全公司89%的員工都在用AI，內(nèi)部部署了超過800個AI Agent。他們的設(shè)計團隊現(xiàn)在怎么做用研？在客戶訪談進行的同時，用Claude實時生成交互原型，讓用戶當場體驗，當場反饋，當場迭代。

　　以前這個流程是：訪談→整理洞察→出設(shè)計稿→評審→開發(fā)原型→再次用研，最短兩到三周。

　　現(xiàn)在是：訪談和驗證同時發(fā)生。

　　這背后有一個關(guān)鍵的結(jié)構(gòu)性變化，我覺得大部分人還沒有真正想清楚：

　　當”想法到原型”的周期從三周壓縮到三小時，產(chǎn)品經(jīng)理的核心工作對象就變了。

　　傳統(tǒng)PM的核心交付物是：需求文檔——開發(fā)可以照著做的那種。

　　這個交付物存在的前提是：開發(fā)是瓶頸，所以要把需求想清楚寫完整，讓開發(fā)能高效執(zhí)行，減少返工。

　　但現(xiàn)在，AI已經(jīng)可以幫你在幾小時內(nèi)跑出一個可以被用戶點擊的版本。執(zhí)行不再是瓶頸了。

　　那瓶頸在哪里？

　　瓶頸在于：你有沒有在正確的時間，問了正確的用戶，驗證了正確的假設(shè)。

　　這個事情，二十頁的PRD幫不了你。

　　需求文檔不是在變輕，而是在變成錯誤的投資

　　我想說一個可能會讓人不舒服的判斷：

　　很多團隊的PRD，本質(zhì)上是一份給”執(zhí)行團隊”看的文件。它的主要價值，是減少溝通成本、對齊理解、明確邊界。

　　這些價值是真實的。但這份文件有一個隱含的前提：你在寫它的時候，你認為自己已經(jīng)知道用戶想要什么了。

　　問題是，你真的知道嗎？

　　在沒有快速驗證工具的時代，這個問題很難回答，所以只能靠經(jīng)驗、靠調(diào)研、靠數(shù)據(jù)，然后盡量想清楚。PRD的厚度，某種程度上是對”我認為我想清楚了”的信心背書。

　　但當你可以在兩小時內(nèi)跑出一個原型、然后拿給五個真實用戶點擊的時候——你還需要先寫二十頁來證明你”想清楚了”嗎？

　　還是說，那二十頁，其實是一種讓自己安心的儀式，而不是真正的驗證？

　　我說這個不是要否定文檔的價值。

　　我在團隊里還是會寫文檔，尤其是涉及復(fù)雜系統(tǒng)邏輯、跨部門協(xié)作、合規(guī)要求的時候，文檔不可替代。

　　我想說的是：文檔的位置變了。它不應(yīng)該出現(xiàn)在”驗證之前”，而應(yīng)該出現(xiàn)在”驗證之后”。

　　先跑一個原型，拿到真實用戶的反饋，確認方向是對的——然后再寫文檔，把這個已經(jīng)被驗證過的方向說清楚。

　　這時候的文檔，寫起來其實更快，因為你不需要猜了。

　　這時候的文檔，也更有價值，因為它記錄的不是”我們的假設(shè)”，而是”被驗證過的事實”。

　　那什么能力變得更重要了？

　　說清楚了什么在變輕，要說什么在變重。

　　第一個：構(gòu)建可驗證假設(shè)的能力，而不是寫完整需求的能力。

　　可驗證假設(shè)是什么？是一句可以被真實數(shù)據(jù)證偽的話。

　　比如：

　　“用戶在反饋提交后會主動返回查看處理進度，且查看頻率超過每兩天一次”

　　“如果標簽由用戶自定義，標簽使用率會比系統(tǒng)預(yù)設(shè)高30%以上”

　　這兩句話，都可以在原型驗證階段被檢驗。

　　而不是：”用戶希望有靈活的標簽管理系統(tǒng)，支持自定義分類和批量操作，同時提供系統(tǒng)推薦標簽供快速選擇……”

　　后者是需求描述，不是假設(shè)。你無法從它里面提煉出一個可以被驗證的真?zhèn)闻袛唷?/p>

　　構(gòu)建假設(shè)的密度，決定了你能以多快的速度逼近真相。

　　第二個：知道什么時候停止迭代的判斷力。

　　AI讓原型變得極其便宜。便宜到什么程度？Rakuten的工程師讓Claude Code在一個有1250萬行代碼的巨型倉庫里自主工作了7個小時，一次性完成了一項復(fù)雜任務(wù)，數(shù)值精度與參考方法匹配99.9%。

　　這意味著”再改一版看看”的成本極低。

　　但低成本迭代會帶來一個新問題：你可能永遠在改，永遠在優(yōu)化，但永遠沒有到達”足夠好了，可以上線”的那個判斷。

　　這個判斷，AI給不了你。

　　什么時候停，為什么停，停在哪里，這是只有人能做的決策。

　　它需要你對用戶、對業(yè)務(wù)、對資源約束有綜合理解——不是數(shù)據(jù)分析，是判斷。這是PM在AI時代最不可替代的事情之一。

　　第三個：能直接跑起來一個最小可驗證版本。

　　這個能力以前不是PM的標配，但我認為接下來會變成。

　　不是說PM要學(xué)會寫代碼。而是說PM要能用Claude Code、Cursor這類工具，在不需要排開發(fā)人員的情況下，把一個核心流程跑起來，讓真實用戶能點擊。

　　Anthropic自己法務(wù)團隊的一個沒有編程經(jīng)驗的律師，用Claude構(gòu)建了一套合同分流工具，把原來2到3天的營銷內(nèi)容審查周期縮短到24小時。她沒有寫一行代碼，但她解決了一個真實的業(yè)務(wù)問題，而且不需要排工程師的開發(fā)隊列。

　　這件事之所以值得被一個產(chǎn)品經(jīng)理認真對待，不是因為”PM也能寫代碼了”，而是因為：

　　當你可以自己把想法跑起來，你和用戶之間的反饋循環(huán)，就不再需要經(jīng)過開發(fā)這個中間層了。

　　這改變的不是工作量，是你獲取真實信息的速度。

　　但有一件事，我需要說清楚

　　Anthropic工程師說過一句話，我覺得是這個時代關(guān)于AI能力判斷最誠實的一句話：

　　“我主要在我知道答案應(yīng)該是什么樣子的時候才使用AI。這種判斷力是我通過’笨辦法’積累出來的?！?/p>

　　這句話翻譯成產(chǎn)品語言是：AI放大的是你已有的判斷力，不是憑空創(chuàng)造判斷力。

　　你越清楚一個好產(chǎn)品應(yīng)該是什么樣，你就越能用好AI。

　　反過來，如果你對用戶沒有真實的理解，對業(yè)務(wù)邏輯沒有清晰的認知，對什么是”好”沒有標準——AI給你一個粗糙的原型，你也看不出問題在哪里，更不知道下一步該往哪里改。

　　所以這不是一篇”AI讓PM更輕松”的文章。

　　AI讓行動變得更便宜了，但判斷變得更貴了。

　　以前你寫完P(guān)RD，還有兩周的開發(fā)周期來做緩沖，有時間發(fā)現(xiàn)錯誤、糾正方向。

　　現(xiàn)在原型兩小時就能跑起來，你有沒有判斷力，立刻就會被放大——如果判斷力強，驗證速度驚人；如果判斷力弱，你會以驚人的速度驗證錯誤的東西。

　　回到那個下午

　　我們的運營同事拿著那個粗糙原型回來的時候，有個開發(fā)問他：這東西你花了多長時間？

　　他說：兩小時多一點。

　　然后開發(fā)沉默了一下，說：那咱們是不是可以先把這個給用戶用著？

　　這句話很重要。不是因為它說明了AI多厲害，而是因為它說明了一件事：

　　這個團隊里，第一次有人在開發(fā)介入之前就獲得了真實用戶的驗證。

　　這在以前是不可能發(fā)生的。因為在以前，”能讓用戶點擊的東西”需要工程師來做，而工程師的時間從來都是稀缺資源。

　　現(xiàn)在不是了。

　　這個變化如果只停留在”工作效率提升”的層面，它是一個工具層面的改變。

　　但如果你認真思考它的含義——誰能在最快的時間內(nèi)，用最真實的方式，獲得用戶的真實反饋——它是一個關(guān)于整個產(chǎn)品工作方式的結(jié)構(gòu)性重塑。

　　你，一個產(chǎn)品經(jīng)理，站在這個變化里，會怎么選？

　　一個可能讓你不舒服的結(jié)尾

　　我不會說”趕快學(xué)Claude Code，不然就被淘汰”。這種話說起來容易，但它沒有告訴你真正值得思考的問題。

　　真正值得思考的問題是：

　　你上次在沒有寫任何文檔的情況下，直接把一個想法給到真實用戶驗證，是什么時候？

　　如果你的答案是”很久了”，或者”好像沒有”——不是因為你不想，是因為以前的工具成本不允許你這么做。

　　現(xiàn)在允許了。

　　你的工作方式，準備好跟上了嗎？

　　歡迎在評論區(qū)告訴我：你們團隊現(xiàn)在從想法到能讓用戶點擊的原型，最快需要多長時間？

　　本文來自作者：吳知