清華開了家員工都是GPT的公司，代碼、文檔一條龍服務(wù)

機(jī)器之心報(bào)道

編輯：Panda W

我們都知道以 ChatGPT 為代表的大型語言模型（LLM）具備代碼生成能力，畢竟代碼本身也是一種語言。

近日，清華大學(xué)孫茂松團(tuán)隊(duì)不只是讓 LLM 當(dāng)程序員，還更進(jìn)一步，基于 LLM 開發(fā)出了一家「虛擬軟件開發(fā)公司」ChatDev。這家公司的各個(gè)職員都是 LLM，能端到端地完成從分析需求到寫代碼再到文檔制作的整個(gè)軟件開發(fā)流程，實(shí)現(xiàn)軟件開發(fā)一條龍服務(wù)。理想情況下，基于該框架，用戶只需提個(gè)需求，就能收獲一個(gè)文檔配置良好的軟件！這篇論文的第一作者為清華大學(xué)軟件學(xué)院畢業(yè)的錢忱博士。

論文地址 ：https://arxiv.org/abs/2307.07924

軟件系統(tǒng)的開發(fā)、運(yùn)行和維護(hù)需要有條理、有原則地執(zhí)行。

但是，由于開發(fā)軟件需要復(fù)雜的智慧，因此很多決定往往是基于直覺和對(duì)資深開發(fā)者的有限咨詢。深度學(xué)習(xí)技術(shù)的發(fā)展讓研究者看到了新的可能性：能否將深度學(xué)習(xí)用于軟件工程，從而提升有效性和效率并降低成本？之前已經(jīng)有一些相關(guān)研究解決了一些任務(wù)，涉及軟件需求、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試和維護(hù)。軟件開發(fā)流程涉及多種工作職能，包括組織協(xié)調(diào)、任務(wù)分配、代碼編寫、系統(tǒng)測(cè)試、文檔制作等。因此復(fù)雜的軟件需要長時(shí)間的開發(fā)周期和對(duì)細(xì)節(jié)的高度關(guān)注。

近些年，大型語言模型（LLM）已經(jīng)在自然語言處理（NLP）和計(jì)算機(jī)視覺（CV）領(lǐng)域取得了重大進(jìn)展。簡單來說，LLM 的訓(xùn)練范式是基于大規(guī)模語料庫來「預(yù)測(cè)下一個(gè)詞」；而訓(xùn)練得到的模型能出色應(yīng)對(duì)許多不同的下游任務(wù)，如上下文感知型問答、機(jī)器翻譯和代碼生成。事實(shí)上，軟件開發(fā)的核心元素（即代碼和文檔）其實(shí)都可以被視為「語言」，即字符序列。

基于這一思考，清華大學(xué)、北京郵電大學(xué)和布朗大學(xué)的一個(gè)研究團(tuán)隊(duì)設(shè)計(jì)了一種框架，可用 LLM 來實(shí)現(xiàn)端到端的軟件開發(fā)。據(jù)介紹，該框架涵蓋了整個(gè)開發(fā)流程，包括分析需求、代碼開發(fā)、系統(tǒng)測(cè)試和文檔生成，目標(biāo)是為軟件開發(fā)提供一個(gè)統(tǒng)一、高效、低成本的范式。

研究者的做法并非用 LLM 直接生成整個(gè)軟件系統(tǒng)，因?yàn)檫@會(huì)出現(xiàn)一些代碼幻覺（code hallucinations）問題，類似于自然語言知識(shí)查詢中的幻覺現(xiàn)象。這些幻覺包括功能實(shí)現(xiàn)不完整、缺少依賴以及尚未發(fā)現(xiàn)的可能錯(cuò)誤。出現(xiàn)代碼幻覺的原因主要有兩個(gè)。

第一，當(dāng)一步式地生成軟件系統(tǒng)時(shí)，由于難以指定具體任務(wù)，LLM 會(huì)感到困惑。LLM 在處理高層級(jí)任務(wù)時(shí)缺乏細(xì)粒度思考，比如分析用戶 / 客戶需求和選擇編程語言，而這些細(xì)粒度任務(wù)能為軟件開發(fā)提供引導(dǎo)。

第二，決策過程缺乏交叉檢查具有重大風(fēng)險(xiǎn)。不同的模型示例給出的答案也不盡相同，這就需要辯論和檢驗(yàn)各個(gè)模型的響應(yīng)，進(jìn)而收斂到單個(gè)或多個(gè)更準(zhǔn)確的共同答案。這類措施包括代碼同行評(píng)審和建議反饋。

