1.存在的問題

1.研發(fā)產(chǎn)品新人上手難：系統(tǒng)存在知識壁壘，需求背景知識不了解，上線容易出問題，有些壁壘知識只能靠口述,效率極低，上線游鏈路不了解

2.資料散亂:各處資料散亂，雖然可能已經(jīng)沉淀，但隨著人員迭代，可能逐步丟失，造成公司重要資產(chǎn)損失

3.運維時間長:面向運維和研發(fā)需要日常答疑的時間長，占據(jù)開發(fā)的核心工作時間

4.研發(fā)新人對于歷次變更不熟悉，或者系統(tǒng)交接存在風(fēng)險

5.測試新人對于歷次變更看不懂代碼無法把控風(fēng)險

6.產(chǎn)品對于之前的邏輯不熟悉，對于剛接手的系統(tǒng)不了解

8.大模型是否能夠?qū)W會歷次的需求變更?

9.大模型是否能夠寫出業(yè)務(wù)代碼

2.解題思路

基于以上問題，從產(chǎn)研角度思考了對于產(chǎn)研角度對于大模型的日常應(yīng)用的三個階段并進行了實戰(zhàn)

1.日常簡單使用大模型，此處不再贅述，屬于通識

2.大模型結(jié)合系統(tǒng)相關(guān)的知識庫，用于解決日常運維以及產(chǎn)研變更或產(chǎn)研新人對于系統(tǒng)不熟悉的問題

3.大模型結(jié)合系統(tǒng)相關(guān)的知識庫和代碼，用于了解歷史代碼變更點，新需求依據(jù)TRD生成代碼

3.結(jié)果

階段1-成果

略-大模型使用通識

階段2-成果

1.沉淀了適合于大模型基于系統(tǒng)緯度的最佳語料庫模版，大模型會變，工具會變，沉淀的文章是核心資產(chǎn)

2.提問時可給出具體文檔位置，確定來源，快速獲得結(jié)果

3.通過制作一個系統(tǒng)維度的大模型，可以推動研發(fā)產(chǎn)品整理所有的文檔沉淀

4.能夠結(jié)合大模型能力給出衍生答案和具體例子

階段3-成果

1.能夠給出該代碼庫的歷史變更檢索

2.對于新人產(chǎn)品來說，能夠給出該系統(tǒng)的所有變更需求的分析和總結(jié)

3.對于新人研發(fā)來說能夠依據(jù)TRD寫代碼，修改即用

4.對于新人研發(fā)來說能夠詢問大模型獲取類似需求的改動思路和改動點

4.大模型應(yīng)用STAGE-1

此階段不贅述，作為一個基本常識,能夠運用基本的提示詞對大模型提問一些常見的工作問題

5.大模型應(yīng)用STAGE-2

5.1架構(gòu)圖

5.2 實踐案例-DMS技術(shù)專家實踐

5.2.1推薦語料庫

示例文檔添加 擴充文檔作用 細化 給出具體范例

1.【必備】經(jīng)典的需求TRD、ERD整理

ERD文檔： 系統(tǒng)文檔的梳理可以有助于模型快速熟悉系統(tǒng)，并且可以解釋業(yè)務(wù)方面的知識

TRD文檔： 模型可以結(jié)合TRD文檔，可以從技術(shù)角度提出專業(yè)意見，并且對系統(tǒng)/技術(shù)知識進行解答

系統(tǒng)梳理文檔： 可以從數(shù)據(jù)庫設(shè)計/系統(tǒng)設(shè)計/系統(tǒng)業(yè)務(wù)功能分享等角度，對系統(tǒng)文檔進行補充

1.【推薦】研發(fā)注意事項/常見問題:

技術(shù)專家可以結(jié)合常見問題的文檔，給出專業(yè)的解釋，并且結(jié)合歷史案例，預(yù)防事故的發(fā)生。

例如：

（1）歷史出現(xiàn)的白虎線上問題，避免線上問題的再次發(fā)生

（2）研發(fā)/產(chǎn)品整理的Q/A文檔，協(xié)助產(chǎn)研快速定位并且解決問題

