這項(xiàng)由加拿大女王大學(xué)的鐘蘇珍、鄒穎以及布拉姆·亞當(dāng)斯領(lǐng)導(dǎo)的研究發(fā)表于2020年9月的《IEEE軟件工程期刊》，研究團(tuán)隊(duì)深入分析了現(xiàn)實(shí)世界中開發(fā)者與大語言模型（如ChatGPT和Claude）之間的對話互動。有興趣深入了解的讀者可以通過arXiv:2509.10402訪問完整論文。

在當(dāng)今這個AI助手滿天飛的時代，幾乎每個程序員都有過這樣的經(jīng)歷：遇到棘手的編程問題時，會習(xí)慣性地打開ChatGPT或Claude，輸入自己的困惑，然后等待AI給出答案。但這些看似簡單的對話背后，究竟隱藏著怎樣的規(guī)律和問題？開發(fā)者們最喜歡向AI請教什么？AI生成的代碼質(zhì)量到底如何？這些問題長期以來缺乏系統(tǒng)性的研究，因?yàn)樯虡I(yè)AI服務(wù)商出于隱私和知識產(chǎn)權(quán)保護(hù)，很少公開真實(shí)的對話數(shù)據(jù)。

為了填補(bǔ)這一空白，研究團(tuán)隊(duì)從WildChat數(shù)據(jù)集中篩選出了一個名為CodeChat的大規(guī)模數(shù)據(jù)集，包含82,845個真實(shí)的開發(fā)者與AI對話，總計31萬多輪交互，生成了36萬多個代碼片段，覆蓋20多種編程語言。這就像是給程序員與AI助手的日?；优牧艘徊块L達(dá)一年多的紀(jì)錄片，記錄了從2023年4月到2024年5月期間發(fā)生的真實(shí)編程對話。

研究團(tuán)隊(duì)想要回答三個核心問題：開發(fā)者與AI的對話有什么特征？開發(fā)者最常向AI請教哪些編程話題？AI生成的代碼質(zhì)量究竟如何？通過分析這些海量對話數(shù)據(jù)，他們發(fā)現(xiàn)了許多有趣且實(shí)用的現(xiàn)象，這些發(fā)現(xiàn)不僅能幫助程序員更好地使用AI工具，也為AI助手的改進(jìn)提供了重要參考。

一、AI助手的話癆特質(zhì)與對話模式

當(dāng)我們分析這些真實(shí)對話時，第一個跳出來的發(fā)現(xiàn)就是AI助手的"話癆"特質(zhì)。在CodeChat數(shù)據(jù)集中，AI回復(fù)的長度是開發(fā)者提問的14倍！這就像你問朋友"今天天氣怎么樣"，結(jié)果他給你講了一整篇關(guān)于氣象學(xué)原理的論文。具體來說，AI回復(fù)平均包含約2000個字符，而開發(fā)者的提問只有約971個字符，甚至連Stack Overflow上那些詳細(xì)回答（平均836字符）都顯得簡潔許多。

這種冗長并非沒有代價。在GPT-4這樣的商業(yè)模型中，生成文本的成本遠(yuǎn)高于輸入文本——每百萬個輸出token需要20美元，而輸入token只需要5美元。AI助手的啰嗦特質(zhì)意味著用戶需要為這些冗長回復(fù)付出更高的使用成本。

更有趣的是對話的互動模式。研究發(fā)現(xiàn)，68%的對話都是多輪次的，也就是說，開發(fā)者通常不會在第一次提問后就滿意地離開，而是會繼續(xù)追問、修改需求或請求更多功能。這就像你向朋友請教做菜方法，結(jié)果發(fā)現(xiàn)光是一道菜就需要來回討論好幾輪——先問基本做法，然后問調(diào)料比例，接著又想知道素食版本的做法。

通過分析連續(xù)提問的模式，研究團(tuán)隊(duì)發(fā)現(xiàn)了造成多輪對話的主要原因。最常見的情況是"不同用例"，占37.8%。這意味著開發(fā)者經(jīng)常在同一個對話中跳轉(zhuǎn)到完全不同的編程任務(wù)，而不是針對同一問題深入討論。其次是"缺失規(guī)格說明"（14.8%）和"額外功能需求"（12.8%），這反映了開發(fā)者往往在初始提問時沒有完整表達(dá)自己的需求，需要后續(xù)補(bǔ)充說明。

