OKOK大家好欢迎大家来到大鹏 AI 教育我是张大鹏。上一篇我讲了为什么要做RuyiLibraryAdmin这个图书管理系统也讲了为什么第一阶段不急着上 Django、FastAPI 或数据库而是先把前端业务 Mock 跑起来。今天这篇我想换一个更直接的问题纯 AI 开发一个图书管理系统这套技术栈到底真不真香我先把答案放在前面如果目标是做一个能演示、能截图、能部署、能持续迭代的后台管理系统React TypeScript Vite shadcn/ui TanStack Cloudflare这套组合我认为是很香的。但它的香不是因为它听起来高级而是因为它特别适合 AI 协作开发。先看最终要做成什么样这个项目第一阶段我准备先做 7 个基础页面登录页仪表盘图书管理借阅管理读者管理分类管理关于/联系页也就是说它不是一个只有首页和几个按钮的玩具项目而是一个真正有后台系统味道的图书管理系统。这里先放一张总览截图。等页面完成以后这张图会展示图书总数、在库图书、借出图书、逾期记录、热门书籍和借阅趋势。为什么我说它适合纯 AI 开发纯 AI 开发最怕什么不是 AI 写不出代码。现在的问题反而是AI 太能写了。你给它一句“做一个图书管理系统”它马上能生成一大堆页面、一堆组件、一堆假数据。但这种代码经常有一个问题刚开始看着很快后面越改越乱。所以我判断一个技术栈适不适合 AI 开发主要看三个标准第一目录结构能不能清楚拆分。第二类型系统能不能兜住错误。第三每个模块能不能单独验证。React TypeScript TanStack shadcn/ui这套组合刚好满足这三个条件。React 负责组件TypeScript 负责类型TanStack Router 负责路由TanStack Table 负责复杂表格React Hook Form 和 Zod 负责表单和校验。AI 写错一个表单字段TypeScript 能提醒。AI 改错一个路由构建能发现。AI 生成一个表格列TanStack Table 的结构也比较容易约束。这就是我说的“适合 AI 开发”。不是靠感觉而是靠工程边界把 AI 的输出关进一个可靠范围里。图书管理页面是核心图书管理系统最核心的页面一定是图书列表。这个页面看起来普通其实很考验后台系统的基本功。它至少要包含书名作者ISBN分类出版社馆藏位置总库存在库数量借出数量状态后续我会让 AI 先基于 Mock 数据生成这张表再逐步加搜索、筛选、编辑、上下架和导入导出。我不会一上来就让 AI 做特别复杂的功能。第一版先把列表做稳再补操作。这样每一步都能截图、能验证、能写成课程内容。借阅管理决定系统有没有业务味很多后台模板最大的问题是页面很漂亮但没有业务。图书管理系统要有业务味关键就在借阅管理。借阅记录里至少要有借阅编号图书读者借出日期应还日期实际归还日期状态借阅中、已归还、已逾期操作还书、续借、查看详情这个页面后面可以讲很多东西。比如状态流转怎么设计逾期怎么计算续借规则怎么限制读者最多能借几本书。这些都是课堂里很好的实战点。读者管理不是简单用户表读者管理也不是随便放一张用户表。在图书系统里读者有自己的业务属性读者类型学生、教师、会员借阅额度当前借阅数逾期次数账号状态最近借阅时间这个页面做出来以后系统就开始有“人”和“书”的关系了。后台系统一旦有了关系项目就不再是静态页面而是能往真实业务继续长。为什么先做 Mock不直接接数据库这个问题我在直播间肯定会反复讲。很多同学一开始做项目就想数据库、接口、权限、部署全都一起上。结果一周过去前端没成型接口没调通页面也没法展示。我的习惯是先做可演示版本。Mock 数据不是偷懒而是让我们先把业务模型跑通。等页面、字段、流程都稳定了再接真实 API。这样后端就不是凭空设计而是根据已经跑通的前端体验反推接口。这对 AI 开发尤其重要。因为 AI 最适合做边界明确的任务。你让它“把这份 Mock 数据替换成真实接口”比让它“一口气设计完整前后端”靠谱得多。自动截图是基础设施这次我会把自动截图作为第一阶段的基础能力。计划脚本是pnpmscreenshots固定输出docs/screenshots/01-login.png docs/screenshots/02-dashboard.png docs/screenshots/03-books.png docs/screenshots/04-loans.png docs/screenshots/05-readers.png docs/screenshots/06-categories.png docs/screenshots/07-about-contact.png为什么这么早就做截图因为截图不是最后发博客才需要的东西。截图是项目验收的一部分。我做完登录页截图能不能出做完图书管理截图能不能出做完借阅管理截图能不能出只要截图脚本能稳定跑这个项目就有了一个很直观的质量检查方式。Cloudflare 在这里扮演什么角色Cloudflare 不是第一天就必须接入的东西但它决定了这个项目的上线方向。第一阶段前端可以先本地跑。第二阶段把 Vite 构建产物部署到 Cloudflare Pages。第三阶段如果要接真实数据再考虑 Workers、D1 和 Drizzle。也就是说这个项目的路线是纯前端 Mock - Cloudflare Pages 演示 - Workers D1 数据版这个路线比较适合教学也比较适合做产品化演示。这套技术栈真香在哪里我觉得它真香的地方有四个。第一AI 容易写。React、TypeScript、Vite、Tailwind 都是 AI 非常熟悉的技术生成代码质量相对稳定。第二页面容易拆。图书、读者、借阅、分类每个模块都可以独立做适合一节课一个模块。第三截图容易验收。Playwright 能把页面跑一遍再生成固定截图后续写博客、做商品页、录课程都能复用。第四部署路线清晰。先 Pages再 Workers再 D1不需要第一天就背上完整后端架构。它不香的地方也要讲我不想把这篇写成单纯吹技术栈。这套方案也有几个限制。第一如果项目一开始就是复杂权限、多租户、工作流审批那纯前端 Mock 只能做演示不能直接商用。第二Cloudflare D1 更适合轻量业务如果未来要做大型图书馆系统可能还是要 PostgreSQL。第三AI 生成页面很快但业务规则必须由人来把关。比如逾期规则、借阅额度、库存扣减这些不能完全交给 AI 自由发挥。所以我对这套方案的定位很清楚它非常适合项目启动、课程实战、产品原型、轻量演示和后续迭代但不是一开始就把所有企业级能力都塞进去。下一步我准备做什么下一步我会先把基础页面建起来。顺序大概是初始化 React Vite 工程。建立布局、路由、侧边栏和主题。建 Mock 数据模型。做登录页、仪表盘、图书管理、借阅管理、读者管理、分类管理、关于页。接入 Playwright 自动截图。生成真实截图以后替换这篇博客里的截图占位。等这些完成以后我希望读者不是只看到我说“AI 能开发系统”而是能看到一个真实跑起来的图书管理系统有页面、有业务、有截图、有部署路线。这才是我觉得最有价值的地方。