AI項目跨團隊協作：產品技術業務如何不打架

當技術、產品與業務方陷入各自的認知孤島，即使技術指標完美，產品也難逃被拒命運。本文深度剖析AI項目協作特有的三大挑戰與三種典型失敗模式，并給出需求對齊會、周Demo、效果評審三大核心解決方案。

———— / BEGIN / ————

「你們做的這個 AI，完全不是我們要的！」

這是上周業務方在評審會上說的話。

我們辛辛苦苦做了兩個月的 AI 工具，業務方看了一眼就否了。

為什么？

因為從頭到尾，我們都在自己的世界里做產品，沒有真正和業務對齊。

今天聊聊 AI 項目的跨團隊協作，以及如何避免「做出來沒人用」的悲劇。

01

相比傳統軟件項目，AI 項目的跨團隊協作難度更高。

為什么呢。

第一個原因是不確定性太強。傳統軟件你說要一個按鈕我就做一個按鈕，需求是確定的結果是可預期的。AI 項目你說要「智能推薦」，什么叫智能？推薦到什么程度算好？用戶會怎么用？這些都不確定。

不確定性導致大家對「成功」的定義不一樣。技術覺得「模型準確率 85%，很成功」。業務覺得「用戶根本不用，完全失敗」。

第二個原因是認知鴻溝太大。業務方不懂 AI 能做什么、不能做什么。技術方不懂業務流程、用戶痛點。產品方兩邊都懂一點但都不深。

每個人都在用自己的語言說話，說的好像是同一件事其實完全不是。業務說「我要智能客服」，想的是「能解決 80% 的問題」。技術聽到「智能客服」，想的是「做一個能聊天的 Bot」。最后做出來業務發現這個 Bot 啥也不會。

第三個原因是反饋周期太長。傳統軟件開發一個功能做完馬上能看到效果。AI 項目不一樣，模型要訓練、要調參、要評測，可能兩個月才能看到第一版。兩個月后發現方向錯了，改還是不改？改吧又要兩個月，不改吧業務不接受。這種長反饋周期放大了溝通不暢帶來的損失。

02

在經歷了多次失敗后我總結了 AI 項目協作失敗的三種典型模式。

第一種是「瀑布式脫節」。流程是業務提需求、產品寫 PRD、技術開發、兩個月后交付、業務說不對。問題在哪？中間兩個月業務和技術幾乎沒有溝通。業務的需求在變技術的理解有偏差，但沒人知道因為沒有中間檢查點。等到交付的時候差距已經很大了。

第二種是「技術主導偏航」。流程是業務提了個模糊需求、技術自己理解、按自己理解做、做完發現業務不認。問題在哪？技術按自己的理解做沒有和業務確認。技術覺得「我按照最佳實踐來做」，但最佳實踐不一定符合業務場景。最后做出來一個「技術上很先進業務上沒法用」的東西。

第三種是「需求膨脹失控」。流程是業務提需求、開始做、業務加需求、繼續做、業務再加需求、永遠做不完。問題在哪？沒有明確的邊界和優先級。業務不斷提新需求技術疲于奔命，最后啥也沒做好。

03

踩了這些坑之后我們調整了協作方式，效果好了很多。

核心是三個動作。

第一個動作是需求對齊會，先把「成功」定義清楚。

在項目開始前必須開一個需求對齊會。參會人是業務方、產品、技術負責人。

會議目標是對齊幾個問題。

第一個問題是這個項目要解決什么問題。不是「做一個 AI 工具」，而是「解決運營每天花 2 小時找熱點的問題」。問題越具體越容易對齊。

第二個問題是成功的標準是什么。不是「做出來能用就行」，而是運營找熱點的時間從 2 小時降到 30 分鐘、推薦的熱點中有 50% 被采納。可量化可驗證。

第三個問題是什么不在范圍內。明確邊界防止需求膨脹。比如第一期只做 TikTok 不做其他平臺，只做熱點推薦不做腳本生成，不做個性化定制所有人看到的一樣。

第二個動作是周 Demo，快速驗證快速調整。

