一、引言

很高興與大家分享現階段 Cursor 在我的工作中的使用體驗。首先是預期管理，本篇文章不會分享 x 個你可能不知道的小技巧，也不會讓你擁有無需自行編碼的能力，同時不涉及 Cursor 工程化方面內容。僅僅是圍繞個人開發流程中的已有問題，分享如何使用 Cursor 來提升這部分的開發體驗，在工作中持續保持好的節奏和狀態。

TL;DR

• 列舉 Cursor 的錯誤預期

• 相比過去的開發流程，使用 Cursor 后的變化

• Cursor 在現狀分析、方案設計和影響評估中的收益

二、就差一個程序員了

最近團隊在大力推廣 Cursor AI，隨著幾個版本迭代體驗下來，其精準的自動補全深得我心，具體可以體現在Tab 鍵的使用率已逐漸高于 Command + C/V。既然這么懂我，那么能否更進一步，根據 PRD 直接輸出代碼呢？

2.1 從需求到代碼

Cursor 能夠理解代碼上下文，從而根據簡短的描述生成符合上下文的代碼，于是我嘗試直接將 PRD 提供給 Cursor 來生成代碼：

PRD → Cursor → Code（一步到位）

幾個需求嘗試下來，總的來說分為兩類問題：

這就像你去理發店，希望 Tony 老師稍微剪短一點，結果卻被剪得稍微短了點。而這需要我們在開始之前對齊認知，補充描述和參照。在這個前置階段，即使發現對方理解有偏差，也還能及時糾正。俗稱“對齊顆粒度”。

2.2 從規劃到執行

Cursor 產出的代碼由它所接收的上下文決定，如果沒有準確描述需求意圖，它會通過推斷做出假設，導致產出不準確。因此我們在使用 Cursor 時，關鍵在于區分開發過程中的規劃階段和執行階段。在這個分層的視角下，不管是自身的關注點還是 AI 的角色定位都變得更加清晰：

Cursor 在這個過程中，不應該被視為開發者的替代品，而是一面能夠放大開發者能力的鏡子：

• 對于已知的部分，Cursor 可以加速實現，減少重復勞動。

• 對于未知的部分，Cursor 可以協助探索，但不能替代開發者的判斷。

在理解了 AI 的角色后，我們需要重構目前的開發工作流，讓 AI 成為真正有效的助手。最關鍵的轉變是：不再試圖讓 AI 替代開發流程中的任何環節，而是讓它協助完成每個環節。這意味著不是把 PRD 扔給 AI，等待完整代碼，而是和 AI 一起理解 PRD 和代碼現狀，共同設計方案，明確步驟，然后分步實現。

三、現有問題

作為前端開發，我們的日常工作流程中大多圍繞需求文檔進行代碼產出。這需要介于

1. 我們對業務需求的理解。

2. 對所屬業務和項目現狀的認知。

3. 從而進行方案設計和決策，整理思路將復雜問題分解成可執行的粒度。

但同時，這導致我們不得不面臨著一個矛盾：方案設計對效率的影響。一方面，方案設計是保證質量的必要環節；另一方面，生成和維護這些產物又會顯著降低開發效率。尤其是在快速迭代的項目需求中，這種矛盾更為突出。

有時即使是一個小需求，可能也需要經過大量前置分析，才能進入開發。舉個例子，以下是某個小需求的前端方案截圖，通過不同的顏色區分了各流程的占比。從圖中可以看出，各模塊中綠色和藍色所對應的「現狀分析」和「改動方案」后占據了主要的篇幅，與相應的時間占用成正比。

前端方案中的各環節分布

傳統的解決方案通常是：

• 模板化方案設計，減少重復工作。

• 簡化方案設計，減少不必要的細節描述。

• 提高團隊熟練度，使得方案設計生成更加高效。

作為附加項，現在我們能在這些基礎上借助 Cursor 進一步提升效能。

四、協作流程

4.1 反饋循環

