在 AI Coding 提效這件事上，我想我的經(jīng)歷讓我有充分的發(fā)言權(quán)。今年上半年，作為團(tuán)隊中的 24 屆 JDS，我承接了兩位離職同事的業(yè)務(wù)模塊。面對密集的大促需求，我不僅扛住了“以一當(dāng)三”的交付壓力，同時保證了線上零事故。這一切，離不開 Cursor 的深度輔助——我的訂閱也從去年的 Pro 升至 Pro+，甚至在大促攻堅與黑馬程序員大賽期間，不惜投入每月 200 美元升級至 Ultra Plan，只為將開發(fā)效率推向極致。

先上干貨：

Cursor 實戰(zhàn) case 展示

以下展示了過去一年中，我使用 Cursor 開發(fā)的部分前端項目。這些頁面平均的 AI 生成代碼占比超過 60%，業(yè)務(wù)場景橫跨 B/C 兩端，技術(shù)棧全面覆蓋 Vue、React、通天塔樓層以及 Tailwindcss、Antd 等多種方案，充分體現(xiàn)了 Cursor 全面的技術(shù)能力與顯著的效率提升。

移動端

京粉app h5頁面，中秋前夕晚上 22 點業(yè)務(wù)來電話說想要一個中秋推廣的活動頁，使用豆包生成背景圖，使用cursor進(jìn)行樣式設(shè)計，0-1開發(fā)僅耗費兩個半小時，0:30 完成上線：

信息流廣告中間頁，UI 提供的初版 Lottie 動畫是一個完整頁面，無法拆分。由于大促排期緊張，等待 UI 支持較慢。為此，我借助 Cursor 直接解讀 Lottie 的 JSON 配置文件，成功將火焰、殺價、折扣等核心動效元素，精準(zhǔn)地解析為獨立的動畫，并通過CSS實現(xiàn)，降低了引入資源體積的同時還優(yōu)化了動畫的效果，加速通過了協(xié)同工作的卡點：

pc端

東皇鐘資損防控平臺，該項目由研發(fā)發(fā)起，在沒有產(chǎn)品原型和UI設(shè)計的情況下，借助 Cursor 結(jié)合 Shadcn UI，我獨立完成了平臺0-1的交互與界面構(gòu)建，最終成果獲得了后端與測試團(tuán)隊的一致好評：

落地頁中心動態(tài)分流，該模塊核心代碼近萬行，表單聯(lián)動邏輯復(fù)雜，整體由 Cursor 生成實現(xiàn)。面對 5 層以上的嵌套數(shù)據(jù)結(jié)構(gòu)，人工理解其層級關(guān)系并控制動態(tài)聯(lián)動不僅難度大，且極易出錯。通過引入 Cursor，深入解析數(shù)據(jù)結(jié)構(gòu)與聯(lián)動邏輯，顯著降低研發(fā)的理解成本，提升整體開發(fā)效率。

精準(zhǔn)鏈路分析項目，黑馬參賽項目，基于 Cursor 從零啟動，單人僅用兩天便快速構(gòu)建出功能完整的精美 Demo。項目完整實現(xiàn)了基于 React Flow 的JAVA 調(diào)用鏈路展示與組合、AI 流式報告及智能Agent對話等多種高級能力。

工程化

工程化歷來是前端領(lǐng)域的核心挑戰(zhàn)，充斥著依賴版本沖突與繁雜的配置邏輯。為驗證 Cursor 處理系統(tǒng)級任務(wù)的能力，我嘗試將完整升級流程交由它主導(dǎo)：從依賴分析、版本管理到工程配置更新，讓其直接操控終端、執(zhí)行 npm 命令。

在 京粉 App H5 項目中，我基于 Cursor 成功完成了從舊版本到 Vue 2.7.16 + Webpack 5 的升級全流程：《京粉AppH5 升級 Vue 2.7.16 + Webpack 5 記錄》

cursor 提供的升級方案（部分對話）：

更新依賴版本和配置文件（部分對話）：

自動執(zhí)行終端命令與修復(fù)報錯（部分對話）：

