水产养殖企业的鱼类识别服务：视觉大模型封装与多端复用

客户是谁

一家水产养殖方向的企业（以行业别名表述）。围绕鱼类识别能力，产品同时覆盖多个使用端：Web 站、小程序、PC 站与运营后台，并服务观赏鱼爱好者社区的百科与识别场景。

遇到什么问题

鱼类照片的识别能力如果分散在各个端，就会出现重复建设、字段口径不一、模型一换全端要改的局面。

客户要的不是某一个端里的一次性识别功能，而是一个独立的识别服务：统一接入、统一返回口径，识别结果能落到标准名，供百科词条归档与多端复用。

我们做了什么

把视觉大模型的图片分析能力封装成统一的鱼类识别 REST 服务：上传鱼类照片 → 视觉大模型分析 → 提取标准名 → 返回结构化识别结果。

• 服务端统一封装。识别服务独立实现，与各端解耦；端上不直接依赖具体模型，底层模型升级或替换时各端代码不动。
• 生产环境部署。服务已部署到生产环境，接口文档载明生产部署地址，可作为服务化交付的核验依据。
• 多端复用。Web、小程序、PC、运营后台与 bot 等多端通过同一份 API 文档接入，共用这一套识别服务，各端不重复封装。
• 结果落标准名。识别输出以标准名为出口，对接百科词条体系，便于归档与检索。

难点怎么解决的

• 识别要能出错而不卡业务：识别结果以标准名为出口，靠词条体系与业务侧流程兜底；不做夸大识别效果的表述，效果指标不对外发布。
  – 模型能力与业务解耦：识别服务独立成服务端工程，视觉大模型只是其中的分析环节——替换或升级模型不影响各端接入方式。
  – 多端一致性：一份 API 文档、一套字段口径，多端按同一契约接入，避免每端各写一套。

交付了什么

交付的是一套已完成部署的识别服务与配套工程：鱼类识别 API（含接口文档，文档载明生产部署 URL）；百科数据链路与多端前端工程（Web、小程序、PC、运营后台、bot 各自独立的工程仓库）；接口契约与字段口径说明。交付边界按代码仓库与接口文档的现状整理。

现在的状态

识别服务已在生产环境部署运行（API 文档载明生产 URL），并持续支撑多端调用。各 C 端产品的运营与在架状态不作公开确认；识别准确率等效果指标不对外发布；底层模型供应商与调用成本不在公开口径。