沒做過專案的人，常以為寫程式最難的是敲程式。真的做過的人都知道，敲程式只是其中一環。動手之前要先釐清需求、決定技術方案；寫完要逐行除錯，還要補測試、寫說明，最後交出來的東西才算能給別人用。一個人獨自走完這條流程，往往要耗上幾天甚至幾週，而時間大多花在不是程式碼的那些步驟上。

ChatDev 把這條生產線上每一個環節的工人換成模型，而且不是一個模型包辦全部，是一整支分工明確的虛擬團隊。它由一所大學的研究團隊與一家模型公司共同打造，並以開源專案的形式釋出。你描述想要的東西，虛擬公司的成員各自領活，最後交回一份能跑的程式。

每個人都有自己的工位與職責

組織的比喻就是一家真實的軟體公司，而且執行得很徹底：執行長、產品官、架構師、程式員、評審員、測試員、文書撰寫者。他們不是各幹各的，而是透過一輪輪像開會討論的對話協作。產品官提出需求，架構師判斷技術上可不可行，程式員動手實作，評審員讀程式並提出修改意見，測試員則真的把程式跑起來，再把錯誤帶回去給程式員繼續修。

有兩個細節讓這些會議不至於變成演戲。評審時刻意把角色翻轉：挑毛病的一方必須明確指出希望修改的那一段程式碼，這能大幅減少模型那種理直氣壯的胡說。另一套版本機制則讓後續環節只看得到最新的原始碼，團隊才不會把時間浪費在修一份已經被換掉的程式上。

一句話進去，程式與手冊出來

使用方式刻意做得很樸素：用日常語言描述你要的軟體，替專案取個名字，團隊就開始運轉。需求分析、介面設計、程式撰寫、測試、文書產生全都涵蓋，最後拿到的不是散落一地的檔案，而是一個附有執行說明與使用手冊的專案。

團隊早期公布的數據可以給個量級感：一個中等複雜度的小型軟體，平均不到十分鐘就完成，呼叫模型的費用大約是幾元人民幣的量級。這些數字來自理想環境，實際結果會隨描述的清確程度與所用模型的能力浮動。需求寫得越具體，成品就越貼近預期。

從開發軟體到「開發一切」

專案並沒有停在軟體公司這個場景裡。2026 年初釋出的第二代（代號 DevAll）把邊界大幅拓寬：它變成一個零程式碼的代理編排環境，用視覺化畫布拖曳節點、連線設定，就能搭出協作流程。資料視覺化、三維建模、深度調研、內容產製，都可以編排成一條自動執行的流程。範本可以像積木一樣組合，底層則開放給想用設定或程式碼客製的人。

平台採前後端分離的架構，把流程畫成圖，並允許在關鍵節點插入人工審核——自動化在需要判斷的時候停下來問人。原始碼以寬鬆授權開放，到 2026 年年中已在專案首頁累積三萬四千多個關注。模型介面與主流服務保持相容，接上自己的金鑰就能開始用。

現在誰適合上手

以目前的成熟度，它最擅長的是小型工具與原型驗證這類目標清楚的專案：把一個臨時的點子快速變成能跑的雛形，效率優勢非常明顯。它同樣適合想研究多代理協作的學生與開發者，把虛擬公司當成觀察群體協作機制的實驗場。如果目標是比較複雜的大型系統，產出通常還需要經驗豐富的開發者接手打磨；把它當成高效的起點，而不是終點的替代品，是更務實的姿勢。

它改變的東西比宣傳小，也比聽起來大：一份程式的初稿，不再必須由一個人獨自寫完。一排各司其職的角色會交出一個不完美但真實的東西，細節可以之後再吵。