深入解析｜Cursor程式設計實踐經驗分享

2025-06-27 13:13 阿里雲開發者

寫在前面
本文是近兩個月的實踐總結，結合在實際工作中的實踐聊一聊Cursor的表現。記錄在該過程中遇到的問題以及一些解法。問題概覽(for 服務端)：
  • 不如我寫的快？寫的不符合預期？
  • Cursor能完成哪些需求？這個需求可以用Cursor，那個需求不能用Cursor?
  • 歷史程式碼分析淺顯，不夠深入理解？
  • 技術方案設計做的不夠好，細節缺失，生成程式碼的可用性不夠滿意？
Cursor專案開發流程

透過近兩個月的實踐，在程式設計中，cursor的表現取決與有效的Rules+正確的開發流程+標準的Prompt。
在日常需求中按照該流程開發，目前對於程式設計的提效是接近預期的。在日常使用中主要以提效為主，不糾結一定要cursor寫。
下一步我們的方向是基於研發的流程分析，我們還有哪些流程可以使用 AI幫助我們提效？本篇文章主要是介紹我們實踐的一些心得體會，以及對未來的一些展望。
Cursor如何用好
1.標準的Prompt
2.好用的Rules
3.合理的開發流程
4.有幫助的mcp
標準的PE如何寫
其實在聊這個問題，大家可能會說有時候好用有時候不好用。大家對好用的第一感知就是一句話溝通後Cursor能完成至少40-60%，不好用則是超過三次後完成的不如預期。
Cursor用好的第一步是首先學會和cursor對話，是否真的會聊？我們工程研發是否會寫PE（Prompt Engineering），對於研發工程同學，其實Prompt對於我們是有些門檻，但是在端到端的過程中，Prompt是我們的入門的必備技能。準確有效的提示詞能能讓Cursor效率事半功倍。
接下來按照每個步驟分析應該給到Cursor的資訊，可以不嚴格按照此格式，精髓是把我們的目標+上下文+要求給到Cursor。
分享一套我們團隊同學總結的Prompt經驗：

提示詞基本結構與原則

  • 目標：明確Cursor到底是寫技術方案、生成程式碼還是理解專案；
  • 上下文資訊：必要的背景資訊。
  • 要求：
  • Cursor要做的事：拆解任務，讓Cursor執行的步驟；
  • Cursor的限制；
專案理解
# 目標請你深入分析當前程式碼庫，生成專案梳理文件。# 要求1. 你生成的專案梳理文件必須嚴格按照專案規則中的《專案文件整理規範》來生成。（在rules使用不規範的情況下可以明確指出）# 輸出請你輸出專案梳理文件，並放到專案的合適位置。（梳理的文件要落到規定的位置,eg:.cursor/docs中）

方案設計

# 目標請你根據需求文件，生成技術方案。注意你只需要輸出詳細的技術方案文件，現階段不需改動程式碼。（此時需求文件已經以文件的形式放到了我們的專案中）# 背景知識為了幫助你更好的生成技術方案，我已為你提供：（1）專案程式碼（2）需求文件：《XX.md》（上下文@檔案的方式給到也可以）（3）專案理解文件:《XX.md》（上下文@檔案給到也是同樣的效果）# 核心任務## 1. 文件分析與理解階段  在完成方案設計前完成以下分析：  - 詳細理解需求：    - 請確認你深刻理解了《需求.md》中提到的所有需求描述、功能改動。    - 若有不理解點或發現矛盾請立即標記並提交備註。  - 程式碼架構理解：    - 深入理解專案梳理文件和現有程式碼庫的分層結構，確定新功能的插入位置。    - 列出可複用的工具類、異常處理機制和公共介面（如`utils.py`、`ErrorCode`列舉類）。 ## 2. 方案設計階段請你根據需求進行詳細的方案設計，並將生成的技術方案放置到專案docs目錄下。該階段無需生成程式碼。# 要求1. 你生成的技術方案必須嚴格按照專案規則中的《技術方案設計文件規範》來生成，並符合技術方案設計文件模板。# 輸出請你輸出技術方案，並將生成的技術方案放到專案的合適位置，無需生成程式碼。

根據技術方案生成程式碼

# 目標請你按照設計好的方案，生成程式碼。# 背景知識為了幫助你更好的生成程式碼，我已為你提供：（1）專案程式碼（2）需求文件：《XX.md》（3）技術方案：《XX.md》（4）專案理解文件:《XX.md》# 核心任務## 1. 文件分析與理解階段  在動手編寫程式碼前完成以下分析：  - 需求匹配度檢查：    - 深入理解需求文件和方案設計文件，確認《方案設計.md》與《需求.md》在功能點、輸入輸出、異常場景上的完全一致性。    - 若發現矛盾請立即標記並提交備註。  - 程式碼架構理解：    - 深入理解專案梳理文件和現有程式碼庫的分層結構，確定新功能的插入位置。    - 列出可複用的工具類、異常處理機制和公共介面（如`utils.py`、`ErrorCode`列舉類）。  ## 2. 程式碼生成階段如果你已明確需求和技術方案，請你完成程式碼編寫工作。# 要求1. 你必須遵循以下核心原則：（1）你生成的程式碼必須參考當前專案的程式碼風格。（2）如專案已有可用方法，必須考慮複用、或在現有方法上擴充套件、或進行方法過載，保證最小粒度改動，減少重複程式碼。2. 你生成的程式碼必須符合《Java統一開發程式設計規範》中定義的規範。# 輸出請你生成程式碼，並放到程式碼庫的合適位置。

生成單測

# 任務請你為《xx.go》檔案生成單測。# 要求1. 你生成的單元測試程式碼必須參考當前專案已有的單測方法風格。# 示例（從你當前專案中複製一個寫好的單測作為提示給大模型的示例）
好用的CursorRules
經過兩個月的實踐，目前Rules趨於穩定，從需求到自測基本可以滿足我們的日常開發。
自己生成Rules
在v0.49版本支援自動生成rules，直接輸入/，即可看到生成規則模式；自動生成規則可以有效的把自己的習慣或者專案的開發規範透過Rules的形式落地而不是每次反覆在Prompt中提醒約束；

比如：生成golang專案開發規範

