---
title: "SDK 播放页会员订购：基于大模型协同的低成本高效交付复盘"
date: 2026-04-21
description: "在不影响主链路业务的前提下，于 SDK 播放页嵌入独立会员订购组件 MembershipModal，承载 SSO、权益校验、商品横滑、协议勾选、下单支付与权益发放全闭环。本文复盘一次\"高推理密度用大模型评审、高吞吐任务用经济型模型编码\"的轻量协同实践：2% Token 架构评审揪出 5 个深埋风险，26/26 单测一次性通过，主链路零改动，研发工时缩短 66%。"
canonical_url: "https://yijinlee.com/articles/article-48"
tags:
  - "AI Coding"
  - Cursor
  - gpt-5.5-medium
  - "Composer 2.5 Fast"
  - SDK
  - React
  - 单测
  - 双模型协作
  - "Prompt Engineering"
topic: "AI 外骨骼"
---

METRICS: 3.8% Token · 26/26 单测 · 0 主链路改动 · 66% 工时缩短

本次需求的目标是在**不影响现有主链路业务**的前提下，在 SDK 播放页中嵌入一个独立的会员订购组件 `MembershipModal`。该组件需独立承载单点登录、权益校验、商品横滑、详情展示、协议勾选、下单支付及权益发放的完整闭环。

在当前追求极致资源利用率的背景下，我们没有盲目地全盘依赖高成本大模型，而是根据**"高推理密度用大模型评审，高吞吐任务用经济型模型编码"**的原则，进行了一次轻量、高效的研发协同尝试。

- **架构评审（gpt-5.5-medium，约 2% Token）**：专门用于前期架构卡点、边界识别与风险纠偏，概要设计。
- **编码走读（composer-2.5-fast，约 1.8% Token）**：用于存量资产走读、编码实现与单测交付。

### 一、任务背景与核心痛点

研发最怕的是"方向错了，代码写得越快越灾难"。`MembershipModal` 看似只是一个弹窗组件，实则横跨 SSO 登录、权益校验、商品检索、支付收银、协议合规与权益发放六条链路——任何一条在 SDK 内嵌环境下走偏，都可能在联调阶段集中爆发。

核心约束只有一条：**主链路零污染**。新组件必须像插件一样即插即拔，不承载、不污染原主链路业务的任何业务路由与控制流。

### 二、设计评审：用 2% 的核心投入，死守"不返工"底线

在方案初稿完成后，我们利用高推理能力模型进行了一轮严格的边界评审。这次评审帮我们揪出了 5 个隐藏极深的落地风险：

- **接口误用**：误将埋点统计接口 `analytics/metricsList` 当作商品集合接口调用。
- **支付断层**：未考虑 SDK 内嵌环境的特殊性，遗漏了跳转收银台与原生弹窗（Sheet）的兼容预案。
- **状态缺失**：会员状态校验与 SSO 前置链路中，缺少了网络超时或登录失败的异常兜底设计。
- **协议扩展性不足**：勾选框的《服务协议》`type` 硬编码，未给后续其他变体协议预留扩展位。
- **副作用污染**：直接复用原详情页组件，会无意间带入页面级的生命周期副作用，影响 SDK 稳定性。

💡 **纠偏结果**：基于评审反馈，我们迅速将方案收敛为：改用 `api/demo/catalog/search` 拉取集合、`fetchProductDetail` 获取详情；支付链路采用 SDK 内置 Sheet 加结果弹窗兜底；权益接口则由基础平台承接。这次前置评审仅消耗了极低的 Token 配额，却把可能在联调阶段爆发的"接口走错、链路不通"风险消灭在了代码编写之前。

### 三、编码前走读：摸清家底与非侵入式挂载

为了避免在敲代码时"边写边找"造成的探索性浪费，在动手前，我们让经济型模型对现有工程进行了盘点，锁定了可复用的存量资产：

| 模块分类 | 可复用资产 / 现有 API | 复用与隔离策略 |
| --- | --- | --- |
| API 接口 | `searchProduct`, `newProductDetail`, `createSubscriptionOrder`, `toSubmitOrderCheck` | 保持纯净，由独立封装的 Service 层进行底层 IO 调用 |
| 公共组件 | `Protocol`（协议组件）, `Win`（弹窗基类） | 采用 HOC 或声明式 Props 进行外围扩展，严禁改动组件源码 |
| 支付链路 | `checkout/ToPay`, `CheckoutSDK` | 封装为独立支付策略模块，与主链路解耦 |

