編譯 | 伊風

事情的發(fā)展越來越有趣了。

Anthropic 在斷供 WindSurf 模型接入時公開表態(tài)：把 Claude 賣給 OpenAI 的產品，確實“感覺很怪”。這番話，讓不少用戶直接為 WindSurf 判了“技術死刑”。

但更出人意料的是——早在 Claude 4 發(fā)布前，Anthropic 就已經和 Cursor 攜手做了一期技術播客。

再加上 Claude 4 發(fā)布當天，WindSurf 就失去了模型接入權限……這些時機一疊加，不免讓人多想：

難道繼 AI 公司紛紛投靠大廠后，AI 編程產品也得“選邊站”？

現在，這期播客已經可以觀看了。拋開這些商業(yè)角力的八卦不談，這期播客在技術維度上絕對是干貨拉滿！

一邊是被認為在編程能力上遙遙領先的 Claude，另一邊是當下最受歡迎的 AI 編程工具 Cursor，四位核心成員坐在一起，聊透了“AI 正如何重塑軟件開發(fā)”。

圖片

左起：

Jacob，Cursor 研究員，負責機器學習和檢索系統(tǒng)

Aman，Cursor CTO&聯(lián)合創(chuàng)始人，在 Cursor 做機器學習相關工作

Lucas，Cursor研究員，在 Cursor 主要負責 AI 編程系統(tǒng)方面的工作

Alex，Anthropic Claude 的開發(fā)者關系團隊負責人

這場對談不僅涉及技術演進和產品理念，更直面一個核心問題：

當 AI 能“寫代碼”，開發(fā)者還需要什么能力？

話不多說，先來畫個重點：

• Claude 3.5 Sonnet 是一個明顯的轉折點，它讓AI編程從單一的自動補全，走向了多文件、長上下文等復雜任務。
• Claude內部是這么平衡模型代碼能力與其他能力的：代碼不是唯一方向，但研究人員發(fā)現，當模型在代碼上表現得更好時，它們在復雜推理、多步驟任務、agent-style 的交互上也會同步提升。
• Cursor內部堅持使用Cursor做研發(fā)，這樣能最快地試驗新功能，如果不work就立即放棄，不用等用戶數據的反饋。
• Cursor致力開發(fā)的“Background Agent（后臺代理）”，可以直接處理完整的 PR（拉取請求），未來我們會支持同時操作三四個變更，隨時放后臺、拉前臺。
• AI編程接下來的最大瓶頸將是“代碼驗證”。因為模型已經非常擅長生成大量代碼，但開發(fā)者目前已經將70% 花在代碼檢查上。
• AI編程可能將促使一類“更高抽象層級工作的軟件工程師”——他們并不掌握太多底層知識，卻依然能高效地開發(fā)。
• AI編程的強大，反而讓開發(fā)者的角色更重要了：你需要判斷這段代碼應該做什么，你需要有判斷力、品味，你要能引導軟件向正確方向發(fā)展。

以下是經過整理的播客全文，enjoy：

模型帶給Cursor新的可能

主持人 Anthropic Alex:

這次我們既會聊 Cursor 本身，也會聊你們如何與 Claude 集成。今年對 Cursor 來說可謂爆發(fā)式的一年，關注 AI 行業(yè)的人都知道——Cursor 在一年內實現了超 3 億美元營收，這太瘋狂了！現在已經有數百萬開發(fā)者在使用 Cursor。在你們看來，今天的 Cursor 和一年前相比，最大的變化是什么？

CTO Aman：

 我覺得主要有幾件大事發(fā)生。語言模型從一開始就有很大潛力，而 Cursor 算是最早一批真正把這些能力發(fā)揮出來的公司，尤其是在編碼領域。

 與此同時，模型本身的能力也在大幅提升。比如 Claude 3.5 Sonnet 就是一個明顯的轉折點，它讓“代碼生成”變得不再只是自動補全，而是可以處理多文件、上下文更深的任務。在那之前，我們主要做的還是像 tab 補全、局部編輯這些事情。

