尧图网页设计 
“一天做完一个系统又一个标题党吧。”说实话我以前也这么想。直到我真的把需求阶段和编码阶段完整跑了一遍用Hermes和Cursor这两个AI工具把疾控应急管理系统从0到1推出来才发现这条路的瓶颈根本不在AI写代码的能力而在你怎么安排需求设计和编码的顺序、怎么给AI喂上下文。这篇文章不是标题党而是一份真实的“1天交付”实测记录内容覆盖需求设计、数据建模、后端编码、前端生成和最终联调的完整流程也把这一天里踩过的坑、返过工的地方原原本本写出来。好吧先交代系统的最终状态。这是一个可以本地跑起来的疾控应急管理系统包含事件登记、事件分级流转、预案管理、物资台账、值班排班和信息报送6个核心模块。后端是Spring Boot 3 MyBatis Plus MySQL 8前端是Vue 3 Element Plus Pinia数据库一共13张表前后端加起来差不多6500行代码。从早上8点半开始做需求设计到晚上7点完成最后一轮联调刚好一天。适合谁看如果你是准备做管理系统类项目的全栈开发者或者正在纠结“AI到底能不能帮我快速搭一套可演示的业务系统”这篇文章能给你一份可以直接抄的作业。写在前面的一个重要观点我并不是在鼓吹“AI替代程序员”。这篇记录真正想说的是AI辅助开发这件事成败关键不在模型强不强而在你对项目主次怎么安排。先想清楚哪部分让AI全权哪部分必须人来把最后一关效率差距才能真正拉开。1. 为什么选Hermes Cursor先搞清楚这俩工具各管哪一段很多人一提到“AI编程”第一反应就是打开某个聊窗口把需求一股脑丢进去等着AI吐出一个能运行的项目。我可以负责任地说对于“从0到1做一个完整管理系统”这种任务这条路走不通。我的做法是把任务拆成两半交给两个各有侧重的工具反倒在一天内跑通了。1.1 Hermes在项目里扮演的角色Hermes是一个通用型的AI Agent智能体框架/平台核心能力是你给它一个自然语言目标它会自己拆解任务、调用工具、维护上下文并把中间产物保存下来。在需求设计阶段我让它当“业务分析师架构师”负责把“疾控应急管理系统”这一句话拆成功能模块再拆成数据表字段最后输出建表SQL和接口清单。到编码阶段我又让它当“代码生成器”按模块批量产出Controller、Service、Mapper的基础代码。为什么需要这样一个角色因为实际开发里最消耗精力的不是“写某一段代码”而是“代码之间能不能串起来”。Hermes这种Agent会把上下文保持在同一个任务流里不像普通聊天框那样聊三页就忘开头。这一点在一天内做完整系统的场景下非常关键——没有连贯的上下文就没有连贯的项目。1.2 Cursor在项目里扮演的角色Cursor是一个AI原生的代码编辑器可以理解成“长了AI脑子的VS Code”。它负责的是“在具体代码文件里真正动手”改一个方法、补一个字段、把一个静态页面改成带接口请求的Vue组件。我的用法很简单项目在Cursor里打开遇到问题直接在编辑器里对话让它定位文件、给出修改方案、应用修改我立刻编译验证循环往复。Hermes和Cursor的分工我后来总结成一句话Hermes管“方案”Cursor管“落地”。Hermes不改具体文件它的产出是文档、SQL、代码片段帮我把全局设计定住Cursor在工程里改文件让方案变成一个能运行的系统。两者一旦混淆就会出现一种尴尬场面Hermes生成了大量代码但没法集成进项目或者Cursor改了一堆文件但缺乏全局设计越改越乱。1.3 为什么不用纯对话式AI一把梭我试过用纯对话式AI一口气输出整个项目结果很惨。第一上下文会失控项目一复杂AI就开始编造不存在的表和字段第二项目不是单个文件而是几十个文件的组合对话式AI给不了你“如何组织这些文件”的连贯方案第三改需求时对话式AI缺少“落地到项目里”的能力你需要手动复制粘贴来回几次就乱套。用Hermes Cursor的组合本质上是给AI开发加了一套“流程约束”先让Agent产出文档和方案再让编辑器AI在工程里落地。这套思路不绑定某一个特定模型我用的是本地部署的Hermes配的是模型API服务你换其他Agent框架搭配Cursor思路一样成立。关键是把“规划”和“执行”分开让每个AI做自己最擅长的事。2. 一天的时间线为什么需求设计必须排在编码前面听完这个选题我同事的第一反应是一天做系统肯定全程都在写代码吧其实不是。真实的顺序是上午先花90分钟做需求设计和数据库建模再花60分钟部署工具、搭项目骨架真正的密集编码集中在下午。很多人觉得“时间紧就应该跳过设计直接写”这恰恰是最容易被返工拖垮的做法。2.1 全天时间安排下面是我实际执行的时间表时间段工作内容用到的工具交付物8:30-10:00需求拆解、模块划分、数据模型设计Hermes需求清单、模块清单、数据库设计初稿10:00-11:00部署Hermes、配置Cursor、初始化项目骨架Hermes Cursor可运行的空项目11:00-14:00后端编码实体、接口、业务逻辑Hermes Cursor后端核心接口可调用14:00-17:00前端编码页面、接口对接、权限Cursor管理端主要页面17:00-19:00联调、修bug、状态机完善Cursor可演示的完整系统这张表值得注意的不是“几点做什么”而是每一步的依赖关系。没有前一步的交付物后一步就会停摆建表SQL没定后端实体没法写接口路径没定前端页面没法接登录权限没定页面做完了也没法演示。AI开发并不会改变软件开发的基本逻辑它只是把每个环节的耗时压缩了。所以安排一整天的工程本质上是在安排“交付物的顺序”。2.2 为什么“先跑通空项目”优先级这么高上午10点到11点我的任务是部署Hermes、配置Cursor以及初始化一个能运行的空项目骨架。这里我给自己定的硬性要求是11点之前新建项目的首页必须在浏览器里能打开后端健康检查接口必须能通。因为后续所有AI生成的代码都需要一个能运行的环境去验证。骨架没搭好AI生成再多代码你也没法立刻看到效果错误就会不断叠加。这个空项目我把它叫作“验证脚手架”。它不需要包含任何业务代码但要包含完整的依赖配置、统一返回结果类、异常处理器、MyBatis Plus配置和前端的基础布局。有了这个脚手架Hermes生成的后端代码可以直接扔进对应的包路径里Cursor生成的前端页面可以直接替换掉脚手架里的占位组件AI的产出才能被快速验证、快速迭代。如果不先做这一步后面所有AI生成的代码都只是在“纸面运行”效率会大打折扣。2.3 把接口规范提前钉死在设计阶段需求设计可以快但不代表字段和接口规范可以含糊。在上午的需求设计阶段除了生成模块清单和SQL我还做了第二件事让Hermes产出一份接口路径规范。比如事件模块统一以/api/event开头列表用POST /api/event/page新增用POST /api/event状态变更用PUT /api/event/{id}/status返回格式统一是ResultT。这个规范在前端开发时帮我省下了大量沟通成本。这个动作在传统开发里可能要开一次接口评审会但在AI辅助流程里只是给Hermes的提示词里多了一句“请一并输出接口路径清单使用RESTful风格”。然而正是这一句话决定了下午前端对接时是顺畅还是崩溃。接口规范一旦不定前端AI和后端AI就会各写各的最后联调阶段一定会出现“字段对不上、路径对不上、返回格式对不上”的三重灾难。3. 需求设计怎样把“疾控应急管理系统”拆成AI能懂的模块需求设计这个环节在传统流程里至少要开两三次会但在AI辅助下我把它压缩成一个提示词加几轮追问。不过压缩的是时间不是思考。恰恰因为AI产出的速度太快人要做的那几次纠偏就显得更加关键。3.1 让Hermes产出模块清单的提示词我给Hermes的第一条提示词是这样写的你是一名公共卫生应急领域的系统分析师。我需要你帮我做需求设计。 项目疾控应急管理系统。 核心业务对突发公共卫生事件进行登记、分级、流转处置、应急物资调配、预案管理和值班管理。 目标用户疾控中心业务人员、应急办管理人员、中心领导。 请输出 1. 功能模块清单 2. 每个模块下的核心子功能 3. 涉及的实体对象和关键字段建议。 约束 - 面向省级疾控中心场景多科室、多角色协作 - 需要有事件全流程状态管理 - 需要数据权限不同角色看到的数据范围不同 - 不需要复杂的财务和审批流。注意提示词里我特意写了两类信息一类是业务范围即“吃什么”一类是约束条件即“不吃什么”。这是AI能给出准确需求设计的关键。如果你只写“帮我设计一个应急管理系统”AI会给出一堆大而全但没法落地的功能比如“智慧预警”“大数据分析”这些对一天可交付的项目来说全是坑。约束写得越清楚AI产出的模块越克制后面写代码时就越不容易跑偏。3.2 生成的模块清单和核心表结构Hermes在几分钟内给出的模块清单基本覆盖了核心业务。它列出的模块包括应急事件模块负责事件登记、事件分级、状态流转和查询预案管理模块负责预案录入、版本管理和启动记录物资管理模块负责物资台账、出入库记录和库存预警值班管理模块负责排班、值班日志和交接班记录信息报送模块负责报送单生成、逐级上报和处置反馈系统管理模块负责用户、角色、菜单权限和操作日志。基于这份清单我继续让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 状态: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 事发地点, description TEXT NULL COMMENT 事件描述, org_code VARCHAR(32) NULL COMMENT 所属区域编码, create_by BIGINT NULL COMMENT 创建人ID, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, 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字段因为后面做数据权限过滤要用它区分“这个事件属于哪个辖区”。第二给状态和报告时间加了索引因为应急事件查询基本都会按这两个条件过滤。其他12张表包括预案表、物资表、出入库明细表、值班表、报送单表、用户角色表等我基本没做大改直接放进了初始化脚本。3.3 人必须做的纠偏AI会“想当然”的三个例子但这里要说一个真实问题AI生成的需求设计表面合理但有几个地方是“想当然”的必须人工修正。第一AI默认所有列表都是单表查询。实际上应急事件列表往往要关联用户表显示处理人姓名关联报送单显示最新处置进度。如果一开始没提醒它后面接口会越写越复杂甚至要推翻重来。我现在的做法是在提示词里约定“列表查询需要支持多表关联返回VO对象”让它在设计阶段就把这个因素考虑进去。第二AI不会主动考虑逻辑删除。疾控应急事件作为业务数据不能物理删除只能逻辑删除。我必须在提示词里明确“所有业务表需要逻辑删除字段”并让Hermes在SQL里统一补上deleted字段。这条约束如果漏了后面删除接口就会直接把记录抹掉在真实业务场景下是绝对不允许的。第三AI对“数据权限”的理解容易停留在“有权限就能访问模块”的层面。在真实应急场景里区县疾控中心只能看本辖区事件省级中心才能看全部。所以我在表设计时增加了org_code把数据范围的维度提前落到表结构里。这些纠偏花了我大概20分钟。如果跳过这一步直接让AI写代码后面改起来就不是20分钟能解决的问题了。4. 后端编码从建表SQL到业务接口的AI协作节奏需求定完建表SQL有了数据库13张表全部建好之后就进入了全天工作量最大的后端编码阶段。这个阶段我又拆成了三步先生成基础代码再写复杂业务最后做接口自测。4.1 实体和基础CRUD批量生成的正确姿势拿到建表SQL之后传统做法是一个表一个Controller、Service、Mapper地去写非常机械。我把建表语句直接丢给Hermes让它按MyBatis Plus规范生成实体类和基础CRUD接口。这里的关键是提示词里要明确项目规范否则AI生成出来的代码风格会五花八门。我当时的规范约束是这些统一返回结果类型ResultT、统一异常处理、逻辑删除字段用TableLogic注解、主键用雪花算法、时间字段用LocalDateTime。把这些规范写成一个约束段落放进提示词AI生成的代码风格就会统一。我抽查了几个生成出来的实体类基本符合预期。比如事件实体里的关键字段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同样中规中矩分页查询、新增、修改、删除、详情五个接口一次给全。这个阶段的目标不是炫技而是把重复劳动快速做完给后面的复杂业务留出时间。基础代码这种活AI最擅长人也最不该在它身上浪费太多时间。4.2 复杂查询和状态流转这部分必须人盯基础CRUD生成完我开始处理真正体现业务价值的两个部分一个是应急事件的多条件分页查询一个是事件状态流转。多条件分页查询这种带动态条件的逻辑我让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); }这段代码本身不难但里面藏着一个容易遗漏的逻辑数据权限。当前用户是区县角色时查询条件里必须强制拼上org_code 当前用户辖区。这个条件是动态拼进去的普通开发很容易忘了在列表页加导致某个区县的人看到了全省的事件这在应急场景下是严重的数据越权。我把这个逻辑单拎出来写成了一个DataScopeHelper所有列表查询统一走这个Helper而不是在每个Service里各写各的。状态流转这里我也提醒一句不要直接生成“谁都能改状态”的接口。事件状态不是随便跳的已结案不能退回待核实处置中不能跳过核实直接结案。我让Hermes生成一个枚举和状态机校验方法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里每次变更状态前先校验。这个逻辑代码量很少但它决定了一个应急系统能不能用。如果状态可以乱跳后面的结案统计、处置时限考核就全废了。AI能帮你写80%的代码但这种业务规则人是必须亲自确认的。4.3 接口自测让AI顺手生成一份最小化测试数据后端写完我遇到一个很现实的问题接口逻辑对不对得拿数据去测。人工造数据实在太慢我让Hermes写了一个CommandLineRunner在应用启动时自动插入测试数据5名用户、3个角色、2个事件、若干物资记录。这样每次启动应用都有现成的数据可以点击验证。这个做法极大加快了联调速度但有一个坑测试数据会自动污染库表。我的处理方式是在配置里加了一个开关本地开发和演示时才开启生产环境绝不带出去。类似这种“开发辅助代码”AI是很乐于生成的但开工前就要约定好隔离方式否则测试数据混进正式环境后面清理起来非常痛苦。5. 前端页面Cursor帮我写出了80%的Vue组件后端接口有了前端页面就进入了密集生产阶段。这个阶段的主工具从Hermes换成了Cursor原因很简单前端页面需要频繁改文件、看效果、再改文件Cursor这种和编辑器深度绑定的AI效率最高。一次对话改完立刻能在浏览器里刷新验证反馈回路非常短。5.1 页面规划和组件拆解我先把后台管理端的页面清单列出来登录页、系统布局、事件管理列表页、事件新增/详情页、预案管理页、物资管理页、值班管理页、信息报送页、用户管理页、角色管理页差不多10个页面。然后让Cursor按“布局组件、列表页、表单页”三种模式分别生成再逐个替换成真实接口。页面规划时有一个容易被忽略的技巧先让Cursor生成一个统一的API请求封装把Axios实例、请求拦截器、Token携带、错误提示都处理好。所有页面共用这个封装而不是让每个页面自己发请求。这一步看似不起眼但它是前端代码风格统一的关键。没有统一封装每个页面的请求代码就会各写各的后面维护起来非常痛苦。5.2 对话式生成一个事件管理页当时让Cursor生成事件列表页我的指令是在src/views/event/index.vue里生成一个事件管理页面用Element Plus的el-table展示事件列表包含事件编号、事件名称、事件等级、事件状态、报告时间、操作列支持分页和状态筛选操作列包含“详情”和“流转”按钮调用/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事件状态 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状态 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生成的前端页面默认情况下不会处理状态枚举的映射。事件状态在数据库里是1、2、3、4这样的数字如果页面上直接显示数字用户根本看不懂。我让Cursor同时生成了statusText、statusType这类映射对象再用el-tag把状态渲染成不同颜色的标签。这个细节虽然小但决定了页面是“能看”还是“能用”。5.3 接口对接和权限按钮处理前端页面接后端接口时最容易出问题的不是请求本身而是字段名对不上。AI生成的前端代码可能默认后端返回的是camelCase字段而后端实体类某些字段是下划线风格两者一错位页面上全是undefined。我的解决办法是在接口封装层统一做字段映射或者在提示词里一开始就规定“所有后端返回字段使用驼峰命名”让两边从一开始就保持一致。经过这一天的实操我更推荐后者与其事后转换不如源头统一。权限按钮的处理也值得单独说。应急系统的操作按钮不是每个人都可见普通业务员能看到“上报”按钮科室负责人能看到“核实”按钮领导能看到“结案”按钮。Cursor可以在按钮上加一个v-permission指令由权限指令根据当前用户的按钮权限列表决定是否渲染。这个能力是我在生成页面时通过提示词提前约定好的后面所有页面统一复用避免每个页面各写各的判断逻辑。6. 疾控应急系统里最容易翻车的两个业务点状态流转和数据权限整天的开发里如果说有哪个环节让我感觉“差点翻车”那一定是状态流转和数据权限。这两个问题AI几乎不可能自己意识到必须由懂业务的人主动提出来然后在需求设计阶段就定好规则。6.1 事件状态机AI默认只会做增删改查我第一次让Hermes做事件状态管理时它生成的是一个简单的updateStatus接口谁都可以调用传什么状态就改成什么状态。从技术上这没错但从业务上这是灾难。如果一条“已结案”的事件被误操作改回“待核实”后面的处置时限统计、结案报表就全乱了。我把状态流转定义成“只允许从当前状态经过合法动作进入下一状态”核心流转关系如下当前状态允许的动作目标状态待核实核实核实中待核实误报关闭已关闭核实中启动处置处置中处置中结案已结案处置中升级上报已上报此外状态之间还必须记录操作人和操作时间所以我让Hermes补了一张状态流转日志表。加入之后领导在详情页可以看到一条事件的完整时间线几点几分谁做了核实几点几分谁启动了处置。这在应急管理场景里非常关键。所以我建议凡是涉及“流程”的项目哪怕再简单都要让AI先生成“状态动作校验”三件套而不是简单生成一个改状态的接口。6.2 数据权限应急场景下“谁看谁的数据”不能一刀切疾控应急系统的用户按层级分为省级中心、市级中心、区县中心。默认规则是区县中心只能看本辖区事件市级中心能看本市所有区县省级中心能看全部。这就是数据权限问题。如果只用简单的RBAC做权限控制它能控制“这个角色能不能访问事件模块”但控制不了“这个用户能看哪几条事件记录”后者必须靠数据权限过滤实现。我的做法是在用户表里存org_code在事件表里存事发地对应的org_code查询时根据当前用户的行政区划级别动态拼接条件。这个逻辑对AI来说可以一次性生成但它不是一个自动出现的需求。如果你不告诉AI“应急系统需要按管辖层级控制数据可见范围”AI交付的版本就一定是所有角色看到同一份数据。这也是我反复强调不要在需求设计阶段省时间的原因——这个阶段20分钟的投入有可能帮你省掉写完后一次大返工。7. Hermes部署与使用Windows环境下实测的几个坑这一章写给第一次接触Hermes的读者。我把自己在Windows本机部署和使用Hermes的过程以及当天遇到的几个典型问题整理一下。需要说明的是具体命令和参数以你使用的版本和官方文档为准但排查思路基本是通用的。7.1 部署流程和模型配置部署这类Agent框架/平台流程通常是固定的先检查本机环境主要看Python或Node版本是否满足要求然后下载或拉取安装包在项目目录里安装依赖接着配置模型的接入方式也就是模型服务的API地址和密钥最后启动服务在浏览器或客户端里开始对话。当天我在自己本机操作时大致就是这个顺序。装依赖的过程花了一点时间整体不算复杂。配模型的时候有个细节值得注意不同模型对上下文长度和工具调用的支持不一样部署之后第一件事应该是先跑一个最简单的测试对话确认它能正常返回结果而不是直接丢一个需求任务过去。如果模型本身没配好后面所有步骤都白搭。7.2 实际遇到的三类问题第一类是PowerShell执行策略问题。在Windows上如果用了脚本启动服务经常会遇到“无法加载文件因为在此系统上禁止运行脚本”之类的报错。这个问题很好解决用管理员身份打开PowerShell执行一次Set-ExecutionPolicy RemoteSigned再重试启动脚本。第二类是端口占用。Agent服务默认端口可能被其他程序占了启动时会报端口冲突。我的做法是启动前先查一下端口占用情况被占用了就换一个端口不要硬刚。第三类是中文乱码。如果Agent生成的文档或日志在Windows终端里显示乱码大概率是终端编码问题。把终端的代码页切到UTF-8或者在启动命令里设置编码参数问题一般就能解决。7.3 提示词交互的实操技巧使用Hermes这类Agent和普通AI聊天的最大区别是它有一个“任务”的概念。你可以把一整天的需求设计变成一个任务让它分步骤执行中间会产出文档、SQL、代码片段。为了让任务执行得稳我有几个小技巧。第一每个任务的开头先交代“角色目标约束”不要边聊边补因为补丁式对话会让上下文越来越乱。第二如果任务里需要AI产出多个文件把文件清单和命名规则一次说清楚比如“实体类放com.example.entity包Controller放com.example.controller包”。第三如果AI中途给出了不满意结果不要直接说“重写”而是告诉它“哪一部分有问题改成什么方向”这样它能保留正确的部分而不是推倒重来。提示Agent的生产结果一定要让它在任务结束时汇总成一份清单比如“输出本次生成的SQL文件清单、代码文件清单”。这份清单方便你逐个核对也方便后续交给Cursor去落地。没有清单AI生成的中间产物就会像散落一地的零件很难组织起来。8. 一天结束后的复盘时间都花在了哪里项目跑起来之后我做了一个效率复盘。这里把AI辅助开发和传统方式的耗时对比放出来也把必须人盯的环节说清楚方便后面再做类似项目时有个参考。8.1 效率对比拿疾控应急管理系统来说如果按传统开发方式需求设计加原型通常要3到5天前后端联调再加一周很正常。而AI辅助下的实际耗时分布大概是环节传统开发耗时AI辅助实际耗时主要省在哪里需求梳理和模块设计2-3天2小时AI生成初稿人只做纠偏数据库设计0.5-1天30分钟建表SQL直接生成后端基础CRUD2-3天3小时批量化生成实体和接口前端全部页面4-5天4小时Cursor批量生成Vue组件联调和修复2-3天2.5小时接口规范统一后问题大减为什么能省这么多核心在于大部分重复劳动的“代码骨架”被AI包掉了人只需要做三件事在需求阶段把业务规则定清楚在编码阶段把复杂逻辑确认好在联调阶段盯着字段和状态流转。剩下的重复代码AI做得又快又不容易疲劳。8.2 必须人工把关的三个环节但我也要说清楚不是所有环节AI都省时间。至少有三个环节人必须亲自盯否则后面一定会返工。第一个是状态流转和业务规则。AI默认的思维是“可修改”而业务要求是“可控制”这两者之间的差距需要人来填。第二个是数据权限。它不是页面上的一个功能而是贯穿所有查询的横切逻辑AI不会主动考虑到组织层级和数据范围。第三个是接口字段的一致性。后端返回什么字段、前端用什么字段必须在一开始就约定好不然联调阶段会反复出现“页面显示undefined”的问题。8.3 后续扩展方向一天做完的版本定位是“可演示、可验证、可继续迭代”的基线版本不是生产级系统。如果要把这个系统继续往前推我大概会按这个顺序扩展第一步把文件上传和附件管理补上比如事件现场照片和处置报告第二步接入大屏展示把事件分布、物资库存、值班情况投到指挥中心的大屏第三步加上消息通知事件状态变化时通过短信或站内信提醒相关人员第四步再做一套移动端H5方便现场人员用手机上报事件。每一层扩展都可以沿用当天的AI协作模式先让Agent出方案再让Cursor改代码。如果让我再做一遍这类项目我会在需求设计阶段再多留半小时。设计阶段省下的时间后面几乎都会以返工的方式还回去。另一个经验是下午四点半之后坚决不开新功能所有时间留给联调和修bug。AI能帮你在一天内把系统“写完”但“写完”和“能用”之间隔着的那层细节——状态能不能走通、权限遮没遮对、按钮点击有没有反应——永远需要一双人眼去盯。这也是AI开发这件事最真实的边界。 AI辅助开发实战：一天从0到1交付疾控应急管理系统
“一天做完一个系统又一个标题党吧。”说实话我以前也这么想。直到我真的把需求阶段和编码阶段完整跑了一遍用Hermes和Cursor这两个AI工具把疾控应急管理系统从0到1推出来才发现这条路的瓶颈根本不在AI写代码的能力而在你怎么安排需求设计和编码的顺序、怎么给AI喂上下文。这篇文章不是标题党而是一份真实的“1天交付”实测记录内容覆盖需求设计、数据建模、后端编码、前端生成和最终联调的完整流程也把这一天里踩过的坑、返过工的地方原原本本写出来。好吧先交代系统的最终状态。这是一个可以本地跑起来的疾控应急管理系统包含事件登记、事件分级流转、预案管理、物资台账、值班排班和信息报送6个核心模块。后端是Spring Boot 3 MyBatis Plus MySQL 8前端是Vue 3 Element Plus Pinia数据库一共13张表前后端加起来差不多6500行代码。从早上8点半开始做需求设计到晚上7点完成最后一轮联调刚好一天。适合谁看如果你是准备做管理系统类项目的全栈开发者或者正在纠结“AI到底能不能帮我快速搭一套可演示的业务系统”这篇文章能给你一份可以直接抄的作业。写在前面的一个重要观点我并不是在鼓吹“AI替代程序员”。这篇记录真正想说的是AI辅助开发这件事成败关键不在模型强不强而在你对项目主次怎么安排。先想清楚哪部分让AI全权哪部分必须人来把最后一关效率差距才能真正拉开。1. 为什么选Hermes Cursor先搞清楚这俩工具各管哪一段很多人一提到“AI编程”第一反应就是打开某个聊窗口把需求一股脑丢进去等着AI吐出一个能运行的项目。我可以负责任地说对于“从0到1做一个完整管理系统”这种任务这条路走不通。我的做法是把任务拆成两半交给两个各有侧重的工具反倒在一天内跑通了。1.1 Hermes在项目里扮演的角色Hermes是一个通用型的AI Agent智能体框架/平台核心能力是你给它一个自然语言目标它会自己拆解任务、调用工具、维护上下文并把中间产物保存下来。在需求设计阶段我让它当“业务分析师架构师”负责把“疾控应急管理系统”这一句话拆成功能模块再拆成数据表字段最后输出建表SQL和接口清单。到编码阶段我又让它当“代码生成器”按模块批量产出Controller、Service、Mapper的基础代码。为什么需要这样一个角色因为实际开发里最消耗精力的不是“写某一段代码”而是“代码之间能不能串起来”。Hermes这种Agent会把上下文保持在同一个任务流里不像普通聊天框那样聊三页就忘开头。这一点在一天内做完整系统的场景下非常关键——没有连贯的上下文就没有连贯的项目。1.2 Cursor在项目里扮演的角色Cursor是一个AI原生的代码编辑器可以理解成“长了AI脑子的VS Code”。它负责的是“在具体代码文件里真正动手”改一个方法、补一个字段、把一个静态页面改成带接口请求的Vue组件。我的用法很简单项目在Cursor里打开遇到问题直接在编辑器里对话让它定位文件、给出修改方案、应用修改我立刻编译验证循环往复。Hermes和Cursor的分工我后来总结成一句话Hermes管“方案”Cursor管“落地”。Hermes不改具体文件它的产出是文档、SQL、代码片段帮我把全局设计定住Cursor在工程里改文件让方案变成一个能运行的系统。两者一旦混淆就会出现一种尴尬场面Hermes生成了大量代码但没法集成进项目或者Cursor改了一堆文件但缺乏全局设计越改越乱。1.3 为什么不用纯对话式AI一把梭我试过用纯对话式AI一口气输出整个项目结果很惨。第一上下文会失控项目一复杂AI就开始编造不存在的表和字段第二项目不是单个文件而是几十个文件的组合对话式AI给不了你“如何组织这些文件”的连贯方案第三改需求时对话式AI缺少“落地到项目里”的能力你需要手动复制粘贴来回几次就乱套。用Hermes Cursor的组合本质上是给AI开发加了一套“流程约束”先让Agent产出文档和方案再让编辑器AI在工程里落地。这套思路不绑定某一个特定模型我用的是本地部署的Hermes配的是模型API服务你换其他Agent框架搭配Cursor思路一样成立。关键是把“规划”和“执行”分开让每个AI做自己最擅长的事。2. 一天的时间线为什么需求设计必须排在编码前面听完这个选题我同事的第一反应是一天做系统肯定全程都在写代码吧其实不是。真实的顺序是上午先花90分钟做需求设计和数据库建模再花60分钟部署工具、搭项目骨架真正的密集编码集中在下午。很多人觉得“时间紧就应该跳过设计直接写”这恰恰是最容易被返工拖垮的做法。2.1 全天时间安排下面是我实际执行的时间表时间段工作内容用到的工具交付物8:30-10:00需求拆解、模块划分、数据模型设计Hermes需求清单、模块清单、数据库设计初稿10:00-11:00部署Hermes、配置Cursor、初始化项目骨架Hermes Cursor可运行的空项目11:00-14:00后端编码实体、接口、业务逻辑Hermes Cursor后端核心接口可调用14:00-17:00前端编码页面、接口对接、权限Cursor管理端主要页面17:00-19:00联调、修bug、状态机完善Cursor可演示的完整系统这张表值得注意的不是“几点做什么”而是每一步的依赖关系。没有前一步的交付物后一步就会停摆建表SQL没定后端实体没法写接口路径没定前端页面没法接登录权限没定页面做完了也没法演示。AI开发并不会改变软件开发的基本逻辑它只是把每个环节的耗时压缩了。所以安排一整天的工程本质上是在安排“交付物的顺序”。2.2 为什么“先跑通空项目”优先级这么高上午10点到11点我的任务是部署Hermes、配置Cursor以及初始化一个能运行的空项目骨架。这里我给自己定的硬性要求是11点之前新建项目的首页必须在浏览器里能打开后端健康检查接口必须能通。因为后续所有AI生成的代码都需要一个能运行的环境去验证。骨架没搭好AI生成再多代码你也没法立刻看到效果错误就会不断叠加。这个空项目我把它叫作“验证脚手架”。它不需要包含任何业务代码但要包含完整的依赖配置、统一返回结果类、异常处理器、MyBatis Plus配置和前端的基础布局。有了这个脚手架Hermes生成的后端代码可以直接扔进对应的包路径里Cursor生成的前端页面可以直接替换掉脚手架里的占位组件AI的产出才能被快速验证、快速迭代。如果不先做这一步后面所有AI生成的代码都只是在“纸面运行”效率会大打折扣。2.3 把接口规范提前钉死在设计阶段需求设计可以快但不代表字段和接口规范可以含糊。在上午的需求设计阶段除了生成模块清单和SQL我还做了第二件事让Hermes产出一份接口路径规范。比如事件模块统一以/api/event开头列表用POST /api/event/page新增用POST /api/event状态变更用PUT /api/event/{id}/status返回格式统一是ResultT。这个规范在前端开发时帮我省下了大量沟通成本。这个动作在传统开发里可能要开一次接口评审会但在AI辅助流程里只是给Hermes的提示词里多了一句“请一并输出接口路径清单使用RESTful风格”。然而正是这一句话决定了下午前端对接时是顺畅还是崩溃。接口规范一旦不定前端AI和后端AI就会各写各的最后联调阶段一定会出现“字段对不上、路径对不上、返回格式对不上”的三重灾难。3. 需求设计怎样把“疾控应急管理系统”拆成AI能懂的模块需求设计这个环节在传统流程里至少要开两三次会但在AI辅助下我把它压缩成一个提示词加几轮追问。不过压缩的是时间不是思考。恰恰因为AI产出的速度太快人要做的那几次纠偏就显得更加关键。3.1 让Hermes产出模块清单的提示词我给Hermes的第一条提示词是这样写的你是一名公共卫生应急领域的系统分析师。我需要你帮我做需求设计。 项目疾控应急管理系统。 核心业务对突发公共卫生事件进行登记、分级、流转处置、应急物资调配、预案管理和值班管理。 目标用户疾控中心业务人员、应急办管理人员、中心领导。 请输出 1. 功能模块清单 2. 每个模块下的核心子功能 3. 涉及的实体对象和关键字段建议。 约束 - 面向省级疾控中心场景多科室、多角色协作 - 需要有事件全流程状态管理 - 需要数据权限不同角色看到的数据范围不同 - 不需要复杂的财务和审批流。注意提示词里我特意写了两类信息一类是业务范围即“吃什么”一类是约束条件即“不吃什么”。这是AI能给出准确需求设计的关键。如果你只写“帮我设计一个应急管理系统”AI会给出一堆大而全但没法落地的功能比如“智慧预警”“大数据分析”这些对一天可交付的项目来说全是坑。约束写得越清楚AI产出的模块越克制后面写代码时就越不容易跑偏。3.2 生成的模块清单和核心表结构Hermes在几分钟内给出的模块清单基本覆盖了核心业务。它列出的模块包括应急事件模块负责事件登记、事件分级、状态流转和查询预案管理模块负责预案录入、版本管理和启动记录物资管理模块负责物资台账、出入库记录和库存预警值班管理模块负责排班、值班日志和交接班记录信息报送模块负责报送单生成、逐级上报和处置反馈系统管理模块负责用户、角色、菜单权限和操作日志。基于这份清单我继续让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 状态: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 事发地点, description TEXT NULL COMMENT 事件描述, org_code VARCHAR(32) NULL COMMENT 所属区域编码, create_by BIGINT NULL COMMENT 创建人ID, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, 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字段因为后面做数据权限过滤要用它区分“这个事件属于哪个辖区”。第二给状态和报告时间加了索引因为应急事件查询基本都会按这两个条件过滤。其他12张表包括预案表、物资表、出入库明细表、值班表、报送单表、用户角色表等我基本没做大改直接放进了初始化脚本。3.3 人必须做的纠偏AI会“想当然”的三个例子但这里要说一个真实问题AI生成的需求设计表面合理但有几个地方是“想当然”的必须人工修正。第一AI默认所有列表都是单表查询。实际上应急事件列表往往要关联用户表显示处理人姓名关联报送单显示最新处置进度。如果一开始没提醒它后面接口会越写越复杂甚至要推翻重来。我现在的做法是在提示词里约定“列表查询需要支持多表关联返回VO对象”让它在设计阶段就把这个因素考虑进去。第二AI不会主动考虑逻辑删除。疾控应急事件作为业务数据不能物理删除只能逻辑删除。我必须在提示词里明确“所有业务表需要逻辑删除字段”并让Hermes在SQL里统一补上deleted字段。这条约束如果漏了后面删除接口就会直接把记录抹掉在真实业务场景下是绝对不允许的。第三AI对“数据权限”的理解容易停留在“有权限就能访问模块”的层面。在真实应急场景里区县疾控中心只能看本辖区事件省级中心才能看全部。所以我在表设计时增加了org_code把数据范围的维度提前落到表结构里。这些纠偏花了我大概20分钟。如果跳过这一步直接让AI写代码后面改起来就不是20分钟能解决的问题了。4. 后端编码从建表SQL到业务接口的AI协作节奏需求定完建表SQL有了数据库13张表全部建好之后就进入了全天工作量最大的后端编码阶段。这个阶段我又拆成了三步先生成基础代码再写复杂业务最后做接口自测。4.1 实体和基础CRUD批量生成的正确姿势拿到建表SQL之后传统做法是一个表一个Controller、Service、Mapper地去写非常机械。我把建表语句直接丢给Hermes让它按MyBatis Plus规范生成实体类和基础CRUD接口。这里的关键是提示词里要明确项目规范否则AI生成出来的代码风格会五花八门。我当时的规范约束是这些统一返回结果类型ResultT、统一异常处理、逻辑删除字段用TableLogic注解、主键用雪花算法、时间字段用LocalDateTime。把这些规范写成一个约束段落放进提示词AI生成的代码风格就会统一。我抽查了几个生成出来的实体类基本符合预期。比如事件实体里的关键字段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同样中规中矩分页查询、新增、修改、删除、详情五个接口一次给全。这个阶段的目标不是炫技而是把重复劳动快速做完给后面的复杂业务留出时间。基础代码这种活AI最擅长人也最不该在它身上浪费太多时间。4.2 复杂查询和状态流转这部分必须人盯基础CRUD生成完我开始处理真正体现业务价值的两个部分一个是应急事件的多条件分页查询一个是事件状态流转。多条件分页查询这种带动态条件的逻辑我让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); }这段代码本身不难但里面藏着一个容易遗漏的逻辑数据权限。当前用户是区县角色时查询条件里必须强制拼上org_code 当前用户辖区。这个条件是动态拼进去的普通开发很容易忘了在列表页加导致某个区县的人看到了全省的事件这在应急场景下是严重的数据越权。我把这个逻辑单拎出来写成了一个DataScopeHelper所有列表查询统一走这个Helper而不是在每个Service里各写各的。状态流转这里我也提醒一句不要直接生成“谁都能改状态”的接口。事件状态不是随便跳的已结案不能退回待核实处置中不能跳过核实直接结案。我让Hermes生成一个枚举和状态机校验方法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里每次变更状态前先校验。这个逻辑代码量很少但它决定了一个应急系统能不能用。如果状态可以乱跳后面的结案统计、处置时限考核就全废了。AI能帮你写80%的代码但这种业务规则人是必须亲自确认的。4.3 接口自测让AI顺手生成一份最小化测试数据后端写完我遇到一个很现实的问题接口逻辑对不对得拿数据去测。人工造数据实在太慢我让Hermes写了一个CommandLineRunner在应用启动时自动插入测试数据5名用户、3个角色、2个事件、若干物资记录。这样每次启动应用都有现成的数据可以点击验证。这个做法极大加快了联调速度但有一个坑测试数据会自动污染库表。我的处理方式是在配置里加了一个开关本地开发和演示时才开启生产环境绝不带出去。类似这种“开发辅助代码”AI是很乐于生成的但开工前就要约定好隔离方式否则测试数据混进正式环境后面清理起来非常痛苦。5. 前端页面Cursor帮我写出了80%的Vue组件后端接口有了前端页面就进入了密集生产阶段。这个阶段的主工具从Hermes换成了Cursor原因很简单前端页面需要频繁改文件、看效果、再改文件Cursor这种和编辑器深度绑定的AI效率最高。一次对话改完立刻能在浏览器里刷新验证反馈回路非常短。5.1 页面规划和组件拆解我先把后台管理端的页面清单列出来登录页、系统布局、事件管理列表页、事件新增/详情页、预案管理页、物资管理页、值班管理页、信息报送页、用户管理页、角色管理页差不多10个页面。然后让Cursor按“布局组件、列表页、表单页”三种模式分别生成再逐个替换成真实接口。页面规划时有一个容易被忽略的技巧先让Cursor生成一个统一的API请求封装把Axios实例、请求拦截器、Token携带、错误提示都处理好。所有页面共用这个封装而不是让每个页面自己发请求。这一步看似不起眼但它是前端代码风格统一的关键。没有统一封装每个页面的请求代码就会各写各的后面维护起来非常痛苦。5.2 对话式生成一个事件管理页当时让Cursor生成事件列表页我的指令是在src/views/event/index.vue里生成一个事件管理页面用Element Plus的el-table展示事件列表包含事件编号、事件名称、事件等级、事件状态、报告时间、操作列支持分页和状态筛选操作列包含“详情”和“流转”按钮调用/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事件状态 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状态 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生成的前端页面默认情况下不会处理状态枚举的映射。事件状态在数据库里是1、2、3、4这样的数字如果页面上直接显示数字用户根本看不懂。我让Cursor同时生成了statusText、statusType这类映射对象再用el-tag把状态渲染成不同颜色的标签。这个细节虽然小但决定了页面是“能看”还是“能用”。5.3 接口对接和权限按钮处理前端页面接后端接口时最容易出问题的不是请求本身而是字段名对不上。AI生成的前端代码可能默认后端返回的是camelCase字段而后端实体类某些字段是下划线风格两者一错位页面上全是undefined。我的解决办法是在接口封装层统一做字段映射或者在提示词里一开始就规定“所有后端返回字段使用驼峰命名”让两边从一开始就保持一致。经过这一天的实操我更推荐后者与其事后转换不如源头统一。权限按钮的处理也值得单独说。应急系统的操作按钮不是每个人都可见普通业务员能看到“上报”按钮科室负责人能看到“核实”按钮领导能看到“结案”按钮。Cursor可以在按钮上加一个v-permission指令由权限指令根据当前用户的按钮权限列表决定是否渲染。这个能力是我在生成页面时通过提示词提前约定好的后面所有页面统一复用避免每个页面各写各的判断逻辑。6. 疾控应急系统里最容易翻车的两个业务点状态流转和数据权限整天的开发里如果说有哪个环节让我感觉“差点翻车”那一定是状态流转和数据权限。这两个问题AI几乎不可能自己意识到必须由懂业务的人主动提出来然后在需求设计阶段就定好规则。6.1 事件状态机AI默认只会做增删改查我第一次让Hermes做事件状态管理时它生成的是一个简单的updateStatus接口谁都可以调用传什么状态就改成什么状态。从技术上这没错但从业务上这是灾难。如果一条“已结案”的事件被误操作改回“待核实”后面的处置时限统计、结案报表就全乱了。我把状态流转定义成“只允许从当前状态经过合法动作进入下一状态”核心流转关系如下当前状态允许的动作目标状态待核实核实核实中待核实误报关闭已关闭核实中启动处置处置中处置中结案已结案处置中升级上报已上报此外状态之间还必须记录操作人和操作时间所以我让Hermes补了一张状态流转日志表。加入之后领导在详情页可以看到一条事件的完整时间线几点几分谁做了核实几点几分谁启动了处置。这在应急管理场景里非常关键。所以我建议凡是涉及“流程”的项目哪怕再简单都要让AI先生成“状态动作校验”三件套而不是简单生成一个改状态的接口。6.2 数据权限应急场景下“谁看谁的数据”不能一刀切疾控应急系统的用户按层级分为省级中心、市级中心、区县中心。默认规则是区县中心只能看本辖区事件市级中心能看本市所有区县省级中心能看全部。这就是数据权限问题。如果只用简单的RBAC做权限控制它能控制“这个角色能不能访问事件模块”但控制不了“这个用户能看哪几条事件记录”后者必须靠数据权限过滤实现。我的做法是在用户表里存org_code在事件表里存事发地对应的org_code查询时根据当前用户的行政区划级别动态拼接条件。这个逻辑对AI来说可以一次性生成但它不是一个自动出现的需求。如果你不告诉AI“应急系统需要按管辖层级控制数据可见范围”AI交付的版本就一定是所有角色看到同一份数据。这也是我反复强调不要在需求设计阶段省时间的原因——这个阶段20分钟的投入有可能帮你省掉写完后一次大返工。7. Hermes部署与使用Windows环境下实测的几个坑这一章写给第一次接触Hermes的读者。我把自己在Windows本机部署和使用Hermes的过程以及当天遇到的几个典型问题整理一下。需要说明的是具体命令和参数以你使用的版本和官方文档为准但排查思路基本是通用的。7.1 部署流程和模型配置部署这类Agent框架/平台流程通常是固定的先检查本机环境主要看Python或Node版本是否满足要求然后下载或拉取安装包在项目目录里安装依赖接着配置模型的接入方式也就是模型服务的API地址和密钥最后启动服务在浏览器或客户端里开始对话。当天我在自己本机操作时大致就是这个顺序。装依赖的过程花了一点时间整体不算复杂。配模型的时候有个细节值得注意不同模型对上下文长度和工具调用的支持不一样部署之后第一件事应该是先跑一个最简单的测试对话确认它能正常返回结果而不是直接丢一个需求任务过去。如果模型本身没配好后面所有步骤都白搭。7.2 实际遇到的三类问题第一类是PowerShell执行策略问题。在Windows上如果用了脚本启动服务经常会遇到“无法加载文件因为在此系统上禁止运行脚本”之类的报错。这个问题很好解决用管理员身份打开PowerShell执行一次Set-ExecutionPolicy RemoteSigned再重试启动脚本。第二类是端口占用。Agent服务默认端口可能被其他程序占了启动时会报端口冲突。我的做法是启动前先查一下端口占用情况被占用了就换一个端口不要硬刚。第三类是中文乱码。如果Agent生成的文档或日志在Windows终端里显示乱码大概率是终端编码问题。把终端的代码页切到UTF-8或者在启动命令里设置编码参数问题一般就能解决。7.3 提示词交互的实操技巧使用Hermes这类Agent和普通AI聊天的最大区别是它有一个“任务”的概念。你可以把一整天的需求设计变成一个任务让它分步骤执行中间会产出文档、SQL、代码片段。为了让任务执行得稳我有几个小技巧。第一每个任务的开头先交代“角色目标约束”不要边聊边补因为补丁式对话会让上下文越来越乱。第二如果任务里需要AI产出多个文件把文件清单和命名规则一次说清楚比如“实体类放com.example.entity包Controller放com.example.controller包”。第三如果AI中途给出了不满意结果不要直接说“重写”而是告诉它“哪一部分有问题改成什么方向”这样它能保留正确的部分而不是推倒重来。提示Agent的生产结果一定要让它在任务结束时汇总成一份清单比如“输出本次生成的SQL文件清单、代码文件清单”。这份清单方便你逐个核对也方便后续交给Cursor去落地。没有清单AI生成的中间产物就会像散落一地的零件很难组织起来。8. 一天结束后的复盘时间都花在了哪里项目跑起来之后我做了一个效率复盘。这里把AI辅助开发和传统方式的耗时对比放出来也把必须人盯的环节说清楚方便后面再做类似项目时有个参考。8.1 效率对比拿疾控应急管理系统来说如果按传统开发方式需求设计加原型通常要3到5天前后端联调再加一周很正常。而AI辅助下的实际耗时分布大概是环节传统开发耗时AI辅助实际耗时主要省在哪里需求梳理和模块设计2-3天2小时AI生成初稿人只做纠偏数据库设计0.5-1天30分钟建表SQL直接生成后端基础CRUD2-3天3小时批量化生成实体和接口前端全部页面4-5天4小时Cursor批量生成Vue组件联调和修复2-3天2.5小时接口规范统一后问题大减为什么能省这么多核心在于大部分重复劳动的“代码骨架”被AI包掉了人只需要做三件事在需求阶段把业务规则定清楚在编码阶段把复杂逻辑确认好在联调阶段盯着字段和状态流转。剩下的重复代码AI做得又快又不容易疲劳。8.2 必须人工把关的三个环节但我也要说清楚不是所有环节AI都省时间。至少有三个环节人必须亲自盯否则后面一定会返工。第一个是状态流转和业务规则。AI默认的思维是“可修改”而业务要求是“可控制”这两者之间的差距需要人来填。第二个是数据权限。它不是页面上的一个功能而是贯穿所有查询的横切逻辑AI不会主动考虑到组织层级和数据范围。第三个是接口字段的一致性。后端返回什么字段、前端用什么字段必须在一开始就约定好不然联调阶段会反复出现“页面显示undefined”的问题。8.3 后续扩展方向一天做完的版本定位是“可演示、可验证、可继续迭代”的基线版本不是生产级系统。如果要把这个系统继续往前推我大概会按这个顺序扩展第一步把文件上传和附件管理补上比如事件现场照片和处置报告第二步接入大屏展示把事件分布、物资库存、值班情况投到指挥中心的大屏第三步加上消息通知事件状态变化时通过短信或站内信提醒相关人员第四步再做一套移动端H5方便现场人员用手机上报事件。每一层扩展都可以沿用当天的AI协作模式先让Agent出方案再让Cursor改代码。如果让我再做一遍这类项目我会在需求设计阶段再多留半小时。设计阶段省下的时间后面几乎都会以返工的方式还回去。另一个经验是下午四点半之后坚决不开新功能所有时间留给联调和修bug。AI能帮你在一天内把系统“写完”但“写完”和“能用”之间隔着的那层细节——状态能不能走通、权限遮没遮对、按钮点击有没有反应——永远需要一双人眼去盯。这也是AI开发这件事最真实的边界。