---

一、项目思考：为什么衣橱项目要接入大模型？

之前做智能衣橱，我最开始用的是固定标签匹配：上衣配裤子、纯色配简约，全是写死的规则。

但实际开发中发现问题特别明显：

• 搭配非常死板，完全没有个性化

• 新增衣物、新风格就要改代码，扩展性极差

• 无法根据季节、场景、风格灵活给出穿搭建议

所以接入 SophNet大模型API，用AI生成式能力替代传统硬编码规则是必不可少的。本质就是：把固定规则判断，交给大模型智能推理，让穿搭建议更灵活、更贴合真实场景。

但移动端直接接大模型，真的不是简单调个接口就完事，里面藏了很多新手容易忽略的工程问题。

---

二、核心架构抉择：两种接入方式，为什么只能选中转？

对接SophNet大模型，我一开始也纠结两种方案，后来彻底想明白了：前端直连只能用来临时测试，真正落地必须后端中转。

2.1 不推荐前端直连的真实原因（不止是密钥泄露）

很多新手图省事，直接在Android端写死SophNet的Key和接口地址，本地跑确实很快，但隐患巨多：

• 密钥完全裸奔：APK反编译就能直接看到明文Key，一旦泄露，别人可以随便盗刷你的SophNet额度

• 极易触发平台风控：SophNet有严格的风控机制，会校验IP、请求频率。手机IP是动态的，用户多了会直接封禁Key

• 完全无法管控流量：前端请求散乱，没法限流、没法缓存、没法排查异常请求，线上一旦出问题完全抓瞎

简单说：前端直连=裸奔上线，只能做Demo，绝对不能用于正式项目。

2.2 后端中转架构的核心优势

关于采用 Android客户端 + SpringBoot中转 + SophNet大模型 的标准架构的核心价值，我总结了4个关键，也是企业级项目通用思路：

• 安全收口：把密钥、鉴权逻辑全部藏在后端，前端零敏感信息，从根源避免被盗刷

• 适配平台风控：后端固定公网IP，配置SophNet白名单，彻底解决移动端IP乱跳被拦截的问题

• 流量可控：后端统一收口所有AI请求，可以做缓存、限流、重试、日志记录，线上问题可追溯

• 业务解耦：前端不用管SophNet的接口规则、返回格式，后期换模型、换接口，前端代码完全不用动

---

三、吃透SophNet平台核心机

想要稳定对接SophNet，不能只会复制请求代码，必须懂它的底层运行规则，这是减少报错的关键。

3.1 鉴权机制

SophNet采用标准的 Bearer Token 鉴权方式，请求头格式错一个空格、大小写不对、Key不匹配，直接401鉴权失败。

它的鉴权逻辑是：Key绑定项目、绑定模型权限，不是通用密钥，错一个参数就直接拦截，不会给任何模糊提示。

3.2 限流与额度机制

SophNet对测试账号、免费额度用户管控很严格：有QPS限制、有总额度限制。

短时间频繁调用就会429限流，额度耗尽直接静默失败，这也是很多人“时好时坏”的根本原因。

3.3 接口交互机制

统一POST+JSON格式，参数不规范、字段缺失都会导致模型不返回内容，或者返回乱结构。

---

四、进阶知识点：Prompt工程决定AI效果上限

对接大模型久了我发现一个真理：代码只是基础，Prompt才是效果核心。

如果直接空请求大模型，返回的内容又长又啰嗦，全是客套话，完全不适合移动端展示。

所以我针对穿搭业务，做了专属的约束设计：

• 固定AI角色为专业穿搭设计师，避免闲聊式回答

• 强制限制字数，适配移动端卡片展示

• 禁止多余解释、客套话，只输出核心穿搭方案

• 传入结构化衣物数据（分类、标签、季节、风格），让AI推理更精准

同时在后端做了结果清洗层，自动过滤换行、空格、乱符号，保证前端UI展示统一干净。

---

五、代码层设计思

我前后端代码的编写思路，全程围绕「安全、解耦、稳定」三个点。

5.1 移动端思路

客户端完全不碰任何SophNet密钥和接口细节，只负责传递纯业务结构化数据。通过协程异步请求，避免主线程阻塞，保证APP交互流畅，符合Android开发规范。

5.2 服务端思路

后端是整个AI能力的核心中转站，主要做三件事：

• 统一管理SophNet密钥、接口地址，方便多环境切换

• 组装规范Prompt、调用平台标准接口

• 清洗、统一AI返回结果，对外暴露简洁稳定的业务接口

---

六、本篇技术总结

做完这一整套SophNet接入，我最大的收获不是“实现了AI穿搭功能”，而是理清了移动端AI功能的工程落地思维：

• 大模型接入绝不只是调接口，安全、风控、流量、适配都要考虑

• 架构选择优先考虑线上稳定性，而不是开发方便

• Prompt工程是AI项目差异化的关键，直接决定最终展示效果

• 代码要解耦、收口，才能让项目可维护、可迭代、可上线