引言

最近一段時間，回收團隊一直堅持用Cursor來輔助開發，并在AI開發模式上進行了多次迭代。今天，我想和大家分享一些我們在AI編程方面的實踐心得。

首先要明確的是，AI編程并不能取代程序員的獨立編碼能力，也不是說簡單配置幾個MCP就能讓AI的編程能力發生質的飛躍。今天我將重點從實際應用出發，分享一些AI編程的思路與流程優化經驗，幫助各位真正的在項目開發中，把AI用起來。

我們到底能用Cursor干什么

我一直在思考，作為一個月使用成本超過100塊的“權威”工具來說，如果只讓他做一些bean的生成，mapper的生成，未免太過于浪費。但是如果直接把需求文檔喂給他，生成的代碼距離我們的期望又太大。我們總說，想讓AI生成符合要求的代碼，需要詳細的將我們的需求寫成提示詞告訴AI，但是到底如何才算詳細呢？如何才能寫出這份詳細的提示詞呢？

下面是我使用Cursor進行項目開發的三步走：

1. 由Cursor幫助開發者拆分項目——初步完成提示詞框架
2. 由開發者幫助Cursor理解項目——豐富提示詞內容
3. 完成開發后由Cursor幫助開發者進行回歸驗證

一、讓Cursor幫助你更好地拆分項目

既然直接生成代碼難度太大，我們能不能先嘗試讓AI做一些更簡單的事情，比如分析一下需求文檔。

一般來講，對于一個項目的分析主要分兩步：

1. 對于項目新流程的分析
2. 對于相關現狀的分析

上述步驟步完成后我們期望Cursor能夠基于需求PRD文檔，幫我們總結一份兼容當下系統邏輯的初步的功能分析文檔（不需要功能的具體實現方案，只需要確定有哪些功能即可），包括一些實體類、VO對象的定義，接口定義，數據庫表定義等等。

1.1、針對新流程（PRD文檔）的分析

Cursor可以很好的分析并總結PRD文檔的內容，但產品給出的PRD文檔中不可避免的會對一些“眾所周知”的上下文進行省略，Cursor也因此無法得知項目的全貌，單純把PRD文檔喂給Cursor并不能讓他直接生成符合我們期望的代碼。

但這不代表我們在這一階段完全無法讓Cursor為我們創造價值。我們可以利用Cursor的分析總結能力，梳理PRD文檔中的功能點與要點，加速自己理解項目，并結合自己對prd的理解進行雙向驗證。避免后期開發時出現與產品理解不符或者遺漏功能點。

使用Cursor讀取并分析本次需求PRD文檔的內容時，為了不被上下文長度所限制，我們需要讓Cursor將他的思考結果進行記錄。例如下面的提示詞：

https://dashen.zhuanspirit.com/pages/viewpage.action?pageId=xxxxxxxx 
提取一下上面鏈接的文檔中的內容。幫我提煉【XXXXX賬單】部分相關功能，有哪些需要開發的功能點，注意，我們本次僅需要查詢XXXX列表以及查詢XXXX流水詳情，其余相關功能和組件已經實現完成。
分析你需要拆分出多少個功能點以及接口

在我讓你寫代碼之前不要生成代碼，先逐步分析需求，再說明你打算怎么做
將你的思考以md的形式保存在.docs/技術設計.md下

也許你的在線PRD文檔需要登錄才可查看，這里給出兩個解決方案：

1. 找到你的本地cookie，讓Cursor帶著cookie對你的在線文檔進行訪問
2. 使用mcp，具體方法這里不進行展開

然后，反復與AI進行溝通，明確告訴他我們需要什么，不需要什么，例如下面的提示詞。

我們不做數據同步與保存相關的工作，從設計方案中剔除，所有的數據已經準備就緒，我們只需要查詢就可以了
幫我設計這個接口的查詢的參數與返回值

下面是基于Cursor進行PRD文檔分析的基本流程：

Cursor輔助確認PRD文檔功能點的過程

