更多問題 · Cursor

承接我們的原始問題貼文，以下是我們認為在 AI（人工智慧）程式開發下一階段最重要的一些問題。

下一步動作預測

Cursor 內建Copilot++，這是更聰明的 Copilot 版本，能預測你接下來的編輯。我們能把這個理念發揮到極致嗎？

在寫程式時，你不只進行低熵的編輯；在整個編輯器裡，你的按鍵、點擊與各種操作也多是低熵的。我們能否打造一個模型，以低延遲預測每一項行為？

首先，我們已將 Copilot++ 擴充，讓它能預測你的下一個游標位置。再搭配下一次編輯的預測，模型即可連續執行一系列低熵變更：

我們按下 Tab 鍵 11 次，其他鍵各按 3 次。這稱作 Cursor Flow（原因顯而易見）。

我們正在開發能預測你下一步操作的能力：你接下來會切換到哪個檔案、即將在終端機執行的指令，以及基於你先前終端機指令所做的下一次編輯——一個下一步動作預測模型。

此外，模型應在你需要的當下即時提供資訊，無論是合適的程式碼片段或相關文件。

Cursor 應該讓你感到它就是你意志的延伸。當你剛想到要做出變更時，模型只需極少的明確意圖即可即時執行。

值得期待的方向

針對整個程式碼庫的動作預測之基礎研究。
針對約 5–13B 參數規模的程式碼模型，持續進行前訓練與後訓練（用於 prefill 受限的低延遲預測）。
與Speculative Edits

以不打擾的方式呈現「操作」的巧妙 UX。（你會怎麼建議使用者下一步切換到哪個檔案？或是導引到當前視窗可視範圍之外的下一個位置？）

完美修改

我們能否在推論時擴充運算資源，以產生更高品質、規模更大的編輯？面對因此增加的延遲，我們該如何補償？

有時可能需要在背景中進行該項編輯。將可放心交由智慧模型處理的一段工作分派出去。

我們需要具備強大編輯器工具使用能力的模型、更智慧的全程式碼庫脈絡處理，以及更佳的長期推理能力。

我們要如何讓非同步的程式碼生成也能保留流程？這聽起來像是自相矛盾，但我們相信，透過對模型能力與使用者體驗（UX）的巧妙研究，有機會做到。

幻覺式偽程式碼

我們先撰寫尚不存在的函式或程式碼，接著模型會在背景中為我們自動生成它們。

使用者先撰寫描述所需變更的偽程式碼，接著即可放心交由 Cursor 在背景將偽程式碼轉換為完整的變更。

多檔編輯

Cmd‑k已經相當強大，但如果你能對整個程式碼庫提出一個通用的編輯需求呢？尤其是那種能準確跨越多個檔案的變更？

有前景的方向

擴大推理時的計算資源配置。我們知道獎勵模型與拒絕抽樣能帶來快速且容易的改進，但我們還能把邊界推到多遠？
更強大的推理模型（gpt-5、Claude-4、Gemini 2.0）
在特定使用者工作區同時執行多個語言伺服器／檔案系統副本。這將需要使用 model 工具，並在遠端重建執行環境。
以代理運行軌跡訓練／提升模型效能
大幅嘗試與改進流程內的非同步編輯體驗

最佳脈絡

文件可能包含數百萬個 tokens，原始碼有數千萬個 tokens，提交紀錄也有數千萬個 tokens——這些 tokens 都可能有助於解決單一查詢。

更不用說，你的 UI 中的像素、在生產環境與本機（localhost）的日誌、Slack 中的訊息等等……

我們相信，最出色的程式開發系統會結合檢索、循環處理，以及長脈絡注意力來吸收這些資訊。

我們強調系統，因為在短期內，這可能是一組由多個模型與基礎設施構成的組合，作為用於程式開發的無限脈絡引擎；從長期來看，我們預期它將被內建進整體架構。

當我們以創新思維想像檢索的未來時，特別讓人振奮。拋開 embeddings 之後，若前置包含昂貴的索引處理步驟、而查詢步驟成本低（相對於語料庫規模為次線性），在此前提下能達到的最佳效能是什麼？

或許它會像將 Transformer 記憶體作為可微分的搜尋索引的某種變體，也可能完全不是這回事。這是一條尚未充分探索的研究方向。

多階段脈絡

在我的程式碼庫中，我想計算兩個字串之間的差異。使用嵌入向量（embeddings）後，我得到以下片段：

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

為了回應最初的問題，我必須找出如何從字串建立 ITextModel。這個問題需要兩個步驟才能解決。

