1.源起

李明是今年剛加入某互聯(lián)網(wǎng)公司的研發(fā)新人，滿懷期待地開始了他的職業(yè)生涯。然而，短短兩周后，他的熱情就被現(xiàn)實(shí)澆了一盆冷水。

第一周： 當(dāng)他第一次接手需求時(shí)，mentor只是簡單交代了幾句：“這個(gè)功能之前做過類似的，你參考下歷史代碼。”可當(dāng)他打開代碼倉庫，卻發(fā)現(xiàn)注釋寥寥，變量名像密碼一樣難懂，更找不到任何需求文檔。他硬著頭皮修改，結(jié)果上線后引發(fā)了線上故障——原來有個(gè)隱藏的業(yè)務(wù)規(guī)則，只有老員工才知道。

第二周： 測試同事小張跑來問：“這次改動(dòng)會(huì)影響訂單狀態(tài)流轉(zhuǎn)嗎？”李明愣住了，他根本不知道系統(tǒng)里還有這樣一條鏈路。小張無奈地說：“上次變更時(shí)沒留文檔，現(xiàn)在只能靠猜。”

第三周： 產(chǎn)品經(jīng)理突然要求緊急修復(fù)一個(gè)“歷史遺留問題”，但翻遍Confluence，只找到三年前零散的會(huì)議記錄。運(yùn)維團(tuán)隊(duì)更頭疼：每天要花大量時(shí)間重復(fù)解答“這個(gè)報(bào)錯(cuò)是什么意思”“服務(wù)依賴誰”這類問題。

某天深夜加班時(shí)，李明對(duì)著屏幕發(fā)呆：

?為什么每次變更都像在挖雷？

?為什么系統(tǒng)做這么久，代碼煙囪式設(shè)計(jì)越來越多，知識(shí)卻只維護(hù)在老員工的腦子里？新人學(xué)習(xí)成本為什么這么大？

?如果有AI能直接告訴我這段代碼對(duì)應(yīng)什么需求，或者自動(dòng)生成業(yè)務(wù)邏輯說明該多好…

這時(shí)，他想如果利用大模型將——它似乎能關(guān)聯(lián)代碼、需求文檔和運(yùn)維手冊(cè)。一個(gè)念頭閃過：或許，打破這座“代碼迷宮”的鑰匙，就藏在AI與知識(shí)庫的結(jié)合中？

2.解題思路

連續(xù)幾周的挫折讓李明意識(shí)到，這些問題不是他一個(gè)人能解決的。他決定主動(dòng)尋找解決方案。

深夜的辦公室里，李明盯著屏幕上復(fù)雜的代碼，突然萌生了一個(gè)想法：如果能把這些零散的知識(shí)點(diǎn)都串聯(lián)起來，是不是就能解決現(xiàn)在的問題？

第一次嘗試： 他想起mentor提到過的大模型技術(shù)。抱著試試看的心態(tài)，他寫了個(gè)簡單的腳本，把公司文檔庫里的需求文檔和代碼提交記錄做了關(guān)聯(lián)索引。雖然粗糙，但至少能通過關(guān)鍵詞搜索到相關(guān)文檔了。他又想如果把這種基于索引的代碼結(jié)果，放到大模型訓(xùn)練會(huì)碰撞出什么火花呢？

初步驗(yàn)證： 當(dāng)李明訓(xùn)訓(xùn)練好一個(gè)基本的智能體后，當(dāng)產(chǎn)品經(jīng)理再次詢問某個(gè)歷史功能時(shí)，李明腿間了這個(gè)智能體，產(chǎn)品經(jīng)理查到了兩年前的需求，并且還可以做解釋。雖然不夠完善，但比之前漫無目的地翻找強(qiáng)多了。

系統(tǒng)升級(jí)： 受到初步成果的鼓舞，李明開始思考更系統(tǒng)的解決方案。他梳理出三個(gè)關(guān)鍵點(diǎn)：

1.基礎(chǔ)查詢：讓新人產(chǎn)品和研發(fā)能快速找到常見業(yè)務(wù)問題的標(biāo)準(zhǔn)答案

2.知識(shí)關(guān)聯(lián)：把代碼變更和需求文檔、故障記錄打通，做針對(duì)于需求的知識(shí)庫

3.智能提示：在新需求開發(fā)時(shí)自動(dòng)關(guān)聯(lián)歷史經(jīng)驗(yàn)

實(shí)際應(yīng)用： 在開發(fā)一個(gè)新功能時(shí)，李明嘗試著把相關(guān)歷史需求、代碼和運(yùn)維記錄都整理到一起。他發(fā)現(xiàn)，這樣不僅自己理解得更透徹，組內(nèi)新來的實(shí)習(xí)生同學(xué)都可以用這個(gè)快速上手

?

?

?

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

此階段不贅述，作為一個(gè)基本常識(shí),能夠運(yùn)用基本的提示詞對(duì)大模型提問一些常見的工作問題

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

4.1架構(gòu)圖

?

?

4.2技術(shù)路線