在編程語言的分布方面，AI生成的代碼呈現(xiàn)出明顯的偏好。Python以31%的比例遙遙領(lǐng)先，這與其在機(jī)器學(xué)習(xí)和數(shù)據(jù)科學(xué)領(lǐng)域的流行地位相符。JavaScript排名第二（9%），但有趣的是，這個比例遠(yuǎn)高于TIOBE編程語言排行榜中JavaScript的位置，說明AI模型在Web開發(fā)相關(guān)任務(wù)上被頻繁使用。Bash和Shell腳本也占據(jù)了重要位置（8%），盡管它們在傳統(tǒng)編程語言排行榜中并不突出。

AI助手還經(jīng)常在單次回復(fù)中生成多種編程語言的代碼。最常見的組合是CSS-HTML（17%的多語言代碼），這完全符合Web開發(fā)的實(shí)際需求。HTML-JavaScript（14%）和Java-XML（12%）的組合也很常見，分別對應(yīng)Web前端交互和企業(yè)級開發(fā)場景。

代碼片段的長度分析顯示，不同編程語言有著顯著差異。C語言的代碼片段最長，中位數(shù)達(dá)到26行，這可能與C語言的低級特性和需要更多顯式聲明有關(guān)。HTML和C++分別以25行和23行緊隨其后。相比之下，Python和JavaScript的代碼片段相對簡潔，中位數(shù)分別為17行和18行。最簡潔的是各種Shell腳本，通常只有3行左右，這符合Shell腳本通常執(zhí)行簡單任務(wù)的特點(diǎn)。

二、熱門編程話題的真實(shí)畫像

當(dāng)深入分析開發(fā)者向AI請教的具體話題時，研究團(tuán)隊(duì)運(yùn)用了先進(jìn)的主題建模技術(shù)，從52,086個英文對話中識別出了47個不同的編程話題。這就像給程序員的日常困惑繪制了一幅詳細(xì)地圖，揭示了現(xiàn)代軟件開發(fā)中最受關(guān)注的領(lǐng)域。

排在首位的是Web設(shè)計和開發(fā)，占到所有對話的9.6%。這個結(jié)果并不意外，畢竟在今天這個互聯(lián)網(wǎng)時代，幾乎每個公司都需要網(wǎng)站，每個開發(fā)者都或多或少要接觸Web技術(shù)。在這類對話中，HTML占39%，Python占32.3%，JavaScript占26.6%。開發(fā)者們經(jīng)常詢問如何創(chuàng)建響應(yīng)式布局、如何實(shí)現(xiàn)特定的用戶界面效果，或者如何讓不同瀏覽器上的網(wǎng)頁表現(xiàn)一致。常見的關(guān)鍵詞包括"div"（HTML中用于頁面結(jié)構(gòu)的標(biāo)簽）和"react"（流行的JavaScript框架）。

緊隨其后的是機(jī)器學(xué)習(xí)模型訓(xùn)練和AI機(jī)器人部署，占8.7%。這反映了AI技術(shù)的火爆程度——不僅普通人在使用AI，連開發(fā)者們也在大量學(xué)習(xí)和應(yīng)用AI技術(shù)。在這類對話中，Python占據(jù)了絕對主導(dǎo)地位（72.9%），這符合Python在數(shù)據(jù)科學(xué)和機(jī)器學(xué)習(xí)領(lǐng)域的統(tǒng)治地位。開發(fā)者們經(jīng)常詢問如何使用PyTorch進(jìn)行梯度縮放、如何在Keras中設(shè)計深度學(xué)習(xí)架構(gòu)，以及如何優(yōu)化多任務(wù)學(xué)習(xí)工作流程。

第三大類話題是匯編級操作和內(nèi)存處理，占4.9%。這可能讓人感到意外，因?yàn)檫@些都是相對底層的技術(shù)。但實(shí)際上，這反映了現(xiàn)代軟件開發(fā)的復(fù)雜性——即使在高級編程語言盛行的今天，開發(fā)者仍然需要處理底層系統(tǒng)問題。在這類對話中，C++和C語言分別占39.8%和16.4%，這些語言天然適合系統(tǒng)級編程。開發(fā)者們詢問的問題通常涉及精細(xì)的內(nèi)存控制和底層系統(tǒng)行為，包括匯編指令如"mov"、"ptr"和"eax"的使用。

