水族物种拍照识别 APP（自研产品）

客户是谁

橙智合自有产品。这是橙智合自研的一款产品，不是受委托的建设项目，全篇不使用委托方口径。

遇到什么问题

观赏鱼知识的公开资料分散、命名混乱：同一鱼种往往同时存在俗名、地方名、商品名与学名，还要在界门纲目科属种的分类树上各归其位。爱好者拍到不认识的鱼难以查证，发布的内容也难以稳定挂到正确词条下；平台侧还要同时处理图文内容审核、高频互动统计与多端一致体验。目标不是再做一个只读图鉴，而是把查证、识别、发布、互动与沉淀回百科做成一条可运营的链路。

我们做了什么

产品的底座是以水族物种百科为基础，把拍照识别、图文社区与运营后台接进同一条数据链路，让百科、识别与社区共用一套数据口径。

• 先底座后识别：先把分类树与词条模型定下来，学名精确匹配为主、别名检索兜底，词条携带参数化属性与图集，同一份数据供各端共用。识别链路再接在这套底座之上——没有可靠的词条体系，识别结果就没有归档去处。
• 识别做成事件驱动的异步链路：上传后由服务端并发调用外部大模型视觉识别服务，按学名投票取胜出者，命中词条自动归档；未命中时按策略生成待审草稿，流程停在校准环节而不是卡死在“识别中”。
• 失败治理三级递进：单次调用带超时预算，失败走指数退避重试，外部服务故障期由断路器降级停调用，保留待识别状态以便恢复后重放。
• 内容与互动链路：图文发布可带位置信息，先机审再人工复核，通过后进入信息流与频道分发；评论、回复、点赞、收藏、关注构成互动链路，热度分由计数聚合、内容质量因子与时间衰减共同计算，用于排序与榜单，优质内容再回流词条图集。
• 数据侧：独立采集服务把公开资料按分类、栖息环境、生活史、保护级别与图片等字段整理入库，作为词条底稿与后台编辑的输入，来源与版权口径逐项确认后再进入正式词条。
• 运营后台基于成熟开源底座自研业务页面，覆盖词条编辑、审核工作台、频道策略、资源位与首页看板。

难点怎么解决的

• 识别要能出错而不能出错就卡住：按学名投票取胜出者，未命中生成待审草稿；允许识别出错，靠投票、草稿与人工编辑兜底，不做夸大识别效果的表述。
• 外部模型服务不稳定：超时预算、指数退避重试与断路器降级三级递进，保留待识别状态以便恢复后重放。
• 高频互动计数扛不住：互动行为经事件总线异步落库，高频计数走多槽位分片写入、低频指标单槽位，查询时按指标类型实时聚合，避开热点计数行的锁竞争。
• 多端一致：对外口径统一为按同一套接口与字段口径支持多端，字段命名以后端定义为准，数字格式化只在展示层处理。
• 内容合规：图文与评论先经第三方内容安全服务机审，再由运营人工复核，处置过程与状态可追溯，并保留用户投诉与申诉入口。

交付了什么

交付的是一套已完成实现的平台：后端是 Go 与 Fiber 的模块化单体，按业务域分模块，统一走接口层、服务层与实体层分层；点赞、评论、回复、提及、收藏、关注、私信等多类事件由统一订阅器生成站内信，移动端经服务端推送通道实时接收。端上要区分确证与推断：小程序是主要确证端；APP、H5 与其他小程序平台目前只有同一套跨端工程的构建脚本与依赖证据，未逐端确认发布状态；PC 站以服务端渲染承接词条与文章，配套站点地图与抓取规则。

能力范围按“当前已实现”与“当前未包含或尚未确认”两个口径整理，依据是代码仓库、设计文档与开发规约的现状：对话式问答等生成交互功能的入口现为占位，未纳入当前提供的能力；小程序之外的端仅有跨端构建工程证据，未逐端确认；外部大模型服务的供应商、模型型号、服务地址、用量与成本不在公开口径；百科来源授权与署名口径仍在逐项核对；本页不声称任何认证、测评或资质结论；运营数据与识别准确率等效果指标不对外发布。

现在的状态

本页描述的是已完成的产品实现与工程能力，当前运营与在架状态不对外确认。数据治理按“平台具备的能力与设计原则”表述：个人信息采集限于账号功能所需，昵称、签名等资料进入审核与保护范围；敏感字段做确定性加密并支持密钥轮换，展示与日志侧统一脱敏。本页不据此声称任何合规资质或测评结论。