Cursor預測程序員行業倒計時：CTO應做好50%裁員計劃

提供AI咨詢+AI項目陪跑服務，有需要回復1

前兩天跟幾個業內同學做了一次比較深入的探討，時間從15.00到21.00，足足6個小時！

其中有個問題特別有意思：從ChatGPT誕生到DeepSeek爆發2年多了，真正的文字類爆款AI應用是什么？

不出所料，大家一致認為是Cursor，原因很簡單：開源生態的繁榮為代碼領域的AI突破提供了關鍵燃料，而程序員群體對開源的“狂熱”在客觀上創造了大量高質量語料庫。

GitHub上有超過2億個開源倉庫，涵蓋幾乎所有編程語言和技術棧，這種結構化、標注清晰（通過代碼邏輯隱式標注）的文本數據是訓練代碼模型的理想素材。

而開源項目通過社區協作（Pull Request審核、Issue討論）天然篩選出較高質量的代碼，相比通用文本（如社交媒體內容），代碼的噪聲更低、邏輯更嚴謹。

對比其他領域的數據困境：

1. 醫療AI：患者數據涉及隱私，獲取難度極高；
2. 法律AI：判例和合同文本分散且版權敏感；
3. 金融AI：交易數據封閉性強，且噪聲復雜；

代碼領域幾乎是唯一一個數據既開放又結構化的大規模垂直場景，這直接導致代碼AI的“先發優勢”。

但怎么說呢，其結果也許不是好的，因為他真的會大量殺死碼農，所謂程序員“殺死”程序員，老程序員“斷送”新生程序員后路，就是如此...

今天，我們就來簡單介紹下這個“程序員AI殺手：Cursor”！

Cursor

Cursor 是 Anysphere 公司推出智能代碼編輯器。先從資本情況來看看這個產品，恐怖如斯：

1. 2022年獲得1100萬美元種子輪融資；
2. 2024年完成4億美元A輪融資；
3. 2024年底，完成1億美元B輪融資；
4. 2025年3月，Anysphere正與投資者洽談新一輪融資，目標估值接近100億美元；

Cursor基于 VS Code 深度開發，提供?然語??成代碼、上下?感知補全、實時錯誤診斷以及修復等 AI 增強功能，并能?縫融?現有開發環境，顯著提升開發效率與代碼質量。

這里先來個案例嘗嘗鮮：

實際案例

你是?位優秀的 Java ?程師，現在需要根據以下需求構建?個 Java Web 系統。
技術棧要求
Spring Boot + MyBatis + MySQL + Maven
功能需求
你需要開發?個簡單的圖書管理系統，主要包含以下三個管理模塊：
圖書管理：包括圖書的增、刪、改、查功能，每本圖書需要關聯出版社和貨架。
出版社管理：獨?管理出版社信息，?持增、刪、改、查。
貨架管理：獨?管理貨架信息，?持增、刪、改、查。
數據庫設計
設計數據庫結構，創建合適的表，確保數據關聯性（如圖書與出版社、貨架的關聯關系）。
注意數據庫設計不要設計外鍵的關聯關系
?成 init.sql ?件，并將其放? 項?/scripts/ ?錄下。
開發要求
采? Spring Boot 構建后端，并使? MyBatis 進?數據庫操作。
設計 RESTful API，提供對應的增、刪、改、查接?。
采? Maven 進?項?構建和依賴管理。
項?結構清晰，遵循分層架構（如 controller、service、mapper、entity 等）。
編寫適當的測試代碼，確保接?功能正常。
請按照以上需求進?開發，并確保代碼清晰、可讀、易維護。

上圖是Cursor完成后?成的readme?件，項?可以正常啟動，我閱讀了?部分代碼，都是正常可運?，但是測試?例并沒有?成。

接下來，我們需要讓他將測試?例?成，另外我會給他增加?個需求，就是查詢貨架的時候，需要將上?關聯的圖書返回：

Cursor最終?成了所有接?的測試?例，貨架管理模塊要求查詢時返回關聯圖書列表功能也添加成功。

雖然Cursor通過MyBatis的 collection 標簽實現了延遲加載，但這種?式與慣?的 JOIN 查詢結合DTO映射模式存在實現路徑差異，并不符合常見開發習慣和實際項?中代碼?格。

以下是一些實際技巧，大家可參考：

Cursor技巧

三種模式

Cursor提供了三種不同的模式：Agent、Ask和Edit：