golang開發規範，僅適用於當前專案
---description: 此規則適用於go專案的開發規範，技術方案設計文件的編寫保證核心程式碼符合規範，寫程式碼遵守該規範，確保開發質量和效率。globs:alwaysApply: false---# Go專案開發規範## 專案結構規範- 採用領域驅動設計(DDD)分層架構，明確劃分為以下層次：- `controller` 層：處理 HTTP 請求，引數驗證，路由轉發- `logic` 層：實現核心業務邏輯，協調各個元件和服務呼叫- `model` 層：資料訪問和持久化，定義資料結構- `framework` 層：基礎設施和通用工具- `hsf` 層：服務呼叫介面定義和實現-**依賴方向**- 嚴格遵循依賴方向：controller → logic → model- 禁止迴圈依賴- 上層模組不能依賴於下層模組實現細節，應透過介面進行依賴## 編碼規範### 命名約定-**包名命名**- 使用小寫單詞，不使用下劃線或混合大小寫- 使用簡短、具有描述性的名稱- 例如：`model`、`controller`、`logic`-**檔案命名**- 使用小寫字母，使用下劃線分隔單詞- 例如：`user_service.go`、`order_model.go`-**變數命名**- 使用駝峰命名法- 區域性變數使用小駝峰（`userID`）- 全域性變數使用大駝峰（`UserService`）- 常量使用全大寫，下劃線分隔（`MAX_RETRY_COUNT`）-**介面和結構體命名**- 使用大駝峰命名法- 介面名應以 "er" 結尾表示行為，如 `Reader`、`Writer`- 避免使用 "I" 字首表示介面### 程式碼組織-**結構體欄位順序**- 首先是匯出欄位，然後是非匯出欄位- 相關欄位應分組在一起-**函式宣告順序**- 先宣告型別和常量，然後是變數- 接著是初始化函式（`init()`）- 最後是其他方法，按重要性或呼叫關係排序-**import 宣告**- 將 import 分組為標準庫、第三方庫和內部包- 組之間用空行分隔- 使用 goimports 自動排序```goimport("context""fmt""time""github.com/gin-gonic/gin""github.com/pkg/errors""amap-aos-activity/framework/mlogger""amap-aos-activity/model/base")```## 錯誤處理規範-**使用專案標準錯誤型別**- 使用 `common.Error` 統一封裝業務錯誤- 保持錯誤碼和錯誤資訊的一致性-**錯誤傳播**- 在邏輯層中，使用 `errors.Wrap` 包裝錯誤以保留堆疊資訊- 謹慎處理空指標和邊界情況-**錯誤日誌記錄**- 只在錯誤發生的源頭記錄日誌，避免重複記錄- 使用專案統一的日誌框架 `mlogger`- 在記錄錯誤時包含足夠的上下文資訊```goif err !=nil {    tracelogger.XErrorf(ctx, "failed to query data: %v", err)returnnil, common.NewError(common.ErrCodeDB, "資料查詢失敗")}```## 併發處理規範-**使用 context 進行超時控制**- 所有長時間執行的操作都應接受 context 引數- 及時檢查和響應 context 取消訊號-**併發安全**- 使用 mutex、atomic 或 channel 來保護共享資源- 避免 goroutine 洩漏，確保所有 goroutine 都能正確退出- 使用專案提供的 `errgroup` 包管理併發任務-**資源控制**- 使用 worker pool 或訊號量控制併發數量- 使用專案提供的框架元件進行非同步任務處理## 效能最佳化規範-**避免不必要的記憶體分配**- 預分配已知大小的切片和 map- 使用 pointer 傳遞大結構體- 使用 sync.Pool 複用臨時物件-**高效的 IO 操作**- 使用緩衝 IO- 批次處理資料庫操作- 實現合理的快取策略，使用 mcache 或 mredis-**高效的 JSON 處理**- 使用專案指定的高效能 JSON 庫（sonic）- 對頻繁使用的結構體預定義欄位標籤## 測試規範-**單元測試覆蓋**- 為所有關鍵業務邏輯編寫單元測試- 使用表驅動測試方法- 測試檔案與被測試檔案放在同一目錄，使用 `_test.go` 字尾-**模擬外部依賴**- 使用介面和依賴注入以便於測試- 使用 mock 框架模擬外部服務和資料庫-**基準測試**- 為效能關鍵路徑編寫基準測試- 使用效能分析工具發現瓶頸## 專案標準組件使用指南-**日誌記錄**- 使用 `mlogger` 包進行日誌記錄- 在關鍵流程節點記錄日誌，但避免過度記錄-**配置管理**- 使用 `mconfig` 包讀取配置- 避免硬編碼配置值-**HTTP 客戶端**- 使用 `mhttp` 包進行 HTTP 呼叫- 設定合理的超時和重試策略-**快取使用**- 使用 `mcache` 或 `mredis` 實現快取- 實現合適的快取失效策略## 程式碼示例### Controller 層示例```go// controller/example/example.gopackage exampleimport ("context""github.com/gin-gonic/gin""amap-aos-activity/framework/mlogger""amap-aos-activity/logic/example")// Handler 處理HTTP請求funcHandler(c *gin.Context) {    ctx := c.Request.Context()// 引數解析與驗證var req struct {UserID string `json:"userId" binding:"required"`    }if err := c.ShouldBindJSON(&req); err !=nil {        mlogger.XWarnf(ctx, "invalid request: %v", err)        c.JSON(400, gin.H{"code": "INVALID_PARAM", "message": "引數不合法"})return    }// 呼叫邏輯層    resp, err := example.ProcessRequest(ctx, req)if err !=nil {        c.JSON(500, gin.H{"code": err.Code, "message": err.Message})return    }    c.JSON(200, resp)}```### Logic 層示例```go// logic/example/processor.gopackage exampleimport ("context""github.com/pkg/errors""amap-aos-activity/basic/common""amap-aos-activity/framework/mlogger""amap-aos-activity/model/example")// ProcessRequest 處理業務邏輯funcProcessRequest(ctx context.Context, req interface{}) (interface{}, *common.Error) {// 型別斷言    request, ok := req.(struct{ UserID string })if!ok {returnnil, common.NewError(common.ErrCodeParam, "請求引數型別錯誤")    }// 業務邏輯處理    data, err := example.GetUserData(ctx, request.UserID)if err !=nil {        mlogger.XErrorf(ctx, "failed to get user data: %+v", errors.WithStack(err))returnnil, common.NewError(common.ErrCodeService, "獲取使用者資料失敗")    }// 返回結果    returnmap[string]interface{}{"userId": request.UserID,"data": data,    }, nil}```### Model 層示例```go// model/example/user_model.gopackage exampleimport ("context""time""github.com/pkg/errors""amap-aos-activity/framework/mdb""amap-aos-activity/framework/mcache")// UserData 表示使用者資料type UserDatastruct {UserID    string    `json:"userId" db:"user_id"`Name      string    `json:"name" db:"name"`CreatedAt time.Time `json:"createdAt" db:"created_at"`}// GetUserData 從資料庫獲取使用者資料funcGetUserData(ctx context.Context, userID string) (*UserData, error) {// 嘗試從快取獲取    cacheKey :="user_data:"+ userIDvar userData UserData    cached, err := mcache.Get(ctx, cacheKey, &userData)if err ==nil&& cached {return&userData, nil    }// 從資料庫查詢    query :="SELECT user_id, name, created_at FROM user_table WHERE user_id = ?"    err = mdb.GetDB().GetContext(ctx, &userData, query, userID)if err !=nil {returnnil, errors.Wrap(err, "query database failed")    }// 更新快取_= mcache.Set(ctx, cacheKey, userData, 5*time.Minute)return&userData, nil}```## 示例<example>// 良好實踐：正確的錯誤處理和日誌記錄package serviceimport ("context""github.com/pkg/errors""amap-aos-activity/basic/common""amap-aos-activity/framework/mlogger""amap-aos-activity/model/user")funcGetUserProfile(ctx context.Context, userID string) (*user.Profile, *common.Error) {// 引數驗證if userID =="" {returnnil, common.NewError(common.ErrCodeParam, "使用者ID不能為空")    }// 呼叫模型層    profile, err := user.GetProfileByID(ctx, userID)if err !=nil {// 包裝錯誤並記錄日誌        wrappedErr := errors.Wrap(err, "獲取使用者資料失敗")        mlogger.XErrorf(ctx, "%+v", wrappedErr) // 記錄堆疊資訊// 返回適當的業務錯誤if errors.Is(err, user.ErrUserNotFound) {returnnil, common.NewError(common.ErrCodeNotFound, "使用者不存在")        }returnnil, common.NewError(common.ErrCodeService, "獲取使用者資料失敗")    }return profile, nil}</example><example type="invalid">// 不良實踐：不規範的錯誤處理和日誌記錄package serviceimport ("context""fmt""log""amap-aos-activity/model/user")funcGetUserProfile(ctx context.Context, userID string) (*user.Profile, error) {// 缺少引數驗證// 直接呼叫模型層    profile, err := user.GetProfileByID(ctx, userID)if err !=nil {// 錯誤：使用fmt直接列印錯誤        fmt.Println("Error getting user profile:", err)// 錯誤：使用標準log包而非專案日誌框架        log.Printf("Failed to get profile for user %s: %v", userID, err)// 錯誤：直接返回底層錯誤，沒有包裝或分類returnnil, err    }return profile, nil}</example>
結合當前專案總結出golang開發規範，可以免去我們花大量時間補充。
最近新發布的版本，不建議大家馬上更新，涉及到隱私模式許可權問題，會有程式碼洩漏的風險，可以先等等。
新增自動記憶模組：簡單來說，這個功能會根據我們和Cursor的歷史對話，來自動建立User Rules。只要你的專案持續迭代，那麼這個User Rules就會自動更新。之前我們使用每次chat新開就是它的記憶在每次會話（session）之間會完全重置，目前新增了該模組，透過自動建立user rules變得更懂你。
一些有幫助的rules
1.專案梳理文件Rule：透過已有的程式碼進行codebase整理輸出專案架構、技術實現細節等