為了解決前述難題，這些研究者的做法是創(chuàng)立一家虛擬公司。當(dāng)然，這并不是一家真正的公司，而是以公司模式運(yùn)行的一個(gè)模型框架。他們?yōu)槠淦鹈麨?ChatDev。

該框架遵循經(jīng)典的瀑布模型（Waterfall Model），將開發(fā)過程分成了四個(gè)階段：設(shè)計(jì)、寫代碼、測(cè)試和做文檔。

ChatDev 在每個(gè)階段都會(huì)使用多個(gè)不同的智能體，它們充當(dāng)著公司的不同角色，比如程序員、評(píng)審員和測(cè)試員。

為了促進(jìn)有效的溝通和協(xié)作，研究者為 ChatDev 提出了一種名為聊天鏈（chat chain）的設(shè)計(jì)，即將每個(gè)階段都切分為易于執(zhí)行的原子級(jí)子任務(wù)。在聊天鏈中，每個(gè)節(jié)點(diǎn)代表一個(gè)特定的子任務(wù)，兩個(gè)角色參與可感知上下文的多輪討論，進(jìn)而提出并驗(yàn)證解決方案。這種方法能確保客戶需求得到分析、產(chǎn)生出創(chuàng)意思路、設(shè)計(jì)并實(shí)現(xiàn)原型系統(tǒng)、識(shí)別和解決潛在問題、解釋調(diào)試信息、創(chuàng)建吸引人的圖形界面并生成用戶手冊(cè)。通過沿聊天鏈引導(dǎo)軟件開發(fā)過程，ChatDev 能將最終的軟件交付給用戶，包括源代碼、依賴環(huán)境規(guī)范和用戶手冊(cè)。

研究者通過實(shí)驗(yàn)檢驗(yàn)了這一框架的可行性：他們?cè)O(shè)計(jì)了 70 個(gè)用戶需求，然后分析了 ChatDev 產(chǎn)出的軟件。平均而言，ChatDev 生成的每個(gè)軟件有 17.04 個(gè)文件、緩解由代碼幻覺引起的潛在代碼漏洞 13.23 次、軟件生成時(shí)間為 409.84 秒、制造成本為 0.2967 美元。

實(shí)驗(yàn)中，討論發(fā)揮了巨大作用：評(píng)審員和程序員之間的討論成功識(shí)別出并修改了近 20 種代碼漏洞類型，而測(cè)試員和程序員之間的討論則成功找到了 10 多種可能漏洞并進(jìn)行了修改。

本文的主要貢獻(xiàn)包括：

• 提出了 ChatDev，這是一個(gè)基于聊天的軟件開發(fā)框架。用戶只需簡單指定一項(xiàng)任務(wù)，ChatDev 就會(huì)按順序進(jìn)行設(shè)計(jì)、寫代碼、測(cè)試和做文檔。這種新范式通過語言交流統(tǒng)一了主要開發(fā)流程，從而無需在每個(gè)階段都使用專門的模型，這能極大簡化軟件的開發(fā)過程。
• 研究者提出了聊天鏈，可將開發(fā)流程分解成按順序執(zhí)行的原子級(jí)子任務(wù)。每個(gè)子任務(wù)都需要兩個(gè)角色之間的協(xié)作交互和交叉檢查。該框架支持多智能體協(xié)作、用戶對(duì)中間輸出進(jìn)行檢查、錯(cuò)誤診斷和推理得出干預(yù)措施。這能確保對(duì)每次聊天中的特定子任務(wù)進(jìn)行細(xì)粒度的關(guān)注，促進(jìn)有效的協(xié)作，幫助得到所需的輸出。
• 為了進(jìn)一步緩解與代碼幻覺相關(guān)的潛在難題，研究者引入了思維指示（thought instruction）機(jī)制，可用于寫代碼、審查和測(cè)試階段的每個(gè)獨(dú)立聊天過程。通過執(zhí)行「角色翻轉(zhuǎn)」，指示員可將修改代碼的具體思路明確地注入到指令中，從而更精準(zhǔn)地引導(dǎo)輔助程序員。
• 研究者進(jìn)行了實(shí)驗(yàn)驗(yàn)證，結(jié)果表明 ChatDev 能有效且高效地自動(dòng)完成軟件開發(fā)過程。通過每次聊天中角色之間的有效溝通、建議和相互審查，該框架可以實(shí)現(xiàn)有效的決策。