但當我們把 Sonnet 3.5 的推理能力和我們自己開發(fā)的檢索模型結合起來，再應用到整個代碼編輯流程中時，就打開了“跨文件編輯”這個新維度。我認為那是 Cursor 用戶量激增的真正關鍵點。從那之后，我們一方面跟隨模型能力的提升，另一方面也不斷優(yōu)化底層邏輯，把模型的潛力發(fā)揮到極致。

主持人 Anthropic Alex:

 這條進化路徑是自然演化的，還是說當你們第一次用上 Sonnet 3.5 時立刻意識到“哇，我們現在可以做以前做不到的事了”？這個轉變過程是怎樣的？

CTO Aman：

 其實是漸進的。每次模型升級后，我們都能在使用中隱約感受到它變得更聰明，但那種改變不是立刻就爆發(fā)的。老實說，我們自己有時候都不太擅長“品嘗”這些模型的質量，因為我們使用它們的方式，和真實用戶場景差異挺大。

我們是在反復試錯中，逐步看到某些模型更擅長推理、更能處理通用編碼任務，慢慢摸索出一些可以“真正跑起來”的功能。Sonnet 是第一個讓我們能讓“跨文件交互”真正跑通的模型。后來我們又在“工具調用”和“像 Agent 一樣嵌入編輯器”的方向上，繼續(xù)推進。

主持人 Anthropic Alex:

 明白了。新模型能力的提升，會帶來新的探索機會，然后你們再把這些驗證過的能力轉化為產品功能，回饋到 Cursor 里。

CTO Aman：

 是的，完全可以這么理解。

如何用Cursor開發(fā)Cursor？

主持人 Anthropic Alex:

 那也就引出下一個問題——我聽說你們團隊是在“用 Cursor 開發(fā) Cursor”，形成了一個自我改進的反饋閉環(huán)。你能說說這在日常中是怎么運作的嗎？

Lukas:

 其實這很依賴于每個員工的具體工作內容，也跟他在負責的產品模塊所處階段有關。

比如說你要從頭鋪設一個新模塊，就很適合用 Agent 功能快速生成基本結構；如果是在調 bug，那就很適合用 Claude 這樣的思考型模型；如果是小改動，tab 補全就很好用。對陌生代碼庫，QA 和檢索能力就很關鍵——而 3.5 和 4 系列模型在“代碼結構研究”這塊表現都特別出色。

主持人 Anthropic Alex:

 也就是說，在探索代碼時，這些工具能幫助你搞清結構，而你們在使用過程中發(fā)現某個點做得不夠好，就會反過來改進產品？

Lukas:

 對，我們很多功能其實就是解決自己遇到的痛點。內部試用時，誰卡住了，就會去想“能不能做一個什么功能來解決它”。我們鼓勵每個人都去嘗試添加功能，用完后馬上內部反饋，再決定是否推廣。

主持人 Anthropic Alex:

 那你覺得，從“更高視角”來看，這種“做自己最核心用戶”的狀態(tài)，是一種競爭優(yōu)勢嗎？

CTO Aman：

 絕對是。我們能非常快地試驗新功能，做出一個東西，發(fā)現不好用，立刻扔掉都可以，不用等用戶數據來反饋。內部就能立刻判斷：“這玩意不行?！?所以整個迭代速度快得多。

 而且從我們公司內部來看，其實每個人用 AI 的方式差別也很大。

 主要看你在做什么樣的工作。如果你對某塊代碼庫非常熟悉，你腦中已經有了結構圖，這時候直接敲代碼可能反而更快，而 tab 補全就能幫你大幅提速。

但如果你進入一個不熟悉的模塊，或要寫大量重復邏輯，這些都可以交給模型處理。包括一些基礎推理任務也能靠模型完成。

 像 Lucas 進入 Linear（一個新代碼庫）時就是這樣，你會感受到模型帶來的那種“階躍式提速”。而隨著模型越來越好，Cursor 也越來越能在“你狀態(tài)在線”時幫你加速，在“你迷路時”幫你找路。