此外，我也讓 Cursor 實現(xiàn)了京粉 h5 從 Webpack 到 Vite 的遷移路徑驗證，核心構(gòu)建流程已全部跑通。目前因部分邊界場景報錯尚未完全解決，未形成正式文章，但該實踐已初步驗證 Cursor 在復(fù)雜工程鏈路中具備可行的輔助潛力。

Cursor 使用經(jīng)驗分享

重中之重：模型的選擇

模型是 AI 的基座，地基不牢，地動山搖。在此直接上結(jié)論：無腦選擇 Claude。

這不僅因為在大模型代碼能力評測中 Claude 持續(xù)領(lǐng)先（如上圖所示），更是筆者自 Sonnet 3.5 版本發(fā)布以來，實際體驗 Claude 在代碼生成、邏輯理解與上下文關(guān)聯(lián)方面的能力，相比同時期的模型，確實一騎絕塵。

需要注意的兩點：

警惕 Auto 模式：若賬號用量不足，Cursor 會自動切換至 Auto 模式，此時可能分配到性能較弱的模型，輸出質(zhì)量會顯著下降。該模式可用于技術(shù)交流，但不建議用于代碼生成與編輯。這也是我升級了訂閱計劃的原因。

關(guān)注上下文長度：Cursor 會實時顯示上下文使用情況。若接近限制，可主動選擇支持更長上下文的模型，或開啟多倍計費的 Max Mode 以擴(kuò)展處理能力，避免上下文丟失帶來的輸出質(zhì)量下降。

Talk is cheap. Show me the code.

相信研發(fā)同學(xué)對這句話都不陌生。這句話，在此處不妨視作 Cursor 對我們提出的要求。與 Cursor 協(xié)作的第一原則是：能提供代碼片段，絕不用文字描述；能用變量名指代的，絕不用中文名。

手動添加上下文

選中代碼片段，點擊“添加到聊天上下文”按鈕（快捷鍵 Ctrl+I）；

若僅提問不希望 Cursor 改動代碼，可使用 Ctrl+L；

在目錄中右鍵點擊文件或文件夾，將其加入對話；

在輸入框中輸入 @，手動選擇要引用的文件或目錄。

尤其在涉及多文件改動時，主動告知 Cursor 相關(guān)文件路徑，效果遠(yuǎn)優(yōu)于依賴其自行檢索。

統(tǒng)一語義表達(dá)

在業(yè)務(wù)溝通中，請始終使用精準(zhǔn)的變量名與 Cursor 交互。例如，在價格相關(guān)需求中，應(yīng)直接使用purchasePrice、wlPrice等已有變量名，而非口語化的“到手價”、“京東價”。這能確保 AI 在后續(xù)所有交互中對概念理解一致，無需反復(fù)推理映射關(guān)系。

同樣，在描述界面元素與交互邏輯時，精準(zhǔn)引用標(biāo)識符而非依賴自然語言描述，是提升 Cursor 理解準(zhǔn)確度的關(guān)鍵。

定位界面元素，應(yīng)明確指出其className或id，而非使用模糊的自然語言。
例如：? “那個下載按鈕” → ? “類名為.download-btn的按鈕” 或 “ID 為#export-download的元素”。

描述交互邏輯，應(yīng)直接提供回調(diào)函數(shù)名或方法名稱，而非籠統(tǒng)描述行為意圖。
例如：? “點擊按鈕后彈窗” → ? “在handleConfirmClick函數(shù)中調(diào)用showModal()方法”。

這種方式能夠有效避免界面中存在多個相似元素時造成的歧義，也便于 Cursor 直接在代碼庫中定位相關(guān)邏輯，實現(xiàn)精準(zhǔn)編輯。

如何使用 cursor 定位故障？

在“AI 能否取代程序員”的持續(xù)討論中，精準(zhǔn)定位并修復(fù)線上故障一直被視作人類工程師的關(guān)鍵優(yōu)勢。其根本原因在于：AI 雖能較好地解析靜態(tài)代碼結(jié)構(gòu)，卻難以感知系統(tǒng)運行時的動態(tài)狀態(tài)。而很多深層問題——如內(nèi)存泄漏、線程競爭、環(huán)境依賴異常等——恰恰隱藏在靜態(tài)代碼與動態(tài)執(zhí)行之間的鴻溝中，這構(gòu)成了當(dāng)前 AI 在故障處理中的認(rèn)知邊界。

