軟體開發中的每一次重大進展，都改變了團隊表達意圖的方式。瀑布式開發仰賴大量文件，因為調整方向很緩慢。敏捷則減少了文件工作，因為迭代成本低，團隊能在行動中學習。

代理需要一種專屬的規劃方式。與其採用會過早凍結意圖的關卡式流程，不如採用一種能在一開始給出方向、同時在真實工作中保持靈活並緊貼實際的規劃方法。

#代理要如何有效運作

當代理能夠用清楚的語言拆解問題時，就能保持在正軌上。它們會提出問題、去除預設假設，並在動手寫程式碼之前先勾勒出路徑。它們的訓練會強化這種行為。

當計畫是明確且可調整時，它們就能在較長的工作階段中不易偏離軌道。這就是為什麼替代理做規劃，更適合使用可反覆迭代的介面，而不是固定不變的規格說明。計畫會成為循環的一部分。

隨著代理發現限制條件，它會更新計畫。隨著使用者細化意圖，計畫又會再度調整。這種節奏比起早期那種劃分為離散階段的規劃方式，更符合代理驅動開發的特性。

#Cursor 如何為代理智慧設計規劃機制

我們根據對軟體開發團隊如何透過代理最大化產出的理解，打造了 Plan Mode。這是一種強大、通用，並且專為代理式開發設計的規劃方法。

Plan Mode 為代理提供一個空間，可以提出問題、掃描程式碼庫、提出路徑，並與使用者一起加以細化。它可以在處理快速任務時保持輕量，也可以演變成一個長期存在的標準化成果物。這個流程分為五個步驟：

1. 釐清問題。代理會提出問題來消除歧義。敏捷團隊通常透過快速的來回溝通處理這一點。規格驅動開發（SDD）則把它變成正式的需求步驟。Plan Mode 延續同樣「降低模糊性」的目標，但讓代理直接主導發問，更符合代理式工作的節奏。

2. 研究。代理掃描程式碼庫，以找出它需要互動的部分。較舊的工作流程會把這視為一個獨立的設計階段。Plan Mode 則將這一步直接融入代理的推理過程。

3. 起草計畫。代理會撰寫一個可編輯的計畫檔，說明要做的變更以及實作這些變更的步驟。SDD 會把這凍結成固定規格；敏捷流程則常讓文件逐漸偏離實際。Plan Mode 讓計畫保持「活著」，因此你和代理可以隨著新資訊出現持續調整它。

4. 執行工作。代理會按部就班地執行，並在完成時勾選任務。傳統方法會把規劃與實作拆開。Plan Mode 則把它們視作同一個流程，讓計畫可以動態調整。

5. 修訂計畫。當事情偏離軌道時，計畫同時也是重置的起點。與其用後續提示來「打補丁」調整行為，團隊可以回退變更、完善計畫，然後再次執行。這能讓意圖保持清晰，也比在代理執行中途硬轉向更能產出乾淨的結果。

計畫會儲存到你的工作區中，作為 .cursor/plans/ 內由版本控制管理的檔案。它們就放在你的程式碼旁邊，像其他專案產物一樣由 git 追蹤。你可以看到哪些內容在何時被修改，並在需要時回滾。

#彈性的規劃基本元件

不同團隊用不同方式組織規劃意圖。有些依賴正式的需求文件，其他則使用不斷演進的設計或分階段的工作流程。一套規劃框架應該足夠彈性，能容納團隊偏好的工作方式。

這一點現在更重要，因為整個環境正在快速變動。瀑布式開發定義了好幾十年的規劃方式，敏捷又塑造了接下來二十年的團隊運作。Agent 智能的進步則是在更短的時間尺度上發生。任何固定不變的流程都會很快老化。

這就是為什麼我們圍繞著簡單的基本元件來設計我們的方法，讓你可以自由塑造。你可以使用 Agent Skills 來定義你團隊偏好的規劃結構，而代理會一致地遵循那套結構。

有些團隊會把更正式、以規格驅動的工作流程編碼成一個代理技能。其他團隊則定義一些技能，產生更輕量、會隨工作推進而演進的規劃。因為規劃是由技能來塑造，而不是由固定流程決定，這兩種做法都能自然地融入 規劃模式。

重點不在於我們的規劃方法能向後相容——雖然它確實可以；重點在於它是前瞻性的。一個建立在少數共享基本元件上的框架，能在代理開始承擔過去規劃風格從未預期的工作時，預留空間讓團隊持續演進自己的方法。

#展望未來

代理能處理的工作規模與複雜度正在快速提升。由於我們在設計 Plan 模式時，採用簡單的基礎構件，並從一開始就以代理為核心，因此它能夠跟上這些進展。

我們正在測試能在專案中進行長時間執行、在多個工作階段間保留脈絡，並在任務適合平行處理時建立子代理的代理。多位開發者很快就能加入同一個工作階段，一起查看計畫如何演進，並在專案推進過程中引導代理。我們的目標，是在維持軟體團隊一向期望從規劃中獲得的核心要素——清晰度、可見度與使用者控制權——的同時，擴大代理可以完成的工作範圍。