AI工具雖已深度融入職場，卻在產(chǎn)品經(jīng)理與研發(fā)之間制造了新的協(xié)作摩擦。本文從一線實戰(zhàn)經(jīng)驗出發(fā)，揭示AI時代特有的'半懂不懂'認知墻現(xiàn)象，提出重構協(xié)作標尺的三大維度，供大家參考。

———— / BEGIN / ————

距離生成式AI火遍職場已經(jīng)三年，產(chǎn)品經(jīng)理用AI寫需求文檔、畫產(chǎn)品原型，研發(fā)人員靠AI敲代碼、搭演示版本，早成了職場日常。

我們曾滿心期待，AI能填平產(chǎn)品經(jīng)理和研發(fā)之間那道“你不懂技術，我不懂業(yè)務”的鴻溝，讓跨團隊協(xié)作順風順水。可現(xiàn)實卻是，協(xié)作摩擦沒減少，反而因為AI多了新的“掐架由頭”，甚至形成了“各自為戰(zhàn)”的小幫派。

作為帶了近十年產(chǎn)品團隊的老兵，我?guī)е鴪F隊踩了很多AI時代協(xié)作的坑，也摸出了一套能落地、能見效的實戰(zhàn)方法，把產(chǎn)品經(jīng)理和研發(fā)從“互懟冤家”拉回了“共創(chuàng)戰(zhàn)友”。

今天就用一線的真實案例、實打?qū)嵉穆涞貦C制，跟各位同行聊聊，AI時代，產(chǎn)品經(jīng)理和研發(fā)該怎么打破協(xié)作壁壘，讓工具回歸工具，讓協(xié)作回歸本質(zhì)。

舊平衡徹底崩了：AI抹平信息差，卻造了新的“半懂不懂”認知墻

在AI沒普及的時候，產(chǎn)品經(jīng)理和研發(fā)的協(xié)作邏輯其實特別簡單，甚至可以說“靠信息差分工”。

產(chǎn)品經(jīng)理不懂代碼、不懂架構，所以我們只聚焦一件事：把“為什么要做”講透，搞清楚用戶要什么、業(yè)務價值在哪、需求的核心痛點是什么；

研發(fā)人員不懂用戶調(diào)研、不懂業(yè)務場景，所以他們也只聚焦一件事：把“該怎么做”落地，算清技術難度、開發(fā)周期、成本投入。

那會兒就算有摩擦，大多是“隔行如隔山”的溝通問題，邊界清晰，吵完了該干嘛干嘛。

但AI一來，直接打碎了這套運行了十幾年的平衡，問題也從“不懂”變成了更棘手的“我以為我懂”。

去年底我們團隊啟動了智能周報生成工具的項目，這事讓我徹底看清了新的協(xié)作矛盾。

按傳統(tǒng)流程，本該是產(chǎn)品經(jīng)理先寫需求文檔，研發(fā)再做架構設計。

結果這邊研發(fā)小哥用AI編程工具Cursor，吭哧兩天就搭出了一個能跑的演示版本，能自動抓取數(shù)據(jù)生成周報；那邊產(chǎn)品經(jīng)理也沒閑著，讓ChatGPT生成了一份20頁的需求文檔，邏輯看著密不透風，里面寫滿了業(yè)務場景的細節(jié)，比如部門數(shù)據(jù)拆解、周報模板自定義、跨崗數(shù)據(jù)聯(lián)動。

等到評審會把倆東西擺一起，倆人都懵了，接著就吵起來了。

研發(fā)說：“你這需求文檔就是紙上談兵，我這架構根本撐不起這么多自定義功能，硬做的話算力成本高到離譜，而且系統(tǒng)會卡死?！?/p>

產(chǎn)品經(jīng)理也委屈：“你這演示版本就是個技術殼子，用戶要的是能適配各部門的周報，不是單純抓數(shù)據(jù)堆文字，根本沒法用?！?/p>

事后我?guī)е鴤z人復盤，問題根本不是誰對誰錯，而是AI帶來的“半桶水”認知錯位：AI讓產(chǎn)品經(jīng)理能看懂研發(fā)的架構圖，卻不懂架構落地的隱性成本、算力限制這些技術細節(jié)；也讓研發(fā)能聊明白產(chǎn)品的業(yè)務場景，卻抓不住用戶的核心痛點、需求的優(yōu)先級排序。

倆人都跨進了對方的領域，卻只摸到了皮毛，結果就是越界指手畫腳，把協(xié)作變成了博弈。

這就是AI時代產(chǎn)品經(jīng)理和研發(fā)協(xié)作的核心痛點：信息差消失了，但基于專業(yè)深度的協(xié)作共識，還沒建立起來。