那么，我們?nèi)绾螢?AI 架起一座跨越這道鴻溝的橋梁？

答案正在于我們?nèi)祟愖钍煜さ恼{(diào)試手段：日志。既然日志能夠成為開發(fā)者和運行中系統(tǒng)之間的溝通媒介，那么它同樣可以轉(zhuǎn)化為 AI 理解運行時行為的關(guān)鍵信息來源。

引導(dǎo) AI 插入關(guān)鍵日志

當(dāng)你發(fā)現(xiàn)某個功能異常，可指示 Cursor 在關(guān)鍵邏輯路徑上添加日志點。只需簡單指令，如：“請幫我在xx功能相關(guān)的函數(shù)內(nèi)部添加 console.log，輸出關(guān)鍵變量的值?！?br />

運行代碼并捕獲日志

執(zhí)行添加日志后的代碼，復(fù)制運行時所生成的完整日志輸出。

將日志與代碼共同提交給 AI 分析

然后再將日志復(fù)制發(fā)送給cursor，神奇的事發(fā)生了，本來它改動了幾遍都沒能解決的問題，一下就定位到了根因：

技巧背后的邏輯

此方法之所以有效，是因為它將 AI 從純粹的代碼靜態(tài)分析者，轉(zhuǎn)變?yōu)榱艘粋€具備“運行時視野”的調(diào)試伙伴。通過日志，AI 能夠：

追蹤變量的實際變化軌跡

識別邏輯分支的真實執(zhí)行路徑

發(fā)現(xiàn)數(shù)據(jù)流與預(yù)期不符的具體位置

添加 Rules：讓 AI 記住你的工程規(guī)范

在使用日志與 Cursor 協(xié)作調(diào)試時，我遇到了一個典型問題：項目中已有大量日志，新增的調(diào)試信息很快被淹沒，難以快速定位。我希望 Cursor 在每次插入調(diào)試日志時，自動在開頭附加 【xx功能調(diào)試】 這樣的標(biāo)識，以便在控制臺中快速篩選。但若每次對話都重復(fù)這一要求，既低效又容易遺漏。

這時，Cursor 的 Rules 功能便可發(fā)揮關(guān)鍵作用。你可以在規(guī)則中固話這類常見的工程約束或團(tuán)隊規(guī)范，例如：

Cursor 支持為不同項目配置獨立的規(guī)則集，靈活適配各工程的特定規(guī)范。具體設(shè)置方法詳見官方文檔：Cursor - 規(guī)則

完成規(guī)則配置后，我們重新執(zhí)行之前的調(diào)試對話。如下圖所示，現(xiàn)在每個console.log語句的開頭都已自動加上了對應(yīng)的函數(shù)名作為標(biāo)識，極大方便了在控制臺中的篩選與查看：

集成 MCP：拓展能力邊界

在使用日志輔助 Cursor 進(jìn)行調(diào)試的過程中，我逐漸發(fā)現(xiàn)兩個影響效率的典型問題：

手動復(fù)制繁瑣：頻繁從控制臺復(fù)制日志再粘貼至 Cursor，本質(zhì)上仍是一種重復(fù)勞動，與 AI 協(xié)作的自動化理念相悖。

日志內(nèi)容雜亂：控制臺中的引用類型數(shù)據(jù)（如對象、數(shù)組）若不展開或格式不當(dāng)，難以完整復(fù)制；同時，控制臺自動插入的代碼位置信息（文件路徑與行號）常混雜在日志正文中，導(dǎo)致最終提供給 Cursor 的文本結(jié)構(gòu)混亂、難以解析。

上圖正是這一問題的直觀體現(xiàn)：日志中穿插了源代碼位置，而對象數(shù)據(jù)未完整展開，這樣的信息直接交給 Cursor，會影響其理解與推理的準(zhǔn)確性。

