AI編碼不是夢：手把手教你指揮Agent開發需求

前情介紹

AI已經持續火爆3年有餘了，相關知識及理論本文不再贅述。本文主要聚焦於AI實踐應用，首先從實操講起（可直接復刻），然後再是實踐背後的設計及思考，接著列舉了團隊在生產中的實踐案例，最後談談感想展望。

實踐場景：後端領域開發
AI編碼工具：可使用通義靈碼等（可在生成的rule資料夾下建立多規則並按需選擇，本文實踐由其他內部AI軟體進行）
AI大模型：Qwen-Max（編碼，預設模型）、Claude-4-Sonnet（生成工程結構）

實踐拆解

本章節以簡單的增刪改查為例來演示及說明AI在需求編碼中的實踐流程及應用，但並不意味著AI不能寫業務邏輯，實際上我們已上線的需求業務邏輯也都先由AI編碼完成。先睹為快（影片是一口氣錄製的，全程由AI完成編碼及檔案建立，無剪輯無快進）：

影片中AI編碼過程說明：介面定義->介面文件（至此再也不會成為開發瓶頸了）->建表shema（複製後可直接在DB控制檯透過建表語句執行建表）->持久化層->業務邏輯層->介面實現。實際研發中也是按照這個過程分開執行的，未來繼續探索更加絲滑的過程一體化編碼。

材料準備

1.技術方案：技術方案模版參考（見文末），AI編寫程式碼的依據，複製到釘釘文件編輯好後轉為markdown格式，專門建個目錄存放。

2.工程結構：程式碼工程的詳細目錄結構，藉助AI生成，用來指導AI將程式碼檔案放至合適的工程目錄下。

3.內部AI軟體（可使用通義靈碼等）：AI編碼工具，本文實踐使用的相關能力如下（具體介紹見官方文件）：

a.Agent：類似自然人，有大腦、有手、有腳，可自動完成各種動作。（與之對應是Chat，只有大腦，需要手動採納程式碼）

b.Copilot Rules：可用來沉澱Prompt、工程結構等可複用的相關資料，會在每次會話中作為上下文帶給大模型，以實現模型輸出可控及Prompt等資產共享。

i.User Rules：全域性Rules，在所有Agent及行內會話生效。

ii.Project Rules：工程級Rules，只在當前工程中生效，也是本文實踐使用重點。當前只有Always（一直生效）、Never（可手動選擇生效）兩種模式，相比Cursor有4種模式，但主打夠用，如何呢，又能怎！

接下來按照下述拆解步驟，可以盡情享受一邊喝茶一邊指揮AI牛馬來幹活的時刻了。

分層拆解

說明：本章節每個小結由3部分組成：Agent提示詞+Prompt Rule+AI輸出截圖，前2部分可直接複製，必要時進行微調即可。另外只有生成的工程結構的rule有必要設定為Always模式，其他rule均設定為Never，需要哪個選哪個。

工程結構

根據工程結構prompt生成當前工程的目錄結構

注意：claude-4-Sonnet生成的目錄結構是最全面且最準確的，其他模型怎麼調prompt都差點意思

幫我生成當前工程的資料夾目錄樹並用*中文註釋*，生成結果以*樹形結構*輸出：1. 排除target目錄和.git目錄，其他目錄保留。

2. 使用最高效的方式列出每個工程模組的資料夾目錄樹，直到葉節點資料夾，但又不能包含具體檔案。

3. 生成結果整合到一個”工程結構.aonerule“檔案中，並放在aone_copilot合適目錄下。------------------------------下面是其中一個模組輸出格式示例：fulfill-admin-service/ # 服務層模組，主要包含業務邏輯和服務配置。├── src/ ├── main/ ├── java/ └── com/ └── ifp/ └── service/ ├── config/ # 配置類 │ ├── diamod # diamod配置 │ ├── model # 資料模型配置 │ ├── resource # 資源配置配置 │ └── xstream # xstream配置 └── fbi/ # fbi類 └── resources/ # 資原始檔目錄 └── explain-mapping/ # 解釋對映配置

具體內容：

# IFP智慧運營平臺工程結構## 專案概述

本專案是一個基於Maven的多模組智慧運營平臺，主要用於履約管理、異常處理、機器人排程等業務功能。

