本發(fā)明屬于人工智能與軟件工程交叉，具體涉及一種針對代碼倉庫的readme文檔自動生成方法。

背景技術(shù)：

1、在現(xiàn)代軟件開發(fā)中，readme文檔是代碼倉庫中的重要組成部分，它提供了項目簡介、主要功能說明、安裝和使用指南、代碼結(jié)構(gòu)概述以及關(guān)鍵代碼的解釋；對于開發(fā)者來說，readme文檔能夠幫助他們快速理解和上手項目。然而，手動編寫和維護(hù)readme文檔是一項費(fèi)時費(fèi)力的任務(wù)，尤其是對于大型和不斷變化的代碼庫而言，這就引出了自動生成readme文檔的需求。

2、隨著代碼倉庫規(guī)模的擴(kuò)大和復(fù)雜性的增加，手動編寫readme文檔不僅效率低下，還容易出現(xiàn)遺漏或不準(zhǔn)確的信息。因此，利用先進(jìn)的技術(shù)手段自動生成readme文檔顯得尤為重要；通過自動化的方式，不僅可以確保readme文檔的內(nèi)容始終與代碼庫保持一致，還能減少人為錯誤，提升文檔質(zhì)量和開發(fā)效率。

3、現(xiàn)有的協(xié)助開發(fā)者編寫readme文檔的方法主要依賴于提供靜態(tài)模板或基于用戶輸入填充模板，這類工具包括github的默認(rèn)readme生成器以及其他靜態(tài)文檔生成工具；這些工具通常通過預(yù)定義的模板讓開發(fā)者根據(jù)項目需求手動填寫內(nèi)容，例如項目名稱、使用說明、安裝步驟等。然而，這些方案并不能實際幫助開發(fā)者撰寫具體的文檔內(nèi)容，由于模板生成的局限性，開發(fā)者仍需花費(fèi)大量時間和精力編寫詳細(xì)的項目介紹、功能描述、使用說明等，尤其對于復(fù)雜的項目，這種方式不僅效率低下，還容易導(dǎo)致文檔質(zhì)量參差不齊。

4、此外，已有研究表明，大語言模型具備生成類/函數(shù)級代碼注釋的能力，例如文獻(xiàn)[chen,mark,jerry?tworek,etc.“evaluating?large?language?models?trained?oncode.”arxiv?abs/2107.03374(2021):n.pag]利用語言模型生成函數(shù)注釋，通過對函數(shù)的輸入?yún)?shù)、輸出結(jié)果及其內(nèi)部邏輯進(jìn)行解析和概括，生成相應(yīng)的注釋文本；這種方法可以對小范圍的代碼提供較為精確的注釋幫助，從而提高了代碼的可讀性和維護(hù)性。然而，這類方法的應(yīng)用范圍局限于函數(shù)或類級別的注釋生成，通常只涉及幾十行代碼的解析和生成。

5、生成readme文檔的挑戰(zhàn)在于需要對整個項目進(jìn)行高度抽象和概括，readme文檔通常需要涵蓋項目的全局信息，包括項目目標(biāo)、主要功能模塊、安裝步驟、使用方法、項目結(jié)構(gòu)等，涉及數(shù)千甚至數(shù)百萬行代碼。因此，單純依靠現(xiàn)有的大語言模型生成注釋的方法不足以應(yīng)對readme文檔生成的復(fù)雜性；現(xiàn)有技術(shù)無法從項目級別進(jìn)行整體抽象，生成的內(nèi)容往往缺乏系統(tǒng)性和全局性。

6、現(xiàn)有的方法如代碼文檔生成工具(例如sphinx和doxygen)雖然可以基于代碼注釋自動生成api文檔，但它們的作用局限于從代碼本身提取文檔，無法自動生成對項目整體有概括性的readme文檔；這些工具通常依賴于開發(fā)者手動編寫的注釋，并不能自動生成項目級別的文檔，由于缺乏對代碼全局結(jié)構(gòu)和邏輯的深度理解，這類方法生成的文檔也難以滿足開發(fā)者對高層次文檔需求。目前最優(yōu)的方法larch[koreeda,yuta&morishita,terufumi&imaichi,osamu&sogawa,yasuhiro.(2023).larch:large?language?model-basedautomatic?readme?creation?with?heuristics.10.48550/arxiv.2308.03099]通過啟發(fā)式的方法提取項目的入口文件，進(jìn)而生成readme文檔，但是這樣的方法也有非常明顯的局限性，因為項目的入口并不能去代表整個項目的含義。

