ChatDev 與清華 THUNLP：用對話取代文件，讓 AI 真正學會開會

在真實的軟體公司裡，最重要的決策很少發生在文件上。

它們發生在走廊裡，發生在會議室的白板前，發生在工程師和產品經理面對面辯論的那幾分鐘——「這個功能真的必要嗎？」「這個架構撐得住嗎？」「這個 Bug 是設計問題還是實作問題？」

ChatDev 想把這些對話，複製進 AI。

上一篇我們看了 MetaGPT：它用文件傳遞驅動 AI 軟體公司——PM 寫 PRD、架構師出設計圖、工程師照圖施工。這是流水線的邏輯。

ChatDev 走的是另一條路：讓 AI Agent 真正地互相對話、互相質疑、互相說服——用溝通的方式，把軟體做出來。

• 為什麼你需要認識 ChatDev？
• THUNLP 與 OpenBMB：清華的開源傳統
  • THUNLP——中國 NLP 研究的核心據點
  • OpenBMB——把研究成果推向社群
• 核心研究者是誰？
  • 錢忱（Chen Qian）——ChatDev 論文第一作者
  • 指導教授：劉知遠 & 孫茂松
• ChatDev 的核心哲學：對話才是軟體開發的靈魂
  • 為什麼文件傳遞還不夠？
• 三個核心設計
  • 1. Chat Chain：把開發流程切成原子對話
  • 2. Communicative Dehallucination：溝通去幻覺
  • 3. Role Reversal：角色反轉，強迫思考
• 四階段開發架構圖
• ChatDev vs MetaGPT：同是「AI 軟體公司」，哲學截然不同
• ChatDev 2.0：從軟體開發到「開發一切」
• 實用建議：三個起步行動
  • 步驟 1：把需求說得「剛剛好模糊」
  • 步驟 2：觀察 Agent 之間的對話過程
  • 步驟 3：從小型、有明確輸入的任務開始
• 我的反思
• 參考資料 (References)

為什麼你需要認識 ChatDev？

在這個「AI 軟體公司」三部曲裡：

• GPT-Engineer：一個 AI，先澄清需求，生成整個 codebase
• MetaGPT：五個 AI，流水線式的 SOP 文件傳遞
• ChatDev：多個 AI，透過真實對話協作完成設計、程式碼、測試

ChatDev 的核心主張是：軟體開發最難的不是寫程式，而是讓不同角色的人對同一件事有相同的理解。 這個問題，文件解決不了，只有對話才能解決。

這個洞見，來自中國頂尖 NLP 研究室長達數年的研究積累。

THUNLP 與 OpenBMB：清華的開源傳統

THUNLP——中國 NLP 研究的核心據點

THUNLP（清華大學自然語言處理實驗室） 是中國最具影響力的 NLP 研究機構之一，由 劉知遠（Zhiyuan Liu） 教授和 孫茂松（Maosong Sun） 教授共同領導。

這個實驗室的研究清單，幾乎是近十年中文 NLP 發展的縮影：

• 清華 GLM / ChatGLM 系列大語言模型
• MiniCPM 輕量級語言模型
• CPM（Chinese Pre-trained Model）系列

THUNLP 有一個鮮明的風格：做頂會論文的同時，強調開源可復現。 ChatDev 的誕生，正是這個傳統的延續。

OpenBMB——把研究成果推向社群

OpenBMB 是 THUNLP 生態下的開源平台，連結清華研究成果與工業界落地，背後有 Modelbest Inc.（面壁智能）的商業支撐。

ChatDev 從第一天就在 OpenBMB 的旗幟下開源——不是因為商業策略，而是因為這個實驗室本來就這樣做事。

核心研究者是誰？

錢忱（Chen Qian）——ChatDev 論文第一作者

錢忱的職涯路線，走的是典型的「工業 → 學術」路線。

他曾在騰訊擔任演算法工程師，入選騰訊「技術菁英」計畫，直接面對工業規模的 NLP 問題。