## 工程結構樹```ifp-intelligent-ops/ # IFP智慧運營平臺根目錄├── .aone_copilot/ # Aone Copilot配置目錄│ └── rules/ # 規則配置檔案目錄├── APP-META/ # 應用元資料配置│ └── docker-config/ # Docker配置檔案目錄├── TRequest/ # 技術方案文件目錄├── shell/ # Shell指令碼目錄│ ├── batchRestart/ # 批次重啟指令碼│ └── cleanLog/ # 日誌清理指令碼├── fulfill-admin-adapter/ # 介面卡模組，負責外部系統介面適配│ └── src/│ └── main/│ └── java/│ └── com/│ └── ifp/│ └── adapter/│ ├── DTO/ # 資料傳輸物件│ ├── fbi/ # FBI相關適配│ └── touch/ # Touch系統適配├── fulfill-admin-archive/ # 歸檔模組，負責資料歸檔和歷史資料管理│ └── src/│ └── main/│ └── java/│ └── com/│ └── ifp/│ └── archive/│ ├── common/ # 歸檔公共元件│ ├── param/ # 歸檔引數│ └── service/ # 歸檔服務│ └── impl/ # 服務實現├── fulfill-admin-client/ # 客戶端模組，提供外部呼叫介面│ └── src/│ └── main/│ └── java/│ └── com/│ └── ifp/│ └── client/│ ├── constants/ # 客戶端常量│ ├── enums/ # 列舉定義│ ├── model/ # 資料模型│ │ ├── duty/ # 值班相關模型│ │ ├── fbi/ # FBI相關模型│ │ └── sls/ # SLS日誌相關模型│ ├── protocol/ # 協議定義│ │ ├── dto/ # 協議資料傳輸物件│ │ └── result/ # 協議返回結果│ ├── request/ # 請求物件│ ├── result/ # 返回結果│ ├── service/ # 客戶端服務介面│ └── util/ # 工具類├── fulfill-admin-common/ # 公共模組，包含通用元件和工具│ └── src/│ └── main/│ └── java/│ └── com/│ └── ifp/│ └── common/│ ├── constants/ # 系統常量│ ├── domain/ # 領域物件│ │ ├── service/ # 領域服務│ │ └── xflush/ # 重新整理相關│ ├── enums/ # 列舉定義│ ├── exception/ # 異常定義│ ├── switchcenter/ # 開關中心│ └── util/ # 通用工具類├── fulfill-admin-dal/ # 資料訪問層模組，負責資料庫操作│ └── src/│ └── main/│ ├── java/│ │ └── com/│ │ └── ifp/│ │ └── dal/│ │ ├── config/ # 資料庫配置│ │ ├── dao/ # 資料訪問物件│ │ │ ├── archive/ # 歸檔資料訪問│ │ │ ├── dump/ # 匯出資料訪問│ │ │ ├── ifp/ # IFP資料訪問│ │ │ │ └── basic/ # 基礎資料訪問│ │ │ ├── pos/ # POS資料訪問│ │ │ ├── query/ # 查詢資料訪問│ │ │ └── reboot/ # 重啟資料訪問│ │ ├── dataobject/ # 資料物件│ │ ├── mapper/ # MyBatis對映器│ │ └── model/ # 資料模型│ └── resources/│ ├── mappers/ # MyBatis對映檔案│ │ ├── ifp_service_center/ # IFP服務中心對映├── fulfill-admin-metaq/ # 訊息佇列模組，負責訊息處理│ └── src/

├── fulfill-admin-service/                     # 服務層模組，主要包含業務邏輯和服務配置

│ └── src/│ └── main/│ ├── java/│ │ └── com/│ │ └── ifp/│ │ └── service/│ │ ├── abnormal/ # 異常處理服務│ │ ├── biz/ # 業務服務│ │ ├── bizquality/ # 業務質量服務│ │ │ ├── operate/ # 操作相關│ │ │ └── strategy/ # 策略相關│ │ ├── config/ # 配置類│ │ │ ├── diamond/ # Diamond配置│ │ │ ├── model/ # 資料模型配置│ │ │ ├── resource/ # 資源配置│ │ │ └── xstream/ # XStream配置│ │ ├── eagleeye/ # 鷹眼監控服務│ │ ├── fbi/ # FBI服務│ │ ├── judge/ # 判斷服務│ │ │ ├── constants/ # 判斷常量│ │ │ └── rules/ # 判斷規則│ │ ├── model/ # 服務模型│ │ │ └── vo/ # 值物件│ │ ├── mq/ # 訊息佇列服務│ │ ├── protocol/ # 協議服務│ │ │ ├── business/ # 業務協議│ │ │ ├── impl/ # 協議實現│ │ │ └── param/ # 協議引數│ │ ├── provider/ # 服務提供者│ │ ├── proxy/ # 代理服務│ │ │ └── impl/ # 代理實現│ │ ├── qianwen/ # 千問AI服務│ │ ├── report/ # 報表服務│ │ │ ├── entity/ # 報表實體│ │ │ └── handler/ # 報表處理器│ │ ├── robot/ # 機器人服務│ │ │ ├── order/ # 訂單機器人│ │ │ ├── protocol/ # 機器人協議│ │ │ ├── schedule/ # 排程機器人│ │ │ └── slslog/ # SLS日誌機器人│ │ ├── schedulerx/ # SchedulerX排程服務│ │ ├── sls/ # SLS日誌服務│ │ │ ├── processor/ # 日誌處理器│ │ │ └── query/ # 日誌查詢│ │ ├── test/ # 測試服務│ │ ├── tt/ # TT工單服務│ │ └── util/ # 服務工具類│ └── resources/│ └── explain-mapping/ # 解釋對映配置├── fulfill-admin-start/ # 啟動模組，應用程式入口和Web資源│ └── src/│ ├── main/│ │ ├── java/│ │ │ └── com/│ │ │ └── ifp/│ │ │ └── start/│ │ │ ├── config/ # 啟動配置│ │ │ ├── controller/ # Web控制器│ │ │ │ ├── duty/ # 值班相關控制器│ │ │ │ ├── external/ # 外部介面控制器│ │ │ │ ├── fbi/ # FBI控制器│ │ │ │ ├── oms/ # OMS控制器│ │ │ │ ├── page/ # 頁面控制器│ │ │ │ ├── qianwen/ # 千問控制器│ │ │ │ ├── robot/ # 機器人控制器│ │ │ │ └── sls/ # SLS控制器│ │ │ └── interceptor/ # 攔截器│ │ └── resources/│ │ ├── static/ # 靜態資源│ │ │ ├── adminlte/ # AdminLTE主題│ │ │ │ ├── css/ # CSS樣式│ │ │ │ ├── js/ # JavaScript指令碼│ │ │ │ └── plugins/ # 外掛│ │ │ │ ├── font-awesome/ # FontAwesome圖示│ │ │ │ └── ionicons/ # Ionicons圖示│ │ │ ├── bootstrap/ # Bootstrap框架│ │ │ │ ├── css/ # CSS樣式│ │ │ │ ├── fonts/ # 字型檔案│ │ │ │ └── js/ # JavaScript指令碼│ │ │ ├── jquery/ # jQuery庫│ │ │ ├── jsoneditor/ # JSON編輯器│ │ │ │ └── img/ # 圖片資源│ │ │ └── main/ # 主要資源│ │ │ ├── css/ # CSS樣式│ │ │ ├── img/ # 圖片資源│ │ │ └── js/ # JavaScript指令碼│ │ └── velocity/ # Velocity模板│ │ ├── layout/ # 佈局模板│ │ └── templates/ # 頁面模板│ │ ├── modify/ # 修改頁面模板│ │ ├── outer/ # 外部頁面模板│ │ ├── querytool/ # 查詢工具模板│ │ └── stable/ # 穩定頁面模板│ └── test/│ ├── java/│ │ └── com/│ │ └── ifp/│ │ └── test/│ │ ├── autoconfig/ # 自動配置測試│ │ ├── diamond/ # Diamond測試│ │ └── sls/ # SLS測試│ └── resources/ # 測試資源└── fulfill-admin-test/ # 測試模組，包含整合測試和單元測試 └── src/ ├── main/ │ └── java/ │ ├── com/ │ │ ├── auto/ # 自動化測試 │ │ ├── dto/ # 測試DTO │ │ └── ifp/ # IFP測試 └── test/ ├── java/ │ └── com/ │ └── ifp/ │ ├── common/ # 公共測試 │ └── config/ # 配置測試 └── resources/ └── ddl/ # 資料庫DDL指令碼```## 模組說明### 核心業務模組- **fulfill-admin-service**: 核心業務邏輯層，包含機器人排程、異常處理、質量監控等主要功能- **fulfill-admin-dal**: 資料訪問層，負責與資料庫互動，支援多資料來源### 介面和適配模組 - **fulfill-admin-client**: 對外提供的客戶端SDK，包含介面定義和呼叫工具- **fulfill-admin-adapter**: 外部系統介面卡，負責與FBI、Touch等系統整合### 支撐模組- **fulfill-admin-common**: 公共工具和元件，提供通用功能支援- **fulfill-admin-start**: 應用啟動模組，包含Web介面和啟動配置- **fulfill-admin-archive**: 資料歸檔模組，負責歷史資料管理- **fulfill-admin-metaq**: 訊息佇列處理模組- **fulfill-admin-test**: 測試模組，包含整合測試和單元測試### 運維支援- **shell/**: 運維指令碼，包含應用重啟、日誌清理等自動化指令碼- **APP-META/**: 應用部署配置，包含各環境的Docker配置## 技術架構特點1. **分層架構**: 採用經典的分層架構模式，職責清晰2. **模組化設計**: 各模組獨立，便於維護和擴充套件3. **多資料來源支援**: 支援多個數據庫的資料訪問4. **訊息驅動**: 整合MetaQ訊息佇列，支援非同步處理5. **視覺化管理**: 提供Web管理介面，支援視覺化操作

