AI编程实战：拆解设备参数管理模块，掌握指挥AI的核心方法

最近有朋友问我：AI编程到底能不能独立开发一个业务模块？我先没回答，反问他一句——你能不能用三句话把你要的东西说清楚？他愣了一下，然后说“那你还是给我讲讲吧”。后来我花了一下午，带他把这个模块完整做出来，他才意识到，AI编程的关键从来不在AI本身，而在你给出的指令质量。这一篇是这个系列实战部分的第2篇，我拿一个真实的业务模块——设备参数管理模块——走一遍完整流程，把“指挥AI”这件事拆开揉碎，包括你该做什么、AI该做什么、以及过程中一定会踩的坑，都摊开讲清楚。内容偏实践，适合产品经理、后端开发、全栈工程师，以及所有想用AI把活干得再快一点的人。

1. 业务模块开发为什么是AI编程的天然练兵场

1.1 什么算“业务模块”，AI到底能覆盖到哪一层

先把这个概念对齐一下。我说的“业务模块”，指的是系统里一个边界清晰的独立功能单元，比如用户管理、订单管理、参数配置、报表查询、审批流转这类东西。它的特征是：入口明确（一个菜单、一组接口）、数据模型明确（几张表）、动作明确（增删改查加状态流转）。

这种模块有极强的规律性。从代码量占比来看，一个典型业务模块里至少有六到七成是所谓的“模式代码”——实体类、DTO、Mapper、Service、Controller，写法和项目里已经存在的模块几乎一模一样。AI训练数据里恰好充满了这类大量重复、有标准范式的代码，所以AI在这种任务上表现特别好。

我自己实测下来，一个中等复杂度的模块（三张表、两个页面、若干业务校验规则），传统开发怎么也得两到三天，人加AI协作的话，四到六个小时就能到可提测的版本。这不是夸张，前提是需求本身已经被澄清过了。

1.2 AI擅长与不擅长的边界，一张表说清楚

很多人用AI开发业务模块，要么期望过高，要么期望过低。我把经验整理成一张边界表：

为什么边界恰好在这里？原因很简单：AI的训练语料里，海量先例都集中在“通用模式”上，但它缺少对你业务上下文的真正理解。凡是依赖“这个项目私有规则”的地方，AI很容易一本正经地编一个看似合理的方案。比如它可能默认删除设备是物理删除，而你们项目一直是逻辑删除。这种偏差不怪AI，怪你没把上下文讲清楚。

1.3 这个时间点为什么值得掌握AI辅助开发

我见过很多开发者的抱怨：“AI生成的代码我又要改一遍，还不如自己写。”这话放到三年前，我承认有道理。但现在的关键是，AI最大的价值不是替你省掉全部工作，而是把“从零到一”的时间压缩到极限，让你能把精力放到“从一到十”的打磨上。

以前一个需求过来，先写设计文档、拉评审会、排期，然后等后端开发。现在我的流程是：先让AI根据需求生成一个可运行的骨架，评审会直接对着骨架开。大家讨论的是“这里的数据权限不对”“这个字段的校验规则漏了”，而不是对着空气想象一个系统长什么样。沟通成本完全不是一个量级。

这也是我把这一篇的实战主题定为“指挥AI”而不是“用AI”的原因。工具更迭太快，今天你记的快捷键，下个月可能就废了。但拆解需求、把话说清楚、定义输入输出、驱动AI完成任务这套方法，不管底层模型怎么换，都是管用的。

2. 指挥AI的核心心法：提示词不是聊天，是需求文档的浓缩版

2.1 任务拆解：一条指令只交代一件事

我见过最典型的失败案例，是开发者上来就一句“帮我做一个设备管理模块”。AI收到这种指令，会怎么做？它会按它自己脑子里的“平均”理解去生成，结果通常是：要么过度设计，冒出一堆你没要的功能；要么实现得太简单，把你最看重的校验逻辑全漏了。

正确做法是把一个模块拆成五到六个子任务，每个子任务一条指令，逐轮进行：

1. 表结构设计
2. 实体、Mapper、Service、Controller四层代码生成
3. 参数校验和异常处理补全
4. 分页与条件查询完善
5. 接口自测脚本与前端页面骨架