1.【必備】DMS系統(tǒng)PRD/DMS需求集

通過PRD文檔，可以幫助模型理解業(yè)務(wù)，并且結(jié)合具體需求，對需求的特定問題進行解答

1.【必備】系統(tǒng)常見的坑合集

通過常見系統(tǒng)問題，例如上線前需要預(yù)熱，redis共用一套風(fēng)險，某些MQ流量大消費可能時常積壓，

5.2.2推薦提示詞(可迭代)

【實踐】1.問題解答：為產(chǎn)品經(jīng)理提供準(zhǔn)確的信息和解答，處理他們關(guān)于門店工單或系統(tǒng)功能的問題，同時解決研發(fā)新人或非本系統(tǒng)研發(fā)人員的疑問。

2.方案指引：當(dāng)研發(fā)人員對系統(tǒng)有疑問時，從系統(tǒng)層面詳細解釋問題，并提供解決方案。當(dāng)產(chǎn)品團隊需要業(yè)務(wù)知識支持時，協(xié)助他們進行解釋，并為門店反饋的工單提供可行的解決方案。

3.系統(tǒng)的詳細介紹：針對任何人提出的系統(tǒng)設(shè)計問題，結(jié)合ERD、TRD等文檔，詳細解釋數(shù)據(jù)庫設(shè)計、系統(tǒng)設(shè)計或業(yè)務(wù)流程設(shè)計，并通過可能的使用場景進行說明。

4.注意事項：在研發(fā)提出注意事項或建議時，結(jié)合研發(fā)注意事項中的問題和案例，以及歷史真實問題，提供建議。當(dāng)產(chǎn)品團隊對某一場景有疑問時，結(jié)合常見問題和運營手冊中的相關(guān)問題，給予專業(yè)回答。

5.2.3范例

6.大模型應(yīng)用STAGE-3

6.1架構(gòu)圖

實現(xiàn)具體方案:通過將歷史需求切割，讓大模型學(xué)會針對于業(yè)務(wù)系統(tǒng)每一個需求是如何做的，就像我們當(dāng)初初入職場時，mentor如何帶領(lǐng)我們逐步做一個需求，另外對大模型補充業(yè)務(wù)知識，讓其真正成為一個熟悉業(yè)務(wù)，并且會寫代碼的Agent，使用模型訓(xùn)練時，使用京東內(nèi)部自研的言犀大模型,能夠保障代碼安全，和召回準(zhǔn)確度

6.2實踐案例

6.2.1歷史變動檢索

現(xiàn)在想要結(jié)合<交易歷史需求變更>知識庫 拼拼融合華冠改了什么 給出改動代碼

6.2.2歷史變更分析

現(xiàn)在想要結(jié)合<交易歷史需求變更>知識庫 總結(jié)拼拼融合華冠改動點 我是產(chǎn)品 看不懂代碼 給出

6.2.2依據(jù)TRD寫代碼

類的全路徑com.jd.xstore.settlement.center.biz.service.CommonSettlementFacadeSaasImpl#calculateTotalPrice

改造點PRD：

1）支持POS傳入是否使用京豆，

2）查詢積理會員系統(tǒng)獲取京豆總數(shù)量和本單抵扣數(shù)量、轉(zhuǎn)變比例，

3）根據(jù)京豆總數(shù)量和本單抵扣數(shù)量、轉(zhuǎn)變比例，計算可抵扣金額，京豆總余（不使用也返回）

4）進行各資產(chǎn)試算

5）結(jié)果返回京豆可抵扣金額，本次抵扣數(shù)量，京豆總刷量、京豆總余額（不使用也返回）。

6.2.3做過的類似的需求設(shè)計

新增加一種SendPayParam 需要改動哪些 類型需求支持

7.未來優(yōu)化點

1.比較依賴需求變動的coding庫，如果新增需求較少，寫出來的代碼可能比較薄弱

2.強依賴與新增知識庫和代碼庫的召回能力，依賴于合并記錄和需求的綁定關(guān)系，如果未來對此進行強要求可以提升代碼準(zhǔn)確率