最近一段時間我一直想把后臺管理系統(tǒng)里那些機械重復(fù)的增刪改查代碼交給AI去寫?？蚣苡玫氖侨粢腊蠢碚f這類業(yè)務(wù)代碼模式非常固定應(yīng)該是AI最擅長的事情?？烧嬖囅聛韰s不是那么回事——你讓AI生成一個用戶管理模塊它給出的Controller方法命名一會兒對一會兒錯Mapper XML動不動少一段resultMap前端頁面更是經(jīng)常跟菜單配置對不上。反復(fù)調(diào)提示詞折騰了好幾個版本效果始終不穩(wěn)定。后來我換了個思路不再把需求當作一次性對話丟給AI而是把“寫若依代碼”這件事整體打包成一個Agent Skill。配合我自己總結(jié)的黃金三層結(jié)構(gòu)來做內(nèi)部設(shè)計再用一套五步法逐步打磨AI輸出的代碼質(zhì)量一下子穩(wěn)定了很多基本能直接進編譯環(huán)節(jié)。這篇文章就把這套方法完整拆開講包括三層結(jié)構(gòu)里每一層該放什么內(nèi)容、五步法落地時的具體操作以及我在實測過程中反復(fù)踩過的坑。1. 直接讓AI寫若依代碼為什么總是差一口氣先聊聊為什么原來的方式不work。很多人跟我一開始一樣把建表語句貼在對話框里然后寫一大段“幫我生成若依的增刪改查”AI確實能給你吐出一堆代碼看著結(jié)構(gòu)挺完整可用起來就露餡了。1.1 一次性提示詞的三個死穴第一個問題是規(guī)則沒有顯式化。若依框架看著簡單里面的隱含約定非常多Service接口要帶I前綴Mapper接口和XML的namespace必須全限定名對應(yīng)Controller繼承BaseController之后返回AjaxResult還是TableDataInfo有嚴格區(qū)分。這些規(guī)則分散在AI的“印象”里而不是你的提示詞里它就很容易憑感覺輸出。第二個問題是流程不可控。生成代碼本身是有順序的先分析表結(jié)構(gòu)再做類型映射然后生成實體類再生成Mapper、Service、Controller最后才是前端頁面和SQL腳本。如果你不把順序定死AI經(jīng)常東一榔頭西一棒子生成到一半還會自己“優(yōu)化”掉某些步驟。第三個問題是經(jīng)驗無法沉淀。就算你一次性調(diào)出了好結(jié)果下次換一張表、換一個對話一切重新碰運氣。你在調(diào)試過程中積累的那點修正經(jīng)驗全留在聊天記錄里沒變成可復(fù)用的資產(chǎn)。1.2 把“問AI要答案”變成“讓AI調(diào)技能”對比一下直接對話和Skill方式的差異我用一張表來說明對比項直接對話方式Agent Skill方式輸出穩(wěn)定性換一次上下文就飄規(guī)范固定在Skill內(nèi)部穩(wěn)定輸出若依規(guī)則掌握時好時壞靠運氣規(guī)則顯式寫入規(guī)范層強制執(zhí)行復(fù)用成本每次重新描述需求一次構(gòu)建長期復(fù)用質(zhì)量保障憑輸出后人工檢查Skill自帶自查清單生成時同步檢查擴展能力換個框架或風(fēng)格等于重來維護多個Skill即可應(yīng)對不同場景Skill的本質(zhì)是把一套“怎么做好某件事”的經(jīng)驗結(jié)構(gòu)化讓AI在調(diào)用時嚴格按照這套結(jié)構(gòu)來執(zhí)行。它不是一段簡單的提示詞而是包含觸發(fā)條件、執(zhí)行流程、規(guī)范約束、示例樣例的完整“技能包”。所以我現(xiàn)在不跟AI說“幫我寫個訂單模塊”而是把一個寫好的單表CRUD生成Skill掛載好然后把表結(jié)構(gòu)丟給它。2. 黃金三層結(jié)構(gòu)拆解一個若依生成Skill的內(nèi)部構(gòu)造我總結(jié)的三層結(jié)構(gòu)分別解決三個問題什么時候調(diào)用這個技能、按什么步調(diào)做事、用什么風(fēng)格產(chǎn)出。這三層缺一不可我管它們叫技能描述層、流程編排層、規(guī)范與樣例層。2.1 第一層技能描述層這一層說白了就是Skill的“門面”。它要讓AI和人都能一眼看懂這個技能管什么、不管什么、需要什么輸入、產(chǎn)出什么結(jié)果。我一般用類似下面的內(nèi)容填充這一層name: ruoyi-single-table-crud description: 根據(jù)數(shù)據(jù)庫建表語句生成若依框架下單表CRUD全套代碼。 適用于業(yè)務(wù)模塊的后臺管理功能輸出后端分層的Java代碼、前端Vue頁面和菜單SQL。 不適用于復(fù)雜業(yè)務(wù)邏輯、流程審批、主子表結(jié)構(gòu)。 input: table_name: 數(shù)據(jù)庫表名例如 biz_order table_comment: 表業(yè)務(wù)注釋例如 訂單信息表 columns: - field: 字段英文名 type: 數(shù)據(jù)庫字段類型 comment: 字段注釋 required: 是否必填 optional: author: 代碼作者注釋默認 某開發(fā)者 output: - BizOrder.java 實體類 - BizOrderMapper.java 與 BizOrderMapper.xml - IBizOrderService.java 與 BizOrderServiceImpl.java - BizOrderController.java - index.vue 與 form.vue 頁面文件 - menu.sql 菜單初始化SQL你別小看這一層。AI拿到你的Skill時首先讀的就是這段描述。如果描述里沒有明確“只處理單表”遇到主子表結(jié)構(gòu)它就會不管三七二十一硬上最后生成一堆沒法看的代碼。邊界寫得越清楚AI越不會越界操作。2.2 第二層流程編排層第二層負責(zé)把生成過程變成一步步可執(zhí)行的流水線。生成Java代碼這件事最怕AI跳步驟。比如實體類還沒定好它就先寫了Mapper XML結(jié)果字段一對不上。我的流程編排層長這樣解析建表語句提取表名、表注釋、所有字段的名稱、類型、注釋與主鍵。將數(shù)據(jù)庫字段類型映射為Java類型并確定實體屬性命名。按順序生成實體類、Mapper接口、Mapper XML、Service接口、Service實現(xiàn)類、Controller。根據(jù)后端字段信息生成前端Vue頁面包括搜索條件、表格列、表單驗證規(guī)則。生成菜單權(quán)限SQL菜單地址與Controller的RequestMapping保持一致。對照規(guī)范層執(zhí)行自查輸出完整的生成清單。每一步之間是強依賴關(guān)系。AI在這一層的引導(dǎo)下不會突然去研究時間復(fù)雜度也不會自作主張加一個跟若依毫無關(guān)系的工具類。整個過程就像工廠里的流水線每個工位做固定的事。2.3 第三層規(guī)范與樣例層第三層存放的是“若依風(fēng)格”本身。AI生成代碼像不像若依就看你這一層喂了多少規(guī)則和樣例。規(guī)則部分要細到字段級別。我整理了一套最基礎(chǔ)的映射規(guī)范放在Skill里數(shù)據(jù)庫類型Java類型若依風(fēng)格約定varchar / charString較長字段增加Size長度校驗int / integerInteger直接映射即可bigintLong主鍵字段加TableId(type IdType.AUTO)decimal / numericBigDecimal涉及金額時保留兩位小數(shù)datetime / timestampDate前端默認用日期時間選擇器text / longtextStringMapper XML中用#{remark}正常取值除了映射還需要放若干段完整樣例代碼。樣例不用多一個典型的單表模塊徹底吃透就夠了。我會在規(guī)范層放一段標準的Controller代碼讓AI在生成時嚴格對齊RestController RequestMapping(/business/order) public class BizOrderController extends BaseController { Autowired private IBizOrderService bizOrderService; GetMapping(/list) public TableDataInfo list(BizOrder bizOrder) { startPage(); ListBizOrder list bizOrderService.selectBizOrderList(bizOrder); return getDataTable(list); } }樣例的作用是給AI一個“錨”。純文字規(guī)則它可能理解偏差但給它一段地地道道的若依風(fēng)格代碼它就能從中提取出返回類型、分頁寫法、注解風(fēng)格這些信息生成的東西自然靠譜得多。3. 五步法落地從零構(gòu)建可復(fù)用的若依代碼生成Skill有了三層結(jié)構(gòu)做骨架具體怎么把Skill造出來我總結(jié)了一套五步法每一步都有明確的交付物。3.1 第一步把輸入邊界和輸出約定寫成文檔動手寫Skill之前先拿一張紙把“這個技能做什么、不做什么”寫清楚。我最初的版本野心太大想兼顧單表、樹表、主子表結(jié)果哪個都做不精。后來砍到只管單表CRUD效果一下就上來了。這一步的交付物是一份邊界文檔核心內(nèi)容包括支持的輸入格式只接受建表語句或字段清單不接受模糊描述。支持的輸出范圍后端五層代碼、前端兩個Vue文件、菜單SQL。明確不做的事不生成業(yè)務(wù)校驗之外的復(fù)雜規(guī)則、不處理主子表分頁查詢。默認約定包名、模塊名、作者名等參數(shù)未提供時使用預(yù)設(shè)值。邊界定得越死Skill之后維護起來越輕松。AI一旦接收了清晰的約束就不會把精力浪費在那些不該它操心的方向上。3.2 第二步把若依生成器的規(guī)則反向翻譯成文本這一步是核心中的核心。若依框架自帶代碼生成器里面已經(jīng)沉淀了一套完整的代碼模板邏輯我們做的就是把那套邏輯“反向工程”成文字規(guī)則。我對照生成器的模板思路整理出一套規(guī)則草案內(nèi)容包括類名生成規(guī)則表名去掉下劃線并轉(zhuǎn)大駝峰比如 biz_order 變?yōu)?BizOrdersys_user 變?yōu)?SysUser。分層類命名實體類直接用BizOrderMapper接口叫BizOrderMapperService接口叫IBizOrderService實現(xiàn)類叫BizOrderServiceImpl。XML命名空間必須是Mapper接口的全限定名寫錯一個字符整個項目啟動就會報綁定錯誤。Controller路由RequestMapping用小寫復(fù)數(shù)形式例如 /business/order與菜單地址保持一致。這些規(guī)則看起來瑣碎但恰恰是AI最容易出錯的地方。把規(guī)則文本寫進Skill的規(guī)范層之后AI相當于有了一本“操作手冊”不用每次都在腦海里猜若依是怎么約定的。3.3 第三步搭一個只覆蓋單表CRUD的最小原型不要一上來就求全先把最小可用版本搭起來。我會挑選一張最簡單的表比如一張只有主鍵、名稱、狀態(tài)、備注的字典類型表然后手動生成一遍完整的若依代碼把這段代碼當作標準答案。接著把三層結(jié)構(gòu)按最小原型填寫進去描述層寫清楚輸入模板流程編排層寫六步流水線規(guī)范層放入映射表和幾個關(guān)鍵樣例。第一版Skill不需要考慮太多異常情況能用起來就行。我建議在這一步把所有內(nèi)容放到同一個Skill配置文件里不要拆散。你可以用Markdown、YAML或者JSON都行重點是讓AI在一個上下文里同時讀到三層內(nèi)容。拆太散的話AI閱讀時容易丟失關(guān)鍵信息。3.4 第四步準備自測集正反例都要有Skill寫完了不能拿同一張表測那樣測不出問題。我準備了三張結(jié)構(gòu)差異很大的表一張純單表字段基本只有字符串和數(shù)字用于驗證基礎(chǔ)CRUD。一張包含BigDecimal金額、Date時間、長文本備注的表用來驗證字段映射。一張字段很多、注釋不全的“壞表”用來驗證Skill在輸入信息缺失時的表現(xiàn)。正例用來確認功能正常反例用來確認邊界約束生效。比如對字段注釋不全的表Skill應(yīng)該明確提示補齊信息而不是自己腦補一堆含義。自測的方式很簡單把這些表結(jié)構(gòu)依次丟給掛了Skill的AI看它產(chǎn)出的代碼能不能通過IDE編譯能不能對應(yīng)上若依的規(guī)范。第一版跑下來通常會發(fā)現(xiàn)不少問題比如類型映射漏了BigDecimal或者前端頁面缺失時間日期選擇器。這些問題會直接反饋到第三步的規(guī)則補充里。3.5 第五步用真實業(yè)務(wù)表做回歸驗收最小原型通過了就要拉真實業(yè)務(wù)表來驗收。我個人偏好拿項目里新開發(fā)的業(yè)務(wù)模塊來測試因為真實表的復(fù)雜程度遠高于手工造的測試樣例。驗收標準我定得很硬性生成的后端代碼在IDE中零錯誤編譯通過。Mapper XML與Mapper接口全部正確綁定。前端Vue頁面打開后能正常渲染查詢、新增、編輯、刪除功能可操作。菜單SQL執(zhí)行后能正常掛載到角色權(quán)限。就這樣跑十幾個真實表之后規(guī)則庫會越來越厚Skill的穩(wěn)定度才會真正上來。我目前的規(guī)則庫里已經(jīng)有二十多條補充約定都是靠這一步慢慢積累的。4. 實戰(zhàn)記錄一個訂單表從建表語句到全套代碼光講原理有點虛我拿一張實際開發(fā)中常見的訂單表走一遍完整的生成過程。4.1 輸入一張訂單表的建表語句我準備的輸入如下CREATE TABLE biz_order ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 訂單ID, order_no VARCHAR(64) NOT NULL COMMENT 訂單編號, customer_name VARCHAR(64) DEFAULT NULL COMMENT 客戶名稱, total_amount DECIMAL(10,2) DEFAULT NULL COMMENT 訂單總金額, status VARCHAR(16) DEFAULT NULL COMMENT 訂單狀態(tài), create_by VARCHAR(64) DEFAULT NULL COMMENT 創(chuàng)建者, create_time DATETIME DEFAULT NULL COMMENT 創(chuàng)建時間, update_by VARCHAR(64) DEFAULT NULL COMMENT 更新者, update_time DATETIME DEFAULT NULL COMMENT 更新時間, remark VARCHAR(500) DEFAULT NULL COMMENT 備注, PRIMARY KEY (id) ) COMMENT訂單信息表;把這段SQL丟給AI同時點名“用掛載的ruoyi-single-table-crud技能處理”AI就會自動進入技能流程。4.2 Skill內(nèi)部的執(zhí)行流程是怎樣的AI根據(jù)第二層的流程編排逐步處理第一步解析表結(jié)構(gòu)明確表名biz_order、注釋“訂單信息表”、主鍵id、10個業(yè)務(wù)字段。第二步做類型映射其中total_amount映射BigDecimalcreate_time映射Date其余字符映射Stringid從bigint映射為Long并標注主鍵。第三步生成實體類帶好TableName注解TableName(biz_order) public class BizOrder extends BaseEntity { private static final long serialVersionUID 1L; TableId(type IdType.AUTO) private Long id; private String orderNo; private String customerName; private BigDecimal totalAmount; private String status; private String remark; }因為createBy、createTime、updateBy、updateTime這幾個字段和若依BaseEntity里自帶的字段重名了Skill在規(guī)范層里有約定直接交由父類維護所以實體類里不再重復(fù)定義。這一步很關(guān)鍵很多第一次嘗鮮的人在這里就翻車了要么重復(fù)定義字段要么漏了繼承BaseEntity。之后AI繼續(xù)按流水線生成Mapper接口、Mapper XML、Service、Service實現(xiàn)和Controller再根據(jù)字段信息生成前端頁面和菜單SQL。4.3 生成結(jié)果長什么樣質(zhì)量怎么查生成的Controller代碼風(fēng)格對齊了若依規(guī)范RestController RequestMapping(/business/order) public class BizOrderController extends BaseController { Autowired private IBizOrderService bizOrderService; GetMapping(/list) public TableDataInfo list(BizOrder bizOrder) { startPage(); ListBizOrder list bizOrderService.selectBizOrderList(bizOrder); return getDataTable(list); } PostMapping public AjaxResult add(RequestBody BizOrder bizOrder) { return toAjax(bizOrderService.insertBizOrder(bizOrder)); } }生成完之后我會按一張固定的自查表逐項過檢查項判定標準實體注解TableName與TableId齊全繼承關(guān)系正確Mapper XMLnamespace匹配接口全限定名字段映射完整Service層接口帶I前綴實現(xiàn)類注入Mapper并加ServiceController統(tǒng)一返回AjaxResult或TableDataInfo分頁用startPage前端頁面搜索區(qū)、表格區(qū)、分頁區(qū)齊全字段與后端完全對應(yīng)菜單SQL菜單路徑與Controller的RequestMapping保持一致只要這一層檢查通過我才會把代碼合進工程。不是不信AI而是生成邏輯本身無法保證100%覆蓋所有場景校驗環(huán)節(jié)絕不能省。5. 反復(fù)踩過的坑給正在調(diào)Skill的人提個醒方案很順但落地過程中坑也不少。我挑幾個印象最深的說說免得你再踩一遍。5.1 表信息給半截AI就自動“補腦”我一開始偷懶傳建表語句時漏了幾列注釋想著AI這么智能應(yīng)該能猜出來。結(jié)果它真開始猜了把amount字段腦補成“余額”把status腦補成“啟用禁用枚舉”生成的前端頁面對不上原始業(yè)務(wù)含義返工成本相當高。對策就是輸入模板嚴格化。描述層明確寫上“必須提供完整字段清單包括字段名、類型、注釋、是否必填缺失信息時先向用戶索要不得自行假設(shè)”。這一步能攔住大多數(shù)“自由發(fā)揮”。5.2 模板樣例和項目版本漂移了Skill里存的樣例代碼跟實際項目的若依版本是強綁定的。我最初用一套老版本樣例里面Controller還在用舊的返回結(jié)構(gòu)而項目已經(jīng)切換成新風(fēng)格了生成的代碼自然不合拍。解決辦法是在規(guī)范層頂部標注版本信息比如“適配若依前后端分離版本V3.x系列”并且每次升級框架后同步更新樣例代碼。版本漂移這個問題很隱蔽建議在自測集的驗收標準里加入“對照當前項目源碼風(fēng)格”這一項。5.3 生成不等于編譯通過AI生成的代碼不能當作文檔看。我第一次測試時生成結(jié)果看著非常順眼一編譯直接紅了原因是Mapper XML里某個字段類型寫成了java.lang.String跟實際映射不一致。所以我現(xiàn)在的流程里固定加一步生成完代碼后立即放到Maven工程里編譯驗證不通過就回去改Skill規(guī)則。編譯本身就是最好的校驗器它能把99%的隱藏問題暴露出來。5.4 多張表共用一個會話上下文串了在同一個對話里連續(xù)生成多張表的代碼Skill容易出現(xiàn)上下文污染生成訂單表時前面客戶表的字段名偶爾會混進來特別是字段名相似的場景。我把這個問題想明白了之后就在流程編排層加了一條硬性規(guī)定每次生成新表前必須重新完整解析并復(fù)述本次的建表語句確認表名與字段與上一次無關(guān)。同時建議每張表單獨開一個會話徹底切斷干擾源需要對比時再手動匯總。個人現(xiàn)在實際操作中的感受是這套三層加五步的打法真正幫我把AI從“偶爾給個驚喜”變成了“穩(wěn)定給個及格”而及格才是工程化的起點。我最近還在做第二個Skill目標是讓AI根據(jù)需求文檔自動把表結(jié)構(gòu)設(shè)計出來再順手接上這個若依生成技能兩條流水線串起來開發(fā)效率又能往上走一截。如果你也在折騰類似的事情強烈建議從一張最簡單的表開始把三層結(jié)構(gòu)填滿再用五步法慢慢磨別急著上來就搞全家桶。