每一条指令都要带上上一步的产物。比如第二步的提示词里，直接把第一步生成的建表SQL贴进去，而不是让AI“回忆”上一轮你说了什么。这个习惯很重要，能避免后续对话跑偏。

2.2 上下文注入：把你脑子里的“项目常识”写出来

业务模块开发失败的头号原因，不是AI不会写代码，而是它不知道你项目的规范。举几个我踩过的例子：你们的统一返回类叫Result<T>，AI给你返回裸的HashMap，前端接数据时直接崩溃；你们的分页用MyBatis-Plus的Page，AI按PageHelper的写法生成，接口路径都对但参数完全对不上；你们字段命名用驼峰、数据库用下划线，AI把实体类字段名直接写成了下划线风格。

解决这个问题，最有效的办法是准备一个“项目规范片段”，每次和AI对话之前先粘贴进去。这个片段不用很长，五到十行就够用：

项目技术栈：Spring Boot 3.2 + MyBatis-Plus + MySQL 8 包名根路径：com.example.equipment 统一返回类：com.example.common.Result<T>，结构为{code, message, data} 异常处理：业务异常抛BizException，由全局异常处理器统一转换 分页方式：MyBatis-Plus的Page对象，页码从1开始，每页默认20条 数据库约定：表名和字段名下划线，实体类字段驼峰，逻辑删除字段deleted 日志规范：使用Slf4j，关键操作记录操作人、操作时间和变更内容

这段话看着普通，但它是你指挥AI的“上下文锚点”。有了它，AI生成的第一版代码就大概率符合项目约定，而不是生成一个“看起来像那么回事但完全不兼容”的版本。我见过太多人忽略了这一步，然后花大量时间在改AI的命名和结构上，最后得出“AI写代码不行”的结论。

2.3 输入输出定义：先给“长什么样”，再让它写

如果你希望AI生成高质量的CRUD代码，最好把“长什么样”先给它。具体来说，先给表结构SQL，再给接口定义。我一般是这么干的：

先丢一段创建表的SQL，然后跟着一段接口期望：

POST /api/device/page 请求体: {"pageNum":1,"pageSize":20,"deviceName":"","status":1} 响应体: {"code":0,"message":"ok","data":{"total":10,"records":[{"id":1,"deviceCode":"D001","deviceName":"水泵","model":"XQ-200","location":"1号车间","status":1}]}}

有了表结构、有了请求响应样例，AI生成的Controller基本就不用大改。为什么这个办法有效？因为AI做的是模式匹配，你给的样例越具体，它匹配到的模式就越接近你想要的。这跟在搜索引擎里输入关键词越多、结果越精准是同一个道理。

2.4 验收标准：让AI自己判断“做完没”

还有一个很容易被忽略的点：AI对“完成”的理解和人类对“完成”的理解，经常不是一回事。你问它“代码写完了吗”，它说“写完了”，结果一编译全是错。这不是AI在骗你，而是它对“写完”的定义就是“把代码生成出来”，不包括“编译通过”“接口验证过”。

我在提示词最后一定会加一段“验收角度的自检要求”，原话大概是这样的：

“代码生成完毕后，请按以下格式回复：1. 本次新增/修改的文件清单；2. 你是否检查过编译级别的错误，包括缺依赖、缺导入、字段名不匹配；3. 接口入参出参是否和要求的JSON结构一致；4. 给出你自己执行验证的建议步骤。”

这个变化看起来很小，但对流程的影响非常大。它会强制AI在执行阶段就做一次静态自查，而不是交一堆半成品给我。我现在的工作流里，几乎每一条实现类指令都会带上这段验收要求。

3. 实战录：设备参数管理模块从零到一

3.1 需求定义与表结构设计

先交代背景。我要做的模块叫“设备参数管理”，核心需求有三块：

1. 设备台账维护：新增、编辑、停用设备，设备有编号、名称、型号、安装位置、状态
2. 参数定义管理：每个设备可以绑定多个参数项，每个参数项有编码、名称、单位、报警上下限
3. 参数记录查询：按设备、参数编码、采集时间范围，分页查询采集历史