同时，我们定下了严苛的隔离原则：新组件必须在**独立目录**下开发，主链路仅通过**动态 Import（懒加载）**在播放页声明组件入口，组件内部通过事件监听或声明式 Props 触发。这确保了新需求的接入"像插件一样，即插即拔"。

### 四、编码实现：高质量骨架与 26 条单测的踏实落地

在编码阶段，模型高效地帮我们完成了繁琐的结构化工作。最终交付物包含：**1 个主组件 + 6 个子组件 + 6 个服务/工具模块**，并同步配置了中英文 i18n 和 4 个权益 API 的占位符。

为了让后续的联调和维护更轻松，我们在架构上做了业务与 IO 的彻底解耦。同时，针对前端订购链路中"单点登录（SSO）跳转可能导致 JavaScript 运行时（Runtime）丢失"的硬伤，我们对状态机进行了持久化改良：

```arch
[UI 层: MembershipModal]
       │
       ▼
[业务层: flowState 状态机] ◄──► [快照持久化: sessionContext (30min 有效期)]
       │
       ▼
[IO 基础设施层: productService / memberService / orderService]
```

关键业务逻辑全部通过纯函数实现，并编写了 **26 条单测用例**（由开发者显式定义 TestCase 边界，大模型负责补全断言与 Mock 数据），保障以下核心规则：

- **协议拦截**：未勾选服务协议时，调用 `validateProtocolBeforePay` 必须精准拦截。
- **价格排序**：商品列表按价格升序排列，默认选中最低价（`sortProductsByPrice` / `pickDefaultProduct`）。
- **断点恢复**：针对 SSO 跳转导致的页面刷新，状态机采用"纯函数逻辑 + 序列化快照"设计。在跳转前通过 `sessionContext` 将状态写入本地缓存，30 分钟内回填恢复，确保长链路异步操作前后的状态幂等。

#### 单测避坑经验

在跑单测时，我们主动将依赖 `containerAPI` / 原生容器 Method 的业务逻辑与纯函数剥离，避免了 Jest 去解析 `lodash-es` 等重型依赖导致的报错或耗时问题。最终 **26 条用例一次性全部通过**，通过率 100%。

### 五、效益评估：数据中的人效与克制

这次实践不追求酷炫的 AI 全包写代码，而是追求"好钢用在刀刃上"，用可量化的指标来看：

```roi
核心主链路 0 处逻辑修改|真正做到了对线上既有路由和控制流的零污染
26/26 单测一次性通过|核心规则全部可自动回归，保障了骨架的高质量交付
1.5 人天 → 0.5 人天|整体研发工时缩短 66%，ROI 来自前置评审而非事后返工
```

以前这类涉及跨端登录、SDK 支付、协议校验的复杂组件，全靠人工对齐接口和排查依赖，至少需要 **1.5 人天** 的探索与沉淀期。本次通过将 2% 的高推理配额倾斜于架构评审，前置拉齐了全量边界，使后续编码收敛为纯结构化交付，实际仅耗时 **0.5 人天**。

### 六、团队经验沉淀

- **模型分层是降本的关键**：让高推理大模型充当"架构师"去做评审和卡点；让高吞吐模型充当"熟练工"去写结构化代码和单测。
- **防范轻量模型的"防御性重构"幻觉**：经济型模型在走读老代码时，倾向于重新编写一套全新的工具函数，而非主动复用既有 Utils。为此，我们在 Prompt 中必须强制约束"存量资产优先字典"，避免模型因"图省事"而导致的代码体积膨胀。
- **纯函数先行，骨架与联调分离**：状态机、参数映射、排序逻辑尽量写成纯函数，不依赖复杂的浏览器运行时。在后端接口未完全定型、产品配置未就绪时，先把骨架搭好并预留好扩展点（如 `PROTOCOL_TYPES.SERVICE_AGREEMENT`）。这让前端的研发节奏摆脱了阻塞，走在了项目组的前面。

## 参考文章：相关链接

- [Android · Billing / subscriptions overview](https://developer.android.com/google/play/billing)（官方文档）— 订阅计费官方模型，SDK 播放页会员订购的合规参照。
- [Apple · StoreKit](https://developer.apple.com/documentation/storekit)（权威引文）— iOS 内购框架文档，Hybrid/SDK 场景常踩的边界。
- [VersionUpgradeModal 实战复盘](https://yijinlee.com/articles/article-37)（站内深度）— 商业弹层工程化的对照样本。
- [Cursor Composer 高效交付复盘](https://yijinlee.com/articles/article-45)（站内深度）— 低成本高效交付的 AI 协作账本。