1. 为什么“顺序”这件事在AI全栈开发里被反复强调第一次看到“AI全栈开发的四个指令为什么必须按顺序跑”这个说法我其实没太当回事。干Java这行十来年从Eclipse换到IDEA从手写SSM配置到Spring Boot自动装配什么“顺序”没见过——不就是先建项目再写代码最后跑起来吗但真正把AI辅助开发工具比如飞算JavaAI这类接进日常流程之后我才发现这个“顺序”跟以前理解的完全不是一回事。它说的不是操作步骤的先后而是四个指令之间存在严格的依赖关系前一个指令的输出直接构成后一个指令的输入上下文跳步或者乱序AI给出的结果基本没法用。先把结论摆在这儿这四个指令通常对应的是需求描述、数据模型定义、接口契约生成、业务逻辑填充。它们必须按顺序跑核心原因在于AI全栈开发工具的工作机制是“上下文累积式”的——每一步都在前一步产出的结构化信息基础上做增量推理。你跳过数据模型直接让它生成接口它只能靠猜猜出来的字段名、类型、关联关系跟后面真正要用的对不上返工成本比从头按顺序来高得多。这篇文章我打算把这四个指令拆开揉碎讲清楚每个指令到底在干什么、为什么不能换位置、实际操作中怎么判断上一步已经“跑到位”了、以及我踩过的那些因为顺序错乱导致的坑。适合正在用或者准备用AI辅助工具做Java全栈开发的朋友尤其是那种“想让AI帮我省事结果反而更费事”的情况。2. 四个指令的完整拆解与顺序逻辑2.1 第一个指令需求结构化——把模糊描述变成AI能吃的输入很多人用AI开发工具的第一个动作就是打开对话框敲一句“帮我做一个电商后台管理系统”。这个做法不能说错但效率极低。AI全栈开发工具的第一个指令正确用法是把自然语言需求转成结构化的功能清单和实体关系描述。为什么这个必须排第一因为后面所有指令都依赖这里产出的“实体”和“关系”。比如你说“做一个订单管理模块”AI需要知道订单跟用户是什么关系一对多还是多对一、订单跟商品是什么关系多对多通过中间表、订单本身有哪些状态流转。这些信息如果在第一个指令里没交代清楚第二个指令生成的数据模型就是残缺的。我通常的做法是分两步走。第一步先用一段话把业务场景说清楚不用管格式第二步让AI把这段话拆成“实体列表关系描述关键字段”三部分。举个例子原始输入做一个简单的图书借阅系统读者可以借书还书管理员可以管理图书和读者。 结构化输出 实体读者、图书、借阅记录 关系读者与借阅记录一对多图书与借阅记录一对多 关键字段 - 读者姓名、证件号、联系方式、状态 - 图书ISBN、书名、作者、库存状态 - 借阅记录借出时间、应还时间、实际归还时间、状态这一步的产出质量直接决定后面三步的天花板。我见过太多人在这里偷懒结果第三个指令生成的接口里字段名全是拼音缩写第四个指令填充的业务逻辑里状态判断缺东少西。注意第一个指令不要涉及任何技术选型。不要说“用MySQL”或者“用Spring Boot”那是后面的事。这一步只关心业务概念和它们之间的关系。2.2 第二个指令数据模型定义——为什么不能跟接口生成调换位置第二个指令是基于第一步的实体关系生成具体的数据模型定义包括表结构、字段类型、约束条件、索引策略。在Java全栈场景下这一步通常产出的是DDL语句或者JPA实体类。为什么数据模型必须排在接口之前道理很简单接口的入参和出参本质上就是数据模型的子集或组合。如果你先让AI生成接口它只能根据实体名称去猜字段。比如“借阅记录”这个实体AI可能猜字段有“借阅人ID、图书ID、借阅日期”但实际业务里还需要“续借次数、逾期天数、罚款金额”这些字段。先定模型再定接口接口的字段就是确定的反过来接口生成之后发现模型缺字段改模型会导致接口全部重写。这一步我通常会做三件事让AI输出DDL和实体类两套结果DDL用于建库实体类用于后续代码生成。两套结果要交叉验证确保字段名和类型一致。手动检查关联关系的外键设置。AI有时候会把一对多关系的外键放在错误的一侧这个必须人工确认。补充索引建议。AI默认只生成主键索引但实际查询中经常需要按状态、时间范围过滤这些索引要手动加上去。-- AI生成的借阅记录表我调整过索引部分 CREATE TABLE borrow_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, reader_id BIGINT NOT NULL, book_id BIGINT NOT NULL, borrow_time DATETIME NOT NULL, due_time DATETIME NOT NULL, return_time DATETIME, status TINYINT DEFAULT 1 COMMENT 1借出 2已还 3逾期, renew_count INT DEFAULT 0, INDEX idx_reader (reader_id), INDEX idx_book (book_id), INDEX idx_status_due (status, due_time) );实操心得这一步生成的实体类不要急着让AI加Lombok注解或者Swagger注解那些是第三个指令之后的事。模型层保持干净只包含字段定义和基本的getter/setter后面改起来才灵活。2.3 第三个指令接口契约生成——依赖关系最密集的一步第三个指令是在数据模型确定之后生成Controller层的接口定义和Service层的接口方法签名。这一步是整个流程里依赖关系最密集的环节因为它同时依赖第一步的“功能清单”和第二步的“数据模型”。为什么不能跳过第二步直接做第三步因为接口的请求体和响应体需要精确的字段类型。比如“查询借阅记录列表”这个接口返回的每条记录里要不要包含读者姓名和图书书名如果要包含就需要在数据模型之外定义VO视图对象如果只返回ID那前端还得再调一次接口。这些决策都建立在数据模型已经确定的基础上。我一般会让AI按这个模板输出// Controller接口定义 RestController RequestMapping(/api/borrow) public interface BorrowController { PostMapping(/create) ResultBorrowRecordVO createBorrow(RequestBody Valid BorrowCreateDTO dto); GetMapping(/list) ResultPageResultBorrowRecordVO listBorrow(BorrowQueryDTO query); PutMapping(/return/{recordId}) ResultVoid returnBook(PathVariable Long recordId); }对应的DTO和VO也要在这一步生成但只生成字段定义不生成业务逻辑。业务逻辑是第四个指令的事。这一步的关键检查点是接口的粒度是否合理。比如“创建借阅”这个操作是应该一个接口搞定还是拆成“检查库存”和“创建记录”两个接口我的经验是AI倾向于生成粒度较粗的接口但实际业务里往往需要更细的控制这个需要人工调整。常见坑AI生成的接口路径经常是单数形式/api/borrow而不是复数/api/borrows这个不影响功能但影响一致性。建议在第三个指令的提示词里明确要求RESTful风格。2.4 第四个指令业务逻辑填充——最后一步但最考验前面三步的质量第四个指令是让AI在已经确定的接口骨架和数据模型基础上填充Service层的具体实现逻辑。这一步之所以必须排最后是因为业务逻辑是“动词”它操作的对象是前面三步定义的“名词”和“关系”。如果前面的名词定义有歧义动词就会执行错误。举个例子借书操作里有一个“检查读者是否有逾期未还的书”的逻辑。这个逻辑依赖借阅记录表里的status字段和due_time字段。如果第二步的数据模型里status字段的定义是模糊的比如没有明确1代表什么第四个指令生成的判断条件就可能写反。这一步我通常会分两轮跑。第一轮让AI生成主流程代码比如创建借阅记录、更新图书库存状态第二轮让AI补充异常分支和边界条件比如库存不足时抛什么异常、并发借同一本书怎么处理。两轮之间我会人工检查第一轮的产出把明显的逻辑错误修掉再跑第二轮。// 第四步生成的Service实现节选 Service public class BorrowServiceImpl implements BorrowService { Override Transactional public BorrowRecordVO createBorrow(BorrowCreateDTO dto) { // 检查读者状态 Reader reader readerMapper.selectById(dto.getReaderId()); if (reader.getStatus() 0) { throw new BusinessException(读者账户已冻结); } // 检查是否有逾期未还 Long overdueCount borrowRecordMapper.countOverdue(dto.getReaderId()); if (overdueCount 0) { throw new BusinessException(存在逾期未还图书请先归还); } // 检查库存 Book book bookMapper.selectById(dto.getBookId()); if (book.getStock() 0) { throw new BusinessException(图书库存不足); } // 扣减库存并创建记录 bookMapper.decreaseStock(dto.getBookId()); BorrowRecord record new BorrowRecord(); // ... 字段填充 borrowRecordMapper.insert(record); return convertToVO(record); } }关键提醒第四个指令生成的代码里事务注解、异常类型、日志打点这些细节需要根据项目规范统一调整。AI默认生成的异常处理往往过于简单生产环境需要更细的分类。3. 顺序错乱会引发哪些连锁问题3.1 先做接口后做模型字段对不上的返工噩梦我刚开始用AI工具时就犯过这个错。当时觉得“先把接口定下来模型后面再补”更符合敏捷开发的思路。结果第三个指令生成的接口里借阅记录的返回字段有“readerName”和“bookName”但第二个指令生成数据模型时我忘了在借阅记录表里加这两个冗余字段实际应该通过JOIN查询获取。等发现的时候接口的VO定义、Service的转换方法、前端的调用代码全都要改。更隐蔽的问题是类型不匹配。接口里定义的是LocalDateTime模型里生成的是Date这种差异在编译期不一定报错但运行时的序列化结果会出问题。AI不会主动帮你做类型映射它只根据当前上下文生成代码。上下文顺序错了类型就对不上。3.2 跳过需求结构化AI开始“自由发挥”有一次我直接跳到第二个指令跟AI说“生成一个博客系统的数据模型”。AI确实生成了包括用户表、文章表、评论表、标签表。但实际需求里还有“文章草稿箱”和“定时发布”功能这两个功能需要额外的状态字段和定时任务表。因为第一个指令没做AI完全不知道这些需求的存在。这种“自由发挥”在简单场景下问题不大但在复杂业务里就是灾难。AI会按照最常见的模式生成模型而你的业务偏偏不是最常见的那种。等第四个指令填充业务逻辑时你会发现缺了太多东西只能回头补第一个指令然后重新跑第二、三、四个指令。时间全浪费在返工上。3.3 四个指令的依赖关系速查表指令序号指令名称依赖的前置指令主要产出跳步后果1需求结构化无实体列表、关系描述、功能清单后续所有步骤缺乏业务上下文2数据模型定义指令1DDL、实体类、索引策略接口字段靠猜类型不一致3接口契约生成指令1、指令2Controller接口、DTO/VO定义业务逻辑缺乏操作对象4业务逻辑填充指令1、2、3Service实现、异常处理逻辑与接口不匹配事务边界模糊这张表我建议贴在显示器旁边。每次想跳步的时候看一眼能省下不少返工时间。4. 实操中怎么判断每一步“跑到位”了4.1 第一个指令的验收标准能不能画出ER图第一个指令跑完之后我会拿一张纸把AI输出的实体和关系画成ER图。如果能画出来且没有歧义说明这一步到位了。画不出来的地方就是需求描述模糊的地方需要补充说明重新跑。比如AI输出“用户和角色是多对多关系”但实际业务里角色可能还分“系统角色”和“自定义角色”这两种角色的关联方式不一样。画ER图的时候就会发现这个歧义及时补上。4.2 第二个指令的验收标准DDL能不能直接执行第二个指令的输出我通常会直接丢到测试库里执行一遍。能执行通过只是最低标准还要检查三件事字段类型是否合理比如金额用DECIMAL而不是FLOAT、索引是否覆盖主要查询场景、外键约束是否会影响后续的数据迁移。小技巧让AI在DDL里加上注释每个字段的注释就是它的业务含义。后面第三个指令生成接口时AI会参考这些注释来命名DTO字段减少歧义。4.3 第三个指令的验收标准接口能不能通过Mock测试第三个指令的输出可以用Postman或者curl做一轮Mock测试。不需要真实的数据只要接口能返回结构正确的假数据就算通过。这一步主要检查接口的路径、方法、参数位置path/query/body是否符合预期。我一般会写一个简单的检查清单所有接口路径是否以/api开头分页查询是否统一使用pageNum和pageSize参数创建和更新操作是否区分POST和PUT删除操作是否使用DELETE方法返回结构是否统一为Result 包装4.4 第四个指令的验收标准核心流程能不能跑通第四个指令跑完之后我会挑一个最核心的业务流程做端到端测试。比如借书流程创建借阅记录→扣减库存→查询借阅列表→归还图书→恢复库存。这个流程能跑通说明四个指令的衔接没有问题。跑不通的地方就是需要回头调整的地方。但注意不要直接改第四个指令生成的代码而是回到对应的前置指令去修。比如发现库存扣减逻辑不对应该回到第二个指令检查库存字段的定义而不是在Service里硬改。这样才能保持四个指令的一致性。5. 常见问题与排查技巧实录5.1 AI生成的字段名跟预期不一致怎么办这个问题几乎每次都会遇到。AI倾向于用驼峰命名法生成Java字段但数据库字段可能是下划线命名。我的做法是在第二个指令的提示词里明确要求“数据库字段使用下划线命名Java实体类字段使用驼峰命名并在实体类中通过Column注解建立映射关系。”这样第三个和第四个指令生成的代码就会自动遵循这个规范。如果已经生成了不一致的代码不要手动一个个改。把不一致的地方整理成列表回到第二个指令重新跑一遍让AI统一修正。手动改容易漏而且下次重新生成时又乱了。5.2 第四个指令生成的业务逻辑太简单怎么办AI默认生成的业务逻辑通常只覆盖主流程异常分支和边界条件需要额外提示。我的做法是在第四个指令的提示词里加一段“请考虑以下异常场景数据不存在、状态不允许操作、并发冲突、参数校验失败。每个场景都要有对应的异常抛出和错误码。”如果还是不够就分多轮跑。第一轮生成主流程第二轮专门生成异常处理第三轮专门生成日志和监控打点。每轮之间人工检查确保不冲突。5.3 四个指令跑完之后发现需求变了怎么办这是最头疼的情况。我的经验是小改动直接改第四个指令的输出大改动从第一个指令重新跑。判断标准是看改动是否影响实体和关系。如果只是加一个字段或者改一个判断条件在Service层改就行如果要加一个新实体或者改变实体之间的关系必须从第一个指令重新来。重新跑的时候可以把之前生成的代码作为参考提供给AI让它在此基础上做增量修改而不是完全从零开始。这样能保留之前已经验证过的部分。5.4 常见问题速查表问题现象可能原因排查方向解决方式接口字段与模型字段不匹配第二、三指令顺序颠倒检查DTO字段是否在实体类中存在回到第二指令补字段重跑第三指令业务逻辑缺少异常处理第四指令提示词不完整检查Service方法是否有try-catch补充异常场景提示词重跑第四指令数据库表缺少索引第二指令未指定查询场景检查WHERE条件涉及的字段在第二指令中补充索引要求接口路径风格不统一第三指令未指定RESTful规范检查所有Controller的RequestMapping统一路径规范重跑第三指令实体关系映射错误第一指令关系描述模糊检查ER图是否有歧义补充关系描述从第一指令重跑最后分享一个我自己的习惯每次跑完四个指令我会把整个对话记录导出成一个Markdown文件按指令序号分章节保存。下次做类似项目时直接参考这个文件调整提示词效率能提升不少。而且出了问题回溯的时候能清楚看到是哪一步的输入有问题。这个流程我用了大半年最大的体会是AI全栈开发工具的效率优势建立在“喂对上下文”的基础上。四个指令的顺序本质上是在构建一个逐步细化的上下文链条链条断了AI就只能靠猜。猜对了是运气猜错了是常态。按顺序跑看起来慢实际上是最快的路径。
1. 为什么“顺序”这件事在AI全栈开发里被反复强调第一次看到“AI全栈开发的四个指令为什么必须按顺序跑”这个说法我其实没太当回事。干Java这行十来年从Eclipse换到IDEA从手写SSM配置到Spring Boot自动装配什么“顺序”没见过——不就是先建项目再写代码最后跑起来吗但真正把AI辅助开发工具比如飞算JavaAI这类接进日常流程之后我才发现这个“顺序”跟以前理解的完全不是一回事。它说的不是操作步骤的先后而是四个指令之间存在严格的依赖关系前一个指令的输出直接构成后一个指令的输入上下文跳步或者乱序AI给出的结果基本没法用。先把结论摆在这儿这四个指令通常对应的是需求描述、数据模型定义、接口契约生成、业务逻辑填充。它们必须按顺序跑核心原因在于AI全栈开发工具的工作机制是“上下文累积式”的——每一步都在前一步产出的结构化信息基础上做增量推理。你跳过数据模型直接让它生成接口它只能靠猜猜出来的字段名、类型、关联关系跟后面真正要用的对不上返工成本比从头按顺序来高得多。这篇文章我打算把这四个指令拆开揉碎讲清楚每个指令到底在干什么、为什么不能换位置、实际操作中怎么判断上一步已经“跑到位”了、以及我踩过的那些因为顺序错乱导致的坑。适合正在用或者准备用AI辅助工具做Java全栈开发的朋友尤其是那种“想让AI帮我省事结果反而更费事”的情况。2. 四个指令的完整拆解与顺序逻辑2.1 第一个指令需求结构化——把模糊描述变成AI能吃的输入很多人用AI开发工具的第一个动作就是打开对话框敲一句“帮我做一个电商后台管理系统”。这个做法不能说错但效率极低。AI全栈开发工具的第一个指令正确用法是把自然语言需求转成结构化的功能清单和实体关系描述。为什么这个必须排第一因为后面所有指令都依赖这里产出的“实体”和“关系”。比如你说“做一个订单管理模块”AI需要知道订单跟用户是什么关系一对多还是多对一、订单跟商品是什么关系多对多通过中间表、订单本身有哪些状态流转。这些信息如果在第一个指令里没交代清楚第二个指令生成的数据模型就是残缺的。我通常的做法是分两步走。第一步先用一段话把业务场景说清楚不用管格式第二步让AI把这段话拆成“实体列表关系描述关键字段”三部分。举个例子原始输入做一个简单的图书借阅系统读者可以借书还书管理员可以管理图书和读者。 结构化输出 实体读者、图书、借阅记录 关系读者与借阅记录一对多图书与借阅记录一对多 关键字段 - 读者姓名、证件号、联系方式、状态 - 图书ISBN、书名、作者、库存状态 - 借阅记录借出时间、应还时间、实际归还时间、状态这一步的产出质量直接决定后面三步的天花板。我见过太多人在这里偷懒结果第三个指令生成的接口里字段名全是拼音缩写第四个指令填充的业务逻辑里状态判断缺东少西。注意第一个指令不要涉及任何技术选型。不要说“用MySQL”或者“用Spring Boot”那是后面的事。这一步只关心业务概念和它们之间的关系。2.2 第二个指令数据模型定义——为什么不能跟接口生成调换位置第二个指令是基于第一步的实体关系生成具体的数据模型定义包括表结构、字段类型、约束条件、索引策略。在Java全栈场景下这一步通常产出的是DDL语句或者JPA实体类。为什么数据模型必须排在接口之前道理很简单接口的入参和出参本质上就是数据模型的子集或组合。如果你先让AI生成接口它只能根据实体名称去猜字段。比如“借阅记录”这个实体AI可能猜字段有“借阅人ID、图书ID、借阅日期”但实际业务里还需要“续借次数、逾期天数、罚款金额”这些字段。先定模型再定接口接口的字段就是确定的反过来接口生成之后发现模型缺字段改模型会导致接口全部重写。这一步我通常会做三件事让AI输出DDL和实体类两套结果DDL用于建库实体类用于后续代码生成。两套结果要交叉验证确保字段名和类型一致。手动检查关联关系的外键设置。AI有时候会把一对多关系的外键放在错误的一侧这个必须人工确认。补充索引建议。AI默认只生成主键索引但实际查询中经常需要按状态、时间范围过滤这些索引要手动加上去。-- AI生成的借阅记录表我调整过索引部分 CREATE TABLE borrow_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, reader_id BIGINT NOT NULL, book_id BIGINT NOT NULL, borrow_time DATETIME NOT NULL, due_time DATETIME NOT NULL, return_time DATETIME, status TINYINT DEFAULT 1 COMMENT 1借出 2已还 3逾期, renew_count INT DEFAULT 0, INDEX idx_reader (reader_id), INDEX idx_book (book_id), INDEX idx_status_due (status, due_time) );实操心得这一步生成的实体类不要急着让AI加Lombok注解或者Swagger注解那些是第三个指令之后的事。模型层保持干净只包含字段定义和基本的getter/setter后面改起来才灵活。2.3 第三个指令接口契约生成——依赖关系最密集的一步第三个指令是在数据模型确定之后生成Controller层的接口定义和Service层的接口方法签名。这一步是整个流程里依赖关系最密集的环节因为它同时依赖第一步的“功能清单”和第二步的“数据模型”。为什么不能跳过第二步直接做第三步因为接口的请求体和响应体需要精确的字段类型。比如“查询借阅记录列表”这个接口返回的每条记录里要不要包含读者姓名和图书书名如果要包含就需要在数据模型之外定义VO视图对象如果只返回ID那前端还得再调一次接口。这些决策都建立在数据模型已经确定的基础上。我一般会让AI按这个模板输出// Controller接口定义 RestController RequestMapping(/api/borrow) public interface BorrowController { PostMapping(/create) ResultBorrowRecordVO createBorrow(RequestBody Valid BorrowCreateDTO dto); GetMapping(/list) ResultPageResultBorrowRecordVO listBorrow(BorrowQueryDTO query); PutMapping(/return/{recordId}) ResultVoid returnBook(PathVariable Long recordId); }对应的DTO和VO也要在这一步生成但只生成字段定义不生成业务逻辑。业务逻辑是第四个指令的事。这一步的关键检查点是接口的粒度是否合理。比如“创建借阅”这个操作是应该一个接口搞定还是拆成“检查库存”和“创建记录”两个接口我的经验是AI倾向于生成粒度较粗的接口但实际业务里往往需要更细的控制这个需要人工调整。常见坑AI生成的接口路径经常是单数形式/api/borrow而不是复数/api/borrows这个不影响功能但影响一致性。建议在第三个指令的提示词里明确要求RESTful风格。2.4 第四个指令业务逻辑填充——最后一步但最考验前面三步的质量第四个指令是让AI在已经确定的接口骨架和数据模型基础上填充Service层的具体实现逻辑。这一步之所以必须排最后是因为业务逻辑是“动词”它操作的对象是前面三步定义的“名词”和“关系”。如果前面的名词定义有歧义动词就会执行错误。举个例子借书操作里有一个“检查读者是否有逾期未还的书”的逻辑。这个逻辑依赖借阅记录表里的status字段和due_time字段。如果第二步的数据模型里status字段的定义是模糊的比如没有明确1代表什么第四个指令生成的判断条件就可能写反。这一步我通常会分两轮跑。第一轮让AI生成主流程代码比如创建借阅记录、更新图书库存状态第二轮让AI补充异常分支和边界条件比如库存不足时抛什么异常、并发借同一本书怎么处理。两轮之间我会人工检查第一轮的产出把明显的逻辑错误修掉再跑第二轮。// 第四步生成的Service实现节选 Service public class BorrowServiceImpl implements BorrowService { Override Transactional public BorrowRecordVO createBorrow(BorrowCreateDTO dto) { // 检查读者状态 Reader reader readerMapper.selectById(dto.getReaderId()); if (reader.getStatus() 0) { throw new BusinessException(读者账户已冻结); } // 检查是否有逾期未还 Long overdueCount borrowRecordMapper.countOverdue(dto.getReaderId()); if (overdueCount 0) { throw new BusinessException(存在逾期未还图书请先归还); } // 检查库存 Book book bookMapper.selectById(dto.getBookId()); if (book.getStock() 0) { throw new BusinessException(图书库存不足); } // 扣减库存并创建记录 bookMapper.decreaseStock(dto.getBookId()); BorrowRecord record new BorrowRecord(); // ... 字段填充 borrowRecordMapper.insert(record); return convertToVO(record); } }关键提醒第四个指令生成的代码里事务注解、异常类型、日志打点这些细节需要根据项目规范统一调整。AI默认生成的异常处理往往过于简单生产环境需要更细的分类。3. 顺序错乱会引发哪些连锁问题3.1 先做接口后做模型字段对不上的返工噩梦我刚开始用AI工具时就犯过这个错。当时觉得“先把接口定下来模型后面再补”更符合敏捷开发的思路。结果第三个指令生成的接口里借阅记录的返回字段有“readerName”和“bookName”但第二个指令生成数据模型时我忘了在借阅记录表里加这两个冗余字段实际应该通过JOIN查询获取。等发现的时候接口的VO定义、Service的转换方法、前端的调用代码全都要改。更隐蔽的问题是类型不匹配。接口里定义的是LocalDateTime模型里生成的是Date这种差异在编译期不一定报错但运行时的序列化结果会出问题。AI不会主动帮你做类型映射它只根据当前上下文生成代码。上下文顺序错了类型就对不上。3.2 跳过需求结构化AI开始“自由发挥”有一次我直接跳到第二个指令跟AI说“生成一个博客系统的数据模型”。AI确实生成了包括用户表、文章表、评论表、标签表。但实际需求里还有“文章草稿箱”和“定时发布”功能这两个功能需要额外的状态字段和定时任务表。因为第一个指令没做AI完全不知道这些需求的存在。这种“自由发挥”在简单场景下问题不大但在复杂业务里就是灾难。AI会按照最常见的模式生成模型而你的业务偏偏不是最常见的那种。等第四个指令填充业务逻辑时你会发现缺了太多东西只能回头补第一个指令然后重新跑第二、三、四个指令。时间全浪费在返工上。3.3 四个指令的依赖关系速查表指令序号指令名称依赖的前置指令主要产出跳步后果1需求结构化无实体列表、关系描述、功能清单后续所有步骤缺乏业务上下文2数据模型定义指令1DDL、实体类、索引策略接口字段靠猜类型不一致3接口契约生成指令1、指令2Controller接口、DTO/VO定义业务逻辑缺乏操作对象4业务逻辑填充指令1、2、3Service实现、异常处理逻辑与接口不匹配事务边界模糊这张表我建议贴在显示器旁边。每次想跳步的时候看一眼能省下不少返工时间。4. 实操中怎么判断每一步“跑到位”了4.1 第一个指令的验收标准能不能画出ER图第一个指令跑完之后我会拿一张纸把AI输出的实体和关系画成ER图。如果能画出来且没有歧义说明这一步到位了。画不出来的地方就是需求描述模糊的地方需要补充说明重新跑。比如AI输出“用户和角色是多对多关系”但实际业务里角色可能还分“系统角色”和“自定义角色”这两种角色的关联方式不一样。画ER图的时候就会发现这个歧义及时补上。4.2 第二个指令的验收标准DDL能不能直接执行第二个指令的输出我通常会直接丢到测试库里执行一遍。能执行通过只是最低标准还要检查三件事字段类型是否合理比如金额用DECIMAL而不是FLOAT、索引是否覆盖主要查询场景、外键约束是否会影响后续的数据迁移。小技巧让AI在DDL里加上注释每个字段的注释就是它的业务含义。后面第三个指令生成接口时AI会参考这些注释来命名DTO字段减少歧义。4.3 第三个指令的验收标准接口能不能通过Mock测试第三个指令的输出可以用Postman或者curl做一轮Mock测试。不需要真实的数据只要接口能返回结构正确的假数据就算通过。这一步主要检查接口的路径、方法、参数位置path/query/body是否符合预期。我一般会写一个简单的检查清单所有接口路径是否以/api开头分页查询是否统一使用pageNum和pageSize参数创建和更新操作是否区分POST和PUT删除操作是否使用DELETE方法返回结构是否统一为Result 包装4.4 第四个指令的验收标准核心流程能不能跑通第四个指令跑完之后我会挑一个最核心的业务流程做端到端测试。比如借书流程创建借阅记录→扣减库存→查询借阅列表→归还图书→恢复库存。这个流程能跑通说明四个指令的衔接没有问题。跑不通的地方就是需要回头调整的地方。但注意不要直接改第四个指令生成的代码而是回到对应的前置指令去修。比如发现库存扣减逻辑不对应该回到第二个指令检查库存字段的定义而不是在Service里硬改。这样才能保持四个指令的一致性。5. 常见问题与排查技巧实录5.1 AI生成的字段名跟预期不一致怎么办这个问题几乎每次都会遇到。AI倾向于用驼峰命名法生成Java字段但数据库字段可能是下划线命名。我的做法是在第二个指令的提示词里明确要求“数据库字段使用下划线命名Java实体类字段使用驼峰命名并在实体类中通过Column注解建立映射关系。”这样第三个和第四个指令生成的代码就会自动遵循这个规范。如果已经生成了不一致的代码不要手动一个个改。把不一致的地方整理成列表回到第二个指令重新跑一遍让AI统一修正。手动改容易漏而且下次重新生成时又乱了。5.2 第四个指令生成的业务逻辑太简单怎么办AI默认生成的业务逻辑通常只覆盖主流程异常分支和边界条件需要额外提示。我的做法是在第四个指令的提示词里加一段“请考虑以下异常场景数据不存在、状态不允许操作、并发冲突、参数校验失败。每个场景都要有对应的异常抛出和错误码。”如果还是不够就分多轮跑。第一轮生成主流程第二轮专门生成异常处理第三轮专门生成日志和监控打点。每轮之间人工检查确保不冲突。5.3 四个指令跑完之后发现需求变了怎么办这是最头疼的情况。我的经验是小改动直接改第四个指令的输出大改动从第一个指令重新跑。判断标准是看改动是否影响实体和关系。如果只是加一个字段或者改一个判断条件在Service层改就行如果要加一个新实体或者改变实体之间的关系必须从第一个指令重新来。重新跑的时候可以把之前生成的代码作为参考提供给AI让它在此基础上做增量修改而不是完全从零开始。这样能保留之前已经验证过的部分。5.4 常见问题速查表问题现象可能原因排查方向解决方式接口字段与模型字段不匹配第二、三指令顺序颠倒检查DTO字段是否在实体类中存在回到第二指令补字段重跑第三指令业务逻辑缺少异常处理第四指令提示词不完整检查Service方法是否有try-catch补充异常场景提示词重跑第四指令数据库表缺少索引第二指令未指定查询场景检查WHERE条件涉及的字段在第二指令中补充索引要求接口路径风格不统一第三指令未指定RESTful规范检查所有Controller的RequestMapping统一路径规范重跑第三指令实体关系映射错误第一指令关系描述模糊检查ER图是否有歧义补充关系描述从第一指令重跑最后分享一个我自己的习惯每次跑完四个指令我会把整个对话记录导出成一个Markdown文件按指令序号分章节保存。下次做类似项目时直接参考这个文件调整提示词效率能提升不少。而且出了问题回溯的时候能清楚看到是哪一步的输入有问题。这个流程我用了大半年最大的体会是AI全栈开发工具的效率优势建立在“喂对上下文”的基础上。四个指令的顺序本质上是在构建一个逐步细化的上下文链条链条断了AI就只能靠猜。猜对了是运气猜错了是常态。按顺序跑看起来慢实际上是最快的路径。