而此時，正是 MCP（Model Context Protocol）可大顯身手的場景。通過為 Cursor 配置瀏覽器 MCP 服務(wù)，我實現(xiàn)了工作流的質(zhì)的飛躍：

MCP 賦予 Cursor 直接控制瀏覽器的能力，使其能夠：

自動捕獲頁面截圖

直接讀取控制臺日志

分析 DOM 結(jié)構(gòu)

當(dāng)前 Cursor 的瀏覽器 MCP 僅支持內(nèi)置窗口與 Chrome。若你使用 Edge 或其他瀏覽器，可選用微軟推出的 Playwright 作為替代方案。

同時，主流前端工具已紛紛提供 MCP 或知識庫。以 Ant Design 為例，將其官方知識庫 LLMs.txt - Ant Design ，添加到 Cursor 的指定位置：

添加后，Cursor 即可基于官方最新文檔提供準(zhǔn)確的組件使用建議。

優(yōu)先選用 AI “擅長”的技術(shù)棧

何為 AI “擅長”的技術(shù)棧？簡單來說：React、TailwindCSS 屬于 AI 表現(xiàn)優(yōu)異的技術(shù)棧；微信小程序次之；而像 Taro、uni-app 這類一碼多端的框架，則往往是 AI 的弱項。

其背后的邏輯在于數(shù)據(jù)可見性：開源生態(tài)越豐富、網(wǎng)絡(luò)公開樣本越多的技術(shù)，大模型在訓(xùn)練時接觸到的相關(guān)代碼就越充分，生成質(zhì)量自然更高。反之，閉源、文檔稀少的場景，AI 由于缺乏學(xué)習(xí)材料，表現(xiàn)往往不盡如人意。

在實際的 Taro 項目中，當(dāng)我嘗試讓 AI 協(xié)助處理 H5、小程序與 RN 三端的代碼適配時，其表現(xiàn)確實令人沮喪。我最常遇到的狀況是：好不容易讓 AI 修復(fù)了 H5 端的樣式錯位，轉(zhuǎn)頭就發(fā)現(xiàn)小程序端布局崩潰；當(dāng) RN 端的交互問題被解決后，H5 端又出現(xiàn)了新的渲染異常。

因此，在 AI Coding 日益普及的背景下，我們不得不重新審視如 Taro、UniApp 等一碼多端框架的效率等式：其帶來的跨端便利，是否足以抵消因 AI 支持薄弱而導(dǎo)致的額外研發(fā)成本？這一點值得深思。

破局之道或許在于深度擁抱 AI 生態(tài)。如果這類框架能官方的推出強(qiáng)大的 MCP 服務(wù)，將其多端差異和配置邏輯“結(jié)構(gòu)化”地注入 AI 的認(rèn)知過程，它們將有潛力從當(dāng)前的“AI 洼地”轉(zhuǎn)變?yōu)椤爸悄芸缍恕钡牡浞丁?/p>

反直覺：0-1不難，1-100 更難？

讀過不少 AI 編程文章的人都會發(fā)現(xiàn)，多數(shù)內(nèi)容都在展示如何從 0 到 1 快速搭建應(yīng)用。但實際上存在一個反直覺的真相：用 AI 從 0 到 1 并不難，真正難的是讓它接手和維護(hù)存量代碼。

在新項目中，AI 面對的是清晰的上下文和現(xiàn)代技術(shù)棧。而在存量代碼中，它需要理解混亂的命名、隱含的業(yè)務(wù)邏輯和特殊的實現(xiàn)方式，同時要避免“修復(fù)一個 bug 引入兩個新 bug”的連鎖反應(yīng)。這就像讓新人從頭做項目，遠(yuǎn)比讓他修改復(fù)雜的老系統(tǒng)要簡單。

要讓 AI 有效接手存量代碼，關(guān)鍵在于像幫助新人一樣為它提供清晰的指引。核心方法有二：

為 AI 優(yōu)化的代碼注釋

