如何讓AI成為你的程式設計搭檔？一次真實重構告訴你答案

2025-07-15 15:21 阿里雲開發者

引言綜述
效率提升一直是開發者的不懈追求。大語言模型被世人熟知以來，AI程式設計逐步進入人們的視野。從程式碼垂域模型到與IDE的工程應用結合，從GitHub Copilot到Cursor，AI對研發流程的滲透在不斷深入，對於開發者也從淺嘗輒止的新奇物變為了不可或缺的助手。Cursor就是在本次大模型浪潮中立於潮頭的“AI原生化”程式設計工具。
Cursor簡介
Cursor 是一款面向開發者的智慧程式碼編輯器。它基於強大的 VS Code，更深度集成了AI模型。開發者可以直接用自然語言讓它幫你編寫新程式碼、解釋複雜邏輯、重構現有程式碼、查詢 Bug。它理解專案上下文，像一個在 IDE 裡隨時待命的超級程式設計助手，旨在大幅提升開發效率和探索速度。
Cursor的能力與侷限
Cursor提供三種內建模式：Agent、Ask 和 Manual。Agent模式是預設模式，可以自主學習和探索程式碼庫，能夠進行跨檔案的大範圍修改和重構。Ask模式專注於程式碼理解和問題解答，不會對程式碼進行修改。Manual 模式是 Cursor 的精準編輯工具，只依賴使用者提供的具體指令和上下文，不會自動探索程式碼庫或執行命令。同時，Cursor已經支援自定義模式，允許我們為特定的工作流程建立更適合自己的模式。
上述這些模式反映了它與傳統Copilot等程式碼提示工具的核心超越之處，如：
  • 產品形態更原生。獨立的程式碼編輯器而非外掛，編輯區即對話介面。透過自然語言可以實現幾乎所有需要的能力，如命令執行、編譯執行等。
  • 開發能力更強大。可以主動學習程式碼庫，直接生成跨檔案的完整邏輯，並擁有主動重構能力。從而實現“模組級”任務開發，而非僅有行級或單檔案級。
  • 參與週期更深度。不止在於程式碼開發階段，更深入到前期方案設計、後期測試CR等階段，都可以使用Cursor一站式解決或輔助解決。
但是，Cursor並不是“銀彈”。它也有很多並不“得心應手”的地方，如：
  • Cursor依賴於底層模型的能力，大模型本身當前無法解決的問題在它身上都會體現。比如不論是學習程式碼和文件的讀需求，還是單次產出程式碼的寫能力，都是有限的。如果超出“記憶能力”限制，會引發極大的不穩定。
  • 當前Cursor對於跨應用的支援並不好，無法解決跨應用更勿論跨團隊分工的複雜需求。
  • Cursor在各個研發環節的支援能力不盡相同，且需要很多工程方面的限制來達到開發者的預期目標，杜絕天馬行空。
系列內容概述
綜上所述，一個“能力超強”但是“有稜有角”的工具，就更加考驗使用者的經驗和技巧。生產工具的升級必定引發生產流程的改進，以何種思路、方法、正規化，去最大化Cursor帶來的效率提升，並最小化其薄弱之處和引入風險，是當前在團隊中最需要思考的問題。
本系列將從一個普通開發者的視角及一個團隊推動者的視角，淺談如何將Cursor真正落地於業務需求開發。
  • 本篇作為第一篇是筆者個人在複雜重構類需求中全流程使用Cursor的過程，總結單點經驗教訓。
  • 第二篇是在團隊中推進Cursor覆蓋提效的正規化生成與落地經驗。
  • 後續可能涉及Cursor及Agent本身的原理性探究，幫助大家更好地使用。
