Cursor 上線多人協作 Projects：讓你的 AI 直接找同事的 AI 溝通

過去一年裡，不少程式設計師的工作流變成了這樣：左邊坐著自己，右邊開著 AI 程式設計助手，你發指令它敲程式碼，效率確實提上去了。

可只要一進團隊協作，事情就容易打回原形。

你想讓前端 AI 做個登入介面，AI 告訴你缺後端介面。於是你在 Slack 上敲同事，同事再把這需求轉述給自己的 AI。等後端 AI 寫好了，同事把文件發給你，你再餵給你的前端 AI。

你明明在寫程式碼，卻生生被幹成了兩個 AI 之間的“人工傳話筒”。

Cursor 開始向所有使用者公測多人協作版 Projects。這次更新最核心的改變，就是讓不同開發者的 AI 終於可以直接“互通有無”，不再非得讓人在中間當傳聲筒。

把私聊留下，給團隊墊一層“公共記憶”

Cursor 解決這個問題的方式很有意思，它並沒有粗暴地把所有人的聊天框拉成一個幾千條訊息的大群。

每個人依然保留自己跟 AI 協調員（coordinator）以及執行智慧體（worker agent）的一對一私聊視窗，寫程式碼時不受別人干擾。

真正的變化發生在上層。Cursor 在所有人的對話之上鋪了一層團隊共享資訊層。需求文件、技術規範、架構圖以及設計原型，都會被存進這個公共層裡。

更方便的是新人接入。以往新同事進專案，每個人都得花大把時間給各自的 AI 喂上下文。現在新成員一旦被拉進同一個 Project，AI 就能直接讀懂整個專案的技術背景和歷史決策。

在這個工作區裡，團隊還能共用一個任務看板。誰在幹什麼、各自的 AI 在跑哪個任務、程式碼對應哪一個 Pull Request（PR），人和 AI 都能看得清清楚楚。

別等衝突提交了，讓 AI 提前對齊

不過，多人版 Projects 最抓人的看點，還是讓兩個人的 AI 協調員直接對話。

軟體工程裡最頭疼的事之一，就是多個人同時改程式碼導致的碰撞衝突。Cursor 給出的典型場景非常接地氣。

比如前端工程師在做一個需要讀取資料庫的新功能，而另一位後端同事恰好在重構該資料表結構。以往往往是大家各自寫完準備合併時，才發現底層欄位變了，只能痛苦地大改程式碼。

在新的協作模式下，雙方的 AI 協調員在排期階段就會先溝通對齊，商定好工作順序，先把表結構更新完，再讓前端 AI 依據新結構編寫呼叫邏輯。

再比如設計師在重構商品詳情頁，工程師正好在往這個頁面塞商品評價模組。兩邊的 AI 也能提前碰頭，把佈局和元件的結構順順好，省去後面的返工。

Cursor 內部還拿它跑值班交接。交班工程師下線後，接班工程師的 AI 協調員會自動調取在途任務、未解決的事故日誌，甚至直接監控對應的通訊頻道和任務看板，手頭的未完工作能無縫交接給接班人的 AI。

為什麼重要

我們認為，Cursor 這次邁出的一步非常聰明，它切中了當前 AI 程式設計工具最大的痛點：個人效率已經見頂，瓶頸全卡在人與人的協同損耗上。

把 Agent 之間的私有對話升級為跨人的協作網路，本質上是在重新定義軟體開發的生產流程。從過去的人與人協作，走向“人、Agent、不同人的 Agent”組成的混合協同網。如果你平時經常遇到跨模組依賴或者複雜的版本合併，現在完全值得拉上隊友去測試版裡建個專案試一試。

但這件事也存在明顯的隱患。Cursor 目前給出的例子都是理想狀態下的協同演示，業內也指出，他們並沒有公佈 Agent 自主協商究竟能在實際生產中減少多少程式碼衝突。

AI 之間互相商量介面和先後順序，聽起來很美好，可一旦雙方的 Prompt 產生歧義，或者一方的模型對架構理解出現偏差，很可能會演變成“兩個 AI 揹著人類達成了一個錯誤的共識”。

無論如何，開發工具的戰場正在發生轉移。只拼單兵寫程式碼速度的時代差不多過去了，接下來比的，是誰能讓成群結隊的 AI 在一個專案裡不打架、少添亂。