在協作時，關鍵在于對 Cursor 補充上下文，并對 Cursor 提供的結論進行人工核驗，兩者構成反饋循環。前者是希望 Cursor 知道，后者是需要我們自己知道，從而保障產出的結果符合預期。

整體的 Cursor 協作流程分為規劃和執行兩個階段。規劃階段專注于產出方案，執行階段根據方案產出代碼，兩者交替執行。

4.2 流程對比

相較于以往，在使用 Cursor 后的工作模式差異如下：

乍一看使用 Curosr 后流程更加繁瑣，而實際上也確實如此。

所以這里更推薦換一個心態來看待流程上的變化，不必為了使用工具而使用。過去我們面向 Google / GitHub / Stack Overflow 編程也并不是因為我們為了搜索而搜索，是因為在具體開發中遇到了不明確的信息需要確認，現在這個角色可以漸進地由 Cursor 替代，比起搜索引擎，Cursor 能充分地根據項目現狀分析出更貼切的答案，如同行車的導航和選購的得物，為此不必有太多的心理負擔。

五、場景應用

重新回到在需求開發工作中的問題，占據我代碼之外的主要工作是“現狀分析”、“改動方案”和“影響評估”，因此主要分享這三個場景中的 Cursor 使用體驗。

關于提示詞，可根據實際需要使用 notepads 或 rules 降低單次使用成本。

5.1 現狀分析

在需求開發過程中，我們時常會接觸到陌生的業務模塊，如何理解現狀往往是最耗時也最容易被忽視的部分。如果對現狀不夠了解，當需求相對復雜或者項目本身存在較多的歷史債務時，我們很難輸出符合預期的方案，更難以保證最終代碼的質量。對于新接手項目的開發者而言，這一階段常常伴隨著無數次的"代碼考古"和"問詢前人"。

Cursor 離代碼上下文更近，我們可以在它的協助下抽絲剝繭，快速了解業務主線。這是一個學習的過程，當知道的越多，在后續的設計和開發中就越能正確地引導 Cursor。

具體可以從需求的目標改動點開始，梳理其所屬功能和實現方式，包含交互流程、數據管理和條件渲染等：

業務需求 ├── 1. 功能 │ ├── 2. 實現 │ ... └── 3. 字段 ...

目標	了解業務功能	了解代碼實現	了解字段依賴
提示詞參考	當前功能如何運作，用戶交互有哪些路徑，具體數據流向是怎樣的，請整理成 mermaid 時序圖。	當前代碼如何組織，核心模塊有哪些，組件間如何通信，梳理組件關系圖。	梳理當前表單字段的顯隱關系、聯動邏輯以及數據源。
效果	輸出所屬功能中的角色和角色之間的交互方式，能快速掌握業務模塊的大體脈絡。（表下圖一）	輸出組件職責和組件間的關系，以便在投入開發前以組件模塊維度確定改動范圍。（表下圖二）	能直觀地呈現表單字段間的聯動說明。（表下圖三）

圖一

圖二

圖三

通過對上述三個層面的不斷往復，Cursor 提供的直觀輸入能幫助我們擺脫掉一知半解的狀態，消除不確定性也就消除了焦慮。

5.2 改動方案

在了解了現狀后，開始面向需求進行改動方案設計。

在問答中，Cursor 傾向于直接滿足表面的需求，但可能會忽略一些深層的系統設計考慮。當遇到復雜的問題時，建議先讓 Cursor 分析問題本身，而不是直接要求它給出解決方案。通過引導它進行更全面的思考，能防止 Cursor 胡編亂造，確保它理解需求，同時也能暴露自身的思考局限，減少返工。具體做法可以先提示 “在我讓你寫代碼之前不要生成代碼” 以及 “先逐步分析需求再說明你打算怎么做”；

