🔧 阿川の電商水電行
Cursor 一年深度開發實踐：前端開發的效率革命🚀
在 AI Coding 提效這件事上，我想我的經歷讓我有充分的發言權。今年上半年，作為團隊中的校招新人，我承接了兩位離職同事的業務模組。面對密集的需求，我不僅扛住了“以一當三”的交付壓力，同時保證了線上零事故。這一切，離不開 Cursor 的深度輔助。
先上乾貨：
Cursor 實戰案例展示
以下展示了過去一年中，我使用 Cursor 開發的部分前端項目。這些頁面平均的 AI 生成代碼佔比超過 80%，業務場景橫跨 B/C 兩端，技術棧全面覆蓋 Vue、React、微信小程式以及 Tailwindcss、Antd、shadcn UI 等多種技術框架，充分體現了 Cursor 全面的技術能力與顯著的效率提升。
移動端
App H5推廣頁面，中秋前夕晚上 22 點業務來電話說想要一個中秋推廣的活動頁，使用豆包生成背景圖，使用 Cursor 進行樣式設計，0-1 開發僅耗費兩個半小時，0:30 完成上線：
廣告落地頁，UI 提供的初版 Lottie 動畫是一個完整頁面，無法拆分。由於大促排期緊張，等待 UI 支持較慢。為此，我借助 Cursor 直接解讀 Lottie 的 JSON 配置文件，成功將火焰、殺價、折扣等核心動效元素，精準地解析為獨立的動畫，並讓 Cursor 通過 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 的升級全流程：Vue 2.5.16 + Webpack 4 升級 Vue 2.7.16 + Webpack 5 記錄項目從 Vue - 掘金
Cursor 提供的升級方案（部分對話）：
更新依賴版本和配置文件（部分對話）：
自動執行終端命令與修復報錯（部分對話）：
此外，我也讓 Cursor 實現了該 App 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、price 等已有變量名，而非口語化的“到手價”、“原價”。這能確保 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 取代？恰恰
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
