Cursor 在前端需求開發工作流中的應用
一、引言
很高興與大家分享現階段 Cursor 在我的工作中的使用體驗。首先是預期管理，本篇文章不會分享 x 個你可能不知道的小技巧，也不會讓你擁有無需自行編碼的能力，同時不涉及 Cursor 工程化方面內容。僅僅是圍繞個人開發流程中的已有問題，分享如何使用 Cursor 來提升這部分的開發體驗，在工作中持續保持好的節奏和狀態。
TL;DR
- 列舉 Cursor 的錯誤預期
- 相比過去的開發流程，使用 Cursor 后的變化
- Cursor 在現狀分析、方案設計和影響評估中的收益
二、就差一個程序員了
最近團隊在大力推廣 Cursor AI，隨著幾個版本迭代體驗下來，其精準的自動補全深得我心，具體可以體現在 Tab 鍵的使用率已逐漸高于 Command + C/V。既然這么懂我，那么能否更進一步，根據 PRD 直接輸出代碼呢？
從需求到代碼
Cursor 能夠理解代碼上下文，從而根據簡短的描述生成符合上下文的代碼，于是我嘗試直接將 PRD 提供給 Cursor 來生成代碼：
PRD → Cursor → Code（一步到位）幾個需求嘗試下來，總的來說分為兩類問題：
這就像你去理發店，希望 Tony 老師稍微剪短一點，結果卻被剪得稍微短了點。而這需要我們在開始之前對齊認知，補充描述和參照。在這個前置階段，即使發現對方理解有偏差，也還能及時糾正。俗稱“對齊顆粒度”。
從規劃到執行
Cursor 產出的代碼由它所接收的上下文決定，如果沒有準確描述需求意圖，它會通過推斷做出假設，導致產出不準確。因此我們在使用 Cursor 時，關鍵在于區分開發過程中的規劃階段和執行階段。在這個分層的視角下，不管是自身的關注點還是 AI 的角色定位都變得更加清晰：
Cursor 在這個過程中，不應該被視為開發者的替代品，而是一面能夠放大開發者能力的鏡子：
- 對于已知的部分，Cursor 可以加速實現，減少重復勞動。
- 對于未知的部分，Cursor 可以協助探索，但不能替代開發者的判斷。
在理解了 AI 的角色后，我們需要重構目前的開發工作流，讓 AI 成為真正有效的助手。最關鍵的轉變是：不再試圖讓 AI 替代開發流程中的任何環節，而是讓它協助完成每個環節。這意味著不是把 PRD 扔給 AI，等待完整代碼，而是和 AI 一起理解 PRD 和代碼現狀，共同設計方案，明確步驟，然后分步實現。
三、現有問題
作為前端開發，我們的日常工作流程中大多圍繞需求文檔進行代碼產出。這需要介于
- 我們對業務需求的理解。
- 對所屬業務和項目現狀的認知。
- 從而進行方案設計和決策，整理思路將復雜問題分解成可執行的粒度。
但同時，這導致我們不得不面臨著一個矛盾：方案設計對效率的影響。一方面，方案設計是保證質量的必要環節；另一方面，生成和維護這些產物又會顯著降低開發效率。尤其是在快速迭代的項目需求中，這種矛盾更為突出。
有時即使是一個小需求，可能也需要經過大量前置分析，才能進入開發。舉個例子，以下是某個小需求的前端方案截圖，通過不同的顏色區分了各流程的占比。從圖中可以看出，各模塊中綠色和藍色所對應的「現狀分析」和「改動方案」后占據了主要的篇幅，與相應的時間占用成正比。
前端方案中的各環節分布
傳統的解決方案通常是：
- 模板化方案設計，減少重復工作。
- 簡化方案設計，減少不必要的細節描述。
- 提高團隊熟練度，使得方案設計生成更加高效。
作為附加項，現在我們能在這些基礎上借助 Cursor 進一步提升效能。
四、協作流程
反饋循環
在協作時，關鍵在于對 Cursor 補充上下文，并對 Cursor 提供的結論進行人工核驗，兩者構成反饋循環。前者是希望 Cursor 知道，后者是需要我們自己知道，從而保障產出的結果符合預期。
整體的 Cursor 協作流程分為規劃和執行兩個階段。規劃階段專注于產出方案，執行階段根據方案產出代碼，兩者交替執行。
流程對比
相較于以往，在使用 Cursor 后的工作模式差異如下：
乍一看使用 Curosr 后流程更加繁瑣，而實際上也確實如此。
所以這里更推薦換一個心態來看待流程上的變化，不必為了使用工具而使用。過去我們面向 Google / GitHub / Stack Overflow 編程也并不是因為我們為了搜索而搜索，是因為在具體開發中遇到了不明確的信息需要確認，現在這個角色可以漸進地由 Cursor 替代，比起搜索引擎，Cursor 能充分地根據項目現狀分析出更貼切的答案，如同行車的導航和選購的得物，為此不必有太多的心理負擔。
五、場景應用
重新回到在需求開發工作中的問題，占據我代碼之外的主要工作是“現狀分析”、“改動方案”和“影響評估”，因此主要分享這三個場景中的 Cursor 使用體驗。
關于提示詞，可根據實際需要使用 notepads 或 rules 降低單次使用成本。
現狀分析
在需求開發過程中，我們時常會接觸到陌生的業務模塊，如何理解現狀往往是最耗時也最容易被忽視的部分。如果對現狀不夠了解，當需求相對復雜或者項目本身存在較多的歷史債務時，我們很難輸出符合預期的方案，更難以保證最終代碼的質量。對于新接手項目的開發者而言，這一階段常常伴隨著無數次的"代碼考古"和"問詢前人"。
Cursor 離代碼上下文更近，我們可以在它的協助下抽絲剝繭，快速了解業務主線。這是一個學習的過程，當知道的越多，在后續的設計和開發中就越能正確地引導 Cursor。
具體可以從需求的目標改動點開始，梳理其所屬功能和實現方式，包含交互流程、數據管理和條件渲染等：
業務需求
├── 1. 功能
│ ├── 2. 實現
│ ... └── 3. 字段
...目標 | 了解業務功能 | 了解代碼實現 | 了解字段依賴 |
提示詞參考 | 當前功能如何運作，用戶交互有哪些路徑，具體數據流向是怎樣的，請整理成 mermaid 時序圖。 | 當前代碼如何組織，核心模塊有哪些，組件間如何通信，梳理組件關系圖。 | 梳理當前表單字段的顯隱關系、聯動邏輯以及數據源。 |
效果 | 輸出所屬功能中的角色和角色之間的交互方式，能快速掌握業務模塊的大體脈絡。
| 輸出組件職責和組件間的關系，以便在投入開發前以組件模塊維度確定改動范圍。
| 能直觀地呈現表單字段間的聯動說明。
|
通過對上述三個層面的不斷往復，Cursor 提供的直觀輸入能幫助我們擺脫掉一知半解的狀態，消除不確定性也就消除了焦慮。
改動方案
在了解了現狀后，開始面向需求進行改動方案設計。
在問答中，Cursor 傾向于直接滿足表面的需求，但可能會忽略一些深層的系統設計考慮。當遇到復雜的問題時，建議先讓 Cursor 分析問題本身，而不是直接要求它給出解決方案。通過引導它進行更全面的思考，能防止 Cursor 胡編亂造，確保它理解需求，同時也能暴露自身的思考局限，減少返工。具體做法可以先提示 “在我讓你寫代碼之前不要生成代碼” 以及 “先逐步分析需求再說明你打算怎么做”；
另一方面，由于 Cursor 背后 LLM 的 Context Window 存在上下文長度限制，意味著 Cursor 跟我們一樣都存在“短期記憶”，這體現在當對話超出范圍后，Cursor 會在輸出方案和代碼時，遺忘此前的要求和結論，造成不準確。因此，為了將短期記憶轉換成長期記憶，需要我們對復雜任務進行必要的拆解，每次只專注于單個粒度下的問答，當確認方案后，再讓 Cursor 匯總并記錄到外置文檔，以便在后續的對話中補充上下文（也可以借助 @Summarized Composers 實現）。在面對下一個任務時，開啟新的會話進行問答，多輪下來形成由不同模塊組裝而成的方案設計。
這樣一來，在生成代碼階段，Cursor 所需要面對的只是局部復雜度中的改動，這能很大程度上減緩我們在代碼審核和驗證上的投入成本。Cursor 也能始終保持在長度限制范圍內，面對精煉后的方案設計進行決策和產出。
因此在整體流程上：
1. 拆解需求，縮小關注范圍
2. 明確目標，清晰表達需求描述
- Cursor 提供方案
- 檢查是否有理解偏差，并不斷調整提示
- 在確認方案后，最終由 Cursor 匯總成果
3. 漸進開發，分模塊由 Cursor 生成代碼，及時驗證效果和審核代碼
提示詞參考：
- 方案設計
我們先探討方案，在我讓你寫代碼之前不要生成代碼
如果此處要加個 xxx 該怎么做，請先逐步分析需求
在想明白后向我說明為什么要這么設計- 代碼產出，在功能之外，留意識別邊界場景以及控制影響面
在寫代碼時遵循最小改動原則，避免影響原先的功能
即使識別到歷史問題也不要自行優化，可以先告知我問題描述和對當前需求的影響，不要直接改跟本次需求無關的代碼影響評估
除去開發之前的方案耗時，在完成開發后，我們所要解決的是如何保障自測質量的問題。對于研發而言，需要關注的是在這個需求迭代內，改動點所關聯的調用鏈路，而在這個路徑依賴下不斷冒泡所涉及到的具體功能就是影響面。
因此可以從兩個方面提高自測可信度
- 自下而上：基于改動代碼和依賴項進行白盒測試，這需要研發自身投入必要的時間進行代碼審核；
- 自上而下：識別改動最終涉及到的頁面和功能進行黑盒測試，逐個回歸和確認功能是否符合預期。
借助 Cursor 可以很低成本地分析改動，并按需產出測試用例，通過 @git 指令讓 Cursor 參與到對當前功能分支或具體 commit 的評估：
目標 | 代碼審查 | 功能驗證 |
提示詞 | @git 逐個文件分析并總結改動點，評估是否引入了新的問題。 | @git 基于代碼變更輸出自測用例清單。 |
效果 | 在列舉出每個文件的改動意圖后，會告知潛在問題和修改意見。
| 圍繞改動，生成新舊功能在不同場景中的測試用例。
|
六、小結
過去，成為一名優秀開發者需要經歷漫長的積累：從反復查閱文檔、在搜索引擎中篩選有效信息，到系統掌握編程語言、算法與網絡原理，每一步都在構建扎實的「知識護城河」。而 AI 時代顛覆了這一邏輯 —— 當大模型能快速生成代碼、解析技術方案時，開發者的核心能力似乎從“記憶與執行”轉向成了“正確地提問，讓 AI 提供答案”。
客觀來看，AI 降低了信息獲取的門檻，能更快地落地想法、驗證思路。不變的是，好的答案源于好的問題，而提出好問題依舊需要積累專業領域下的知識，知道的越清楚才能在提問時描述得越清晰。
所有事都有吃力不討好的部分，隨著 Cursor 等 AI 工具在工程中的應用，我們可以逐漸將這部分職能分配出去，利用我們的知識儲備，描述問題，引導過程，審核結果。工具的使用始終是為了節省人類體力和腦力的開銷，從而在提升體驗的同時提升生產力，以更充沛的精力聚焦在工作成果和個人成長上。