另一方面，由于 Cursor 背后 LLM 的 Context Window 存在上下文長度限制，意味著 Cursor 跟我們一樣都存在“短期記憶”，這體現在當對話超出范圍后，Cursor 會在輸出方案和代碼時，遺忘此前的要求和結論，造成不準確。因此，為了將短期記憶轉換成長期記憶，需要我們對復雜任務進行必要的拆解，每次只專注于單個粒度下的問答，當確認方案后，再讓 Cursor 匯總并記錄到外置文檔，以便在后續的對話中補充上下文（也可以借助 @Summarized Composers 實現）。在面對下一個任務時，開啟新的會話進行問答，多輪下來形成由不同模塊組裝而成的方案設計。

這樣一來，在生成代碼階段，Cursor 所需要面對的只是局部復雜度中的改動，這能很大程度上減緩我們在代碼審核和驗證上的投入成本。Cursor 也能始終保持在長度限制范圍內，面對精煉后的方案設計進行決策和產出。

因此在整體流程上：

1. 拆解需求，縮小關注范圍

2. 明確目標，清晰表達需求描述

• Cursor 提供方案

• 檢查是否有理解偏差，并不斷調整提示

• 在確認方案后，最終由 Cursor 匯總成果

3. 漸進開發，分模塊由 Cursor 生成代碼，及時驗證效果和審核代碼

提示詞參考：

• 方案設計

我們先探討方案，在我讓你寫代碼之前不要生成代碼 如果此處要加個 xxx 該怎么做，請先逐步分析需求 在想明白后向我說明為什么要這么設計

• 代碼產出，在功能之外，留意識別邊界場景以及控制影響面

在寫代碼時遵循最小改動原則，避免影響原先的功能 即使識別到歷史問題也不要自行優化，可以先告知我問題描述和對當前需求的影響，不要直接改跟本次需求無關的代碼

5.3 影響評估

除去開發之前的方案耗時，在完成開發后，我們所要解決的是如何保障自測質量的問題。對于研發而言，需要關注的是在這個需求迭代內，改動點所關聯的調用鏈路，而在這個路徑依賴下不斷冒泡所涉及到的具體功能就是影響面。

因此可以從兩個方面提高自測可信度

• 自下而上：基于改動代碼和依賴項進行白盒測試，這需要研發自身投入必要的時間進行代碼審核；

• 自上而下：識別改動最終涉及到的頁面和功能進行黑盒測試，逐個回歸和確認功能是否符合預期。

借助 Cursor 可以很低成本地分析改動，并按需產出測試用例，通過 @git 指令讓 Cursor 參與到對當前功能分支或具體 commit 的評估：

目標	代碼審查	功能驗證
提示詞	@git 逐個文件分析并總結改動點，評估是否引入了新的問題。	@git 基于代碼變更輸出自測用例清單。
效果	在列舉出每個文件的改動意圖后，會告知潛在問題和修改意見。（表下圖一）	圍繞改動，生成新舊功能在不同場景中的測試用例。（表下圖二）

圖一

圖二

六、小結

過去，成為一名優秀開發者需要經歷漫長的積累：從反復查閱文檔、在搜索引擎中篩選有效信息，到系統掌握編程語言、算法與網絡原理，每一步都在構建扎實的「知識護城河」。而 AI 時代顛覆了這一邏輯 —— 當大模型能快速生成代碼、解析技術方案時，開發者的核心能力似乎從“記憶與執行”轉向成了“正確地提問，讓 AI 提供答案”。

客觀來看，AI 降低了信息獲取的門檻，能更快地落地想法、驗證思路。不變的是，好的答案源于好的問題，而提出好問題依舊需要積累專業領域下的知識，知道的越清楚才能在提問時描述得越清晰。

所有事都有吃力不討好的部分，隨著 Cursor 等 AI 工具在工程中的應用，我們可以逐漸將這部分職能分配出去，利用我們的知識儲備，描述問題，引導過程，審核結果。工具的使用始終是為了節省人類體力和腦力的開銷，從而在提升體驗的同時提升生產力，以更充沛的精力聚焦在工作成果和個人成長上。

文 / 魏命名

關注得物技術，每周一、三更新技術干貨

要是覺得文章對你有幫助的話，歡迎評論轉發點贊～

未經得物技術許可嚴禁轉載，否則依法追究法律責任。