先重構協(xié)作標尺：別再糾結“能不能做”，要先算“值不值得做”

我剛?cè)胄凶霎a(chǎn)品經(jīng)理那會，嘴邊上總掛著一句話：“這個功能技術上很簡單吧？”

現(xiàn)在回頭看，這就是典型的外行話，說白了就是想通過低估技術難度，逼著研發(fā)趕進度。

相信不少產(chǎn)品同行都有過這經(jīng)歷，也因此沒少被研發(fā)懟。

但在AI時代，這話徹底失效了。

有Copilot、通義靈碼這些AI工具加持，單純的“寫代碼”早就不是什么稀缺技能了，甚至很多標準化功能，研發(fā)連手都不用動，AI就能直接生成。

既然“技術能不能實現(xiàn)”不再是核心矛盾，那產(chǎn)品經(jīng)理和研發(fā)就必須建立新的協(xié)作標尺——我們不再迷信技術難度，而是回歸價值密度，所有需求的討論，都從“能不能做”轉(zhuǎn)向“值不值得做”。

這大半年，我們團隊把這套標尺落地成了三個具體維度，每一個都有真實案例支撐，踩過的坑也都給各位避好了。

維度1：算清ROI，業(yè)務價值必須覆蓋算力成本

以前評估需求，產(chǎn)品經(jīng)理追著研發(fā)問的永遠是“這個功能要做多久？多少人？”；現(xiàn)在研發(fā)會直接反問產(chǎn)品經(jīng)理：“這個功能上線后帶來的收益，能蓋過模型推理、訓練的算力成本嗎？”

這話不是研發(fā)故意“卡脖子”，而是AI時代的客觀規(guī)律。去年我們團隊想做一個7×24小時用戶情緒識別系統(tǒng)，初衷特別好：實時抓取APP里的用戶評論，用大模型分析情緒，自動生成安撫話術，還能給運營團隊推送預警。

產(chǎn)品經(jīng)理做的方案里，寫滿了這個功能能提升用戶體驗、減少投訴率，聽著特別香。

研發(fā)那邊也確認了，技術上完全能實現(xiàn)，甚至還做了個小的測試版本。

但就在立項前，研發(fā)總監(jiān)給我算了一筆明明白白的賬：我們平臺每天大概有10萬條用戶評論，調(diào)用大模型API做情緒識別和話術生成，單條推理成本約0.00011元，光這一項，一年的算力成本就高達40萬元；再加上后期的模型調(diào)優(yōu)、服務器維護，一年成本至少50萬。

而我們預估，這個功能能帶來的用戶留存提升，轉(zhuǎn)化成實際的營收增量，一年撐死也就18萬元。

一筆賬算完，產(chǎn)品經(jīng)理自己都放棄了這個需求。

這件事之后，我給團隊定了死規(guī)矩：所有需求提報前，產(chǎn)品經(jīng)理必須和研發(fā)一起算清三本賬——功能上線后的業(yè)務收益（轉(zhuǎn)化率、留存率、營收提升等，必須量化）、模型推理/訓練的算力成本、數(shù)據(jù)標注/清洗的人工成本。

如果ROI為負，哪怕技術再炫酷、方案再完美，直接打回，連評審的資格都沒有。

AI時代，產(chǎn)品經(jīng)理如果沒有數(shù)據(jù)ROI的敏感度，連需求的決策權都握不住，這不是危言聳聽，是一線的現(xiàn)實。

維度2：先盤數(shù)據(jù)，沒有數(shù)據(jù)的AI就是空中樓閣

做產(chǎn)品的都知道，AI的核心是數(shù)據(jù)，沒有優(yōu)質(zhì)的數(shù)據(jù)，再牛的算法都是白搭。

但很多產(chǎn)品經(jīng)理做AI相關需求時，總?cè)菀紫萑胍粋€誤區(qū)：光顧著設計功能邏輯，卻忽略了“我們有沒有對應的數(shù)據(jù)源”。

傳統(tǒng)的需求評審會，我們聊的是邏輯流程圖、產(chǎn)品原型；現(xiàn)在我們團隊的評審會，第一步永遠是數(shù)據(jù)盤點，沒有數(shù)據(jù)支撐的需求，直接暫停。

去年做個性化推薦改版時，就有一位產(chǎn)品經(jīng)理栽了這個跟頭。

他花了一周時間做方案，在評審會上眉飛色舞講了半小時，核心是“基于用戶的興趣偏好，做千人千面的內(nèi)容分發(fā)”，還放了AI生成的用戶畫像、推薦邏輯圖，看著特別專業(yè)。