在程式碼庫中，最棘手的問題與查詢往往需要多次推理／串接步驟；而一般的檢索方式只適用於單一步驟（單一 hop）。

值得期待的方向

用於程式碼庫的專用／強化型嵌入模型與重排序器。
訓練多跳式嵌入模型。給定一個查詢與目前已找到的相關程式碼，判斷下一個應跳至的程式碼片段。
更聰明的前綴快取，以及可能更適用於程式碼庫的自訂注意力遮罩。
針對程式碼庫層級檢索的創新研究。
讓模型在其權重中學會一個程式碼庫，類似將 Transformer 當作搜尋索引。

漏洞偵測與除錯

現有的錯誤偵測系統在校準與充分理解程式碼庫方面表現不佳。

模型足夠聰明，能正確找出錯誤，但也常被誤判所困。要辨識最棘手的錯誤，必須更深入理解程式碼庫。而那些看似有問題的程式碼，在放大整體脈絡後可能其實無害。

其中一種具體體現方式，是透過語言模型大幅改善程式碼審查體驗：

在 AI（人工智慧）審查中偵測臭蟲

「AI（人工智慧）審查」的好處在於，由於是使用者主動要求審查，他們對誤判更能容忍。缺點是需要改變使用者的使用習慣。

AI（人工智慧）程式碼 Lint 檢查

偵錯的最佳方案，是一個常駐、在背景持續檢查並攔截錯誤的 linter。由於我們每分鐘會多次執行，它需要使用比 AI-review 更便宜且更快速的 model，並且必須調校至更低的誤報率。

更智慧的偵錯

比起偵測錯誤，更令人印象深刻的是能調試棘手問題。

我們需要超越僅靠 LLM（大型語言模型）的靜態分析。比如說，我們已開發一個 cursor/debug 套件。將它注入你的程式碼後，即可追蹤執行時資訊。

在背景中，我們甚至可以用它來追蹤更多變數狀態（類似於用列印除錯，並將相關輸出導入 Cursor 的 Context）。

具前景的方向

精巧的資料集蒐整與策製（可能包含合成資料），並在前沿程式碼模型上進行強化學習，以提升校準性。
從其他介面（瀏覽器或未整合的終端機）追蹤相關資訊。
提升前沿模型在針對除錯器的工具使用與工作鏈上的效能。
無限脈絡，近乎完美地理解程式碼庫。
擴充我們的 cursor/debug 程式庫，使其能追蹤所有有用的程式狀態資訊。

如果您對上述任何問題有興趣，歡迎透過hiring@anysphere.inc

承接我們的原始問題貼文，以下是我們認為在 AI（人工智慧）程式開發下一階段最重要的一些問題。

下一步動作預測

Cursor 內建Copilot++，這是更聰明的 Copilot 版本，能預測你接下來的編輯。我們能把這個理念發揮到極致嗎？

首先，我們已將 Copilot++ 擴充，讓它能預測你的下一個游標位置。再搭配下一次編輯的預測，模型即可連續執行一系列低熵變更：

我們按下 Tab 鍵 11 次，其他鍵各按 3 次。這稱作 Cursor Flow（原因顯而易見）。

此外，模型應在你需要的當下即時提供資訊，無論是合適的程式碼片段或相關文件。

Cursor 應該讓你感到它就是你意志的延伸。當你剛想到要做出變更時，模型只需極少的明確意圖即可即時執行。

值得期待的方向

針對整個程式碼庫的動作預測之基礎研究。
針對約 5–13B 參數規模的程式碼模型，持續進行前訓練與後訓練（用於 prefill 受限的低延遲預測）。
與Speculative Edits

以不打擾的方式呈現「操作」的巧妙 UX。（你會怎麼建議使用者下一步切換到哪個檔案？或是導引到當前視窗可視範圍之外的下一個位置？）

完美修改

我們能否在推論時擴充運算資源，以產生更高品質、規模更大的編輯？面對因此增加的延遲，我們該如何補償？

有時可能需要在背景中進行該項編輯。將可放心交由智慧模型處理的一段工作分派出去。

我們需要具備強大編輯器工具使用能力的模型、更智慧的全程式碼庫脈絡處理，以及更佳的長期推理能力。

幻覺式偽程式碼

我們先撰寫尚不存在的函式或程式碼，接著模型會在背景中為我們自動生成它們。

使用者先撰寫描述所需變更的偽程式碼，接著即可放心交由 Cursor 在背景將偽程式碼轉換為完整的變更。

多檔編輯