ChatDev

ChatDev 的大致架構(gòu)如圖 1 所示，這是一家聊天驅(qū)動(dòng)的軟件技術(shù)「虛擬公司」，其中包含不同的職能角色，它們對(duì)應(yīng)于真實(shí)公司的不同職業(yè)崗位，比如各種首席官、專業(yè)程序員、測(cè)試工程師和藝術(shù)設(shè)計(jì)師。當(dāng)接到任務(wù)時(shí)，ChatDev 的不同智能體將協(xié)作開發(fā)所需的軟件，包括可執(zhí)行系統(tǒng)、環(huán)境指南和用戶手冊(cè)。這種范式的核心思路是利用大型語言模型作為核心思考組件，使智能體模擬整個(gè)軟件開發(fā)過程，避免額外的模型訓(xùn)練需求，并在一定程度上減輕代碼幻覺問題。

圖 1：ChatDev 的大致架構(gòu)

聊天鏈

ChatDev 采用被廣泛應(yīng)用的瀑布模型，將軟件開發(fā)過程分成了四個(gè)不同階段：設(shè)計(jì)、寫代碼、測(cè)試和做文檔。每個(gè)階段都需要多個(gè)角色之間有效溝通，而其中的難點(diǎn)就在于確定互動(dòng)順序和參與角色。

這里，研究者提出的解決方案是將每個(gè)階段分解為多個(gè)原子級(jí)聊天，每個(gè)聊天都特定關(guān)注面向任務(wù)的兩個(gè)不同角色的角色扮演。通過參與智能體之間的指令交換和協(xié)作，可以讓每個(gè)聊天都輸出所需結(jié)果，而這些結(jié)果是構(gòu)成目標(biāo)軟件的重要組成部分。

圖 2 描述了這個(gè)過程，其中展示了一個(gè)解決中間任務(wù)的聊天序列。在每次聊天中，指示員都會(huì)發(fā)出指令，引導(dǎo)對(duì)話完成任務(wù)，而助手則遵循指令，提供合適的解決方案，并參與可行性討論。指示員和助手通過多輪對(duì)話互相協(xié)作，直至達(dá)成共識(shí)，確定任務(wù)成功完成。

圖 2：新提出的 ChatDev 架構(gòu)，其中包含階段級(jí)組件和聊天級(jí)組件

設(shè)計(jì)

在設(shè)計(jì)階段，ChatDev 從人類客戶處獲得一個(gè)想法。該階段涉及三個(gè)預(yù)定義角色：CEO（首席執(zhí)行官）、CPO（首席產(chǎn)品官）和 CTO（首席技術(shù)官）。然后，聊天鏈將設(shè)計(jì)階段分解為按順序執(zhí)行的原子級(jí)聊天任務(wù)，包括決定目標(biāo)軟件模式的聊天（CEO 和 CPO）和決定編程語言的聊天（CEO 和 CTO）。

1.角色分配

在角色扮演過程中，使用系統(tǒng)提示 / 消息為每個(gè)智能體分配角色。與其它典型的對(duì)話語言模型相比，新框架的提示工程僅限于角色扮演場景的初始階段。在這個(gè)框架中，指示員最初是作為 CEO，參與互動(dòng)規(guī)劃，而助手則承擔(dān) CPO 的角色，執(zhí)行任務(wù)和提供響應(yīng)。

為了實(shí)現(xiàn)角色專業(yè)化（role specialization），研究者采用了初始提示（inception prompting），事實(shí)證明這可以有效地使智能體履行其角色職能。指示員和助手 prompt 包含很多重要細(xì)節(jié)，比如指定的任務(wù)和角色、交流協(xié)議、終止標(biāo)準(zhǔn)和旨在防止不良行為（如指令冗余、無信息響應(yīng)、無限循環(huán)等）的約束。

圖 3：每次聊天中使用的三個(gè)關(guān)鍵機(jī)制：角色專業(yè)化、記憶流、自我反思

2.記憶流（Memory Stream）

記憶流機(jī)制的作用是維持智能體之前對(duì)話的全面記錄，以一種可感知話語的方式輔助后續(xù)決策。有關(guān)記憶流的形式化描述，請(qǐng)參看原論文。

3.自我反思

