微拍堂：海外业务平台

一、项目定性

这条线不要讲成“海外硬币识别项目”。

更准确、也更有竞争力的讲法是：

这是一个面向海外用户的垂直产品后端系统，AI 识别只是其中一层，完整链路覆盖识别、收藏、真人鉴定、订阅、支付、退款、交易、归因、SEO、报表和后台运营支撑。

这条线最能代表你的能力边界：

复杂业务系统
多第三方平台对接
交易 / 订阅 / 退款状态治理
AI 能力接入真实产品
后端组长视角下的方案落地和治理

二、你在这条线里可以如实表述的角色

可以如实表述为：

负责海外业务平台核心后端模块研发与维护
长期承担订阅、支付、退款、归因、后台和鉴定相关链路的方案与落地
负责需求拆解、技术方案推进、联调上线和线上问题处理
参与复杂业务文档梳理、AI 辅助研发和工作流建设

不要讲成“我一个人做了整个平台”，更合适的表达是：

我负责这条线里的核心模块和关键链路，尤其是订阅支付、归因报表、真人鉴定、导入和 AI 能力接入相关部分。

三、详细功能点清单

1. 识别链路

上传正反面图片
前端压缩和 CDN 上传
后端识别接口
机制币
古钱币
纸币
调用中台识别服务
识别结果处理
失败订单记录
价格信息补充
历史识别记录
识别行为统计

你可以强调

这不是简单调模型接口，而是识别能力和业务订单、价格、统计、收藏都联在一起
识别失败、置信度低、中台异常都要有完整兜底

2. 收藏与用户资产

识别记录转收藏
收藏列表、收藏详情
收藏合集 / 套币管理
收藏次数限制
收藏笔记
资产总额统计
价格趋势
收藏搜索
收藏数据导入 ES

你可以强调

免费用户与订阅用户的收藏限制不一样
收藏不只是列表功能，后面还会和趋势、资产、搜索联动

3. 真人鉴定

识别结果页发起真人鉴定
收藏详情页发起真人鉴定
Web 端鉴定入口
创建鉴定订单
鉴定图片 / 视频上传
鉴定师分配
订单状态流转
语音转文本
翻译
审核流转
免费赠送次数 / 消耗次数
专家鉴定与普通鉴定师区分

你可以强调

这是个典型的多阶段业务流，不是一次请求完成
有同步国内鉴定、翻译、审核、转单、打回等流程

4. 订阅与权益

首页弹窗
收藏次数不足弹窗
识别成功后 paywall
真人鉴定次数不足引导
iOS 订阅购买与恢复
Android 订阅购买与校验
Apple Receipt 验证
Google Purchase Token 验证
Apple / Google 回调
7 天试用、3 天试用、月订阅、周订阅
订阅成功后 Firebase 上报
赠送真人鉴定次数
权益配置下发

你可以强调

这条链路最难的是状态流转和回调治理
购买成功、恢复购买、退款、续订关闭、续订失败、登录同步这些场景都会影响权益

5. 支付与交易

交易商品发布
商品详情
下单
地址填写 / 补齐
创建支付订单
支付回调
发货
确认收货
退款
手续费计算
订单超时关闭

支付渠道

Stripe
PayPal
Apple Pay
Google Pay

你可以强调

你做的不是单一支付对接，而是整条支付到交易闭环
支付和订阅、鉴定、后台、报表都有联动

6. 报表与归因

Google Ads 数据拉取与报表
ASA 数据拉取、重试和归因
Google Ads 广告用户判断
H5 / 分享活动归因
TikTok 归因
网页归因
AppsFlyer 调研与接入方案
广告操作记录
日报、7 天、33 天多层级报表

你可以强调

你不是只接平台，而是把 H5、分享、下载、激活、广告用户识别串起来
报表不是简单导出，而是有重试、存储和后续归因判断

7. SEO / 搜索 / 数据能力

SEO 数据清理
币种 SEO 信息维护
SEO 数据缓存
ES 重建与导入
钱币搜索
批量导入国家匹配
Dify 工作流辅助国家匹配

8. 工具与 AI 配套

Excel / CSV 批量导入
导入文件安全校验
Dify 工作流搭建与部署
ChatGPT / OpenAI OAuth
Google 登录 / Apple 登录
Firebase 上报
Push 推送
AdMob 数据获取
语音转文本工作流
网站数据抓取
Apify / BrightData / PCGS / NGC 数据接入

你可以强调