具體的Rule給到大家一個參考：
專案梳理文件Rule
# 專案文件規範**文件受眾明確為軟體開發人員**，目的是幫助開發團隊快速理解系統架構、業務邏輯和技術實現細節，便於程式碼維護、功能擴充套件和知識傳遞。## 關鍵規則- 專案文件必須包含四個核心部分：專案簡介、核心領域模型、專案結構和外部依賴- 介面文件必須按照@介面文件規範進行編寫和維護- 業務流程文件必須按照@業務流程文件規範進行編寫和維護- 文件應保持客觀性，基於現有程式碼而非理想狀態- 文件中使用的術語必須與程式碼中的術語保持一致- 文件應使用Markdown格式，支援圖表、表格和程式碼塊- 程式碼示例必須是從實際程式碼中提取的，而非虛構的- 圖表應使用Mermaid或PlantUML語法，以確保可維護性- 文件應當引用具體的程式碼檔案路徑，便於讀者查詢相關實現- 首先判斷專案是否使用GBF框架，並根據實際架構選擇適合的文件結構和內容- 所有文件必須統一放置在docs目錄下，並使用規定的中文名稱-**文件生成過程中必須確保完整覆蓋所有內容，不允許任何遺漏**## 文件最佳化與結構指南-**主索引文件**：每個核心部分建立一個主索引文件，包含子文件連結和簡要說明-**文件內導航**：超過500行的文件必須在開頭提供目錄-**分層結構**：按照"金字塔結構"組織（頂層：核心概念；中層：主要功能模組；底層：具體實現細節）-**文件拆分**：介面超過20個時按業務域拆分；核心實體超過10個時按業務領域拆分## 文件結構和內容要求### 1. 專案簡介 - docs/專案概述.md必須包含：專案背景、專案目標、功能概述、技術棧和架構型別（明確是否使用GBF框架）### 2. 核心領域模型 - docs/領域模型說明.md必須包含：- 領域模型概述：核心業務概念的定義和邊界- 核心實體關係圖：使用E-R圖或類圖表示- 關鍵業務場景下的模型互動- 資料流轉關係**強制性領域模型掃描規則**：-**全面掃描**：包括`*Entity.java`、`*DO.java`、`*PO.java`、`*Model.java`、`@Entity`、`@Table`、`@Document`註解類、服務層核心模型、DTO/VO類-**按目錄結構識別**：位於`model`、`domain`、`entity`目錄及其子目錄下的Java類檔案，以及領域模型專用包路徑（如`*.domain.*`、`*.model.*`、`*.entity.*`）下的類檔案-**完整提取**：實體屬性和業務含義、實體關係、聚合結構、生命週期和狀態流轉-**識別規則**：屬性約束、實體關係約束、狀態轉換規則**領域模型分析策略**：- 全域掃描實體類和值物件，支援多種ORM框架- 提取關聯關係（透過欄位型別、泛型引數和ORM註解）- 識別聚合根和聚合邊界（透過包結構和類間關係）- 分析繼承結構（包括抽象類、介面和實現類）- 提取業務方法和狀態轉換邏輯- 生成完整屬性表和業務規則說明**GBF框架專案補充**：擴充套件點定義與實現、行業/場景定製點、路由條件與動態選擇機制### 3. 介面文件 - docs/介面文件.md介面文件應遵循專門的@介面文件規範進行建立和維護，以確保API介面的完整記錄和更新。### 4. 業務流程 - docs/業務流程說明.md業務流程文件應遵循專門的@業務流程文件規範進行建立和維護，以確保業務流程的完整記錄和更新。### 5. 專案結構 - docs/專案結構說明.md必須包含：專案模組劃分、程式碼組織結構、關鍵包說明、分層架構說明**GBF框架專案補充** - docs/GBF框架應用說明.md：GBF分層結構、擴充套件點檔案位置、行業定製目錄、場景定製目錄### 6. 外部依賴與下游服務 - docs/外部依賴說明.md必須包含：- 下游服務概述：依賴的所有外部服務列表和用途- 呼叫關係圖：系統與外部服務的呼叫關係## 文件生成工作流程1.**架構識別**：確定專案架構型別、識別關鍵元件和分層結構2.**程式碼分析**：識別核心業務包和類、分析領域模型、提取介面定義、理解呼叫鏈路3.**內容整理**：按文件結構組織資訊、提取程式碼示例、繪製圖表4.**稽核完善**：驗證文件與程式碼一致性、補充關鍵資訊、完善圖表和示例   - **介面覆蓋性驗證**：確認總覽文件中的所有介面都在詳細文件中有完整描述   - **文件完整性檢查**：確保沒有遺漏任何必要的介面和服務描述5.**定期更新**：與程式碼審查流程整合、重大變更更新文件、每季度全面稽核## 示例### 領域模型示例```markdown## 核心實體關係圖```mermaidclassDiagram  classItem {    +Long id    +String name    +BigDecimal price    +String status    +validatePrice()    +changeStatus(String)  }  classTyingRule {    +Long id    +Long mainItemId    +List<Long> subItemIds    +Date startTime    +Date endTime    +enable()    +disable()  }  Item "1" -- "n" TyingRule: 被定義為主商品  TyingRule "1" -- "n" Item: 關聯搭售商品```## 實體屬性詳細說明### Item 商品實體| 屬性名 | 型別 | 說明 ||----|---|---|| id | Long | 商品唯一標識 || name | String | 商品名稱，長度限制：2-50個字元 || price | BigDecimal | 商品價格，精確到小數點後2位，最小值：0.01 || status | String | 商品狀態，列舉值：ON_SHELF(上架)、OFF_SHELF(下架)、DELETED(刪除) |#### 業務規則- 商品價格必須大於0- 商品狀態只能按特定流程轉換（上架->下架->刪除）```### 業務流程示例```markdown## 搭售規則建立流程### 核心流程圖```mermaidflowchart TD    A[建立請求] --> B{校驗引數}    B -->|無效| C[返回錯誤]    B -->|有效| D[查詢主商品]    D --> E{商品存在?}    E -->|否| F[返回錯誤]    E -->|是| G[查詢搭售商品]    G --> H{商品存在?}    H -->|否| I[返回錯誤]    H -->|是| J[儲存規則]    J --> K[返回成功]```### 呼叫鏈路**入口點**: `ItemTyingController.createTyingRule()`**呼叫流程**:1. 請求引數校驗 - `validateTyingRequest(request)`2. 查詢主商品資訊 - `itemService.getItemById()`3. 校驗主商品狀態 - `validateItemStatus(item)`4. 查詢並校驗搭售商品列表 - `validateSubItems()`5. 構建並儲存搭售規則 - `tyingRuleRepository.save()`6. 傳送規則建立事件 - `eventPublisher.publishEvent()`### 關鍵判斷點| 判斷點 | 條件 | 處理路徑 ||-----|---|----|| 引數校驗 | 主商品ID為空 | 返回引數錯誤 || 主商品校驗 | 主商品不存在 | 返回商品不存在錯誤 || 搭售商品校驗 | 存在無效商品 | 返回商品無效錯誤 |
兩個rule可以親自試試效果，第二個描述規範了Cursor要深入檢索，但是目前免費能用的模型很難做到，新出來的Claude4.0可以完成複雜任務的分析研究。
梳理專案Rule
# 程式碼分析規則## 目標根據程式碼入口深入分析完整業務流程，生成詳細的業務流程文件，便於團隊理解和維護程式碼。## 關鍵規則-**必須生成分析文件儲存到專案的docs目錄下**-**必須使用sequential-thinking輔助分析**-**必須深入方法內部邏輯，因此你可能需要檢索程式碼**-**建議使用sequential-thinking輔助檢索程式碼**### 1. 聚焦業務核心邏輯- 忽略日誌列印、引數基礎校驗等次要邏輯- 忽略異常處理中的技術細節，只關注業務異常處理邏輯- 忽略與業務無關的工具方法呼叫（如字串處理、集合操作等）- 聚焦業務狀態轉換、流程分支、核心計算等關鍵邏輯### 2. 深入方法呼叫鏈- 追蹤每個關鍵方法的內部實現，不僅停留在方法呼叫層面- 對呼叫鏈上的每個重要方法都分析其內部業務邏輯- 對於外部依賴的服務（如HSF、RPC呼叫），說明其功能和業務意義- 深入分析每個關鍵業務分支的條件和處理邏輯### 3. 結合已有文件- 優先使用已有文件中的描述，避免重複分析- 如果已有文件對某個方法有詳細描述，直接引用該內容- "站在巨人的肩膀上"，基於已有文件進行補充和完善- 對已有文件與程式碼實現不一致的地方進行標註### 4. 文件輸出規範- 分析結果儲存到 `/docs` 目錄下，使用 Markdown 格式- 文件命名格式：`業務名稱-流程分析.md`（如：`訂單建立-流程分析.md`）- 文件需包含方法呼叫樹，清晰展示呼叫層級關係- 使用分步業務流程描述完整處理過程## 文件結構模板```markdown# 業務名稱流程分析## 功能概述[簡要描述該業務功能的目的和作用]## 入口方法`com.example.Class.method`## 方法呼叫樹```入口方法├─ 一級呼叫方法1│  ├─ 二級呼叫方法1.1│  ├─ 二級呼叫方法1.2├─ 一級呼叫方法2   ├─ 二級呼叫方法2.1   └─ 二級呼叫方法2.2      └─ 三級呼叫方法```## 詳細業務流程1. [步驟1：業務邏輯描述]2. [步驟2：業務邏輯描述]   - [子步驟2.1：詳細邏輯]   - [子步驟2.2：詳細邏輯]3. [步驟3：業務邏輯描述]## 關鍵業務規則- [規則1：描述業務規則及其條件]- [規則2：描述業務規則及其條件]## 資料流轉- 輸入：[描述方法輸入及其業務含義]- 處理：[描述關鍵資料處理和轉換]- 輸出：[描述方法輸出及其業務含義]## 擴充套件點/分支邏輯- [分支1：觸發條件及處理邏輯]- [分支2：觸發條件及處理邏輯]## 外部依賴- 標註對外部系統的依賴## 注意事項- [列出實現中需要特別注意的點]```## 系統互動圖- 如果業務流程包含多個系統模組，請使用PlantUML畫出時序圖## 程式碼分析技巧### 步驟1：明確業務入口- 確定程式碼分析的起點（通常是Controller、Facade或Service層的公開方法）- 瞭解該方法的呼叫場景和業務背景### 步驟2：構建方法呼叫樹- 從入口方法開始，追蹤所有重要的方法呼叫- 使用縮排表示呼叫層級，清晰展示呼叫關係- 忽略非核心方法呼叫（如日誌、引數校驗等）### 步驟3：分析業務流程- 按照程式碼執行順序分析業務處理步驟- 重點關注業務狀態轉換和分支邏輯- 提取關鍵業務規則和資料處理邏輯### 步驟4：整理業務規則- 總結條件判斷中隱含的業務規則- 分析不同場景下的處理差異- 提煉業務邏輯的核心決策點### 步驟5：描述資料流轉- 分析關鍵資料的來源、處理和去向- 說明資料模型轉換和業務含義- 關注核心業務實體的狀態變化## 示例分析參考 [訂單查詢.md](/docs/訂單查詢.md) 文件瞭解完整的分析示例:該示例展示了訂單查詢業務的完整分析，包括:- 方法呼叫樹展示了完整呼叫鏈- 詳細業務流程按步驟拆解- 關鍵業務規則清晰列出- HSF介面等外部依賴明確說明- 特殊處理邏輯如推廣通退款按鈕透出詳細解釋## 好的分析的特徵1.**完整性**：覆蓋所有核心業務邏輯和分支2.**層次性**：清晰展示處理流程的層次結構3.**業務性**：以業務視角描述，而非技術實現細節4.**精確性**：準確反映程式碼的實際處理邏輯5.**可理解性**：業務人員也能理解的表述方式6.**實用性**：幫助讀者快速理解業務流程和規則 
2.技術方案詳細設計Rule:在Cursor輸出具體的方案，按照此Rule的結構生成，包含了核心實體、具體的時序互動、核心api的修改等等
技術方案詳細設計Rule
# 技術方案設計文件規範## 關鍵規則- 技術方案文件必須遵循規定的章節結構，包括名詞解釋、領域模型、應用呼叫關係和詳細方案設計四個主要部分- 名詞解釋部分必須建立業務和技術的統一語言，確保術語簡單易懂- 領域模型需清晰表達業務實體及其關係，可使用UML圖或ER圖進行視覺化- 應用呼叫關係必須體現跨應用的介面呼叫關係和MQ的生產消費關係- 詳細方案設計應按應用和業務流程進行分類，對每個介面的改動點、程式碼分層和文件變更進行詳細說明- 程式碼改動點需重點突出實現思路，而不僅是羅列程式碼變更- 對外介面協議的所有變更（包括欄位變更等）必須在介面文件中明確體現- 首先明確專案是否使用GBF框架，並選擇相應的技術方案設計模板- 使用GBF框架的專案，需明確說明各層級服務規劃及擴充套件點設計- 非GBF框架專案，應明確說明標準分層架構設計## 架構識別與方案適配### 如何判斷專案是否使用GBF框架- 程式碼中存在Process、NodeService、DomainService等類或註解- 存在Ability介面和Action實現類- 包結構中有platform、node、domain、ability等目錄- 有明確的擴充套件點機制和BizCode、Scenario路由### 方案適配策略- 使用GBF框架的專案，技術方案需關注擴充套件點設計和流程編排- 非GBF框架專案，技術方案關注傳統分層設計和介面實現- 在方案開頭明確說明專案所使用的架構模式- 根據架構特點選擇適當的設計模式和描述方式## 技術方案設計文件模板```markdown# 技術方案設計文件：[方案名稱]## 文件資訊- 作者：[作者姓名]- 版本：[版本號，如v1.0]- 日期：[建立/更新日期]- 狀態：[草稿/已評審/已確認]- 架構型別：[GBF框架/非GBF框架] - 版本：[框架版本號]# 一、名詞解釋[建立業務和技術的統一語言，儘量簡單易懂]| 術語 | 解釋 ||------|------|| 術語1 | 含義說明 || 術語2 | 含義說明 |# 二、領域模型[描述業務領域中的核心實體及其關係，推薦使用UML圖表示]## 核心實體[列出核心業務實體及其屬性、行為]## 實體關係[描述實體間的關係，可使用ER圖]```mermaidclassDiagram    Class01 <|-- AveryLongClass : Cool    Class03 *-- Class04    Class05 o-- Class06    Class07 .. Class08    Class09 --> C2 : Where am I?    Class09 --* C3    Class09 --|> Class07    Class07 : equals()    Class07 : Object[] elementData    Class01 : size()    Class01 : int chimp    Class01 : int gorilla    Class08 <--> C2: Cool label```# 三、應用呼叫關係[體現跨應用的介面呼叫關係、MQ的生產消費關係]## 系統架構圖[系統整體架構圖，展示系統元件和互動關係]```mermaidflowchart TD    A[應用1] -->|介面呼叫| B[應用2]    B -->|訊息傳送| C[訊息佇列]    D[應用3] -->|訊息消費| C    D -->|資料儲存| E[(資料庫)]```## 時序圖[關鍵流程的時序圖，展示元件間的互動順序]```mermaidsequenceDiagram    參與者A->>參與者B: 請求資料    參與者B->>參與者C: 轉發請求    參與者C-->>參與者B: 返回資料    參與者B-->>參與者A: 處理後返回```# 四、詳細方案設計## 架構選型[說明本方案採用的架構模式，如標準三層架構、GBF框架架構等]### 分層架構說明[描述本方案的分層架構，說明各層職責]#### 標準分層架構（非GBF框架專案）```# HTTP介面方式- Controller層：處理HTTP請求，引數校驗- Service層：實現業務邏輯- Repository層：資料訪問和持久化- Domain層：領域模型和業務規則# HSF/RPC服務方式- Provider層：服務提供者，定義和實現HSF服務介面- Service層：實現業務邏輯- Repository層：資料訪問和持久化- Domain層：領域模型和業務規則```### 資料模型設計[描述資料模型的設計，包括不同層次的資料模型]```# 標準資料模型（非GBF框架專案）- DTO(Data Transfer Object)：介面層資料傳輸物件- BO(Business Object)：業務邏輯層資料物件- DO(Domain Object)：領域模型物件- PO(Persistent Object)：持久化物件# GBF框架資料模型（GBF框架專案）- DTO：對接客戶端，透出業務流程結果- DO：封裝核心領域邏輯，定義服務入口- PO：與資料庫互動，遮蔽儲存細節```## 應用1### 業務流程1#### xxx介面**介面說明**：[詳細說明介面的用途和功能]**介面路徑**：[HTTP方法] [路徑] 或 [HSF服務介面定義]**請求引數**：```json{  "param1": "value1",  "param2": "value2"}```**返回結果**：```json{  "code": 200,  "message": "success",  "data": {    "field1": "value1",    "field2": "value2"  }}```#### 介面改動點[說明介面的改動型別：新增、能力調整、擴充套件等，並詳述改動內容]#### 程式碼分層設計[描述程式碼的分層結構，確保符合工程規範]##### 標準分層設計（非GBF框架專案）```# HTTP介面方式- Controller層：處理HTTP請求，引數校驗  - 職責：引數校驗、請求處理、結果封裝  - 程式碼位置：web包、controller包  - 設計要點：保持輕量，不包含業務邏輯- Service層：實現業務邏輯  - 職責：實現業務邏輯、編排服務呼叫、事務管理  - 程式碼位置：service包、manager包  - 設計要點：聚合與編排，可包含複雜業務邏輯- Repository層：資料訪問和持久化  - 職責：封裝資料訪問邏輯，實現資料持久化  - 程式碼位置：repository包、dao包  - 設計要點：封裝資料庫操作，提供資料訪問介面- Domain層：領域模型和業務規則  - 職責：定義領域模型，實現領域規則  - 程式碼位置：domain包、model包  - 設計要點：領域驅動設計，封裝核心業務規則```##### GBF框架分層設計（GBF框架專案）```# Process定義（Platform層）- 職責：編排NodeService，形成完整業務流程- 程式碼位置：platform包- 設計要點：  - Process作為最上層邏輯，直接承接介面請求  - 透過Spring Bean宣告Process流程配置  - Process只能呼叫NodeService，不能跨層呼叫  - 不應包含具體業務邏輯，專注於流程編排# NodeService實現（Node層）- 職責：組合多個DomainService，形成標準化服務入口- 程式碼位置：node包- 設計要點：  - NodeService作為標準化服務入口  - 禁止NodeService之間相互呼叫  - 透過擴充套件點控制節點級邏輯(如前置校驗)  - 不應包含複雜業務邏輯，主要負責編排# DomainService實現（Domain層）- 職責：提供原子級業務能力- 程式碼位置：domain包- 設計要點：  - DomainService提供原子級業務能力  - 禁止DomainService之間相互呼叫  - 依賴擴充套件點介面實現邏輯分支控制  - 包含特定領域的核心業務邏輯# 擴充套件點設計（Ability層與App層）- 職責：定義擴充套件點介面和實現- 程式碼位置：  - 介面定義：ability包  - 行業實現：app包下對應行業目錄  - 場景實現：domain/node包下對應scenario目錄- 設計要點：  - 統一在Ability層宣告擴充套件點介面  - 行業定製實現放在App層(如/app/food/)  - 場景定製實現放在Domain/Node包下  - 擴充套件點必須有預設實現，保證基礎功能可用```#### 擴充套件點設計（GBF框架專案）[詳細說明本功能涉及的擴充套件點設計]```java# 擴充套件點介面（Ability層）package com.amap.xxx.ability;/** * [擴充套件點名稱]能力 */public interface XxxAbility {    /**     * [方法說明]     * @param request 請求引數     * @return 處理結果     */    Result doSomething(XxxRequest request);}# 擴充套件點實現路由條件- BizCode：[業務碼，如"FOOD"、"RETAIL"]- Scenario：[場景碼，如"C2C"、"B2C"]- 優先順序規則：  1. 精確匹配（BizCode + Scenario）  2. 按場景降級匹配  3. 使用預設實現# 擴充套件點預設實現（Ability層）package com.amap.xxx.ability.impl;/** * [擴充套件點名稱]預設實現 */publicclassDefaultXxxActionimplementsXxxAbility {    @Override    public Result doSomething(XxxRequest request){        // 預設實現邏輯        return Result.success();    }}# 擴充套件點行業定製實現（App層）package com.amap.xxx.app.food;/** * [行業名稱][擴充套件點名稱]實現 */@Extension(bizId = "FOOD")publicclassFoodXxxActionimplementsXxxAbility {    @Override    public Result doSomething(XxxRequest request){        // 行業特定實現邏輯        return Result.success();    }}# 擴充套件點場景定製實現（Domain/Node層）package com.amap.xxx.domain.scenario.b2c;/** * [場景名稱][擴充套件點名稱]實現 */@Extension(scenario = "B2C")publicclassB2CXxxActionimplementsXxxAbility {    @Override    public Result doSomething(XxxRequest request){        // 場景特定實現邏輯        return Result.success();    }}```##### 路由條件設計[說明擴充套件點的路由條件設計]```# 路由維度- 業務維度（BizCode）：區分不同行業，如"FOOD"、"RETAIL"- 場景維度（Scenario）：區分不同場景，如"C2C"、"B2C"- 其他維度：使用者型別、渠道等# 路由策略- 優先順序1：精確匹配（BizCode=A + Scenario=B）- 優先順序2：業務碼匹配（BizCode=A）- 優先順序3：場景碼匹配（Scenario=B）- 優先順序4：預設實現# 降級策略如果找不到滿足條件的擴充套件點實現，按優先順序順序降級匹配，直到找到預設實現```#### 程式碼改動點[詳述需要改動的程式碼，重點說明實現思路]1. Controller/Provider層改動：   - 新增XX控制器/服務提供者   - 修改YY方法引數2. Service層改動：   - 新增XX服務   - 調整YY邏輯處理流程3. GBF框架特定改動(GBF框架專案)：   - 新增Process流程定義   - 新增NodeService節點服務   - 新增擴充套件點介面與實現   - 修改擴充套件點路由規則## 資料庫變更### 表結構設計[描述需要新增或修改的資料庫表結構]#### 表名：[表名]| 欄位名 | 資料型別 | 是否為空 | 主鍵 | 註釋 ||-------|---------|---------|------|------|| id | bigint | 否 | 是 | 主鍵ID || ... | ... | ... | ... | ... |### 索引設計[描述需要新增或修改的索引]| 索引名 | 欄位 | 索引型別 | 說明 ||-------|------|---------|------|| idx_xxx | 欄位1, 欄位2 | 普通/唯一/主鍵 | 索引說明 |## 介面文件變更[描述需要新增或修改的介面文件]### 介面名：[介面名]- 介面路徑：[HTTP方法] [路徑] 或 [HSF服務介面定義]- 變更型別：[新增/修改/刪除]- 變更說明：[詳細說明介面變更]## 配置變更[描述需要新增或修改的配置]### 配置型別：[配置型別]- 配置名：[配置名]- 配置值：[配置值]- 說明：[配置說明]## 非功能性需求### 效能需求[描述效能需求，如響應時間、併發量等]### 可用性需求[描述可用性需求，如系統可用率、故障恢復能力等]### 擴充套件性需求[描述擴充套件性需求，如系統的可擴充套件性、可伸縮性等]## 相容性與平滑遷移方案[描述系統升級的相容性問題及平滑遷移方案]### 相容性問題[描述可能的相容性問題]### 平滑遷移方案[描述平滑遷移的方案]## 風險與應對措施[描述可能的風險及應對措施]| 風險 | 可能性 | 影響 | 應對措施 ||------|-------|------|---------|| 風險1 | 高/中/低 | 高/中/低 | 應對措施1 || 風險2 | 高/中/低 | 高/中/低 | 應對措施2 |```## 示例### 非GBF框架專案技術方案示例<example>## 程式碼分層設計### 新增商品API的實現結構如下：```# Controller層- com.amap.mall.web.controller.ProductController  - 職責：接收HTTP請求，校驗引數，呼叫Service層，封裝返回結果  - 主要方法：addProduct(AddProductRequest request)# Service層- com.amap.mall.service.ProductService (介面)- com.amap.mall.service.impl.ProductServiceImpl (實現)  - 職責：處理業務邏輯，呼叫Repository層，實現事務控制  - 主要方法：addProduct(ProductDO product)# Repository層- com.amap.mall.repository.ProductRepository (介面)- com.amap.mall.repository.impl.ProductRepositoryImpl (實現)  - 職責：封裝資料訪問邏輯，呼叫DAO層  - 主要方法：insert(ProductPO product)# DAO層- com.amap.mall.dao.ProductDAO  - 職責：與資料庫互動，執行SQL  - 主要方法：insert(ProductPO product)```根據上述設計，新增商品功能的呼叫鏈為：1. 客戶端呼叫ProductController.addProduct()2. Controller校驗引數並呼叫ProductService.addProduct()3. Service處理業務邏輯並呼叫ProductRepository.insert()4. Repository轉換物件並呼叫ProductDAO.insert()5. DAO執行SQL插入資料</example>### GBF框架專案技術方案示例<example>## GBF框架分層設計### 新增搭售規則功能的實現結構如下：```# Process層（Platform層）- com.amap.mall.tying.platform.CreateRuleProcess  - 職責：定義搭售規則建立流程，編排NodeService呼叫順序  - 流程節點：引數校驗 -> 商品資訊獲取 -> 規則衝突檢查 -> 規則持久化# NodeService層（Node層）- com.amap.mall.tying.node.ValidateRuleNodeService  - 職責：實現規則引數校驗節點  - 使用擴充套件點：RuleValidateAbility（規則校驗能力）- com.amap.mall.tying.node.CheckConflictNodeService  - 職責：實現規則衝突檢查節點  - 使用擴充套件點：ConflictCheckAbility（衝突檢查能力）- com.amap.mall.tying.node.PersistRuleNodeService  - 職責：實現規則持久化節點  - 使用擴充套件點：RulePersistAbility（規則持久化能力）# DomainService層（Domain層，可選）- com.amap.mall.tying.domain.service.ItemInfoDomainService  - 職責：獲取商品資訊的原子能力服務  - 使用擴充套件點：ItemInfoAbility（商品資訊獲取能力）# Ability層（擴充套件點介面定義）- com.amap.mall.tying.ability.RuleValidateAbility  - 職責：定義規則校驗的擴充套件點介面  - 方法：validate(RuleRequest request)- com.amap.mall.tying.ability.ConflictCheckAbility  - 職責：定義衝突檢查的擴充套件點介面  - 方法：check(RuleRequest request)# App層（行業定製實現）- com.amap.mall.tying.app.food.FoodRuleValidateAction  - 職責：實現食品行業特定的規則校驗邏輯  - 路由條件：@Extension(bizId = "FOOD")- com.amap.mall.tying.app.retail.RetailRuleValidateAction  - 職責：實現零售行業特定的規則校驗邏輯  - 路由條件：@Extension(bizId = "RETAIL")# 預設實現（Ability層實現）- com.amap.mall.tying.ability.impl.DefaultRuleValidateAction  - 職責：實現預設的規則校驗邏輯  - 應用場景：當不滿足任何行業/場景定製條件時```擴充套件點路由設計：1. 按業務碼（bizId）路由：不同行業的定製實現   - FOOD -> FoodRuleValidateAction   - RETAIL -> RetailRuleValidateAction2. 按場景碼（scenario）路由：不同場景的定製實現   - B2C -> B2CRuleValidateAction   - C2C -> C2CRuleValidateAction3. 精確匹配：同時匹配業務碼和場景碼   - FOOD + B2C -> FoodB2CRuleValidateAction4. 降級策略：找不到匹配的實現時，使用預設實現   - 預設 -> DefaultRuleValidateAction</example><example type="invalid">## 技術方案設計我們將實現一個新的搭售規則管理功能。開發計劃：1. 新增新的Controller處理HTTP請求2. 新增新的Service處理業務邏輯3. 新增新的DAO訪問資料庫（錯誤原因：沒有明確說明專案使用的架構型別，缺乏分層設計的詳細說明，沒有明確介面定義和實現方式，對於GBF專案沒有說明擴充套件點設計）</example>## 方案設計工作流程1. **架構識別階段**   - 確定專案使用的架構型別(GBF/非GBF)   - 識別關鍵架構元件和分層結構   - 確定方案設計重點和特殊要求   - 選擇適合的方案模板2. **需求分析階段**   - 確定功能邊界和核心業務流程   - 識別核心業務實體和領域模型   - 確定介面定義和資料結構   - 識別可能的擴充套件點和變化點3. **方案設計階段**   - 根據架構特點進行分層設計   - 確定介面實現和元件互動   - 設計資料庫結構和索引   - 對於GBF專案，設計擴充套件點和路由規則4. **方案評審階段**   - 驗證方案與架構的一致性   - 驗證功能覆蓋度和完整性   - 評估技術風險和效能問題   - 確保方案文件結構清晰、內容完整
3.中介軟體Rule:專案開發用到的一些比較常見的中介軟體的呼叫規範。
中介軟體使用規範
---description: `此規則適用於go專案的單元測試開發規範，Go單元測試提供全面指南，規範測試結構、mock技術和斷言方法，確保測試程式碼質量與可維護性。`globs:alwaysApply: false---# 中介軟體客戶端呼叫規範## 關鍵規則- **所有HTTP和HSF等中介軟體客戶端必須放在framework/client目錄下**- **必須遵循統一的命名規範：服務功能+Service命名方式**- **必須使用Context作為第一個引數，支援分散式追蹤和日誌記錄**- **中介軟體客戶端必須從配置中心讀取配置，不允許硬編碼**- **中介軟體呼叫必須記錄完整的請求和響應日誌**- **必須實現統一的錯誤處理和返回機制**- **應對關鍵呼叫實現快取機制，減少直接呼叫次數**- **請求和響應結構體必須實現JavaClassName方法（HSF特有）**- **HSF服務必須在init方法中註冊模型**- **客戶端呼叫需要進行合理的超時控制**## HTTP客戶端標準實現### 客戶端定義規範```go// 客戶端標準定義type XXXHttpClient struct {// 可選的客戶端配置}// 必須定義統一的初始化方法func NewXXXHttpClient(ctx context.Context) *XXXHttpClient {return &XXXHttpClient{}}```### 請求引數定義```go// 請求引數必須使用結構體定義type RequestParams struct {// 請求欄位    Field1 string `json:"field1"`    Field2 int    `json:"field2"`// ...}```### 標準HTTP呼叫實現```go// 標準HTTP呼叫方法func (client *XXXHttpClient) SendRequest(ctx context.Context, params RequestParams) (ResponseType, error) {// 1. 從配置中心獲取URL配置var conf simplehttp.URLSetting    urlConf := mconfig.UrlConfig()if err := urlConf.UnmarshalKey("ConfigKey", &conf); err != nil || conf.URL == "" {return nil, common.Errorf(common.ErrorInternal, "url conf miss")    }// 2. 構建URL和請求引數    url := conf.URL + "/api/endpoint"    httpParams := map[string]string{"param1": params.Field1,"param2": types.IWrapper(params.Field2).String(),// 必須加入追蹤ID"trace_id": eagleeye.GetTraceId(ctx),    }// 3. 構建請求選項    opt := simplehttp.BuildOptions(&simplehttp.Options{        Method:           "GET", // 或 POST 等        Params:           httpParams,        Timeout:          conf.Timeout,        HostWithVip:      conf.VipHost,        RecordWithParams: httpcommon.RecordWithParams,    })// 4. 傳送請求並記錄日誌    respData, err := simplehttp.RequestWithContext(ctx, url, opt)    common.LogInfof(ctx, "log_type", "request info, params=%v, err=%v", params, err)// 5. 錯誤處理if err != nil {return nil, common.Errorf(common.ErrorInternal, "request failed.err:%s", err.Error())    }// 6. 解析響應var response ResponseType    err = json.Unmarshal(respData, &response)if err != nil {return nil, common.Errorf(common.ErrorInternal, "unmarshal failed.err:%s", err.Error())    }// 7. 返回結果return response, nil}```### 帶快取的HTTP呼叫```gofunc GetDataWithCache(ctx context.Context, key string, params RequestParams) (ResponseType, error) {var resp ResponseType    cacheKey := fmt.Sprintf("cache_key_prefix_%s", key)// 使用快取機制    err := mcache.GetLocalCacheFiveSecond(ctx).Once(ctx, cacheKey, &resp, 5*time.Second, func() (interface{}, error) {// 呼叫實際APIdata, e := SendRequest(ctx, params)// 記錄日誌        common.LogDebugf(ctx, "module_name", "GetData, key:%s, data:%+v, err:%v", key, data, e)// 錯誤處理if e != nil {return nil, errors.New(e.Error())        }returndata, nil    })if err != nil {return nil, err    }return resp, nil}```## HSF客戶端標準實現### 服務定義規範```go// 全域性服務例項var XXXService = new(XXXServiceImpl)// 註冊HSF模型func init() {    hsfCommon.RegisterModel(&ModelType1{})    hsfCommon.RegisterModel(&ModelType2{})// 其他模型註冊...}// 服務結構體定義type XXXServiceImpl struct {// 方法定義，必須遵循標準方法簽名    MethodName func(ctx context.Context, args []interface{}) (*ResponseType, error)}// 介面名配置func (s *XXXServiceImpl) InterfaceName() string {return mconfig.UrlConfig().GetString("ServiceName.interfaceName")}// 版本配置func (s *XXXServiceImpl) Version() string {return mconfig.UrlConfig().GetString("ServiceName.version")}// 組名配置func (s *XXXServiceImpl) Group() string {return mconfig.UrlConfig().GetString("ServiceName.group")}// 超時配置func (s *XXXServiceImpl) TimeoutMs() int {return mconfig.UrlConfig().GetInt("ServiceName.timeout")}```### 請求模型定義```go// 請求模型必須實現JavaClassName方法type RequestType struct {    Field1 string    `json:"field1" hessian:"field1"`    Field2 int64     `json:"field2" hessian:"field2"`// ...}func (RequestType) JavaClassName() string {return"com.package.RequestType"}// 響應模型必須實現JavaClassName方法type ResponseType struct {    Code    int32       `json:"code"`    Data    interface{} `json:"data"`    Success bool        `json:"success"`// ...}func (ResponseType) JavaClassName() string {return"com.package.ResponseType"}```### 標準HSF呼叫實現```go// 標準HSF呼叫方法func CallHSFService(ctx context.Context, request *RequestType) (*DataType, *common.Error) {// 1. 呼叫HSF服務    hsfResp, e := XXXService.MethodName(ctx, []interface{}{request})// 2. 記錄請求和響應日誌    reqJson, _ := json.Marshal(request)    respJson, _ := json.Marshal(hsfResp)    common.LogInfof(ctx, "hsf_call", "hsf resp:%s, err:%v, req:%s",        string(respJson), e, string(reqJson))// 3. 錯誤處理if e != nil {return nil, common.Errorf(common.ErrorInternal, "HSF call failed.err:%s", e.Error())    }// 4. 結果處理if hsfResp != nil {        result := ParseResponseData(hsfResp.Data)return result, nil    }return nil, nil}// 解析響應資料的標準方法func ParseResponseData(datainterface{}) *DataType {ifdata == nil {return nil    }if items, ok := data.(SpecificResponseType); ok {// 處理資料轉換        result := &DataType{// 資料轉換邏輯        }return result    }return nil}```### 帶快取的HSF呼叫```gofunc GetHSFDataWithCache(ctx context.Context, param1, param2 string) (*DataType, error) {var resp *DataType    cacheKey := fmt.Sprintf("hsf_cache_key_%s_%s", param1, param2)// 使用快取機制    err := mcache.GetLocalCacheFiveSecond(ctx).Once(ctx, cacheKey, &resp, 5*time.Second, func() (interface{}, error) {// 構建HSF請求        request := &RequestType{            Field1: param1,            Field2: param2,        }// 呼叫HSF服務data, e := CallHSFService(ctx, request)// 記錄日誌        common.LogDebugf(ctx, "hsf_module", "GetHSFData, key:%s, data:%+v, err:%v", cacheKey, data, e)// 錯誤處理if e != nil {return nil, errors.New(e.Error())        }returndata, nil    })if err != nil {return nil, err    }return resp, nil}```## 錯誤處理規範- **所有中介軟體呼叫都必須返回標準化的錯誤**- **錯誤必須包含錯誤碼和錯誤資訊**- **網路錯誤必須歸類為InternalError**- **引數錯誤必須歸類為InvalidError**- **業務邏輯錯誤必須根據具體場景進行分類**```go// 錯誤處理示例if err != nil {// 網路錯誤if netErr, ok := err.(net.Error); ok && netErr.Timeout() {return nil, common.Errorf(common.ErrorTimeout, "request timeout: %s", err.Error())    }// 一般錯誤return nil, common.Errorf(common.ErrorInternal, "request failed: %s", err.Error())}// 業務錯誤if resp.Code != 200 {return nil, common.Errorf(common.ErrorBusiness, "business error: %s", resp.Message)}```## 日誌記錄規範- **所有中介軟體呼叫必須記錄請求和響應日誌**- **日誌必須包含追蹤ID、請求引數和響應結果**- **敏感資訊（如密碼、token）必須在日誌中脫敏**- **必須使用統一的日誌模組和日誌格式**```go// 標準日誌示例common.LogInfof(ctx, "module_name", "method_name, param1=%v, param2=%v, resp=%s, err=%v",    param1, param2, respJson, err)```## 示例<example>// HTTP客戶端呼叫示例package clientimport ("amap-aos-activity/basic/common""amap-aos-activity/framework/mconfig""context""encoding/json""fmt""gitlab.alibaba-inc.com/amap-go/eagleeye-go""gitlab.alibaba-inc.com/amap-go/http-client/simplehttp"    httpcommon "gitlab.alibaba-inc.com/amap-go/http-client/common""time")// 請求引數定義type SearchParams struct {    Query    string  `json:"query"`    Latitude float64 `json:"latitude"`    Longitude float64 `json:"longitude"`}// 響應結構定義type SearchResponse struct {    Code    int           `json:"code"`    Message string        `json:"message"`    Data    []SearchItem  `json:"data"`}type SearchItem struct {    ID      string  `json:"id"`    Name    string  `json:"name"`    Distance float64 `json:"distance"`}// 傳送搜尋請求func SendSearchRequest(ctx context.Context, params SearchParams) (*SearchResponse, *common.Error) {// 從配置中獲取URLvar conf simplehttp.URLSetting    urlConf := mconfig.UrlConfig()if err := urlConf.UnmarshalKey("SearchService", &conf); err != nil || conf.URL == "" {return nil, common.Errorf(common.ErrorInternal, "search service url conf miss")    }// 構建請求引數    httpParams := map[string]string{"query": params.Query,"latitude": fmt.Sprintf("%f", params.Latitude),"longitude": fmt.Sprintf("%f", params.Longitude),"trace_id": eagleeye.GetTraceId(ctx),    }// 構建請求選項    opt := simplehttp.BuildOptions(&simplehttp.Options{        Method:           "GET",        Params:           httpParams,        Timeout:          conf.Timeout,        HostWithVip:      conf.VipHost,        RecordWithParams: httpcommon.RecordWithParams,    })// 傳送請求    url := conf.URL + "/search/api"    respData, err := simplehttp.RequestWithContext(ctx, url, opt)    common.LogInfof(ctx, "search_service", "search request, params=%v, err=%v", params, err)// 錯誤處理if err != nil {return nil, common.Errorf(common.ErrorInternal, "search request failed: %s", err.Error())    }// 解析響應var response SearchResponseif err := json.Unmarshal(respData, &response); err != nil {return nil, common.Errorf(common.ErrorInternal, "unmarshal search response failed: %s", err.Error())    }// 業務錯誤處理if response.Code != 200 {return nil, common.Errorf(common.ErrorBusiness, "search business error: %s", response.Message)    }return &response, nil}// 帶快取的搜尋請求func SearchWithCache(ctx context.Context, params SearchParams) (*SearchResponse, error) {var resp *SearchResponse    cacheKey := fmt.Sprintf("search_%s_%f_%f", params.Query, params.Latitude, params.Longitude)    err := mcache.GetLocalCacheFiveSecond(ctx).Once(ctx, cacheKey, &resp, 30*time.Second, func() (interface{}, error) {        result, e := SendSearchRequest(ctx, params)if e != nil {return nil, e        }return result, nil    })if err != nil {return nil, err    }return resp, nil}</example><example>// HSF客戶端呼叫示例package clientimport ("amap-aos-activity/basic/common""amap-aos-activity/framework/mconfig""context""encoding/json""errors""fmt"    hsfCommon "gitlab.alibaba-inc.com/amap-go/hsf-go/common""time")// 全域性服務例項var ProductService = new(ProductServiceImpl)// 註冊HSF模型func init() {    hsfCommon.RegisterModel(&ProductQueryRequest{})    hsfCommon.RegisterModel(&ProductQueryResponse{})    hsfCommon.RegisterModel(&ProductDetail{})}// 請求模型type ProductQueryRequest struct {    ProductId string   `json:"productId" hessian:"productId"`    Fields    []string `json:"fields" hessian:"fields"`}func (ProductQueryRequest) JavaClassName() string {return"com.example.product.request.ProductQueryRequest"}// 響應模型type ProductQueryResponse struct {    Code    int32         `json:"code"`    Data    *ProductDetail `json:"data"`    Success bool          `json:"success"`    Message string        `json:"message"`}func (ProductQueryResponse) JavaClassName() string {return"com.example.product.response.ProductQueryResponse"}// 產品詳情type ProductDetail struct {    Id          string  `json:"id" hessian:"id"`    Name        string  `json:"name" hessian:"name"`    Price       int64   `json:"price" hessian:"price"`    Description string  `json:"description" hessian:"description"`}func (ProductDetail) JavaClassName() string {return"com.example.product.model.ProductDetail"}// 服務結構體type ProductServiceImpl struct {    QueryProduct func(ctx context.Context, args []interface{}) (*ProductQueryResponse, error)}// 介面配置func (s *ProductServiceImpl) InterfaceName() string {return mconfig.UrlConfig().GetString("ProductService.interfaceName")}func (s *ProductServiceImpl) Version() string {return mconfig.UrlConfig().GetString("ProductService.version")}func (s *ProductServiceImpl) Group() string {return mconfig.UrlConfig().GetString("ProductService.group")}func (s *ProductServiceImpl) TimeoutMs() int {return mconfig.UrlConfig().GetInt("ProductService.timeout")}// 查詢產品資訊func GetProductDetail(ctx context.Context, productId string) (*ProductDetail, *common.Error) {// 構建請求    request := &ProductQueryRequest{        ProductId: productId,        Fields: []string{"id", "name", "price", "description"},    }// 呼叫HSF服務    resp, err := ProductService.QueryProduct(ctx, []interface{}{request})// 記錄日誌    reqJson, _ := json.Marshal(request)    respJson, _ := json.Marshal(resp)    common.LogInfof(ctx, "product_service", "query product, req=%s, resp=%s, err=%v",        string(reqJson), string(respJson), err)// 錯誤處理if err != nil {return nil, common.Errorf(common.ErrorInternal, "query product failed: %s", err.Error())    }// 結果處理if resp != nil {if !resp.Success || resp.Code != 200 {return nil, common.Errorf(common.ErrorBusiness, "business error: %s", resp.Message)        }return resp.Data, nil    }return nil, common.Errorf(common.ErrorInternal, "empty response")}// 帶快取的產品查詢func GetProductWithCache(ctx context.Context, productId string) (*ProductDetail, error) {var product *ProductDetail    cacheKey := fmt.Sprintf("product_detail_%s", productId)    err := mcache.GetLocalCacheFiveSecond(ctx).Once(ctx, cacheKey, &product, 5*time.Minute, func() (interface{}, error) {        detail, e := GetProductDetail(ctx, productId)if e != nil {return nil, errors.New(e.Error())        }return detail, nil    })if err != nil {return nil, err    }return product, nil}</example><example type="invalid">// 錯誤示例：硬編碼URL和缺少日誌記錄package clientimport ("context""encoding/json""net/http""io/ioutil")// 錯誤1: 硬編碼URL// 錯誤2: 沒有使用配置中心// 錯誤3: 沒有傳遞和使用contextfunc BadSearchRequest(query string) ([]byte, error) {// 硬編碼URL    url := "http://search.example.com/api?query=" + query// 沒有超時控制    resp, err := http.Get(url)if err != nil {return nil, err    }    defer resp.Body.Close()// 沒有日誌記錄return ioutil.ReadAll(resp.Body)}// 錯誤示例：HSF呼叫不規範var badHsfService = struct {    Method func(args []interface{}) (interface{}, error)}{}// 錯誤1: 不遵循標準介面定義// 錯誤2: 沒有使用Context引數// 錯誤3: 沒有註冊模型// 錯誤4: 錯誤處理不規範func BadHsfCall(id string) interface{} {    result, _ := badHsfService.Method([]interface{}{id})// 忽略錯誤處理return result}</example>
MCP
MCP作為cursor的加強工具，可以讓工作中更加流暢。
在MCP開發過程中發現了一個很好用的平臺，可以直接API轉MCP,大家有需求的可以嘗試使用，比自己開發mcp省時方便。
https://openlm.alibaba-inc.com/web/workbench/chatOs/tools?pathname=%2Ftools
簡單介紹我日常會用到的MCP
釘釘文件搜尋
在我們日常引用到內部的文件比較麻煩，可能需要把文章下載為md文件，在載入到cursor中，使用該MCP可以直接使用，不需要來回轉換，比較便利，這個是我們前端的團隊同學開發的mcp