这个模块听起来小，但它是工业物联网系统里典型的基础数据模块。我把建表SQL直接给AI，要求它先评审一遍表结构，再生成代码。建表SQL如下：

CREATE TABLE device ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', device_code VARCHAR(64) NOT NULL UNIQUE COMMENT '设备编号', device_name VARCHAR(128) NOT NULL COMMENT '设备名称', model VARCHAR(128) DEFAULT NULL COMMENT '型号', location VARCHAR(256) DEFAULT NULL COMMENT '安装位置', status TINYINT DEFAULT 1 COMMENT '状态：1启用，0停用', deleted TINYINT DEFAULT 0 COMMENT '逻辑删除', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) COMMENT '设备台账表'; CREATE TABLE device_param ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_id BIGINT NOT NULL COMMENT '关联设备ID', param_code VARCHAR(64) NOT NULL COMMENT '参数编码', param_name VARCHAR(128) NOT NULL COMMENT '参数名称', unit VARCHAR(32) DEFAULT NULL COMMENT '单位', alarm_min DECIMAL(12,4) DEFAULT NULL COMMENT '报警下限', alarm_max DECIMAL(12,4) DEFAULT NULL COMMENT '报警上限', enabled TINYINT DEFAULT 1 COMMENT '是否启用', UNIQUE KEY uk_device_param (device_id, param_code) ) COMMENT '设备参数定义表'; CREATE TABLE param_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_id BIGINT NOT NULL COMMENT '设备ID', param_code VARCHAR(64) NOT NULL COMMENT '参数编码', param_value DECIMAL(12,4) NOT NULL COMMENT '采集值', collect_time DATETIME NOT NULL COMMENT '采集时间', KEY idx_device_time (device_id, collect_time) ) COMMENT '参数采集记录表';

关于表结构这块我想多说一句：建表SQL是你和AI沟通的“通用语言”，比任何自然语言描述都精准。你在提示词里啰嗦十句“设备有个编码、有个名称”，不如直接给一张CREATE TABLE。第一轮对话我让AI评审表结构，它只提了两点合理建议：一是param_record的idx_device_time索引建议把param_code也加进去，方便按“设备+参数+时间”查询；二是给device_param加唯一索引防止同一设备重复绑定同一参数编码。这两点都采纳了，省了我自己想的功夫。

3.2 第一轮对话：生成后端四层代码骨架

表结构敲定之后，我给AI的指令是：

“根据上面的三张表，生成设备参数管理模块的后端代码。要求：包名com.example.equipment；Controller统一返回Result ；分页使用MyBatis-Plus的Page；实体类用MyBatis-Plus注解映射；不生成XML，Mapper直接用BaseMapper；生成完成后按文件清单、编译检查、验证建议的格式输出。”

AI生成的实体类基本可用，但有一个细节要注意：MyBatis-Plus的@TableName注解，AI有时候会根据表名推理出驼峰实体名，但如果项目里配了全局表前缀，就需要手动指定。这里我把@TableName("device")标的清清楚楚。Controller层生成也比较顺利，分页接口大概长这样：

@RestController @RequestMapping("/api/device") @RequiredArgsConstructor public class DeviceController { private final DeviceService deviceService; @PostMapping("/page") public Result<Page<DeviceVO>> page(@RequestBody DeviceQueryDTO query) { return Result.ok(deviceService.pageDevices(query)); } }

第一轮生成的代码，编译级别的问题已经很少，因为有“验收自检”那段话盯着它自查了一遍。但我仍然发现一个问题：它生成的DeviceVO里把alarmMin这些参数报警字段直接塞进了设备查询结果里，导致列表页的VO和设备的实体概念混在一起。这个是我在review的时候手动纠正的，让VO只管设备本身的信息，参数定义走独立的接口。这件事说明：AI能给你一个起点，但业务的字段边界划分，还是要人来定。

3.3 第二轮对话：把业务规则补进去

骨架跑通之后，第二轮我集中补业务规则。我给出的规则有四条：

