从0到上线一个图书管理系统：Java程序员用飞算JavaAI四步走完全栈
前面的文章拆过需求分析、前后端设计、前端开发、后端开发各自怎么用。今天把它们串成一条线——用图书管理系统，从一句需求走到系统上线，看一个只写过 Java 的后端，是怎么四步把全栈交付掉下来的。
后端同学转全栈，通常被三道坎拦住：需求说不清、前端不会写、联调对不齐。前面四篇分别拆过解法，这一篇是把它们接成一条流水线，看三道坎是怎么被逐个填平的。
不用先学 Vue，不用先背 npm 命令。你只需要跟着流水线的顺序走，前一步是后一步的硬前提。
第一步：/需求分析——先把话说清楚
一切从一句白话需求开始。你不需要写 PRD，把脑子里的东西自然说出来就行：
做一个图书管理系统。
- 图书有 ISBN、书名、作者、分类、在馆状态
- 能按关键词和分类检索图书
- 读者可以借书、还书，借了能看到借阅记录
- 借出的书不能重复借，超期要有标记
把这个丢进「添加指令」选 /需求分析。它做的第一件事不是写代码，而是反问澄清——「超期怎么定义，按天数还是按固定归还日？」「分类是固定几个还是可维护？」「借阅记录要支持按读者筛选吗？」
你把歧义答完，它产出两份文档：需求文档和业务设计文档，自动存进当前项目的 docs 目录。
比如它会追问：「逾期是按固定还书日算，还是借出后 N 天算？」「分类由管理员维护还是系统预置？」「借阅记录要不要支持按读者筛选？」这些点在传统开发里常被含糊带过，等到联调甚至上线才暴露，返工成本最高。需求分析把它们提前到了写代码之前。
这一句命令就够：添加指令 → /需求分析 → 输入上面那段需求。产物是 docs/ 下的两份文档，后面三步都靠它们吃饭。
第二步：/前后端设计——一份契约，两端共用
拿着第一步的需求文档，选 /前后端设计。它会读取上游文档作为依据，把业务设计翻译成技术层面能落地的东西，然后产出一组文档存进 docs：
- 工作区上下文
- 技术栈决策（默认 Spring Boot + MyBatis + Vue3）
- 数据库设计（
Book/Category/BorrowRecord三张表及字段） - 接口设计（
GET /api/books、POST /api/borrow、POST /api/return等） - 技术需求覆盖
- 后端设计规范基线
还会据此推导前端页面设计。这一步是整条流水线的灵魂：接口契约先定下来，前后端从同一份定义生长，字段和类型天然不可能漂移。
拿数据库设计这部分的产出举个例，三张核心表直接落成了结构：
| 表 | 核心字段 | 备注 |
|---|---|---|
book | id, isbn, title, author, category_id, status, publish_year | status 标识在馆/借出 |
category | id, name | 图书分类 |
borrow_record | id, book_id, reader_id, borrow_date, due_date, return_date, status | status 标识借阅中/已归还/逾期 |
接口设计也同步定稿：GET /api/books?keyword=&categoryId= 检索、POST /api/borrow 借书、POST /api/return 还书、GET /api/borrow/records 记录查询。后面三步生成的代码，全部锚定在这张表和两个文档上。
命令：添加指令 → /前后端设计 → "帮我完成图书管理系统的前后端设计。"
产物：docs/ 下六份设计文档 + 一份前端页面设计。
第三步：/前端开发——从设计长出页面
确认设计文档齐全后，选 /前端开发，输入「帮我完成图书管理系统的前端页面开发」。它读取上游前端设计文件，生成标准 Vue3 工程。
生成完，在 IDEA 终端 cd 到前端目录，两步走：
npm install # 装依赖
npm run dev # 启动，浏览器预览
页面骨架、API 封装、类型定义都是从契约生成的。你拿到的是「能读懂、能微调」的代码，不是从零手写。类型定义直接由后端接口派生，前端写错字段名 IDE 立刻报红，不再靠人肉发现。等后端起来，前端就能联调。
命令：添加指令 → /前端开发 → 描述 → npm install && npm run dev。
产物：一个能跑起来的 Vue3 前端工程。
第四步：/后端开发——生成代码、一键修复、联调
最后选 /后端开发，输入「根据图书管理系统的相关文档，完成后端的代码开发。」它读取设计文档，生成 Spring Boot 的 Entity / Mapper / Service / Controller。
代码跑起来如果报红，别自己熬夜抠。打开工具箱点「一键修复」，它会定位报错、自动修补可修复的模式（日期转换、空指针判空、事务配置等），改完重新编译反馈结果。修好之后启动后端，和已经 npm run dev 的前端联调。
生成的 BorrowService 里，借书逻辑默认带着「在馆状态校验 + 冲突拦截」——这正是图书系统的业务核心，也是手写时最容易漏边界的地方。你拿到的不是空壳，而是带校验骨架的可运行代码。
因为契约同源，联调你主要验的是业务规则：同一本书借出后不能再借、超期要标「逾期」、还书后状态回到「在馆」。这些规则对不对，得你亲自跑场景确认。
命令：添加指令 → /后端开发 → 描述 → 一键修复 → 启动联调。
产物：可运行的后端工程 + 跑通的前后端闭环。
落地之前，你还得补三刀
四步走完，系统能跑、能联调，但离「能上线」还差几件只有人能定的事。别把生成的工程当成品直接推生产：
- 数据库索引。
book_id、reader_id上的查询必须要有索引，契约和生成逻辑都不会替你决定，得你对着实际查询量拍； - 并发策略。借书冲突检测要不要上分布式锁、锁的粒度多大，取决于你们真实的并发压力，不是一键开关；
- 公司基建对齐。统一的鉴权、日志、分页、链路追踪切面，生成的是干净骨架，得你接进现有体系。
这三刀补完，它才从「demo」变成「系统」。工具负责把脏活干掉，边界判断和责任归属始终是你自己的。
传统人工 vs 飞算JavaAI 四步流水线
回到开头那个图书管理系统，同一份需求，两种走法的差距：
| 环节 | 传统人工（后端主导） | 飞算JavaAI 四步流水线 | 缩短 |
|---|---|---|---|
| 需求澄清 | 0.5 天，靠开会对齐歧义 | 5 分钟，反问把歧义问死 | ~98% |
| 前后端设计 | 1 天，契约常跳过 | 自动产出六份文档 + 契约 | ~95% |
| 后端工程 | 2 天 | 约 3 分钟生成 + 微调 | ~85% |
| 前端页面 | 5 天，学习成本占大头 | 约 3 分钟生成 + 1 小时微调 | ~95% |
| 联调 | 3 天，字段格式对不齐 | 接近 0，同源契约 | ~95% |
| 合计 | 11.5 天 | 约 2 小时 | ~97% |
质量结构的变化比工时更值得看：
| 质量维度 | 人工常见情况 | 流水线生成 |
|---|---|---|
| 字段一致性 | 微信群一句句对齐 | 契约同源，类型系统保证 |
| 空指针防护 | 测试阶段才暴露 | 一键修复编译期补判空 |
| 事务配置 | 默认只回滚 RuntimeException | 显式 rollbackFor |
| 业务规则 | 想到哪写到哪 | 由需求推导，不易漏 |
| 超期/冲突逻辑 | 容易边界写错 | 生成带校验，人审规则 |
四步走完，一个图书管理系统从需求到上线就落在了手里。中间没有逼你去学框架，没有让前端成为跨不过的墙——你做的只是确认业务取舍、把生成结果接进公司既有基建。
AI 不替你思考业务，但替你跨过那道本不该存在的墙；工具的价值是把「必须人会」变成「机器默认就会」。对一个写了多年 Java 的人来说，全栈第一次变得不是「再去学一门语言」，而是「把已经想清楚的业务，直接交付出去」。
9
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
