1.源起

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

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

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

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

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

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

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

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

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

2.解題思路

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

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

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

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

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

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

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

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

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

?

?

?

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

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

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

4.1架構(gòu)圖

?

?

4.2技術(shù)路線

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

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

4.3.1推薦語料庫

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

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

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

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

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

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

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

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

4.3.2推薦提示詞

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

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

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

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

4.3.3范例

?

?

?

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

5.1架構(gòu)圖

?

?

?

5.2實踐路線

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

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

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

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

?返回的 JSON 中會包含 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)識（如 [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 實現(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)部的代碼平臺分頁獲取該應(yīng)用的歷次變更信息

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

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

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

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

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. 添加分段（代碼-需求對）

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": "對應(yīng)的代碼實現(xiàn)1",
            "keywords": ["關(guān)鍵詞1", "關(guān)鍵詞2"]
        },
        {
            "content": "需求描述2的詳細(xì)內(nèi)容",
            "answer": "對應(yīng)的代碼實現(xiàn)2",
            "keywords": ["關(guān)鍵詞3", "關(guān)鍵詞4"]
        }
    ]
}'

方案二：使用元數(shù)據(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歷史變動檢索

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

?

?

?

5.3.2歷史變更分析

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

?

?

?

5.3.3依據(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）進(jìn)行各資產(chǎn)試算

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

?

?

?

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

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

?

?

?

6.總結(jié)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.未來優(yōu)化

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

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

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

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

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

審核編輯 黃宇