1.存在的問題
1.研發產品新人上手難：系統存在知識壁壘，需求背景知識不瞭解，上線容易出問題，有些壁壘知識只能靠口述,效率極低，上線遊鏈路不瞭解
2.資料散亂:各處資料散亂，雖然可能已經沉澱，但隨着人員迭代，可能逐步丟失，造成公司重要資產損失
3.運維時間長:面向運維和研發需要日常答疑的時間長，佔據開發的核心工作時間
4.研發新人對於歷次變更不熟悉，或者系統交接存在風險
5.測試新人對於歷次變更看不懂代碼無法把控風險
6.產品對於之前的邏輯不熟悉，對於剛接手的系統不瞭解
8.大模型是否能夠學會歷次的需求變更?
9.大模型是否能夠寫出業務代碼
2.解題思路
基於以上問題，從產研角度思考了對於產研角度對於大模型的日常應用的三個階段並進行了實戰
1.日常簡單使用大模型，此處不再贅述，屬於通識
2.大模型結合系統相關的知識庫，用於解決日常運維以及產研變更或產研新人對於系統不熟悉的問題
3.大模型結合系統相關的知識庫和代碼，用於瞭解歷史代碼變更點，新需求依據TRD生成代碼
3.結果
階段1-成果
略-大模型使用通識
階段2-成果
1.沉澱了適合於大模型基於系統緯度的最佳語料庫模版，大模型會變，工具會變，沉澱的文章是核心資產
2.提問時可給出具體文檔位置，確定來源，快速獲得結果
3.通過製作一個系統維度的大模型，可以推動研發產品整理所有的文檔沉澱
4.能夠結合大模型能力給出衍生答案和具體例子
階段3-成果
1.能夠給出該代碼庫的歷史變更檢索
2.對於新人產品來説，能夠給出該系統的所有變更需求的分析和總結
3.對於新人研發來説能夠依據TRD寫代碼，修改即用
4.對於新人研發來説能夠詢問大模型獲取類似需求的改動思路和改動點
4.大模型應用STAGE-1
此階段不贅述，作為一個基本常識,能夠運用基本的提示詞對大模型提問一些常見的工作問題
5.大模型應用STAGE-2
5.1架構圖
5.2 實踐案例-DMS技術專家實踐
5.2.1推薦語料庫
示例文檔添加 擴充文檔作用 細化 給出具體範例
1.【必備】經典的需求TRD、ERD整理
ERD文檔： 系統文檔的梳理可以有助於模型快速熟悉系統，並且可以解釋業務方面的知識
TRD文檔： 模型可以結合TRD文檔，可以從技術角度提出專業意見，並且對系統/技術知識進行解答
系統梳理文檔： 可以從數據庫設計/系統設計/系統業務功能分享等角度，對系統文檔進行補充
1.【推薦】研發注意事項/常見問題:
技術專家可以結合常見問題的文檔，給出專業的解釋，並且結合歷史案例，預防事故的發生。
例如：
（1）歷史出現的白虎線上問題，避免線上問題的再次發生
（2）研發/產品整理的Q/A文檔，協助產研快速定位並且解決問題
1.【必備】DMS系統PRD/DMS需求集
通過PRD文檔，可以幫助模型理解業務，並且結合具體需求，對需求的特定問題進行解答
1.【必備】系統常見的坑合集
通過常見系統問題，例如上線前需要預熱，redis共用一套風險，某些MQ流量大消費可能時常積壓，
5.2.2推薦提示詞(可迭代)
【實踐】1.問題解答：為產品經理提供準確的信息和解答，處理他們關於門店工單或系統功能的問題，同時解決研發新人或非本系統研發人員的疑問。
2.方案指引：當研發人員對系統有疑問時，從系統層面詳細解釋問題，並提供解決方案。當產品團隊需要業務知識支持時，協助他們進行解釋，併為門店反饋的工單提供可行的解決方案。
3.系統的詳細介紹：針對任何人提出的系統設計問題，結合ERD、TRD等文檔，詳細解釋數據庫設計、系統設計或業務流程設計，並通過可能的使用場景進行説明。
4.注意事項：在研發提出注意事項或建議時，結合研發注意事項中的問題和案例，以及歷史真實問題，提供建議。當產品團隊對某一場景有疑問時，結合常見問題和運營手冊中的相關問題，給予專業回答。
5.2.3範例
6.大模型應用STAGE-3
6.1架構圖
實現具體方案:通過將歷史需求切割，讓大模型學會針對於業務系統每一個需求是如何做的，就像我們當初初入職場時，mentor如何帶領我們逐步做一個需求，另外對大模型補充業務知識，讓其真正成為一個熟悉業務，並且會寫代碼的Agent，使用模型訓練時，使用京東內部自研的言犀大模型,能夠保障代碼安全，和召回準確度
6.2實踐案例
6.2.1歷史變動檢索
現在想要結合<交易歷史需求變更>知識庫 拼拼融合華冠改了什麼 給出改動代碼
6.2.2歷史變更分析
現在想要結合<交易歷史需求變更>知識庫 總結拼拼融合華冠改動點 我是產品 看不懂代碼 給出
6.2.2依據TRD寫代碼
類的全路徑com.jd.xstore.settlement.center.biz.service.CommonSettlementFacadeSaasImpl#calculateTotalPrice
改造點PRD：
1）支持POS傳入是否使用京豆，
2）查詢積理會員系統獲取京豆總數量和本單抵扣數量、轉變比例，
3）根據京豆總數量和本單抵扣數量、轉變比例，計算可抵扣金額，京豆總餘（不使用也返回）
4）進行各資產試算
5）結果返回京豆可抵扣金額，本次抵扣數量，京豆總刷量、京豆總餘額（不使用也返回）。
6.2.3做過的類似的需求設計
新增加一種SendPayParam 需要改動哪些 類型需求支持
7.未來優化點
1.比較依賴需求變動的coding庫，如果新增需求較少，寫出來的代碼可能比較薄弱
2.強依賴與新增知識庫和代碼庫的召回能力，依賴於合併記錄和需求的綁定關係，如果未來對此進行強要求可以提升代碼準確率