每周做一次 Demo 演示，哪怕功能還不完整。目的是讓業務方持續看到進展及時發現偏差。

Demo 不需要完美，可以是一個原型、一個技術驗證、一組測試數據。關鍵是讓業務方看到「你們在做什么」，而不是兩個月后才知道。

我們的經驗是在 Demo 環節發現問題調整成本是交付后的十分之一。

第三個動作是效果評審，用數據說話。

功能上線后必須做效果評審。不是「業務方說好就好」，而是用數據驗證。運營使用頻率是多少？推薦內容的采納率是多少？用戶滿意度評分多少？

數據說話避免主觀爭議。如果數據不好一起分析原因，而不是互相甩鍋。

04

除了上面三個大動作還有一些小技巧也很有用。

第一個技巧是用業務語言溝通不用技術術語。

不要說「我們用 RAG 架構，Embedding 用的是 text-embedding-3-large，召回策略是混合檢索」。

要說「用戶問問題時系統會自動從知識庫里找到相關內容，然后 AI 基于這些內容回答」。

用對方能聽懂的語言。技術和業務溝通講業務語言，業務和技術溝通把需求具體化。

第二個技巧是建立共同的文檔。

所有的需求、討論、決策都記錄在一個共同的文檔里。需求變更要記錄、設計決策要記錄、會議結論要記錄。

文檔是「共識」的載體。兩周后有爭議了翻文檔，文檔里寫的就是當時的共識。

第三個技巧是設立「接口人」。

業務方指定一個接口人負責收集和整理需求。技術方指定一個接口人負責同步進展和問題。

所有溝通走接口人避免信息混亂。不要出現「業務 A 跟技術 B 說了一個需求技術 C 不知道」的情況。

第四個技巧是區分「問題」和「方案」。

業務方提需求時經常會直接說方案，「我要一個按鈕點擊后自動生成腳本」。但這是方案不是問題。

要追問你想解決什么問題。可能真正的問題是「寫腳本太花時間」。解決方案可能不是「自動生成」，而是「提供模板」或「輔助編輯」。

先理解問題再討論方案。

05

分享一個我們最近的協作案例。

背景是業務方想要一個「AI 內容審核工具」幫運營審核短視頻腳本。

第一次對齊會我們問了幾個問題。現在審核流程是怎樣的？答案是運營寫完腳本后發給主管審核，主管審核周期 1 到 2 天有時候會漏看。審核主要看什么？答案是看有沒有違規詞、有沒有事實錯誤、語氣是否合適。如果有 AI 幫忙你希望它做到什么程度？答案是能幫我先篩一遍把明顯有問題的標出來，最后還是人來判斷。什么標準算成功？答案是審核時間從 1 到 2 天降到 2 小時，漏審率降低 50%。

然后我們一起定了邊界。做什么包括檢測違規詞、檢測事實錯誤基于知識庫、標記需要關注的內容。不做什么包括不自動通過或拒絕因為最終決策權在人、不做語氣風格判斷因為太主觀、不做視頻審核只做文本。

接下來是每周 Demo。第 1 周演示違規詞檢測，第 2 周演示事實核查功能，第 3 周演示完整流程。每次 Demo 后業務方會反饋「這個違規詞庫不全要加上 XX」「事實核查太慢了能不能快點」「界面上這個按鈕位置不對改一下」。小問題及時改大方向一直對。

上線一個月后的數據是審核時間從 1 到 2 天降到 3 小時達標，漏審率降低 60% 超預期，運營滿意度 4.2 分滿分 5 分。

復盤這次協作比較順利的關鍵是開始前就對齊了「成功標準」，每周 Demo 保證了方向不偏，邊界清晰沒有無限膨脹。

06

AI 項目的成功 30% 靠技術 70% 靠協作。

技術再強做出來的東西沒人用也是失敗。

有效協作的核心是對齊目標讓大家對「成功」的定義一致，持續溝通不要兩個月后才發現方向錯了，用數據說話避免主觀爭議。

如果你也在做 AI 項目希望這些經驗對你有幫助。

做對的事比把事做對更重要。

本文來自公眾號：AI產品鳴哥 作者：鳴老師