1. 删除设备时，如果设备下已有参数定义，不允许物理删除，改为停用设备
2. 新增参数定义时，报警上限必须大于报警下限，两个值不能同时为空
3. 参数记录只允许新增和查询，不允许修改和删除，保证采集数据的可追溯性
4. 分页查询设备时，支持按设备名称模糊搜索、按状态精确筛选

这一轮我把每条规则单独拆成一小段描述，而不是一段话全糊上去。AI对“编号清晰、一条一条列出来”的规则理解准确率高得多。下面是它生成的关键方法之一，也就是删除设备的逻辑：

@Override @Transactional(rollbackFor = Exception.class) public void deleteDevice(Long deviceId) { Long paramCount = deviceParamMapper.selectCount( new LambdaQueryWrapper<DeviceParam>() .eq(DeviceParam::getDeviceId, deviceId) .eq(DeviceParam::getEnabled, 1) ); if (paramCount > 0) { deviceMapper.update(null, new LambdaUpdateWrapper<Device>() .eq(Device::getId, deviceId) .set(Device::getStatus, 0)); return; } deviceMapper.deleteById(deviceId); }

这段代码整体思路对，事务注解也加上了。但我在review时发现一个隐患：它在判断“是否物理删除”时，只看启用的参数定义，等于说设备下有停用的参数定义时，设备会被直接物理删除，而停用的参数定义还留在表里变成孤儿数据。我要求AI改成“只要存在参数定义记录，就只停用设备”。这个例子挺典型——AI会忠实执行你给的规则，但如果规则描述里存在对你真实业务意图的“想当然”空间，它就会生成一个“字面正确但实际有漏洞”的逻辑。人工审查的意义就在这里。

3.4 第三轮对话：前端页面与接口联调

后端逻辑稳定后，第三轮我让AI生成前端页面。技术栈是Vue3加Element Plus，需求就只有两个页面：设备列表页（含新增、编辑、停用按钮），参数定义管理页（在设备列表点击“参数配置”进入弹窗）。

AI写前端页面比写后端更快，因为前端页面的模式更统一，表格、弹窗、表单全是固定套路。我给的提示词很简短，只提了几个关键约束：列表页用el-table，分页用el-pagination，新增和编辑共用一个弹窗，表单校验规则用Element Plus的rules。AI生成的代码基本能跑，表格列和按钮事件都对应上了。

但前端有一个后端不存在的麻烦：字段的显示格式、按钮的loading状态、弹窗关闭后表单重置，这些细节AI经常处理得不到位。比如它生成的编辑弹窗，打开时能正确回显数据，但关掉再打开新增，表单里还是上一次残留的数据。这种小问题就需要我手动补一行resetFields()。我的策略是：AI负责把页面骨架和数据交互逻辑搭好，交互细节我快速过一遍补齐。总的来说，前端这块从零到勉强可用，大概花了一个小时，其中AI生成占二十分钟，我修修补补占四十分钟。

3.5 自测清单：提测前必须过一遍

一个模块开发完，不代表就能提测。我自己会按下面这个清单快速过一遍，确保没有低级问题：

• 编译与启动：mvn clean package通过，应用能正常启动
• 接口冒烟：用ApiPost或Postman把增删改查接口各调一遍，确认返回结构符合预期
• 异常场景：传空参数、传超长字符串、删除不存在的记录，看全局异常是否统一处理
• 唯一性验证：重复创建设备编号、重复绑定参数编码，确认数据库唯一索引和代码校验都在生效
• 前端操作：列表页分页、搜索、新增弹窗、编辑回显、停用确认，按正常用户路径走一遍

这五步看起来基础，但每一条背后都有血的教训。别问我为什么专门强调“重复创建设备编号”和“编辑回显”这两个点，问就是曾经直接带病上了测试环境，被测试同事追着骂了一周。

4. AI代码的调试与返工：一份排查链路的实操笔记

4.1 症状一：代码生成完，项目一启动就报错

AI生成的代码拿到手，第一件事不是看逻辑，是先编译、先启动。这一步会暴露大量低级问题：缺依赖、缺注解、字段名拼写不一致、包路径引错。我见过最多的两类编译错误，一是mybatis-plus的依赖没引入完整，AI代码里用了LambdaQueryWrapper但pom里压根没有对应starter；二是Mapper接口忘了加@Mapper注解，Spring容器启动时直接报NoSuchBeanDefinitionException。