首先明確一點：不要試圖讓Cursor來教我們如何做項目，而是讓它協助完成每個環節。所以如果覺得自己可以更快更準確的修改文檔的某一部分，主動去修改，不要讓AI來做。比如，AI幫忙設計了一個實體對象，但是其中部分字段命名不符合我們的業務要求，我們就不要讓AI來修改了，直接動手修改md文檔。

另外，如果你親自改動的內容很多，建議下次跟Cursor溝通的時候新開啟一個對話框，重新讓他讀取PRD文檔及對應的分析文檔，否則Cursor會保留之前生成的記憶，導致你的改動可能不會生效。

下面是此階段生成的功能分析文檔的部分展示：

1.2、對于目前已有代碼的分析，以及影響范圍分析

相比于開發者來說，Cursor會更貼近代碼。我們可以在Cursor的協助下更好地完成現有業務流程的梳理。 更具體的講，我們可以從需求的目標改動點開始，梳理其所屬功能和實現方式，包含數據管理、交互流程等等。 這里介紹一下我們常用的Cursor插件： Mermaid Preview插件，與Markdown Preview Enhanced插件。

流程圖生成插件

安裝完插件并重啟cursor后我們便可以通過如下提示詞進行流程圖生成了。

com.xxx.xxx.xxx.xxx.facade.SxxxxxxxxFacade#getxxxxxx
針對該方法幫我生成一個.md的業務流程圖

對于復雜的系統流程來說，我們可以基于此種方法生成流程圖，輔助確定本次改動的代碼的影響范圍。

二、幫助Cursor更好地理解項目，并生成代碼

我們總是希望有一個工具來幫助我們挖掘AI的潛力，讓他更好的明白我們的系統，了解我們的業務，例如各種知識庫，各種Rule?即使AI的思維能力可以與真人媲美，我們也很難想象讓你身邊的某一位經驗豐富的同事僅依靠產品文檔就可以準確的完成項目開發。項目過程中必然會經歷多次溝通,多次方案修正，最終多方達成一致，再進入開發階段。 同樣，在正式進行開發前，我們也需要有一份技術文檔來指導Cursor進行開發。不同于前面需求文檔的簡單分析，這一部分的分析需要對每一個功能有詳細的描述。我們可以基于之前落地md文檔繼續進行完善。這一階段的主要目標是為Cursor補充上下文細節并核驗Cursor結論的過程。我們需要針對每一個功能點：

1. 調整AI的命名方式與代碼生成位置（可以使用Rule進行簡化）。
2. 調整AI使用的工具類與服務類。
3. 調整AI的邏輯細節（例如調整校驗規則，判斷順序等）。
4. 調整AI的業務細節（優先從PRD文檔上節選原文給到Cursor，嘗試讓Cursor理解。如果PRD文檔沒有寫清業務流程，就自己動手描述流程或者干脆直接讓Cursor跳過生成并預留方法，方便后面自己動手補充邏輯）。

最終我們得到了這樣一份詳細描述了業務功能的md文檔：

如此一來，得到的這份文檔實際上是我們與Cursor都能理解，并且達成一致的。我們終于得到了那份可以供我們用作“生成提示詞”的功能分析文檔，基于這份文檔后續Cursor生成的代碼也都基本可以滿足要求。

下圖為使用Cursor生成代碼的整體邏輯流程：

需要注意的是，我們每次只就一個功能點進行分析，并且一旦你覺得這個功能點已經相對完善，盡快落地成代碼，不要留在一起，讓AI最后一起生成。 一方面AI在處理過多的內容時會不可避免的產生偏差，另一方面，如果項目過大，我們也容易忘記一些細節，導致花費額外的時間來進行回憶與驗證。

三、Cursor幫助開發者進行回歸驗證

除去開發階段的輔助作用，Cursor另一大作用體現在開發后的輔助質量保證上。通常體現在以下兩個方面：

1. 改動影響評估
2. 功能驗證

為了實現上述能力，我們按照三步走的方式來進行

3.1、改動范圍整理

