本文想要分享當引入生成式AI創(chuàng)建新產品或升級原有產品的時候，項目流程會有哪些變化。

當公司想要引入生成式AI創(chuàng)建新產品或升級原有產品的時候，整個項目周期是怎么樣的呢？這其中有哪些地方和原來沒有相比沒有變化，又有哪些地方因為引入生成式AI而需要變化呢？

一、確定項目目標及范圍

第一步依舊需要決定我們要做什么，就像在之前的文章AI時代下，產品經理的“變”與“不變”中分享的觀點，本質上來說，我們就是要讓機器找一個函數，這不是一個技術的問題，而是你要做什么樣的應用，滿足什么樣的需求，解決了一個什么問題。

當我們找到這個函數之后，我們需要思考并明確這個項目的目標，以及什么范圍包含在這個項目中，什么范圍不包含在這個項目中，為什么這個范圍可以幫助我們達成這個項目目標。

在這一步中，作為產品經理，需要過濾需求里的場景是否適合引入AI，如果不適合的話則需要把相應的場景過濾以避免投入產出比產生問題。

例如，當我們想要做一個企業(yè)內部的問答產品，以提高前臺部門應對客戶問題的質量及效率。那我們需要了解前臺有哪些部門，這些部門通常會應對客戶哪些問題（例如新產品介紹，產品方案問題，產品操作疑問等等），他們之前是如何應對的，客戶不滿意的點在哪里等等。最終定義出這個項目的合適的范圍。

二、快速構建并迭代這個產品

這一步就進入了產品細節(jié)設計和研發(fā)流程，大家都會非常熟悉。但是筆者認為，在這個過程中，引入AI后的產品和普通的數字化產品有三個最大的不同

1）引入AI的產品搭建一個初始的版本會相當快，更多的時間是在調整引入模型和我們期待它達到我們要求的GAP。

2）需要更加詳細的定義驗收標準，通常這個驗收標準會包括

• 內容驗收維度的定義
• 什么樣的條件才可以被判定為Good Case
• 最終Good Case占比多少才算驗收通過

3）需要和測試一起定義測試集，確保我們選擇的測試集是可以匹配上我們的驗收標準，通常包括

• 建立標準
• 測試集的覆蓋要求 & 數量要求
• 自造數據/真實數據的權重比

例如，假設在第一步我們的范圍是前臺的項目負責人可以使用這個助手快速的解決客戶在操作產品過程中的疑問。

其實我們會發(fā)現(xiàn)，當我們利用LLM+RAG就可以快速的構建這個產品，可能一周之后產品的雛形已經出來了。而針對這樣的產品和原本的功能產品不同，產品經理需要花比較多的時間和相關的專家去整理這個私有知識庫，并確定這些知識的分類，定義及示例。從而幫助后續(xù)和開發(fā)測試溝通的過程中更快速的互相理解。

其次，產品經理需要定義驗收維度，比如在這個例子中，我們可能會定義正確性、相關性、合規(guī)性等驗收維度。并且需要定義有90%的Good Case才能代表驗收通過。

最后，我們需要從知識的分類、定義維度出發(fā)去建立測試集的標準，并明確測試集的覆蓋和數量的要求。這些步驟都是在一個引入AI產品后必要的步驟，這可以幫助我們在這個過程中和開發(fā)測試人員快速迭代產品最終完成這個產品。

三、內部評估

這一步在傳統(tǒng)數字化產品可能會非常簡單，大致就是上線前讓相關的Stakeholder做一下簡單的驗收。但是在引入AI的項目中，這一步至關重要。

為什么這么說？我們在數據漂移（Data Drift）：AI+產品的隱形風險這篇文章中有提到，AI+產品有個很典型的隱形分享，就是“數據漂移”。這種情況在自造數據比重高的新項目中特別容易發(fā)生。

所以在這個步驟中，我們通常會要求所有的內部團隊人員都參與到這個內部評估中。

例如，假設在第一步我們的范圍是前臺的項目負責人可以使用這個助手快速的解決客戶在操作產品過程中的疑問。那么我們會讓所有的內部團隊成員每人寫指定個數的操作疑問，從而去測試產品給出正確反饋的比例是否依舊符合我們預期。如果不符合我們的預期，則需要重新回到第二步。

這個步驟可以很好的規(guī)避上線前由于自造數據權重較高而產生的風險。很多時候，這個步驟產生出來的Bad Case是一個很好的分析步驟，幫助我們重新調整步驟二中驗收標準定義和數據集定義。

四、產品上線并持續(xù)監(jiān)控

經過充分的內部評估，我們會部署產品上線，并持續(xù)監(jiān)控。

在傳統(tǒng)數字化產品中，我們可能會監(jiān)控這個功能上線有沒有人使用，使用率如何，使用反饋如何，使用過程中產生的Bug需要及時修復。而在引入AI的項目中，除了這些常規(guī)監(jiān)控，我們更需要監(jiān)控真實用戶在使用這個產品的過程中是否依舊存在數據漂移。根據我們的項目經驗，大多數時候，真實用戶的數據和自造數據，無論在問法，復雜度等都有可能發(fā)生變化。

我們需要定期監(jiān)控用戶的反饋，并回到“內部評估”做進一步的分析，是不是針對某一類問題表現(xiàn)的不夠好，甚至需要回到“迭代產品”重新調整某些定義。

總結來說，構建AI+產品的項目是一個高度實驗性的過程，這意味著這類項目需要我們快速的反復嘗試，發(fā)現(xiàn)并修復錯誤。而在整個項目周期中這些“變化”的步驟，都在為這個實驗更好的服務，幫助我們可以更快速，更準確的做出我們想要的AI+產品。