模式	核心能力	使用場景	邊界
Agent	全自主項目構建：代碼生成、Shell命令執行、上下文關聯	創建完整項目/復雜任務（重構/糾錯/自動化）	需清晰需求描述
Ask	交互式代碼問答：代碼庫探索/局部修改/調試支持	理解代碼邏輯/快速調試/單文件問題解決	不適合復雜系統級設計
Edit	半自主代碼編輯：功能迭代/規模化修改	新功能開發/重復代碼生成/中規模代碼調整	依賴明確的任務拆解

選擇哪種模式取決于具體需求：

1. 構建新項?或解決復雜問題時選擇Agent模式；
2. 理解和探索代碼庫或進??范圍調整選擇Ask模式；
3. 專注于添加或修改代碼時則選擇Edit模式；

Cursor Rules

Cursor Rules 是一系列自定義規則，指導 AI 生成代碼、提供建議和進行補全。它們對于提升開發效率和代碼質量至關重要：

1. 提?代碼質量：確保 AI ?成的代碼符合你的編碼規范和最佳實踐；
2. 提升開發效率：減少?動編寫重復代碼的時間，讓 AI 幫你完成更多?作；
3. 增強代碼?致性：在團隊項?中，統?代碼?格，避免混亂和沖突；
4. 定制化 AI ?為：根據你的項?需求和個?喜好，定制 AI 的?為，讓它更懂你；

其他技巧

1. 寫好提?詞。明確表達需求，避免模糊或簡略的描述，以確保生成的代碼準確；
2. 定制項目規則。
   為項目設置符合團隊代碼風格和規范的 Cursor Rules，減少后續調整工作量；
3. 任務拆解細化。
   拆解任務：將復雜任務分解為更小、更具體的子任務，以提高生成結果的質量；
4. 系統設計階段，考慮 AI 的參與?式。
   在設計時提前規劃 AI 的參與方式，充分利用其優勢，規避潛在的局限性，提升整體開發效率；

最后進入爭議話題：Cursor到達會不會干掉程序員？

Cursor “殺死”程序員

先說結論：Cursor 確實能在某些場景下實現 10 倍甚? 100 倍的效率提升，但在真實業務開發環境中，實際的效率提升通常不到 30%。

為什么差距會這么?？接下來，我們詳細拆解這個問題：

10倍提效場景

在許多 Cursor 的宣傳案例中，我們經常看到這樣的?例：

輸?提?詞：
"幫我實現?個數獨游戲，使? JavaScript 實現。"

?約 30 秒后，Cursor 即可完成從需求分析、問題拆解、編碼實現到效果預覽的完整流程。?例效果：

這個數獨游戲不僅實現完整，還?持響應式布局。

如果讓開發者?動編碼實現，?約需要 4-8 ?時，? Cursor 僅需 30 秒，提升的效率何? 10 倍？甚? 100 倍。

這類場景的確容易讓?認為 AI 具備顛覆性的效率提升。但我們需要拆解這些案例的特點：

1. 需求清晰、任務簡單：數獨游戲的規則固定，AI 只需基于已有的訓練數據?成代碼，?不需要額外的上下?理解；
2. 代碼質量不重要：在展?“AI 速度”的場景中，代碼的健壯性、可維護性往往被忽略。哪怕?成的代碼不符合團隊規范、不易擴展，也不會影響展?效果；
3. 極端場景的放?：?些演?視頻可能會挑選 AI 表現最優的時刻，?忽略它犯錯的情況。例如，在 Cursor ?成 UI 代碼時，可能會遺漏復雜交互的細節，導致實際使?時需要?量修改；

這種能?對于?專業開發者、初創團隊或需要快速驗證 MVP、短平快的原型開發、簡單?具編寫的場景?常有幫助，讓技術?檻?幅降低。

然?，這僅僅是理想化的場景，現實中的業務開發卻遠?這個復雜得多。

真實場景提效

為了分析 Cursor 在業務開發中的實際提效，我們先拆解前端開發的典型流程，以及各環節的?致時間占?：

開發環節	時間占比
需求分析	10%
技術方案設計	5%
UI 設計與組件開發	20%
業務邏輯與狀態管理	20%
API 集成	15%
路由與權限控制	5%
測試與調試	15%
構建與部署	5%
其他	5%

從表格可以看出，占據開發者較多時間的環節主要是：

1. 需求分析
2. UI 還原與組件開發
3. 業務邏輯實現
4. API 集成與調試

接下來，我們分析 Cursor 在這些環節中的實際表現：

需求分析：Cursor 介?難度極?

原因很簡單：

1. 需求分析涉及業務背景、上下?理解、利益取舍，需要?量主觀判斷。
2. 需求變更頻繁，AI 很難?效處理動態變化。
3. 許多需求難以??然語?準確描述，導致 AI ?成的內容不夠精準。