對於結合業務功能要求的重構類需求，由於歷史邏輯錯綜複雜、新功能迭代週期要求快速，一般很難高質量完成。本篇是筆者在明確業務需求後，結合當前團隊的技術重構目標，並結合Cursor的長項評估，決定以此需求作為第一個全程使用Cursor的試驗。最終效果非常好，在此分享使用路徑及“踩坑填坑”經驗。
需求背景
業務背景
1.整體業務背景：高德商家平臺經營成長業務，包含店鋪裝修相關功能。B端商家生產內容，如官方相簿、品牌故事、特色推薦等模組，作為店鋪裝修的一部分，提供給C端使用者消費。
2.本期需求背景：需要新增一個“找路指引”模組，商家在B端上傳圖文影片等模態的內容，指導C端使用者如何從附近地標到達店鋪，“打通最後100米”。
技術背景
1.歷史技術問題：
a.資料模型設計過於複雜，且由於命名不規範等導致理解成本過高。
b.由於資料模型複雜，介面的出入參特別複雜，且存在多級巢狀情況，造成理解維護困難。
c.內部呼叫鏈路過於複雜，存在很多handler分支邏輯，難以梳理呼叫鏈路。且應用內歷史模組和業務邏輯半數以上不再使用。
2.整體技術架構：
a.由於本文主要為了說明Cursor使用，具體店鋪裝修域的技術架構並非本文重點，不在此詳細介紹。讀者可以簡單理解為將裝修內容劃分為“內容元素”和“元素與店鋪的繫結關係”兩個領域實體，圍繞這兩個領域展開內容相關的增刪改、稽核、下游互動等一系列鏈路。
3.本期技術目標：
a.由於新增業務模組，故本次同時對歷史技術鏈路進行重構，後續逐步將歷史業務模組遷移。
b.重構目標包括：
i.簡化資料模型，降低理解和維護成本；
ii.最佳化介面設計，降低介面複雜度並解決多級巢狀問題；
iii.清晰呼叫鏈路，減少複雜的handler邏輯，提高程式碼可維護性；
實現過程
下面按照實際做需求的順序分享本次實現過程。篇幅限制，將挑選重點鏈路，體現與Cursor互動過程。本次實踐主要體現在方案設計階段和程式碼開發階段，整體流程摘要如下：

歷史邏輯梳理
由於是重構類需求，首先要將歷史業務邏輯全部梳理清楚，剔除廢棄的業務邏輯，重新規劃組織。沉澱領域能力，並實現清晰的業務編排。

整體應用框架梳理

目標是讓Cursor輔助梳理整體應用概況，實現對應用的全域性性掌握。但是本應用由於之前做過人工的梳理，故本步驟跳過。如果需要，也可以使用Rules對Cursor進行要求和指導。

具體介面流程梳理