使用下面的命令逐個文件分析當前分支改動點并輸出到cr.diff 文件中，隨后在md文件末尾進行總結：git diff origin/master  > cr.diff

3.2、基本代碼審查

我們可以使用下面的提示詞引導Cursor進行基本代碼審查：

掃描diff 文件中的差異代碼。reviwe 的規則如下

1. 方法體行數應少于100行, 不包括空行,和注釋
2. 枚舉定義需要有兩個以上屬性, code, name, 并且需要有通過code獲取枚舉項的方法
3. 接口返回false , 前端是否有對false進行處理 
4. throw 了異常的位置, 一定要打log日志 
5. 所有的public 公有方法都要打印入參log.info日志 
6. 所有的public 公有方法, 結束都要打印結束日志 
7. 所有調用rpc的方法, 都要打印日志
8. 所有方法都要有方法級別的注釋
9. try catch異常后, 如果在catch 中又拋出了新創建的異常時, 需要將原異常賦值給新異常
10. 不能調用被標記@Deprecated 的屬性或方法或類
11. 定義的常量值, 給出清晰的注釋說明用途, 避免硬編碼
12. 標注了@transactional的方法要明確回滾異常類型, 對于只讀操作要標注只讀readOnly=true 提高性能
13. 3次以上字符串拼接使用StringBuilder代替字符串拼接
14. 檢查是否存在其他破壞兼容性的改動或邏輯上的錯誤
15. 檢查是否存在循環調用導致的邏輯問題
16、新增的頁面提交和支付相關流程要考慮冪等處理
17、接口可能被重復調用和mq消息重復接收場景要考慮并發和事務沖突和數據覆蓋，要善用分布式鎖
18、針對數據庫單一字段的修改，盡可能要精確修改，使用整體對象進行修改
19、是否存在重復代碼
20、修改邏輯是否設計到計數系統口徑的修改
21、數據交互過程中（數據庫和外部調用）的空指針判斷和處理
22、狀態流轉過程和涉及資產損失的部分要對前置狀態進行校驗
23、涉及數據庫和外部事務的接口，要保證整體事務的一致性，無法保證的要有補償機制
24、涉及異步回調的場景，要考慮中間態的處理
25、不允許把配置規則交給運營同學
26、返回的list類型，要給定默認值，不能給null
27、主鍵必須設置自增或者使用分布式id
28、數據庫表是否建立了索引
29、異常場景要打印報警，盡可能優先多打印
遍歷所有規則, 一個規則一個規則的去檢查增量代碼的規范性, 每個規則進行Review時, 使用獨立的上下文, 最后歸納所有的Review結果.
輸出違反規則的文件位置, 在我說可以修改之前不要修改文件

3.3、功能輔助驗證

在完成代碼生成與初步審查后，我們進入功能驗證階段。此時可利用Cursor分析代碼變更，自動生成自測用例清單。通過提示詞引導Cursor結合業務邏輯、接口輸入輸出及異常分支，輸出覆蓋核心路徑、邊界條件和錯誤處理的測試場景。

例如：

基于當前代碼變更，列出需要自測的功能點和邊界情況，包括正常流程、異常輸入、狀態校驗等，輸出為表格形式，包含用例編號、場景描述、預期結果。

該過程不僅是測試準備，更是對整體邏輯的再確認。通過Cursor輔助驗證，提升自測完整性，減少后期回歸成本，確保交付質量。

小結

至此，本文分享了回收團隊在AI編程實踐中的經驗，重點介紹了如何高效使用Cursor輔助開發。通過分階段協作——從需求分析，現狀梳理到技術設計，代碼生成，再到測試驗證。

AI時代，開發者的核心競爭力正從“掌握知識”轉向“提出問題”。工具如Cursor并非替代開發人員，而是通過人機協同，提升需求理解、技術設計與代碼質量的效率。我們要以專業積累構建清晰上下文，引導AI完成拆解、分析、生成與驗證，最終實現高效、高質量的開發閉環。

關于作者，黃敬乾，俠客匯Java開發工程師。