實戰(zhàn)：一天從0到1交付疾控應急管理系統(tǒng))
“一天做完一個系統(tǒng)又一個標題黨吧?！闭f實話我以前也這么想。直到我真的把需求階段和編碼階段完整跑了一遍用Hermes和Cursor這兩個AI工具把疾控應急管理系統(tǒng)從0到1推出來才發(fā)現這條路的瓶頸根本不在AI寫代碼的能力而在你怎么安排需求設計和編碼的順序、怎么給AI喂上下文。這篇文章不是標題黨而是一份真實的“1天交付”實測記錄內容覆蓋需求設計、數據建模、后端編碼、前端生成和最終聯調的完整流程也把這一天里踩過的坑、返過工的地方原原本本寫出來。好吧先交代系統(tǒng)的最終狀態(tài)。這是一個可以本地跑起來的疾控應急管理系統(tǒng)包含事件登記、事件分級流轉、預案管理、物資臺賬、值班排班和信息報送6個核心模塊。后端是Spring Boot 3 MyBatis Plus MySQL 8前端是Vue 3 Element Plus Pinia數據庫一共13張表前后端加起來差不多6500行代碼。從早上8點半開始做需求設計到晚上7點完成最后一輪聯調剛好一天。適合誰看如果你是準備做管理系統(tǒng)類項目的全棧開發(fā)者或者正在糾結“AI到底能不能幫我快速搭一套可演示的業(yè)務系統(tǒng)”這篇文章能給你一份可以直接抄的作業(yè)。寫在前面的一個重要觀點我并不是在鼓吹“AI替代程序員”。這篇記錄真正想說的是AI輔助開發(fā)這件事成敗關鍵不在模型強不強而在你對項目主次怎么安排。先想清楚哪部分讓AI全權哪部分必須人來把最后一關效率差距才能真正拉開。1. 為什么選Hermes Cursor先搞清楚這倆工具各管哪一段很多人一提到“AI編程”第一反應就是打開某個聊窗口把需求一股腦丟進去等著AI吐出一個能運行的項目。我可以負責任地說對于“從0到1做一個完整管理系統(tǒng)”這種任務這條路走不通。我的做法是把任務拆成兩半交給兩個各有側重的工具反倒在一天內跑通了。1.1 Hermes在項目里扮演的角色Hermes是一個通用型的AI Agent智能體框架/平臺核心能力是你給它一個自然語言目標它會自己拆解任務、調用工具、維護上下文并把中間產物保存下來。在需求設計階段我讓它當“業(yè)務分析師架構師”負責把“疾控應急管理系統(tǒng)”這一句話拆成功能模塊再拆成數據表字段最后輸出建表SQL和接口清單。到編碼階段我又讓它當“代碼生成器”按模塊批量產出Controller、Service、Mapper的基礎代碼。為什么需要這樣一個角色因為實際開發(fā)里最消耗精力的不是“寫某一段代碼”而是“代碼之間能不能串起來”。Hermes這種Agent會把上下文保持在同一個任務流里不像普通聊天框那樣聊三頁就忘開頭。這一點在一天內做完整系統(tǒng)的場景下非常關鍵——沒有連貫的上下文就沒有連貫的項目。1.2 Cursor在項目里扮演的角色Cursor是一個AI原生的代碼編輯器可以理解成“長了AI腦子的VS Code”。它負責的是“在具體代碼文件里真正動手”改一個方法、補一個字段、把一個靜態(tài)頁面改成帶接口請求的Vue組件。我的用法很簡單項目在Cursor里打開遇到問題直接在編輯器里對話讓它定位文件、給出修改方案、應用修改我立刻編譯驗證循環(huán)往復。Hermes和Cursor的分工我后來總結成一句話Hermes管“方案”Cursor管“落地”。Hermes不改具體文件它的產出是文檔、SQL、代碼片段幫我把全局設計定住Cursor在工程里改文件讓方案變成一個能運行的系統(tǒng)。兩者一旦混淆就會出現一種尷尬場面Hermes生成了大量代碼但沒法集成進項目或者Cursor改了一堆文件但缺乏全局設計越改越亂。1.3 為什么不用純對話式AI一把梭我試過用純對話式AI一口氣輸出整個項目結果很慘。第一上下文會失控項目一復雜AI就開始編造不存在的表和字段第二項目不是單個文件而是幾十個文件的組合對話式AI給不了你“如何組織這些文件”的連貫方案第三改需求時對話式AI缺少“落地到項目里”的能力你需要手動復制粘貼來回幾次就亂套。用Hermes Cursor的組合本質上是給AI開發(fā)加了一套“流程約束”先讓Agent產出文檔和方案再讓編輯器AI在工程里落地。這套思路不綁定某一個特定模型我用的是本地部署的Hermes配的是模型API服務你換其他Agent框架搭配Cursor思路一樣成立。關鍵是把“規(guī)劃”和“執(zhí)行”分開讓每個AI做自己最擅長的事。2. 一天的時間線為什么需求設計必須排在編碼前面聽完這個選題我同事的第一反應是一天做系統(tǒng)肯定全程都在寫代碼吧其實不是。真實的順序是上午先花90分鐘做需求設計和數據庫建模再花60分鐘部署工具、搭項目骨架真正的密集編碼集中在下午。很多人覺得“時間緊就應該跳過設計直接寫”這恰恰是最容易被返工拖垮的做法。2.1 全天時間安排下面是我實際執(zhí)行的時間表時間段工作內容用到的工具交付物8:30-10:00需求拆解、模塊劃分、數據模型設計Hermes需求清單、模塊清單、數據庫設計初稿10:00-11:00部署Hermes、配置Cursor、初始化項目骨架Hermes Cursor可運行的空項目11:00-14:00后端編碼實體、接口、業(yè)務邏輯Hermes Cursor后端核心接口可調用14:00-17:00前端編碼頁面、接口對接、權限Cursor管理端主要頁面17:00-19:00聯調、修bug、狀態(tài)機完善Cursor可演示的完整系統(tǒng)這張表值得注意的不是“幾點做什么”而是每一步的依賴關系。沒有前一步的交付物后一步就會停擺建表SQL沒定后端實體沒法寫接口路徑沒定前端頁面沒法接登錄權限沒定頁面做完了也沒法演示。AI開發(fā)并不會改變軟件開發(fā)的基本邏輯它只是把每個環(huán)節(jié)的耗時壓縮了。所以安排一整天的工程本質上是在安排“交付物的順序”。2.2 為什么“先跑通空項目”優(yōu)先級這么高上午10點到11點我的任務是部署Hermes、配置Cursor以及初始化一個能運行的空項目骨架。這里我給自己定的硬性要求是11點之前新建項目的首頁必須在瀏覽器里能打開后端健康檢查接口必須能通。因為后續(xù)所有AI生成的代碼都需要一個能運行的環(huán)境去驗證。骨架沒搭好AI生成再多代碼你也沒法立刻看到效果錯誤就會不斷疊加。這個空項目我把它叫作“驗證腳手架”。它不需要包含任何業(yè)務代碼但要包含完整的依賴配置、統(tǒng)一返回結果類、異常處理器、MyBatis Plus配置和前端的基礎布局。有了這個腳手架Hermes生成的后端代碼可以直接扔進對應的包路徑里Cursor生成的前端頁面可以直接替換掉腳手架里的占位組件AI的產出才能被快速驗證、快速迭代。如果不先做這一步后面所有AI生成的代碼都只是在“紙面運行”效率會大打折扣。2.3 把接口規(guī)范提前釘死在設計階段需求設計可以快但不代表字段和接口規(guī)范可以含糊。在上午的需求設計階段除了生成模塊清單和SQL我還做了第二件事讓Hermes產出一份接口路徑規(guī)范。比如事件模塊統(tǒng)一以/api/event開頭列表用POST /api/event/page新增用POST /api/event狀態(tài)變更用PUT /api/event/{id}/status返回格式統(tǒng)一是ResultT。這個規(guī)范在前端開發(fā)時幫我省下了大量溝通成本。這個動作在傳統(tǒng)開發(fā)里可能要開一次接口評審會但在AI輔助流程里只是給Hermes的提示詞里多了一句“請一并輸出接口路徑清單使用RESTful風格”。然而正是這一句話決定了下午前端對接時是順暢還是崩潰。接口規(guī)范一旦不定前端AI和后端AI就會各寫各的最后聯調階段一定會出現“字段對不上、路徑對不上、返回格式對不上”的三重災難。3. 需求設計怎樣把“疾控應急管理系統(tǒng)”拆成AI能懂的模塊需求設計這個環(huán)節(jié)在傳統(tǒng)流程里至少要開兩三次會但在AI輔助下我把它壓縮成一個提示詞加幾輪追問。不過壓縮的是時間不是思考。恰恰因為AI產出的速度太快人要做的那幾次糾偏就顯得更加關鍵。3.1 讓Hermes產出模塊清單的提示詞我給Hermes的第一條提示詞是這樣寫的你是一名公共衛(wèi)生應急領域的系統(tǒng)分析師。我需要你幫我做需求設計。 項目疾控應急管理系統(tǒng)。 核心業(yè)務對突發(fā)公共衛(wèi)生事件進行登記、分級、流轉處置、應急物資調配、預案管理和值班管理。 目標用戶疾控中心業(yè)務人員、應急辦管理人員、中心領導。 請輸出 1. 功能模塊清單 2. 每個模塊下的核心子功能 3. 涉及的實體對象和關鍵字段建議。 約束 - 面向省級疾控中心場景多科室、多角色協(xié)作 - 需要有事件全流程狀態(tài)管理 - 需要數據權限不同角色看到的數據范圍不同 - 不需要復雜的財務和審批流。注意提示詞里我特意寫了兩類信息一類是業(yè)務范圍即“吃什么”一類是約束條件即“不吃什么”。這是AI能給出準確需求設計的關鍵。如果你只寫“幫我設計一個應急管理系統(tǒng)”AI會給出一堆大而全但沒法落地的功能比如“智慧預警”“大數據分析”這些對一天可交付的項目來說全是坑。約束寫得越清楚AI產出的模塊越克制后面寫代碼時就越不容易跑偏。3.2 生成的模塊清單和核心表結構Hermes在幾分鐘內給出的模塊清單基本覆蓋了核心業(yè)務。它列出的模塊包括應急事件模塊負責事件登記、事件分級、狀態(tài)流轉和查詢預案管理模塊負責預案錄入、版本管理和啟動記錄物資管理模塊負責物資臺賬、出入庫記錄和庫存預警值班管理模塊負責排班、值班日志和交接班記錄信息報送模塊負責報送單生成、逐級上報和處置反饋系統(tǒng)管理模塊負責用戶、角色、菜單權限和操作日志?；谶@份清單我繼續(xù)讓Hermes產出數據庫設計。它最終生成了13張表其中最核心的一張是應急事件表我貼出來CREATE TABLE emergency_event ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 事件ID, event_code VARCHAR(32) NOT NULL COMMENT 事件編號, event_name VARCHAR(128) NOT NULL COMMENT 事件名稱, event_type VARCHAR(32) NOT NULL COMMENT 事件類型, event_level TINYINT NOT NULL COMMENT 事件等級:1一般 2較大 3重大 4特別重大, event_status TINYINT NOT NULL DEFAULT 1 COMMENT 狀態(tài):1待核實 2核實中 3處置中 4已結案, report_time DATETIME NOT NULL COMMENT 報告時間, reporter VARCHAR(64) NULL COMMENT 報告人, reporter_phone VARCHAR(20) NULL COMMENT 報告人電話, location VARCHAR(255) NULL COMMENT 事發(fā)地點, description TEXT NULL COMMENT 事件描述, org_code VARCHAR(32) NULL COMMENT 所屬區(qū)域編碼, create_by BIGINT NULL COMMENT 創(chuàng)建人ID, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 創(chuàng)建時間, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新時間, KEY idx_status (event_status), KEY idx_report_time (report_time) ) COMMENT 應急事件表;這個表生成后基本夠用但我做了兩處補充。第一加了org_code字段因為后面做數據權限過濾要用它區(qū)分“這個事件屬于哪個轄區(qū)”。第二給狀態(tài)和報告時間加了索引因為應急事件查詢基本都會按這兩個條件過濾。其他12張表包括預案表、物資表、出入庫明細表、值班表、報送單表、用戶角色表等我基本沒做大改直接放進了初始化腳本。3.3 人必須做的糾偏AI會“想當然”的三個例子但這里要說一個真實問題AI生成的需求設計表面合理但有幾個地方是“想當然”的必須人工修正。第一AI默認所有列表都是單表查詢。實際上應急事件列表往往要關聯用戶表顯示處理人姓名關聯報送單顯示最新處置進度。如果一開始沒提醒它后面接口會越寫越復雜甚至要推翻重來。我現在的做法是在提示詞里約定“列表查詢需要支持多表關聯返回VO對象”讓它在設計階段就把這個因素考慮進去。第二AI不會主動考慮邏輯刪除。疾控應急事件作為業(yè)務數據不能物理刪除只能邏輯刪除。我必須在提示詞里明確“所有業(yè)務表需要邏輯刪除字段”并讓Hermes在SQL里統(tǒng)一補上deleted字段。這條約束如果漏了后面刪除接口就會直接把記錄抹掉在真實業(yè)務場景下是絕對不允許的。第三AI對“數據權限”的理解容易停留在“有權限就能訪問模塊”的層面。在真實應急場景里區(qū)縣疾控中心只能看本轄區(qū)事件省級中心才能看全部。所以我在表設計時增加了org_code把數據范圍的維度提前落到表結構里。這些糾偏花了我大概20分鐘。如果跳過這一步直接讓AI寫代碼后面改起來就不是20分鐘能解決的問題了。4. 后端編碼從建表SQL到業(yè)務接口的AI協(xié)作節(jié)奏需求定完建表SQL有了數據庫13張表全部建好之后就進入了全天工作量最大的后端編碼階段。這個階段我又拆成了三步先生成基礎代碼再寫復雜業(yè)務最后做接口自測。4.1 實體和基礎CRUD批量生成的正確姿勢拿到建表SQL之后傳統(tǒng)做法是一個表一個Controller、Service、Mapper地去寫非常機械。我把建表語句直接丟給Hermes讓它按MyBatis Plus規(guī)范生成實體類和基礎CRUD接口。這里的關鍵是提示詞里要明確項目規(guī)范否則AI生成出來的代碼風格會五花八門。我當時的規(guī)范約束是這些統(tǒng)一返回結果類型ResultT、統(tǒng)一異常處理、邏輯刪除字段用TableLogic注解、主鍵用雪花算法、時間字段用LocalDateTime。把這些規(guī)范寫成一個約束段落放進提示詞AI生成的代碼風格就會統(tǒng)一。我抽查了幾個生成出來的實體類基本符合預期。比如事件實體里的關鍵字段Data TableName(emergency_event) public class EmergencyEvent { TableId(type IdType.ASSIGN_ID) private Long id; private String eventCode; private String eventName; private String eventType; private Integer eventLevel; private Integer eventStatus; private LocalDateTime reportTime; private String reporter; private String reporterPhone; private String location; private String description; private String orgCode; TableLogic private Integer deleted; private Long createBy; private LocalDateTime createTime; private LocalDateTime updateTime; }批量生成的Controller同樣中規(guī)中矩分頁查詢、新增、修改、刪除、詳情五個接口一次給全。這個階段的目標不是炫技而是把重復勞動快速做完給后面的復雜業(yè)務留出時間?；A代碼這種活AI最擅長人也最不該在它身上浪費太多時間。4.2 復雜查詢和狀態(tài)流轉這部分必須人盯基礎CRUD生成完我開始處理真正體現業(yè)務價值的兩個部分一個是應急事件的多條件分頁查詢一個是事件狀態(tài)流轉。多條件分頁查詢這種帶動態(tài)條件的邏輯我讓Hermes生成了一段Wrapper查詢Override public PageEmergencyEventVO pageEvents(EventQuery query) { LambdaQueryWrapperEmergencyEvent wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.hasText(query.getEventType()), EmergencyEvent::getEventType, query.getEventType()) .eq(query.getEventLevel() ! null, EmergencyEvent::getEventLevel, query.getEventLevel()) .eq(query.getEventStatus() ! null, EmergencyEvent::getEventStatus, query.getEventStatus()) .like(StringUtils.hasText(query.getKeyword()), EmergencyEvent::getEventName, query.getKeyword()) .eq(StringUtils.hasText(query.getOrgCode()), EmergencyEvent::getOrgCode, query.getOrgCode()) .orderByDesc(EmergencyEvent::getReportTime); return eventMapper.selectPage(new Page(query.getPageNum(), query.getPageSize()), wrapper); }這段代碼本身不難但里面藏著一個容易遺漏的邏輯數據權限。當前用戶是區(qū)縣角色時查詢條件里必須強制拼上org_code 當前用戶轄區(qū)。這個條件是動態(tài)拼進去的普通開發(fā)很容易忘了在列表頁加導致某個區(qū)縣的人看到了全省的事件這在應急場景下是嚴重的數據越權。我把這個邏輯單拎出來寫成了一個DataScopeHelper所有列表查詢統(tǒng)一走這個Helper而不是在每個Service里各寫各的。狀態(tài)流轉這里我也提醒一句不要直接生成“誰都能改狀態(tài)”的接口。事件狀態(tài)不是隨便跳的已結案不能退回待核實處置中不能跳過核實直接結案。我讓Hermes生成一個枚舉和狀態(tài)機校驗方法public enum EventStatus { PENDING(1, 待核實), VERIFYING(2, 核實中), HANDLING(3, 處置中), CLOSED(4, 已結案); private final int code; private final String text; EventStatus(int code, String text) { this.code code; this.text text; } }然后把合法的流轉關系放在一個Map里每次變更狀態(tài)前先校驗。這個邏輯代碼量很少但它決定了一個應急系統(tǒng)能不能用。如果狀態(tài)可以亂跳后面的結案統(tǒng)計、處置時限考核就全廢了。AI能幫你寫80%的代碼但這種業(yè)務規(guī)則人是必須親自確認的。4.3 接口自測讓AI順手生成一份最小化測試數據后端寫完我遇到一個很現實的問題接口邏輯對不對得拿數據去測。人工造數據實在太慢我讓Hermes寫了一個CommandLineRunner在應用啟動時自動插入測試數據5名用戶、3個角色、2個事件、若干物資記錄。這樣每次啟動應用都有現成的數據可以點擊驗證。這個做法極大加快了聯調速度但有一個坑測試數據會自動污染庫表。我的處理方式是在配置里加了一個開關本地開發(fā)和演示時才開啟生產環(huán)境絕不帶出去。類似這種“開發(fā)輔助代碼”AI是很樂于生成的但開工前就要約定好隔離方式否則測試數據混進正式環(huán)境后面清理起來非常痛苦。5. 前端頁面Cursor幫我寫出了80%的Vue組件后端接口有了前端頁面就進入了密集生產階段。這個階段的主工具從Hermes換成了Cursor原因很簡單前端頁面需要頻繁改文件、看效果、再改文件Cursor這種和編輯器深度綁定的AI效率最高。一次對話改完立刻能在瀏覽器里刷新驗證反饋回路非常短。5.1 頁面規(guī)劃和組件拆解我先把后臺管理端的頁面清單列出來登錄頁、系統(tǒng)布局、事件管理列表頁、事件新增/詳情頁、預案管理頁、物資管理頁、值班管理頁、信息報送頁、用戶管理頁、角色管理頁差不多10個頁面。然后讓Cursor按“布局組件、列表頁、表單頁”三種模式分別生成再逐個替換成真實接口。頁面規(guī)劃時有一個容易被忽略的技巧先讓Cursor生成一個統(tǒng)一的API請求封裝把Axios實例、請求攔截器、Token攜帶、錯誤提示都處理好。所有頁面共用這個封裝而不是讓每個頁面自己發(fā)請求。這一步看似不起眼但它是前端代碼風格統(tǒng)一的關鍵。沒有統(tǒng)一封裝每個頁面的請求代碼就會各寫各的后面維護起來非常痛苦。5.2 對話式生成一個事件管理頁當時讓Cursor生成事件列表頁我的指令是在src/views/event/index.vue里生成一個事件管理頁面用Element Plus的el-table展示事件列表包含事件編號、事件名稱、事件等級、事件狀態(tài)、報告時間、操作列支持分頁和狀態(tài)篩選操作列包含“詳情”和“流轉”按鈕調用/api/event/page接口。Cursor生成的頁面我只做了少量修改就接上了接口核心代碼結構類似這樣template div classpage-container el-card shadownever el-form :inlinetrue :modelquery el-form-item label事件名稱 el-input v-modelquery.keyword placeholder請輸入關鍵詞 clearable / /el-form-item el-form-item label事件狀態(tài) el-select v-modelquery.eventStatus placeholder全部 clearable el-option v-foritem in statusOptions :keyitem.value :labelitem.label :valueitem.value / /el-select /el-form-item el-form-item el-button typeprimary clickloadData查詢/el-button /el-form-item /el-form el-table :datatableData v-loadingloading border stripe el-table-column propeventCode label事件編號 min-width140 / el-table-column propeventName label事件名稱 min-width200 / el-table-column propeventLevel label等級 width80 template #default{ row } el-tag :typelevelType[row.eventLevel]{{ levelText[row.eventLevel] }}/el-tag /template /el-table-column el-table-column propeventStatus label狀態(tài) width90 template #default{ row } el-tag :typestatusType[row.eventStatus]{{ statusText[row.eventStatus] }}/el-tag /template /el-table-column el-table-column propreportTime label報告時間 width160 / el-table-column label操作 width150 fixedright template #default{ row } el-button link typeprimary clickopenDetail(row)詳情/el-button el-button link typewarning clickopenFlow(row)流轉/el-button /template /el-table-column /el-table el-pagination v-model:current-pagequery.pageNum v-model:page-sizequery.pageSize :totaltotal layouttotal, prev, pager, next current-changeloadData / /el-card /div /template這里特別想提醒一點AI生成的前端頁面默認情況下不會處理狀態(tài)枚舉的映射。事件狀態(tài)在數據庫里是1、2、3、4這樣的數字如果頁面上直接顯示數字用戶根本看不懂。我讓Cursor同時生成了statusText、statusType這類映射對象再用el-tag把狀態(tài)渲染成不同顏色的標簽。這個細節(jié)雖然小但決定了頁面是“能看”還是“能用”。5.3 接口對接和權限按鈕處理前端頁面接后端接口時最容易出問題的不是請求本身而是字段名對不上。AI生成的前端代碼可能默認后端返回的是camelCase字段而后端實體類某些字段是下劃線風格兩者一錯位頁面上全是undefined。我的解決辦法是在接口封裝層統(tǒng)一做字段映射或者在提示詞里一開始就規(guī)定“所有后端返回字段使用駝峰命名”讓兩邊從一開始就保持一致。經過這一天的實操我更推薦后者與其事后轉換不如源頭統(tǒng)一。權限按鈕的處理也值得單獨說。應急系統(tǒng)的操作按鈕不是每個人都可見普通業(yè)務員能看到“上報”按鈕科室負責人能看到“核實”按鈕領導能看到“結案”按鈕。Cursor可以在按鈕上加一個v-permission指令由權限指令根據當前用戶的按鈕權限列表決定是否渲染。這個能力是我在生成頁面時通過提示詞提前約定好的后面所有頁面統(tǒng)一復用避免每個頁面各寫各的判斷邏輯。6. 疾控應急系統(tǒng)里最容易翻車的兩個業(yè)務點狀態(tài)流轉和數據權限整天的開發(fā)里如果說有哪個環(huán)節(jié)讓我感覺“差點翻車”那一定是狀態(tài)流轉和數據權限。這兩個問題AI幾乎不可能自己意識到必須由懂業(yè)務的人主動提出來然后在需求設計階段就定好規(guī)則。6.1 事件狀態(tài)機AI默認只會做增刪改查我第一次讓Hermes做事件狀態(tài)管理時它生成的是一個簡單的updateStatus接口誰都可以調用傳什么狀態(tài)就改成什么狀態(tài)。從技術上這沒錯但從業(yè)務上這是災難。如果一條“已結案”的事件被誤操作改回“待核實”后面的處置時限統(tǒng)計、結案報表就全亂了。我把狀態(tài)流轉定義成“只允許從當前狀態(tài)經過合法動作進入下一狀態(tài)”核心流轉關系如下當前狀態(tài)允許的動作目標狀態(tài)待核實核實核實中待核實誤報關閉已關閉核實中啟動處置處置中處置中結案已結案處置中升級上報已上報此外狀態(tài)之間還必須記錄操作人和操作時間所以我讓Hermes補了一張狀態(tài)流轉日志表。加入之后領導在詳情頁可以看到一條事件的完整時間線幾點幾分誰做了核實幾點幾分誰啟動了處置。這在應急管理場景里非常關鍵。所以我建議凡是涉及“流程”的項目哪怕再簡單都要讓AI先生成“狀態(tài)動作校驗”三件套而不是簡單生成一個改狀態(tài)的接口。6.2 數據權限應急場景下“誰看誰的數據”不能一刀切疾控應急系統(tǒng)的用戶按層級分為省級中心、市級中心、區(qū)縣中心。默認規(guī)則是區(qū)縣中心只能看本轄區(qū)事件市級中心能看本市所有區(qū)縣省級中心能看全部。這就是數據權限問題。如果只用簡單的RBAC做權限控制它能控制“這個角色能不能訪問事件模塊”但控制不了“這個用戶能看哪幾條事件記錄”后者必須靠數據權限過濾實現。我的做法是在用戶表里存org_code在事件表里存事發(fā)地對應的org_code查詢時根據當前用戶的行政區(qū)劃級別動態(tài)拼接條件。這個邏輯對AI來說可以一次性生成但它不是一個自動出現的需求。如果你不告訴AI“應急系統(tǒng)需要按管轄層級控制數據可見范圍”AI交付的版本就一定是所有角色看到同一份數據。這也是我反復強調不要在需求設計階段省時間的原因——這個階段20分鐘的投入有可能幫你省掉寫完后一次大返工。7. Hermes部署與使用Windows環(huán)境下實測的幾個坑這一章寫給第一次接觸Hermes的讀者。我把自己在Windows本機部署和使用Hermes的過程以及當天遇到的幾個典型問題整理一下。需要說明的是具體命令和參數以你使用的版本和官方文檔為準但排查思路基本是通用的。7.1 部署流程和模型配置部署這類Agent框架/平臺流程通常是固定的先檢查本機環(huán)境主要看Python或Node版本是否滿足要求然后下載或拉取安裝包在項目目錄里安裝依賴接著配置模型的接入方式也就是模型服務的API地址和密鑰最后啟動服務在瀏覽器或客戶端里開始對話。當天我在自己本機操作時大致就是這個順序。裝依賴的過程花了一點時間整體不算復雜。配模型的時候有個細節(jié)值得注意不同模型對上下文長度和工具調用的支持不一樣部署之后第一件事應該是先跑一個最簡單的測試對話確認它能正常返回結果而不是直接丟一個需求任務過去。如果模型本身沒配好后面所有步驟都白搭。7.2 實際遇到的三類問題第一類是PowerShell執(zhí)行策略問題。在Windows上如果用了腳本啟動服務經常會遇到“無法加載文件因為在此系統(tǒng)上禁止運行腳本”之類的報錯。這個問題很好解決用管理員身份打開PowerShell執(zhí)行一次Set-ExecutionPolicy RemoteSigned再重試啟動腳本。第二類是端口占用。Agent服務默認端口可能被其他程序占了啟動時會報端口沖突。我的做法是啟動前先查一下端口占用情況被占用了就換一個端口不要硬剛。第三類是中文亂碼。如果Agent生成的文檔或日志在Windows終端里顯示亂碼大概率是終端編碼問題。把終端的代碼頁切到UTF-8或者在啟動命令里設置編碼參數問題一般就能解決。7.3 提示詞交互的實操技巧使用Hermes這類Agent和普通AI聊天的最大區(qū)別是它有一個“任務”的概念。你可以把一整天的需求設計變成一個任務讓它分步驟執(zhí)行中間會產出文檔、SQL、代碼片段。為了讓任務執(zhí)行得穩(wěn)我有幾個小技巧。第一每個任務的開頭先交代“角色目標約束”不要邊聊邊補因為補丁式對話會讓上下文越來越亂。第二如果任務里需要AI產出多個文件把文件清單和命名規(guī)則一次說清楚比如“實體類放com.example.entity包Controller放com.example.controller包”。第三如果AI中途給出了不滿意結果不要直接說“重寫”而是告訴它“哪一部分有問題改成什么方向”這樣它能保留正確的部分而不是推倒重來。提示Agent的生產結果一定要讓它在任務結束時匯總成一份清單比如“輸出本次生成的SQL文件清單、代碼文件清單”。這份清單方便你逐個核對也方便后續(xù)交給Cursor去落地。沒有清單AI生成的中間產物就會像散落一地的零件很難組織起來。8. 一天結束后的復盤時間都花在了哪里項目跑起來之后我做了一個效率復盤。這里把AI輔助開發(fā)和傳統(tǒng)方式的耗時對比放出來也把必須人盯的環(huán)節(jié)說清楚方便后面再做類似項目時有個參考。8.1 效率對比拿疾控應急管理系統(tǒng)來說如果按傳統(tǒng)開發(fā)方式需求設計加原型通常要3到5天前后端聯調再加一周很正常。而AI輔助下的實際耗時分布大概是環(huán)節(jié)傳統(tǒng)開發(fā)耗時AI輔助實際耗時主要省在哪里需求梳理和模塊設計2-3天2小時AI生成初稿人只做糾偏數據庫設計0.5-1天30分鐘建表SQL直接生成后端基礎CRUD2-3天3小時批量化生成實體和接口前端全部頁面4-5天4小時Cursor批量生成Vue組件聯調和修復2-3天2.5小時接口規(guī)范統(tǒng)一后問題大減為什么能省這么多核心在于大部分重復勞動的“代碼骨架”被AI包掉了人只需要做三件事在需求階段把業(yè)務規(guī)則定清楚在編碼階段把復雜邏輯確認好在聯調階段盯著字段和狀態(tài)流轉。剩下的重復代碼AI做得又快又不容易疲勞。8.2 必須人工把關的三個環(huán)節(jié)但我也要說清楚不是所有環(huán)節(jié)AI都省時間。至少有三個環(huán)節(jié)人必須親自盯否則后面一定會返工。第一個是狀態(tài)流轉和業(yè)務規(guī)則。AI默認的思維是“可修改”而業(yè)務要求是“可控制”這兩者之間的差距需要人來填。第二個是數據權限。它不是頁面上的一個功能而是貫穿所有查詢的橫切邏輯AI不會主動考慮到組織層級和數據范圍。第三個是接口字段的一致性。后端返回什么字段、前端用什么字段必須在一開始就約定好不然聯調階段會反復出現“頁面顯示undefined”的問題。8.3 后續(xù)擴展方向一天做完的版本定位是“可演示、可驗證、可繼續(xù)迭代”的基線版本不是生產級系統(tǒng)。如果要把這個系統(tǒng)繼續(xù)往前推我大概會按這個順序擴展第一步把文件上傳和附件管理補上比如事件現場照片和處置報告第二步接入大屏展示把事件分布、物資庫存、值班情況投到指揮中心的大屏第三步加上消息通知事件狀態(tài)變化時通過短信或站內信提醒相關人員第四步再做一套移動端H5方便現場人員用手機上報事件。每一層擴展都可以沿用當天的AI協(xié)作模式先讓Agent出方案再讓Cursor改代碼。如果讓我再做一遍這類項目我會在需求設計階段再多留半小時。設計階段省下的時間后面幾乎都會以返工的方式還回去。另一個經驗是下午四點半之后堅決不開新功能所有時間留給聯調和修bug。AI能幫你在一天內把系統(tǒng)“寫完”但“寫完”和“能用”之間隔著的那層細節(jié)——狀態(tài)能不能走通、權限遮沒遮對、按鈕點擊有沒有反應——永遠需要一雙人眼去盯。這也是AI開發(fā)這件事最真實的邊界。 AI輔助開發(fā)實戰(zhàn)：一天從0到1交付疾控應急管理系統(tǒng)
“一天做完一個系統(tǒng)又一個標題黨吧?！闭f實話我以前也這么想。直到我真的把需求階段和編碼階段完整跑了一遍用Hermes和Cursor這兩個AI工具把疾控應急管理系統(tǒng)從0到1推出來才發(fā)現這條路的瓶頸根本不在AI寫代碼的能力而在你怎么安排需求設計和編碼的順序、怎么給AI喂上下文。這篇文章不是標題黨而是一份真實的“1天交付”實測記錄內容覆蓋需求設計、數據建模、后端編碼、前端生成和最終聯調的完整流程也把這一天里踩過的坑、返過工的地方原原本本寫出來。好吧先交代系統(tǒng)的最終狀態(tài)。這是一個可以本地跑起來的疾控應急管理系統(tǒng)包含事件登記、事件分級流轉、預案管理、物資臺賬、值班排班和信息報送6個核心模塊。后端是Spring Boot 3 MyBatis Plus MySQL 8前端是Vue 3 Element Plus Pinia數據庫一共13張表前后端加起來差不多6500行代碼。從早上8點半開始做需求設計到晚上7點完成最后一輪聯調剛好一天。適合誰看如果你是準備做管理系統(tǒng)類項目的全棧開發(fā)者或者正在糾結“AI到底能不能幫我快速搭一套可演示的業(yè)務系統(tǒng)”這篇文章能給你一份可以直接抄的作業(yè)。寫在前面的一個重要觀點我并不是在鼓吹“AI替代程序員”。這篇記錄真正想說的是AI輔助開發(fā)這件事成敗關鍵不在模型強不強而在你對項目主次怎么安排。先想清楚哪部分讓AI全權哪部分必須人來把最后一關效率差距才能真正拉開。1. 為什么選Hermes Cursor先搞清楚這倆工具各管哪一段很多人一提到“AI編程”第一反應就是打開某個聊窗口把需求一股腦丟進去等著AI吐出一個能運行的項目。我可以負責任地說對于“從0到1做一個完整管理系統(tǒng)”這種任務這條路走不通。我的做法是把任務拆成兩半交給兩個各有側重的工具反倒在一天內跑通了。1.1 Hermes在項目里扮演的角色Hermes是一個通用型的AI Agent智能體框架/平臺核心能力是你給它一個自然語言目標它會自己拆解任務、調用工具、維護上下文并把中間產物保存下來。在需求設計階段我讓它當“業(yè)務分析師架構師”負責把“疾控應急管理系統(tǒng)”這一句話拆成功能模塊再拆成數據表字段最后輸出建表SQL和接口清單。到編碼階段我又讓它當“代碼生成器”按模塊批量產出Controller、Service、Mapper的基礎代碼。為什么需要這樣一個角色因為實際開發(fā)里最消耗精力的不是“寫某一段代碼”而是“代碼之間能不能串起來”。Hermes這種Agent會把上下文保持在同一個任務流里不像普通聊天框那樣聊三頁就忘開頭。這一點在一天內做完整系統(tǒng)的場景下非常關鍵——沒有連貫的上下文就沒有連貫的項目。1.2 Cursor在項目里扮演的角色Cursor是一個AI原生的代碼編輯器可以理解成“長了AI腦子的VS Code”。它負責的是“在具體代碼文件里真正動手”改一個方法、補一個字段、把一個靜態(tài)頁面改成帶接口請求的Vue組件。我的用法很簡單項目在Cursor里打開遇到問題直接在編輯器里對話讓它定位文件、給出修改方案、應用修改我立刻編譯驗證循環(huán)往復。Hermes和Cursor的分工我后來總結成一句話Hermes管“方案”Cursor管“落地”。Hermes不改具體文件它的產出是文檔、SQL、代碼片段幫我把全局設計定住Cursor在工程里改文件讓方案變成一個能運行的系統(tǒng)。兩者一旦混淆就會出現一種尷尬場面Hermes生成了大量代碼但沒法集成進項目或者Cursor改了一堆文件但缺乏全局設計越改越亂。1.3 為什么不用純對話式AI一把梭我試過用純對話式AI一口氣輸出整個項目結果很慘。第一上下文會失控項目一復雜AI就開始編造不存在的表和字段第二項目不是單個文件而是幾十個文件的組合對話式AI給不了你“如何組織這些文件”的連貫方案第三改需求時對話式AI缺少“落地到項目里”的能力你需要手動復制粘貼來回幾次就亂套。用Hermes Cursor的組合本質上是給AI開發(fā)加了一套“流程約束”先讓Agent產出文檔和方案再讓編輯器AI在工程里落地。這套思路不綁定某一個特定模型我用的是本地部署的Hermes配的是模型API服務你換其他Agent框架搭配Cursor思路一樣成立。關鍵是把“規(guī)劃”和“執(zhí)行”分開讓每個AI做自己最擅長的事。2. 一天的時間線為什么需求設計必須排在編碼前面聽完這個選題我同事的第一反應是一天做系統(tǒng)肯定全程都在寫代碼吧其實不是。真實的順序是上午先花90分鐘做需求設計和數據庫建模再花60分鐘部署工具、搭項目骨架真正的密集編碼集中在下午。很多人覺得“時間緊就應該跳過設計直接寫”這恰恰是最容易被返工拖垮的做法。2.1 全天時間安排下面是我實際執(zhí)行的時間表時間段工作內容用到的工具交付物8:30-10:00需求拆解、模塊劃分、數據模型設計Hermes需求清單、模塊清單、數據庫設計初稿10:00-11:00部署Hermes、配置Cursor、初始化項目骨架Hermes Cursor可運行的空項目11:00-14:00后端編碼實體、接口、業(yè)務邏輯Hermes Cursor后端核心接口可調用14:00-17:00前端編碼頁面、接口對接、權限Cursor管理端主要頁面17:00-19:00聯調、修bug、狀態(tài)機完善Cursor可演示的完整系統(tǒng)這張表值得注意的不是“幾點做什么”而是每一步的依賴關系。沒有前一步的交付物后一步就會停擺建表SQL沒定后端實體沒法寫接口路徑沒定前端頁面沒法接登錄權限沒定頁面做完了也沒法演示。AI開發(fā)并不會改變軟件開發(fā)的基本邏輯它只是把每個環(huán)節(jié)的耗時壓縮了。所以安排一整天的工程本質上是在安排“交付物的順序”。2.2 為什么“先跑通空項目”優(yōu)先級這么高上午10點到11點我的任務是部署Hermes、配置Cursor以及初始化一個能運行的空項目骨架。這里我給自己定的硬性要求是11點之前新建項目的首頁必須在瀏覽器里能打開后端健康檢查接口必須能通。因為后續(xù)所有AI生成的代碼都需要一個能運行的環(huán)境去驗證。骨架沒搭好AI生成再多代碼你也沒法立刻看到效果錯誤就會不斷疊加。這個空項目我把它叫作“驗證腳手架”。它不需要包含任何業(yè)務代碼但要包含完整的依賴配置、統(tǒng)一返回結果類、異常處理器、MyBatis Plus配置和前端的基礎布局。有了這個腳手架Hermes生成的后端代碼可以直接扔進對應的包路徑里Cursor生成的前端頁面可以直接替換掉腳手架里的占位組件AI的產出才能被快速驗證、快速迭代。如果不先做這一步后面所有AI生成的代碼都只是在“紙面運行”效率會大打折扣。2.3 把接口規(guī)范提前釘死在設計階段需求設計可以快但不代表字段和接口規(guī)范可以含糊。在上午的需求設計階段除了生成模塊清單和SQL我還做了第二件事讓Hermes產出一份接口路徑規(guī)范。比如事件模塊統(tǒng)一以/api/event開頭列表用POST /api/event/page新增用POST /api/event狀態(tài)變更用PUT /api/event/{id}/status返回格式統(tǒng)一是ResultT。這個規(guī)范在前端開發(fā)時幫我省下了大量溝通成本。這個動作在傳統(tǒng)開發(fā)里可能要開一次接口評審會但在AI輔助流程里只是給Hermes的提示詞里多了一句“請一并輸出接口路徑清單使用RESTful風格”。然而正是這一句話決定了下午前端對接時是順暢還是崩潰。接口規(guī)范一旦不定前端AI和后端AI就會各寫各的最后聯調階段一定會出現“字段對不上、路徑對不上、返回格式對不上”的三重災難。3. 需求設計怎樣把“疾控應急管理系統(tǒng)”拆成AI能懂的模塊需求設計這個環(huán)節(jié)在傳統(tǒng)流程里至少要開兩三次會但在AI輔助下我把它壓縮成一個提示詞加幾輪追問。不過壓縮的是時間不是思考。恰恰因為AI產出的速度太快人要做的那幾次糾偏就顯得更加關鍵。3.1 讓Hermes產出模塊清單的提示詞我給Hermes的第一條提示詞是這樣寫的你是一名公共衛(wèi)生應急領域的系統(tǒng)分析師。我需要你幫我做需求設計。 項目疾控應急管理系統(tǒng)。 核心業(yè)務對突發(fā)公共衛(wèi)生事件進行登記、分級、流轉處置、應急物資調配、預案管理和值班管理。 目標用戶疾控中心業(yè)務人員、應急辦管理人員、中心領導。 請輸出 1. 功能模塊清單 2. 每個模塊下的核心子功能 3. 涉及的實體對象和關鍵字段建議。 約束 - 面向省級疾控中心場景多科室、多角色協(xié)作 - 需要有事件全流程狀態(tài)管理 - 需要數據權限不同角色看到的數據范圍不同 - 不需要復雜的財務和審批流。注意提示詞里我特意寫了兩類信息一類是業(yè)務范圍即“吃什么”一類是約束條件即“不吃什么”。這是AI能給出準確需求設計的關鍵。如果你只寫“幫我設計一個應急管理系統(tǒng)”AI會給出一堆大而全但沒法落地的功能比如“智慧預警”“大數據分析”這些對一天可交付的項目來說全是坑。約束寫得越清楚AI產出的模塊越克制后面寫代碼時就越不容易跑偏。3.2 生成的模塊清單和核心表結構Hermes在幾分鐘內給出的模塊清單基本覆蓋了核心業(yè)務。它列出的模塊包括應急事件模塊負責事件登記、事件分級、狀態(tài)流轉和查詢預案管理模塊負責預案錄入、版本管理和啟動記錄物資管理模塊負責物資臺賬、出入庫記錄和庫存預警值班管理模塊負責排班、值班日志和交接班記錄信息報送模塊負責報送單生成、逐級上報和處置反饋系統(tǒng)管理模塊負責用戶、角色、菜單權限和操作日志?；谶@份清單我繼續(xù)讓Hermes產出數據庫設計。它最終生成了13張表其中最核心的一張是應急事件表我貼出來CREATE TABLE emergency_event ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 事件ID, event_code VARCHAR(32) NOT NULL COMMENT 事件編號, event_name VARCHAR(128) NOT NULL COMMENT 事件名稱, event_type VARCHAR(32) NOT NULL COMMENT 事件類型, event_level TINYINT NOT NULL COMMENT 事件等級:1一般 2較大 3重大 4特別重大, event_status TINYINT NOT NULL DEFAULT 1 COMMENT 狀態(tài):1待核實 2核實中 3處置中 4已結案, report_time DATETIME NOT NULL COMMENT 報告時間, reporter VARCHAR(64) NULL COMMENT 報告人, reporter_phone VARCHAR(20) NULL COMMENT 報告人電話, location VARCHAR(255) NULL COMMENT 事發(fā)地點, description TEXT NULL COMMENT 事件描述, org_code VARCHAR(32) NULL COMMENT 所屬區(qū)域編碼, create_by BIGINT NULL COMMENT 創(chuàng)建人ID, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 創(chuàng)建時間, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新時間, KEY idx_status (event_status), KEY idx_report_time (report_time) ) COMMENT 應急事件表;這個表生成后基本夠用但我做了兩處補充。第一加了org_code字段因為后面做數據權限過濾要用它區(qū)分“這個事件屬于哪個轄區(qū)”。第二給狀態(tài)和報告時間加了索引因為應急事件查詢基本都會按這兩個條件過濾。其他12張表包括預案表、物資表、出入庫明細表、值班表、報送單表、用戶角色表等我基本沒做大改直接放進了初始化腳本。3.3 人必須做的糾偏AI會“想當然”的三個例子但這里要說一個真實問題AI生成的需求設計表面合理但有幾個地方是“想當然”的必須人工修正。第一AI默認所有列表都是單表查詢。實際上應急事件列表往往要關聯用戶表顯示處理人姓名關聯報送單顯示最新處置進度。如果一開始沒提醒它后面接口會越寫越復雜甚至要推翻重來。我現在的做法是在提示詞里約定“列表查詢需要支持多表關聯返回VO對象”讓它在設計階段就把這個因素考慮進去。第二AI不會主動考慮邏輯刪除。疾控應急事件作為業(yè)務數據不能物理刪除只能邏輯刪除。我必須在提示詞里明確“所有業(yè)務表需要邏輯刪除字段”并讓Hermes在SQL里統(tǒng)一補上deleted字段。這條約束如果漏了后面刪除接口就會直接把記錄抹掉在真實業(yè)務場景下是絕對不允許的。第三AI對“數據權限”的理解容易停留在“有權限就能訪問模塊”的層面。在真實應急場景里區(qū)縣疾控中心只能看本轄區(qū)事件省級中心才能看全部。所以我在表設計時增加了org_code把數據范圍的維度提前落到表結構里。這些糾偏花了我大概20分鐘。如果跳過這一步直接讓AI寫代碼后面改起來就不是20分鐘能解決的問題了。4. 后端編碼從建表SQL到業(yè)務接口的AI協(xié)作節(jié)奏需求定完建表SQL有了數據庫13張表全部建好之后就進入了全天工作量最大的后端編碼階段。這個階段我又拆成了三步先生成基礎代碼再寫復雜業(yè)務最后做接口自測。4.1 實體和基礎CRUD批量生成的正確姿勢拿到建表SQL之后傳統(tǒng)做法是一個表一個Controller、Service、Mapper地去寫非常機械。我把建表語句直接丟給Hermes讓它按MyBatis Plus規(guī)范生成實體類和基礎CRUD接口。這里的關鍵是提示詞里要明確項目規(guī)范否則AI生成出來的代碼風格會五花八門。我當時的規(guī)范約束是這些統(tǒng)一返回結果類型ResultT、統(tǒng)一異常處理、邏輯刪除字段用TableLogic注解、主鍵用雪花算法、時間字段用LocalDateTime。把這些規(guī)范寫成一個約束段落放進提示詞AI生成的代碼風格就會統(tǒng)一。我抽查了幾個生成出來的實體類基本符合預期。比如事件實體里的關鍵字段Data TableName(emergency_event) public class EmergencyEvent { TableId(type IdType.ASSIGN_ID) private Long id; private String eventCode; private String eventName; private String eventType; private Integer eventLevel; private Integer eventStatus; private LocalDateTime reportTime; private String reporter; private String reporterPhone; private String location; private String description; private String orgCode; TableLogic private Integer deleted; private Long createBy; private LocalDateTime createTime; private LocalDateTime updateTime; }批量生成的Controller同樣中規(guī)中矩分頁查詢、新增、修改、刪除、詳情五個接口一次給全。這個階段的目標不是炫技而是把重復勞動快速做完給后面的復雜業(yè)務留出時間?；A代碼這種活AI最擅長人也最不該在它身上浪費太多時間。4.2 復雜查詢和狀態(tài)流轉這部分必須人盯基礎CRUD生成完我開始處理真正體現業(yè)務價值的兩個部分一個是應急事件的多條件分頁查詢一個是事件狀態(tài)流轉。多條件分頁查詢這種帶動態(tài)條件的邏輯我讓Hermes生成了一段Wrapper查詢Override public PageEmergencyEventVO pageEvents(EventQuery query) { LambdaQueryWrapperEmergencyEvent wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.hasText(query.getEventType()), EmergencyEvent::getEventType, query.getEventType()) .eq(query.getEventLevel() ! null, EmergencyEvent::getEventLevel, query.getEventLevel()) .eq(query.getEventStatus() ! null, EmergencyEvent::getEventStatus, query.getEventStatus()) .like(StringUtils.hasText(query.getKeyword()), EmergencyEvent::getEventName, query.getKeyword()) .eq(StringUtils.hasText(query.getOrgCode()), EmergencyEvent::getOrgCode, query.getOrgCode()) .orderByDesc(EmergencyEvent::getReportTime); return eventMapper.selectPage(new Page(query.getPageNum(), query.getPageSize()), wrapper); }這段代碼本身不難但里面藏著一個容易遺漏的邏輯數據權限。當前用戶是區(qū)縣角色時查詢條件里必須強制拼上org_code 當前用戶轄區(qū)。這個條件是動態(tài)拼進去的普通開發(fā)很容易忘了在列表頁加導致某個區(qū)縣的人看到了全省的事件這在應急場景下是嚴重的數據越權。我把這個邏輯單拎出來寫成了一個DataScopeHelper所有列表查詢統(tǒng)一走這個Helper而不是在每個Service里各寫各的。狀態(tài)流轉這里我也提醒一句不要直接生成“誰都能改狀態(tài)”的接口。事件狀態(tài)不是隨便跳的已結案不能退回待核實處置中不能跳過核實直接結案。我讓Hermes生成一個枚舉和狀態(tài)機校驗方法public enum EventStatus { PENDING(1, 待核實), VERIFYING(2, 核實中), HANDLING(3, 處置中), CLOSED(4, 已結案); private final int code; private final String text; EventStatus(int code, String text) { this.code code; this.text text; } }然后把合法的流轉關系放在一個Map里每次變更狀態(tài)前先校驗。這個邏輯代碼量很少但它決定了一個應急系統(tǒng)能不能用。如果狀態(tài)可以亂跳后面的結案統(tǒng)計、處置時限考核就全廢了。AI能幫你寫80%的代碼但這種業(yè)務規(guī)則人是必須親自確認的。4.3 接口自測讓AI順手生成一份最小化測試數據后端寫完我遇到一個很現實的問題接口邏輯對不對得拿數據去測。人工造數據實在太慢我讓Hermes寫了一個CommandLineRunner在應用啟動時自動插入測試數據5名用戶、3個角色、2個事件、若干物資記錄。這樣每次啟動應用都有現成的數據可以點擊驗證。這個做法極大加快了聯調速度但有一個坑測試數據會自動污染庫表。我的處理方式是在配置里加了一個開關本地開發(fā)和演示時才開啟生產環(huán)境絕不帶出去。類似這種“開發(fā)輔助代碼”AI是很樂于生成的但開工前就要約定好隔離方式否則測試數據混進正式環(huán)境后面清理起來非常痛苦。5. 前端頁面Cursor幫我寫出了80%的Vue組件后端接口有了前端頁面就進入了密集生產階段。這個階段的主工具從Hermes換成了Cursor原因很簡單前端頁面需要頻繁改文件、看效果、再改文件Cursor這種和編輯器深度綁定的AI效率最高。一次對話改完立刻能在瀏覽器里刷新驗證反饋回路非常短。5.1 頁面規(guī)劃和組件拆解我先把后臺管理端的頁面清單列出來登錄頁、系統(tǒng)布局、事件管理列表頁、事件新增/詳情頁、預案管理頁、物資管理頁、值班管理頁、信息報送頁、用戶管理頁、角色管理頁差不多10個頁面。然后讓Cursor按“布局組件、列表頁、表單頁”三種模式分別生成再逐個替換成真實接口。頁面規(guī)劃時有一個容易被忽略的技巧先讓Cursor生成一個統(tǒng)一的API請求封裝把Axios實例、請求攔截器、Token攜帶、錯誤提示都處理好。所有頁面共用這個封裝而不是讓每個頁面自己發(fā)請求。這一步看似不起眼但它是前端代碼風格統(tǒng)一的關鍵。沒有統(tǒng)一封裝每個頁面的請求代碼就會各寫各的后面維護起來非常痛苦。5.2 對話式生成一個事件管理頁當時讓Cursor生成事件列表頁我的指令是在src/views/event/index.vue里生成一個事件管理頁面用Element Plus的el-table展示事件列表包含事件編號、事件名稱、事件等級、事件狀態(tài)、報告時間、操作列支持分頁和狀態(tài)篩選操作列包含“詳情”和“流轉”按鈕調用/api/event/page接口。Cursor生成的頁面我只做了少量修改就接上了接口核心代碼結構類似這樣template div classpage-container el-card shadownever el-form :inlinetrue :modelquery el-form-item label事件名稱 el-input v-modelquery.keyword placeholder請輸入關鍵詞 clearable / /el-form-item el-form-item label事件狀態(tài) el-select v-modelquery.eventStatus placeholder全部 clearable el-option v-foritem in statusOptions :keyitem.value :labelitem.label :valueitem.value / /el-select /el-form-item el-form-item el-button typeprimary clickloadData查詢/el-button /el-form-item /el-form el-table :datatableData v-loadingloading border stripe el-table-column propeventCode label事件編號 min-width140 / el-table-column propeventName label事件名稱 min-width200 / el-table-column propeventLevel label等級 width80 template #default{ row } el-tag :typelevelType[row.eventLevel]{{ levelText[row.eventLevel] }}/el-tag /template /el-table-column el-table-column propeventStatus label狀態(tài) width90 template #default{ row } el-tag :typestatusType[row.eventStatus]{{ statusText[row.eventStatus] }}/el-tag /template /el-table-column el-table-column propreportTime label報告時間 width160 / el-table-column label操作 width150 fixedright template #default{ row } el-button link typeprimary clickopenDetail(row)詳情/el-button el-button link typewarning clickopenFlow(row)流轉/el-button /template /el-table-column /el-table el-pagination v-model:current-pagequery.pageNum v-model:page-sizequery.pageSize :totaltotal layouttotal, prev, pager, next current-changeloadData / /el-card /div /template這里特別想提醒一點AI生成的前端頁面默認情況下不會處理狀態(tài)枚舉的映射。事件狀態(tài)在數據庫里是1、2、3、4這樣的數字如果頁面上直接顯示數字用戶根本看不懂。我讓Cursor同時生成了statusText、statusType這類映射對象再用el-tag把狀態(tài)渲染成不同顏色的標簽。這個細節(jié)雖然小但決定了頁面是“能看”還是“能用”。5.3 接口對接和權限按鈕處理前端頁面接后端接口時最容易出問題的不是請求本身而是字段名對不上。AI生成的前端代碼可能默認后端返回的是camelCase字段而后端實體類某些字段是下劃線風格兩者一錯位頁面上全是undefined。我的解決辦法是在接口封裝層統(tǒng)一做字段映射或者在提示詞里一開始就規(guī)定“所有后端返回字段使用駝峰命名”讓兩邊從一開始就保持一致。經過這一天的實操我更推薦后者與其事后轉換不如源頭統(tǒng)一。權限按鈕的處理也值得單獨說。應急系統(tǒng)的操作按鈕不是每個人都可見普通業(yè)務員能看到“上報”按鈕科室負責人能看到“核實”按鈕領導能看到“結案”按鈕。Cursor可以在按鈕上加一個v-permission指令由權限指令根據當前用戶的按鈕權限列表決定是否渲染。這個能力是我在生成頁面時通過提示詞提前約定好的后面所有頁面統(tǒng)一復用避免每個頁面各寫各的判斷邏輯。6. 疾控應急系統(tǒng)里最容易翻車的兩個業(yè)務點狀態(tài)流轉和數據權限整天的開發(fā)里如果說有哪個環(huán)節(jié)讓我感覺“差點翻車”那一定是狀態(tài)流轉和數據權限。這兩個問題AI幾乎不可能自己意識到必須由懂業(yè)務的人主動提出來然后在需求設計階段就定好規(guī)則。6.1 事件狀態(tài)機AI默認只會做增刪改查我第一次讓Hermes做事件狀態(tài)管理時它生成的是一個簡單的updateStatus接口誰都可以調用傳什么狀態(tài)就改成什么狀態(tài)。從技術上這沒錯但從業(yè)務上這是災難。如果一條“已結案”的事件被誤操作改回“待核實”后面的處置時限統(tǒng)計、結案報表就全亂了。我把狀態(tài)流轉定義成“只允許從當前狀態(tài)經過合法動作進入下一狀態(tài)”核心流轉關系如下當前狀態(tài)允許的動作目標狀態(tài)待核實核實核實中待核實誤報關閉已關閉核實中啟動處置處置中處置中結案已結案處置中升級上報已上報此外狀態(tài)之間還必須記錄操作人和操作時間所以我讓Hermes補了一張狀態(tài)流轉日志表。加入之后領導在詳情頁可以看到一條事件的完整時間線幾點幾分誰做了核實幾點幾分誰啟動了處置。這在應急管理場景里非常關鍵。所以我建議凡是涉及“流程”的項目哪怕再簡單都要讓AI先生成“狀態(tài)動作校驗”三件套而不是簡單生成一個改狀態(tài)的接口。6.2 數據權限應急場景下“誰看誰的數據”不能一刀切疾控應急系統(tǒng)的用戶按層級分為省級中心、市級中心、區(qū)縣中心。默認規(guī)則是區(qū)縣中心只能看本轄區(qū)事件市級中心能看本市所有區(qū)縣省級中心能看全部。這就是數據權限問題。如果只用簡單的RBAC做權限控制它能控制“這個角色能不能訪問事件模塊”但控制不了“這個用戶能看哪幾條事件記錄”后者必須靠數據權限過濾實現。我的做法是在用戶表里存org_code在事件表里存事發(fā)地對應的org_code查詢時根據當前用戶的行政區(qū)劃級別動態(tài)拼接條件。這個邏輯對AI來說可以一次性生成但它不是一個自動出現的需求。如果你不告訴AI“應急系統(tǒng)需要按管轄層級控制數據可見范圍”AI交付的版本就一定是所有角色看到同一份數據。這也是我反復強調不要在需求設計階段省時間的原因——這個階段20分鐘的投入有可能幫你省掉寫完后一次大返工。7. Hermes部署與使用Windows環(huán)境下實測的幾個坑這一章寫給第一次接觸Hermes的讀者。我把自己在Windows本機部署和使用Hermes的過程以及當天遇到的幾個典型問題整理一下。需要說明的是具體命令和參數以你使用的版本和官方文檔為準但排查思路基本是通用的。7.1 部署流程和模型配置部署這類Agent框架/平臺流程通常是固定的先檢查本機環(huán)境主要看Python或Node版本是否滿足要求然后下載或拉取安裝包在項目目錄里安裝依賴接著配置模型的接入方式也就是模型服務的API地址和密鑰最后啟動服務在瀏覽器或客戶端里開始對話。當天我在自己本機操作時大致就是這個順序。裝依賴的過程花了一點時間整體不算復雜。配模型的時候有個細節(jié)值得注意不同模型對上下文長度和工具調用的支持不一樣部署之后第一件事應該是先跑一個最簡單的測試對話確認它能正常返回結果而不是直接丟一個需求任務過去。如果模型本身沒配好后面所有步驟都白搭。7.2 實際遇到的三類問題第一類是PowerShell執(zhí)行策略問題。在Windows上如果用了腳本啟動服務經常會遇到“無法加載文件因為在此系統(tǒng)上禁止運行腳本”之類的報錯。這個問題很好解決用管理員身份打開PowerShell執(zhí)行一次Set-ExecutionPolicy RemoteSigned再重試啟動腳本。第二類是端口占用。Agent服務默認端口可能被其他程序占了啟動時會報端口沖突。我的做法是啟動前先查一下端口占用情況被占用了就換一個端口不要硬剛。第三類是中文亂碼。如果Agent生成的文檔或日志在Windows終端里顯示亂碼大概率是終端編碼問題。把終端的代碼頁切到UTF-8或者在啟動命令里設置編碼參數問題一般就能解決。7.3 提示詞交互的實操技巧使用Hermes這類Agent和普通AI聊天的最大區(qū)別是它有一個“任務”的概念。你可以把一整天的需求設計變成一個任務讓它分步驟執(zhí)行中間會產出文檔、SQL、代碼片段。為了讓任務執(zhí)行得穩(wěn)我有幾個小技巧。第一每個任務的開頭先交代“角色目標約束”不要邊聊邊補因為補丁式對話會讓上下文越來越亂。第二如果任務里需要AI產出多個文件把文件清單和命名規(guī)則一次說清楚比如“實體類放com.example.entity包Controller放com.example.controller包”。第三如果AI中途給出了不滿意結果不要直接說“重寫”而是告訴它“哪一部分有問題改成什么方向”這樣它能保留正確的部分而不是推倒重來。提示Agent的生產結果一定要讓它在任務結束時匯總成一份清單比如“輸出本次生成的SQL文件清單、代碼文件清單”。這份清單方便你逐個核對也方便后續(xù)交給Cursor去落地。沒有清單AI生成的中間產物就會像散落一地的零件很難組織起來。8. 一天結束后的復盤時間都花在了哪里項目跑起來之后我做了一個效率復盤。這里把AI輔助開發(fā)和傳統(tǒng)方式的耗時對比放出來也把必須人盯的環(huán)節(jié)說清楚方便后面再做類似項目時有個參考。8.1 效率對比拿疾控應急管理系統(tǒng)來說如果按傳統(tǒng)開發(fā)方式需求設計加原型通常要3到5天前后端聯調再加一周很正常。而AI輔助下的實際耗時分布大概是環(huán)節(jié)傳統(tǒng)開發(fā)耗時AI輔助實際耗時主要省在哪里需求梳理和模塊設計2-3天2小時AI生成初稿人只做糾偏數據庫設計0.5-1天30分鐘建表SQL直接生成后端基礎CRUD2-3天3小時批量化生成實體和接口前端全部頁面4-5天4小時Cursor批量生成Vue組件聯調和修復2-3天2.5小時接口規(guī)范統(tǒng)一后問題大減為什么能省這么多核心在于大部分重復勞動的“代碼骨架”被AI包掉了人只需要做三件事在需求階段把業(yè)務規(guī)則定清楚在編碼階段把復雜邏輯確認好在聯調階段盯著字段和狀態(tài)流轉。剩下的重復代碼AI做得又快又不容易疲勞。8.2 必須人工把關的三個環(huán)節(jié)但我也要說清楚不是所有環(huán)節(jié)AI都省時間。至少有三個環(huán)節(jié)人必須親自盯否則后面一定會返工。第一個是狀態(tài)流轉和業(yè)務規(guī)則。AI默認的思維是“可修改”而業(yè)務要求是“可控制”這兩者之間的差距需要人來填。第二個是數據權限。它不是頁面上的一個功能而是貫穿所有查詢的橫切邏輯AI不會主動考慮到組織層級和數據范圍。第三個是接口字段的一致性。后端返回什么字段、前端用什么字段必須在一開始就約定好不然聯調階段會反復出現“頁面顯示undefined”的問題。8.3 后續(xù)擴展方向一天做完的版本定位是“可演示、可驗證、可繼續(xù)迭代”的基線版本不是生產級系統(tǒng)。如果要把這個系統(tǒng)繼續(xù)往前推我大概會按這個順序擴展第一步把文件上傳和附件管理補上比如事件現場照片和處置報告第二步接入大屏展示把事件分布、物資庫存、值班情況投到指揮中心的大屏第三步加上消息通知事件狀態(tài)變化時通過短信或站內信提醒相關人員第四步再做一套移動端H5方便現場人員用手機上報事件。每一層擴展都可以沿用當天的AI協(xié)作模式先讓Agent出方案再讓Cursor改代碼。如果讓我再做一遍這類項目我會在需求設計階段再多留半小時。設計階段省下的時間后面幾乎都會以返工的方式還回去。另一個經驗是下午四點半之后堅決不開新功能所有時間留給聯調和修bug。AI能幫你在一天內把系統(tǒng)“寫完”但“寫完”和“能用”之間隔著的那層細節(jié)——狀態(tài)能不能走通、權限遮沒遮對、按鈕點擊有沒有反應——永遠需要一雙人眼去盯。這也是AI開發(fā)這件事最真實的邊界。