結果數(shù)據(jù)挖掘工程師一句話，就讓他啞口無言：“你說的這6個興趣偏好標簽，我們平臺目前只有30%的用戶有數(shù)據(jù)覆蓋，剩下70%的新用戶全是冷啟動，算法根本跑不起來，而且這些標簽的臟數(shù)據(jù)占比高達15%，根本沒法用?！?/p>

更尷尬的是，這位產(chǎn)品經(jīng)理壓根沒提前和研發(fā)、數(shù)據(jù)團隊溝通，不知道公司的用戶數(shù)據(jù)現(xiàn)狀。

這場評審會最后成了“大型社死現(xiàn)場”，也讓我們意識到，產(chǎn)品經(jīng)理必須從“功能設計師”轉(zhuǎn)向“數(shù)據(jù)資產(chǎn)管理者”。

之后我們建立了數(shù)據(jù)資產(chǎn)前置評審機制，要求產(chǎn)品經(jīng)理提需求前，必須和研發(fā)、數(shù)據(jù)團隊一起確認三件事：

1. 目標數(shù)據(jù)是否存在，有沒有可調(diào)用的數(shù)據(jù)源；

2. 數(shù)據(jù)清洗度是否達標，臟數(shù)據(jù)占比不能超過5%；

3. 如果需要新標注數(shù)據(jù)，標注成本和周期是否可控。

比如今年初我們做的用戶分層運營工具，產(chǎn)品經(jīng)理提前兩周就和研發(fā)、數(shù)據(jù)團隊盤數(shù)據(jù)：用戶的行為數(shù)據(jù)覆蓋92%，消費、興趣標簽的臟數(shù)據(jù)占比僅3%，新增的2個標簽標注成本約1.2萬元，遠低于功能上線后預估的20萬營收增量。因為前期數(shù)據(jù)盤得透，這個需求從開發(fā)到上線只用了3周，而且零返工，這就是數(shù)據(jù)前置的價值。

維度3：看懂架構圖，用技術的語言聊業(yè)務，這是產(chǎn)品經(jīng)理的新基本功

我見過不少非技術背景的產(chǎn)品經(jīng)理，總把“我懂用戶就夠了”掛在嘴邊，覺得研發(fā)的架構圖、技術邏輯都是天書，沒必要看。但在AI時代，如果你看不懂架構圖，連和研發(fā)“吵到點子上”都做不到，更別說高效協(xié)作了。

華為云的一位AI專家曾聊過一個觀點：技術架構圖是產(chǎn)品經(jīng)理和研發(fā)之間的溝通貨幣。

這話我深以為然。

今年年初，我給團隊定了一個硬要求：

• 所有高級產(chǎn)品經(jīng)理必須能看懂技術架構圖，甚至能參與繪制；

• 初級產(chǎn)品經(jīng)理至少要能看懂核心的技術邏輯層，搞清楚需求和技術實現(xiàn)的關聯(lián)。

我們還梳理了一套分層溝通機制，把技術架構拆成三層，給產(chǎn)品經(jīng)理定了不同的掌握要求，不用懂太深，但必須懂關鍵：

• 基礎層（算力/存儲）：不用記GPU型號、存儲協(xié)議，但要明白算力擴容需要2周左右的周期、存儲成本按TB計費，知道這些，就能在做需求時合理規(guī)劃時間和成本；

• 技術邏輯層（模型訓練/推理引擎）：這是產(chǎn)品經(jīng)理必須吃透的核心層，要能參與討論，判斷一個需求是“改模型參數(shù)就能實現(xiàn)”，還是“需要重新調(diào)業(yè)務規(guī)則”，甚至是“要重新訓練小模型”；

• 應用層（用戶功能）：這是產(chǎn)品經(jīng)理的傳統(tǒng)陣地，但設計時要給模型迭代預留空間，比如按鈕的布局、功能的入口，要能適配后續(xù)模型升級后的新功能。

之前做用戶行為分析系統(tǒng)升級時，這套機制立了大功，還避免了一次上線事故。

當時研發(fā)為了節(jié)省成本，打算復用兩年前的用戶行為分析模型，說能省不少模型訓練的時間和錢。

結果負責的產(chǎn)品經(jīng)理當場就提出了質(zhì)疑：“我查了去年的技術數(shù)據(jù)，這個模型對我們今年新推出的企服業(yè)務線，用戶行為識別準確率只有65%，而我們的業(yè)務要求準確率不低于90%，上線后肯定會出現(xiàn)數(shù)據(jù)分析偏差，導致運營策略誤判，反而會流失核心用戶。”

