React图书管理系统，为什么我选择Cloudflare？

OKOK大家好欢迎大家来到大鹏 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 或 FastAPIDjango 和 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 开发教学、适合项目实战课、也适合后续商品化包装的长期项目。这就是我为什么在第一天先选技术栈而不是急着写页面。