1. 應用層

介面定義

參照三層架構，根據*介面定義prompt*的提示生成應用層的介面定義（包括出、入參定義），已存在的介面不要重複定義

【目標需求】

根據__技術方案文件__中“應用服務”章節的*服務介面*和*服務方法*，為每個服務介面都生成相應的介面類程式碼，同時確保介面設計符合SOLID原則（**應用層介面定義**）。

【設計要求】 1. **入參設計**：

     - 複雜入參：方法入參個數大於3個時，首先將引數封裝為 Request 字尾的複雜型別，然後再將 Request物件作為入參（比如 OrderRequest ），相同服務介面內方法的複雜入參須共享 OrderRequest。

- 簡單入參：方法入參個數小於等於3個時，直接使用原始引數作為入參。 2. **出參設計**： - 出參類以大寫 DTO 作為字尾，比如 OrderDTO（簡單型別除外，比如 Boolean）。 - 出參要合理且有意義，優先使用 Boolean 等簡單型別，禁止使用void型別。

     - 出參應使用 xxxResult 或 xxxResponse 型別再包裝作為方法完整出參，比如 `SingleResult<OrderDTO>`、`SingleResult<Boolean>`（需替換為實際輸入的合適程式碼類）。

3. **路徑要求**： - 介面路徑需符合__工程結構文件__中的規範，確保程式碼組織清晰。 4. **註釋要求**： - 所有介面和引數類均需新增 JavaDoc 標準中文註釋，說明其功能和用途。【實現步驟】1.**提取服務介面與服務方法** - 遵照事實：僅從__技術方案文件__提到的內容進行分析，不要編造內容。

   - 分析__技術方案文件__中的“應用服務”章節，列出所有服務介面及其對應的服務方法。每個服務介面應明確其職責範圍，服務方法則描述具體的操作或行為。

2.**設計引數類**

   - 根據服務方法的描述，參考“業務實體”章節設計入參Request類和出參DTO類，每個欄位都要加上 JavaDoc 標準的中文註解，不要省略或遺漏欄位。

     - 額外再追加欄位：`id`（主鍵）、`gmtCreate`（建立時間）、`gmtModified`（修改時間），日期型別統一為 `Date`。

- 使用 Lombok 的 `@Data` 註解DTO類和Request類，且實現 `java.io.Serializable`。3.**編寫介面程式碼** - 根據上文的分析，生成每個服務介面的類定義，並以 ServiceI 作為字尾。4.**路徑組織** - 確保介面路徑符合__工程結構文件__的規範要求。【輸出內容】

**根據<目標需求>嚴格按照上下文要求生成完整的目的碼，不要遺漏服務程式碼，也不要只給部分示例**