結論：Cursor 在需求分析環節?乎?法發揮作?。

UI 還原：能?有限，仍需?量??調整

當前 Cursor 可以基于 Figma 設計稿或截圖?成 UI 代碼，但仍然存在較多問題：

1. ?多產品UI?格定制化程度?，AI 難以精準適配。
2. 解析圖?時容易丟失信息，導致代碼偏差較?。
3. ?法抽離公共組件，導致代碼冗余，復?性差。
4. ?法直接與現有組件庫（如 Ant Design、Material-UI、內部?定義組件庫）?縫對接。

結論：還原效果不穩定，仍需?動調整，不如??編碼實現。

業務邏輯實現：Cursor 提效最明顯的環節

如果我們能夠把功能模塊拆解清楚，提供?夠的上下?，清晰表達要做什么事情，Cursor 確實能夠?幅提升開發效率。適?場景：

1. ?成 CRUD 代碼（增刪改查）
2. ?成算法實現（如排序、解析等）
3. ?成?具函數
4. 代碼重構與優化
5. 代碼?動補全與?檔?成
6. 單元測試?例的?成
7. 歷史代碼的閱讀理解
8. 潛在的bug分析

結論：Cursor 在這?環節能帶來 30% 左右的提效。

API 集成與調試：介?難度?

這里的挑戰是：

1. 前后端項?分離，AI對于后端項??感知，?法協同
2. 接?字段對接繁瑣，隱性使?條件多，難以??然語?描述完整

結論：Cursor 在 API 集成環節的作?有限，調試環節?乎?能為?。

小結

綜上所述，在完整的前端開發流程中，Cursor 能真正帶來顯著提效的環節主要是業務邏輯編碼實現，在其他環節的作??常受限。

整體來看：Cursor 實際帶來的提效約為 20%-30%，那么，是否意味著我們只能接受這個上限？并不?定。

何重塑?作流

?媒體宣傳中 Cursor 提效可達 10 倍，?實際業務開發中僅提升 30%，核?區別在于上下?的缺失。

當前 Cursor 在代碼理解和?成??已?常強?，要讓 Cursor 在業務開發中發揮更?作?，我們需要調整?作流，使其更適應 Cursor 參與。

關鍵在于清晰表達需求并提供?夠的上下?。如果 cursor的實現未達預期，先反思??是否描述清楚 ?畢竟，AI ?法讀懂你的?思。

分治思維，逐步驗證

在使?Cursor agent模式的時候，切記不要?次性完成?常龐?的功能再驗證，不然可能會越改越亂。

最佳的實踐：將復雜的功能拆解為多個?的獨?功能模塊，每完成?個?的獨?功能就驗證是否正確，如果正確在進?下?個功能模塊。

結構化需求，讓 AI 能夠更好的理解

從產品源頭采?更標準化的需求?檔格式，如 Markdown、JSON 結構化描述需求。團隊可共享這份結構化的需求?檔，避免開發?次表達導致信息失真。

結合 AI Prompt 設計優化，提?輸?的精準度。

利?反向費曼學習法，通過Cursor chat模式，讓AI反訴需求，看他是否真正理解了你的需求，并讓他提出質疑，去挖掘你更深層次的需求或者?考慮的場景。

提供 UI 設計標準規范、組件庫與 API ?檔等更多上下?

通過Cursor rules提供上下?信息：

代碼與測試?體化

讓 Cursor?成代碼的同時?成單元測試，減少調試時間。

結合 CI/CD 流程，讓 Cursor直接檢測代碼問題。

......

結語

Cursor 作為 AI 輔助開發?具，確實能夠提升開發效率，但如果?作流不變，僅僅依賴 AI 來適應當前流程，最終的提升可能不會超過 30%。

真正的 10 倍效率提升，不是 AI 本?帶來的，?是 結合 AI 進??作流重塑的結果。

如果我們能夠優化需求管理、UI設計標準及組件庫對接、API 接?集成、測試?動化等環節，AI輔助編程?具的潛?才能被真正釋放，實現指數級的效率提升。

最后，依舊要讓各位焦慮一下：

據GitHub數據，AI已參與46%的新代碼生成（2023），Gartner預測2027年AI將承擔40%開發任務。

根據普華永道的報告，到2026年，AI將迫使程序員轉向更具創造性和戰略性的角色，例如AI系統的設計、優化和維護。

因此，程序員未來的競爭力將取決于其對AI工具的掌握以及跨領域的綜合能力，而不是僅僅依賴于編寫代碼的能力。

言盡于此...