主持人 Anthropic Alex:

 聽起來，這些功能的適配性也像是一個“使用光譜”——越熟悉的時候用自動補全，越陌生時就更依賴模型的主動幫助。

CTO Aman：

 是的，可以把這個功能的“使用光譜”想象成一端是“Tab 補全”，適合你完全掌控、明確知道自己在做什么的時候；再往前是“Command+K”編輯某個具體區(qū)域，甚至整個文件；更進一步是“Agent”——它已經能處理多個文件的編輯；而最末端的，就是我們最近一直在開發(fā)的“Background Agent（后臺代理）”，它可以直接處理完整的 PR（拉取請求），非常強大。

主持人 Anthropic Alex:

 你們最近剛發(fā)布了 Background Agent 的預覽版，能介紹一下它是什么嗎？

CTO Aman：

 現在模型在完成端到端任務上確實越來越強，但還沒達到 100%，短期內也不會。這種情況下，加速開發(fā)者的方式，是允許他們并行處理任務，而不是像以前那樣完全“放在后臺跑”，然后出來一個 PR，去 GitHub 審閱。如果這個 PR 只有 90% 完成度，那你就得接管后續(xù)的修改，這時就需要借助 Cursor 的特性，快速在前臺和后臺之間切換。這種流暢切換真的很關鍵?，F在還只是這個功能的早期階段，我可以想象，未來我們會支持同時操作三四個變更，隨時放后臺、拉前臺，非常有趣，可能會改變大家使用 Cursor 和開發(fā)軟件的方式。

Lukas:

 從更廣義的角度看，Background Agent 其實是一種新的“計算原語”（primitive），它可以用在很多地方。目前的交互方式比較直接，就是你輸入提示詞后，它就可以在后臺獨立運行并迭代。但未來我們還會有更多集成方式，支持各種觸發(fā)場景，我覺得這是個有很多產品潛力的方向。

主持人 Anthropic Alex:

 那它是不是把代碼庫放進一個虛擬機里？這個“轉移”到底是怎么發(fā)生的？

Lukas:

 沒錯，我們會啟動一個獨立環(huán)境（VM），預裝好所有開發(fā)環(huán)境工具，Agent 可以直接使用它們。包括所有 VS Code 插件，它可以看到 linter 報錯等。

 AI編程的下一步是“代碼檢查”

主持人 Anthropic Alex:

 現在我們確實看到越來越多的“異步任務”、“后臺任務”，從編碼到研究都是如此。你覺得如果未來我們有成千上萬個代理在后臺并行處理問題，會是什么樣的情景？就像一整支“AI團隊”在后臺作戰(zhàn)一樣？

CTO Aman：

 我覺得接下來最大瓶頸會是“代碼驗證”。模型已經非常擅長生成大量代碼，但設想一下，開發(fā)者的時間可能有 70% 花在代碼審查上，30% 寫代碼。即使寫代碼的部分完全自動化，也只能把效率提升 3 倍。驗證的過程必須優(yōu)化，AI 代碼是否“正確”，這不只是功能實現了這么簡單——還要匹配開發(fā)者的原始意圖。

CTO Aman：

 所以我們要解決的，是如何讓開發(fā)者更容易驗證代碼、對 AI 的修改更有信心。正確性本身很模糊，有時你給 AI 的指令可能并不清晰，它只能在這個含糊的范圍里盡力做到最好。問題是：這是不是你心中真正想要的？所以，我們非常重視優(yōu)化“代碼審查體驗”。

主持人 Anthropic Alex:

 那你們有沒有一些初步的想法？

CTO Aman：

 我們團隊有不少想法在內部討論。其中一個是我們 CEO Michael 特別喜歡的設想：通過一種“抽象表示形式”來操作代碼庫，比如用偽代碼來描述變更，然后系統(tǒng)能確保這些變更與真實代碼完全一致。這樣，驗證過程可以大大縮短。這就類似“vibe coding”模式有效的原因——你可以快速驗證修改是否生效。但在生產環(huán)境里，這套方法很難直接用，如何擴展它，是我們非常重視的問題。