7、由此可見，現(xiàn)有方法存在顯著局限性：一方面，靜態(tài)模板填充方法缺乏自動化能力，不能幫助開發(fā)者生成具體內(nèi)容；另一方面，基于語言模型生成注釋的技術(shù)僅能處理小范圍的代碼片段，無法有效應(yīng)對規(guī)模龐大的代碼庫的文檔生成需求。因此，如何在項目級別上生成完整、準(zhǔn)確且抽象的readme文檔，仍然是一個亟待解決的技術(shù)難題。

技術(shù)實現(xiàn)思路

1、為了應(yīng)對上述挑戰(zhàn)，本發(fā)明提供了一種針對代碼倉庫的readme文檔自動生成方法，能夠為開發(fā)者提供了一個強(qiáng)有力的工具來應(yīng)對復(fù)雜代碼倉庫的文檔編寫。

2、一種針對代碼倉庫的readme文檔自動生成方法，包括如下步驟：

3、(1)使用預(yù)訓(xùn)練的機(jī)器學(xué)習(xí)模型從代碼倉庫中提取關(guān)鍵代碼文件；

4、(2)對關(guān)鍵代碼文件進(jìn)行函數(shù)級拆分用以生成函數(shù)摘要；

5、(3)以代碼倉庫的元數(shù)據(jù)、關(guān)鍵代碼文件的函數(shù)摘要作為提示詞，輸入至大語言模型用以自動生成readme文檔。

6、進(jìn)一步地，所述步驟(1)的具體實現(xiàn)方式如下：

7、1.1獲取代碼倉庫的數(shù)據(jù)集；

8、1.2為數(shù)據(jù)集中的每一代碼文件生成標(biāo)簽數(shù)據(jù)，根據(jù)標(biāo)簽數(shù)據(jù)確定代碼文件的重要性；

9、1.3對代碼文件進(jìn)行特征提取并作為機(jī)器學(xué)習(xí)模型的輸入，將重要性作為模型的輸出，從而對模型進(jìn)行訓(xùn)練；

10、1.4利用訓(xùn)練好的模型對代碼倉庫中的代碼文件進(jìn)行重要性排序，選取排名靠前的若干個代碼文件作為整個代碼倉庫的關(guān)鍵代碼文件。

11、進(jìn)一步地，所述步驟1.1中獲取代碼倉庫數(shù)據(jù)集，即根據(jù)指定倉庫的編程語言、star數(shù)量、大小限制構(gòu)建api請求，使用分頁查詢的方式繞過api請求的訪問限制，獲取大量代碼倉庫及其元數(shù)據(jù)作為數(shù)據(jù)集。

12、進(jìn)一步地，所述步驟1.2中為數(shù)據(jù)集中的每一代碼文件生成標(biāo)簽數(shù)據(jù)，即采用數(shù)據(jù)編程的范式，人工制作一組啟發(fā)式的標(biāo)簽函數(shù)為每一代碼文件創(chuàng)建生成帶有噪聲的標(biāo)簽數(shù)據(jù)，進(jìn)而使用snorkel庫的統(tǒng)計模型處理標(biāo)簽沖突，通過解決矩陣補(bǔ)全式問題來恢復(fù)標(biāo)簽函數(shù)的準(zhǔn)確性，進(jìn)而整合來自不同標(biāo)簽函數(shù)輸出的標(biāo)簽數(shù)據(jù)得到代碼文件的重要性。

13、進(jìn)一步地，所述標(biāo)簽函數(shù)包括以下四類信息判斷：

14、文件信息，包括文件長度是否過短(小于200個字符)、文件中的函數(shù)是否含有“main”字符串、文件中是否含有參數(shù)解析器等；

15、文件夾信息，包括文件名是否含有“main”字符串、是否含有程序入口類的名稱(例如cli.py)等；

16、靜態(tài)代碼分析信息，包括是否在導(dǎo)入依賴關(guān)系樹的頂層、是否包含被繼承多次的類等；

17、預(yù)言機(jī)信息，包括是否在原先的readme文檔中被引用、是否被列在setup.py當(dāng)中等。