遇到这类问题，我的排查链路是固定的：

1. 先看控制台堆栈，找到最底部的Caused by那一行，而不是最上面的异常描述
2. 把完整报错信息复制回给AI，原话是“项目启动报错：……，请分析原因并给出修复后的完整文件内容”
3. 等AI给出修复方案后，不要直接相信，自己看一眼报错的位置和它改的地方是否对应

这里有个关键技巧：不要自己先去猜原因，也不要自己去改。把报错原样丢回给AI，它定位问题的速度往往比自己翻代码快得多。我实测下来，十次有七八次它能直接给出正确的修复方案，剩下两三次会陷入“改A报B、改B报C”的死循环，这种时候直接重开对话，把项目背景和报错信息重新粘贴一遍，比和它杠到底有效得多。

4.2 症状二：改了一个需求，连带把之前好的功能也改坏了

AI编程最让人恼火的不是刚开始报错，而是中途改需求。你让它加一个字段，它可能顺手把另一个无关字段的校验规则也改了。你让它改前端的按钮逻辑，它可能把表格的列定义也动了。这种“隐性回归”比显性报错更费时间，因为它不会第一时间暴露。

我现在对AI改动有两条硬性约束：

第一，每次批量修改前，先自己在测试环境跑一遍原功能，把“当前确实是好的”行为记录下来。比如设备列表的分页是好的，参数新增的校验是好的，做一个简单备注。然后让AI修改，改完只允许它动它该动的地方，输出修改diff。

第二，全程用Git管理代码，AI每次改完，我先git diff看一遍再提交。这种情况下，即使AI改了不该改的地方，回滚成本也很低。我见过不少同事用AI改代码，改了三天之后发现回不去了，就是因为没有版本控制兜底。这不是AI的问题，是流程的问题。

4.3 症状三：AI开始“自由发挥”，做了你完全没要求的事

另一种高频问题是AI在生成代码时，会自行发挥。比如我让它改DeviceController的一个接口，它把DeviceServiceImpl的整个类重写了一遍；我告诉它时间字段用LocalDateTime，它在某个角落里生成了Date；我让它只返回设备基础信息，它额外带出了设备下的参数列表。这类问题在长对话里尤其常见——对话轮次越多，AI越会顺着自己前一轮的“惯性”往下推，而不是严格贴着你的最新指令。

对策只有一个：一旦发现AI开始自由发挥，立即缩小指令范围，重新声明边界。比如我会说：“本次只允许修改DeviceController类，其他文件和类的任何内容都保持原样。请先列出你准备修改的方法清单，确认后再动工。”这种“先声明再动手”的模式，能很大程度抑制AI跑偏。如果它已经跑偏了好几轮，最干净的做法是重开一个对话，把项目背景、上下文信息包、最新需求重新粘贴一遍，而不是在乱成一团的旧对话里继续掰扯。

4.4 上下文管理的实用工具方法

随着模块越做越大，我和AI的对话上下文也变得越来越长。这里有一个很多教程不会讲的经验：不要在一个对话里完成所有事。我的划分规则是：

• 表结构设计是一轮独立对话，只聊设计，聊完就结束
• 后端代码生成是一轮独立对话，上下文只包含建表SQL和项目规范
• 前端页面是另一轮独立对话，上下文只包含接口定义和后端返回结构
• 后续修改统一以“修改工单”的形式开新对话，每条工单里附上相关代码片段

每一轮对话都轻装上阵，AI的上下文窗口不会被无关信息占满，生成质量会显著提高。这个策略听起来简单，但实际效果比任何人告诉你“换一个更强的模型”都要明显。

5. 不管AI多强，这几个关口必须人工把住

5.1 安全与权限：AI生成的接口默认不带鉴权

AI生成的Controller、Service代码，默认是不会考虑权限的。它不会主动给你的新接口加@PreAuthorize，也不会处理“用户A能看到设备B的数据吗”这类跨租户问题。如果你们项目的接口鉴权依赖网关或统一的拦截器，可能这个问题还小一点；但如果你们的权限控制是散落在各个Controller里的，那么AI每生成一个接口，都意味着一个潜在的数据暴露点。