ps:此處以DIFY（大模型工作流平臺(tái)）為例，對(duì)于在企業(yè)內(nèi)部的小伙伴要注意權(quán)限敏感問題，強(qiáng)烈建議使用各自的內(nèi)部的大模型平臺(tái)工具 此處技術(shù)路線參考5.2，與5.2類似，此處不贅述

4.3 結(jié)果展示-DMS技術(shù)專家實(shí)踐

4.3.1推薦語料庫

示例文檔添加 擴(kuò)充文檔作用 細(xì)化 給出具體范例

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

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

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

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

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

技術(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é)合具體需求，對(duì)需求的特定問題進(jìn)行解答

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

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

4.3.2推薦提示詞

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

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

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

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

4.3.3范例

?

?

?

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

5.1架構(gòu)圖

?

?

?

5.2實(shí)踐路線

5.2.1 步驟1:綁定需求名稱和代碼之間的關(guān)聯(lián)關(guān)系

1. 通過 Issue/PR 編號(hào)關(guān)聯(lián)代碼

場景：如果代碼提交時(shí)在 Commit Message 中引用了 Issue/PR 編號(hào)（如 Fix #123），可以通過以下步驟獲取關(guān)聯(lián)代碼：

curl -H "Authorization: token YOUR_TOKEN" 
"https://api.github.com/repos/{owner}/{repo}/issues/{issue_number}"

?返回的 JSON 中會(huì)包含 pull_request 字段（如果是 PR）或 timeline_url（通過事件查詢關(guān)聯(lián)提交）。

Step 2: 使用 GitHub Commit API 獲取具體代碼變更：

curl -H "Authorization: token YOUR_TOKEN" 
"https://api.github.com/repos/{owner}/{repo}/commits/{commit_sha}"

方法2. 通過 Search API 直接搜索代碼

場景：如果代碼文件或提交信息中明確包含需求標(biāo)識(shí)（如 [REQ-123]）：

curl -H "Authorization: token YOUR_TOKEN" 
"https://api.github.com/search/commits?q=repo:{owner}/{repo}+[REQ-123]+in:message"

搜索代碼文件內(nèi)容：

curl -H "Authorization: token YOUR_TOKEN" 
"https://api.github.com/search/code?q=repo:{owner}/{repo}+REQ-123+in:file"

?注：需啟用 GitHub Advanced Security 才支持代碼內(nèi)容搜索。

3. 通過 Pull Request 獲取關(guān)聯(lián)代碼

場景：如果需求通過 PR 實(shí)現(xiàn)，直接獲取 PR 的代碼變更：

?Step 1: 獲取 PR 詳情（包含分支和提交）：

curl -H "Authorization: token YOUR_TOKEN" 
"https://api.github.com/repos/{owner}/{repo}/pulls/{pr_number}"

?Step 2: 獲取 PR 的差異文件（Diff）：

curl -H "Authorization: token YOUR_TOKEN" 
"https://api.github.com/repos/{owner}/{repo}/pulls/{pr_number}/files"

4. 如果是相關(guān)企業(yè)

Step 1: 通過內(nèi)部的代碼平臺(tái)分頁獲取該應(yīng)用的歷次變更信息

Step 2: 遍歷獲取唯一id對(duì)應(yīng)的代碼變更然后轉(zhuǎn)換成KEY/VALUE格式

6.2.2 步驟2:將獲取的數(shù)據(jù)進(jìn)行清洗標(biāo)注上傳知識(shí)庫

ps:此處以DIFY（大模型工作流平臺(tái)）為例，對(duì)于在企業(yè)內(nèi)部的小伙伴要注意權(quán)限敏感問題，強(qiáng)烈建議使用各自的內(nèi)部的大模型平臺(tái)工具，否則會(huì)有法律風(fēng)險(xiǎn)，涉及代碼安全

1. 創(chuàng)建空的知識(shí)庫

curl --location --request POST 'https://api.dify.ai/v1/datasets' 
--header 'Authorization: Bearer {api_key}' 
--header 'Content-Type: application/json' 
--data-raw '{"name": "name", "permission": "only_me"}'

2. 添加分段（代碼-需求對(duì)）

curl --location --request POST 'https://api.dify.ai/v1/datasets/{dataset_id}/documents/{document_id}/segments' 
--header 'Authorization: Bearer {api_key}' 
--header 'Content-Type: application/json' 
--data-raw '{
    "segments": [
        {
            "content": "需求描述1的詳細(xì)內(nèi)容",
            "answer": "對(duì)應(yīng)的代碼實(shí)現(xiàn)1",
            "keywords": ["關(guān)鍵詞1", "關(guān)鍵詞2"]
        },
        {
            "content": "需求描述2的詳細(xì)內(nèi)容",
            "answer": "對(duì)應(yīng)的代碼實(shí)現(xiàn)2",
            "keywords": ["關(guān)鍵詞3", "關(guān)鍵詞4"]
        }
    ]
}'

方案二：使用元數(shù)據(jù)增強(qiáng)搜索（高級(jí)方案）

1. 創(chuàng)建元數(shù)據(jù)字段

