阿里妹導讀
如果你是技術負責人、團隊推動者或希望在團隊中引入 AI 程式設計工具的工程師，這篇文章將為你提供一條可借鑑、可落地、可最佳化的路徑。
引言
上一篇《如何讓 AI 成為你的程式設計搭檔？一次真實重構告訴你答案》中提到，對於Cursor這樣一個擁有跨時代AI程式碼能力，但是又需要從工程角度不斷約束或拓展其易用性的工具，就更加考驗使用者的經驗和技巧。生產工具的升級必定引發生產流程的改進，以何種思路、方法、正規化，去最大化Cursor帶來的效率提升，並最小化其薄弱之處和引入的風險，是當前在團隊中最需要思考的問題。
上篇以個人開發者的角度，介紹了在複雜重構類需求中全流程使用Cursor的過程，也明確了Cursor對於開發的效率提升是巨大的。作為高德資訊業務中心大供給團隊的Cursor落地介面人，如何能讓Cursor參與的研發流程在團隊中真正紮根，達到提效預期？本篇簡要講述了我們供給側先鋒隊集體拆解問題和解決問題的路徑。
問題拆解和解法概要
大而全的角度講，團隊推廣中遇到的問題可以分為意願問題和能力問題，所以一方面要提高大家使用Cursor的意願，另一方面要提升大家駕馭Cursor的能力。意願的角度，資訊業務中心整體有較強的激勵方式，大家也有足夠的執行力。我們聚焦於能力提升方面，拆解了很多問題，以Top3舉例：
-
不同型別的需求，不同的開發者，對於Cursor的使用方式都不同。尤其是方案設計階段，容易陷入盲目Agent對話。如何沉澱出初學者開箱即用的使用流程。
-
在複雜的業務需求背景下，難以清晰地向Cursor闡述自己希望得到怎樣的技術設計和程式碼。由於語言表達問題引起後期的不確定性被放大。
-
Cursor的使用前置步驟過於複雜，對於每個工程都要進行特化Rules和docs生成，才能提升Cursor的準確性。如何為大家降低初期複雜度，避免望而生畏。
針對上述問題，我們提出了團隊內的解法。概要如下，後面逐個詳細說明。
研發流程規範
總體流程
雖然Cursor的Agent模式非常便捷，但是如果只通過自然語言的對話堆疊，無法有序地組織整個需求開發過程的推進。面臨不同型別需求的時候，對話輪次和生成程式碼結果的巨大不確定性，會將Cursor的效率提升對沖掉。實際上，在整個需求研發流程中，Cursor適合的使用場景和使用規範是有跡可循的，我們也亟需這樣的規範化研發流程。
經過筆者在不同需求內的嘗試，加上組內同學們幾周的探索，提煉總結出下圖研發流程。其中，左側是傳統需求級別的研發流程，是跨應用、跨崗位、跨團隊的。但是我們知道，Cursor當前對跨應用的支援並不完善，更別說跨團隊開發。所以右側是經過拆解的單個應用級別研發流程，是加入Cursor提效後的最佳實踐。說明，黃色代表需要人工完成的部分，綠色代表由Cursor完成的部分。下面對整個流程進行介紹。
需求階段
團隊內當前需求階段分為幾個步驟：需求建立、需求內審、需求預串、需求正串。
由於供給側團隊業務邏輯普遍比較複雜，技術全力保障業務發展。故在需求階段不建議因為具體的技術實現，包括Cursor參與的因素，影響產品業務團隊的需求設計。應用級研發流程中也不包含此階段。
方案設計階段
在資訊工程團隊的統一需求級研發流程中，方案設計階段要求產出系分文件。而在我們拆解的應用級研發流程中，要求人工產出概要設計文件，並由Cursor轉化為詳細設計文件。講清楚這三種文件的區別，也就講清楚了整個方案設計階段。
-
系分文件定義：在業務需求分析與技術方案設計時，需求的技術一號位同學需要從全鏈路視角產出整體設計方案，定義清楚上下游邊界及互動鏈路，並透過一個整體文件將各方設計串聯起來。
-
概要設計定義：在技術方案設計時、交由Cursor開發前，此文件由人類開發者撰寫，產出單個應用或單個子模組的概要設計。面向Cursor，描述清楚應用內的技術實現方案，包括目標功能、目標改動點、關鍵鏈路、關鍵技術實現細節等。
-
詳細設計定義：在概要設計產出後，Cursor實際生成程式碼前，此文件由Cursor根據概要設計生成詳細的技術實現方案。精確到具體的類、方法、資料結構等定義，由圖或虛擬碼的形式清晰地表明每一層的業務流程處理。經過人類開發者Review通過後，達到Cursor可以直接由詳細設計準確生成程式碼的程度。
從以上三個定義進一步解釋：
-
系分文件是面向人類開發者的，是整體需求層面的。所以可以用抽象的描述，且不詳細說明有共識的上下文的情況下，表達清楚整體技術鏈路即可。系分文件和概要設計、詳細設計是不衝突的，即使有Cursor參與，也需要技術一號位同學來統籌全域性。
-
概要設計文件是面向Cursor的，是單個應用層面的。不需要精細到虛擬碼的級別，但是要將關鍵的領域劃分、資料結構設計、介面設計、業務邏輯等清晰表述出來。對於Cursor來說，概要設計可以理解為“半白盒”的方案。
-
詳細設計文件是面向Cursor的，是單個應用層面的。所有Cursor生成程式碼所需的背景知識和方案細節，都需要在詳細設計中體現，只是沒有使用完整程式碼的形式。對於Cursor來說，詳細設計可以理解為“完全白盒”的方案。
至此我們明確了方案設計階段每個應用的研發流程，也知道了概要設計和詳細設計的作用。但不同的需求如何撰寫概要設計，放在下個問題討論。
開發階段
由組內同學的實踐經驗得出，在實際程式碼開發階段，並不能一股腦地讓Cursor根據詳細設計生成所有程式碼。由於文件和程式碼量過大，Cursor無法處理這麼多上下文，會造成生成的程式碼錯亂。表現形式如，詳細設計中不同介面的邏輯跳躍性地生成在同一個介面的方法程式碼中。
所以整個程式碼編寫環節應該拆分為多個步驟的迴圈。目標就是將任務顆粒度拆解到Cursor單次能完成得很好的程度。
拆分標準
如何拆分需要根據需求的複雜度具體分析。如果需求本身較為簡單，涉及的業務邏輯是比較淺顯的增刪改查，則顆粒度可以稍粗一些。對於複雜的需求，建議先按業務邏輯，再按技術分層進行拆分。
1.首先按照業務邏輯拆分步驟，比如先寫基本的資料庫讀寫實現，再加資料校驗，再加稽核，再加狀態機。這樣更有利於方法的複用，也有利於Cursor注意力集中在一個具體功能點上。
2.對於複雜的業務，需要分層架構去生成程式碼。推薦自底向上，從DO開始，到domain層的model、converter、gateway定義，再到具體mapper的SQL實現。然後domainService，app層，client層。當然，這只是常用的Java後端服務框架，其他技術棧同學可以生成自己的規範。
單次迴圈內步驟
每次生成程式碼的迴圈，需要遵循以下步驟：
prompt設計
本模組的程式碼生成目標，需要使用清晰的prompt向Cursor交代清楚。可以手動@詳細設計文件，並指出本模組在詳細設計文件中涉及的位置。具體如何清晰地表達出自己的目標，在下個問題討論。
程式碼生成
使用prompt和Cursor互動後，Cursor會根據本輪提示詞和詳細設計、現有Rules，對程式碼進行生成。在生成過程中，可以關注使用到的Rules是否符合預期、輪次過多後及時手動確認繼續執行等。
當然，這只是Agent模式下常用的使用方式，也可以使用manual模式手動修改一些檔案等。
單輪程式碼Review修改及git提交
Cursor生成程式碼後，要及時進行Review，並決定是否採納。因為Cursor目前還沒有區分對話輪次的採納功能，所以需要每次生成後就立即Review，並結合git等工具，明確掌握Cursor程式碼的改動點。這也就要求人類開發者對每個輪次生成的預期結果有清晰的認知。
本環節至關重要，因為單輪次程式碼量小的時候，更容易發現Cursor程式碼的問題。如果都堆到最後統一Review，一定會導致準確性大打折扣，從而導致線上事故。
建議使用Rules，要求Cursor每個輪次生成程式碼之後，先自行Review，發現可能的語法及邏輯問題。人工Review也要細緻跟進。
判斷是否達到整體預期
本環節既可以使用Cursor根據詳細設計判斷是否完成，也可以由人類開發者直接決定。依照效率準則進行。
Review階段
單元測試
單測環節可以完全交給Cursor生成。但是要注意，要讓Cursor首先根據人類Review過的詳細設計生成單測CASE，再根據CASE生成單測程式碼。而不是直接根據Cursor寫的業務程式碼生成單測程式碼，那就會出現“打哪指哪”的情況。
Code Review
1.先由Cursor進行一輪CR，可以包含兩個層面：
a.語法語義層面，可以使用提煉後的Java開發規範等作為Rules，讓Cursor對比master分支和當前分支的程式碼差異，進行CR。
b.業務邏輯方面，可以讓Cursor根據詳細設計，對比當前程式碼實現，進行CR。
2.人類開發者CR。不論Cursor如何智慧，最終人類開發者才是線上安全的“第一責任人”。所以CR階段一定要嚴格遵守規範，比如交叉CR等。
上線計劃
1.可以先由Cursor進行一輪上線計劃的整理。Cursor對比master分支和當前分支的程式碼差異，找出需要提起準備或配置的要點，羅列出來。以防人類開發者遺漏。
2.由於上線是多個應用和系統配合的過程，Cursor當前在此方面幫助不大。所以最終的上線計劃一定是人來確定的。
聯調階段
當前主要由人類參與實現，Cursor可以輔助定位問題。
測試階段
當前主要由人類參與實現，Cursor可以輔助定位問題。
結構化語言表達
當Cursor使用進入深水區，不僅停留在最初的概念理解和簡單互動階段後，一個普遍性大問題浮出水面：要想提高Cursor生成程式碼的準確性，就要提高人類對Cursor指令的準確性。主旨要明確、邏輯要清楚、指令不能有歧義、上下文還需要交代到位。那麼如何將人類腦子裡紛繁複雜的意圖，在本就天馬行空的業務需求背景下，變成Cursor及背後的模型能聽懂的自然語言？
遇到現實困難的時候，不妨回顧歷史。現在我們已經可以和模型使用自然語言進行溝通，那計算機發展的初期，如何和硬體進行有效溝通呢？組成原理知識告訴我們，透過最底層的0-1電訊號，上層不斷地規範化封裝，使用結構化的形式，直到我們現在使用的Java語言。可能在不久的將來，也會有成熟的自然語言規範去定義如何與模型互動。但現在為了快速在團隊內鋪開，需要做到最基本的點：結構化、模板化。
在上述研發流程中，主要涉及到語言表達的有兩個點：prompt和概要設計。
prompt
對於prompt，最重要的是結構化。結構化的prompt會比純自然語言更容易讓模型進行意圖理解。供給側團隊針對歷史邏輯梳理、輔助繪圖生成、根據概要設計生成詳細設計、程式碼編寫等各個環節，總結了多個結構化prompt的模板，不同研發階段、不同業務場景、不同技術複雜度下，prompt詳細程度可以不同，大家可以按需取用。
由於篇幅限制，這裡給出一個示例：
目標在建立元素、修改元素後，所有新增的元素資訊都要透過統一的稽核系統。其中包括兩個步驟：提交稽核和接收稽核迴流資訊。我們現在要將稽核系統接入現有裝修元素相關的流程中。# 業務規則# 1. 提交稽核規則...## 2. 稽核迴流規則...# 現有知識背景1. 已經將稽核系統的互動規則整理為《稽核互動規則.md》放在.cursor/docs目錄下。提交稽核我們採用“2.1 HSF請求方式”進行。2. 現有程式碼已經實現了建立元素、修改元素等流程。3. 稽核迴流的處理框架流程可以參考別的工程的Consumer，《audit.java》放在.cursor/docs目錄下。但是要對其進行重構精簡。# 核心要求送審是所有模組通用的能力，請儘量可通用。對於不同模組區分的內容（主要是提審欄位準備），採用策略模式進行，不同模組的子類重寫父類方法。# 核心任務# 1. 仔細閱讀上述知識背景文件，仔細閱讀現有new-b-dolphin-*的程式碼實現。# 2. 根據上述規則和現有new-b-dolphin-*的程式碼實現，將你對這部分的詳細設計輸出到文件。注意，至少要精確到類和方法的定義，所有圖都使用mermaid格式。# 3. 文件輸出後，等待人類確認。確認該文件技術方案可行後，生成具體程式碼到對應檔案。當然，結構化只是一個好的prompt最基本的要求，還有很多可以提高的地方。
概要設計
在上述Cursor研發流程中，方案階段決定了最終程式碼生成的準確性，方案階段最重要的就是概要設計的撰寫。概要設計如何清晰地表達，供給側同學在經驗總結後，給出了一套類似系分文件的模板：
上述模板的核心思路是，透過模板化的表達，嚴格約束對於目標的描述，從而幫助Cursor更加準確定位修改點和修改內容：
1.將傳統領域設計的統一語言新增一層“技術程式碼語言”，即實現 “業務語言 – 技術中文自然語言 – 技術程式碼語言” 的嚴格對映，增強目標準確性。
2.從業務流程設計的角度，縱向規定業務程式碼走向。給出關鍵資料結構設計、具體介面文件、詳細業務流程圖或時序圖等。
3.從技術實現設計的角度，橫向約束每個層次程式碼的輸入和輸出。結合縱向的業務流程，限定Cursor自主發揮的範圍，符合目標預期。
4.不論橫向或縱向，都需要說明現狀和目標修改點，便於Cursor定位。
應用級特化沉澱的通用解決方案
問題及解法
有了改進的研發流程、結構化的語言表達形式，Cursor對於業務的理解和支援準確度已經大幅提升。但是最終落在程式碼上，每一個應用都有獨特的技術棧、技術框架及分包目錄、程式碼風格、通用技術元件等。如果不給Cursor在應用級背景知識和上下文方面的輸入，最終的程式碼結果會天馬行空，如胡亂新建包路徑、對已有的Utils方法全部重寫、對現有的技術元件隨意選用（eg: Diamond or Switch）等，後果是災難性的。
所以每個應用，都要有一套自己特化的Rules和Docs，將所有可能影響到業務或技術的規範資訊儲存在內。但是人工構建這個體系的過程是冗長且痛苦的，不僅要手動梳理所有技術元件相關的內容，還要按照Rules的格式撰寫並且試驗。
解法的解法
為了解決這個問題，降低Cursor使用的初始難度，供給側團隊共同撰寫出一套針對Java應用通用的Rules或prompt，在該應用第一次使用Cursor時交由Cursor自主探索程式碼，並生成上述特化的Rules和Docs，並且每一個都經過且正在持續驗證迭代中。不同團隊一定有自己的技術棧、技術要點、關鍵鏈路等，可以打造自己團隊的通用方案。
主要思路：
1.對於大部分程式碼規範類，使用Rules讓Cursor按照一定的順序對程式碼進行分段探索，在Rules中明確預期目標、輸出形式、退出條件和正例反例。
2.對於技術棧、上線計劃等，可以窮舉當前需要整理的內容備選項，讓Cursor根據應用程式碼或對比master分支程式碼，進行逐個排查填充，從而形成符合當前應用的目標Rules。
通用Rules或prompt展示
由於篇幅限制，無法將上述prompt和Rules都在本文展示。故列出所有提綱和少數詳情如下：
提綱
1.各個粒度的文件生成與更新prompt、Rules
-
專案整體介紹文件（業務、技術）
-
單個介面業務邏輯整理
-
單點輔助畫圖
-
介面文件生成
-
文件即時更新規範
2.引用的外部技術棧Rules：自主探索本專案中所有技術棧及版本
-
基礎：JDK版本、springboot版本
-
資料庫：MySQL（TDDL）、Lindorm
-
ORM、分頁等：Mybatis、mybatis-plus、baomidou
-
快取：Redis、Tair、本地快取
-
通訊服務（區分上下游）：HSF、HTTP（通用呼叫配置）
-
配置中心：Diamond、Switch
-
日誌：Slf4j、日誌格式
-
工具庫：JSON用哪個（fastJSON、Gson）、lombok
-
其他不同專案可能用到的技術棧，如security、規則引擎…
3.應用中已有的自定義程式碼框架 及 獨特的程式碼風格規定和使用方式
-
統一異常處理：自定義業務異常類、errorCode、丟擲和捕獲方式等
-
統一日誌列印註解，日誌級別使用規範
-
統一分散式鎖使用方式
-
統一HSFConfig配置
-
統一快取讀寫使用方式
-
統一監控規範
-
現有自定義util類的功能總結，方便Cursor後續複用
4.自主探索程式碼分包目錄結構規範：程式碼結構應該怎麼寫，程式碼檔案放到什麼目錄
-
現有流行程式碼框架的羅列及匹配：cola？GBF？
-
交由Cursor前，所有包名都手動新建完成
-
探索當前工程的所有包路徑，及程式碼放置規則
5.CR、單測、上線計劃整理規範
-
CR：程式碼語法規則與風格習慣、是否符合詳細設計
-
單測：單測用例與程式碼生成
-
上線計劃整理：窮舉可能的上線準備，Cursor自動在變更程式碼中選取
詳情舉例
1.程式碼分包目錄結構規範，作者 @珵玉
程式碼分包目錄結構規範
---description: globs: alwaysApply: false---# 程式碼探索規則## 前置資訊收集(1) 首先查閱探索結果檔案 `.cursor/rules/project-structure.mdc`,優先閱讀檔案內容獲取當前專案的整體路徑結構,後續的分析基於該檔案內容進行改寫最佳化 (2) 其次查詢git提交忽略檔案`.gitignore`,檔案內部標註非程式碼路徑,在後續探索中忽略這些路徑的以及檔案的探索 (3) 結合前置收集到的資訊,確定探索檔案的範圍,**注意:不要遺漏路徑，也不要省略路徑的探索** ## 確定探索順序> 探索時需要參考前置資訊收集的結果,對於忽略的路徑、檔案則無需探索. > `<example></example>` 為示例，根據實際情況進行分析### 1. **探索前先要分析專案中的模組依賴關係**： - 對於Java專案，可以先閱讀專案的主POM配置`pom.xml`,然後逐個去探索子POM配置 #### (1) 先探索主POM檔案內容，確認總共有哪些模組：<example>```xml<modules> <module>A</module> <module>B</module> <module>C</module> <module>D</module></modules>```</example> #### (2) 再逐個閱讀分析模組的子POM檔案,確認模組之間真實的依賴關係 <example> ```xml<dependencies> <dependency> <groupId>xxxxx</groupId> <artifactId>A</artifactId> </dependency></dependencies>```</example> #### (3) 整理出模組之間真實的依賴關係，一般是有向無環圖（DAG），依賴模組的版本號不一致可以忽略. **當整理完後需要再閱讀各子pom，確認依賴的正確和無遺漏** <example> ```mermaidgraph TD A --> B B --> C A --> D```</example>### 2. **按模組依賴順序,自底向上探索;探索過程中按照廣度優先遍歷檔案路徑**：<example> ```ModuleA/└── src/ ├── api/ │ ├── service_A/ │ └── service_B/ ├── enum/ └── dto/ ````src/`路徑下，先遍歷`api/`、`enum/`、`dto/`，再遍歷`src/api/service_A/`、`src/api/service_B/`</example>## 確定路徑用途**1.透過閱讀路徑下的若干檔案來確認該目錄是檔案存放規則，路徑功能包括但不限於** - 存放常量、列舉：路徑下存放的程式碼主要是常量/列舉資訊，檔案命名一般以`Constant.java`、`Enum.java`等結尾 - 存放服務介面：路徑下存放定義的介面，檔案一般都是`Interface` - 存放服務實現：路徑下存放介面的邏輯實現,檔案命名一般以`InterfaceImpl.java`、`ServiceImpl.java`等結尾 - 存放工具類：路徑下存放專案中使用的工具,檔案命名一般以`Utils.java`、`Util.java`等結尾 - 存放配置、開關：路徑下存放專案中使用的配置開關，路徑一般為`switches/`、`config/`、`diamond/`等 - 存放核心領域模型：一般在領域module下，module命名一般包含`core`、`domain`等關鍵字;路徑下存放核心業務模型，路徑一般為`domain/`、`model/`、`core/`等 - 存放核心領域服務：一般在領域module下，module命名一般包含`core`、`domain`等關鍵字;路徑下存放核心業務服務 - 存放資料庫倉儲服務：路徑一般包含`mysql`、`repository`、`db`等關鍵字;路徑下的程式碼檔案一般都是連線資料服務或資料庫的互動邏輯**2.設計模式相關結構識別指引**- 在探索目錄和檔案時，需特別關注以下常見設計模式相關命名，若路徑或檔名中包含這些關鍵詞，應優先判斷其是否為該模式的實現，並在結構輸出和規範中予以標註： - handler/Handler：處理鏈、事件分發、命令等（如handler、eventhandler、xxxHandler.java） - strategy/Strategy：策略模式實現（如strategy、xxxStrategy.java） - wrapper/Wrapper：裝飾器/包裝器模式（如wrapper、xxxWrapper.java） - factory/Factory：工廠模式（如factory、xxxFactory.java） - adapter/Adapter：介面卡模式（如adapter、xxxAdapter.java） - proxy/Proxy：代理模式（如proxy、xxxProxy.java） - builder/Builder：建造者模式（如builder、xxxBuilder.java） - observer/Observer：觀察者模式（如observer、xxxObserver.java） - command/Command：命令模式（如command、xxxCommand.java） - visitor/Visitor：訪問者模式（如visitor、xxxVisitor.java） - state/State：狀態模式（如state、xxxState.java） - template/Template：模板方法模式（如template、xxxTemplate.java）**3.結合模組下的檔案資訊，確認該模組的定義，包括但不限於**- 專案啟動模組：一般模組命名包含關鍵字`start`、`starter`等- 對外介面模組：一般模組命名包含關鍵字`client`、`gateway`等，系統對外提供的RPC/HTTP/閘道器服務- 外部介面對接模組：一般模組命名包含關鍵字`integration`等，包含對接二三方服務- 基礎設施模組：包含資料倉儲、專案基礎框架、工具類等- 領域模組：一般模組命名包含關鍵字`core`、`domain`等，包含系統穩定的核心領域模型和服務- 業務模組：一般模組命名包含關鍵字`bussiness`、`application`、`biz`、`app`等，包含業務邏輯，對外介面的實現邏輯**4.常見系統框架結構識別指引**- 在探索目錄和檔案時，需特別關注以下主流企業級架構的典型分層和命名： - **阿里COLA框架**： - 典型分層：client（介面層）、app（應用層）、domain（領域層）、infrastructure（基礎設施層）、integration（外部整合層）、web（表現層） - 目錄命名示例：client/dto/、app/service/、domain/model/、infrastructure/repository/、integration/、web/controller/ - 用途說明：各層職責分明，DTO、Command、Query、DO、Repository、Service等應放在對應分層包下 - **高德GBF框架**： - 典型分層：platform（Process流程層）、node（NodeService節點層）、domain（DomainService領域層）、ability（擴充套件點介面層）、app（行業/場景定製層） - 目錄命名示例：platform/、node/、domain/、ability/、app/food/、app/retail/ - 用途說明：Process、NodeService、DomainService、Ability、Action等應放在對應分層包下- **如發現專案採用上述主流框架，應優先按其分層和命名規範輸出結構和放置建議。**## 探索結果輸出1、內容輸出到檔案中 `.cursor/rules/project-structure.mdc`，如果該檔案存在則進行內容更新 2、只需要輸出目錄路徑，不要輸出具體程式碼檔案；路徑下沒有檔案可以進行合併，有檔案的路徑不能擅自合併. <case> ```A/└── src/ └── main/ └── java/ └── B/ ├── aaa.java ├── domainservice/ │ └── bbb.xml └── domainmodel/``` 1、`A/src/main/java/B/` 可以合併輸出2、但是 `domainservice/` `domainmodel/` 不能合併 3、`aaa.java` 、`bbb.xml` 是具體檔案，不需要輸出所以最終正確輸出如下 ```A/src/main/java/B/ ├── domainservice/ └── domainmodel/```</case> 3、在洞察過程中發現的規範，輸出到程式碼檔案放置規範中.**重要規則:不要自己亂寫程式碼檔案放置規範，所有規範都需要有依據** **4.設計模式相關結構輸出要求**- 輸出結構時，若發現有上述設計模式相關的包或類，應在輸出中加註釋說明其用途（如"# 策略模式實現"）。- 在規範部分，補充"常見設計模式類的放置建議"，並舉例說明。### 輸出格式如下> `<example></example>` 為示例，根據實際分析結果進行填寫;填寫時不需要用`<example></example>` 包裝 ``````mdc ---description: `此規則包含了本專案的程式碼路徑結構和規範，所有程式碼編寫時必須按照該模組化結構進行放置`globs: *.java,*.xmlalwaysApply: true---# 專案模組及依賴關係 <example> ```mermaidgraph TD A --> B B --> C A --> D```</example># 專案目錄及使用規範```<example> systemA/├── systemA-start/ # 專案的啟動模組├── systemA-client/ # 系統對外暴露的RPC介面門面模組│ └── src/main/java/systemA/client│ ├── api/ # 對外介面│ └── dto/ # 對外模型,請求,響應等├── systemA-domain/ # 領域基礎模組,作為專案的最基礎的模組;所有二三方服務依賴在此引入│ └── src/main/java/systemA/domain│ ├── domainservice/ # 基礎服務框架│ ├── constant/ # 常量│ ├── enum/ # 列舉│ ├── exception/ # 異常│ ├── gateway/ # 二三方服務的接入的防腐層;所有外部服務需要在此建立防腐層interface│ ├── switch/ # 領域基礎層的開關配置│ ├── util/ # 系統基礎工具│ ├── model/ # 領域模型│ ├── strategy/ # 策略模式實現 # 設計模式示例│ ├── handler/ # 處理鏈/事件分發/命令模式實現 # 設計模式示例│ ├── wrapper/ # 裝飾器/包裝器模式實現 # 設計模式示例│ └── observer/ # 觀察者模式實現 # 設計模式示例└── systemA-application/ # 最上層業務應用層; └── src/main/java/systemA/application ├── client/ # 對應服務RPC服務實現 ├── controller/ # 對外暴露的http服務 ├── gateway/ # 註冊在閘道器上的閘道器服務介面 │ ├── request/ # 閘道器介面請求定義 │ ├── response/ # 閘道器介面響應定義 │ └── impl/ # 閘道器介面的實現 ├── converter/ # 模型轉換器,主要將領域或者db模型轉換成對外DTO、VO模型 ├── service/ # 業務服務介面 │ ├── factory/ # 工廠模式實現 # 設計模式示例 │ ├── adapter/ # 介面卡模式實現 # 設計模式示例 │ └── proxy/ # 代理模式實現 # 設計模式示例 └── service/impl/ # 業務服務實現```</example> # 程式碼檔案放置規範<example>1、資料物件(DO)規範：資料物件(DO)必須放在XXX模組下的dataobject包中2、傳輸資料物件(DTO)規範：傳輸資料物件(DTO)必須放在XXX模組下的xxx包中3、檢視資料物件(VO)規範：檢視資料物件(VO)必須放在XXX模組下的xxx包中4、工具類(Util)規範：工具類必須放在XXX模組下的xxxx包中5、單測類(Test)規範：單測型別必須放在Test模組下的xxx包中6、策略模式(Strategy)規範：策略相關類應統一放在strategy包下，命名以Strategy結尾，如XxxStrategy.java7、處理鏈/命令模式(Handler/Command)規範：相關類應統一放在handler或command包下，命名以Handler或Command結尾8、裝飾器/包裝器模式(Wrapper)規範：相關類應統一放在wrapper包下，命名以Wrapper結尾9、工廠模式(Factory)規範：相關類應統一放在factory包下，命名以Factory結尾10、介面卡模式(Adapter)規範：相關類應統一放在adapter包下，命名以Adapter結尾11、代理模式(Proxy)規範：相關類應統一放在proxy包下，命名以Proxy結尾12、建造者模式(Builder)規範：相關類應統一放在builder包下，命名以Builder結尾13、觀察者模式(Observer)規範：相關類應統一放在observer包下，命名以Observer結尾14、訪問者模式(Visitor)規範：相關類應統一放在visitor包下，命名以Visitor結尾15、狀態模式(State)規範：相關類應統一放在state包下，命名以State結尾16、模板方法模式(Template)規範：相關類應統一放在template包下，命名以Template結尾....</example>2.單應用釋出計劃整理，作者 @有漸
release-plan-template-agent.mdc
---description: 此規則用於生成標準化的需求上線計劃文件。當需要建立新的上線計劃、準備釋出新功能或更新現有系統時應用此規則。規則確保上線計劃包含完整的釋出定義、釋出計劃、灰度策略、配置管理、監控方案及回滾預案等關鍵資訊，有助於團隊高效協作並降低上線風險。適用於各類需求的釋出與上線準備工作。globs: alwaysApply: false---# 需求上線計劃模板規則## 關鍵規則- 所有需求上線計劃必須包含完整的釋出定義、釋出計劃、預釋出、灰度釋出和正式釋出五個主要部分- 釋出定義必須明確需求責任人、釋出執行人、需求分級和風險等級- 需求分級必須明確區分：A級（測試測）、B級、C級、D級（自測）- 釋出計劃必須詳細說明上下游釋出節奏，包括模組依賴關係和釋出順序- 釋出計劃必須以工程為單位進行規劃（如amap-mp-shop整體工程），而非以子模組為單位（如shop-app、shop-infrastructure等）- 灰度釋出部分必須說明灰度策略、灰度驗證點和對線上功能的影響評估- 正式釋出部分必須包含配置項清單、影響面分析、監控方案和回滾預案（三板斧）- 所有依賴的配置項（如Diamond配置、訊息佇列、閘道器等）必須詳細列出並指定負責人- 回滾預案必須針對不同階段可能出現的問題制定詳細的操作步驟- 模板中必須包含版本管理資訊，記錄文件的變更歷史## 上線計劃文件結構上線計劃文件必須按照以下結構組織：```# 需求名稱上線計劃當前版本號：vX.X# 一、釋出定義（需求負責人、釋出執行人、需求分級、風險等級）# 二、釋出計劃（上下游釋出節奏、內部工程釋出順序）# 三、預釋出（預髮狀態、驗證結果）# 四、灰度釋出（灰度策略、灰度驗證點）# 五、正式釋出（釋出節奏、配置項、影響面分析、監控方案、回滾預案）# 六、上線流程（具體上線步驟）# 七、評審回看（上線評審記錄）# 版本管理（文件版本歷史）```## 各章節詳細規範### 一、釋出定義-**需求一號位**：主要負責人，對整個需求負責-**釋出執行人**：負責執行釋出的人員列表-**需求分級**：標明需求的重要程度 - **A級**：完全測試測，需要最高級別的測試覆蓋 - **B級**：部分測試測，部分自測 - **C級**：大部分自測，小部分測試測 - **D級**：自測，由開發人員自行測試-**風險等級**：標明發布風險（高/中/低）### 二、釋出計劃-**上下游釋出節奏**：必須使用表格形式列出所有相關係統/工程的釋出時間、跟進人和釋出內容-**模組間依賴**：使用圖表明確標示各工程間的依賴關係，區分強依賴和弱依賴-**工程釋出順序**：必須以整體工程為單位（如amap-mp-shop、amap-mp-shop-service），而非以子模組為單位（shop-app、shop-infrastructure等）### 三、預釋出- 明確標明預髮狀態（已預發/未預發）- 如已預發，需說明預發驗證結果### 四、灰度釋出- 明確灰度釋出時間- 使用表格形式列出各工程的灰度情況，包括： - 是否有灰度環境 - 當前進度 - 釋出後對線上功能的影響 - 灰度上線後核心驗證點### 五、正式釋出-**釋出節奏**：明確正式釋出的批次和時間安排-**配置項**：詳細列出所有需要配置的專案，包括： - 合併origin/master - Diamond配置 - Switch配置 - 資料庫建表及配置 - 訊息佇列（生產者/消費者） - 閘道器ACTION配置：如果有新增hsf介面，則將其列到釋出計劃中，由開發人員決策是否需要釋出閘道器ACTION - autoconfig：如果程式碼有改動antx.properties檔案 - SchedulerX - 二方包：如果pom.xml檔案有改動，則需要列舉改動點，讓使用者確認是否需要更新二方包版本或釋出二方包 - Sentinel：如果調整了sentinel相關邏輯，則需要列舉sentinel配置項 - Jingwei - Tair/Redis - 其他中介軟體配置-**影響面梳理與驗證方案**：分析釋出影響面，制定驗證方案-**三板斧**： - **可灰度**：明確說明是否需要灰度及灰度策略 - **可監控**：列出關鍵監控指標 - **可回滾**：詳細說明判定需要回滾的依據及回滾操作步驟### 六、上線流程- 列出上線的具體流程或引用相關流程文件### 七、評審回看- 存放上線評審記錄或會議影片連結### 版本管理- 使用表格記錄文件的版本歷史，包括版本號、修訂型別、修訂時間、修訂人、修訂內容和生效時間## 配置項詳細規範### Diamond配置使用表格列出所有Diamond配置，包括：- groupId- dataId- 配置項確認人- 配置值注意：如果dataId相同，則合併表格單元格### 訊息佇列配置分別列出生產者和消費者配置：- Topic- Group（消費者）- Tag- 功能說明### 閘道器配置列出所有需要配置的閘道器action，包括：- action名稱- 配置地址- 功能說明### autoconfig如果程式碼有改動antx.properties檔案,則需要配置autoconfig，包括- 配置key- 配置value## 回滾預案規範回滾預案必須包含：- 判定需要回滾的明確依據- 針對不同階段（如程式碼上線階段、業務灰度階段）的回滾操作步驟- 回滾後的驗證方法和後續操作## 示例<example># 使用者身份認證系統升級上線計劃當前版本號：v2.0# 一、釋出定義### 需求一號位張三### 釋出執行人張三、李四、王五### 需求分級A級（測試測）### 風險等級中# 二、釋出計劃### 1、上下游釋出節奏模組間依賴: 實線箭頭: 強依賴，必須按照順序釋出虛線箭頭: 邏輯上有依賴關係，但可並行釋出| | **釋出時間** | **跟進人** | **釋出內容** || --- | --- | --- | --- || 認證服務工程 | 10.15（已完成） | 張三 | 1、支援新的認證方式 2、最佳化認證流程 || 使用者中心工程 | 10.16 | 李四 | 1、適配新的認證介面 2、增加使用者安全等級 || 前端系統工程 | 10.17 | 王五 | 1、更新認證頁面 2、增加安全等級展示 |# 三、預釋出* [x] 已預發，驗證透過所有測試用例# 四、灰度釋出* [x] 10.18釋出灰度| | **是否有灰度環境** | **當前進度** | **釋出後對線上功能的影響** | **灰度上線後核心驗證點** || --- | --- | --- | --- | --- || 認證服務工程 | 有 | 已灰度 | 開關控制，對線上無影響 | 1、新舊認證方式切換正常 2、效能指標達標 || 使用者中心工程 | 有 | 已灰度 | 開關控制，對線上無影響 | 1、使用者安全等級計算正確 2、與認證服務互動正常 || 前端系統工程 | 有 | 未灰度 | 新介面預設關閉，對線上無影響 | 1、新舊介面切換正常 2、功能操作流暢 |# 五、正式釋出## 釋出節奏分兩批發布：1. 第一批：10.20 認證服務工程 + 使用者中心工程2. 第二批：10.21 前端系統工程## 配置項| | **是否已完成** | **負責人** | **deadLine** | **認證服務工程** | **使用者中心工程** | **前端系統工程** || --- | --- | --- | --- | --- | --- | --- || 合併master | * [ ] | 張三 | 10.19 | 是 | 是 | 否 || diamond配置 | * [ ] | 李四 | 10.19 | 是 | 是 | 是 || 資料庫指令碼 | * [ ] | 王五 | 10.19 | 是 | 是 | 否 |### Diamond配置| **groupId** | **dataId** | **配置項確認人** | **配置值** || --- | --- | --- | --- || auth-service | auth.switch.config | 張三 | { "newAuthEnabled": false, "authTimeoutMs": 3000 } || user-center | security.level.config | 李四 | { "securityCheckEnabled": false, "defaultLevel": 1 } |### 三板斧-可灰度認證功能透過配置中心開關控制，可實現新舊功能的平滑切換：* 配置開關關閉時，使用舊的認證流程* 配置開關開啟時，使用新的認證流程* 可按使用者分組灰度，先覆蓋內部使用者，再擴大到外部使用者### 三板斧-可監控監控項：* 認證請求量* 認證成功率* 認證響應時間* 異常登入告警* 使用者安全等級變更統計### 三板斧-可回滾**判定需要回滾的依據:**1. 認證成功率下降超過3%2. 認證響應時間超過500ms3. 出現批次使用者無法登入問題| **階段** | **回滾操作和後續操作步驟** || --- | --- || 程式碼上線階段 | 1、同步問題 2、單獨回滾故障服務 3、確認回滾後影響消除 || 業務灰度階段 | 1、將配置開關關閉，切回舊認證方式 2、排查問題 3、修復後重新灰度 |# 六、上線流程參考標準上線流程：[連結]# 七、評審回看[會議錄製連結]# 版本管理| **版本號** | **修訂型別** | **修訂時間** | **修訂人** | **修訂內容** | **生效時間** || --- | --- | --- | --- | --- | --- || V1.0 | 新增 | 2023-10-10 | 張三 | 首次釋出 | 2023-10-10 || V2.0 | 更新 | 2023-10-15 | 李四 | 增加前端系統釋出計劃 | 2023-10-15 |</example><exampletype="invalid"># 系統升級上線計劃# 一、釋出定義需求分級：中級 // 錯誤：未使用標準分級（A/B/C/D）負責人：張三時間：下週釋出# 二、釋出計劃依賴關係：service模組 -> dao模組 -> controller模組 // 錯誤：以子模組而非工程為單位進行規劃釋出順序：1. 釋出dao子模組 // 錯誤：應以整體工程為單位，而非子模組2. 釋出service子模組3. 釋出controller子模組# 三、灰度說明先上線後端，再上線前端 // 錯誤：未提供足夠的灰度策略和驗證點詳情# 回滾 // 錯誤：未按標準結構組織文件如有問題就回滾 // 錯誤：沒有具體的回滾依據和步驟# 其他說明文件撰寫於2023年10月 // 錯誤：未使用標準的版本管理格式</example>結語
如果說只要求大家使用Cursor是爬高樓，那通用的研發流程規範就像搭建好每一層之間的樓梯，而應用級特化沉澱的通用解決方案就像為初學者修築了直通的電梯。這也就是供給側先鋒隊的價值所在。
Cursor在團隊中的落地還在持續進行中，期待不斷解決問題，讓每個同學和整個資訊業務團隊都在Cursor為代表的AI浪潮中獲益。
後續還將抽時間進行相關的原理探究，有意思的點會及時分享出來，希望大家加強交流互動。
MCP 賦能視覺化 OLAP 智慧體應用
針對傳統資料分析中存在的 SQL 使用門檻高、分析視覺化流程複雜，本方案基於雲資料庫 PolarDB MySQL 版與阿里雲百鍊，結合 MCP 工具的 SQL 執行與繪圖能力，利用模型智慧解析與高效推理，實現從資料接入到分析視覺化的全流程一站式部署。
點選閱讀原文檢視詳情。
