OK，OK，大家好，欢迎大家来到大鹏 AI 教育，我是张大鹏。
今天这篇是 RuyiLibraryAdmin 的第一篇项目启动记录。这个项目我准备做成一个图书管理系统，而且这次有一个很明确的前提：纯自研，纯 AI 开发，不从现成后台模板里直接二开。
这句话听起来很爽，但真正开始做项目的时候，第一件事不是写页面，而是定技术栈。技术栈如果选错，后面每一节课、每一次直播、每一次改需求，都会被它拖住。
所以我今天先不急着写"图书列表""借阅记录""读者管理"这些页面，而是先把底层路线讲清楚：为什么我准备选择 React + TypeScript + Vite + shadcn/ui + Cloudflare 这一套。
为什么这个项目要纯自研？
之前我们研究过不少后台模板，也做过可商品化的 Mock 项目。模板二开的好处很明显：起步快，界面完整，适合快速做演示、截图、部署和卖点包装。
但图书管理系统这次我想换一个做法。
我不是只想做一个"看起来像图书系统"的页面，而是想把它做成一个可以长期讲、长期迭代、长期复用的项目。它应该能从第一张表、第一条业务规则开始，逐步长出完整后台系统的样子。
对学员来说，这种项目更适合学习。因为每一个模块为什么这样拆，每一个表格为什么这样设计，每一个接口为什么这样命名，都能在课堂上讲清楚。
对我自己来说，这也更适合沉淀方法论。AI 开发不是让 AI 随便生成一堆代码，而是我来定方向、定边界、定验收标准，让 AI 按工程节奏往前推进。
为什么前端选 React？
图书管理系统本质上是一个后台管理系统。它最常见的页面不是炫酷大屏，而是表格、筛选、表单、弹窗、状态流转和统计卡片。
React 在这类系统里非常稳。它的生态成熟，AI 也最熟悉。无论是生成表格、封装表单、拆组件，还是处理状态和路由，React 都是 AI 最容易写对的一条路线。
我不追求"最新奇"，我更看重"能持续推进"。尤其是纯 AI 开发，技术栈越稳定，AI 犯低级错误的概率越低。
所以前端我会选：
ReactTypeScriptViteTanStack RouterTanStack TableTanStack QueryReact Hook FormZodshadcn/uiTailwind CSS
这套组合的好处是边界清晰。路由归路由，表格归表格，表单归表单，接口状态归接口状态。后面我让 AI 修改某个模块时，不容易牵一发动全身。
为什么 UI 选 shadcn/ui？
我做后台项目，不希望 UI 过度包装。
图书管理系统的用户可能是图书馆管理员、学校老师、培训机构教务，甚至是小型书店老板。他们每天关心的是书有没有库存、谁借走了、什么时候该还、有没有逾期，而不是页面上有没有花哨动效。
shadcn/ui 的优势是干净、可控、容易改。它不是一个黑盒组件库，而是把组件代码放进项目里。后面我想改按钮、表格、弹窗、菜单，都可以直接改。
这对 AI 开发也很友好。因为组件就在本地代码里，AI 可以读到，可以改到，可以按我们的项目规范继续扩展。
为什么部署选 Cloudflare？
这个项目我一开始就希望能在线演示。
如果只是本地跑，学员看不到，客户看不到，后续写博客和做课程也少了一个真实入口。后台系统最有说服力的地方，不是截图，而是我能直接丢一个地址给你，你打开就能试。
Cloudflare 的优势在这里很明显：
- 前端可以放在 Cloudflare Pages
- 轻量 API 可以放在 Workers
- 后续数据库可以接 D1
- 需要国际访问时速度和稳定性都不错
- 对前端项目的部署体验比较顺
这次第一阶段，我不会一上来就把后端做得很重。图书管理系统可以先用 Mock 数据把业务流程跑通，然后再逐步替换成真实 API。
这也是我比较喜欢的开发节奏：先让系统能演示，再让系统能保存数据，最后再让系统能商用。
为什么不一开始就用 Django 或 FastAPI？
Django 和 FastAPI 都很好，我也会用。但在这个项目的第一阶段，我不想让后端框架成为负担。
图书管理系统早期最重要的是业务建模和前端体验：
- 图书信息怎么录入
- ISBN 怎么展示
- 借阅状态怎么流转
- 逾期提醒怎么呈现
- 读者借阅额度怎么管理
- 库存统计怎么做
这些东西没想清楚之前，后端技术越重，反而越容易分散注意力。
如果后面要做真实商用版，我会再考虑两条路线：
第一条是 Cloudflare Workers + D1 + Drizzle，适合轻量在线演示和小型 SaaS。
第二条是 FastAPI 或 Django + PostgreSQL，适合更完整的私有化部署和企业交付。
但启动阶段，我会先把前端和业务流程打磨出来。
第一版准备做哪些模块？
第一版我会先做六个核心模块。
第一个是仪表盘。它要展示图书总数、在库数量、借出数量、逾期数量、近期借阅趋势和热门图书。
第二个是图书管理。这里要支持书名、作者、ISBN、分类、出版社、库存、位置、状态这些字段。
第三个是读者管理。读者可以是学生、教师、会员，也可以是普通用户。每个读者应该有借阅额度和当前状态。
第四个是借阅管理。借书、还书、续借、逾期，这是图书系统最核心的流程。
第五个是分类和馆藏位置。很多图书系统看起来简单，但分类和位置一乱，管理员实际用起来就很痛苦。
第六个是系统设置。比如借阅天数、最大借阅本数、逾期规则、提醒策略等。
这些模块做完之后，这个项目才算有了一个真正的业务骨架。
AI 开发这类系统，关键不在提示词
很多人一听 AI 开发，就以为关键是写一个万能提示词。
我现在越来越觉得，关键不是提示词，而是项目管理方式。
比如这次项目，我会先把目录、博客规范、技术选型、部署方向定下来。然后每次让 AI 做一个明确的小任务：今天只做图书表格，明天只做借阅流程，后天只补截图和部署。
这样 AI 才不容易发散。
我在直播间讲课也是这个思路。不要一上来就让学员"做一个完整系统"，那样太大了。要把系统拆成一节一节能完成、能验证、能复盘的小任务。
这篇文章的结论
RuyiLibraryAdmin 这次我会按纯自研路线推进。
第一阶段先做前端业务 Mock，把图书管理、读者管理、借阅管理、统计看板这些流程跑通。
第二阶段接 Cloudflare Pages，让项目可以在线演示。
第三阶段再考虑 Workers、D1、Drizzle，把 Mock 数据替换成真实数据。
如果未来要做更重的商业交付，再升级到 FastAPI 或 Django 后端。
对我来说，这不是单纯做一个图书管理系统，而是做一个适合 AI 开发教学、适合项目实战课、也适合后续商品化包装的长期项目。
这就是我为什么在第一天先选技术栈，而不是急着写页面。