主持人 Anthropic Alex:

 這是個好問題——vibe coding 適用于小工具或 demo，但如果面對的是企業(yè)級代碼庫，上千萬行代碼，這時該怎么做？現階段的模型能勝任嗎？

Jacob：

 這正是我們在設計 Background Agent 時重點考慮的問題。比如說，一個簡單的任務是“這里有個測試失敗了，請修復代碼讓它通過。”這對簡單代碼庫來說不難。但在企業(yè)級項目中，依賴設置可能非常復雜，模型無法直接運行測試。所以我們重點優(yōu)化的是：如何為開發(fā)者自動創(chuàng)建一個可以運行測試的環(huán)境，并使其可重復更新。

這樣一來，模型可以在后臺開啟 VM，不斷嘗試修改，有些能通過測試，有些不能。最終開發(fā)者只需要關注“成功的那個結果”。這個流程的基礎設施和用戶體驗非常重要，我們花了很多精力去打磨。

CTO Aman：

 另外還有一些更底層的問題。就像剛才說的，如果你能讓模型“嘗試讓測試通過”，也許就能一定程度上驗證它。但在大型代碼庫中，你常常會遇到“領域特定語言”（DSL）或定制開發(fā)的工具鏈，幾乎形成了獨特的語言體系，分布在上百萬個文件里，總 token 數量可能達到數億，甚至更多。

 我們已經做了很多工作來提升模型對大規(guī)模代碼庫的理解，包括訓練檢索模型、整合其他上下文來源。例如，最近你在代碼里修改的地方，往往能反映出你正在專注的方向，這其實就蘊含了很多有價值的信息；還有團隊成員最近做的改動，也同樣可以作為提示信號。不過我認為，僅僅給模型提供更好的檢索能力，依然不足以讓它真正“理解”一個龐大的代碼庫。這仍是一個本質性的難題，我們非常希望能解決它。

主持人 Anthropic Alex:

 可能還需要結合“記憶”機制和長上下文窗口來解決吧。

CTO Aman：

 是的，記憶是一種很有意思的嘗試，讓模型能從你與它的使用過程里“學習”。但目前來看，它帶來的性能提升還比較有限，比較原始，離我們真正需要的那種對大規(guī)模代碼庫的掌握，還有很長的路。

Lukas:

 而且在大型代碼庫中，目標不僅僅是“讓測試通過”。更重要的是以正確的方式實現它：要參考已有代碼的風格和結構，把新代碼融入進去，并遵循所有既定的規(guī)范。我們?yōu)榇送度肓撕芏嗯?，比如跨越式?guī)則整合、引入多種上下文來源等。

CTO Aman：

 就拿防抖（debounce）函數舉例，我當然可以手寫一個新的 debounce 函數，讓測試通過，但這并不是正確做法。你應該使用已有的 debounce 函數。但問題是，可能這個項目里已經有三四個類似函數，如何知道該用哪個？可能只有發(fā)個 Slack 問下某位老員工才能搞明白。所以說，在這種體量下，要解決這些問題真的非常困難。

主持人 Anthropic Alex:

 你這個例子很有意思。原來還有這么多組織知識是存在于代碼庫之外的，而這些隱性知識卻會深刻影響開發(fā)決策，尤其在處理大型項目時。

CTO Aman：

 我不認為“組織知識”是當前的主要瓶頸。但就算你讓模型能“完美理解代碼庫”，你可能也就獲得 5 倍、10 倍的提升而已。接下來會卡在另一個瓶頸：模型能否獲取那些永遠不會出現在 PR、代碼注釋或文檔中的信息。這些才是真正影響開發(fā)效率的隱性背景。

Lukas:

 而且很多商業(yè)側的上下文，比如銷售、業(yè)務邏輯，也必須被納入到 Cursor 的體系中，才能真正發(fā)揮作用。

主持人 Anthropic Alex:

 也就是說，未來的 Cursor 需要對接更多系統(tǒng)，才能真正“智能”。