這話一出，研發(fā)團隊當場就服了，趕緊調(diào)整方案，重新訓練了適配新業(yè)務的小模型。

這位產(chǎn)品經(jīng)理不是技術出身，就是靠著看懂架構圖、吃透技術數(shù)據(jù)，贏得了研發(fā)的尊重。

說到底，產(chǎn)品經(jīng)理看懂架構圖，不是為了“裝技術大佬”，而是為了用研發(fā)能懂的語言，聊清楚業(yè)務的核心訴求，讓協(xié)作更高效。

落地新的協(xié)作范式：從“流水線開發(fā)”到“種植園共創(chuàng)”，讓矛盾變合力

傳統(tǒng)的產(chǎn)品開發(fā)，像一條標準化的流水線：產(chǎn)品經(jīng)理出需求文檔→研發(fā)做架構開發(fā)→測試做功能驗證→上線，一步一步線性推進，出了問題就互相甩鍋，產(chǎn)品怪研發(fā)做的不對，研發(fā)怪產(chǎn)品需求改來改去。

但在AI時代，這套流水線模式徹底不適用了。

AI的開發(fā)特性是“不可精確控制”，你沒法像要求研發(fā)寫固定代碼那樣，要求AI生成完全符合預期的結果，只能引導、篩選、優(yōu)化。Perplexity的設計總監(jiān)說過，AI時代的開發(fā)是“種植”而非“制造”，這話特別貼切。

這大半年，我們把這套“種植園思維”落地成了兩個核心機制，把產(chǎn)品經(jīng)理和研發(fā)從“流水線的上下游”變成了“同一片園子里的共創(chuàng)者”，團隊的協(xié)作效率直接提上去了，拌嘴的次數(shù)也少了80%。

機制1：創(chuàng)意花園——2-3人微型戰(zhàn)隊，并行探索取代線性執(zhí)行

過去我們做產(chǎn)品，總怕“試錯成本太高”，一個需求做完再做下一個，結果往往陷入“路徑依賴”，做出來的東西未必是用戶想要的。

現(xiàn)在有了AI，試錯成本被降到了最低，我們索性成立了微型戰(zhàn)隊，讓產(chǎn)品經(jīng)理和研發(fā)一對一、二對一組隊，針對同一個業(yè)務目標，用AI輔助并行做出2-3個高保真的演示版本，用數(shù)據(jù)說話，選最優(yōu)的那個。

比如今年3月做用戶注冊流程改版，我們就組了兩個微型戰(zhàn)隊，目標都是“提升注冊轉(zhuǎn)化率、降低注冊耗時”。

• A戰(zhàn)隊：產(chǎn)品經(jīng)理用AI生成極簡注冊的產(chǎn)品原型，還通過AI做了快速的用戶調(diào)研，確定了“手機號一鍵驗證+后續(xù)補全信息”的核心邏輯；研發(fā)則用AI搭后端架構，做接口開發(fā)，3天就做出了可運行的演示版本。

• B戰(zhàn)隊：產(chǎn)品經(jīng)理用AI分析了10家競品的注冊流程，設計了“社交賬號一鍵登錄+微信/支付寶授權補全信息”的邏輯；研發(fā)則用AI優(yōu)化了數(shù)據(jù)同步接口，解決了社交賬號登錄的隱私問題，4天做出了演示版本。

一周后，我們沒開冗長的評審會，而是直接把兩個演示版本放到測試環(huán)境，找了200名真實用戶做測試。

數(shù)據(jù)很直觀：A戰(zhàn)隊的注冊耗時20秒，轉(zhuǎn)化率28%；B戰(zhàn)隊的注冊耗時12秒，轉(zhuǎn)化率35%。

結果一目了然，直接選B戰(zhàn)隊的方案推進開發(fā)，還把A戰(zhàn)隊的“后續(xù)補全信息”邏輯融合了進去。

這種模式下，產(chǎn)品經(jīng)理和研發(fā)不再是“甲方乙方”，而是并肩作戰(zhàn)的伙伴。

產(chǎn)品負責業(yè)務場景和用戶驗證，研發(fā)負責技術可行性和落地，AI則是雙方的效率助手，最終的決策依據(jù)是真實數(shù)據(jù)，而不是誰的話語權大、誰的嗓門高。

試錯的成本低了，做出來的產(chǎn)品也更貼合用戶需求。

機制2：協(xié)同攻堅——產(chǎn)品和研發(fā)共背價值KPI，綁在一條船上

協(xié)作的核心矛盾，很多時候源于“考核目標不一樣”：產(chǎn)品經(jīng)理的KPI是需求交付量、用戶活躍度，研發(fā)的KPI是代碼完成率、系統(tǒng)穩(wěn)定性，結果就是雙方各顧各的，出了問題互相推諉。