任務分解大師
對於cursor的實踐，需求拆分到合理的粒度cursor的效果更好些，對於一些複雜的需求可以嘗試使用任務分解的工具，能幫助cursor更加專注

Cursor現階段做得不好的點
經過這段時間的實踐，在程式設計領域Cursor做的很不錯，在一些比較大的需求上，表現的效果不穩定，比如技術方案需要參考業界已有的優秀案例為參考，能設計出有水平的技術方案，業界對這部分的定義稱為-深度研究。說到深度研究，鼎鼎有名的就是今年釋出的DeepResearch，簡單介紹一下:
DeepResearch深度研究
先說一下背景，為什麼會討論到深度研究：
  • 目前Cursor在根據已有的程式碼做codebase，梳理專案，發現他很偷懶，梳理的淺顯；
  • 對於服務開發來說，一個大型專案是需要充分的調研&技術選型，目前cursor能做到的是給出一個方案，但是大多數是不可用的而且也沒有依據不可追溯；
對於目前Cursor是無法按照預期完成以上兩個任務，經過調研，發現了DeepResearch深度研究。
深度研究通常包括以下幾個步驟：
1.規劃：AI處理研究任務並獨立規劃搜尋過程和搜尋查詢；
2.資訊搜尋：AI搜尋多種來源的資訊並過濾不重要的內容；
3.分析：AI"閱讀"所有收集的文字，提取重要事實，比較來源並識別矛盾；
4.結構化和整理：AI以清晰結構化的報告形式呈現結果；
目前主要提供深度研究功能的平臺有：
  • Perplexity Pro
  • ChatGPT Pro
  • Gemini Advanced