研究者觀察到，有時(shí)候?qū)υ掚p方已達(dá)成共識(shí)，但沒有觸發(fā)作為終止條件的預(yù)定義的交流協(xié)議。為此，他們引入了自我反思機(jī)制，其中涉及到對(duì)記憶的提取和檢索。為了實(shí)現(xiàn)這一機(jī)制，研究者引入一個(gè)「偽自我」，將其作為質(zhì)疑者來發(fā)起新聊天。這個(gè)偽質(zhì)疑者會(huì)將所有之前對(duì)話的歷史記錄告知當(dāng)前助手并要求對(duì)對(duì)話中的結(jié)論性信息進(jìn)行摘要，如圖 3 (c) 所示。

這一機(jī)制能有效地鼓勵(lì)助手反思對(duì)話期間提出和討論的決定。

寫代碼

該階段涉及三個(gè)預(yù)定義角色：CTO、程序員和藝術(shù)設(shè)計(jì)師。聊天鏈會(huì)將寫代碼階段分解為按順序執(zhí)行的原子級(jí)聊天任務(wù)，例如生成完整的代碼（CTO 和程序員）和設(shè)計(jì)圖形用戶界面（設(shè)計(jì)師和程序員）。

基于上一階段討論的主要設(shè)計(jì)，CTO 會(huì)指示程序員使用 Markdown 格式實(shí)現(xiàn)軟件系統(tǒng)。程序員的響應(yīng)是生成代碼，并根據(jù) Markdown 格式提取出對(duì)應(yīng)的代碼。設(shè)計(jì)師的任務(wù)是提出一種對(duì)用戶友好的圖形用戶界面（GUI），它可使用圖形圖標(biāo)進(jìn)行用戶交互，而非文本命令。然后，設(shè)計(jì)師使用外部的文本轉(zhuǎn)圖像工具創(chuàng)建吸人眼球的圖形，程序員再使用標(biāo)準(zhǔn)的工具包將其整合到 GUI 設(shè)計(jì)中。

1.代碼管理

為了應(yīng)對(duì)復(fù)雜的軟件系統(tǒng)，ChatDev 使用了 Python 等面向?qū)ο蟮木幊陶Z言。面向?qū)ο蟮木幊淌悄K化的，這能實(shí)現(xiàn)自包含的（self-contained）對(duì)象，有助于故障排除和協(xié)作開發(fā)。可復(fù)用性支持通過繼承實(shí)現(xiàn)代碼復(fù)用，減少冗余。

研究者引入了「版本演進(jìn)」機(jī)制來限制角色之間最新代碼版本的可見性，從記憶流中丟棄早期的代碼版本。程序員使用 Git 相關(guān)命令來管理項(xiàng)目。提議的代碼修改和更改會(huì)將軟件版本號(hào)增加 1.0。版本演進(jìn)可逐漸消除代碼幻覺。面向?qū)ο缶幊膛c版本演進(jìn)相結(jié)合，適合涉及長段代碼的對(duì)話。

2.思維指示

傳統(tǒng)的問答可能會(huì)導(dǎo)致出現(xiàn)不準(zhǔn)確或不相關(guān)的信息，特別是在代碼生成中，簡單直接的指令可能會(huì)導(dǎo)致意想不到的幻覺。在生成代碼時(shí)，這個(gè)問題變得尤其突出。

為了解決這個(gè)問題，研究者在「思維鏈提示」的啟發(fā)下提出了「思維指示（thought instruction）」機(jī)制。這涉及到在指令中明確解決特定的問題求解思路，類似于按順序解決子任務(wù)。如圖 4 (a) 和 4 (b) 所示，思維指示包括交換角色以詢問哪些方法尚未實(shí)現(xiàn)過，然后切換回來，從而為程序員提供更精確的指示。

通過整合思維指示，寫代碼過程會(huì)變得更關(guān)注重點(diǎn)和有針對(duì)性。指令中特定思維的明確表達(dá)有助于減少歧義并確保生成的代碼與預(yù)期目標(biāo)保持一致。這種機(jī)制可讓寫代碼過程更準(zhǔn)確且實(shí)現(xiàn)上下文感知，從而最大限度地減少幻覺，輸出更可靠更全面的代碼。

圖 4：思維指示可緩解編碼和測(cè)試階段的代碼幻覺

測(cè)試