今年1月，我們借鑒了航天科技集團一院一部的“協(xié)同攻堅”模式——人家造火箭，設計師和工人共背“火箭發(fā)射成功”的目標，我們做產(chǎn)品，產(chǎn)品經(jīng)理和研發(fā)也該共背價值創(chuàng)造KPI，而不是各自的小KPI。

我們把產(chǎn)品經(jīng)理和研發(fā)綁在同一個項目組，所有項目的考核指標，都從“過程指標”變成了“價值指標”。

比如針對“用戶注冊轉(zhuǎn)化率提升”這個核心目標，考核規(guī)則很清晰：

• 產(chǎn)品經(jīng)理負責：用AI分析用戶注冊流失的原因，設計優(yōu)化方案，做用戶測試驗證；

• 研發(fā)負責：用AI重構注冊流程的后端架構，優(yōu)化接口性能，降低系統(tǒng)卡頓率；

• 考核結果：雙方共享一個KPI——注冊轉(zhuǎn)化率提升10%，團隊一起拿獎金、評優(yōu)秀；沒達標，雙方一起復盤，找問題，不單獨追責。

這套機制運行了半年，我們拿到了一組實打?qū)嵉臄?shù)據(jù)：產(chǎn)品迭代周期縮短了22%，因溝通不暢導致的需求返工率下降了35%，團隊的跨部門協(xié)作滿意度從60分漲到了89分。

更重要的是，團隊的氛圍變了。

以前產(chǎn)品經(jīng)理和研發(fā)見面，聊的都是“你這個功能什么時候做完”“你這個需求根本沒法做”；

現(xiàn)在見面，聊的都是“這個模型的準確率怎么提”“怎么用AI優(yōu)化流程，既能省成本又能提體驗”。

大家不再糾結于“誰比誰更懂”，而是開始琢磨“怎么讓AI更懂我們的產(chǎn)品”，從互相指責的冤家，變成了面對共同問題的戰(zhàn)友。

終局思考：AI是放大鏡，協(xié)作才是產(chǎn)品團隊的核心競爭力

常有剛?cè)胄械漠a(chǎn)品新人問我：“AI這么厲害，能寫需求、能敲代碼、能畫原型，產(chǎn)品經(jīng)理會不會被取代？研發(fā)會不會被取代？”

我的答案始終很明確：只會用AI寫需求文檔的產(chǎn)品經(jīng)理，只會用AI敲代碼的研發(fā)，早晚會失去價值；但能通過AI放大彼此優(yōu)勢，把用戶洞察和技術落地完美結合的團隊，價值會呈指數(shù)級增長。

AI從來都不是產(chǎn)品經(jīng)理和研發(fā)之間的“新幫派”，也不該成為彼此博弈的工具。

它更像一面放大鏡——

• 放大產(chǎn)品經(jīng)理對用戶的敏感度、對業(yè)務的判斷力

• 放大研發(fā)對技術的把控力、對成本的計算力；

但同時，它也會放大團隊的協(xié)作問題，如果產(chǎn)品和研發(fā)不能達成共識，AI只會讓矛盾更突出。

做產(chǎn)品這么多年，我始終堅信一個道理：好產(chǎn)品從來都不是一個人做出來的，也不是一個崗位做出來的，而是產(chǎn)品經(jīng)理、研發(fā)、測試、運營一起共創(chuàng)出來的。

就像航天人造火箭，火箭能成功上天，不是設計師比工人更厲害，也不是工人比設計師更懂行，而是他們都懂，唯有協(xié)作，才是穿越大氣層的唯一燃料。

AI時代，產(chǎn)品經(jīng)理和研發(fā)的協(xié)作，終究要回歸本質(zhì)：放下對“話語權”的執(zhí)念，握緊彼此的手，用產(chǎn)品經(jīng)理的用戶視角、研發(fā)的技術視角，共同定義“什么是真正有價值的產(chǎn)品”。

畢竟，工具再強大，也替代不了人與人之間的同頻與共創(chuàng)，而這，正是產(chǎn)品團隊最核心的競爭力。

（本文由某不愿透露姓名的產(chǎn)品總監(jiān)供稿，經(jīng)AI輔助整理成文，但每一個標點符號都代表著人類的思考。）

本文來自公眾號：嚕嚕貓 作者：嚕嚕貓

想要第一時間了解行業(yè)動態(tài)、面試技巧、商業(yè)知識等等等？加入產(chǎn)品經(jīng)理進化營，跟優(yōu)秀的產(chǎn)品人一起交流成長！