離開騰訊後，他以「水木清華學者計畫」博士後身份加入 THUNLP，在劉知遠與孫茂松兩位教授的指導下，把研究重心轉向 LLM 驅動的多 Agent 協作。

ChatDev 的論文（arXiv 2307.07924）是他在這個方向最重要的成果，2024 年發表於 ACL——自然語言處理領域最頂尖的學術會議之一。

目前，錢忱已轉任上海交通大學人工智能學院 的助理教授（Tenure-track），繼續指導學生在 Multi-Agent 方向深耕。

指導教授：劉知遠 & 孫茂松

這兩位教授是整個研究的知識後盾：

• 劉知遠：NLP 知識圖譜、預訓練語言模型領域的國際頂尖學者
• 孫茂松：清華計算機系教授，長期推動中文 NLP 基礎研究

ChatDev 不是一個「週末做出來的東西」，它是清華頂尖研究室多年 NLP 研究的應用結晶。

ChatDev 的核心哲學：對話才是軟體開發的靈魂

為什麼文件傳遞還不夠？

MetaGPT 的 SOP 流水線非常嚴謹，但它有一個隱藏的假設：每一份文件的內容，下游 Agent 都能完全正確地理解並執行。

現實呢？即使是最好的 PRD，工程師讀完還是會有問題。即使是最清楚的 API 定義，實作出來還是可能跟設計有落差。

ChatDev 的答案是：不要假設文件能消除歧義，讓 Agent 直接開口問。

這就是 Chat Chain（對話鏈） 的核心：把每個開發階段，切成一個個的「雙人對話」——每次對話，只解決一個具體問題，直到雙方達成共識，才繼續下一步。

三個核心設計

1. Chat Chain：把開發流程切成原子對話

ChatDev 把軟體開發分成四個大階段，每個大階段再切成多個原子對話（Atomic Chat）：

大階段：Design → Coding → Testing → Document

Design 階段的原子對話：
  Chat 1: CEO vs CTO   → 確認技術模式（GUI 還是 CLI？）
  Chat 2: CEO vs CPO   → 確認產品需求（核心功能是什麼？）
  Chat 3: CTO vs CPO   → 確認介面規格（UI 風格與互動方式）

Coding 階段的原子對話：
  Chat 4: CTO vs Programmer  → 確認程式架構
  Chat 5: Programmer vs Programmer → 逐模組實作與 Review
  Chat 6: CTO vs Programmer  → 整合測試與修正

每次原子對話結束，雙方對這個子問題達成共識，才進入下一個對話。整個開發過程，是一串有序的共識達成過程。

2. Communicative Dehallucination：溝通去幻覺

這是 ChatDev 最獨特的技術設計，也是它與其他框架最大的差異點。

一般的 LLM Agent 如果遇到模糊的指令，會傾向於猜一個答案繼續往前走——這就是「幻覺（Hallucination）」的來源之一。

ChatDev 的解法：讓 Agent 在回答之前，先主動要求更多細節。

Programmer 收到 CTO 的任務：「實作用戶登入功能」

❌ 普通 Agent：直接開始寫 username/password 登入

✅ ChatDev Dehallucination：
Programmer → CTO：「請問需要支援第三方 OAuth 登入嗎？
                   密碼需要 bcrypt 加密嗎？
                   需要 JWT 還是 Session？」

CTO → Programmer：「只需要 email/password，
                    bcrypt 加密，JWT token。」

Programmer：現在開始實作——有依據，不猜測。

這個機制讓 ChatDev 在生成複雜功能時，錯誤率顯著低於「直接生成」的方式。

3. Role Reversal：角色反轉，強迫思考

ChatDev 還有一個特別的設計：在某些關鍵對話中，讓 Agent 扮演對方的角色，強迫自己從對方視角思考問題。

這類似於人類開發流程中的「橡皮鴨除錯（Rubber Duck Debugging）」，或是「設計評審（Design Review）」——當你必須向別人解釋自己的設計，你會發現自己原本沒注意到的問題。

