01 背景与问题
该客户提供以租赁为重点的 BNPL 产品：客户申请批准的消费限额，然后通过贷款支付符合条件的购买，并以分期付款方式偿还，而非全额付款。该产品仅涵盖家具、电视和消费电子产品等可租赁物品，不包括笔、笔记本和文具等低价值消耗品。客户通过将支付选项直接整合到每个零售商的网站中而实现增长：销售人员主动接触零售商，零售商提供沙盒，团队整合网关，工程和质量保证测试结账，然后双方协调生产发布。
这种模式在五到七家零售商中奏效，随着网络的增长而失效。零售商运行着不同的Shopify、Magento、BigCommerce和自定义平台组合，不同的结账方式、不同的支付处理商，以及不同的沙盒和发布流程，因此每一次集成都成为独立的永久实施和支持生命周期。任何零售商平台升级或结账更改都可能迫使客户重建集成、重新进行回归测试并安排新的联合发布。大约六个月后，该项目支持了大约15家零售商，员工人数为60至70人，计划在次年实现200+零售商：线性扩展意味着将有数百甚至接近一千人。真正的问题不在于发展能力。这种架构让每个新零售商都成为新的外部依赖，因此客户需要一个模型，使零售商的增长不再需要工程和支持的成比例增长。
02 角色与约束
AI Product Manager我负责端到端解决方案：产品战略、问题定义、客户旅程设计、AI用例定义、解决方案架构、零售商赋能战略、产品数据与标签需求、工程与AI/ML协调、API和后端需求、虚拟卡集成、移动和浏览器扩展体验、安全与合规协调、分析与模型性能要求、推广规划及利益相关者管理。其中最重要的呼吁之一是界定人工智能应在哪些领域应使用、哪些不应该使用：模型仅回答产品是否符合可租赁产品政策的资格。它没有确定信用状况、设定信用限额、身份验证身份、定义还款条款、进行社会安全号码验证或批准账户，这些都保留在客户现有的审批、身份和协议系统中。
这些限制是具体的。消除零售商端实施依赖：没有零售商需要添加支付方式、提供沙盒访问、更改结账、暴露自定义API、分配开发人员或联合QA。支持产品层面的资格，因为零售商可以同时销售可租赁和不可租赁商品，因此系统将单个购物车商品分类，而非整家零售商，并通过仅融资符合条件的部分来处理混合购物车。跨越不同零售商技术并管理DOM变更，因为扩展仍能读取零售商页面，页面更新可能会改变HTML结构、选择器、产品卡、价格和结账字段。保持可接受的分类准确率，通常为85%到90%，目标在90以上并逐步提升至95%。通过加密、令牌化、访问控制和审计日志保护客户信息（姓名、地址、手机号码、社会安全号码和OTP）。之后，支持实体零售，而无需集成到每家门店的销售点系统。
03 产品方法
我们没有组建更高效的零售商与整合团队，而是改变了整合地点。最初的模式将客户的融资能力置于零售商的结账处。重新设计的模式将融资体验置于客户控制的渠道内：电商的 Chrome 扩展和实体店的客户移动应用。这创造了一个共享的、商户无关的平台，在许多零售商之间运行，没有零售商为客户实施支付方式。
在线上， Chrome 分机识别零售商，告知客户融资，阅读购物车和总额，向后台发送产品详情，将每项商品分类为可租赁或不可租赁，排除不符合条件的商品，核对符合条件的金额与客户的限额，支持注册和核实，提交协议，生成一次性或有限使用的虚拟卡， 并自动填入了零售商的标准结账窗口。启用新零售商成为内部管理流程，而非六个月的双边整合：收集零售商的公开目录数据，根据客户政策给产品贴标签，培训或更新成千上万条记录的分类器，验证已知标签的准确性，配置产品名称、价格、数量、类别及购物车总量的DOM提取， 测试端到端流程，然后激活零售商，无需沙盒、结账更改或网关部署。
在门店中，我们将同样的功能扩展到了移动应用中。应用检测到顾客处于商店的地理围栏内;在计费柜台，顾客拍摄了明细账单; OCR 提取产品名称、数量和价格;这些行项被规范化并传递到相同的资格模型;该应用将符合条件和不符合条件的产品分开付款，因此不可租赁的产品可以单独支付;合格总额会与限额进行核对;客户接受了协议;为符合条件的金额生成了一张虚拟卡，并通过门店正常的卡片接受流程使用。如果客户在使用卡前离开地理围栏，卡会自动失效。地理围栏并不处理交易，而是作为后端改变卡生命周期状态的触发器。
客户似乎需要一个更大的集成团队。真正的问题是增长依赖于数百个外部零售商系统和发布时间表。将体验迁移到客户控制的扩展和移动应用中，虚拟卡片作为互操作层，改变了这种依赖关系：零售商的产品数据取代了自定义支付集成，每一项商品都独立决定。
4 个已制造的特色
支持零售商检测
该分机识别已启用的零售商网站，并告知客户融资支持。
基于DOM的卡车提取
零售商专用的DOM逻辑会从页面中提取产品和购物车信息。
人工智能产品的资格
每个购物车商品都根据共享模型被分类为可租赁或不可租赁。
混合车搬运
不符合条件的项目被排除在外，因此只有符合条件的部分可以分期付款。
延伸内注册
新客户无需离开购物旅程即可创建账户。
虚拟卡+结账自动填充
一次性或有限使用卡会生成并自动填充到零售商的结账处。
店内移动旅程
现有的客户端应用被扩展，用于资助符合条件的实体店购买。
商店地理围栏
该应用检测顾客是否进入了支持商店的配置区域。
账单捕获+ OCR
客户拍摄明细账单; OCR 从图片中提取行项。
收据归一化
OCR 输出被转换为结构化的产品、数量和价格记录。
符合条件/不符合条件的分配
应用会显示哪些可以分期付款，哪些需要单独计费或支付。
地势触发的失效
使用前离开店铺边界会触发自动卡牌过期。
还提供：批准限额验证、移动OTP验证、与客户现有身份系统的实时SSN验证、协议展示与验收（扩展内和应用内）、通过产品培训和DOM配置实现零售商可重复赋能、跨渠道重复使用的产品分类，以及单一全渠道后端用于资格认证、客户验证、协议、虚拟卡和分析。
05 建筑
两个客户渠道汇聚在一个后端。在线渠道是 Chrome 扩展加上零售商的DOM提取;店内渠道包括移动应用，加上账单摄影、 OCR 和地理围栏。两者都使用相同的核心服务，包括产品规范化、可租赁产品分类、客户身份和信用额度验证、协议生成、虚拟卡发行、卡生命周期管理以及分析和审计日志。 Python 后端会暴露 REST API;外部PCI DSS兼容卡提供商发行一次性或有限使用虚拟卡。
建筑风格改变了膨胀单位。过去每个零售商都需要商业协议、零售商技术资源、沙盒访问、支付集成、联合质量保证、协调发布和持续平台支持，而新的在线零售商现在主要要求产品数据准备、标签制作、模型培训或验证、DOM配置、结账测试和扩展激活。新实体零售商主要要求门店位置配置、产品数据覆盖、收据格式验证、 OCR 测试、资格测试和卡片接受验证。安全涵盖加密、令牌化、受限访问、审计日志、OTP验证、实时社会安全号码验证、受控协议执行、一次性或有限使用卡、位置触发到期以及PCI DSS合规提供商。可靠性是按表面监控的：在线DOM故障（缺少产品、无效选择器、自动填充失败）、 OCR 店内的变异性（光线差、模糊、折叠、缩写、税费和折扣线）、地理围栏限制（被拒绝权限、室内精度、GPS漂移、退出事件延迟、操作系统背景限制）以及虚拟卡结果（发行失败、提供者超时、激活、过期、授权）。权衡是明确的：零售商的独立性仍取决于零售商的DOM授权;POS 独立性取决于收据质量;一个共享模型涵盖两种截然不同的输入类型;位置控制受限于位置精度;外部卡提供商则降低基础设施负担，同时增加对供应商的依赖。
06 分析与可观测性
扩展后的平台需要针对在线结账、 OCR 性能、模型准确性、位置行为和支付结果进行单独测量，因为单一故障可能源自其中任何一个。 OCR 准确性和分类准确性分别测量：分类失败可能源于 OCR 文本错误、收据解析错误、产品上下文不足或模型真实错误。电子商务漏斗（零售商检测到→扩展→购物车提取出→分类→合格金额→验证→协议→卡→自动填充→购买）和店内漏斗（→门店检测到，输入地理围栏→账单→ OCR →清单→分类→非租赁、分开→符合条件的→协议→卡→付款或到期）都被端到端监控。支持风格也发生了变化：从零售商集成、沙盒和网关缺陷转向计费、协议、付款、 OCR 或账单阅读、DOM变更、位置权限和卡片授权问题。
在线零售商指标
零售商检测、购物车提取、DOM错误、自动填充和结账成功、批准转购买转换。
分类指标
按零售商、类别和渠道的准确性、虚假可租赁和不可租赁率，以及置信度分布。
OCR 指标
捕获与处理成功率、行线和价格提取、全面对账、重录和手动更正率。
地势度量
入侵检测、权限拒绝、退出事件、退出后卡片过期情况，以及从生成到付款的时间。
虚拟卡指标
请求成功、生成延迟、提供商错误、激活、授权结果和未使用卡率。
07 人工智能决策层
该模型回答了一个狭义且在两个渠道中一致的问题：该产品是否符合客户的可租赁产品政策？在线输入结合了产品名称、图片、类别、零售商上下文、描述（如有）、价格和数量，以及可租赁/不可租赁培训标签。店内输入包括 OCR提取的描述、收据条目文本、数量、价格、店铺上下文以及之前零售商的产品数据，这些数据通常远不如电商页面描述性强，因此产品规范化在店内流程中最为重要。该流程从DOM或收据中获取产品信息，规范化零售商特定文本，映射到已知类别，评估可租赁性，返回结果，计算合格总额，并记录模型结果和版本以便监控。训练使用结构化的电子表格数据（名称、图片、类别、零售商、标签），每个零售商或零售商集团包含数千个示例，采用监督式产品分类模型。报告准确率约为85%至90%，目标是超过90并逐步提升至95;这是客户的项目层级衡量标准，没有单独的精确度、召回、F1或独立审计评估。
AI只回答了产品资格。它从未确定信用状况，设定信用额度，验证身份，定义还款条款，执行社会安全号码验证或批准账户，这些都保留在客户现有系统中。已知的失败模式（不可租赁商品被评分为可租赁、可租赁商品错误拒绝、缩写收据行错误映射、捆绑或全新产品、零售商分类法变动或不良 OCR）指向推荐的下一步步骤：基于信心的决策，信心自动继续，中置信度应用确定性类别规则，要求客户低置信度重新捕获， 未解决时排除或引导复核。
08 现状与结果
Chrome延长在约四个月内支持了100+零售商，而原模型中15个零售商大约需要六个月，最终允许客户在300+在线零售商中使用融资产品，比15家零售商的基准增加了约20倍。新零售商不再需要技术资源、沙盒访问、网关集成、联合质量保证、零售商部署或协调发布;它可以通过内部控制的数据准备、标记、模型训练、DOM配置、检验测试和激活来实现。最初60至70人的团队基本保持不变，增加了大约四到五名人工智能/机器学习工程师负责数据准备、模型训练和精度工作，避免了旧模式所带来的比例人力增加。零售商集成工作、定制开发、沙盒工作、联合测试和平台特定支付维护被移除;客户报告说，随着更多地方接受批准的限额，结账交易量增加（以定性方式报告，未提供具体数字）。随后，该平台通过移动应用扩展到实体零售，证明核心模式不仅限于网页结账，且与反复集成、沙盒、网关开发、联合质量保证、发布协调和按比例支持增长相关的成本有所提升，虚拟卡提供商成为主要的外部依赖。
300+
支持的在线零售商
20×
零售商覆盖增加
4 mo
卖到100+零售商（相比15个月6个月）
85-90%
报告模型准确性
09 反思 / 接下来是什么
有效的是解决依赖问题，而非人员配置问题：一个资格功能服务网页、购物车和 OCR提取账单，虚拟卡让客户通过零售商已支持的支付流程操作，每个渠道都增加了自己的控制（DOM提取和自动填充在线; OCR、地理围栏和店内卡片过期）在一致的共享平台上。我接下来会改进的方面：将零售商赋能正式化为内部运营产品（上传、标签、培训、验证、DOM和门店设置、发布批准、健康监测）;添加收据对账，以提取总额、折扣和税务对账;引入低信任审查政策;加强地理围栏管控，包括短期有效期、金额和单笔交易限制，以及授权后立即关闭;通过计划合成测试构建自动化DOM变化检测;仪表盘上的独立 OCR 和人工智能错误报告;提升模型治理可追溯性（渠道、零售商、模型和训练数据版本、输入、 OCR 和分类置信度、协议版本、卡片结果）;并且由于 Android 和 iOS 权限和背景定位行为不同，可以谨慎地扩展到各类 Android 和 iOS。最终成果是一个全渠道平台，零售商产品数据取代了定制支付集成，AI确定资格，现有系统管理身份和信用，虚拟卡实现互操作性，浏览器和移动端让客户控制分销，业务增长与工程工作脱钩。