ata有分析對比多這幾個平臺的差異性，大家可以自行前往檢視。
Deep Research 和Cursor的區別，以下是Cursor給出的答案：

以上能回答能解釋我們一部分的疑惑，為什麼codebase回答的淺顯，目前看深入研究並不是他擅長的，研究的活要交給專業的DeepResearch來做。相應的阿里千問也支援深度思考，官網地址：https://chat.qwen.ai/c/2e6f01d2-81ba-45ba-b943-9997970f07b8

由於是商業化的模型閉源，其實內部真實的原理如何做到如此強大是無法清晰瞭解，藉此機會瞭解了一下AutoGPT。
AutoGPT

Auto-GPT是什麼？

Auto-GPT是一種基於OpenAI的GPT（Generative Pre-trained Transformer）大語言模型的自動化智慧體（Agent）框架。它的核心思想是讓AI能夠自主地分解目標、規劃任務、執行操作，並根據反饋不斷調整自己的行為，最終實現使用者設定的複雜目標。
其中AutoGPT算是其中一個比較具有代表性的Agent
主要特點：
1. 自主性：Auto-GPT可以根據使用者給定的高層目標，自動生成子任務並逐步完成，無需人工干預每一步。
2. 任務分解與執行：它會將複雜目標拆解為多個可執行的小任務，並自動呼叫各種工具（如搜尋、程式碼生成、檔案操作等）來完成這些任務。
3. 迴圈反饋：Auto-GPT會根據每一步的結果自動調整後續計劃，直到目標達成或遇到無法解決的問題。
4. 外掛與擴充套件性：支援整合第三方API、資料庫、網路爬蟲等多種能力，適合自動化辦公、資料分析、內容生成等場景。
典型應用場景：
  • 自動化寫作、報告生成
  • 自動化程式碼編寫與除錯
  • 自動化資料收集與分析
  • 智慧助手、RPA（機器人流程自動化）