測試階段：Tester 對 Programmer 進行 Code Review

Tester：「這個 for 迴圈在輸入為空時會發生什麼？」

Programmer（被迫以 Tester 視角思考）：
「……確實沒處理邊界情況。讓我加一個 guard clause。」

四階段開發架構圖

ChatDev vs MetaGPT：同是「AI 軟體公司」，哲學截然不同

簡單記：MetaGPT 是流水線工廠，ChatDev 是敏捷小隊。

ChatDev 2.0：從軟體開發到「開發一切」

2025 年，ChatDev 宣布重大演進：ChatDev 2.0（DevAll），從「AI 軟體公司」升級為「零程式碼多 Agent 協作平台」。

核心變化：

• 不再只限於軟體開發——任何可以被多 Agent 協作完成的任務，都可以在 ChatDev 2.0 上編排
• 零程式碼設定——用圖形介面定義 Agent 角色和對話流程，不需要寫 Python
• NeurIPS 2025：論文「Multi-Agent Collaboration via Evolving Orchestration」被接受，持續深耕學術研究

這個演進方向和 DeepWisdom 的 Atoms 形成了有趣的平行：兩個「AI 軟體公司」框架，最後都往「通用多 Agent 平台」的方向靠攏。

實用建議：三個起步行動

步驟 1：把需求說得「剛剛好模糊」

ChatDev 的 Dehallucination 機制，在需求有些不確定性的時候最有價值。如果你一開始就把所有細節都定死了，反而損失了 AI 幫你發現盲點的機會。給它方向，讓它問你問題，這個過程本身就有價值。

步驟 2：觀察 Agent 之間的對話過程

ChatDev 的執行過程是可以被觀察的——你可以在 log 裡看到 CEO、CTO、Programmer 之間說了什麼。這些對話不只是過場，它們反映了 AI 對你需求的理解過程，讀一遍可以幫你發現哪裡說清楚了、哪裡還有歧義。

步驟 3：從小型、有明確輸入的任務開始

ChatDev 的多輪對話消耗的 Token 比 GPT-Engineer 更多。第一次使用，選一個「功能明確但細節需要討論」的任務——例如「一個支援多種幣別換算的 CLI 工具」，比「一個完整的電商系統」更適合入門。

我的反思

讀完 ChatDev 的設計，我想到一件事：這個框架，是目前系列裡最像在研究「人類如何協作」的作品。

MetaGPT 研究的是組織流程——SOP、文件規範、角色職責。這是管理學的語言。

ChatDev 研究的是溝通本身——歧義如何產生、如何消除、對話如何讓兩個認知不一致的個體達成共識。這是語言學、溝通心理學的語言。

錢忱在 THUNLP 長期研究自然語言處理，他比大多數工程師更清楚一件事：語言不只是傳遞資訊的工具，它也是澄清思維、建立共識的工具。

ChatDev 的 Dehallucination 機制，本質上是在模擬一個好的工程師在接到任務時，不會「收到什麼做什麼」，而是會先問清楚：「你說的這個功能，具體指的是什麼？邊界條件是什麼？跟現有系統怎麼整合？」

這個「先問再做」的習慣，是資深工程師和初階工程師最大的差別之一。ChatDev 試圖把這個習慣，編碼進 AI 的溝通協議。

回到這個系列：吳成林（MetaGPT）把軟體公司的管理智慧壓進 SOP，Anton Osika（GPT-Engineer）把「先澄清再生成」的邏輯做進產品，而錢忱與 THUNLP 的貢獻，是從學術角度嚴謹地問了一個問題：

如果 AI 能真正學會「開會」，軟體開發會變成什麼樣子？

ChatDev 是目前最認真嘗試回答這個問題的框架。

參考資料 (References)

官方資源

• ChatDev GitHub（OpenBMB）
• ChatDev 論文 arXiv 2307.07924

延伸閱讀

• ACL 2024 論文頁面
• 錢忱個人頁面