更多課題 · Cursor

作為我們最初那篇問題文章的延續，以下是我們認為對 AI 程式開發下一階段最重要的一些新課題。

下一步動作預測

Cursor 內建 Copilot++，這是一個更聰明的 copilot 版本，可以預測你的下一個編輯動作。我們能不能把這個想法推到極致？

在寫程式時，你不只是做低熵的編輯。在整個編輯器中，你輸入的是低熵的按鍵、點擊、動作。我們能不能建立一個模型，以低延遲預測每一個這類動作？

一開始，我們已將 Copilot++ 擴展為能預測你的下一個游標位置。把這個和下一步編輯預測結合起來，模型就能自動完成一連串低熵變更：

我們按下 Tab 鍵 11 次，其他所有按鍵各按 3 次。我們把這稱為 Cursor Flow（原因不言自明）。

我們正在研究預測你下一個會切換到的檔案、你下一個會執行的終端機指令，以及在你過去的終端機指令條件下的下一步編輯——一個下一步動作預測模型。

此外，模型應該在你需要的那一刻主動為你提供資訊，無論是正確的程式碼片段，還是正確的文件。

Cursor 應該感覺起來就像你意志的延伸。當你一想到要做出改動，語言模型只需要極少的意圖提示就能立刻替你執行。

具前景的方向

圍繞整個程式碼庫進行 action prediction（動作預測） 的基礎研究。
持續對約 5–13B 活躍參數的程式碼模型進行 pre-training 與 post-training（用於 prefill 受限的低延遲預測）。
類似於 Speculative Edits 的額外推論技巧

在不干擾使用者的前提下，以巧妙的 UX 浮現這些「動作」。（你要如何建議使用者接下來應該切換到哪個檔案？或是目前視窗範圍外的哪個位置？）

完美編輯

我們能否在推理時投入更多計算資源，以產生更高品質、影響範圍更大的編輯？我們又該如何彌補因此增加的延遲？

可能有必要在背景執行這些編輯，啟動一個可以放心交給智慧模型處理的工作單元。

我們將需要具備強大編輯器專用工具使用能力的模型、更聰明的整個程式碼庫層級脈絡理解，以及改進的長期推理能力。

另外，我們該如何讓非同步程式碼生成仍能維持流程連貫？這聽起來像是自相矛盾，但我們相信，針對模型能力與使用者體驗（UX）的精巧研究，可能讓這成為現實。

幻覺式偽程式碼

使用者會撰寫描述期望變更的偽程式碼，接著我們就可以放心交給 Cursor，在背景中將這些偽程式碼轉換成完整的程式碼變更。

多檔案編輯

Cmd-k 已經非常好用了，但如果你可以對整個程式碼庫發出一個通用的編輯指令呢？尤其是那種能夠精準涵蓋多個檔案的編輯？

具前景的方向

擴展推理階段的運算資源。我們知道獎勵模型與拒絕取樣可以帶來快速且容易的改進，但我們還能把效能推進到什麼程度？
更強的推理模型（gpt-5、claude-4、gemini 2.0）
在單一使用者工作區中執行多個 language server／檔案系統副本。這將需要模型的工具使用能力，以及在遠端重現執行環境。
針對代理軌跡訓練／提升模型效能
為流程中進行的非同步編輯進行大量 UX 實驗

最佳脈絡

說明文件可能就有數百萬個 token，原始碼有上千萬個 token，提交歷史又是另一個上千萬個 token，而這些 token 都可能對解決單一查詢有幫助。

更不用說，你的 UI 畫面裡的像素、正式環境與本機上的日誌、Slack 裡的訊息等等……

我們認為，最好的程式開發系統會混合運用檢索（retrieval）、循環機制（recurrence）以及長上下文注意力機制（long-context attention）來吸收並處理所有這些資訊。

我們特別強調「系統」，因為在短期內，這可能會是由多個模型與基礎架構組成的組合，來打造一個用於程式開發的「無限上下文引擎」。從長期來看，我們預期這將會被直接內建到架構之中。

我們對於有創意地思考檢索（retrieval）的未來特別感到興奮。當我們不再侷限於 embeddings，而是在「昂貴的索引處理步驟」加上「便宜的查詢步驟」（相對於語料庫大小為次線性）的這種基本前提下，究竟能達到的最佳效能是什麼？

也許它會長得像某種將 transformer 記憶體作為可微分搜尋索引的變體，也可能完全是別的樣子。這仍是一個尚未被充分探索的研究方向。

多跳上下文

在我的程式碼庫中，我想要計算兩個字串之間的 diff。使用 embeddings，我取得的片段是：

