所有人都知道Google Photos好用，但很少有人认真想过：为什么找一张白板照片要交给硅谷的服务器？

一名印度学生在课程作业里做了件反常识的事——用Flutter和AWS Rekognition搭了一套完全可控的智能相册。没有厂商锁定，没有黑箱算法，连后端都能塞进旧手机运行。

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

从React Native"被迫"转向Flutter

开发者原本想写React Native。但课程因师资问题统一指定了Flutter 3.x，带Material 3设计。

这个"被迫"的选择反而成了简历加分项：单一代码库覆盖Android、Web、Linux三端，比玩具项目硬得多。

前端定了，后端选Django REST框架配SimpleJWT。REST API要干净，认证授权走JWT——经典组合，但求稳。

为什么不用自研模型

AI部分是最关键的决策点。人脸识别、人脸聚类、OCR全交给Amazon Rekognition，而非自己训模型。

理由很实际：不想跳ML模型的坑，且便宜。重计算扔到AWS，本地只付几美分。

SDK走Boto3库，Django上传视图里同步调AWS。这里有个反直觉的设计——同步而非异步，因为整个流程要在单次HTTP请求里跑完。

最激进的架构选择：即时处理

PhotoSense的核心体验是"上传即处理"。POST /api/photos/upload/这一个端点，同时触发三条流水线：

文件读进内存字节流，一分为三：S3存原图，两个Rekognition服务分别做人脸和文字识别。

这种"单请求串并行"的设计牺牲了部分吞吐量，换来了用户体验的极简——用户不需要刷新等状态，上传完就能看到分类结果。

更隐蔽的好处是后端极轻。真正的计算在AWS，自建服务器只跑数据库和路由。开发者实测：硬件要求低到"现代手机装Termux就能跑"。

控制感作为产品定义

整个项目的出发点是对Google Photos的四个不满：厂商锁定、隐私黑箱、处理流程不透明、平台功能不可控。

PhotoSense的回应不是功能更多，而是"可解释"——每个识别步骤都能说清逻辑，每个模型调用都能开关。

这对25-40岁科技从业者有特殊吸引力：我们习惯了云服务便利，却越来越难以忍受"方便但失控"的交易。

这件事为什么重要

PhotoSense是个课程作业，但它戳中了一个真实趋势——边缘AI基础设施成熟后，"个人可控的智能服务"成本正在断崖式下跌。

AWS Rekognition按调用计费，Flutter跨端无额外成本，Django后端轻到能塞进旧手机。技术栈全部现成，唯一需要的是整合意愿。

如果你也在找"能写进简历、又能解决真问题"的 side project，这个组合值得抄作业：Flutter跨端打底，托管AI服务扛计算，自建后端保控制。三端代码一份，重活云上付费，轻活本地可控——这可能是个人开发者对抗平台锁定的最优解之一。