1. 为什么“写代码的顺序”这件事值得单独拿出来聊我一开始看到“AI 写代码也有工序”这个说法的时候第一反应是不就是给个需求让 AI 把代码吐出来吗哪来什么工序直到我用飞算 JavaAI 配合 IDEA 完整跑了一个全栈项目之后才意识到自己之前的用法有多粗糙。同样的工具同样的模型别人生成出来的代码能直接跑通、结构清晰、改起来不费劲而我生成出来的东西编译报错、依赖冲突、逻辑断层改到最后还不如自己从头写。差别不在工具本身而在于调用 AI 的工序。这篇文章想聊的就是这件事AI 辅助写代码到底有没有一套可复现的工序这套工序的顺序为什么不能随便调换以及我在实际项目里踩过的那些坑。内容会围绕 Java 后端、IDEA 开发环境、飞算 JavaAI 这类工具以及全栈项目的落地场景展开。不管你是刚接触 AI 编程的新手还是已经用了一段时间但总觉得“差点意思”的老手应该都能从里面找到点有用的东西。先把结论摆出来AI 写代码的工序本质上和传统软件工程的流程是同构的只是每一步的执行主体从“人”变成了“人 AI”。顺序错了AI 就会在错误的前提上做正确的推理最后产出一个逻辑自洽但完全不符合你需求的东西。这不是 AI 笨是你没给它铺好路。2. 工序拆解AI 写代码到底分几步2.1 需求结构化别让 AI 猜你的心思很多人用 AI 写代码的第一步就是打开对话框敲一句“帮我写一个用户登录功能”。这个做法的问题在于你把“需求分析”这一步完全甩给了 AI。AI 会基于它见过的海量代码猜一个“最常见的登录功能”给你。但你的项目可能用的是 JWT可能要求手机号加验证码可能对接的是公司内部的统一认证这些它一概不知道。我现在的做法是在打开任何 AI 工具之前先花十分钟把需求写成结构化的形式。所谓结构化就是把这几个要素列清楚输入是什么接口接收哪些参数参数类型、是否必填、校验规则输出是什么返回的数据结构成功和失败分别返回什么业务规则有哪些边界条件、特殊逻辑、权限要求技术约束用什么框架、什么数据库、有没有现成的工具类可以复用拿登录功能举例我会写成这样接口路径/api/auth/login接收username和password两个字符串参数密码需要前端做一次 SHA256 再传输后端用 BCrypt 比对登录成功返回 JWT token 和用户基本信息失败返回统一错误码。技术栈是 Spring Boot 3.x MyBatis-Plus MySQL 8。这份结构化需求写出来之后再丢给飞算 JavaAI 或者任何 AI 编程工具生成结果的可用率会有一个质的提升。原因很简单AI 的推理是基于上下文的你给的上下文越精确它的输出就越收敛。你给一句模糊的话它只能给你一个模糊的答案然后你花大量时间去改改的成本比重新生成还高。注意结构化需求不是让你写一份完整的需求文档而是把 AI 最容易搞错的那几个点提前锁定。我一般控制在 200 字以内写多了反而会干扰 AI 对核心逻辑的判断。2.2 技术选型前置先定框架再动手这一步是很多人会跳过的。我见过不少人在 IDEA 里新建了一个空项目然后让 AI 生成代码生成完了才发现 AI 用的是 JPA而项目里已经配好了 MyBatis-Plus。或者 AI 生成的代码用的是 Lombok 注解但项目根本没引入 Lombok 依赖。技术选型前置的意思是在让 AI 写第一行代码之前把项目的基础骨架搭好。具体来说包括依赖管理pom.xml 或 build.gradle 里该引的依赖先引好版本号确定下来目录结构controller、service、mapper、entity 这些包先建好让 AI 知道代码该往哪放基础配置数据库连接、日志配置、全局异常处理这些基础设施先配好代码规范如果有团队统一的代码风格比如命名规范、注释格式提前告诉 AI我用飞算 JavaAI 的时候发现它有一个很实用的能力是可以读取当前项目的结构。如果你先把项目骨架搭好它生成的代码会自动适配你的包结构类名和路径都能对上。但如果你面对的是一个空项目它就只能按自己的默认习惯来生成出来的东西你还得手动调整路径和包名。这一步的投入产出比极高。花二十分钟搭骨架能省下后面一两个小时的调整时间。而且骨架搭好之后后面每一步 AI 生成的代码都能直接往里面塞整个流程会顺畅很多。2.3 分模块生成不要一次性要一个完整系统我踩过最大的一个坑就是让 AI 一次性生成一个完整的模块。比如“帮我写一个订单管理模块包含增删改查、分页、导出 Excel、状态流转”。结果 AI 确实生成了但生成出来的代码有八百多行里面各种逻辑交织在一起我看都看不过来更别说调试了。后来我改成按工序拆解先让 AI 生成实体类和数据库表结构确认无误后再生成 Mapper 和 XML然后是 Service 层最后是 Controller 层。每一层生成完我都会在 IDEA 里编译一下确认没有语法错误和依赖问题再进行下一步。这个顺序不能乱。实体类是地基Mapper 依赖实体类Service 依赖 MapperController 依赖 Service。如果你先让 AI 生成 Controller它就会自己“脑补”一个 Service 接口出来而这个接口可能和你实际需要的完全不一样。等你再生成 Service 的时候又得回头去改 Controller来回折腾。分模块生成还有一个好处是每一层的代码量都不大AI 的注意力集中生成质量更高。而且你可以在每一层生成完之后做一次人工审查发现问题及时纠正不会等到最后才发现整个方向都错了。2.4 人工审查与迭代AI 不是甩手掌柜AI 生成完代码你的工作才完成了一半。我见过太多人把 AI 生成的代码直接复制粘贴到项目里编译通过了就认为万事大吉。但实际上编译通过只代表语法没问题逻辑对不对、边界条件处理了没有、性能有没有隐患这些都需要人工审查。我的审查清单大概是这样逻辑正确性业务逻辑和需求描述是否一致有没有理解偏差边界处理空值、越界、并发这些情况有没有考虑异常处理异常有没有被正确捕获和处理错误信息是否友好安全性有没有 SQL 注入风险敏感数据有没有脱敏权限校验有没有遗漏性能有没有 N1 查询循环里有没有数据库操作大列表有没有分页审查发现问题之后不要自己闷头改而是把问题描述清楚让 AI 重新生成或者修改。比如“这个查询在循环里调用了数据库帮我改成批量查询”AI 会给你一个优化后的版本。这样迭代几轮代码质量会明显提升。3. 实操全流程一个全栈项目的 AI 工序实录3.1 项目背景与技术栈确认为了把工序讲清楚我拿一个实际做过的全栈项目来举例。项目是一个内部用的设备管理系统功能不复杂设备信息的增删改查、设备状态流转、简单的数据统计。技术栈选的是 Spring Boot 3.2 MyBatis-Plus MySQL 8 Vue 3 Element Plus开发工具是 IDEA 2024 社区版AI 辅助工具用的是飞算 JavaAI 插件。选这个技术栈的原因很实际Spring Boot 和 MyBatis-Plus 是国内 Java 后端最主流的组合资料多、坑少、AI 训练数据也充分。Vue 3 加 Element Plus 是前端快速出活的标准搭配。IDEA 社区版免费飞算 JavaAI 有免费的额度整体成本可控。在正式动手之前我先把项目骨架搭好了。后端这边pom.xml 里引了 Spring Boot Starter Web、MyBatis-Plus、MySQL Driver、Lombok、Hutool 工具包。包结构建了 controller、service、service.impl、mapper、entity、common、config 这几个。前端这边用 Vite 创建了 Vue 3 项目装了 Element Plus 和 Axios。这些准备工作做完之后我才打开飞算 JavaAI开始让 AI 参与代码生成。这个顺序很重要先有骨架再有 AI 生成的内容而不是让 AI 从零开始搭。3.2 数据库表设计与实体类生成第一步是设计数据库表。设备管理系统的核心表就一张device表字段包括id主键、device_name设备名称、device_code设备编号、status状态、location位置、create_time、update_time。我把这张表的字段定义和类型写成一段描述丢给飞算 JavaAI让它生成对应的实体类。提示词大概是这样的请根据以下表结构生成 Java 实体类使用 MyBatis-Plus 注解 表名 device 字段id BIGINT 主键自增、device_name VARCHAR(64)、device_code VARCHAR(32) 唯一、status TINYINT、location VARCHAR(128)、create_time DATETIME、update_time DATETIME 要求使用 Lombok 的 Data 注解类名 Device包路径 com.example.device.entityAI 生成的实体类基本可以直接用我检查了一下字段类型和注解确认没问题。这里有个细节status字段我用的是 TINYINTAI 生成的是 Integer 类型这个没问题。但如果你用的是枚举就需要额外告诉 AI 状态值的含义否则它不知道 0 代表什么、1 代表什么。实体类生成完之后我在 IDEA 里编译了一下确认没有报错。然后我让 AI 根据实体类反向生成建表 SQL这样能保证实体类和表结构完全对应。这个反向生成的能力飞算 JavaAI 是支持的省去了手写 SQL 的麻烦。3.3 Mapper 层与 XML 的生成要点Mapper 层是 MyBatis-Plus 的强项基础的增删改查用BaseMapper就能搞定不需要写 XML。但设备管理系统里有一个按状态和位置组合查询的需求这个需要自定义 SQL。我的做法是先让 AI 生成 Mapper 接口继承BaseMapperDevice然后单独定义一个方法ListDevice selectByCondition(Param(status) Integer status, Param(location) String location);然后在 XML 里写对应的 SQL。这里有个坑如果你直接让 AI 生成 XML它可能会用SELECT *这在生产环境里是大忌。我会在提示词里明确要求“不要用 SELECT *列出所有字段名”。另外动态 SQL 的if标签也要让 AI 加上否则传 null 的时候会出问题。AI 生成的 XML 我一般会重点检查这几个地方字段名和实体类是否对应、resultType或resultMap有没有写对、动态 SQL 的判空逻辑是否合理。检查完之后我会在 IDEA 里用 MyBatis 的插件跑一下 SQL 预览确认语法没问题。3.4 Service 层业务逻辑的 AI 协作方式Service 层是业务逻辑的核心也是 AI 最容易出错的地方。因为业务逻辑往往有很多隐含的规则你不说清楚AI 就会按自己的理解来。设备状态流转这个功能规则是这样的设备初始状态是“闲置”可以流转到“使用中”使用中的设备可以流转到“维修中”或“闲置”维修中的设备只能流转到“闲置”。这个状态机如果不用文字描述清楚AI 生成的代码大概率是错的。我的提示词是这样写的请生成 DeviceService 的 updateStatus 方法实现设备状态流转。 状态定义0-闲置1-使用中2-维修中。 流转规则0 可以到 11 可以到 0 或 22 只能到 0。其他流转抛出 BusinessException。 方法签名void updateStatus(Long id, Integer targetStatus)AI 生成的代码逻辑基本正确但它把状态流转规则硬编码在了 if-else 里。我后来让它改成用枚举或者 Map 来管理流转规则这样以后加状态的时候不用改方法体。这个迭代过程很重要第一版能跑就行第二版再优化结构。Service 层还有一个要注意的是事务。AI 生成的代码有时候会忘记加Transactional注解或者加在了不该加的地方。我的习惯是涉及多表操作或者状态变更的方法都手动确认一下事务注解有没有加对。3.5 Controller 层与接口联调Controller 层相对简单主要是参数接收、调用 Service、封装返回结果。但这里有一个统一返回格式的问题。如果项目里已经有ResultT这样的统一返回类要在提示词里告诉 AI让它用这个类来包装返回值。AI 生成的 Controller 我一般会检查这几个点参数校验注解有没有加Valid、NotNull这些、请求方式对不对GET 还是 POST、路径有没有冲突。检查完之后我会用 IDEA 自带的 HTTP Client 或者 Postman 跑一遍接口确认能通。前后端联调的时候如果前端也是 AI 生成的要注意接口字段名的一致性。后端返回deviceName前端接收device_name这种问题很常见。我的做法是后端接口定好之后把返回的 JSON 结构贴给 AI让它按这个结构生成前端的 Axios 请求代码。4. 常见问题与排查技巧实录4.1 AI 生成代码编译报错的典型原因AI 生成的代码编译报错原因就那么几类。第一类是依赖缺失比如用了 Lombok 的注解但没引 Lombok 依赖或者用了 Hutool 的工具类但 pom 里没有。第二类是包路径不对AI 按自己的习惯生成了com.example.xxx但你的项目包名是com.company.project。第三类是版本不兼容比如 AI 用的是 Spring Boot 2.x 的写法但你项目是 3.xjavax和jakarta包名对不上。排查这类问题的思路很简单看报错信息的第一行找到是哪个类找不到或者哪个方法不存在然后去检查对应的依赖和包路径。IDEA 的自动导入功能Alt Enter能解决大部分包路径问题依赖问题就需要手动改 pom.xml。实操心得在让 AI 生成代码之前先把项目的 JDK 版本、Spring Boot 版本、关键依赖的版本告诉它。比如“项目使用 JDK 17、Spring Boot 3.2、MyBatis-Plus 3.5.5”这样 AI 生成的代码会适配你的版本减少很多兼容性问题。4.2 逻辑正确但跑不通的排查思路有时候代码编译没问题但运行起来就是不对。比如接口返回 500或者数据查不出来。这种情况我一般按这个顺序排查先看日志。IDEA 的控制台会打印异常堆栈找到最下面的Caused by那里通常是根因。如果是 SQL 相关的问题把 MyBatis 的 SQL 日志打开看看实际执行的 SQL 是什么参数有没有传进去。再看数据。有时候是数据库里没数据或者字段值不符合预期。我习惯在排查的时候直接连数据库手动跑一遍 SQL确认数据层面没问题。最后看配置。比如数据库连接配置、MyBatis 的 mapper 扫描路径、事务配置这些。AI 生成的代码本身逻辑是对的但如果你项目里的配置和它预期的不一样就会出问题。4.3 常见问题速查表问题现象可能原因排查方法编译报错找不到类依赖缺失或包路径不对检查 pom.xml 和 import 语句接口返回 500空指针或 SQL 异常看控制台异常堆栈定位到具体行查询结果为空条件不对或数据不存在打印实际 SQL手动执行验证状态流转不生效事务未提交或逻辑错误检查 Transactional 注解和流转规则前端接收字段为 undefined前后端字段名不一致对比接口返回 JSON 和前端接收变量AI 生成的代码风格不统一未指定代码规范在提示词中明确命名和注释要求4.4 让 AI 生成代码更稳定的几个技巧第一个技巧是给示例。如果你项目里已经有一个写好的 Service 类可以把那个类的结构贴给 AI让它参照这个风格来生成。AI 的模仿能力很强给一个样板它生成的东西会贴合你的项目风格。第二个技巧是分步确认。不要一次性让 AI 生成太多东西生成一个类就检查一个类生成一个方法就测试一个方法。这样问题能及早发现不会积累到最后变成一团乱麻。第三个技巧是保留对话上下文。飞算 JavaAI 这类工具通常支持多轮对话你在同一个会话里连续生成代码AI 能记住前面的上下文。如果你每生成一个文件就新开一个会话AI 就失去了上下文生成的东西可能和前面的对不上。5. 工序背后的逻辑为什么这个顺序不能乱5.1 从软件工程视角看 AI 编程传统软件工程的流程是需求分析、概要设计、详细设计、编码、测试、部署。AI 编程并没有颠覆这个流程只是把“编码”这一步的一部分工作交给了 AI。但很多人用 AI 的时候直接跳过了前面的分析和设计上来就让 AI 写代码。这就好比盖房子不打地基直接砌墙砌到一半发现歪了只能推倒重来。需求结构化对应的是需求分析技术选型前置对应的是概要设计分模块生成对应的是详细设计人工审查对应的是测试。每一步都有它的作用跳过任何一步后面的步骤都会受到影响。AI 不会帮你做需求分析它只会基于你给的信息做推理。你给的信息越完整它的推理越准确。5.2 顺序错了会怎样几个真实翻车案例我印象最深的一次翻车是让 AI 先生成 Controller再生成 Service。结果 AI 在 Controller 里定义了一个DeviceService接口方法签名是它自己猜的。等我再让 AI 生成 Service 实现的时候它生成的方法签名和 Controller 里定义的完全不一样。最后我只能手动把两边对齐花的时间比从头按顺序生成还多。还有一次是没做技术选型前置直接让 AI 生成代码。AI 默认用了 JPA 的注解但我项目里用的是 MyBatis-Plus。生成的实体类上带着Entity、Table这些注解和 MyBatis-Plus 的TableName冲突编译直接报错。后来我把项目里已经配好的依赖和配置贴给 AI让它重新生成才解决问题。这些翻车案例的共同点是AI 在错误的前提下做了正确的推理。它的推理能力没问题问题在于你给它的前提不对。工序的作用就是保证每一步的前提都是正确的这样 AI 的输出才能为你所用。5.3 不同规模项目的工序调整工序不是一成不变的项目规模不同工序的侧重点也不一样。小项目或者原型验证工序可以简化。需求结构化可以口头过一遍技术选型直接用最熟悉的分模块生成可以合并成一次生成人工审查重点看核心逻辑。这种情况下速度优先AI 的价值在于快速出活。中型项目工序要完整走一遍。需求结构化写成文档技术选型确认版本分模块生成按层推进人工审查覆盖主要功能。这种情况下质量和速度要平衡AI 的价值在于减少重复劳动。大型项目或者团队协作工序还要加上代码规范统一、接口文档同步、代码审查流程这些环节。AI 生成的代码要符合团队规范接口定义要和文档一致代码审查要覆盖 AI 生成的部分。这种情况下规范优先AI 的价值在于提升整体效率。6. 工具链搭配IDEA 飞算 JavaAI 的实际体验6.1 IDEA 环境准备与插件安装IDEA 的安装没什么好说的官网下载社区版就行免费够用。这里重点说一下插件安装。飞算 JavaAI 在 IDEA 的插件市场里可以直接搜到安装完之后重启 IDEA在右侧边栏会出现它的面板。安装完之后需要登录账号免费额度对于个人开发者来说基本够用。登录之后你可以在设置里配置一些偏好比如默认的代码风格、是否自动导入依赖这些。我建议把“自动导入”打开这样 AI 生成的代码如果引用了新的类IDEA 会自动帮你加 import 语句。还有一个细节是 JDK 的配置。飞算 JavaAI 生成代码的时候会读取项目的 JDK 版本如果你项目配的是 JDK 17它生成的代码就会用 JDK 17 的语法特性。如果配的是 JDK 8它就会用更保守的写法。所以项目创建的时候JDK 版本要选对。6.2 飞算 JavaAI 的核心功能拆解飞算 JavaAI 我用得最多的功能是“根据描述生成代码”和“根据表结构生成实体类”。前者适合生成 Service 和 Controller 的逻辑后者适合生成实体类和 Mapper。它还有一个“代码解释”功能选中一段代码让它解释这段代码在做什么。这个功能在我审查 AI 生成的代码时很有用有时候 AI 生成的逻辑比较绕我自己看一遍不一定能完全理解让它解释一遍能帮我快速判断逻辑对不对。另外一个是“代码优化”功能选中一段代码让它给出优化建议。我一般用这个功能来检查 AI 自己生成的代码有没有性能问题。比如它生成的循环查询优化功能会提示改成批量查询。6.3 工具搭配的注意事项飞算 JavaAI 和 IDEA 的配合整体很顺畅但有几个地方要注意。第一是网络问题。AI 功能需要联网如果你的开发环境网络不稳定生成代码的时候可能会超时。我的做法是在网络好的时候批量生成生成完的代码本地保存不依赖实时联网。第二是代码覆盖问题。AI 生成的代码如果直接覆盖你已有的文件可能会丢失你手动改过的内容。我的习惯是AI 生成的代码先放到一个临时文件里确认没问题之后再手动合并到目标文件。第三是版本管理。AI 生成的代码也要纳入 Git 管理每次生成完提交一次这样出问题的时候可以回滚。我见过有人 AI 生成完直接覆盖结果把之前能跑的代码搞坏了又找不回来。7. 从单点工具到全栈工作流7.1 后端到前端的工序衔接全栈项目里后端和前端是两条线但工序上是有衔接的。后端接口定好之后前端的请求代码才能生成。我的做法是后端 Controller 写完之后用 Swagger 或者 Knife4j 生成接口文档然后把接口文档的 JSON 贴给 AI让它生成前端的 API 调用代码。这样生成出来的前端代码接口路径、请求方式、参数名、返回结构都是和后端对齐的联调的时候基本不会出现字段对不上的问题。Vue 3 的 Composition API 写法 AI 也很熟悉生成的代码结构清晰改起来方便。7.2 全栈项目的工序清单我把全栈项目的 AI 工序整理成了一个清单每次做新项目的时候照着走确认技术栈和版本搭好前后端项目骨架设计数据库表生成实体类和建表 SQL生成 Mapper 接口和 XML确认 SQL 正确生成 Service 接口和实现重点审查业务逻辑生成 Controller确认参数校验和返回格式生成接口文档联调后端接口根据接口文档生成前端 API 调用代码生成前端页面和组件联调前后端整体测试修复问题优化代码这个清单看起来步骤多但每一步的耗时都不长。因为 AI 承担了大部分编码工作你主要做的是确认和调整。实际做下来一个中等复杂度的全栈项目从零到能跑两三天就能搞定。7.3 工序固化后的效率变化工序固化之后最大的变化是“可预期”。以前用 AI 写代码生成出来的东西质量忽高忽低有时候能用有时候完全不能用心里没底。现在按工序走每一步的输出质量都相对稳定因为前提条件控制住了。另一个变化是“可复现”。同样的工序换一个项目换一个技术栈照样能走通。工序本身是和技术栈无关的它是一套方法论。你学会了这套方法论用任何 AI 工具都能发挥出它的价值。还有一个变化是“可协作”。工序清晰之后你可以把工序中的某一步交给别人做比如让前端同事负责前端部分的 AI 生成你负责后端部分两边按接口文档对接。工序成了团队协作的框架而不是个人的经验。8. 一些踩坑之后的个人体会飞算 JavaAI 这类工具刚出来的时候我其实是有点抵触的觉得 AI 生成的代码不可控改起来比自己写还麻烦。但用了一段时间之后我发现问题不在工具而在用法。工具本身的能力是够的关键在于你有没有一套工序来驾驭它。我现在用 AI 写代码心态和以前完全不一样了。以前是“让 AI 帮我写代码”现在是“我带着 AI 走工序”。前者是把控制权交给 AI后者是我掌控流程AI 负责执行。这个心态的转变带来的效率提升是实实在在的。还有一个体会是工序不是死的。不同项目、不同团队、不同技术栈工序都可以调整。但调整的前提是你先有一套完整的工序然后根据实际情况做减法或者加法。如果你一开始就没有工序那就无从调整只能凭感觉来质量自然不稳定。最后说一个具体的技巧每次用 AI 生成代码之前花三十秒想一下“这一步的前提是什么”。前提对了AI 的输出大概率是对的前提错了AI 的输出再漂亮也是白搭。这个三十秒的思考是我用 AI 写代码以来投入产出比最高的一个习惯。