Cmd‑k已經相當強大，但如果你能對整個程式碼庫提出一個通用的編輯需求呢？尤其是那種能準確跨越多個檔案的變更？

有前景的方向

擴大推理時的計算資源配置。我們知道獎勵模型與拒絕抽樣能帶來快速且容易的改進，但我們還能把邊界推到多遠？
更強大的推理模型（gpt-5、Claude-4、Gemini 2.0）
在特定使用者工作區同時執行多個語言伺服器／檔案系統副本。這將需要使用 model 工具，並在遠端重建執行環境。
以代理運行軌跡訓練／提升模型效能
大幅嘗試與改進流程內的非同步編輯體驗

最佳脈絡

文件可能包含數百萬個 tokens，原始碼有數千萬個 tokens，提交紀錄也有數千萬個 tokens——這些 tokens 都可能有助於解決單一查詢。

更不用說，你的 UI 中的像素、在生產環境與本機（localhost）的日誌、Slack 中的訊息等等……

我們相信，最出色的程式開發系統會結合檢索、循環處理，以及長脈絡注意力來吸收這些資訊。

或許它會像將 Transformer 記憶體作為可微分的搜尋索引的某種變體，也可能完全不是這回事。這是一條尚未充分探索的研究方向。

多階段脈絡

在我的程式碼庫中，我想計算兩個字串之間的差異。使用嵌入向量（embeddings）後，我得到以下片段：

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

為了回應最初的問題，我必須找出如何從字串建立 ITextModel。這個問題需要兩個步驟才能解決。

在程式碼庫中，最棘手的問題與查詢往往需要多次推理／串接步驟；而一般的檢索方式只適用於單一步驟（單一 hop）。

值得期待的方向

用於程式碼庫的專用／強化型嵌入模型與重排序器。
訓練多跳式嵌入模型。給定一個查詢與目前已找到的相關程式碼，判斷下一個應跳至的程式碼片段。
更聰明的前綴快取，以及可能更適用於程式碼庫的自訂注意力遮罩。
針對程式碼庫層級檢索的創新研究。
讓模型在其權重中學會一個程式碼庫，類似將 Transformer 當作搜尋索引。

漏洞偵測與除錯

現有的錯誤偵測系統在校準與充分理解程式碼庫方面表現不佳。

其中一種具體體現方式，是透過語言模型大幅改善程式碼審查體驗：

在 AI（人工智慧）審查中偵測臭蟲

「AI（人工智慧）審查」的好處在於，由於是使用者主動要求審查，他們對誤判更能容忍。缺點是需要改變使用者的使用習慣。

AI（人工智慧）程式碼 Lint 檢查

更智慧的偵錯

比起偵測錯誤，更令人印象深刻的是能調試棘手問題。

我們需要超越僅靠 LLM（大型語言模型）的靜態分析。比如說，我們已開發一個 cursor/debug 套件。將它注入你的程式碼後，即可追蹤執行時資訊。

在背景中，我們甚至可以用它來追蹤更多變數狀態（類似於用列印除錯，並將相關輸出導入 Cursor 的 Context）。

具前景的方向

精巧的資料集蒐整與策製（可能包含合成資料），並在前沿程式碼模型上進行強化學習，以提升校準性。
從其他介面（瀏覽器或未整合的終端機）追蹤相關資訊。
提升前沿模型在針對除錯器的工具使用與工作鏈上的效能。
無限脈絡，近乎完美地理解程式碼庫。
擴充我們的 cursor/debug 程式庫，使其能追蹤所有有用的程式狀態資訊。

如果您對上述任何問題有興趣，歡迎透過hiring@anysphere.inc

承接我們的原始問題貼文，以下是我們認為在 AI（人工智慧）程式開發下一階段最重要的一些問題。

下一步動作預測

Cursor 內建Copilot++，這是更聰明的 Copilot 版本，能預測你接下來的編輯。我們能把這個理念發揮到極致嗎？

首先，我們已將 Copilot++ 擴充，讓它能預測你的下一個游標位置。再搭配下一次編輯的預測，模型即可連續執行一系列低熵變更：

我們按下 Tab 鍵 11 次，其他鍵各按 3 次。這稱作 Cursor Flow（原因顯而易見）。

此外，模型應在你需要的當下即時提供資訊，無論是合適的程式碼片段或相關文件。

Cursor 應該讓你感到它就是你意志的延伸。當你剛想到要做出變更時，模型只需極少的明確意圖即可即時執行。

值得期待的方向

針對整個程式碼庫的動作預測之基礎研究。
針對約 5–13B 參數規模的程式碼模型，持續進行前訓練與後訓練（用於 prefill 受限的低延遲預測）。
與Speculative Edits