function computeDiff(
  firstModel: ITextModel,
  secondModel: ITextModel,
): string {
  //...
}

為了回應原始查詢，我必須找出如何從一個字串建立一個 ITextModel。這是一個需要兩跳才能解決的查詢。

在程式碼庫中，最難的問題與查詢需要多跳。一般的檢索方式只適用於單跳。

有前景的方向

為程式碼庫設計的專用／強化版 embeddings 與 reranker 模型。
訓練 multi-hop embedders。給定一個查詢以及目前已找到的相關程式碼，決定下一段要跳轉的程式碼。
更聰明的 prefix caching，以及可能更適合程式碼庫的自訂 attention mask。
關於程式碼庫層級檢索的創新研究。
讓模型在權重中「內化」整個程式碼庫，類似把 Transformer 當作搜尋索引來使用。

錯誤偵測與除錯

現有的錯誤偵測系統在結果校準以及對程式碼庫的理解深度方面表現不佳。

模型本身已足夠聰明，能正確找出錯誤，但常被大量誤報所困擾。偵測最棘手的錯誤，往往需要對整個程式碼庫有更深入的理解。而那些看起來像有問題的程式碼，在放到更大的脈絡中檢視後，其實可能是無害的。

其中一種具體呈現方式，是透過語言模型提供大幅更佳的程式碼審查體驗。

在 AI review 中偵測錯誤（bugs）

「AI review」的優點是，使用者對誤報（false-positives）的容忍度較高，因為是他們主動發起這個審查請求。缺點是這需要改變使用者的使用習慣。

AI 程式碼檢查（linting）

偵測錯誤的最佳方式，是一個持續在背景執行、隨時幫你抓 bug 的 linter。由於我們每分鐘會執行數次，它必須使用比 AI-review 更便宜且更快速的模型，同時也必須調整到較低的誤報率。

更智慧的除錯

或許比起偵測錯誤，更令人印象深刻的是能夠除錯棘手的問題。

我們需要超越僅依賴 LLM 的靜態分析。例如，我們打造了一個 cursor/debug 套件。當你在程式碼中引入它時，它會追蹤執行期間的資訊。

在背景執行時，我們甚至可以用它來追蹤更多變數狀態（有點像用 print 進行除錯，但會將相關輸出匯入 Cursor 的上下文中）。

具前景的發展方向

更聰明的資料集整理與篩選（可能包含合成資料），並在前沿程式碼模型上使用 RL（強化學習）來提升校準能力。
從其他工作介面（如瀏覽器或未整合的終端機）追蹤相關資訊。
提升前沿模型在除錯器相關工具使用與工具鏈（chains）上的表現。
無限的上下文長度（context）與幾乎完美的程式碼庫理解能力。
擴充我們的 cursor/debug 函式庫的範圍，以追蹤所有有用的程式執行狀態資訊。

如果你對上述任何一個問題感興趣，請寄信到 hiring@cursor.com 與我們聯絡。

作為我們最初那篇問題文章的延續，以下是我們認為對 AI 程式開發下一階段最重要的一些新課題。

下一步動作預測

Cursor 內建 Copilot++，這是一個更聰明的 copilot 版本，可以預測你的下一個編輯動作。我們能不能把這個想法推到極致？

一開始，我們已將 Copilot++ 擴展為能預測你的下一個游標位置。把這個和下一步編輯預測結合起來，模型就能自動完成一連串低熵變更：

此外，模型應該在你需要的那一刻主動為你提供資訊，無論是正確的程式碼片段，還是正確的文件。

Cursor 應該感覺起來就像你意志的延伸。當你一想到要做出改動，語言模型只需要極少的意圖提示就能立刻替你執行。

具前景的方向

圍繞整個程式碼庫進行 action prediction（動作預測） 的基礎研究。
持續對約 5–13B 活躍參數的程式碼模型進行 pre-training 與 post-training（用於 prefill 受限的低延遲預測）。
類似於 Speculative Edits 的額外推論技巧

在不干擾使用者的前提下，以巧妙的 UX 浮現這些「動作」。（你要如何建議使用者接下來應該切換到哪個檔案？或是目前視窗範圍外的哪個位置？）

完美編輯

我們能否在推理時投入更多計算資源，以產生更高品質、影響範圍更大的編輯？我們又該如何彌補因此增加的延遲？

可能有必要在背景執行這些編輯，啟動一個可以放心交給智慧模型處理的工作單元。

我們將需要具備強大編輯器專用工具使用能力的模型、更聰明的整個程式碼庫層級脈絡理解，以及改進的長期推理能力。

幻覺式偽程式碼

使用者會撰寫描述期望變更的偽程式碼，接著我們就可以放心交給 Cursor，在背景中將這些偽程式碼轉換成完整的程式碼變更。