其他重要話題還包括SQL模式設(shè)計和ORM持久化（4.8%）、游戲開發(fā)和控制機(jī)制（4.6%）、圖像處理和分析（4.2%），以及二進(jìn)制補(bǔ)丁和內(nèi)存處理（3.4%）。每個話題都有其獨(dú)特的語言偏好和技術(shù)特點(diǎn)，展現(xiàn)了現(xiàn)代軟件開發(fā)的多樣性和復(fù)雜性。

特別值得注意的是，不同話題的對話長度存在顯著差異。AI增強(qiáng)業(yè)務(wù)工具和策略自動化話題的平均對話輪次最多，達(dá)到3.40輪。這類對話往往涉及復(fù)雜的業(yè)務(wù)邏輯和多變的需求，開發(fā)者需要反復(fù)澄清和調(diào)整，導(dǎo)致更長的交互過程。

在分析話題轉(zhuǎn)換模式時，研究團(tuán)隊(duì)發(fā)現(xiàn)了一個有趣現(xiàn)象：連續(xù)三次"不同用例"的模式出現(xiàn)頻率最高，占16.0%。這意味著開發(fā)者經(jīng)常在同一個對話中連續(xù)跳轉(zhuǎn)不同的編程任務(wù)，就像一個人在同一次購物中買菜、買衣服、又買書，完全沒有關(guān)聯(lián)。其次是"額外功能→額外功能→不同用例"（2.3%）和"不同用例→不同用例→額外功能"（1.9%）的模式，這些都反映了開發(fā)者在使用AI助手時的探索性和多任務(wù)特性。

還有一個值得關(guān)注的現(xiàn)象是"錯誤響應(yīng)→錯誤響應(yīng)→錯誤響應(yīng)"的三連模式，占1.9%。這表明AI有時會陷入持續(xù)生成錯誤代碼的循環(huán)，而沒有得到有效糾正。這提醒我們，雖然AI助手很有用，但開發(fā)者仍需要保持批判性思維，不能盲目信任AI的每一個回復(fù)。

三、AI生成代碼的質(zhì)量真相

為了全面評估AI生成代碼的質(zhì)量，研究團(tuán)隊(duì)對五種主流編程語言（Python、JavaScript、C++、Java、C#）的63,685個代碼片段進(jìn)行了深入分析。這就像給AI助手的編程能力做了一次全面體檢，結(jié)果既有令人驚喜的地方，也暴露了不少問題。

在Python代碼中，最突出的問題是命名規(guī)范。令人震驚的是，83.4%的Python代碼片段都存在無效命名問題，也就是說十個代碼片段中有八個都不符合Python的PEP8命名規(guī)范。這就像是一個外國人說中文，語法可能對了，但總是用錯成語和習(xí)慣用法，讓人聽起來怪怪的。除了命名問題，未定義變量也是一個嚴(yán)重困擾，影響30.8%的代碼片段。這就像是在菜譜中突然提到一種沒有在材料清單中列出的調(diào)料，讓人摸不著頭腦。

導(dǎo)入錯誤在Python代碼中也很常見，出現(xiàn)在20.8%的代碼片段中。相比之下，語法錯誤只影響8.0%的代碼，頻率相對較低。有趣的是，在人類編寫的Jupyter筆記本代碼中，未定義變量的比例是46.3%，而AI生成代碼中這個比例類似，說明AI在這方面確實(shí)"學(xué)到了"人類的編程習(xí)慣，包括不好的習(xí)慣。

JavaScript代碼的問題更加嚴(yán)重。75.3%的代碼片段存在未定義變量問題，這比Python還要嚴(yán)重。這就像是在對話中頻繁使用對方不認(rèn)識的人名，造成交流障礙。此外，33.7%的代碼包含未使用的變量，14.4%存在語法錯誤。在語法錯誤中，最常見的是意外的尖括號，出現(xiàn)在5.8%的代碼片段中。與人類在Stack Overflow上編寫的JavaScript代碼相比，AI生成的代碼在語法錯誤方面表現(xiàn)更差——人類代碼的語法錯誤率只有1.9%，而AI代碼高達(dá)14.4%。

C++代碼的主要問題是缺少頭文件包含，影響41.1%的代碼片段。這就像是在使用電器時忘記插電源線，代碼根本無法編譯運(yùn)行。未使用函數(shù)的問題也比較常見，出現(xiàn)在17.8%的代碼中。相對而言，C++的語法錯誤率較低，只有9.4%，這比人類在Stack Overflow上編寫的C/C++代碼表現(xiàn)要好（人類代碼的語法錯誤率約為20%）。

