Full-stack Product · 2025–2026
Ovanta
跨区域签证、移民与海外身份自助申请平台。
面向中国及国际用户的签证、移民与海外身份自助申请平台，一套核心代码支撑国内版与国际版，覆盖结构化内容、区域化登录支付与会员权益，已上线 ovanta.cn。
业务问题与个人职责
业务问题：把分散、专业且持续变化的官方政策组织为可审核、可组合的结构化指南，并通过订阅、支付与权益完成商业化交付。我主导内容模型、区域化与支付幂等设计。
系统链路
- 政策内容
- 结构化建模
- 资格评估
- 订阅支付
- 权益发放
- 顾问服务
- 运营回流
工程重点
- Content System
- 16 类内容模型与类型化组件，支撑多产品、200+ 页面统一编辑与发布。
- Payment Hook Chain
- 支付回调走阻断型 Hook 链：验签、金额、状态机与幂等校验——写侧阻断、读侧降级。
- Regional Architecture
- 国内/国际共享核心业务代码，构建期区域配置 + 渠道适配器，区域重复开发大幅下降。
可验证证据
- Content Models
- 16 模型 · 25 组件 · 200+ 页面
- Entitlements
- 对账一致率 99.9%+ · 千次级回放零重复发放
- Events API
- P95 < 100ms · 重复率 < 0.1%
- E2E
- Given-When-Then 通过率 ≥ 98%
React · Vite · Django · DRF · Strapi · MySQL · PostgreSQL · Redis · Celery · Docker Compose · Cloudflare
设计取舍
-
把政策做成结构化内容模型，而不是富文本长文
- 为什么
- 一篇富文本很难知道哪项材料已经过期、当前评估依据的是哪个版本，也无法稳定控制会员可见章节。
- 代价
- Strapi/PostgreSQL 与 Django/MySQL 之间形成跨系统边界，内容模型每扩展一次都要同步改两侧。
-
国内版与国际版共享核心业务代码，差异收敛到构建期配置
- 为什么
- 两套代码会立刻分叉，而订单、支付、权益恰恰是最需要保持一致的部分——一旦分叉就再也收敛不回来。
- 代价
- 区域差异被压进配置与适配器，运行时的分支判断变多；区域特有的产品需求要先评估是否值得进主干。
-
支付回调走阻断型 Hook 链：验签、金额、状态机、幂等逐层校验
- 为什么
- 支付回调天然会重复、乱序、延迟到达，任何一步校验缺失都会直接变成多发或少发权益。
- 代价
- 回调链路变长，异常路径要单独设计降级与人工介入；对账从此是一项必须长期运行的独立能力。
-
权限以服务端校验为准，前端展示状态不作为依据
- 为什么
- 前端隐藏一个入口不等于用户没有权限——把展示当授权，等于把权限边界交给浏览器。
- 代价
- 每个需要展示态的功能都要服务端再查一次权限，接口数量和往返次数增加。
系统不负责清单
刻意划出的非目标。写下来的边界才是能守住的边界。
- 不代替政府部门受理或审批申请
- 不保证签证、移民、永久居民或开户结果
- 不在缺乏依据时自动作出专业法律判断
- 不替代顾问完成必须由人工判断和把关的工作
- 不自动从非权威来源生成并直接发布政策内容
- 不让 AI 直接修改内容、资格规则、价格、套餐和权益配置
- 不把运营数据的相关性自动解释为确定因果关系
- 不通过前端展示状态代替服务端的真实权限校验
- 不自行处理支付清算——资金仍由合规支付渠道完成
开放问题
目前还没有答案的部分。欢迎就其中任何一条追问。
- 内容模型的覆盖度取决于编辑对政策的拆解粒度，跨区域复用时「最小公共模型」还没有稳定答案
- 支付回调已按幂等键压到千次级回放零重复，但渠道侧对账文件的延迟到达仍需人工兜底
- 如何在「政策结论必须人工确认」这条线之内提高内容生产效率，目前只在运营侧做聚合解释，还谈不上自动化
- 区域化适配器把差异收敛进了配置，但新区域接入时本地支付渠道与合规要求仍需逐个评估