产品经理PM还会存在吗 | Codex主管Andrew | 产品流程反转 | 品味 | PRD已死原型当立 | 锚定效应 | 判断力 | 设计流程 | 协作模式 | 失败教训

AI 編程工具 Codex 的爆紅背後，反映的是整個產品工作流的根本反轉。過去十年，軟體產業的底層假設是「實現成本高昂」，因此團隊必須在動手寫代碼前就把所有假設驗證清楚：先做用戶研究、寫詳細需求文檔、做低保真原型、多輪評審，風險預置換掉後才動手開發。儘管行業早已告別瀑布式開發，但這套「預先規劃」的邏輯仍根深蒂固。

而今，AI 把代碼實現的成本壓到了幾乎零。OpenAI 內部時常出現 90 個毫不相關的團隊各自手搓同一功能的情景。這時候，真正稀缺的能力變了：不再是「能否把想法實現出來」，而是「在幾十上百個現成方案中，品味出哪個值得正式投入、哪個應該棄用、哪個該整合進某個更大的功能模組」。這是對審美、系統思維和戰略眼光的綜合考驗。

很多人誤解品味就是介面好不好看。實際上品味分好幾層。表層確實是審美——動效節奏對不對、視覺與語義是否匹配；中層是系統思維——這個功能放進整體產品架構裡合不合適，會不會和別的模組衝突；最深層是方向判斷——當你什麼都能做時，該選擇做什麼，怎樣走到那個目標。正因如此，過去「能不能寫代碼」成了硬門檻，現在「該寫什麼代碼」變成了最難的問題。

這一轉變也改寫了產品團隊的協作方式。傳統的分工（產品經理負責規劃、設計師負責美感、工程師負責實現）已然模糊，但並未消失。Codex 團隊的設計師多數懂代碼、產品經理懂技術，工作內容高度重疊。然而岗位不再由「你做的事從哪開始到哪結束」定義，而是由「你平均把時間花在什麼上」定義。設計師可能花 30% 的時間寫代碼，但平均下來重心仍在設計美感和系統架構。這是融合而非消失。

在規劃策略上，Codex 團隊採取了完全不同的節奏：短期事情（幾週到一個月）要做細節，長期規劃（9 個月以上）只看大方向，任何超過 9 個月的精確計畫都是虛假精確。核心原則是「提前做完所有功能的原型」，等著模型升級。同一個功能的外殼可能保持不變，但因為模型能力差異，用戶體驗可能天差地別——2 月發布的版本成功，同樣的產品若提前到 11 月發布就會失敗，唯一的變數就是這幾個月裡大模型能力的躍升。

講者本人則用 Codex 搭建了自己的工作系統：每天早上一份自動生成的日報，汇總了他加入的幾千個 Slack 頻道中最關鍵的五個問題；五月的一次大版本發布，整個協調基本靠 Codex 在 Notion 裡自動拉取代碼提交和 Slack 更新。這些個人工作流因人而異，但共性需求（如記憶功能）應該沉澱進產品底座，避免每人都重複造輪子。

Codex 最終的願景不是把所有軟體都塞進一個聊天框，而是像水一樣滲透進使用者習慣的所有工具——用表格就不展示代碼、寫代碼就給完整開發環境、自動調用需要的工具、根據任務自適應介面複雜度。這種「工作主機」的定位，跨越了傳統的「開發者工具」邊界。

---