Java代碼的最大問題是缺少必需的注釋，這影響了75.9%的代碼片段。這反映了AI在代碼文檔方面的不足，生成的代碼往往缺乏必要的說明和注釋，影響代碼的可維護(hù)性。此外，45.3%的代碼存在局部變量可以聲明為final但沒有聲明的問題，這在人類編寫的Java代碼中也很常見（41.1%）。

C#代碼的主要問題是無法解析的命名空間，影響49.2%的代碼片段。這就像是在使用某個工具時，發(fā)現(xiàn)工具箱里缺少必要的配件。此外，42.4%的代碼缺少文檔注釋，10%缺少訪問修飾符，9.8%存在格式問題。

在多輪對話中，代碼質(zhì)量的變化呈現(xiàn)出有趣的趨勢。在Python代碼中，未定義變量錯誤隨著對話輪次增加而惡化，從第1輪的23.5%增加到第5輪的32.8%，這在統(tǒng)計上是顯著的變化。這說明隨著對話的延續(xù)，AI可能會失去對變量上下文的追蹤能力。然而，導(dǎo)入相關(guān)錯誤卻有所改善，從48.3%下降到44.6%，說明AI在多輪對話中能夠逐漸補(bǔ)充缺失的導(dǎo)入語句。

Java代碼在多輪對話中表現(xiàn)出了積極的改善趨勢。文檔違規(guī)從第1輪的78.1%顯著下降到第5輪的63.4%，局部變量final聲明問題也從51.6%改善到41.3%。這表明AI在迭代過程中能夠?qū)W習(xí)和改進(jìn)代碼的文檔質(zhì)量和編程規(guī)范。

在JavaScript和C++代碼中，主要質(zhì)量問題在多輪對話過程中基本保持穩(wěn)定，沒有顯著的改善或惡化趨勢。C#代碼的情況類似，各種質(zhì)量指標(biāo)在多輪對話中變化不大。

當(dāng)開發(fā)者需要修復(fù)AI生成代碼中的語法錯誤時，最有效的提示策略是直接指出錯誤并要求修復(fù)，這種方法在22.8%的成功案例中被使用。其次是通過提問來引導(dǎo)正確解決方案（16.9%）和添加具體指令（16.5%）。這三種方法合計占到成功修復(fù)案例的56.2%，說明清晰的錯誤信號、引導(dǎo)性提問和精確指令是獲得正確代碼的關(guān)鍵策略。

四、對開發(fā)者和工具建設(shè)者的啟示

這項(xiàng)研究的發(fā)現(xiàn)對不同群體都有重要的實(shí)際指導(dǎo)意義。對于使用AI助手的開發(fā)者來說，首要建議是建立系統(tǒng)化的代碼驗(yàn)證流程。由于AI生成的代碼經(jīng)常存在語法錯誤、未定義變量和維護(hù)性問題，開發(fā)者不應(yīng)該直接復(fù)制粘貼AI的代碼，而應(yīng)該將其視為初稿，需要經(jīng)過仔細(xì)檢查和測試。

具體來說，開發(fā)者應(yīng)該養(yǎng)成使用靜態(tài)分析工具檢查AI代碼的習(xí)慣。對于Python代碼，使用Pylint等工具檢查命名規(guī)范和變量定義；對于JavaScript，使用ESLint檢查語法和變量使用；對于其他語言，也有相應(yīng)的檢查工具。這就像是在發(fā)表文章前使用拼寫檢查一樣重要。

在提示工程方面，研究揭示了一些有效的策略。當(dāng)AI生成錯誤代碼時，最好的修復(fù)方法是直接指出具體錯誤并明確要求修復(fù)，而不是含糊其辭地說"這個代碼有問題"。同時，為了減少不必要的多輪對話，開發(fā)者應(yīng)該在初始提問時盡可能詳細(xì)地描述需求，包括預(yù)期的功能、使用場景和技術(shù)約束。

對于會話型代碼助手的開發(fā)者，研究建議在產(chǎn)品中集成自動化的代碼檢查和修正工具?，F(xiàn)在的AI助手通常只生成代碼文本，但如果能夠在生成后自動運(yùn)行靜態(tài)分析工具，并嘗試修復(fù)發(fā)現(xiàn)的問題，將大大提高用戶體驗(yàn)。一些平臺已經(jīng)開始這樣做，比如自動保存AI生成的代碼為獨(dú)立文件，便于用戶管理和版本控制。