以不打擾的方式呈現「操作」的巧妙 UX。（你會怎麼建議使用者下一步切換到哪個檔案？或是導引到當前視窗可視範圍之外的下一個位置？）

完美修改

我們能否在推論時擴充運算資源，以產生更高品質、規模更大的編輯？面對因此增加的延遲，我們該如何補償？

有時可能需要在背景中進行該項編輯。將可放心交由智慧模型處理的一段工作分派出去。

我們需要具備強大編輯器工具使用能力的模型、更智慧的全程式碼庫脈絡處理，以及更佳的長期推理能力。

幻覺式偽程式碼

我們先撰寫尚不存在的函式或程式碼，接著模型會在背景中為我們自動生成它們。

使用者先撰寫描述所需變更的偽程式碼，接著即可放心交由 Cursor 在背景將偽程式碼轉換為完整的變更。

多檔編輯

Cmd‑k已經相當強大，但如果你能對整個程式碼庫提出一個通用的編輯需求呢？尤其是那種能準確跨越多個檔案的變更？

有前景的方向

擴大推理時的計算資源配置。我們知道獎勵模型與拒絕抽樣能帶來快速且容易的改進，但我們還能把邊界推到多遠？
更強大的推理模型（gpt-5、Claude-4、Gemini 2.0）
在特定使用者工作區同時執行多個語言伺服器／檔案系統副本。這將需要使用 model 工具，並在遠端重建執行環境。
以代理運行軌跡訓練／提升模型效能
大幅嘗試與改進流程內的非同步編輯體驗

最佳脈絡

文件可能包含數百萬個 tokens，原始碼有數千萬個 tokens，提交紀錄也有數千萬個 tokens——這些 tokens 都可能有助於解決單一查詢。

更不用說，你的 UI 中的像素、在生產環境與本機（localhost）的日誌、Slack 中的訊息等等……

我們相信，最出色的程式開發系統會結合檢索、循環處理，以及長脈絡注意力來吸收這些資訊。

或許它會像將 Transformer 記憶體作為可微分的搜尋索引的某種變體，也可能完全不是這回事。這是一條尚未充分探索的研究方向。

多階段脈絡

在我的程式碼庫中，我想計算兩個字串之間的差異。使用嵌入向量（embeddings）後，我得到以下片段：

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

為了回應最初的問題，我必須找出如何從字串建立 ITextModel。這個問題需要兩個步驟才能解決。

在程式碼庫中，最棘手的問題與查詢往往需要多次推理／串接步驟；而一般的檢索方式只適用於單一步驟（單一 hop）。

值得期待的方向

用於程式碼庫的專用／強化型嵌入模型與重排序器。
訓練多跳式嵌入模型。給定一個查詢與目前已找到的相關程式碼，判斷下一個應跳至的程式碼片段。
更聰明的前綴快取，以及可能更適用於程式碼庫的自訂注意力遮罩。
針對程式碼庫層級檢索的創新研究。
讓模型在其權重中學會一個程式碼庫，類似將 Transformer 當作搜尋索引。

漏洞偵測與除錯

現有的錯誤偵測系統在校準與充分理解程式碼庫方面表現不佳。

其中一種具體體現方式，是透過語言模型大幅改善程式碼審查體驗：

在 AI（人工智慧）審查中偵測臭蟲

「AI（人工智慧）審查」的好處在於，由於是使用者主動要求審查，他們對誤判更能容忍。缺點是需要改變使用者的使用習慣。

AI（人工智慧）程式碼 Lint 檢查

更智慧的偵錯

比起偵測錯誤，更令人印象深刻的是能調試棘手問題。

我們需要超越僅靠 LLM（大型語言模型）的靜態分析。比如說，我們已開發一個 cursor/debug 套件。將它注入你的程式碼後，即可追蹤執行時資訊。

在背景中，我們甚至可以用它來追蹤更多變數狀態（類似於用列印除錯，並將相關輸出導入 Cursor 的 Context）。

具前景的方向

精巧的資料集蒐整與策製（可能包含合成資料），並在前沿程式碼模型上進行強化學習，以提升校準性。
從其他介面（瀏覽器或未整合的終端機）追蹤相關資訊。
提升前沿模型在針對除錯器的工具使用與工作鏈上的效能。
無限脈絡，近乎完美地理解程式碼庫。
擴充我們的 cursor/debug 程式庫，使其能追蹤所有有用的程式狀態資訊。

如果您對上述任何問題有興趣，歡迎透過hiring@anysphere.inc