我們要解決的問題

更新：我們又寫了 更多問題。

一份由簡短、具體問題組成的不分先後清單：

更好的脈絡（context）： 在程式碼編輯器裡有非常多資訊來源：開啟的檔案、語意上相似的程式碼區塊、符號上互相關聯的類別、lint 輸出、執行軌跡、git 歷史紀錄、打字歷史紀錄、外部文件等等。我們希望讓模型能立即理解，對使用者問題來說最相關的是哪些內容，目前正在訓練一個客製且快速的 reranker 模型來解決這個問題。對於每個請求，我們會從所有不同來源收集 500k token，並使用我們的 reranker 將它們過濾成最相關的 8k token。這同時是一個模型層面的問題，而且愈來愈是一個基礎建設層面的問題。
「專注在編輯的 copilot」： 雖然 GitHub Copilot 在撰寫新程式碼時，對於消除低熵按鍵輸入（keystrokes）非常有幫助，但當你需要對既有的程式碼區塊做一些小而簡單的修改時，它並不會幫你節省那些低熵輸入。想像一下，為了進行一個只比符號層級的 F2 重新命名再複雜一點點的 rename，你需要做的游標移動、刪除和輸入按鍵。我們在 UX（在你寫程式時，以不打擾的方式顯示 diff）以及模型端都需要創新（光靠提示詞不夠，因為有成本、延遲，以及智慧程度等問題）。
受限且能融入流程的代理： 想像成 OpenAI 的 code interpreter，但用在大型程式碼庫的工程場景。你對一個受限制、步驟不多的代理說明要做什麼，它會替你搜尋、撰寫並執行程式碼，並且時不時向你徵求回饋。實現這件事的第一步（我們現在正著手進行）是做出一個能在幾十萬 token 規模資料夾上運作的這類代理。如果成功，我們就會把它擴展到整個程式碼庫的規模。
找 bug： 這裡有兩種模式：(1) 在背景中，Cursor 會持續被動地掃描你的檔案，幫你尋找潛在的 bug；(2) 當你正深入除錯時，Cursor 會在你的協助下主動尋找 bug。這裡有非常多有趣的資料收集工作可以做。
更大範圍的編輯： Cursor 應該能替你修改整個檔案，甚至整個目錄。這在能力與 UX 上都是一項挑戰。為了速度，模型必須足夠聰明，能挑出需要修改的部分，而不是把所有東西重寫一次。為了讓體驗良好，變更需要以可解析、即時的形式呈現。
規模： 截至 2023 年 10 月 12 日，我們已經對 14 億個向量與 15 萬個程式碼庫做了索引處理。到今年年底，這個數字很可能會成長 10 倍。我們已經用 Rust 打造了一個非常快速、基於 Merkle tree 的程式碼庫同步引擎，而且很可能很快就需要打造一套自訂的索引系統。

未來想法：

時間扭曲（Time warp）：預測並顯示你在接下來 15 分鐘內會做的跨檔案程式碼變更。一個按鍵指令即可接受所有新增／刪除。
理解（Understanding）：我們的模型應該能在權重中深刻理解任何程式碼庫裡的所有概念。
閱讀模式（Reader mode）：透過任意精細程度的文件，以及一個帶你走過相關程式碼路徑、在需要時進行說明的 bot，讓理解程式碼變得毫不費力。
Pseudo-code 模式：編輯你程式碼的「大綱」表示法，並讓這些變更自動套用到原始碼層級。
再也不用為 stack trace 擔心：IDE 應該自己就能理解，並自動幫你修好程式碼。

我們試著把目前正在思考的所有問題都收集起來，但——這也是每天花 12 小時使用自己產品這件事如此美妙的原因之一——我們不斷會有新點子並重新調整優先順序，所以這份清單不該被當成一份終極、完整的藍圖。話雖如此，我們仍希望這能讓你感受到，我們每天把心力花在什麼事情上。

另外，你已經讀到這麼後面了，看起來你很可能對我們感興趣的這些問題也有點興趣 :)。如果真是如此，你應該考慮加入我們！以下是幾個我們認為你會喜歡和我們一起工作的其他理由：

人們喜歡使用 Cursor。 對於我們目前的成長，我們相當滿意。
你會在這裡和非常聰明的人一起工作。 我們非常相信人才密度。你在這裡合作的每一個人都會非常非常優秀。
AI（人工智慧）輔助程式開發是一個龐大的市場。 而且我們有機會拿下這個市場。
這件事很好玩。 這對我們來說非常重要！和你喜歡的夥伴一起工作是件有趣的事；打造一個產品，讓你按下 Cmd-Shift-R 就能立刻看到使用者回饋——而這個正在寫程式的目標使用者正是你自己——也很有趣；每天都能在把程式開發中所有無聊的部分自動化這條路上多推進一點，更是件有趣的事。
我們非常努力。 能夠處理這些問題讓我們覺得很幸運，我們也享受為了解決它們而全力以赴。