这条线里你不只是做业务接口，也做工具、数据和 AI 工作流支撑

四、技术方案与为什么这么选

PHP

这条线主逻辑放 PHP 很合理，因为：

业务规则复杂
需求变化快
和产品、运营、客户端协作密集
订阅、支付、鉴定、报表、后台这些逻辑联动多

适合讲法：

这条线主要是复杂业务落地，所以我更倾向用 PHP 承接核心业务规则，把交付效率和可维护性放在第一位。

Go

Go 在这条线不是主业务承接层，但可以作为：

工具型服务
批量任务
高并发或较重链路的拆分方向

如果被问到，你可以说：

这条线我主战场还是 PHP，因为业务规则复杂；Go 更适合放在独立工具和实时处理上。

MySQL

承接：

识别订单
收藏
订阅交易
支付交易
真人鉴定订单
商品与交易

原因：

状态清晰
事务强
需要可追溯

Redis

承接：

缓存
分布式锁
订阅 / 支付 / 订单幂等
SEO 数据缓存
热点数据缓存

Elasticsearch

承接：

收藏搜索
钱币搜索
数据导入与重建

Dify / OpenAI / Firebase / Push

分别解决：

AI 工作流编排
授权能力 / 外部能力接入
归因与事件上报
通知与消息触达

五、最值得讲的难点与解决方案

1. 订阅 / 支付 / 退款状态一致性

难点

Apple / Google 回调不是绝对按你希望的顺序来
恢复订阅、退款、续订失败、登录同步都会影响用户权益
业务上还叠加了真人鉴定次数、收藏次数、价格趋势等权益

可讲方案

先统一状态模型
购买、恢复、回调、退款走不同入口，但落到统一状态处理
回调侧做幂等控制
关键状态变化入库并保留日志
需要同步任务和补偿任务兜住极端场景

面试中能体现什么

你会做状态机
你重视幂等和补偿
你不是只把支付接口调通

2. 识别链路耗时和稳定性

难点

图片上传、压缩、CDN、识别、中台返回、价格补充是一条长链路
中台异常、识别失败、低置信度都要给用户合理结果

可讲方案

对上传和识别节点做拆分
失败订单单独记录
识别结果和价格信息分阶段补齐
通过缓存、CDN 和链路拆分减少重复处理
做识别成功率、耗时、行为统计

面试中能体现什么

你有链路化思维
你知道怎么做用户可见结果和后台统计

3. 真人鉴定是典型多阶段流程

难点

不是一个同步接口结束
有订单、上传、指派、语音转文本、翻译、审核
多角色协同多

可讲方案

按阶段拆订单状态
定时任务处理语音转文本与翻译
鉴定师和订单关系表分离
关键节点日志和状态变化清晰化

面试中能体现什么

你能处理多角色、多步骤业务
你会拆同步与异步边界

4. 归因与广告链路的完整性

难点

Google Ads、ASA、TikTok、分享、网页的链路不一样
下载、激活、广告用户识别、报表落地要统一

可讲方案

分别处理原始上报、用户来源记录和激活归因
ASA 增加重试队列和日志
区分 Google Ads 用户与 ASA 用户来源表
报表侧做按周期、按层级输出

面试中能体现什么

你不只是懂业务，还懂增长链路技术落地

六、这条项目最能展示你的标签

复杂业务后端
后端组长 / 核心方案角色
订阅支付与权益治理
AI 能力接入业务系统
多第三方接入
增长、归因、报表
文档化、AI 辅助研发、工作流沉淀

七、面试里怎么定性最稳

一句话版

这是一个海外垂直产品的后端系统，AI 识别只是其中一层，真正复杂的是把订阅、支付、退款、真人鉴定、归因、报表和后台运营能力做成一个完整闭环。

两分钟版提纲

这不是单点识别项目，而是完整产品系统
你负责订阅支付、归因报表、真人鉴定、导入和 AI 工作流相关核心模块
技术上是 PHP 为主，MySQL / Redis / ES / 第三方平台协同
最难的是状态一致性、长链路和多平台归因
你通过状态模型、幂等、补偿和链路治理把它做稳

八、如实表达时的边界

你可以放心讲深，但不要讲成：

我一个人做了整个海外平台
我是纯 AI 平台架构师
我训练了模型

更适合的表达：

我负责的是这条线里的核心模块和关键链路
我强项是把 AI 能力、交易链路和增长归因接进真实业务系统
我的经验更偏业务架构和落地架构