與普通GPT的區別：
  • 普通GPT模型通常是“問答式”或“單輪對話”，需要使用者逐步引導。
  • Auto-GPT則具備“自主規劃與執行”能力，可以像一個智慧體一樣，自動完成一系列複雜任務。
舉例說明：
假如你讓Auto-GPT“幫我調研2024年AI領域的最新趨勢並寫一份報告”，它會自動：
1. 拆解任務（如：查詢資料、整理要點、撰寫報告）
2. 自動上網搜尋、收集資訊
3. 歸納整理內容
4. 生成結構化報告
5. 甚至可以自動儲存為檔案或傳送郵件

AutoGPT的原理

AutoGPT組成

1.使用者互動介面CLI：使用者可以在這裡輸入任務和目標，檢視AutoGPT的執行過程和結果。
2.PromptManager：這是AutoGPT的核心模組，負責根據任務和目標生成適當的提示，並呼叫GPT-4或GPT-3.5來獲取回答。
3.LLM能力：這是AutoGPT利用的語言模型，主要是GPT-4，用於生成文字、程式碼、方案等內容；也可以使用GPT-3.5，用於總結資訊、解決問題等功能。
4.Memory管理：這是AutoGPT的儲存模組，負責將互動的結果儲存到檔案中，以便日後參考或複用。
5.任務管理：這是AutoGPT的控制模組，負責記錄使用者的目標，並根據執行情況生成新的子任務或結束任務。

