AI Coding · SDK 播放页会员订购
本次需求的目标是在不影响现有商城订购主链路的前提下，在 SDK 播放页中嵌入一个独立的会员订购组件 SdkMemberProductModal。该组件需独立承载单点登录、权益校验、商品横滑、详情展示、协议勾选、下单支付及权益发放的完整闭环。
在当前追求极致资源利用率的背景下，我们没有盲目地全盘依赖高成本大模型，而是根据"高推理密度用大模型评审，高吞吐任务用经济型模型编码"的原则，进行了一次轻量、高效的研发协同尝试。
架构评审
架构评审（gpt-5.5-medium，约 2% Token）：专门用于前期架构卡点、边界识别与风险纠偏，概要设计。 - 编码走读（composer-2.5-fast，约 1.8% Token）：用于存量资产走读、编码实现与单测交付。
任务背景与核心痛点
研发最怕的是"方向错了，代码写得越快越灾难"。SdkMemberProductModal 看似只是一个弹窗组件，实则横跨 SSO 登录、权益校验、商品检索、支付收银、协议合规与权益发放六条链路——任何一条在 SDK 内嵌环境下走偏，都可能在联调阶段集中爆发。
核心约束只有一条：主链路零污染。新组件必须像插件一样即插即拔，不承载、不污染原本地生活的任何业务路由与控制流。
设计评审：用 2% 的核心投入，死守"不返工"底线
在方案初稿完成后，我们利用高推理能力模型进行了一轮严格的边界评审。这次评审帮我们揪出了 5 个隐藏极深的落地风险：
接口误用
误将埋点统计接口 define/list 当作商品集合接口调用。
编码前走读：摸清家底与非侵入式挂载
为了避免在敲代码时"边写边找"造成的探索性浪费，在动手前，我们让经济型模型对现有工程进行了盘点，锁定了可复用的存量资产：
可复用模块与隔离策略
searchProduct, newProductDetail, createTicketOrder, toSubmitOrderCheck
保持纯净，由独立封装的 Service 层进行底层 IO 调用
Protocol（协议组件）, Win（弹窗基类）
采用 HOC 或声明式 Props 进行外围扩展，严禁改动组件源码
Pay/Topay/Life, PaySDK
封装为独立支付策略模块，与主链路解耦
同时，我们定下了严苛的隔离原则：新组件必须在独立目录下开发，主链路仅通过动态 Import（懒加载）在播放页声明组件入口，组件内部通过事件监听或声明式 Props 触发。这确保了新需求的接入"像插件一样，即插即拔"。
编码实现：高质量骨架与 26 条单测的踏实落地
在编码阶段，模型高效地帮我们完成了繁琐的结构化工作。最终交付物包含：1 个主组件 + 6 个子组件 + 6 个服务/工具模块，并同步配置了中英文 i18n 和 4 个权益 API 的占位符。
为了让后续的联调和维护更轻松，我们在架构上做了业务与 IO 的彻底解耦。同时，针对前端订购链路中"单点登录（SSO）跳转可能导致 JavaScript 运行时（Runtime）丢失"的硬伤，我们对状态机进行了持久化改良：
分层架构 · 业务与 IO 解耦
关键业务逻辑全部通过纯函数实现，并编写了 26 条单测用例（由开发者显式定义 TestCase 边界，大模型负责补全断言与 Mock 数据），保障以下核心规则：
协议拦截
未勾选服务协议时，调用 validateProtocolBeforePay 必须精准拦截。
单测避坑经验
在跑单测时，我们主动将依赖 webapi / 原生容器 Method 的业务逻辑与纯函数剥离，避免了 Jest 去解析 lodash-es 等重型依赖导致的报错或耗时问题。最终 26 条用例一次性全部通过，通过率 100%。
效益评估：数据中的人效与克制
这次实践不追求酷炫的 AI 全包写代码，而是追求"好钢用在刀刃上"，用可量化的指标来看：
人效收益 · 好钢用在刀刃上
真正做到了对线上既有路由和控制流的零污染
核心规则全部可自动回归，保障了骨架的高质量交付
整体研发工时缩短 66%，ROI 来自前置评审而非事后返工
以前这类涉及跨端登录、SDK 支付、协议校验的复杂组件，全靠人工对齐接口和排查依赖，至少需要 1.5 人天 的探索与沉淀期。本次通过将 2% 的高推理配额倾斜于架构评审，前置拉齐了全量边界，使后续编码收敛为纯结构化交付，实际仅耗时 0.5 人天。
团队经验沉淀
模型分层是降本的关键
让高推理大模型充当"架构师"去做评审和卡点；让高吞吐模型充当"熟练工"去写结构化代码和单测。
本文属于 AI 实用主义流派 的第 38 篇肉身实战。
发表评论
分享你的想法和反馈