另一個重要建議是改進(jìn)多語言代碼的上下文管理。研究發(fā)現(xiàn)開發(fā)者經(jīng)常需要跨多種編程語言的代碼解決方案，但現(xiàn)有的AI助手在維護(hù)不同語言間的依賴關(guān)系方面還有不足。未來的工具應(yīng)該能夠自動檢測和管理跨語言的依賴關(guān)系，比如HTML文件中引用的CSS和JavaScript文件。

對于IDE工具的構(gòu)建者，研究建議將會話功能與現(xiàn)有的開發(fā)環(huán)境深度整合?，F(xiàn)在的做法通常是在IDE中開一個聊天窗口，但更好的方案是讓AI助手能夠直接理解項(xiàng)目上下文，包括已有的文件、依賴關(guān)系和編碼規(guī)范，從而生成更適合項(xiàng)目的代碼。

研究還指出了一個重要的成本效益問題。AI回復(fù)比開發(fā)者提問長14倍，這不僅增加了使用成本，也可能影響開發(fā)效率。工具開發(fā)者應(yīng)該考慮提供更簡潔的回復(fù)選項(xiàng)，讓用戶可以選擇詳細(xì)解釋還是簡潔代碼。

對于研究者，這項(xiàng)工作揭示了幾個值得深入探索的方向。首先是動態(tài)令牌分配策略的研究，如何在保證代碼質(zhì)量的同時減少不必要的冗長輸出。其次是針對真實(shí)開發(fā)場景的基準(zhǔn)測試開發(fā)，現(xiàn)有的編程能力評估多基于算法競賽題目，但實(shí)際開發(fā)中更多涉及Web開發(fā)、數(shù)據(jù)處理和系統(tǒng)集成等任務(wù)。

最后，這項(xiàng)研究強(qiáng)調(diào)了提升AI代碼文檔生成能力的重要性。32.1%的Python代碼和42.4%的C#代碼缺少必要的文檔注釋，這在實(shí)際項(xiàng)目中是無法接受的。未來的AI模型應(yīng)該能夠生成不僅功能正確，而且包含清晰文檔的代碼。

研究團(tuán)隊(duì)的這項(xiàng)工作為我們理解開發(fā)者與AI助手的真實(shí)交互提供了寶貴的洞察。隨著AI技術(shù)的不斷發(fā)展，這些發(fā)現(xiàn)將有助于構(gòu)建更智能、更可靠的編程助手，最終提升整個軟件開發(fā)行業(yè)的效率和質(zhì)量。對于每一個使用AI編程助手的開發(fā)者來說，理解這些發(fā)現(xiàn)并相應(yīng)調(diào)整自己的使用方式，將有助于更好地發(fā)揮AI工具的價值，同時避免潛在的陷阱。

說到底，AI助手就像是一個知識淵博但有時會犯低級錯誤的編程伙伴。它能夠快速提供靈感和初步方案，但最終的代碼質(zhì)量還是需要人類開發(fā)者的把關(guān)。隨著我們對這種人機(jī)協(xié)作模式理解的加深，相信未來的編程體驗(yàn)會變得更加高效和可靠。

Q&A

Q1：CodeChat數(shù)據(jù)集包含多少開發(fā)者與AI的真實(shí)對話？

A：CodeChat數(shù)據(jù)集包含82,845個真實(shí)的開發(fā)者與AI對話，總計31萬多輪交互，生成了36萬多個代碼片段，覆蓋20多種編程語言，數(shù)據(jù)收集時間跨度為2023年4月到2024年5月。

Q2：AI生成的代碼主要存在哪些質(zhì)量問題？

A：不同語言的AI代碼存在不同問題：Python代碼83.4%存在命名規(guī)范問題，JavaScript代碼75.3%有未定義變量，C++代碼41.1%缺少頭文件，Java代碼75.9%缺少必需注釋，C#代碼49.2%存在命名空間無法解析的問題。

Q3：開發(fā)者最常向AI請教哪些編程話題？

A：最熱門的三大話題是：Web設(shè)計和開發(fā)（9.6%），主要涉及HTML、JavaScript和Python；機(jī)器學(xué)習(xí)模型訓(xùn)練和AI機(jī)器人部署（8.7%），以Python為主；匯編級操作和內(nèi)存處理（4.9%），主要使用C++和C語言。