傳統(tǒng)的業(yè)務(wù)背景介紹對 AI 幫助有限，應(yīng)該采用更代碼化的注釋方式。避免長篇大論地介紹業(yè)務(wù)邏輯，而是清晰地指出代碼和業(yè)務(wù)之間的關(guān)系，魔法數(shù)字的具體含義等。

比如，不要寫“這里是價格計算模塊，因為歷史原因需要區(qū)分新老用戶”，而應(yīng)該寫“新用戶(level=1)享受首單優(yōu)惠，老用戶(level>=2)按原價計算，優(yōu)惠金額固定為20”。重點注釋魔法數(shù)字的實際含義、復(fù)雜條件判斷的業(yè)務(wù)背景、接口字段的映射關(guān)系等。

TypeScript 的天然優(yōu)勢

在接手現(xiàn)有項目上，TypeScript 有著得天獨厚的優(yōu)勢。類型定義相當(dāng)于強(qiáng)制展示了一遍代碼結(jié)構(gòu)，如果再加上每個變量的注釋，就是現(xiàn)成的知識庫。

通過“精準(zhǔn)注釋 + 完整類型”的組合，即使是最復(fù)雜的遺留代碼，AI 也能快速理解并安全修改，真正突破從 1 到 100 的瓶頸。

AI Coding時代，優(yōu)秀研發(fā)需要哪些新特質(zhì)？

聊了這么多 Cursor 的強(qiáng)大表現(xiàn)，難免讓人心生疑問：研發(fā)是否正在被 AI 取代？恰恰相反，我認(rèn)為 AI 正在急劇拉大開發(fā)者之間的能力差距。今年幾乎人人都用上了 AI 編程工具，可能是 Cursor，也可能是 Joycode。但如果你去 review 團(tuán)隊中的代碼，就會發(fā)現(xiàn)：強(qiáng)者的代碼因AI而更優(yōu)秀，弱者的代碼因AI而更紊亂。

結(jié)合實踐中的經(jīng)驗，我總結(jié)了 AI 編碼時代一名優(yōu)秀開發(fā)者最應(yīng)具備的幾種核心能力：

1??有責(zé)任心，做代碼的owner

早期使用Cursor時，我常常陷入一種狀態(tài)：AI生成的代碼占比太高，以至于我對新增部分失去理解和掌控。一旦被問及業(yè)務(wù)邏輯，或是出現(xiàn)線上問題，甚至?xí)恢獜暮尾槠稹?/p>

這就像一位藝術(shù)家通過AI生成畫作，很難像對待自己親筆作品那樣珍視并負(fù)責(zé)。我的改進(jìn)方案是：在每次 Agent 完成編碼之后，閱讀其改動總結(jié)；在每次提交前，仔細(xì)Review Cursor生成代碼的Diff。這個過程強(qiáng)制我理解每一行變更，重新建立起對代碼的掌控感。

如上圖，通常 cursor 在修改完成后都會自動生成總結(jié)（也可以通過添加 rules 控制），可以結(jié)合總結(jié)閱讀 diff。

2??代碼品味，超越能跑就行

AI生成的代碼能運行、測試通過、上線不出事故，就足夠了嗎？如果你的技術(shù)認(rèn)知水平在 AI 之下，無法判斷其實現(xiàn)是否為最佳實踐，就可能在系統(tǒng)中埋下無數(shù)隱患。

舉個例子，上周在體驗 relay 設(shè)計稿 AI 轉(zhuǎn)代碼的時候遇到過一件事：

AI 將圖中的商品列表拆分為多行布局——一行圖片、一行商品名、一行價格、一行按鈕。然而，具備前端組件化思維的同學(xué)一眼就能看出，更合理的做法是將其封裝為獨立的商品卡片組件進(jìn)行循環(huán)渲染：

盡管 AI 的產(chǎn)出在功能上可以運行，測試、產(chǎn)品與用戶也難以察覺差異，但這樣的結(jié)構(gòu)嚴(yán)重缺乏可復(fù)用性。若未來其他頁面需要復(fù)用相同樣式的商品展示，我們將不得不重復(fù)編寫樣式與邏輯，違背了組件化的設(shè)計初衷。

