在 AI Coding 提效這件事上，我想我的經歷讓我有充分的發言權。今年上半年，作為團隊中的 24 屆 JDS，我承接了兩位離職同事的業務模塊。面對密集的大促需求，我不僅扛住了“以一當三”的交付壓力，同時保證了線上零事故。這一切，離不開 Cursor 的深度輔助——我的訂閲也從去年的 Pro 升至 Pro+，甚至在大促攻堅與黑馬程序員大賽期間，不惜投入每月 200 美元升級至 Ultra Plan，只為將開發效率推向極致。
先上乾貨：
Cursor 實戰 case 展示
以下展示了過去一年中，我使用 Cursor 開發的部分前端項目。這些頁面平均的 AI 生成代碼佔比超過 60%，業務場景橫跨 B/C 兩端，技術棧全面覆蓋 Vue、React、通天塔樓層以及 Tailwindcss、Antd 等多種方案，充分體現了 Cursor 全面的技術能力與顯著的效率提升。
移動端
京粉app h5頁面，中秋前夕晚上 22 點業務來電話説想要一箇中秋推廣的活動頁，使用豆包生成背景圖，使用cursor進行樣式設計，0-1開發僅耗費兩個半小時，0:30 完成上線：\
信息流廣告中間頁，UI 提供的初版 Lottie 動畫是一個完整頁面，無法拆分。由於大促排期緊張，等待 UI 支持較慢。為此，我藉助 Cursor 直接解讀 Lottie 的 JSON 配置文件，成功將火焰、殺價、折扣等核心動效元素，精準地解析為獨立的動畫，並通過CSS實現，降低了引入資源體積的同時還優化了動畫的效果，加速通過了協同工作的卡點：\
pc端
東皇鍾資損防控平台，該項目由研發發起，在沒有產品原型和UI設計的情況下，藉助 Cursor 結合 Shadcn UI，我獨立完成了平台 0-1 的交互與界面構建，最終成果獲得了後端與測試團隊的一致好評：\
\
落地頁中心動態分流，該模塊核心代碼近萬行，表單聯動邏輯複雜，整體由 Cursor 生成實現。面對 5 層以上的嵌套數據結構，人工理解其層級關係並控制動態聯動不僅難度大，且極易出錯。通過引入 Cursor，深入解析數據結構與聯動邏輯，顯著降低研發的理解成本，提升整體開發效率。
\
精準鏈路分析項目，黑馬參賽項目，基於 Cursor 從零啓動，單人僅用兩天便快速構建出功能完整的精美 Demo。項目完整實現了基於 React Flow 的 JAVA 調用鏈路展示與組合、AI 流式報告及智能Agent對話等多種高級能力。\
工程化
工程化歷來是前端領域的核心挑戰，充斥着依賴版本衝突與繁雜的配置邏輯。為驗證 Cursor 處理系統級任務的能力，我嘗試將完整升級流程交由它主導：從依賴分析、版本管理到工程配置更新，讓其直接操控終端、執行 npm 命令。
在 京粉 App H5 項目中，我基於 Cursor 成功完成了從舊版本到 Vue 2.7.16 + Webpack 5 的升級全流程：《京粉AppH5 升級 Vue 2.7.16 + Webpack 5 記錄》
cursor 提供的升級方案（部分對話）：\
更新依賴版本和配置文件（部分對話）：\
自動執行終端命令與修復報錯（部分對話）：\
此外，我也讓 Cursor 實現了京粉 h5 從 Webpack 到 Vite 的遷移路徑驗證，核心構建流程已全部跑通。目前因部分邊界場景報錯尚未完全解決，未形成正式文章，但該實踐已初步驗證 Cursor 在複雜工程鏈路中具備可行的輔助潛力。
Cursor 使用經驗分享
重中之重：模型的選擇
模型是 AI 的基座，地基不牢，地動山搖。在此直接上結論：無腦選擇 Claude。\
\
這不僅因為在大模型代碼能力評測中 Claude 持續領先（如上圖所示），更是筆者自 Sonnet 3.5 版本發佈以來，實際體驗 Claude 在代碼生成、邏輯理解與上下文關聯方面的能力，相比同時期的模型，確實一騎絕塵。
需要注意的兩點：
- 警惕 Auto 模式： 若賬號用量不足，Cursor 會自動切換至 Auto 模式，此時可能分配到性能較弱的模型，輸出質量會顯著下降。該模式可用於技術交流，但不建議用於代碼生成與編輯。這也是我升級了訂閲計劃的原因。
- 關注上下文長度： Cursor 會實時顯示上下文使用情況。若接近限制，可主動選擇支持更長上下文的模型，或開啓多倍計費的 Max Mode 以擴展處理能力，避免上下文丟失帶來的輸出質量下降。
Talk is cheap. Show me the code.
相信研發同學對這句話都不陌生。這句話，在此處不妨視作 Cursor 對我們提出的要求。與 Cursor 協作的第一原則是：能提供代碼片段，絕不用文字描述；能用變量名指代的，絕不用中文名。
手動添加上下文
- 選中代碼片段，點擊“添加到聊天上下文”按鈕（快捷鍵 Ctrl+I）；
- 若僅提問不希望 Cursor 改動代碼，可使用 Ctrl+L；
- 在目錄中右鍵點擊文件或文件夾，將其加入對話；
- 在輸入框中輸入 @，手動選擇要引用的文件或目錄。
尤其在涉及多文件改動時，主動告知 Cursor 相關文件路徑，效果遠優於依賴其自行檢索。
統一語義表達
在業務溝通中，請始終使用精準的變量名與 Cursor 交互。例如，在價格相關需求中，應直接使用 purchasePrice、wlPrice 等已有變量名，而非口語化的“到手價”、“京東價”。這能確保 AI 在後續所有交互中對概念理解一致，無需反覆推理映射關係。
同樣，在描述界面元素與交互邏輯時，精準引用標識符而非依賴自然語言描述，是提升 Cursor 理解準確度的關鍵。
- 定位界面元素，應明確指出其
className或id，而非使用模糊的自然語言。\
例如：❌ “那個下載按鈕” → ✅ “類名為.download-btn的按鈕” 或 “ID 為#export-download的元素”。 - 描述交互邏輯，應直接提供回調函數名或方法名稱，而非籠統描述行為意圖。\
例如：❌ “點擊按鈕後彈窗” → ✅ “在handleConfirmClick函數中調用showModal()方法”。
這種方式能夠有效避免界面中存在多個相似元素時造成的歧義，也便於 Cursor 直接在代碼庫中定位相關邏輯，實現精準編輯。
如何使用 cursor 定位故障？
在“AI 能否取代程序員”的持續討論中，精準定位並修復線上故障一直被視作人類工程師的關鍵優勢。其根本原因在於：AI 雖能較好地解析靜態代碼結構，卻難以感知系統運行時的動態狀態。而很多深層問題——如內存泄漏、線程競爭、環境依賴異常等——恰恰隱藏在靜態代碼與動態執行之間的鴻溝中，這構成了當前 AI 在故障處理中的認知邊界。
那麼，我們如何為 AI 架起一座跨越這道鴻溝的橋樑？
答案正在於我們人類最熟悉的調試手段：日誌。既然日誌能夠成為開發者和運行中系統之間的溝通媒介，那麼它同樣可以轉化為 AI 理解運行時行為的關鍵信息來源。
引導 AI 插入關鍵日誌
當你發現某個功能異常，可指示 Cursor 在關鍵邏輯路徑上添加日誌點。只需簡單指令，如：“請幫我在xx功能相關的函數內部添加 console.log，輸出關鍵變量的值。”\
運行代碼並捕獲日誌
執行添加日誌後的代碼，複製運行時所生成的完整日誌輸出。\
將日誌與代碼共同提交給 AI 分析
然後再將日誌複製發送給cursor，神奇的事發生了，本來它改動了幾遍都沒能解決的問題，一下就定位到了根因：\
技巧背後的邏輯
此方法之所以有效，是因為它將 AI 從純粹的代碼靜態分析者，轉變為了一個具備“運行時視野”的調試夥伴。通過日誌，AI 能夠：
- 追蹤變量的實際變化軌跡
- 識別邏輯分支的真實執行路徑
- 發現數據流與預期不符的具體位置
添加 Rules：讓 AI 記住你的工程規範
在使用日誌與 Cursor 協作調試時，我遇到了一個典型問題：項目中已有大量日誌，新增的調試信息很快被淹沒，難以快速定位。我希望 Cursor 在每次插入調試日誌時，自動在開頭附加 【xx功能調試】 這樣的標識，以便在控制枱中快速篩選。但若每次對話都重複這一要求，既低效又容易遺漏。
這時，Cursor 的 Rules 功能便可發揮關鍵作用。你可以在規則中固話這類常見的工程約束或團隊規範，例如：
Cursor 支持為不同項目配置獨立的規則集，靈活適配各工程的特定規範。具體設置方法詳見官方文檔：Cursor - 規則
完成規則配置後，我們重新執行之前的調試對話。如下圖所示，現在每個 console.log 語句的開頭都已自動加上了對應的函數名作為標識，極大方便了在控制枱中的篩選與查看：\
集成 MCP：拓展能力邊界
在使用日誌輔助 Cursor 進行調試的過程中，我逐漸發現兩個影響效率的典型問題：
- 手動複製繁瑣：頻繁從控制枱複製日誌再粘貼至 Cursor，本質上仍是一種重複勞動，與 AI 協作的自動化理念相悖。
- 日誌內容雜亂：控制枱中的引用類型數據（如對象、數組）若不展開或格式不當，難以完整複製；同時，控制枱自動插入的代碼位置信息（文件路徑與行號）常混雜在日誌正文中，導致最終提供給 Cursor 的文本結構混亂、難以解析。\
\
上圖正是這一問題的直觀體現：日誌中穿插了源代碼位置，而對象數據未完整展開，這樣的信息直接交給 Cursor，會影響其理解與推理的準確性。
而此時，正是 MCP（Model Context Protocol）可大顯身手的場景。 通過為 Cursor 配置瀏覽器 MCP 服務，我實現了工作流的質的飛躍：\
MCP 賦予 Cursor 直接控制瀏覽器的能力，使其能夠：
- 自動捕獲頁面截圖
- 直接讀取控制枱日誌
- 分析 DOM 結構\
當前 Cursor 的瀏覽器 MCP 僅支持內置窗口與 Chrome。若你使用 Edge 或其他瀏覽器，可選用微軟推出的 Playwright 作為替代方案。
同時，主流前端工具已紛紛提供 MCP 或知識庫。以 Ant Design 為例，將其官方知識庫 LLMs.txt - Ant Design ，添加到 Cursor 的指定位置：\
\
添加後，Cursor 即可基於官方最新文檔提供準確的組件使用建議。
優先選用 AI “擅長”的技術棧
何為 AI “擅長”的技術棧？簡單來説：React、TailwindCSS 屬於 AI 表現優異的技術棧；微信小程序次之；而像 Taro、uni-app 這類一碼多端的框架，則往往是 AI 的弱項。
其背後的邏輯在於數據可見性：開源生態越豐富、網絡公開樣本越多的技術，大模型在訓練時接觸到的相關代碼就越充分，生成質量自然更高。反之，閉源、文檔稀少的場景，AI 由於缺乏學習材料，表現往往不盡如人意。
在實際的 Taro 項目中，當我嘗試讓 AI 協助處理 H5、小程序與 RN 三端的代碼適配時，其表現確實令人沮喪。我最常遇到的狀況是：好不容易讓 AI 修復了 H5 端的樣式錯位，轉頭就發現小程序端佈局崩潰；當 RN 端的交互問題被解決後，H5 端又出現了新的渲染異常。
因此，在 AI Coding 日益普及的背景下，我們不得不重新審視如 Taro、UniApp 等一碼多端框架的效率等式：其帶來的跨端便利，是否足以抵消因 AI 支持薄弱而導致的額外研發成本？這一點值得深思。
破局之道或許在於深度擁抱 AI 生態。如果這類框架能官方的推出強大的 MCP 服務，將其多端差異和配置邏輯“結構化”地注入 AI 的認知過程，它們將有潛力從當前的“AI 窪地”轉變為“智能跨端”的典範。
反直覺：0-1不難，1-100 更難？
讀過不少 AI 編程文章的人都會發現，多數內容都在展示如何從 0 到 1 快速搭建應用。但實際上存在一個反直覺的真相：用 AI 從 0 到 1 並不難，真正難的是讓它接手和維護存量代碼。
在新項目中，AI 面對的是清晰的上下文和現代技術棧。而在存量代碼中，它需要理解混亂的命名、隱含的業務邏輯和特殊的實現方式，同時要避免“修復一個 bug 引入兩個新 bug”的連鎖反應。這就像讓新人從頭做項目，遠比讓他修改複雜的老系統要簡單。
要讓 AI 有效接手存量代碼，關鍵在於像幫助新人一樣為它提供清晰的指引。核心方法有二：
為 AI 優化的代碼註釋
傳統的業務背景介紹對 AI 幫助有限，應該採用更代碼化的註釋方式。避免長篇大論地介紹業務邏輯，而是清晰地指出代碼和業務之間的關係，魔法數字的具體含義等。
比如，不要寫“這裏是價格計算模塊，因為歷史原因需要區分新老用户”，而應該寫“新用户(level=1)享受首單優惠，老用户(level>=2)按原價計算，優惠金額固定為20”。重點註釋魔法數字的實際含義、複雜條件判斷的業務背景、接口字段的映射關係等。
TypeScript 的天然優勢
在接手現有項目上，TypeScript 有着得天獨厚的優勢。類型定義相當於強制展示了一遍代碼結構，如果再加上每個變量的註釋，就是現成的知識庫。
通過“精準註釋 + 完整類型”的組合，即使是最複雜的遺留代碼，AI 也能快速理解並安全修改，真正突破從 1 到 100 的瓶頸。
AI Coding時代，優秀研發需要哪些新特質？
聊了這麼多 Cursor 的強大表現，難免讓人心生疑問：研發是否正在被 AI 取代？恰恰相反，我認為 AI 正在急劇拉大開發者之間的能力差距。今年幾乎人人都用上了 AI 編程工具，可能是 Cursor，也可能是 Joycode。但如果你去 review 團隊中的代碼，就會發現：強者的代碼因AI而更優秀，弱者的代碼因AI而更紊亂。
結合實踐中的經驗，我總結了 AI 編碼時代一名優秀開發者最應具備的幾種核心能力：
1️⃣有責任心，做代碼的owner
早期使用Cursor時，我常常陷入一種狀態：AI生成的代碼佔比太高，以至於我對新增部分失去理解和掌控。一旦被問及業務邏輯，或是出現線上問題，甚至會不知從何查起。
這就像一位藝術家通過AI生成畫作，很難像對待自己親筆作品那樣珍視並負責。我的改進方案是：在每次 Agent 完成編碼之後，閲讀其改動總結；在每次提交前，仔細Review Cursor生成代碼的Diff。這個過程強制我理解每一行變更，重新建立起對代碼的掌控感。
如上圖，通常 cursor 在修改完成後都會自動生成總結（也可以通過添加 rules 控制），可以結合總結閲讀 diff。
2️⃣代碼品味，超越能跑就行
AI生成的代碼能運行、測試通過、上線不出事故，就足夠了嗎？如果你的技術認知水平在 AI 之下，無法判斷其實現是否為最佳實踐，就可能在系統中埋下無數隱患。
舉個例子，上週在體驗 relay 設計稿 AI 轉代碼的時候遇到過一件事：\
AI 將圖中的商品列表拆分為多行佈局——一行圖片、一行商品名、一行價格、一行按鈕。然而，具備前端組件化思維的同學一眼就能看出，更合理的做法是將其封裝為獨立的商品卡片組件進行循環渲染：
\
儘管 AI 的產出在功能上可以運行，測試、產品與用户也難以察覺差異，但這樣的結構嚴重缺乏可複用性。若未來其他頁面需要複用相同樣式的商品展示，我們將不得不重複編寫樣式與邏輯，違背了組件化的設計初衷。
因此，我的建議是：堅持閲讀高質量的代碼，無論是優秀的開源項目，還是身邊同事的成熟實現。遇到問題時，不必過度沉溺於調試錯誤實現，而應主動學習並理解最佳實踐，勇於對不合理的代碼進行果斷重構。。
3️⃣知識廣度，做好技術決策
AI在執行明確、具體的指令時表現更佳。這要求開發者既要有廣泛的知識儲備，又要能精準描述需求。研發就像行政總廚，而AI是精通各菜系的廚師——總廚必須清楚做什麼菜的時候，需要備哪些料，使用哪些廚具餐具，才能調度後廚高效產出。
以前端開發為例，若能明確指定使用某個具體的 JavaScript 庫，AI 的響應質量將顯著提升。例如，在實現“前端解析 Excel 文件”功能時，若直接提示 Cursor 使用 xlsx 庫，僅需二三十行代碼即可獲得目標數據結構：\
\
而若未提供任何技術棧提示，AI 可能傾向於使用原生 JS 實現，代碼量激增五倍以上，且邏輯複雜、未經充分驗證：\
因此，持續在技術社區交流，關注經典工具與前沿方案，是提升技術決策能力的關鍵。 只有清楚“用什麼”和“為什麼用”，才能最大限度地發揮 AI 的編碼潛力。
4️⃣表達精度，説 AI 聽得懂的話
一個不善於使用搜索引擎的人，往往也難以通過AI獲得理想結果。 從模糊的需求到清晰的提示詞，本質上是一種結構化與抽象能力的體現。
繼續用行政總廚的比喻：如果只説“番茄炒蛋要甜一點”，廚師會困惑——是加糖還是加番茄醬？如果能明確“300克番茄配3個雞蛋，需要加5克白糖”，產出質量就有保障。
精準表達的能力，與個人知識儲備和語言表達能力相關，不好舉例説明。建議有意識地閲讀完整書籍、觀看有深度的長播客，避免被短視頻時代的碎片化表達削弱這種能力。
對未來的展望
筆者作為 Joycode 的早期深度用户，為其界面交互提出過被採納的優化建議；我也是團隊中最早體驗並給研發同事安利 Cursor，給產品同事安利使用 v0 生成原型圖的人，我很高興看到如今公司已全面擁抱 AI。
然而，當業產研測各環節都在大力推進“+AI”時，我不禁思考：AI 提效，是否真的等同於在現有流程的每個環節簡單疊加 AI？
這讓我想起從功能機到智能機的過渡時期：早期的觸摸屏設備仍保留着大量實體按鍵，或者在屏幕底部保留了觸摸版的菜單鍵和返回鍵，交互邏輯仍是舊時代的延伸。直到多年後，真正的全面屏與手勢導航出現，才徹底釋放了觸摸交互的潛力。
我們當前對 AI 的應用，或許正處在那個“仍帶着實體按鍵”的階段。 若只滿足於在原有流程上“+AI”，恐怕難以觸及其真正的變革性潛力。AI 不應僅是效率工具，更應成為流程重構與體驗重塑的催化劑——而這，才是我們接下來需要共同探索的方向。