curl --location 'https://api.dify.ai/v1/datasets/{dataset_id}/metadata' 
--header 'Content-Type: application/json' 
--header 'Authorization: Bearer {api_key}' 
--data '{
    "type": "string",
    "name": "code_language"
}'

2. 上傳文檔并附加元數(shù)據(jù)

curl --location --request POST 'https://api.dify.ai/v1/datasets/{dataset_id}/document/create_by_text' 
--header 'Authorization: Bearer {api_key}' 
--header 'Content-Type: application/json' 
--data-raw '{
    "name": "Python代碼示例",
    "text": "[代碼內(nèi)容]",
    "indexing_technique": "high_quality",
    "metadata": {
        "code_language": "python"
    }
}'

5.2.3 步驟3配置工作流 (此處僅給出示意圖)

?

?

?

5.3結(jié)果展示

5.3.1歷史變動(dòng)檢索

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

?

?

?

5.3.2歷史變更分析

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

?

?

?

5.3.3依據(jù)TRD寫代碼

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

改造點(diǎn)PRD：

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

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

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

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

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

?

?

?

5.3.4做過的類似的需求設(shè)計(jì)

新增加一種SendPayParam 需要改動(dòng)哪些 類型需求支持

?

?

?

6.總結(jié)

階段1 - 基礎(chǔ)應(yīng)用 李明首先整理了團(tuán)隊(duì)日常使用大模型的常見場景：

?研發(fā)人員用AI生成基礎(chǔ)代碼片段

?測試人員用AI編寫測試用例

?產(chǎn)品經(jīng)理用AI輔助撰寫需求文檔 這些基礎(chǔ)應(yīng)用雖然簡單，但確實(shí)提高了部分工作效率。

階段2 - 知識(shí)整合 在取得初步成效后，李明開始著手解決更深層的問題：

1.建立了系統(tǒng)維度的知識(shí)庫模版，確保關(guān)鍵文檔都能被有效收錄

2.開發(fā)了智能檢索功能，不僅能給出答案，還能定位到具體文檔位置

3.通過知識(shí)庫建設(shè)，反向推動(dòng)了各部門完善文檔沉淀

4.系統(tǒng)能夠結(jié)合已有知識(shí)，給出更貼近實(shí)際的解決方案

階段3 - 深度應(yīng)用 隨著系統(tǒng)不斷完善，李明團(tuán)隊(duì)實(shí)現(xiàn)了更高級(jí)的功能：

1.代碼變更追溯：可以查詢?nèi)我獯a段的歷史修改記錄

2.需求分析：新人產(chǎn)品可以快速了解系統(tǒng)的演進(jìn)歷程

3.開發(fā)輔助：研發(fā)人員可以基于需求文檔自動(dòng)生成基礎(chǔ)代碼

4.經(jīng)驗(yàn)傳承：系統(tǒng)可以提供類似需求的實(shí)現(xiàn)思路和關(guān)鍵點(diǎn)

這個(gè)逐步推進(jìn)的方案，讓團(tuán)隊(duì)的知識(shí)管理從碎片化走向系統(tǒng)化，有效解決了新人上手難、知識(shí)傳承難的問題。最重要的是，它建立了一個(gè)可持續(xù)優(yōu)化的知識(shí)沉淀機(jī)制。

7.未來優(yōu)化

在推進(jìn)的過程中，李明也發(fā)現(xiàn)了一些需要持續(xù)改進(jìn)的問題：

1.代碼生成質(zhì)量依賴需求變動(dòng)頻率李明注意到，對(duì)于那些需求變動(dòng)較少的模塊，系統(tǒng)生成的代碼往往比較基礎(chǔ)，缺乏深度。比如訂單核心流程這樣長期穩(wěn)定的模塊，生成的代碼只能覆蓋最基礎(chǔ)的場景，難以應(yīng)對(duì)復(fù)雜業(yè)務(wù)邏輯。

2.知識(shí)關(guān)聯(lián)的準(zhǔn)確性有待提升當(dāng)前系統(tǒng)對(duì)代碼變更記錄和需求文檔的關(guān)聯(lián)還不夠精準(zhǔn)。特別是在處理歷史數(shù)據(jù)時(shí)，經(jīng)常出現(xiàn)匹配錯(cuò)誤的情況。李明發(fā)現(xiàn)，如果能嚴(yán)格要求每次代碼提交都必須關(guān)聯(lián)明確的需求文檔，系統(tǒng)的準(zhǔn)確率會(huì)有顯著提升。

3.他發(fā)現(xiàn)，由于采用了RAG技術(shù)，生成代碼后比較依賴于對(duì)于query識(shí)別到需求的準(zhǔn)確度，比較依賴召回的準(zhǔn)確度。

李明意識(shí)到，這些問題都需要通過持續(xù)優(yōu)化算法，嚴(yán)格卡控需求和代碼綁定來逐步解決。他計(jì)劃將這些優(yōu)化點(diǎn)納入下一階段的改進(jìn)計(jì)劃中。不過他堅(jiān)信，道阻且長，行則將至，他一次又一次對(duì)自己說,"我知道的，我做什么都會(huì)成功的"～

審核編輯 黃宇