AutoGPT處理流程

AutoGPT的原理是利用GPT-4和其他服務來自主執行任務，其核心是一個無限迴圈的程式，它可以根據使用者的任務指令，自動提出問題並進行回答，從而完成任務。AutoGPT的原理可以分為以下幾個步驟：
1.獲取使用者的任務指令。使用者可以透過命令列或者網頁介面，輸入一個簡單的任務指令，例如“increase net worth”。AutoGPT會接收到使用者的任務指令，並將其儲存在記憶體中。
2.分析使用者的任務指令。AutoGPT會呼叫GPT-4來分析使用者的任務指令，提取出其中的關鍵詞和目標。生成Plan：
a.Use the 'google' command to search for articles on personal finance and investment strategies 
b.Read and analyze the information gathered to determine the best course of action 
3.執行2步生成需要執行command(包括透過google查詢資料，訪問網站，寫程式碼、生成圖片、呼叫API等)，並儲存結果到記憶體。
4.檢查回答是否滿足目標。AutoGPT會檢查每個回答是否滿足使用者的任務指令中的目標，如果滿足，則將回答儲存在檔案中，並繼續回答下一個問題；如果不滿足，則將回答丟棄，並重新生成一個新的任務列表。
5.重複第2~4步，直到完成所有目標或者找不到解決方法。AutoGPT會不斷地重複第三步和第四步，直到回答完所有問題列表中的問題，並且所有回答都滿足使用者的任務指令中的目標；或者無法生成更多有效的問題列表，並且無法找到更多有效的資訊來源或者服務。此時，AutoGPT會結束任務，並將儲存在檔案中的所有回答輸出給使用者。
以上就是AutoGPT的原理，它利用了GPT-4強大的語言生成能力和其他服務豐富的資訊資源，實現了一種自 主執行任務的人工智慧應用程式。AutoGPT不需要使用者提供詳細的指令和提示，只需要設定總體目標，就可以讓AI自己去思考和行動，完成各種複雜和有價值的任務。