CTO Aman：

 是的，但我覺得這還不是最迫切的任務。眼下我們還有很多路要走，比如更好地利用用戶與代碼庫的交互行為、歷史提交記錄等，來增強 Cursor 的能力。

代碼寫法需要兼顧“模型讀者”嗎？

主持人 Anthropic Alex:

 我最近在網頁內容領域看到一個趨勢，人們開始試圖優(yōu)化頁面以便于大語言模型（LLM）閱讀和理解。你覺得在代碼世界，會不會也出現類似的趨勢？比如說，代碼寫法將不再只針對“人類讀者”，而是要兼顧“模型讀者”？

Lukas:

 這個趨勢其實已經開始了。比如 API 設計正在發(fā)生變化——我們不僅改內部版本號，還會顯式地告訴模型這是新版 API，確保它能正確調用。而普通代碼和內部庫的寫法也在改變，我們試圖避免深層嵌套結構，盡量把代碼結構保持在兩層以內，這樣模型理解起來會更輕松。

Jacob：

 其實“干凈代碼”（clean code）的原則，既適用于人類，也適用于模型。你要避免重復、避免不必要的復雜結構，這對人和 AI 都很重要。未來，隨著 AI 編碼能力增強，我們能寫出更多代碼，那就更要注重代碼的整潔性和美感。

主持人 Anthropic Alex:

 說得很好，尤其是“品味”這個話題。我感覺有些人天生審美好一點，但大多數人還是靠經驗，靠踩坑學來的。在 AI 參與代碼創(chuàng)作越來越多的今天，很多人擔心，這會不會讓年輕程序員變懶，失去從零構建復雜系統(tǒng)的機會？你們怎么看這個問題？要如何在“AI 助力”和“保留工程師核心能力”之間找到平衡？

Jacob：

 我覺得這些工具在教育層面也非常有價值，能幫助開發(fā)者成長。如果你對某段代碼不理解，現在可以直接按 Command+L 問 Claude：“這是什么？怎么工作的？”它會一步步解釋給你聽。這種能力讓你寫出更多代碼，確實會出現質量參差不齊的問題，但總體上，這是一個能顯著提升門檻的強大工具。

Lukas:

 代碼質量很多時候來源于快速迭代——你犯錯，修復，理解為什么失敗，再改進。我認為 AI 模型極大地加快了這個反饋循環(huán)，讓你更快地知道什么方法有效、什么不行。從長期看，這對初學者和有志于承擔更復雜項目的開發(fā)者都是非常有益的。

CTO Aman：

 我覺得接下來程序設計會如何演變會很有意思。未來很長一段時間內，我們仍然需要那些了解底層細節(jié)、能深入“草叢”的工程師。但我也在想，會不會慢慢出現一種新型開發(fā)者——他們并不掌握太多底層知識，卻依然能高效地開發(fā)。我覺得現在階段，你仍然需要理解大量細節(jié)，但隨著時間推移，可能會出現一類主要在更高抽象層級工作的軟件工程師。

 也許未來開發(fā)者的“品味”會更像在做交互設計。比如你要構建一個類似 Notion 的應用，最終你無法完全把這事交給語言模型來做。你需要去表達：“當我進行某種交互時，我希望頁面這樣彈出來?！?也許你不需要具體寫實現邏輯，但仍需要清晰地描述交互意圖和系統(tǒng)大致行為——這其實也是一種編程方式。

如何在Cursor里集成最新的Claude模型

主持人 Anthropic Alex:

 換個話題，我們來聊聊模型。等這個視頻上線時，Claude Opus 4 和 Sonnet 4 已經發(fā)布了。想聽聽你們對新模型的看法，以及打算如何將它們集成到 Cursor 里？

CTO Aman：

 我們真的非常喜歡這些新模型。第一次試用新版 Sonnet 時我們都挺震驚的。3.7 已經是非常優(yōu)秀的模型，在“目標明確地解碼”方面表現很強，但大家也知道它有些缺陷，比如有點過于積極。

主持人 Anthropic Alex:

 就是太愛主動“做事”了（笑）。