多檔案編輯

Cmd-k 已經非常好用了，但如果你可以對整個程式碼庫發出一個通用的編輯指令呢？尤其是那種能夠精準涵蓋多個檔案的編輯？

具前景的方向

擴展推理階段的運算資源。我們知道獎勵模型與拒絕取樣可以帶來快速且容易的改進，但我們還能把效能推進到什麼程度？
更強的推理模型（gpt-5、claude-4、gemini 2.0）
在單一使用者工作區中執行多個 language server／檔案系統副本。這將需要模型的工具使用能力，以及在遠端重現執行環境。
針對代理軌跡訓練／提升模型效能
為流程中進行的非同步編輯進行大量 UX 實驗

最佳脈絡

說明文件可能就有數百萬個 token，原始碼有上千萬個 token，提交歷史又是另一個上千萬個 token，而這些 token 都可能對解決單一查詢有幫助。

更不用說，你的 UI 畫面裡的像素、正式環境與本機上的日誌、Slack 裡的訊息等等……

也許它會長得像某種將 transformer 記憶體作為可微分搜尋索引的變體，也可能完全是別的樣子。這仍是一個尚未被充分探索的研究方向。

多跳上下文

在我的程式碼庫中，我想要計算兩個字串之間的 diff。使用 embeddings，我取得的片段是：

function computeDiff(
  firstModel: ITextModel,
  secondModel: ITextModel,
): string {
  //...
}

為了回應原始查詢，我必須找出如何從一個字串建立一個 ITextModel。這是一個需要兩跳才能解決的查詢。

在程式碼庫中，最難的問題與查詢需要多跳。一般的檢索方式只適用於單跳。

有前景的方向

為程式碼庫設計的專用／強化版 embeddings 與 reranker 模型。
訓練 multi-hop embedders。給定一個查詢以及目前已找到的相關程式碼，決定下一段要跳轉的程式碼。
更聰明的 prefix caching，以及可能更適合程式碼庫的自訂 attention mask。
關於程式碼庫層級檢索的創新研究。
讓模型在權重中「內化」整個程式碼庫，類似把 Transformer 當作搜尋索引來使用。

錯誤偵測與除錯

現有的錯誤偵測系統在結果校準以及對程式碼庫的理解深度方面表現不佳。

其中一種具體呈現方式，是透過語言模型提供大幅更佳的程式碼審查體驗。

在 AI review 中偵測錯誤（bugs）

「AI review」的優點是，使用者對誤報（false-positives）的容忍度較高，因為是他們主動發起這個審查請求。缺點是這需要改變使用者的使用習慣。

AI 程式碼檢查（linting）

更智慧的除錯

或許比起偵測錯誤，更令人印象深刻的是能夠除錯棘手的問題。

我們需要超越僅依賴 LLM 的靜態分析。例如，我們打造了一個 cursor/debug 套件。當你在程式碼中引入它時，它會追蹤執行期間的資訊。

在背景執行時，我們甚至可以用它來追蹤更多變數狀態（有點像用 print 進行除錯，但會將相關輸出匯入 Cursor 的上下文中）。

具前景的發展方向

更聰明的資料集整理與篩選（可能包含合成資料），並在前沿程式碼模型上使用 RL（強化學習）來提升校準能力。
從其他工作介面（如瀏覽器或未整合的終端機）追蹤相關資訊。
提升前沿模型在除錯器相關工具使用與工具鏈（chains）上的表現。
無限的上下文長度（context）與幾乎完美的程式碼庫理解能力。
擴充我們的 cursor/debug 函式庫的範圍，以追蹤所有有用的程式執行狀態資訊。

如果你對上述任何一個問題感興趣，請寄信到 hiring@cursor.com 與我們聯絡。

作為我們最初那篇問題文章的延續，以下是我們認為對 AI 程式開發下一階段最重要的一些新課題。

下一步動作預測

Cursor 內建 Copilot++，這是一個更聰明的 copilot 版本，可以預測你的下一個編輯動作。我們能不能把這個想法推到極致？

一開始，我們已將 Copilot++ 擴展為能預測你的下一個游標位置。把這個和下一步編輯預測結合起來，模型就能自動完成一連串低熵變更：

此外，模型應該在你需要的那一刻主動為你提供資訊，無論是正確的程式碼片段，還是正確的文件。

Cursor 應該感覺起來就像你意志的延伸。當你一想到要做出改動，語言模型只需要極少的意圖提示就能立刻替你執行。

具前景的方向