重構涉及到的介面都要進行全流程業務邏輯Review，本文挑選較為複雜的“儲存元素並繫結關係”介面，進行歷史邏輯梳理展示。
由於是跨應用介面，介面入口及部分業務編排在A應用，底層業務能力在B應用。我嘗試過將兩個應用放在同一個Cursor工作空間中同時操作，最終Cursor會詳細給出A應用的業務流程，其中對B應用的呼叫僅用“B應用的處理流程”一句話帶過。即使後續與Cursor對話調整也無法做到預期的顆粒度。故對於多個應用需要分別梳理，然後讓Cursor進行拼接。
為了使Cursor的梳理顆粒度、關注點及輸出方式等能夠達到預期，我們使用Rules規範介面梳理過程：
歷史介面邏輯梳理Rules
---description: 此規則為分析軟體介面提供全面指南，確保充分理解和文件化複雜介面的業務邏輯和技術實現。當開發人員需要理解現有介面、重構介面實現或建立技術文件時應用此規則。它幫助分析人員系統性地探索原始碼，從入口到資料庫操作全面跟蹤呼叫鏈，併產出足夠詳細的流程描述以支援直接開發和重構。該規則適用於微服務、分散式系統和複雜業務場景，特別適合需要深入理解介面工作原理而無需反覆查閱原始碼的情況。globs: alwaysApply: false---# 介面邏輯分析與文件生成規則## 關鍵規則- 分析介面時必須先透過原始碼搜尋工具明確定位入口點，從Controller或HSF入口處入手- 必須完整追蹤呼叫鏈路，跟蹤從入口到持久層及外部系統呼叫的完整路徑- 必須識別並解釋所有條件分支和判斷邏輯，包括每個分支的觸發條件- 必須詳細分析介面中的資料校驗規則、轉換邏輯和持久化操作- 必須識別並解釋併發控制機制，如分散式鎖、事務等的使用場景和作用範圍- 必須分析所有業務規則實現，包括權益/許可權檢查和特殊業務場景處理- 必須分析配置驅動的處理邏輯和動態載入的處理器鏈- 必須分析非同步處理環節，包括訊息傳送、事件釋出和稽核流程- 必須提供按執行順序的步驟式流程描述，每個步驟包含具體處理邏輯- 必須使用mermaid語法建立詳細流程圖，展示主流程和所有重要分支- 必須明確標識同步/非同步操作，及其觸發條件和處理路徑- 必須描述資料模型和關鍵業務實體，包括主要屬性和業務含義- 必須提供足夠的細節，使開發人員能直接基於分析結果進行開發，無需再次查閱原始碼## 原始碼探索方法1.**介面入口確定**   - 使用檔案搜尋和程式碼搜尋工具定位介面入口   - 優先識別Controller類中的目標方法，關注RequestMapping等註解   - 確認HTTP請求型別、路徑和接受的引數格式   - 如果沒有Controller中的目標方法，也可能是HSF呼叫，可以尋找相關的HsfService2.**呼叫鏈路跟蹤**   - 從入口方法開始，逐層跟蹤方法呼叫關係   - 重點關注Service層的實現類和方法   - 注意分析AOP切面和攔截器對介面的影響   - 追蹤到最底層的資料庫操作和外部系統呼叫3.**配置分析**   - 檢查application.yml/properties等配置檔案   - 特別關注與目標介面相關的配置項   - 分析基於配置的條件處理和動態載入邏輯4.**元件與中介軟體識別**   - 識別介面涉及的所有服務和元件   - 確定使用的中介軟體型別和用途   - 分析元件之間的互動方式## 輸出組織1.**文字流程描述**   - 提供按執行順序的步驟式描述   - 每個步驟包含具體的處理邏輯和條件判斷   - 使用縮排表示邏輯層級關係   - 明確標識同步/非同步操作2.**流程圖**   - 使用mermaid語法建立詳細流程圖   - 清晰劃分系統和元件邊界   - 整體使用一張圖   - 透過不同線型區分同步和非同步流程3.**資料模型**   - 描述關鍵業務實體及其關係   - 列出主要屬性及其業務含義   - 說明表間的關聯關係4.**關鍵程式碼分析**   - 重點解釋複雜演算法和資料處理邏輯   - 說明特定業務規則的實現方式   - 分析效能最佳化手段## 示例<example>使用者: 請分析/api/orders/create介面的實現邏輯。AI: 我將對/api/orders/create介面進行全面分析。首先我需要定位入口點並追蹤完整呼叫鏈路。[使用程式碼搜尋工具定位入口點]找到了入口點: OrderController.createOrder(@RequestBody OrderCreateRequest request)方法。詳細分析流程:# /api/orders/create介面完整實現分析## 1. 入口處理 - OrderController.createOrder- 接收OrderCreateRequest物件，包含userId, items[], paymentMethod等欄位- 資料校驗: 檢查userId不為空，items不為空且至少有一項，paymentMethod在支援列表內- 建立OrderContext物件，儲存請求引數和處理狀態- 呼叫orderService.createOrder(OrderContext)處理業務邏輯## 2. 業務處理 - OrderServiceImpl.createOrder- 分散式鎖控制: 加鎖key=order:create:{userId}，防止同一使用者併發下單- 使用者校驗: 呼叫userService.validateUser(userId)驗證使用者狀態和許可權- 商品處理:  - 遍歷items列表，呼叫productService.getProductDetails獲取最新價格和庫存  - 檢查庫存是否充足，不足則丟擲InsufficientStockException  - 計算訂單總價並與請求中價格比對，差異超過閾值丟擲PriceChangedException- 優惠處理:  - 如存在優惠券，呼叫promotionService.applyPromotion計算折扣  - 根據使用者等級應用會員折扣- 支付預處理:  - 建立支付單，呼叫paymentService.preparePayment  - 獲取支付連結或支付引數- 訂單建立:  - 生成訂單號: 呼叫idGenerator.generateOrderId()  - 建立OrderEntity，設定狀態為CREATED  - 呼叫orderRepository.save(orderEntity)儲存訂單  - 建立OrderItemEntity列表並儲存- 鎖定庫存:  - 呼叫inventoryService.lockStock(items)鎖定庫存  - 設定庫存鎖定過期時間為30分鐘- 傳送訊息:  - 透過MQ傳送ORDER_CREATED事件  - 事件包含訂單基本資訊，不包含敏感支付資料- 返回結果:  - 構建OrderCreateResponse，包含orderId和paymentInfo  - 解鎖分散式鎖  - 返回響應結果## 3. 非同步處理流程- 庫存鎖定超時處理:  - 定時任務每5分鐘檢查過期庫存鎖定  - 對超過30分鐘未支付的訂單，釋放庫存鎖定  - 更新訂單狀態為CANCELLED- 訂單建立事件處理:  - 物流系統訂閱ORDER_CREATED事件準備配送資訊  - 資料分析系統訂閱事件更新銷售統計  - 使用者中心訂閱事件更新使用者行為畫像## 資料操作詳情- orders表:  - 插入新記錄: id, user_id, total_amount, status='CREATED', created_at, payment_method- order_items表:  - 批次插入: order_id, product_id, quantity, unit_price, subtotal- inventory_locks表:  - 批次插入: product_id, quantity, order_id, expire_at=now()+30min## 異常處理- 庫存不足: 返回HTTP 400，錯誤碼10001，提示具體缺貨商品- 價格變動: 返回HTTP 409，錯誤碼10002，提示重新下單- 使用者無效: 返回HTTP 403，錯誤碼10003- 支付渠道異常: 返回HTTP 503，錯誤碼20001，觸發重試機制- 資料庫異常: 回滾事務，返回HTTP 500，記錄詳細錯誤日誌[這裡還有詳細的mermaid流程圖和資料模型分析...]</example><exampletype="invalid">使用者: 分析使用者登入介面AI: 使用者登入介面的分析:登入介面負責驗證使用者憑證並返回訪問令牌。入口是AuthController中的login方法，該方法:1. 接收使用者名稱和密碼2. 驗證使用者資訊3. 建立JWT令牌4. 返回給使用者使用者提交憑證後，系統會查詢資料庫驗證身份，然後建立一個包含使用者ID和角色的令牌。這個分析存在以下問題:- 沒有完整跟蹤呼叫鏈路- 沒有分析校驗規則和處理邏輯- 沒有提供實際的方法名和引數- 沒有說明使用了什麼元件和中介軟體- 缺少具體的資料操作說明- 沒有分析異常處理路徑- 過於簡略，無法用於開發- 沒有提供流程圖</example>
分別在AB兩個應用使用該Rules進行梳理，然後給Cursor指明拼接位點，Cursor進行邏輯拼接彙總，成果如下：

