你寫的需求文檔，正在成為公司里最貴的浪費

　　當AI能在兩小時內跑出可點擊原型，傳統PRD的價值正在被顛覆。本文通過Anthropic、Zapier等公司案例，揭示產品開發正從'文檔驅動'轉向'驗證驅動'的范式遷移。

　　———— / BEGIN / ————

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

　　先說一件我們團隊真實發生的事

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

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

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

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

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

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

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

　　那一刻我有點沉默。

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

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

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

　　錯的是：我們用一套為”執行速度是瓶頸”而設計的工作方式，去應對一個”執行速度已經不再是瓶頸”的新世界。

　　這不是個案，是整個行業正在發生的事

　　就在上周，Anthropic發了一篇文章，作者是他們Claude Code的產品主管Cat Wu。

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

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

　　用演示替代文檔。

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

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

　　注意，這不是一家初創公司在分享”敏捷開發的最佳實踐”。

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

　　不止Anthropic。

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

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

　　現在是：訪談和驗證同時發生。

　　這背后有一個關鍵的結構性變化，我覺得大部分人還沒有真正想清楚：

　　當”想法到原型”的周期從三周壓縮到三小時，產品經理的核心工作對象就變了。

　　傳統PM的核心交付物是：需求文檔——開發可以照著做的那種。

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

　　但現在，AI已經可以幫你在幾小時內跑出一個可以被用戶點擊的版本。執行不再是瓶頸了。

　　那瓶頸在哪里？

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

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

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

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

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

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

　　問題是，你真的知道嗎？

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

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

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

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

　　我在團隊里還是會寫文檔，尤其是涉及復雜系統邏輯、跨部門協作、合規要求的時候，文檔不可替代。

　　我想說的是：文檔的位置變了。它不應該出現在”驗證之前”，而應該出現在”驗證之后”。

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

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

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

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

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

　　第一個：構建可驗證假設的能力，而不是寫完整需求的能力。

　　可驗證假設是什么？是一句可以被真實數據證偽的話。

　　比如：

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

　　“如果標簽由用戶自定義，標簽使用率會比系統預設高30%以上”

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

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

　　后者是需求描述，不是假設。你無法從它里面提煉出一個可以被驗證的真偽判斷。

　　構建假設的密度，決定了你能以多快的速度逼近真相。

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

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

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

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

　　這個判斷，AI給不了你。

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

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

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

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

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

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

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

　　當你可以自己把想法跑起來，你和用戶之間的反饋循環，就不再需要經過開發這個中間層了。

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

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

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

　　“我主要在我知道答案應該是什么樣子的時候才使用AI。這種判斷力是我通過’笨辦法’積累出來的。”

　　這句話翻譯成產品語言是：AI放大的是你已有的判斷力，不是憑空創造判斷力。

　　你越清楚一個好產品應該是什么樣，你就越能用好AI。

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

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

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

　　以前你寫完PRD，還有兩周的開發周期來做緩沖，有時間發現錯誤、糾正方向。

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

　　回到那個下午

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

　　他說：兩小時多一點。

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

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

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

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

　　現在不是了。

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

　　但如果你認真思考它的含義——誰能在最快的時間內，用最真實的方式，獲得用戶的真實反饋——它是一個關于整個產品工作方式的結構性重塑。

　　你，一個產品經理，站在這個變化里，會怎么選？

　　一個可能讓你不舒服的結尾

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

　　真正值得思考的問題是：

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

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

　　現在允許了。

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

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

　　本文來自作者：吳知