CTO Aman：

 對，比如它會主動修改測試用例。Sonnet 4 基本修復了這些問題，表現好得多。而且它的“智能程度”也明顯躍升——我們見過一些模型也在“智能性”方面進步了，但還不如 Opus 3 的解碼表現。而 Sonnet 4 則可以與其平起平坐，但價格卻便宜很多。所以我們對 Opus 4 非常興奮，覺得它會成為后臺執(zhí)行任務時的理想選擇。

主持人 Anthropic Alex:

 太好了！我們這次確實花了很多精力解決“測試編寫”和“過度熱情”這類問題，特別是reward hacking——模型為了拿到獎勵信號，會嘗試走捷徑。這次我們把這種現象削減了大約 80%。

CTO Aman：

 我一直挺好奇，3.5 Sonnet 是怎么誕生的？感覺它是 Anthropic 第一個真正意義上的“高質量代碼模型”。

主持人 Anthropic Alex:

 怎么誕生的？其實就是訓練出來就很不錯（笑）。說實話，從公司創(chuàng)立初期我們就知道，“讓模型擅長寫代碼”這事非常重要，尤其是當你打算構建更多模型時。3.5 Sonnet 是我們第一次系統(tǒng)性投入資源來打磨代碼能力，尤其是跨文件編輯、工具調用、長任務規(guī)劃等“遠距離代碼能力”。我們把所有這些能力整合到一體，結果非常好，也為之后的模型定下了基調。

CTO Aman：

 那你們是怎么平衡“代碼能力”與其他方向的？比如 Opus 和 Sonnet 除了寫代碼，還有哪些重點領域？

主持人 Anthropic Alex:

 代碼當然是主要方向之一，但并不是唯一。我們發(fā)現，當模型在代碼上表現得更好時，它們在復雜推理、多步驟任務、agent-style 的交互上也會同步提升。而這些能力對需要融合代碼、信息檢索、研究任務的應用場景非常有用。

 總的來說，我們就是在不斷推動模型能力的邊界。當然我們會考慮安全性，確保模型輸出對用戶有幫助，且符合我們對 AI 應有行為的判斷。但我們也希望向世界展示模型到底能做到什么，比如去年 10 月發(fā)布的 computer use（屏幕理解和操作）能力，這是另一個重大方向——模型直接閱讀屏幕圖像，并在 UI 上完成類似人類操作，而不是只靠 API 或工具調用。

 還有一個我們特別重視的方面是“角色感”。Amanda Askew 是我們這方面的核心研究人員之一，專門負責Claude 的性格與人設打造。我們花了很多精力思考 Claude 應該給人怎樣的感受、說話風格應該如何。畢竟它不僅是代碼助手，還可能成為用戶的傾訴對象、陪伴者。這影響我們對訓練策略的很多決策。

CTO Aman：

 那從 Anthropic 整體來看，你們是如何看待未來的發(fā)展方向？不管是軟件工程領域，還是 AI 研究的長期演變——比如模型將如何增強、替代或重塑現有工作流？

主持人 Anthropic Alex:

 我可以說說我個人的看法。就像我們之前聊到的，我不覺得我們是在“被取代”，而是因為現在有了能幫你完成很多“機械性敲代碼”的模型，我們其實能做的事更多了。拿我自己舉例，我大學是學計算機的，也做過軟件工程工作。現在如果你讓我做一道 LeetCode 題，模型肯定寫得比我快、比我好——它就是比我強（笑）。

但有意思的是，我反而覺得自己現在能做的比過去更多。我可以用模型快速做出原型，迅速搭一個 demo，如果我想展示某個新概念，完全可以在幾小時內做出個雛形。這種感覺非常賦能，而不是讓人覺得自己被拋棄了。

 而且我覺得，正因為我有過去寫代碼的經驗，我能更好地“駕馭”這些模型。我知道它們哪里好、哪里要引導，如果我完全不懂編程，那我可能就不會知道怎么“用對”?！f到未來，我們來預測一個問題好了，兩年后回來看這條回答可能會很有意思：

