Cursor 發布 Projects：一個專案、一條持久對話
9 月 10 日，Cursor 在官方 X 帳號發布 Projects，第一句就點出工作方式的轉向：與其為每個任務各開一個對話，你改為在一條單一而持久的對話中，與一個「協調代理」共事。同日的官方 changelog 給出定位：Projects 是為了承接更大的工作主體——一個功能、一次遷移，或一整套應用程式；服務以 beta 形式自當日起向所有用戶逐步推出。
這則公告改變的不是某個按鈕，而是互動的基本單位。過去兩年，AI 編程工具的共同前提是「對話即任務」：任務來了開一個 chat，代理做完、你驗收，對話隨即沉入歷史紀錄；下一個任務再重新交代一次專案背景。脈絡的壽命與對話等長，專案知識散落在數十個對話之間。Projects 把這個壽命拉長：對話與專案同壽，協調代理是這條對話的常駐管理者。
對已經習慣「開新對話保持乾淨」的用戶，這是把雙面刃。脈絡持續累積，減少了每次重複交代的成本；但哪些事讓協調代理記住、哪些細節要在派工前明確重述，會成為新的日常課題。工作方式的紀律，比工具本身更早決定成效。
協調代理怎麼運作：規劃、派工，但不親自寫碼
changelog 對協調代理的角色界定講得相當直白：專案裡的協調代理自己不寫程式碼；它規劃工作、把工作派給負責實作的代理。換句話說，它被設計成一個調度者，而不是又一個下場寫碼的模型。
拆開來看，這個架構裡有三種角色。人提出目標與驗收條件；協調代理把目標拆解成可派工的段落、安排先後與相依關係；實作代理各自領走一段，在自己的上下文裡動手。這比較接近一個小型工程團隊的分工——技術主管拆解需求、指派任務、彙整結果，但自己不寫第一行程式碼。
派工的價值在平行與隔離。每個實作代理有自己的上下文視窗，互不干擾地推進不同段落；協調代理持有全域視野，避免兩個代理改到同一處、或對同一個問題各做一套解法。這與 Cursor 既有的 subagents 機制一脈相承：官方在 2.4 版 changelog 已宣布預設的 subagents，用於研究程式碼庫、執行終端指令與平行推進工作流。Projects 等於把這些零散的派工能力，收攏到一條持久對話的管理之下。
「合併 PR 增加 6 倍」該怎麼解讀
這次公告中最常被轉述的，是一組採用數據。AlphaSignal 的報導寫道：Cursor 報告重度 Projects 用戶合併的 PR 多出 6 倍，新用戶則多出 30%。數字亮眼，但引用前有三個問題值得先問。
第一，誰測的、怎麼測的。這組數據出自 Cursor、經第三方轉述，目前可查的官方 changelog 條目並未附上方法學：樣本期間、「重度用戶」的定義門檻、是否控制了專案類型，都沒有說明。第二，它是觀察數據還是對照結果。若屬前者，「重度用戶」本來就是高吞吐、高 AI 滲透的團隊——他們合併更多 PR，可能反映的是團隊屬性，而不全是 Projects 帶來的效果。第三，合併量不等於價值。代理式工作流傾向把工作拆成更小的 PR，數量上升也可能部分來自拆分粒度的改變。
不過，數字的方向與 Cursor 先前公布的研究一致：官方部落格曾引述芝加哥大學的分析，指代理成為預設工作模式後，企業合併的 PR 增加 39%。39% 是全體樣本、6 倍是重度子集，兩者並不矛盾，反而勾勒出同一條曲線：用得越深，吞吐差距越大。值得追蹤的是正式版發布時，官方是否補上方法學細節，讓 6 倍這個數字可以被外部檢驗。
從編輯器到開發平台：Cursor 今年的連續布局
把 Projects 放回 Cursor 今年下半年的產品序列，位置會更清楚。8 月中，Cursor 推出 Origin 程式碼託管服務，把儲存庫、pull request 與審查收進自家產品；當時的背景之一，正是越來越多的產出來自代理，審查現場需要機器可讀的結構。模型供應與渠道也在同段時間重整：本站先前報導過 OpenAI 終止向 Cursor 供應模型，而 Cursor 也現身 Anthropic 的 Claude Marketplace 夥伴名單，企業能用既有 Anthropic 承諾額度折抵採購。
三步放在一起看：託管解決「程式碼放在哪裡」，渠道解決「怎麼被企業買走」，Projects 補上「工作怎麼被拆解與執行」的編排層。Cursor 官方另以「軟體工程的第三時代」為題發表長文，把代理自主完成端到端工作、人退向規劃與審查，定位為軟體工程的下一階段。無論是否接受這個敘事，產品結構的走向是明確的：從編輯器起家的 Cursor，正在把託管、調度與採購收攏到同一個屋簷下。
對開發團隊的實際影響：吞吐放大之後，審查是新瓶頸
第一個影響是技能重心的移動。與協調代理協作時，最有槓桿的輸入不再是一段精確的程式碼指示，而是清楚的目標、邊界條件與驗收標準。規劃品質決定派工品質：目標含糊，下游的實作代理會把含糊放大成數個方向各異的 PR，回頭修正的成本更高。
第二個影響是審查負載。當實作代理平行產出，人類的審查頻寬成為整條流水線的上限；合併量提升的前提，是審查能量同步跟上，否則工作只是從「待辦」堆疊搬到「待審」堆疊。Cursor 先前的 Origin 與審查介面把 PR 時間軸、checks 與 diff 收進同一頁，正是為了讓大量代理產出的審查可以規模化——工具鏈的配套，會決定 6 倍的吞吐能不能真正落地。
導入上，官方對 Projects 的定位是承接功能、遷移或整套應用等較大的工作主體，加上仍在 beta，務實的路徑是先挑一個界線清楚的中型專案試行，觀察 PR 品質與審查時間的變化，再決定是否擴大到核心專案。
限制與值得追蹤的訊號
最後是這次公告沒有回答的部分。數據面：6 倍與 30% 的計算基礎、「重度用戶」的定義、正式版時程，官方都尚未揭露。架構面：協調代理是整條流程的單點——它的規劃與分解品質直接決定下游產出；持久對話也帶來新的維護課題，長期累積的脈絡如何避免過期與失真，公告中未見機制說明。成本面：多代理平行的用量如何反映在帳單上，是企業評估時必要的變數，同樣未見著墨。
值得追蹤的訊號有三：changelog 何時從 beta 轉正、定價與用量欄位怎麼變化，以及第三方研究能否複現合併量的提升。在方法學公開之前，把 6 倍視為方向參考而非可預期的投資回報，是比較穩健的讀法。