-**入參類程式碼**：符合上文要求的入參Request類實現程式碼。-**出參類程式碼**：符合上文要求的出參DTO類實現程式碼。-**介面程式碼**：按照上文要求生成每個服務介面的類定義，服務介面間相互獨立。

介面文件

根據*介面文件prompt*和選擇的類檔案及相關程式碼，依次為選擇的類檔案生成每個介面方法的完整介面文件，不能假設不存在的欄位

# 任務目標：

你擅長根據程式上下文及開啟的檔案分析方法的簽名結構，包括引數類的繼承、組合等複雜關係。請根據方法簽名生成詳細的介面資訊。

# 要求及約束：

* 介面的出參、入參以json格式輸出。如果引數類有繼承、組合關係，生成的json也應該包含繼承、組合類的欄位，否則只需包含自身的欄位；

* 嚴格根據方法簽名及出入引數生成要求內容，不要做假設和猜測，也不要遺漏引數中的欄位。

# 輸出內容：1. 介面簽名及描述2. 介面入參：嚴格按照引數定義的欄位解析並輸出，不允許自定義欄位3. 接口出參：嚴格按照引數定義的欄位解析並輸出，不允許自定義欄位# 輸出內容示例：1. 介面簽名及描述* 簽名：long com.ifp.client.service.BizQualityMonitorService.addDO(BizQualityMonitorDTO bizQualityMonitorDTO)* 描述：新增業務監控規則2. 介面入參{"bizQualityMonitorDTO": {"gmt_create": "2025-01-01 12:34:56","gmt_modified": "2025-0-01 12:34:56","type": "型別","team": "團隊" }}3. 接口出參{"success": true,"errorCode": "","errorMessage": "","data": {"id": 1,"data_source_id": 10,"data_source_name": "資料來源名稱","field_name": "欄位名稱","field_desc": "欄位描述","owners": "owner","report_link": "報表連結","report_tab": "報表tab","attribute": "擴充套件屬性" }}

介面實現

參照三層架構，根據*介面實現prompt*及相關程式碼實現應用層*服務包管理*功能模組，應用層介面定義已存在

【目標需求】

根據__技術方案文件__中“應用服務”章節的*方法流程描述*和*校驗約束*，請實現使用者輸入的功能模組（**應用層介面實現**）。程式碼實現需要滿足良好的效能、健壯性和可讀性要求，同時遵循程式碼規範和工程結構。

【任務清單】

1. 分析服務方法：分析<目標需求>包含哪些方法，每個方法的具體流程描述和校驗約束是什麼。

2. 方法校驗約束分析：針對每個方法，分析其實現過程中需要滿足的校驗約束。3. 程式碼實現：按照以下要求完成<目標需求>的程式碼實現。【具體要求】1. 方法定義與校驗約束分析* 遵照事實：僅從__技術方案文件__提到的內容進行分析，不要編造內容。

* 列出所有方法：提取<目標需求>的所有方法，併為每個方法提供清晰詳細的描述， 不要輸出與<目標需求>無關的方法。

* 明確校驗約束：分析每個方法在實現過程中需要滿足的校驗約束（如引數校驗、資料校驗、許可權校驗等）。

2. 程式碼實現要求* 優先使用已有依賴：在實現過程中，優先複用已有的類或工具方法，避免重複造輪子。

* 物件轉換方法：如果涉及物件之間的轉換，請編寫專門的轉換方法，確保欄位對映完整，不要遺漏欄位。禁止使用 BeanUtils 或類似工具。

* 路徑規範：參考__工程結構文件__，將程式碼檔案放置到合適的路徑下，優先選擇已存在的路徑，確保模組劃分清晰。

* 引數校驗：入參欄位為字串時優先使用 `org.apache.commons.lang3.StringUtils` 工具校驗。

* 註釋標準：所有程式碼檔案必須新增符合 JavaDoc 標準的註釋，包括類註釋、方法註釋以及關鍵邏輯的行內註釋。

3. 編碼規範* 命名規範：

  * 變數名、方法名和類名應具有語義化，避免使用無意義的縮寫，DO、DTO、VO等專有詞彙保持大寫。

* 介面的實現類名以 ServiceImpl 作字尾。* 程式碼格式：遵循團隊統一的程式碼格式規範（如縮排、空格、換行等）。* 註釋清晰：對於複雜的邏輯，務必新增清晰的註釋說明其目的和實現方式。4. 編碼質量* 效能與健壯性： * 確保程式碼具有良好的效能，避免不必要的計算或查詢。 * 新增必要的異常處理邏輯，提升程式碼的健壯性。* 可讀性： * 確保程式碼具有良好的易讀性、簡單性以及最短層級巢狀。* 日誌記錄：

    * 方法體使用 trycatch 包裹整個程式碼塊，且在異常日誌中要列印異常物件，catch 後不要再向外拋異常。

    * 新增必要的中文日誌，日誌內容應包含問題定位的關鍵資訊，例如：異常原因、方法入參和出參、異常堆疊等，複雜型別使用 JSON.toJSONString 工具轉換為字串。

    * 日誌格式要清晰易懂，包含異常堆疊的日誌示例程式碼，`logger.error("簽約失敗，異常資訊：{}，paramId：{}，param：{}”, e.getMessage(), paramId, JSON.toJSONString(param), eStack)`。其中`param`代表複雜引數，`eStack`代表異常堆疊，編碼中需要將param*等字元替換為實際方法引數名稱。

【交付物】完整的<目標需求>程式碼實現，包括符合要求的日誌等，禁止使用虛擬碼以及省略程式碼。

2. 資料層

建表schema

根據*建表prompt*幫我生成技術方案中相關實體的建表schema