更新：我們又寫了 更多問題。

一份由簡短、具體問題組成的不分先後清單：

更好的脈絡（context）： 在程式碼編輯器裡有非常多資訊來源：開啟的檔案、語意上相似的程式碼區塊、符號上互相關聯的類別、lint 輸出、執行軌跡、git 歷史紀錄、打字歷史紀錄、外部文件等等。我們希望讓模型能立即理解，對使用者問題來說最相關的是哪些內容，目前正在訓練一個客製且快速的 reranker 模型來解決這個問題。對於每個請求，我們會從所有不同來源收集 500k token，並使用我們的 reranker 將它們過濾成最相關的 8k token。這同時是一個模型層面的問題，而且愈來愈是一個基礎建設層面的問題。
「專注在編輯的 copilot」： 雖然 GitHub Copilot 在撰寫新程式碼時，對於消除低熵按鍵輸入（keystrokes）非常有幫助，但當你需要對既有的程式碼區塊做一些小而簡單的修改時，它並不會幫你節省那些低熵輸入。想像一下，為了進行一個只比符號層級的 F2 重新命名再複雜一點點的 rename，你需要做的游標移動、刪除和輸入按鍵。我們在 UX（在你寫程式時，以不打擾的方式顯示 diff）以及模型端都需要創新（光靠提示詞不夠，因為有成本、延遲，以及智慧程度等問題）。
受限且能融入流程的代理： 想像成 OpenAI 的 code interpreter，但用在大型程式碼庫的工程場景。你對一個受限制、步驟不多的代理說明要做什麼，它會替你搜尋、撰寫並執行程式碼，並且時不時向你徵求回饋。實現這件事的第一步（我們現在正著手進行）是做出一個能在幾十萬 token 規模資料夾上運作的這類代理。如果成功，我們就會把它擴展到整個程式碼庫的規模。
找 bug： 這裡有兩種模式：(1) 在背景中，Cursor 會持續被動地掃描你的檔案，幫你尋找潛在的 bug；(2) 當你正深入除錯時，Cursor 會在你的協助下主動尋找 bug。這裡有非常多有趣的資料收集工作可以做。
更大範圍的編輯： Cursor 應該能替你修改整個檔案，甚至整個目錄。這在能力與 UX 上都是一項挑戰。為了速度，模型必須足夠聰明，能挑出需要修改的部分，而不是把所有東西重寫一次。為了讓體驗良好，變更需要以可解析、即時的形式呈現。
規模： 截至 2023 年 10 月 12 日，我們已經對 14 億個向量與 15 萬個程式碼庫做了索引處理。到今年年底，這個數字很可能會成長 10 倍。我們已經用 Rust 打造了一個非常快速、基於 Merkle tree 的程式碼庫同步引擎，而且很可能很快就需要打造一套自訂的索引系統。

未來想法：

時間扭曲（Time warp）：預測並顯示你在接下來 15 分鐘內會做的跨檔案程式碼變更。一個按鍵指令即可接受所有新增／刪除。
理解（Understanding）：我們的模型應該能在權重中深刻理解任何程式碼庫裡的所有概念。
閱讀模式（Reader mode）：透過任意精細程度的文件，以及一個帶你走過相關程式碼路徑、在需要時進行說明的 bot，讓理解程式碼變得毫不費力。
Pseudo-code 模式：編輯你程式碼的「大綱」表示法，並讓這些變更自動套用到原始碼層級。
再也不用為 stack trace 擔心：IDE 應該自己就能理解，並自動幫你修好程式碼。

人們喜歡使用 Cursor。 對於我們目前的成長，我們相當滿意。
你會在這裡和非常聰明的人一起工作。 我們非常相信人才密度。你在這裡合作的每一個人都會非常非常優秀。
AI（人工智慧）輔助程式開發是一個龐大的市場。 而且我們有機會拿下這個市場。
這件事很好玩。 這對我們來說非常重要！和你喜歡的夥伴一起工作是件有趣的事；打造一個產品，讓你按下 Cmd-Shift-R 就能立刻看到使用者回饋——而這個正在寫程式的目標使用者正是你自己——也很有趣；每天都能在把程式開發中所有無聊的部分自動化這條路上多推進一點，更是件有趣的事。
我們非常努力。 能夠處理這些問題讓我們覺得很幸運，我們也享受為了解決它們而全力以赴。