因此，我的建議是：堅持閱讀高質(zhì)量的代碼，無論是優(yōu)秀的開源項目，還是身邊同事的成熟實現(xiàn)。遇到問題時，不必過度沉溺于調(diào)試錯誤實現(xiàn)，而應(yīng)主動學(xué)習(xí)并理解最佳實踐，勇于對不合理的代碼進(jìn)行果斷重構(gòu)。。

3??知識廣度，做好技術(shù)決策

AI在執(zhí)行明確、具體的指令時表現(xiàn)更佳。這要求開發(fā)者既要有廣泛的知識儲備，又要能精準(zhǔn)描述需求。研發(fā)就像行政總廚，而AI是精通各菜系的廚師——總廚必須清楚做什么菜的時候，需要備哪些料，使用哪些廚具餐具，才能調(diào)度后廚高效產(chǎn)出。

以前端開發(fā)為例，若能明確指定使用某個具體的 JavaScript 庫，AI 的響應(yīng)質(zhì)量將顯著提升。例如，在實現(xiàn)“前端解析 Excel 文件”功能時，若直接提示 Cursor 使用 xlsx 庫，僅需二三十行代碼即可獲得目標(biāo)數(shù)據(jù)結(jié)構(gòu)：

而若未提供任何技術(shù)棧提示，AI 可能傾向于使用原生 JS 實現(xiàn)，代碼量激增五倍以上，且邏輯復(fù)雜、未經(jīng)充分驗證：

因此，持續(xù)在技術(shù)社區(qū)交流，關(guān)注經(jīng)典工具與前沿方案，是提升技術(shù)決策能力的關(guān)鍵。 只有清楚“用什么”和“為什么用”，才能最大限度地發(fā)揮 AI 的編碼潛力。

4??表達(dá)精度，說 AI 聽得懂的話

一個不善于使用搜索引擎的人，往往也難以通過AI獲得理想結(jié)果。從模糊的需求到清晰的提示詞，本質(zhì)上是一種結(jié)構(gòu)化與抽象能力的體現(xiàn)。

繼續(xù)用行政總廚的比喻：如果只說“番茄炒蛋要甜一點”，廚師會困惑——是加糖還是加番茄醬？如果能明確“300克番茄配3個雞蛋，需要加5克白糖”，產(chǎn)出質(zhì)量就有保障。

精準(zhǔn)表達(dá)的能力，與個人知識儲備和語言表達(dá)能力相關(guān)，不好舉例說明。建議有意識地閱讀完整書籍、觀看有深度的長播客，避免被短視頻時代的碎片化表達(dá)削弱這種能力。

對未來的展望

筆者作為 Joycode 的早期深度用戶，為其界面交互提出過被采納的優(yōu)化建議；我也是團(tuán)隊中最早體驗并給研發(fā)同事安利 Cursor，給產(chǎn)品同事安利使用 v0 生成原型圖的人，我很高興看到如今公司已全面擁抱 AI。

然而，當(dāng)業(yè)產(chǎn)研測各環(huán)節(jié)都在大力推進(jìn)“+AI”時，我不禁思考：AI 提效，是否真的等同于在現(xiàn)有流程的每個環(huán)節(jié)簡單疊加 AI？

這讓我想起從功能機(jī)到智能機(jī)的過渡時期：早期的觸摸屏設(shè)備仍保留著大量實體按鍵，或者在屏幕底部保留了觸摸版的菜單鍵和返回鍵，交互邏輯仍是舊時代的延伸。直到多年后，真正的全面屏與手勢導(dǎo)航出現(xiàn)，才徹底釋放了觸摸交互的潛力。

我們當(dāng)前對 AI 的應(yīng)用，或許正處在那個“仍帶著實體按鍵”的階段。若只滿足于在原有流程上“+AI”，恐怕難以觸及其真正的變革性潛力。AI 不應(yīng)僅是效率工具，更應(yīng)成為流程重構(gòu)與體驗重塑的催化劑——而這，才是我們接下來需要共同探索的方向。

審核編輯 黃宇