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

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

一、確定項目目標及范圍

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

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

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

B 端产品经理如何快速成长？

产品与业务架构主要是将整个业务工作流进行分层，梳理，然后抽象出一个个需求，将业务需求与产品合情合理的映射起来，最终使业务数据在产品中流动，执行，记录，使用。

查看详情 >

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

二、快速構(gòu)建并迭代這個產(chǎn)品

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

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

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

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

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

• 建立標準
• 測試集的覆蓋要求 & 數(shù)量要求
• 自造數(shù)據(jù)/真實數(shù)據(jù)的權(quán)重比

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

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

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

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

三、內(nèi)部評估

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

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

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

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

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

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

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

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

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

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