一个人，没融资，没团队，把AI拆成两半塞进手机。本地20毫秒配色，云端8秒理解图片。印度程序员Siddharth Jha做了个 wardrobe app，Google Play已上线。
这事听起来像标准独立开发者叙事，直到你看他的技术选型：Flutter做壳，Rust写核心算法，边缘函数调多模态模型。三种语言，两个大脑，一个目标——让用户在断网地铁里也能搭出能看的衣服。
「满柜子衣服，没一件能穿」
Jha的启动点极其朴素。他自己每天早上对着衣柜发呆，查数据发现普通人常规使用的衣物只占20%，剩下80%是沉默资产。
他没有时尚背景，但「帮我组合已有衣服」这事，他觉得代码能解决。至于自己是不是对的人，「仍是开放问题」。
这个自我怀疑反而救了项目。因为没预设自己是专家，他花了大量时间观察真实用户的反馈循环——不是问卷，是看人怎么用手指戳屏幕。
关键发现：翻穿搭建议时，50毫秒是生死线。超过这个阈值，「用户会觉得app坏了」。
但AI理解图片 inherently 慢。云端跑视觉模型，再快也要2-8秒。
矛盾摆在这儿：既要即时反馈，又要智能理解。Jha的解法是把AI劈成两半。
本地大脑：Rust写的20毫秒配色引擎
手机端负责所有「感觉」类计算。颜色分析、和谐度评分、单品兼容性判断——这些不需要理解「这是什么」，只需要快速算出「搭不搭」。
第一版用Dart写，死在性能上。颜色空间转换、 harmony check 双重循环，Dart isolate 加了复杂度却没解决CPU-bound的本质问题。
「编译型语言该干的事，别交给解释型语言。」
他重写为Rust，通过 flutter_rust_bridge 桥接。APK增重4MB，换来中端安卓机上20-30毫秒的评分速度。
算法本身迭代了三轮。CIE Delta E 能区分海军蓝和黑色，但在暗部光谱上，perceptual color difference 仍是难题。「人眼 effortless 的事，代码很挣扎。」
这4MB的Rust二进制，是用户体验的保险栓。地铁、电梯、偏远地区——只要app开着，配色建议随时可用。
云端大脑：按需调用的理解层
需要「看懂」的时候，照片被发往边缘函数。视觉模型识别品类、颜色、图案、材质；LLM根据 wardrobe + 天气 + 穿着历史生成建议。
这两个任务用不同模型，响应时间2-8秒不等。Jha的设计原则是：这些不是实时交互，用户拍照或请求建议时，天然预期有等待。
「云端的慢是feature，本地的快是requirement。」
双脑架构的副产品是离线可用性。这在印度不是nice-to-have，是生存必需。网络不稳定地区，核心功能不能瘫痪。
一个人的技术债
Jha坦承自己「做了大量不够资格的决定」。没架构师把关，没CTO拍板，每个技术选型都是独自押注。
Flutter + Rust + 边缘函数的组合，社区 precedent 有限。flutter_rust_bridge 的坑、多平台颜色一致性、模型调用的成本曲线——全靠自己踩。
但他有个优势：决策链短。发现Dart不够快，第二天开始学Rust。评分算法第三轮重写，因为前两轮在真实衣物上翻车。
「海军蓝和黑色的区分」这个具体痛点，驱动了技术迭代。不是先选Rust再找场景，是场景逼出了Rust。
Outfii 现已上线Google Play，Jha的下一步是观察用户怎么「驯化」这个双脑系统——哪些搭配被采纳，哪些被无视，离线模式和在线模式的使用比例如何分化。
他留下一个问题：当AI应用必须同时满足「即时」和「智能」两个矛盾需求时，把模型拆成本地+云端是不是默认答案？还是只是独立开发者的权宜之计？
热门跟贴