AutoGPT無限迴圈的終止機制

AutoGPT透過以下幾種機制來防止和終止無限迴圈：
1. 執行步數限制 (Step Limit)
  • AutoGPT設定了最大執行步數限制，通常預設為50-100步
  • 當達到預設的步數上限時，系統會自動停止執行
  • 使用者可以根據任務複雜度調整這個限制
2. 令牌使用限制 (Token Budget)
  • 設定API呼叫的令牌預算上限
  • 當消耗的令牌數量接近或達到預算時，系統停止執行
  • 防止因迴圈導致的過度API呼叫成本
3. 時間超時機制 (Timeout)
  • 設定任務執行的最大時間限制
  • 超過時間閾值後自動終止執行
  • 防止任務無限期執行
4. 迴圈檢測演算法
  • 狀態重複檢測: 監控系統狀態，如果連續幾次執行相同或相似的操作，會觸發迴圈警告
  • 行為模式識別: 分析執行序列，識別重複的行為模式
  • 目標完成檢查: 定期評估是否朝著目標前進
5. 人工干預機制
  • 手動停止: 使用者可以隨時手動終止執行
  • 確認模式: 在關鍵步驟需要人工確認才能繼續
  • 監控儀表板: 即時顯示執行狀態，便於監控
6. 智慧終止條件
  • 目標達成檢測: 當系統判斷目標已完成時自動停止
  • 無進展檢測: 如果連續幾步沒有實質性進展，觸發停止機制
  • 錯誤累積: 當錯誤次數超過閾值時停止執行
7. 資源消耗監控
  • 記憶體使用監控: 防止記憶體溢位
  • CPU使用率檢查: 避免系統資源耗盡
  • 磁碟空間檢查: 防止儲存空間不足

AutoGPT內建的Prompt系統

1.系統級內建Prompt
AutoGPT內建了多個核心prompt模板，用於指導AI的行為：
主系統Prompt
SYSTEM_PROMPT = """你是Auto-GPT，一個自主的AI助手。你的目標是：{ai_goals}你的角色是：{ai_role}約束條件：1. 只能使用提供的命令和工具2. 每次只執行一個命令3. 必須基於當前情況做出最佳決策4. 保持專注於目標5. 避免無限迴圈可用命令：{commands}資源限制：- 令牌預算：{token_budget}- 最大步數：{max_steps}"""
思考過程Prompt
THINKING_PROMPT = """當前情況分析：1. 我已經完成了什麼？2. 下一步需要做什麼？3. 哪個命令最適合當前情況？4. 執行後的預期結果是什麼？決策理由：基於以上分析，我選擇執行：{chosen_command}"""
2.任務特定Prompt模板
研究分析Prompt
RESEARCH_PROMPT = """作為研究分析師，請：1. 收集相關資訊：{topic}2. 驗證資訊的可靠性3. 分析關鍵要點4. 總結髮現和結論5. 提供可行的建議研究方法：- 使用多個可靠來源- 交叉驗證資訊- 保持客觀中立- 區分事實和觀點"""
3.命令執行Prompt
網路搜尋的prompt
WEB_SEARCH_PROMPT = """進行網路搜尋時：1. 使用精確的搜尋關鍵詞2. 評估搜尋結果的相關性3. 篩選可靠的資訊源4. 提取關鍵資訊5. 避免過時或不準確的資訊搜尋策略：- 組合多個關鍵詞- 使用引號精確匹配- 篩選時間範圍- 驗證資訊來源"""
4.自我反思Prompt
REFLECTION_PROMPT = """執行完成後的自我評估：執行結果：✅ 成功完成的任務：{completed_tasks}❌ 遇到的問題：{encountered_issues}🔄 需要重試的操作：{retry_needed}學習總結：1. 這次執行中學到了什麼？2. 哪些策略是有效的？3. 下次可以如何改進？4. 是否需要調整方法？下一步計劃：基於當前進展，下一步應該：{next_action}"""
5.錯誤處理Prompt
ERROR_HANDLING_PROMPT = """遇到錯誤時的處理策略：錯誤分析：- 錯誤型別：{error_type}- 錯誤原因：{error_cause}- 影響範圍：{impact_scope}解決方案：1. 立即處理方案：{immediate_solution}2. 替代方案：{alternative_approaches}3. 預防措施：{prevention_measures}學習記錄：將此錯誤及解決方法記錄，避免重複發生"""
6.Prompt最佳化特性
CONTEXT_MANAGEMENT = """上下文資訊管理：- 短期記憶：最近3-5步的執行歷史- 長期目標：始終保持對主要目標的關注- 環境狀態：當前工作目錄、可用資源等- 約束條件：時間、預算、許可權限制"""
Claude4.0
好吧，說到這裡如果現在Claude模型賦能該能力，可以進行深度研究模式，能直接解決我們現在的訴求，切換不同的模式滿足不同的需求，未來是必達的!
Claude4.0模型的釋出還是很鼓舞人心的！

新功能：
  • 擴充套件推理與工具呼叫功能（Extended thinking with tool use）：兩款新模型均可在進行深入思考時呼叫工具（如網頁搜尋），可在推理與工具使用之間切換，以提升回答質量
  • 新增模型能力：支援並行呼叫多個工具、更精準執行指令；若開發者開放本地檔案訪問許可權，Claude還能大幅提升記憶能力，提取並儲存關鍵事實，幫助模型保持上下文一致性並逐步構建隱性知識
  • Claude Code 正式釋出：在預覽階段獲得大量積極反饋後，擴充套件了開發者與Claude協作方式。現支援透過GitHub Actions後臺執行，並與VS Code和JetBrains原生整合，可在程式碼檔案中直接顯示修改，提升協作效率。
  • 新增API能力：Anthropic API推出四項新功能，助開發者構建更強大AI智慧體，包括程式碼執行工具、MCP聯結器、檔案API以及提示快取功能（最長可達1h）
Claude Opus 4與Sonnet 4屬混合型模型，支援兩種執行模式：
  • 即時響應
  • 深度推理
關於這兩種模式的解釋：Anthropic透過綜合方法解決了AI使用者體驗中的長期問題。Claude 4系列模型在處理簡單查詢時能夠提供接近即時的響應，對於複雜問題則啟動深度思考模式，有效消除了早期推理模型在處理基礎問題時的延遲和卡頓。這種雙模式功能既保留了使用者所期待的即時互動體驗，又能在必要時釋放深度分析能力。系統根據任務的複雜性動態分配計算資源，實現了早期推理模型難以達到的平衡。記憶的永續性是Claude 4系列的另一項重大突破。這兩款模型具備從文件中提取關鍵資訊、建立摘要文件的能力，並在獲得授權後實現跨會話的知識延續。這一能力攻克了長期制約AI應用的[記憶缺失]難題，使AI在需要持續數日或數週上下文關聯的長期專案中真正發揮其作用。這種技術實現方式與人類專家開發知識管理系統的方式相似，AI會自動將資訊整理成適合未來檢索的結構化格式。
透過這種方式，Claude 4系列模型能夠在長時間的互動過程中不斷深化對複雜領域的理解。
一鍵訓練大模型及部署GPU共享推理服務
透過建立ACK叢集Pro版，使用雲原生AI套件提交模型微調訓練任務與部署GPU共享推理服務。    
點選閱讀原文檢視詳情。

相關文章