圍繞整個程式碼庫進行 action prediction（動作預測） 的基礎研究。
持續對約 5–13B 活躍參數的程式碼模型進行 pre-training 與 post-training（用於 prefill 受限的低延遲預測）。
類似於 Speculative Edits 的額外推論技巧

在不干擾使用者的前提下，以巧妙的 UX 浮現這些「動作」。（你要如何建議使用者接下來應該切換到哪個檔案？或是目前視窗範圍外的哪個位置？）

完美編輯

我們能否在推理時投入更多計算資源，以產生更高品質、影響範圍更大的編輯？我們又該如何彌補因此增加的延遲？

可能有必要在背景執行這些編輯，啟動一個可以放心交給智慧模型處理的工作單元。

我們將需要具備強大編輯器專用工具使用能力的模型、更聰明的整個程式碼庫層級脈絡理解，以及改進的長期推理能力。

幻覺式偽程式碼

使用者會撰寫描述期望變更的偽程式碼，接著我們就可以放心交給 Cursor，在背景中將這些偽程式碼轉換成完整的程式碼變更。

多檔案編輯

Cmd-k 已經非常好用了，但如果你可以對整個程式碼庫發出一個通用的編輯指令呢？尤其是那種能夠精準涵蓋多個檔案的編輯？

具前景的方向

擴展推理階段的運算資源。我們知道獎勵模型與拒絕取樣可以帶來快速且容易的改進，但我們還能把效能推進到什麼程度？
更強的推理模型（gpt-5、claude-4、gemini 2.0）
在單一使用者工作區中執行多個 language server／檔案系統副本。這將需要模型的工具使用能力，以及在遠端重現執行環境。
針對代理軌跡訓練／提升模型效能
為流程中進行的非同步編輯進行大量 UX 實驗

最佳脈絡

說明文件可能就有數百萬個 token，原始碼有上千萬個 token，提交歷史又是另一個上千萬個 token，而這些 token 都可能對解決單一查詢有幫助。

更不用說，你的 UI 畫面裡的像素、正式環境與本機上的日誌、Slack 裡的訊息等等……

也許它會長得像某種將 transformer 記憶體作為可微分搜尋索引的變體，也可能完全是別的樣子。這仍是一個尚未被充分探索的研究方向。

多跳上下文

在我的程式碼庫中，我想要計算兩個字串之間的 diff。使用 embeddings，我取得的片段是：

function computeDiff(
  firstModel: ITextModel,
  secondModel: ITextModel,
): string {
  //...
}

為了回應原始查詢，我必須找出如何從一個字串建立一個 ITextModel。這是一個需要兩跳才能解決的查詢。

在程式碼庫中，最難的問題與查詢需要多跳。一般的檢索方式只適用於單跳。

有前景的方向

為程式碼庫設計的專用／強化版 embeddings 與 reranker 模型。
訓練 multi-hop embedders。給定一個查詢以及目前已找到的相關程式碼，決定下一段要跳轉的程式碼。
更聰明的 prefix caching，以及可能更適合程式碼庫的自訂 attention mask。
關於程式碼庫層級檢索的創新研究。
讓模型在權重中「內化」整個程式碼庫，類似把 Transformer 當作搜尋索引來使用。

錯誤偵測與除錯

現有的錯誤偵測系統在結果校準以及對程式碼庫的理解深度方面表現不佳。

其中一種具體呈現方式，是透過語言模型提供大幅更佳的程式碼審查體驗。

在 AI review 中偵測錯誤（bugs）

「AI review」的優點是，使用者對誤報（false-positives）的容忍度較高，因為是他們主動發起這個審查請求。缺點是這需要改變使用者的使用習慣。

AI 程式碼檢查（linting）

更智慧的除錯

或許比起偵測錯誤，更令人印象深刻的是能夠除錯棘手的問題。

我們需要超越僅依賴 LLM 的靜態分析。例如，我們打造了一個 cursor/debug 套件。當你在程式碼中引入它時，它會追蹤執行期間的資訊。

在背景執行時，我們甚至可以用它來追蹤更多變數狀態（有點像用 print 進行除錯，但會將相關輸出匯入 Cursor 的上下文中）。

具前景的發展方向

更聰明的資料集整理與篩選（可能包含合成資料），並在前沿程式碼模型上使用 RL（強化學習）來提升校準能力。
從其他工作介面（如瀏覽器或未整合的終端機）追蹤相關資訊。
提升前沿模型在除錯器相關工具使用與工具鏈（chains）上的表現。
無限的上下文長度（context）與幾乎完美的程式碼庫理解能力。
擴充我們的 cursor/debug 函式庫的範圍，以追蹤所有有用的程式執行狀態資訊。

如果你對上述任何一個問題感興趣，請寄信到 hiring@cursor.com 與我們聯絡。