刚开始学AI的时候，我的注意力几乎全放在模型本身上。

用哪个算法？怎么提高准确率？数据怎么预处理？模型预测效果如何？这些问题占据了我全部的思考。

打开网易新闻 查看精彩图片

这些问题当然重要。但随着我开始构建更完整的应用，一个更关键的事实逐渐清晰：一个好模型，只是有用AI系统的一部分。

模型不等于产品

笔记本里的机器学习模型，和真正跑起来的系统，完全是两回事。

一旦要面对真实用户，API、存储、结构、集成这些词就全冒出来了。问题不再只是"预测准不准"，而是：数据怎么进入系统？前端怎么和后端通信？应用数据存在哪里？后端怎么组织？项目变大之后怎么保持可维护？

正是在这些环节上，FastAPI开始对我变得意义重大。

CORS：一个被低估的生产问题

CORS看起来是个不起眼的技术细节，但它代表了一个真实的生产环境问题。

前端和后端往往跑在不同的源（origin）上，浏览器会强制规定它们之间的通信规则。这意味着，光有能跑的模型远远不够——周边的系统也必须正确配置。

这件事让我意识到：部署和集成，和模型逻辑本身一样重要。

SQL数据库：AI应用也是软件系统

关系型数据库是另一个重要关卡。

在简单demo里，忽略持久化很容易。但真实应用需要存的东西太多了：用户、请求、结果、元数据、应用状态、日志记录……

在FastAPI里操作SQL，让我更认真地思考AI应用作为真实软件系统该怎么运转。模型负责产出智能，但应用本身仍然需要扎实的数据管理。

更大的应用：结构决定生死

"Bigger Applications"模块尤其有用，因为它聚焦在结构上。

小应用可以塞进一个文件里，大应用不行。随着项目膨胀，清晰的分离变得至关重要：路由（routers）、依赖（dependencies）、模块（modules）、可复用组件、可维护的组织方式。

这是最直白的提醒：AI工程不只是关于模型，更是关于构建一个长期可理解、可使用的软件。

我的思维正在转变

我依然热爱机器学习和计算机视觉，那仍然是我方向的核心。

但我越来越想跳出"数据集→模型→准确率"这条窄线，转向更完整的链路：问题→数据→模型→API→数据库→应用→真实使用。

这个更宽的视角，更接近我想成为的那种工程师——不是只会训练模型的人，而是能把AI变成完整可用系统的人。