18、進(jìn)一步地，所述步驟(2)的具體實現(xiàn)方式如下：

19、2.1對關(guān)鍵代碼文件進(jìn)行函數(shù)級拆分，得到函數(shù)的控制流和數(shù)據(jù)流；

20、2.2基于抽象語法樹提取每個函數(shù)中的數(shù)據(jù)流信息和控制流信息；

21、2.3根據(jù)數(shù)據(jù)流信息和控制流信息為每個函數(shù)生成摘要。

22、進(jìn)一步地，所述步驟2.1中對關(guān)鍵代碼文件進(jìn)行函數(shù)級拆分，即將關(guān)鍵代碼文件的字符串解析成抽象語法樹，遍歷抽象語法樹得到每個函數(shù)的定義及其代碼，進(jìn)而通過節(jié)點的屬性得到每個函數(shù)的數(shù)據(jù)流和控制流。

23、進(jìn)一步地，所述步驟2.3中基于數(shù)據(jù)流信息和控制流信息調(diào)用gpt-4api為每個函數(shù)生成摘要，具體地：首先將函數(shù)的數(shù)據(jù)流信息和控制流信息(包括輸入?yún)?shù)、返回值、函數(shù)主體中的關(guān)鍵操作和條件分支等)作為gpt-4api的輸入數(shù)據(jù)；然后將這些輸入數(shù)據(jù)構(gòu)建成一個格式化的提示詞傳遞給gpt-4api，請求生成一個詳細(xì)的摘要，gpt-4api會基于其預(yù)訓(xùn)練的語言模型以及提供的上下文信息，生成一個涵蓋函數(shù)各個方面的摘要，包括函數(shù)的輸入?yún)?shù)、輸出結(jié)果、關(guān)鍵邏輯以及潛在的邊界情況。

24、進(jìn)一步地，所述步驟(3)的具體實現(xiàn)方式如下：

25、3.1以代碼倉庫的元數(shù)據(jù)、關(guān)鍵代碼文件的函數(shù)摘要作為提示詞并對其進(jìn)行格式化；

26、3.2構(gòu)建api請求并發(fā)送給大語言模型所在服務(wù)器，api請求包括身份驗證信息(如api密鑰)、格式化后的提示詞以及其他可能影響生成結(jié)果的參數(shù)設(shè)置(如生成文本的長度、溫度參數(shù)等)；

27、3.3服務(wù)器對收到的api請求進(jìn)行解析，將其中格式化后的提示詞輸入至大語言模型，將關(guān)鍵代碼文件的函數(shù)摘要作為模型輸入的上下文來實現(xiàn)readme文檔的生成。

28、本發(fā)明通過結(jié)合預(yù)訓(xùn)練的機(jī)器學(xué)習(xí)模型和大語言模型，顯著提升了代碼倉庫中readme文檔的生成效率和質(zhì)量，具有重要的技術(shù)效果。首先，本發(fā)明采用預(yù)訓(xùn)練的機(jī)器學(xué)習(xí)模型對代碼倉庫中的代碼文件進(jìn)行重要性排序，能夠自動篩選出最關(guān)鍵的代碼文件，避免了人工篩選帶來的不準(zhǔn)確性和低效問題，從而提高了文檔生成的針對性和準(zhǔn)確性。其次，本發(fā)明通過對關(guān)鍵代碼文件進(jìn)行函數(shù)級拆分，并基于控制流和數(shù)據(jù)流生成函數(shù)摘要，使得文檔內(nèi)容不僅涵蓋了代碼的功能，還體現(xiàn)了代碼邏輯和結(jié)構(gòu)上的復(fù)雜性，確保了文檔能夠全面準(zhǔn)確地描述代碼的核心功能，這種深層次的代碼分析極大地提高了文檔內(nèi)容的精確度。最后，本發(fā)明利用大語言模型生成readme文檔，進(jìn)一步實現(xiàn)了文檔的自動化編寫，減少了人工干預(yù)的工作量，同時確保生成的文檔具有自然流暢的語言表達(dá)和一致性；這一技術(shù)效果使得開發(fā)者能夠快速生成高質(zhì)量的文檔，顯著提高了軟件開發(fā)的效率，尤其在大型代碼倉庫的維護(hù)和協(xié)作中，具有重要的實際應(yīng)用價值。