我的上线前检查清单里，有一项是专门查这个的：所有新增的接口，逐条确认是否有权限注解、是否需要做数据范围过滤。特别是列表查询接口，AI很容易把“查询所有设备”直接暴露出来，而真实业务里往往要求只能看自己负责的车间的设备。这些规则AI不知道，你必须在需求阶段就明确告诉它，并且在生成后人工核对。

5.2 事务与数据一致性：多表操作必须逐个人工确认

AI对事务的处理有个典型倾向：单表操作时它记得加@Transactional，但遇到跨表业务逻辑时，它有时会忽略，或者在方法内部自己catch了异常，导致事务回滚失效。我上面提到的“删除设备时判断参数定义并决定停用或删除”就是一个典型的多表操作场景。

我在review多表方法时，会习惯性问三个问题：

• 这个方法会修改几张表？如果中途抛异常，前面的修改能回滚吗？
• 并发场景下，有没有可能两条请求同一时间操作同一条数据？
• 唯一约束是在数据库层面兜底，还是只依赖代码里的if判断？

这三个问题问完，基本能过滤掉绝大多数数据一致性隐患。另外一个容易被忽略的坑是：AI有时会在Service内部自己catch异常并返回Result.error(),这会导致@Transactional的回滚机制失效。正确做法是让异常一路抛上去，由全局异常处理器统一兜底。这类规则我在上下文信息包里专门写了一条，但review时还是会习惯性检查一遍。

5.3 性能与容量：AI看不见数据库的瓶颈

AI能帮你写出功能正确的代码，但它看不到你们生产环境的真实数据量。一个分页查询，如果表里只有几百条数据，怎么写都快；但如果这张表已经几千万条了，SELECT *加COUNT(*)的常规写法就会直接把数据库拖垮。

我遇到过最典型的案例：AI生成参数记录分页查询时，条件字段是device_id和collect_time，但它生成的查询写法导致索引完全没走，全表扫描加文件排序。原因很简单，AI不会主动思考“这个查询在某个数据量级下应该用什么索引、什么写法”，它只会按最常见的模式生成。所以，我给了建表SQL里的索引建议之后，又单独让AI生成了一轮“索引评审”，针对查询场景调整了联合索引：idx_device_time改成了(device_id, param_code, collect_time)。这一步在数据量小的时候看不出差别，但等表长到百万级，就是快慢五分钟和几十毫秒的区别。

5.4 测试策略：让AI生成测试用例是对的，但执行还得靠人

AI写单元测试骨架的效率非常高，给它一个Service类，它就能生成一套Mockito风格的测试用例，覆盖正常流程和几个常见异常分支。这对提高代码覆盖率很有帮助，我会把它纳入开发流程。

但要注意一点：AI生成的测试用例，几乎没有边界值和极端场景。它不会主动测“上传一个超过数据库字段长度的设备名称”，也不会测“参数报警范围同时传null会不会通过校验”。这些针对业务规则的边界用例，必须人工补齐。我一般让AI先生成“服务端参数校验规则清单”，然后对照清单手写关键测试用例。下面的表格是我实际使用的测试用例参考：

这些用例看着简单，但每一个都是在线上真实踩过雷之后沉淀下来的。测试这件事，AI能帮你提速，但永远替不了你思考业务边界。

6. 最后说点个人体会

这套流程跑了几个月之后，我最大的感受是：AI编程带来的效率提升不是线性的，而是跳跃式的，但跃迁的前提是你先把“指挥”这件事做好。把需求拆清楚、把上下文喂够、把验收标准定明白，这些能力在任何工具面前都不过时。

另外分享一个小技巧：我每天开工前，会花十分钟把最近在做的项目里的代码规范、权限规则、业务口径更新到一个叫project-context.md的文件里，然后每个新对话都从粘贴这个文件开始。这个文件现在成了我所有AI协作的起点，也是团队里新同事了解项目最快的入口。

工具永远在迭代，但拆解需求、表达需求、守住质量底线这些基本功，才是这轮AI普及里真正值得练的本事。