我为什么研究FastGPT：RuyiBookCourse要不要直接做成AI应用平台
OK，OK，大家好，欢迎大家来到大鹏 AI 教育，我是张大鹏。
这篇文章讲FastGPT。
我研究它，不是因为我想马上把RuyiBookCourse迁移到一个外部平台。
我真正想弄清楚的是另一个问题：
RuyiBookCourse 到底应该先做底层能力，还是直接做成 AI 应用平台？FastGPT 对我有参考价值，是因为它不是普通知识库。
它更像一个 AI Agent 应用搭建平台。
FastGPT是什么
FastGPT 官方介绍里，它是一个 AI Agent building platform。
它提供的是一整套应用搭建能力，而不是单纯的文档检索。
从公开文档和仓库来看，它的重点包括：
- 知识库问答
- 数据处理
- 模型调用
- 可视化工作流编排
- Agent 能力
- 工具调用
- API 集成
所以如果只把 FastGPT 理解成“上传文档，然后问答”，就低估它了。
它真正吸引人的地方，是把知识库、流程编排和应用发布放在一起。
这对很多团队非常有用。
因为团队想要的往往不是一个检索模块，而是一个可以交付给用户使用的 AI 应用。
它为什么会让我警惕
FastGPT 让我看到了一条很诱人的路线：
把 RuyiBookCourse 直接做成 AI 应用。比如我可以想象一个页面：
- 上传一本电子书
- 自动解析章节
- 自动生成课程大纲
- 自动生成讲义
- 自动生成练习
- 支持用户问答
- 支持工作流编排
这当然很吸引人。
但我现在不会马上这么做。
原因很简单：平台化会放大底层问题。
如果解析不稳定，平台只会让错误更快地暴露。
如果课程结构不清晰，工作流只会生成更多不稳定内容。
如果 RAG chunk 规则没有设计好，问答页面再漂亮也不可靠。
所以 FastGPT 对我的启发，不是“赶紧上平台”。
它让我更清楚地区分：
底层能力和：
应用编排这两件事不能混在一起。
FastGPT适合什么场景
如果一个团队已经有相对清晰的数据源、知识库结构和业务流程，FastGPT 会很有价值。
比如：
- 企业客服问答
- 内部知识助手
- 销售资料助手
- 运营流程自动化
- 多步骤 AI 工作流
- 对外提供 API 的 AI 应用
这些场景的共同点是：用户要的不是底层解析器，而是一个能用的应用。
FastGPT 的可视化流程和应用编排能力，就适合解决这类问题。
RuyiBookCourse现在适合直接上FastGPT吗
我的判断是：现在还不适合。
不是 FastGPT 不好。
而是RuyiBookCourse当前阶段的核心矛盾还在底层。
我现在更应该先解决：
- EPUB/PDF 解析质量
- 章节结构识别
- 课程输出规范
- Markdown 清洗
- RAG 索引和引用来源
- 本地 CLI 工作流
这些事情做好以后，FastGPT 才可能成为应用层选择。
如果反过来，先用 FastGPT 包一层应用，底层解析还很乱，最终会变成“看起来智能，实际上不稳定”。
这不是我想要的产品。
我会怎么借鉴FastGPT
我不会照搬 FastGPT。
但我会借鉴它的几个方向。
第一，知识库不是终点，应用才是用户看到的结果。
RuyiBookCourse后面不能只停留在“能查资料”，还要能生成课程、讲义、练习和学习计划。
第二，流程编排很重要。
电子书转课程不是一个单步任务。
它至少包括：
解析 -> 清洗 -> 分章 -> 摘要 -> 课程大纲 -> 讲义 -> 练习 -> 问答这些步骤以后都应该可以组合。
第三，工具调用很重要。
AI 不能只聊天，它应该能调用本地命令，检查文件，验证输出，更新课程资料。
这正是RuyiBookCourse要往 AI 原生项目演进的方向。
我的结论
FastGPT 让我看到应用层的可能性。
但我现在不会急着把RuyiBookCourse做成平台。
我会先把本地产品能力做扎实：
电子书解析稳定 课程输出稳定 RAG 查询稳定 博客和课程生成稳定等这些底层能力稳定以后，再考虑是否接入 FastGPT，或者自己做一个更贴合电子书转课程的应用层。
对我来说，FastGPT 不是现在的答案。
但它是一个很好的参照物。
它提醒我：RuyiBookCourse最终不能只是工具，它应该成为一个能交付学习成果的 AI 应用。
参考资料
- FastGPT 官方文档：https://doc.fastgpt.io/en/guide/getting-started
- FastGPT GitHub：https://github.com/labring/FastGPT
- FastGPT License：https://github.com/labring/FastGPT/blob/main/LICENSE