根據__技術方案文件__中的“業務實體”章節幫我建表，欄位id、gmt_create、gmt_modified預設新增,並參考以下建表語句：

CREATETABLE biz_quality_monitor(id bigint(20) unsigned NOTNULL AUTO_INCREMENT COMMENT '主鍵',gmt_create datetime NOTNULL COMMENT '建立時間',gmt_modified datetime NOTNULL COMMENT '修改時間',type varchar(32) NOTNULL COMMENT '資料來源型別',team varchar(32) NOTNULL COMMENT '團隊名稱',data_source_id bigint(20) NOTNULL COMMENT '資料來源id',data_source_name varchar(64) NOTNULL COMMENT '資料來源名稱',field_name varchar(64) NOTNULL COMMENT '欄位名稱',field_desc varchar(64) NOTNULL COMMENT '欄位描述',owners varchar(256) NOTNULL COMMENT '負責任，格式：花名-工號，多個用英文逗號隔開',report_link varchar(256) DEFAULTNULL COMMENT '報表連線',report_tab varchar(128) DEFAULTNULL COMMENT '資料來源所在報表位置，格式：報表名-tab名',attribute text COMMENT '擴充套件欄位',PRIMARY KEY (id),KEY idx_team (team),KEY idx_source_id (data_source_id),KEY idx_gmt_create (gmt_create)) ENGINE=InnoDB AUTO_INCREMENT=1DEFAULT CHARSET=utf8mb4 COMMENT='業務質量預警規則';

持久化DAO

根據*持久化prompt*幫我生成資料訪問層相關程式碼，下面是建表schema：

— 服務包表（替換成自己的表schema）

CREATE TABLE service_package (

id bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵',

gmt_create datetime NOT NULL COMMENT '建立時間',

gmt_modified datetime NOT NULL COMMENT '修改時間',

package_id bigint NOT NULL COMMENT '服務包ID',

name varchar(255) NOT NULL COMMENT '名稱',

description text COMMENT '描述',

type varchar(255) NOT NULL COMMENT '型別: 超客、自配送、平臺配送',

PRIMARY KEY (id),

UNIQUE KEY unique_package_id (package_id),

KEY idx_type_name (type, name)

) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='服務包表';

# 你是java領域專家，擅長mysql及mybatis，請根據使用者提供的建表schema生成包含CRUD操作的mapper.xml、Mapper.java及DO.java檔案。