更新：我們又寫了 更多問題。

一份由簡短、具體問題組成的不分先後清單：

更好的脈絡（context）： 在程式碼編輯器裡有非常多資訊來源：開啟的檔案、語意上相似的程式碼區塊、符號上互相關聯的類別、lint 輸出、執行軌跡、git 歷史紀錄、打字歷史紀錄、外部文件等等。我們希望讓模型能立即理解，對使用者問題來說最相關的是哪些內容，目前正在訓練一個客製且快速的 reranker 模型來解決這個問題。對於每個請求，我們會從所有不同來源收集 500k token，並使用我們的 reranker 將它們過濾成最相關的 8k token。這同時是一個模型層面的問題，而且愈來愈是一個基礎建設層面的問題。
「專注在編輯的 copilot」： 雖然 GitHub Copilot 在撰寫新程式碼時，對於消除低熵按鍵輸入（keystrokes）非常有幫助，但當你需要對既有的程式碼區塊做一些小而簡單的修改時，它並不會幫你節省那些低熵輸入。想像一下，為了進行一個只比符號層級的 F2 重新命名再複雜一點點的 rename，你需要做的游標移動、刪除和輸入按鍵。我們在 UX（在你寫程式時，以不打擾的方式顯示 diff）以及模型端都需要創新（光靠提示詞不夠，因為有成本、延遲，以及智慧程度等問題）。
受限且能融入流程的代理： 想像成 OpenAI 的 code interpreter，但用在大型程式碼庫的工程場景。你對一個受限制、步驟不多的代理說明要做什麼，它會替你搜尋、撰寫並執行程式碼，並且時不時向你徵求回饋。實現這件事的第一步（我們現在正著手進行）是做出一個能在幾十萬 token 規模資料夾上運作的這類代理。如果成功，我們就會把它擴展到整個程式碼庫的規模。
找 bug： 這裡有兩種模式：(1) 在背景中，Cursor 會持續被動地掃描你的檔案，幫你尋找潛在的 bug；(2) 當你正深入除錯時，Cursor 會在你的協助下主動尋找 bug。這裡有非常多有趣的資料收集工作可以做。
更大範圍的編輯： Cursor 應該能替你修改整個檔案，甚至整個目錄。這在能力與 UX 上都是一項挑戰。為了速度，模型必須足夠聰明，能挑出需要修改的部分，而不是把所有東西重寫一次。為了讓體驗良好，變更需要以可解析、即時的形式呈現。
規模： 截至 2023 年 10 月 12 日，我們已經對 14 億個向量與 15 萬個程式碼庫做了索引處理。到今年年底，這個數字很可能會成長 10 倍。我們已經用 Rust 打造了一個非常快速、基於 Merkle tree 的程式碼庫同步引擎，而且很可能很快就需要打造一套自訂的索引系統。

未來想法：

時間扭曲（Time warp）：預測並顯示你在接下來 15 分鐘內會做的跨檔案程式碼變更。一個按鍵指令即可接受所有新增／刪除。
理解（Understanding）：我們的模型應該能在權重中深刻理解任何程式碼庫裡的所有概念。
閱讀模式（Reader mode）：透過任意精細程度的文件，以及一個帶你走過相關程式碼路徑、在需要時進行說明的 bot，讓理解程式碼變得毫不費力。
Pseudo-code 模式：編輯你程式碼的「大綱」表示法，並讓這些變更自動套用到原始碼層級。
再也不用為 stack trace 擔心：IDE 應該自己就能理解，並自動幫你修好程式碼。

人們喜歡使用 Cursor。 對於我們目前的成長，我們相當滿意。
你會在這裡和非常聰明的人一起工作。 我們非常相信人才密度。你在這裡合作的每一個人都會非常非常優秀。
AI（人工智慧）輔助程式開發是一個龐大的市場。 而且我們有機會拿下這個市場。
這件事很好玩。 這對我們來說非常重要！和你喜歡的夥伴一起工作是件有趣的事；打造一個產品，讓你按下 Cmd-Shift-R 就能立刻看到使用者回饋——而這個正在寫程式的目標使用者正是你自己——也很有趣；每天都能在把程式開發中所有無聊的部分自動化這條路上多推進一點，更是件有趣的事。
我們非常努力。 能夠處理這些問題讓我們覺得很幸運，我們也享受為了解決它們而全力以赴。