流程重新編排

此過程必須人工實現，Cursor無法感知哪些功能是正在使用的，及業務應該以何種角度去梳理整合。與Cursor關聯較小，故細節不在本文章體現。
技術方案設計

前期準備

1.明確當前應用的開發規約，並形成Rules用於後續方案設計和程式碼開發。否則Cursor在開發時會胡亂建立包路徑和檔案，程式碼編寫也毫無章法，極大增加Review和修改的複雜度和成本。針對本應用生成的Rules如下，其中包含應用框架規範、檔案目錄規則、命名規則、程式碼風格規約等，及具體的示例：
---description:globs: **/*.javaalwaysApply: false---# mall-pink-dolphin 微服務專案結構規範## 關鍵規則-**所有程式碼必須按照模組化架構放置在正確的位置**，詳見下方模組職責說明-**列舉和常量優先使用公共模組**:- 公共列舉必須放在 `new-b-dolphin-common` 模組的 `com.amap.mp.dolphin.common.enums` 包下- 公共常量必須放在 `new-b-dolphin-common` 模組的 `com.amap.mp.dolphin.common.constants` 包下- 僅當列舉或常量是模組特定的，才可放在對應模組中-**介面定義必須先於實現**，使用介面和實現分離的方式-**嚴格遵循分層架構，禁止跨層呼叫**，必須透過合適的介面呼叫-**資料物件(DO)必須放在正確的位置**，詳見下方DO規範說明-**單元測試必須放在mall-pink-dolphin-start模組中**，確保測試環境的一致性- 公用的方法，必須先寫interface再寫實現。每個interface有Base類實現，每個模組可以在Base類實現的基礎上進行自己的override方式## 模組職責### 1. new-b-dolphin-app (業務服務層)- 路徑: `com.amap.mp.dolphin`- 責任: 實現業務邏輯，業務編排，呼叫領域層- 包含:- `service`: 核心業務服務介面和實現類- `dto`: 返回值傳輸物件，及資料結構轉換類- `executor`: 入參傳輸物件，及資料結構轉換類### 2. new-b-dolphin-client (客戶端層)- 路徑: `com.amap.mp.dolphin`- 責任: 定義對外暴露的介面和處理外部請求- 包含:- `consumer`: 訊息佇列消費者客戶端實現- `controller`: Web控制器，處理HTTP請求- `hsf`: HSF服務介面定義和實現### 3. new-b-dolphin-domain (領域層)- 路徑: `com.amap.mp.dolphin`- 責任: 定義領域模型和領域邏輯- 包含:- `model`: 領域模型，封裝業務實體和規則- `enums`: 領域特定的列舉型別- `transfer`: 領域物件轉換器- `domainservice`: 領域服務，封裝特定領域的業務邏輯### 4. new-b-dolphin-infrastructure (基礎設施層)- 路徑: `com.amap.mp.dolphin`- 責任: 實現資料訪問、外部服務呼叫等基礎設施- 包含:- `mapper`: MyBatis資料庫對映介面- `dataobject`: 資料物件(DO)，用於資料庫訪問- `gatewayimpl`: 閘道器介面實現，封裝外部服務呼叫- `diamond`: Diamond配置中心相關實現- `config`: 配置類- `acl`: 防腐層，隔離外部系統變化### 5. new-b-dolphin-common (公共層)- 路徑: `com.amap.mp.dolphin.common`- 責任: 提供通用工具類、常量、列舉等- 包含:- `utils`: 通用工具類- `constants`: 公共常量（**優先在此定義常量**）- `enums`: 公共列舉（**優先在此定義列舉**）- `exception`: 異常類## 資料物件(DO)規範### DO物件存放位置**關鍵規則**: 資料物件(DO)必須放在new-b-dolphin-infrastructure模組的dataobject包中，嚴格遵循以下位置規範：1. **資料訪問物件**:- 位置: `new-b-dolphin-infrastructure/src/main/java/com/amap/mp/dolphin/dataobject/`- 命名規範: 使用業務實體名加DO字尾，如`OrderDO.java`- 使用場景: 用於資料庫表對映的物件，通常與資料庫表結構一一對應### DO物件編寫規範1. **註解規範**:- 必須使用`@Data`或手動實現getter/setter方法- 推薦使用`@Builder`、`@NoArgsConstructor`、`@AllArgsConstructor`等Lombok註解減少樣板程式碼-MyBatis對映物件必須新增`@TableName("表名")`註解2. **屬性規範**:- 必須註釋說明每個欄位的業務含義- 欄位命名必須使用駝峰式，與資料庫欄位命名保持對應關係- 日期型別優先使用`java.util.Date`型別3. **類註釋規範**:- 必須包含類級別JavaDoc註釋，說明該DO物件的業務用途- 註釋格式必須包含"資料物件"說明和對應的資料表說明### 使用DO物件的程式碼規範1. **Mapper介面定義**:-Mapper介面必須指定對應的DO型別- 示例: `public interface OrderMapper extends BaseMapper<OrderDO>`2. **DO物件轉換**:-DO物件到領域物件的轉換應在Repository實現類中進行- 禁止在Service層直接使用DO物件- 必須透過Repository介面間接訪問DO物件## 單元測試結構- 所有單元測試必須在 `mall-pink-dolphin-start/src/test/java/com/amap/mp/dolohin/newbdolphin/` 目錄下- 測試類命名必須符合被測試類名+Test的格式，如`OrderServiceTest`- 測試方法命名應清晰表明測試的功能和預期結果## 開發新功能流程規範1. **定義領域模型**: 在new-b-dolphin-domain中定義領域模型和服務2. **實現資料訪問**: 在new-b-dolphin-infrastructure中實現資料物件和資料訪問3. **實現業務邏輯**: 在new-b-dolphin-app中實現業務服務4. **實現介面層**: 在new-b-dolphin-client中實現對外介面5. **編寫單元測試**: 在mall-pink-dolphin-start中編寫單元測試## 列舉和常量規範**關鍵規則**: 儘可能使用公共列舉和常量，僅當列舉/常量是高度模組特定的才進行本地定義### 列舉定義位置:1. **第一優先順序**: `new-b-dolphin-common.enums` 包 - 用於跨模組共享的列舉2. **第二優先順序**: `new-b-dolphin-domain.enums` 包 - 用於領域特定的列舉3. **最後選擇**: 模組內部特定包 - 僅用於模組內部使用的列舉### 常量定義位置:1. **第一優先順序**: `new-b-dolphin-common.constants` 包 - 用於跨模組共享的常量2. **第二優先順序**: `new-b-dolphin-domain.constants` 包 - 用於領域特定的常量3. **最後選擇**: 模組內部特定包 - 僅用於模組內部使用的常量## 示例<example>// 正確地定義列舉和常量// 1. 公共列舉 - 定義在new-b-dolphin-common中package com.amap.mp.dolphin.common.enums;publicenumOrderStatus {CREATED("已建立"),PAID("已支付"),DELIVERED("已發貨"),COMPLETED("已完成"),CANCELLED("已取消");privatefinalString desc;OrderStatus(String desc) {        this.desc = desc;    }publicString getDesc() {return desc;    }}// 2. 公共常量 - 定義在new-b-dolphin-common中package com.amap.mp.dolphin.common.constants;publicclassOrderConstants {publicstaticfinalStringORDER_PREFIX="ORD";publicstaticfinal int DEFAULT_PAGE_SIZE=20;publicstaticfinal long ORDER_EXPIRE_TIME=30*60* 1000L; // 30分鐘}// 3. 正確的介面定義和實現// 介面定義在new-b-dolphin-clientpackage com.amap.mp.dolphin.hsf;public interface OrderService {ResultDTO<OrderDTO> createOrder(OrderCreateRequest request);}// 實現在new-b-dolphin-apppackage com.amap.mp.dolphin.service.impl;@ServicepublicclassOrderServiceImplimplementsOrderService {@AutowiredprivateOrderDomainService orderDomainService;@OverridepublicResultDTO<OrderDTO> createOrder(OrderCreateRequest request) {try {OrderModel orderModel = orderDomainService.createOrder(request);returnResultDTO.success(orderConverter.toDTO(orderModel));        } catch (Exception e) {returnResultDTO.error("建立訂單失敗");        }    }}// 4. 正確的DO物件定義// 資料物件 - 定義在infrastructure.dataobject包中package com.amap.mp.dolphin.dataobject;import lombok.Data;import java.util.Date;import com.baomidou.mybatisplus.annotation.TableName;/** * 訂單資料物件 * 對應表：t_order */@Data@TableName("t_order")publicclassOrderDO {/**     * 主鍵     */privateLong id;/**     * 建立時間     */privateDate gmtCreate;/**     * 訂單編號     */privateString orderNo;/**     * 訂單狀態     */privateInteger status;// 其他屬性...}</example><example type="invalid">// 錯誤的程式碼結構示例// 1. 錯誤：在錯誤的模組中定義列舉package com.amap.mp.dolphin.service.enums;  // 錯誤：應該放在common.enums包下publicenumPaymentType {  // 這是一個應該在公共模組的列舉ALIPAY, WECHAT, CREDIT_CARD, CASH;}// 2. 錯誤：跨層呼叫package com.amap.mp.dolphin.service;@ServicepublicclassOrderServiceImplimplementsOrderService {@AutowiredprivateOrderMapper orderMapper;  // 錯誤：直接呼叫基礎設施層，應該透過repository介面@OverridepublicOrderDTO createOrder(OrderCreateRequest request){OrderDO orderDO = new OrderDO();// 設定DO屬性...        orderMapper.insert(orderDO);  // 錯誤的直接呼叫return convert(orderDO);    }}// 3. 錯誤：DO物件放在錯誤的位置package com.amap.mp.dolphin.model;  // 錯誤：DO應該放在infrastructure.dataobject包中import lombok.Data;/** * 訂單資料物件 */@DatapublicclassOrderDO {  // 錯誤：應該放在infrastructure.dataobject包中privateLong id;privateString orderNo;// 其他屬性...}// 4. 錯誤：使用未經轉換的DO物件返回給外部package com.amap.mp.dolphin.controller;@RestControllerpublicclassOrderController {@AutowiredprivateOrderService orderService;@GetMapping("/orders/{id}")publicOrderDO getOrder(@PathVariableLong id){  // 錯誤：直接返回DO物件return orderService.getOrderDO(id);  // 錯誤：應該轉換為DTO再返回    }}</example>

概要設計

人類開發者在開發程式碼之前，需要對需求文件進行理解轉化，並對應當前應用已有的實現現狀，明確需要新增和修改的部分，之後再進行具體程式碼開發。而Cursor在開發之前，並不一定能完全理解需求文件的意圖，轉化成預期的技術方案。這依賴於其一是需求的複雜程度，其二是當前應用的知識背景是否全面充足。
所以為了提高準確性，引入了概要設計的環節，由人類幫助Cursor完成上述步驟，並直接讓Cursor根據人類的概要技術方案，產出詳細的程式碼實現設計。這裡將概要設計的重點部分展示如下：

詳細設計

概要設計是人類編寫的，精確到了介面、資料結構、業務流程層面。但對於讓Cursor開發複雜型別需求還不夠具體，故需要Cursor生成詳細設計，精確到每一層的方法、出入參、虛擬碼層面，對抗Cursor的不確定性。本文摘錄當時部分詳細設計展示如下：
程式碼編寫
在詳細設計中，大部分程式碼實現已經基本定型。在程式碼編寫階段要引用詳細設計文件，不斷和Cursor對話互動，讓Cursor生成程式碼並人工Review，以此往復。

實現步驟拆解

雖然已經有詳細設計，但如何轉化為真正的程式碼卻不能心急。我曾嘗試一次性讓Cursor生成整個詳細設計中的內容，由於文件和程式碼量過大，Cursor無法處理這麼多上下文，造成生成的程式碼會錯亂（詳細設計中不同介面的邏輯跳躍性地生成在同一個介面程式碼中）。
所以我將整個程式碼編寫環節拆分為多個步驟，拆分標準先按業務邏輯，再按技術分層。目標就是將任務顆粒度拆解到Cursor單次能完成得很好的程度。這裡給出原則，具體程式碼不在文章中體現。
1.首先按照邏輯拆分步驟，比如先寫基本的資料庫讀寫實現，再加資料校驗，再加稽核，再加狀態機。這樣更有利於方法的複用，也有利於Cursor注意力集中在一個具體功能上。
2.對於複雜的業務，需要分層架構去生成程式碼。個人推薦自底向上，從DO開始，到domain層的model、converter、gateway定義，再到具體mapper的SQL實現。然後domainService，app層，client層。

提示詞結構化

提示詞的目的是讓Cursor更清晰地理解單次對話的目的，最有效的方式就是將其結構化。對於不同複雜度的需求、不同的已有背景知識完整程度，提示詞的精細程度都可以不同。在此我舉兩個例子說明：

詳細設計中已體現的程式碼生成

# 目標在建立元素和關係的時候，需要對元素做資料校驗，對關係做數量校驗。校驗可以劃分為一個單獨的領域，每個模組有不同的校驗規則。我們現在要實現校驗領域的設計和程式碼。# 業務規則參考 @詳細設計系分文件.md 中“6.1 資料校驗”部分# 核心任務按照詳細設計生成具體程式碼

詳細設計中未體現的程式碼生成

# 目標在建立元素、修改元素後，所有新增的元素資訊都要透過統一的稽核系統。其中包括兩個步驟：提交稽核和接收稽核迴流資訊。我們現在要將稽核系統接入現有裝修元素相關的流程中。# 業務規則## 1. 提交稽核規則1.1 在建立元素、修改元素時，採用執行緒池非同步提交稽核1.2 提交稽核的方式需要匹配稽核系統的互動規則1.3 提交稽核時，需要的欄位準備如下：```eventCode，每個模組一個，採用列舉形式儲存。到店指引是“STORE_GUIDE”requestParam.channel是常量，“store_decoration”，儲存在yml檔案中requestParam.uniqueBizId，採用elementId拼接當前時間戳requestParam.bizId，採用元素IDrequestParam.baseinfo.uid，採用operator欄位requestParam.bizData，是具體的送審資料，採用map的格式。對於到店指引，就是元素data中的資訊。```1.4 提交稽核後，需要將元素狀態更改為“待稽核”，並更新元素表## 2. 稽核迴流規則2.1 稽核迴流資訊透過metaQ接入，詳細互動定義見稽核互動規則。具體metaQ的接入方式，參考當前程式碼庫的com.amap.mall.content.infrastructure.repository.metaq.update.comid.correct.PushDseListener。注意Consumer類、配置檔案都要進行修改。同時新增一個HSF後門方法，直接呼叫Consumer的handle方法，可以提供給測試時期呼叫。2.2 稽核迴流之後，要將稽核結果同步到元素表。當稽核PASS時，元素表狀態改為稽核透過。當稽核REJECT時，元素表狀態改為稽核駁回。同時要將稽核結果資訊儲存到audit_info欄位中。2.3 整體處理就成可以參考《audit.java》# 現有知識背景1. 已經將稽核系統的互動規則整理為《稽核互動規則.md》放在.cursor/docs目錄下。提交稽核我們採用“2.1 HSF請求方式”進行。當前JDK版本為1.82. 現有程式碼已經實現了建立元素、修改元素等流程。3. 稽核迴流的處理框架流程可以參考別的工程的Consumer，《audit.java》放在.cursor/docs目錄下。但是要對其進行重構精簡。# 核心要求送審是所有模組通用的能力，請儘量可通用。對於不同模組區分的內容（主要是提審欄位準備），採用策略模式進行，不同模組的子類重寫父類方法。# 核心任務## 1. 仔細閱讀上述知識背景文件，仔細閱讀現有new-b-dolphin-*的程式碼實現。## 2. 根據上述規則和現有new-b-dolphin-*的程式碼實現，將你對這部分的詳細設計輸出到文件。注意，至少要精確到類和方法的定義，所有圖都使用mermaid格式。## 3. 文件輸出後，等待人類確認。確認該文件技術方案可行後，生成具體程式碼到對應檔案。
踩坑及應對方案
上述實現過程只是最終的實現，真實過程中經歷了非常多踩坑的情況。將其整理下來，並提出我自己的解決方案：
提效總結
過程指標
  • 行數統計（Cursor完成）
  • 新增程式碼總行數: 10894 (80.54%)
  • 新增文件總行數: 2632 (19.45%)
  • 採納率 & AI程式碼生成率
  • 對話輪次的Accept比例幾乎達到100%
  • 由於有部分人工修改，具體程式碼行數的AI生成比例在95%以上
結果指標
  • 排期對比
  • 未考慮Cursor參與的需求排期：16人天，其中方案設計階段4人天，開發12人天。
  • 實際Cursor參與的需求用時：8人天，其中設計階段4人天，開發4人天。
  • 除此之外，用於專案初次搭建Cursor使用環境及Rules，2人天。但專案初次搭建的成本只需要一次，且後續正規化形成後非常快捷，故不算入總消耗。
  • 提效率結論
  • 整體來看，本需求AI提效率為 8 / 16 = 50%
  • 其中，方案設計階段由於Cursor對方案的要求更為細緻，抵消了部分Cursor編寫方案文件的提效時間。但是生成方案後，由於本需求程式碼量巨大，且流程性重複程式碼較多，實際編碼階段的提效率非常高。
  • 後續展望
  • 本次是筆者首次對Cursor的全流程實踐。在下一篇中，經過多次實踐和團隊溝通，形成了統一的開發正規化，對最終的提效結果有非常大的幫助。
與 AI 智慧體進行即時音視訊通話
AI 即時音影片互動是一種旨在幫助企業快速構建 AI 與使用者之間的影片或語音通話應用的解決方案。使用者只需透過白屏化的介面操作，即可快速構建一個專屬的AI智慧體，並透過影片雲 ARTC 網路與終端使用者進行即時互動。
點選閱讀原文檢視詳情。

相關文章