假設是 2027年1月1日，你們覺得那時世界上有多少代碼是由 AI 生成的？而那時候開發(fā)者的“日常工作”又會變成什么樣？

Jacob：

 這就像問 1995 年的律師，“未來的法律文件會有多少是用文字處理器寫出來的？” 答案是——幾乎 100%。AI 將參與未來絕大多數代碼的編寫。

但即便如此，開發(fā)者的角色反而更重要了：你需要判斷這段代碼應該做什么，你需要有判斷力、品味，你要能引導軟件向正確方向發(fā)展。

CTO Aman：

 說實話，我們現在在 Cursor 里就已經接近 90% 的代碼由 AI 生成了。因為我們大量使用高階功能，比如 Ask, MCC, 自動補全等等。而就算是你手動敲代碼時，也往往是你敲幾個字，Tab 自動幫你補完后面的 70%。所以即使你“在寫”，其實也有大部分是 AI 在協(xié)助。

主持人 Anthropic Alex:

 從“鍵盤打下去的字符數”來看，應該已經占比很低了。

CTO Aman：

 沒錯。我覺得，軟件開發(fā)的每一個環(huán)節(jié)，未來都會在某種程度上與 AI 結合。

主持人 Anthropic Alex:

 你覺得我們會不會最終進入一個“按需生成軟件”的世界？那時會是什么樣子？

Jacob：

 我認為我們會看到，很多原本不是開發(fā)者的人也開始寫軟件，比如銷售人員以前不會寫代碼，但未來他們可以自己搭建一個儀表盤來追蹤自己關注的關鍵指標。

這時候，“審美”就變得非常重要——你可以生成一個 dashboard，但你仍然需要決定它展示哪些數據，這個判斷 AI 代替不了。

我們會看到更多人“造自己的軟件”，但瓶頸在于：你能不能定義出一個獨特的需求，而不是重復已有工具。

主持人 Anthropic Alex:

 我特別喜歡的一個例子是：我們有個公關團隊的同事，居然在修復 Claude AI 的生產環(huán)境 bug！他本身完全不是產品線的一員，突然跳出來提了一個 PR，我們當時都驚了，結果發(fā)現他用 Claude Code 這類工具就能修補代碼了。

Jacob：

 沒錯，他修的是正式代碼庫里的 bug（笑）。

主持人 Anthropic Alex:

 這真的很厲害。這也說明——只要你有判斷力和直覺，你就能做很多事。我覺得未來角色會變、工作樣貌會變，但如果你能用這些工具做更多的事，那一定是件好事。

CTO Aman：

 我覺得這條路未來會有很多“分支”。其中一個極端的版本是：你用的軟件會根據你的使用方式實時改變。比如你用了某個功能覺得不爽，下一次它就自動改掉了。

你甚至不需要主動去改代碼，系統(tǒng)會根據你交互中的行為自己適配，這就很酷。我不確定未來是不是所有人都想自己寫軟件，但“需要個性化軟件”的人群可能是整個世界。

主持人 Anthropic Alex:

 好，那最后一個問題吧：如果有一位優(yōu)秀工程師在看這段視頻，他/她正打算找下一份工作，猶豫要不要加入像 Cursor 這樣的初創(chuàng)公司，或者去更大的平臺，你們會對他說什么？

CTO Aman：

 我覺得現在初創(chuàng)公司在吸引頂尖人才方面越來越有優(yōu)勢。像 Anthropic 或 Cursor 這樣的團隊，能吸引到非常棒的人才，這在大公司反而很難做到。

大公司當然也有優(yōu)秀的人，但人才密度（talent density）低。而在一個小團隊中，你能每天跟很多超棒的同事一起工作，大家都能碰撞出很強的能量。

你在構建改變世界的軟件和模型，而你不是幾千人中的一個小螺絲釘——而是幾十人、甚至十幾人里的一份子。這是非常有成就感的事。

主持人 Anthropic Alex:

 真的太棒了！感謝你們的分享，這次聊天非常精彩。

CTO Aman：

 謝謝你，謝謝大家！