# 下面是一個樣例，輸入或者選中：CREATE TABLE `question_exercise` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵', `gmt_create` datetime NOT NULL COMMENT '建立時間', `gmt_modified` datetime NOT NULL COMMENT '修改時間', `type` varchar(32) NOT NULL COMMENT '型別', `user_id` varchar(32) NOT NULL COMMENT '使用者id', `user_nick` varchar(32) NOT NULL COMMENT '使用者nick', `team` varchar(64) NOT NULL COMMENT '團隊名稱', `question_code` varchar(32) NOT NULL COMMENT '問題編碼', `question` varchar(256) NOT NULL COMMENT '問題描述', `answer` varchar(2048) DEFAULT NULL COMMENT '回題答案', `score` decimal(10,2) DEFAULT NULL COMMENT '答題得分', `attribute` varchar(4096) DEFAULT NULL COMMENT 'json擴充套件欄位', `status` varchar(32) NOT NULL DEFAULT 'INIT' COMMENT '狀態', PRIMARY KEY (`id`), KEY `idx_gmt_type_team` (`gmt_create`,`type`,`team`), KEY `idx_user_id` (`user_id`), KEY `idx_status_type_gmt` (`status`,`type`,`gmt_create`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='問答得分表'# 輸出1. com.ifp.dal.model.QuestionExerciseDO.javapackage com.ifp.dal.model;import lombok.Data;import java.io.Serializable;import java.math.BigDecimal;import java.util.Date;/** * @author AI * @date 2025/01/01 */@DatapublicclassQuestionExerciseDOimplementsSerializable { privatestaticfinallong serialVersionUID = -1L; /** * 主鍵 */ private Long id; /** * 建立時間 */ private Date gmtCreate; /** * 修改時間 */ private Date gmtModified; /** * 型別 */ private String type; /** * 狀態 */ private String status; /** * 使用者id */ private String userId; /** * 使用者nick */ private String userNick; /** * 團隊名稱 */ private String team; /** * 問題編碼 */ private String questionCode; /** * 問題描述 */ private String question; /** * 回題答案 */ private String answer; /** * 得分 */ private BigDecimal score; /** * json擴充套件欄位 */ private String attribute;}2. com.ifp.dal.mapper.QuestionExerciseMapper.javapackage com.ifp.dal.mapper;import com.ifp.dal.model.QuestionExerciseDO;import org.apache.ibatis.annotations.Mapper;import org.apache.ibatis.annotations.Param;import java.util.List;/** * @author AI * @date 2025/01/01 */@Mapperpublic interface QuestionExerciseMapper { /** * 新增 * @param questionExerciseDO DO物件 * @return 返回插入資料條數 */ intinsert(QuestionExerciseDO questionExerciseDO); /** * 根據id查詢 * @param id 主鍵id * @return 返回結果 */ QuestionExerciseDO getById(@Param("id") Long id); /** * 根據key查詢 * @param gmtCreate 建立時間 * @param type 型別 * @param team 團隊 * @param userId 使用者ID * @param status 狀態 * @return 返回結果 */ List<QuestionExerciseDO> getByKey(@Param("gmtCreate") Date gmtCreate, @Param("type") String type, @Param("team") String team, @Param("userId") String userId, @Param("status") String status); /** * 根據id更新資料 * @param questionExerciseDO DO物件 * @return 返回結果 */ intupdateById(QuestionExerciseDO questionExerciseDO); /** * 根據ids物理刪除 * @param ids 主鍵列表 * @return 返回結果 */ intdeleteByIds(@Param("ids") List<Long> ids);}3. question-exercise.xml<?xml version="1.0" encoding="UTF-8" ?><!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN""http://mybatis.org/dtd/mybatis-3-mapper.dtd"><mapper namespace="com.ifp.dal.mapper.QuestionExerciseMapper"> <resultMap type="com.ifp.dal.model.QuestionExerciseDO"id="questionExerciseDO"> <result column="id" property="id" /> <result column="gmt_create" property="gmtCreate" /> <result column="gmt_modified" property="gmtModified" /> <result column="type" property="type" /> <result column="status" property="status" /> <result column="user_id" property="userId" /> <result column="user_nick" property="userNick" /> <result column="team" property="team" /> <result column="question_code" property="questionCode" /> <result column="question" property="question" /> <result column="answer" property="answer" /> <result column="score" property="score" /> <result column="attribute" property="attribute" /> </resultMap>  <sql id="questionExerciseDO_columns">id,gmt_create,gmt_modified,type,status,user_id,user_nick,team,question_code,question,answer,score,attribute </sql>

    <insert id="insert" parameterType="com.ifp.dal.model.QuestionExerciseDO" useGeneratedKeys="true" keyProperty="id">

        insert into question_exercise(gmt_create,gmt_modified,type,status,user_id,user_nick,team,question_code,question,answer,score,attribute)

        values(CURRENT_TIMESTAMP(3),CURRENT_TIMESTAMP(3),#{type},#{status},#{userId},#{userNick},#{team},#{questionCode},#{question},#{answer},#{score},#{attribute})

</insert> <selectid="getById" resultMap="questionExerciseDO" parameterType="java.util.Map">select <include refid="questionExerciseDO_columns"/> from question_exercisewhereid = #{id} </select> <selectid="getByKey" resultMap="questionExerciseDO" parameterType="java.util.Map">select <include refid="questionExerciseDO_columns"/> from question_exercise WHERE 1=1 <iftest="gmtCreate != null"> and gmt_create >= #{gmtCreate} </if> <iftest="type != null"> and type = #{type} </if> <iftest="team != null"> and team = #{team} </if> <iftest="userId != null"> and user_id = #{userId} </if> <iftest="status != null"> and status = #{status} </if> </select> <update id="updateById" parameterType="com.ifp.dal.model.QuestionExerciseDO"> update question_exerciseset gmt_modified = CURRENT_TIMESTAMP(3) <iftest="type != null"> ,type = #{type} </if> <iftest="status != null"> ,status = #{status} </if> <iftest="userId != null"> ,user_id = #{userId} </if> <iftest="userNick != null"> ,user_nick = #{userNick} </if> <iftest="team != null"> ,team = #{team} </if> <iftest="questionCode != null"> ,question_code = #{questionCode} </if> <iftest="question != null"> ,question = #{question} </if> <iftest="answer != null"> ,answer = #{answer} </if> <iftest="score != null"> ,score = #{score} </if> <iftest="attribute != null"> ,attribute = #{attribute} </if> WHERE id=#{id} </update> <delete id="deleteByIds" parameterType="java.util.Map"> DELETE FROM question_exercise WHERE idin <foreach item="item" index="index" collection="ids" open="(" separator="," close=")">#{item} </foreach> </delete></mapper># 要求：1. 嚴格參照上面樣例，禁止簡化生成的內容。2. 生成的檔案路徑需符合__工程結構文件__中的路徑規範，確保程式碼組織清晰。3. 給出檔案的名稱。

3. 業務邏輯層

根據*業務層prompt*及相關程式碼幫我實現業務邏輯層*服務包管理*領域服務模組

【目標需求】

根據__技術方案文件__中“領域功能”章節的*功能描述*和*規則約束*，請實現使用者輸入的功能模組（**業務邏輯層**）。程式碼實現需要滿足良好的效能、健壯性和可讀性要求，同時遵循程式碼規範和工程結構。

【任務清單】1. 分析功能需求：分析<目標需求>包含哪些功能，每個功能的具體描述和規則約束是什麼。2. 功能規則約束分析：針對每個功能，分析其實現過程中需要滿足的規則約束。3. 程式碼實現：按照以下要求完成<目標需求>的程式碼實現。【具體要求】1. 功能定義與規則約束分析* 遵照事實：僅從__技術方案文件__提到的內容進行分析，不要編造內容。

* 列出所有功能：提取<目標需求>的所有功能點，併為每個功能提供清晰詳細的描述， 不要輸出與<目標需求>無關的功能。

* 明確規則約束：分析每個功能在實現過程中需要滿足的規則約束（如許可權控制、業務邏輯、規則條件等）。

2. 程式碼實現要求* 優先使用已有依賴：在實現過程中，優先複用已有的類或工具方法，避免重複造輪子。

* 物件轉換方法：如果涉及物件之間的轉換，請編寫專門的轉換方法，確保欄位對映完整，不要遺漏欄位。禁止使用 BeanUtils 或類似工具。

* 路徑規範：參考__工程結構文件__，將程式碼檔案放置到合適的路徑下，優先選擇已存在的路徑，確保模組劃分清晰。

* 註釋標準：所有程式碼檔案必須新增符合 JavaDoc 標準的註釋，包括類註釋、方法註釋以及關鍵邏輯的行內註釋。

* 引數要求：

  * 入參規範：入參超過3個時需要使用封裝後的型別作為入參，比如相關實體的DO型別，避免使用Map型別。

  * 出參規範：出參必須要有意義，避免使用void型別（優先使用boolean型別），不需要額外封裝。

3. 編碼規範* 命名規範：

  * 變數名、方法名和類名應具有語義化，避免使用無意義的縮寫，DO、DTO、VO等專有詞彙保持大寫。

* 介面類名以 DomainServiceI 作字尾，實現類名以 DomainServiceImpl 作字尾。* 程式碼格式：遵循團隊統一的程式碼格式規範（如縮排、空格、換行等）。* 註釋清晰：對於複雜的邏輯，務必新增清晰的註釋說明其目的和實現方式。4. 編碼質量* 效能與健壯性： * 確保程式碼具有良好的效能，避免不必要的計算或查詢。

    * 新增必要的異常處理邏輯，以提升程式碼的健壯性，異常資訊要具有明確的中文語義，直接 throw 即可。

* 可讀性： * 確保程式碼具有良好的易讀性、簡單性以及快速返回原則。【交付物】

* 符合上文要求的領域服務功能的介面定義和完整程式碼實現，禁止使用虛擬碼以及省略程式碼。

* 標準的 JavaDoc 中文註釋。

Tips

1.關於代生成質量：

a.如果生成結果與預期相差較大，請再試一次，基本2次內即可滿足期望；

b.透過多輪次對話，提出明確的修改要求；

c.明確選擇主要相關程式碼檔案作為模型上下文；

d.及時清理歷史會話，避免影響模型下次輸出，同時可節省token；

e.緊貼自己的工程特點微調Prompt Rule。

2.關於工程目錄結構：

a.請使用Claude-4-Sonnet模型；

b.如果生成的結構不符合預期，請單獨為每個模組生成工程結構，然後合併為整體；

c.如果生成的程式碼放置的位置不對，請為工程結構目錄補充更詳細的介紹說明，特別注意區分相似目錄。

實踐思考

怎麼讓AI更加絲滑的高效產出高質量的需求程式碼呢？本章節圍繞上述實踐試著從研發流程及架構設計視角來闡述背後的思考及設計。

實際應用Gap

自從AI編碼火爆以來，特別是Cursor、Devin的出現，一句話需求、程式設計師被AI取代等訊息如雨後春筍般鋪天蓋地，一時間讓程式設計師們無所適從，焦慮感油然而生。誠然，AI編碼可以很快速的完成原型實現及想法驗證，那麼實際應用過程中真的如此絲滑嗎，又會面臨哪些問題呢？

1.大模型天然具有幻覺，生成的程式碼質量不可控；

2.業務需求和系統行為的確定性，需要嚴格可控；

3.生產開發基本是基於已有系統做迭代開發，需要考慮現有系統的相容性、複用性等；

4.現實世界更復雜：多樣性、緊密聯絡性、更抽象也更細微。

研發流程說起

縱觀以上研發流程，由下而上，抽象層度越來越高，不確定性也越來越高，溝通協作等軟能力要求也越來越高，而這些正是AI不擅長的；另一方面考慮到任務拆解及提效顆粒度問題，太粗AI效果不好，太細提效又不明顯，發揮不出AI的威力。

解決的問題

基於以上AI程式設計的能力邊界分析，我們需要：

1.在確定性和不確定性之間尋找生產研發提效的最佳平衡點。

2.尋找研發提效的最大顆粒度，行級別？程式碼塊級別？類級別 or 專案級別？

確定平衡點

需求階段：涉及大量的需求理解，需要不斷的多輪次的溝通才能一步步明確需求流程和需求規則。人類的語言又具有多樣性，同樣的用詞不同的場合、不同的語調意思可能完全不一樣，這個階段在AI當前的發展階段顯然不適合。
架構設計階段：這個階段需求基本已經明確，更多要考慮的是跟當前系統相容、複用性、編髮規範等非功能需求，還是需要人來嚴格把控設計。
程式碼設計階段：這個階段功能性需求與非功能需求均已明確，更多需要做的是提出規範及要求。

最大提效粒度

程式碼設計階段：至於說一個功能拆幾個函式實現，用什麼類庫之類的可以讓AI自由發揮，我們要做的是確保AI產出的程式碼符合我們的程式碼設計的規範及要求。
編碼階段：這個階段已經到了具體的函式級別，對於AI來講控的太細了，發揮不了AI威力。

綜上，我們選擇將“程式碼設計階段”作為分割點，以上工作由自然人來負責，以下可以交給AI自由發揮。

解決的方案

試想下，假如我們需要我們的同事配合做一些事情，我們需要做什麼？首先要找對人（立人設），其次：1. 交代背景；2.交代目標；3.交代要求；事實上，AI就可以看成我們的同事，與AI對話就像與人對話一樣，我們交代的越清楚，它反饋給我們的結果也就越明確，甚至有時候需要反覆多輪溝通。

有了上述分析，我們的方案也顯而易見：

1.透過技術方案模版將業務需求的不確定性轉變為實現方案的確定性；

2.考慮到AI生成的程式碼與當前工程結構的適配性，我們需要交代當前系統的工程結構；

3.結合技術方案、工程結構，透過跟AI溝通（Prompt提示詞）把我們的實現目標和要求交代清楚。

接下來我們針對三層架構（符合我們當前團隊幾乎所有應用的分層架構）進行落地實踐的分析設計：

1. 技術方案模版

為什麼要設計模版，模版的作用是用來約束開發者，按照一定的規範來分析拆解，也可以理解成它是我們跟AI之間溝通的語言協議，保證了文件設計的質量，也就保障了我們輸入給AI的背景資訊。

我們透過技術方案模版設計的規範約束，來描述清楚需求的業務功能及架構分層，包括以下章節：

1.專案資料：主要是為了沉澱專案背景知識，方便後來人瞭解；

2.需求價值：靈魂自問，對齊團隊OKR；

3.需求分析：自己對需求的概要理解；

4.術語解釋：專有名詞解釋，便於AI理解專業術語；

5.業務實體：對應三層架構的資料層，職責：ORM對映，持久化實體；

6.領域功能：對應三層架構的業務邏輯層，職責：封裝領域內業務邏輯和業務規則，沉澱業務知識，遵守領域內開閉原則；

7.應用服務：對應三層架構的應用層，職責：對外提供服務介面，組裝業務流程，模型轉換，必要的引數校驗、事務及異常處理。

2. 系統工程結構

我們的系統經過一代又一代人的不斷努力和迭代，傳到我們這代的時候可能早就說不清楚每個目錄結構是幹什麼的了。不過幸運的是AI可以理解整個程式碼倉庫，可以幫助我們生成整個系統的工程結構，然後再稍作調整即可，特別是針對相似的目錄結構。

3. Prompt分層

Prompt設計這裡面又大有文章了，有一種職業叫做Prompt工程師。它好比演算法工程師的調參，直接關係到AI輸出的效果好壞。當前Prompt設計有很多正規化，並沒有一種設計能適應各個場景，但本質不變：好比人與人之間的交流，需要明確跟誰交流（角色）、背景是什麼（背景）、有什麼要求（要求）、想要達到怎樣的目標（目標）。

分層結構化擴充套件：明確了Prompt設計要素（角色、背景、目標、要求），最關鍵的就是結構化Prompt，類似我們的架構設計，Prompt也分了三層，針對每層的特點又進行結構化，方便進行區域性調優和擴充套件。介面定義的Prompt栗子：

架構規範融入：另外一個很大的好處，我們可以把我們的設計理念，如架構設計、編碼規範、質量規範等放都在Prompt，AI會很聽話的能夠按照這些規範編寫程式碼，這在以往也是很難做到的。
沉澱複用：根據工程特性，在這套Prompt提示詞基礎上經過些許微調，沉澱為整個工程系統的Prompt，這樣相關開發人員可直接使用，避免了Prompt的多次開發和調優，可隨程式碼一起釋出至git倉庫。

上述方案中，工程結構及Prompt可直接共享並適時加以迭代，研發的工作重點更多的聚焦在了對業務需求邏輯的理解。

生產案例

透過類似AI編碼方式，目前已上線需求3個，開發中2個，架構重構中1個。採納行佔比由4月份的8.9%提升至6月份的44.7%（官方統計口徑），實際會有些虛高。下面列舉3個案例簡要說明：

案例1：低起送價轉C配

專案背景：商家設定了起送價，但使用者訂單金額低於起送價，需要支付一定的配送費，產品上需要新建低起送價運營平臺。

功能說明：

1.數層新增表5張；

2.5個領域服務的增刪改查及相關業務邏輯。

AI程式碼生成佔比：保守估約70%+。

案例2：零售服務包推薦

專案背景：為商戶推薦優質服務包及推薦語，並記錄推薦服務呼叫現場。

功能說明：

1.數層新增表1張；

2.1個現有領域服務邏輯修改。

AI程式碼生成佔比：保守估約50%+。

案例3：淘天逆向催支付

專案背景：淘天逆向商戶存在大量退貨已完結訂單，但使用者未支付物流費用的情況，直接影響了蜂鳥的收入，需要實現針對淘天逆向使用者的簡訊催支付功能。

功能說明：

1.1個領域服務邏輯；

2.3個外部介面依賴。（需要在已有的技術方案和Prompt基礎上增加“外部介面”依賴模組標準）

AI程式碼生成佔比：保守估約70%+。

感想展望

AI First

在團隊佈道過程中，聽到太多質疑聲，特別是講到AI可以寫業務邏輯，大家的第一反應基本都是：這玩意能寫業務邏輯？它怎麼知道如何寫？寫錯了線上故障算誰的？改它寫程式碼的時間比我自己寫的時間還要多！But，這些都存在於未開始時的想象和質疑，大家應該能夠多少感受到AI發展之快、熱度之高、之持久。時代在快速進步，試問我們還有退路嗎，但無論如何，最重要的是開始並參與其中！踐行 AI Firsrt！

程式設計師發展

毫無疑問，AI程式設計對程式設計師這個職業的衝擊很大，任何新興技術帶來一批淘汰是不可避免的，但它也會催生一批新的生產力，我們要做的就是迎著時代的發展，不斷提高自身的能力，掌握並用好AI，讓它成為我們的有力生產力。從上述的實踐案例也可以窺探一二，未來基礎的編碼工作主要由AI來承擔，程式設計師需要向更高階的能力發展，如業務理解、架構設計等。不管怎樣，Just do it，才不會患上AI焦慮症！

未來規劃

從研發流程看，可嘗試探索更高階的AI輔助架構設計、技術方案生成、PRD規劃等。

從自動化程度看，未來可整合各個分層任務，合併生成更加連貫更加自動化的長任務。

從增改場景看，本文的實踐主要聚焦於程式碼新增。修改已有程式碼風險高、提效有限，但依然有機會沉澱適當Prompt。

技術方案模板參考

AI編碼配套的三層架構的技術方案模版，一方面控制任務拆分粒度，另一方面幫助理解業務邏輯及系統架構。

1. 不需要的部分留白即可，文件內容僅模版示例，需要根據自己的需求進行分析改寫。

2. 修改類的小需求，沒必要按照此模版來寫，可直接在Agent視窗描述業務邏輯及要求。

3. 同一個需求的不同迭代，可在技術方案名稱上加上迭代日期作為版本區分。