即使人類程序員也不能保證自己第一次嘗試編寫的代碼始終沒有錯(cuò)誤。人類通常不會(huì)直接丟棄不正確的代碼，而會(huì)分析和調(diào)查代碼執(zhí)行結(jié)果以識(shí)別和糾正實(shí)現(xiàn)中的錯(cuò)誤。ChatDev 的測(cè)試階段涉及三個(gè)角色：程序員、審查者和測(cè)試者。

這個(gè)過程包含的原子級(jí)任務(wù)有同行評(píng)審（程序員和審查員）和系統(tǒng)測(cè)試（程序員和測(cè)試員）。同行評(píng)審是靜態(tài)調(diào)試，目的是通過檢查源代碼來識(shí)別潛在問題。系統(tǒng)測(cè)試是一種動(dòng)態(tài)調(diào)試，目的是通過程序員使用解釋器執(zhí)行測(cè)試，從而驗(yàn)證軟件的執(zhí)行情況。該測(cè)試的重點(diǎn)是通過黑盒測(cè)試評(píng)估應(yīng)用程序的性能表現(xiàn)。

如果解釋器難以找到細(xì)粒度的邏輯問題，則可以讓人類客戶參與到軟件測(cè)試中。

寫文檔

經(jīng)過設(shè)計(jì)、寫代碼和測(cè)試階段之后，ChatDev 使用四個(gè)智能體（CEO、CPO、CTO 和程序員）來生成軟件的項(xiàng)目文檔。研究者的做法是使用大型語言模型，通過基于上下文樣本的少樣本 prompt 設(shè)計(jì)來生成文檔。CTO 指示程序員提供環(huán)境依賴項(xiàng)的配置指令，從而生成像 requirements.txt 這樣的文檔。該文檔可讓用戶獨(dú)立地配置環(huán)境。與此同時(shí)，CEO 可向 CPO 傳達(dá)需求和系統(tǒng)設(shè)計(jì)，讓 CPO 生成用戶手冊(cè)。

圖 5：文檔生成過程

實(shí)驗(yàn)

實(shí)驗(yàn)使用了 gpt3.5-turbo-16k 版本的 ChatGPT 來模擬多智能體軟件開發(fā)，具體的參數(shù)設(shè)置請(qǐng)參看原論文，下面我們看看實(shí)驗(yàn)結(jié)果。

表 1：ChatDev 的軟件開發(fā)的統(tǒng)計(jì)數(shù)據(jù)分析，包括各方面數(shù)值的最小值（Min）、最大值（Max）和平均值（Avg.）

ChatDev 開發(fā)的軟件通常會(huì)生成 39-359 行代碼，平均 131.61 行。數(shù)據(jù)表明 ChatDev 傾向于產(chǎn)出代碼規(guī)模相對(duì)較小的軟件。部分原因是面向?qū)ο缶幊痰脑O(shè)計(jì)，其可復(fù)用性可以通過繼承實(shí)現(xiàn)代碼重用，減少冗余。

圖 6：持續(xù)時(shí)間分布。圖中的條形按降序排列，展示了不同任務(wù)的軟件開發(fā)運(yùn)行時(shí)間的分布情況。

平均而言，使用 ChatDev 開發(fā)小型軟件和界面需要 409.84 秒，不到 7 分鐘。相比之下，傳統(tǒng)的定制軟件開發(fā)周期，即使是使用敏捷軟件開發(fā)方法，每個(gè)周期通常也需要 2-4 周甚至幾個(gè)月時(shí)間。

表 2：聊天鏈中所有對(duì)話的統(tǒng)計(jì)分析

圖 7：審查者建議的分布情況。餅圖中的每種顏色代表審查者提供的特定建議的類別。

圖 8：測(cè)試者建議的分布情況。餅圖中的每種顏色代表測(cè)試者提供的漏洞的類別。

圖 9：任務(wù)「design a basic Gomoku game」（設(shè)計(jì)一個(gè)基礎(chǔ)五子棋游戲）所得到的軟件

左邊是一個(gè)沒有 GUI 的簡單軟件。該版本的游戲只能通過命令終端來玩，其交互性和整體趣味性有限。相比之下，通過結(jié)合 GUI 設(shè)計(jì)，ChatDev 可以創(chuàng)造出視覺上好看的小游戲。此外，ChatDev 的設(shè)計(jì)師還可以協(xié)助程序員創(chuàng)建額外的圖形，以增強(qiáng) GUI 的美觀性和可用性。

最后我們看看 ChatDev 公司開發(fā)五子棋游戲時(shí)，職員討論如何選擇編程語言的聊天概況：