Nonmotor 前端开发指南：从需求到交付#

这份指南面向准备接手 Nonmotor 前端需求的后端工程师。代码可以交给 AI 辅助编写；接需求的人仍要弄清产品在什么市场和环境运行、页面由哪些配置控制、改动影响谁，以及怎样证明真实业务链路可用。本文沿一项需求的完整流程，重点讲产品工厂、PFC、Transify 的使用与验证，再说明必要的代码定位、联调和交付。

完成练习后，应能主导一项 Nonmotor 需求：确认产品和业务规则，查清实际生效的 Journey、PFC 与文案配置，让 AI 辅助实现，并用真实流程完成验收和交付。AI 无法仅凭代码判断业务边界、后台配置是否命中以及 App 内全流程是否可用；这些结论需要负责需求的人亲自核实并承担结果。

阅读路线与分享安排#

主线：认识项目 → 跑通环境 → 明确需求 → 使用产品工厂 / PFC / Transify → AI 辅助实现 → 联调 → 交付。

现场分享重点放在第 4—10 章。第 1 章简要开场，第 2、3 章作为提前准备和现场调试手册；安装步骤无需逐项演示。产品工厂、PFC、Transify 保持独立章节，先讲平台怎么用，再讲 AI 如何参与实现。现场顺序见分享提纲。

本文依据 2026-10-09 至 2026-10-14 核对的工作区源码、团队提供的截图和已确认操作约定整理。业务项目的新环境安装、真实产品端到端流程及部署尚未在本次文档整理中实测；登录、权限和负责人等待补信息统一列在附录 A。源码依据见附录 B，市场代理规则见附录 C，Motor 各市场流程详解见附录 D。

1. 项目介绍：先认识业务与复用边界#

本章先建立项目认知：用户经过哪些页面、Motor 与 Nonmotor 为什么分开组织、哪些能力可以复用。入口注册和模板内部实现分别在第 4、5 章展开。

1.1 Motor 与 Nonmotor 的区别#

Motor 主要承载车险，Nonmotor 承载非车险。两者都会经过产品选择、信息填写、报价/确认和支付，但 Checkout 之前的页面组织方式不同：Motor 以市场专属页面为主，Nonmotor 的产品工厂主流程以共享模板和 Journey 配置为主。

对后端同学来说，可以先这样理解：Motor 由各市场的页面代码编排本地业务；Nonmotor 把高度一致的页面骨架、表单和交互做成可复用能力，再由产品工厂描述某个产品应该使用哪些能力。

图 1：两种组织方式的核心差异在 Checkout 之前。图中是源码结构示意，不是真实产品 UI 截图；可点击放大。

业务分类、应用配置、源码目录和维护仓库需要分别确认，具体定位方法见第 4 章。

1.2 为什么采用不同的页面组织方式#

按照团队当前的业务划分，Motor 页面相对复杂，很多业务组件与市场流程强相关，跨市场难以直接复用；Nonmotor 不同市场、产品的页面结构和功能组件高度一致，复用收益更高。源码中的“市场目录”与“共享 Factory 模板”体现了这一设计取向。

这不是绝对隔离。Motor 也会复用 MoneeDesign、InsEntry、Bridge、请求、缓存和部分业务组件；Nonmotor 也保留市场适配，例如 purchase5/config/{region}、PDP 的市场插入规则，以及 PHApplicant 等专属区块。应复用稳定共性，同时保留明确的市场/产品扩展点。

1.3 用户实际经过哪些页面#

两类业务的共同目标都是让用户了解保障、提供投保信息、确认方案并支付。差别在于 Checkout 之前如何拆页、组织交互和复用实现。

图示根据源码导航与配置整理，表示典型路径；产品、续保和可选分支可能改变实际顺序。

Motor 按市场查页面，完整目录截图、页面文件名和源码依据见附录 D。Nonmotor 在多个市场复用 Factory 模板，当前 MY、ID、SG、TH 注册了同一组 PDP6、Purchase5、Confirmation 入口，但其他市场的页面集合并不完全相同。

Checkout 的边界#

Nonmotor 的“模板引擎 + 产品工厂”主要描述 Checkout 之前的产品工厂页面。收银台采用独立的 checkoutV2 实现，处理金额、优惠、支付选项及创单衔接，并保留市场适配。Motor 与 Nonmotor 可以共用收银台源码，传入的数据、应用与市场构建仍然不同。

前端负责交互、展示和及时校验；金额、资格、报价和创单结果应以对应后端契约为准。一个浏览器页面能打开，不等于 App 内完整下单流程已经通过。

1.4 页面最终由什么决定#

实际页面来自几个部分的组合：前端代码、产品 Journey、接口数据、翻译、PFC 配置以及运行环境。

因此，“页面不对”不一定意味着要修改 React 代码。某个字段没有出现，可能是 Journey 没有配置、显隐条件未命中、组件名未匹配，也可能是当前产品或市场选错。

还要区分两个常见概念：

• Journey：产品工厂下发的页面、区块、字段及相关规则，常通过 query_product_factory_journey 获取。
• PFC：项目使用的配置能力，按服务、环境、市场等条件提供配置值；页面从指定 key 读取后决定功能或展示行为。它不代替 Journey 描述 page/block/entry，也不代替业务接口返回报价或保单数据。实际用法见第 6.2 节。

1.5 后端工程师需要建立的前端认知#

当前工程主要使用 React 18、TypeScript、Webpack 5、SCSS，采用多入口多页面架构。每个页面有自己的入口和 HTML，构建时按应用与市场选择页面集合。

页面可以运行在浏览器或 App WebView 中。项目通过 Bridge 封装页面跳转、返回和其他宿主能力。浏览器能打开页面，并不代表 App 中的返回、登录和支付链路已经验证完成。

前端组件会随状态变化重复渲染，不能把组件函数当作“只执行一次的服务初始化”。跨页面跳转后，组件状态也不能自然保留，需要明确缓存与参数传递方式。

2. 本地环境：从安装到打开业务页面#

本章按实际准备顺序操作：拿到有效入口与权限 → 安装依赖 → 选择环境并启动 → 配置浏览器代理与 HTTPS → 验证业务域名、接口和登录态。默认先跑通浏览器，模拟器与真机准备放在第 3 章。

2.1 准备入口、账号与权限#

先拿到仓库访问权限，以及一个可以复现的非生产产品入口。开发样例至少要包含：市场、环境、产品、页面 URL、测试账号获取方式，必要时还包括后端 PFB。

需要访问的能力包括公司 npm 源、项目启动所需的 KMS、产品工厂配置、翻译平台，以及联调使用的后端环境。具体权限申请入口由团队维护人提供。

本文示例从已拉取的 nonmotor_h5 仓库根目录执行。开发者可使用自己的 IDE，但终端工作目录必须正确。

2.2 安装 Node 与项目依赖#

仓库 .nvmrc 当前声明 v20。已安装 nvm 的同学可以执行：

nvm install
nvm use
node -v
npm -v

使用其他 Node 版本管理器时，同样以项目版本文件为依据。package.json 中较宽泛的最低版本声明，不代表所有更低版本都已验证可用。

部署安装脚本使用以下依赖安装方式，本地可以据此准备依赖：

npm install --registry https://npm.shopee.io --legacy-peer-deps

安装失败时，先根据错误区分 npm 源访问、权限、Node 版本和原生依赖编译问题。不要通过随意升级依赖或删除锁文件来跳过原因分析。安装后检查 package-lock.json 差异，确认是否属于本次需求。

2.3 选择环境并启动本地服务#

npm run dev 的交互脚本会把所选配置保存到仓库根目录 .env。新任务开始时应核对配置，不要无意复用上一次开发的市场和应用。

npm run start 和 npm run build 都会先执行 scripts/kms.js。KMS 访问失败属于启动前置条件问题，应按团队约定准备对应凭证和网络；凭证不要写进源码、MR 或共享排障日志。

使用交互入口启动#

npm run dev

依次选择“开发”、目标环境、Transify 上报设置、目标市场、服务 nonmotor、构建环境；需要时再选择主体。首次启动应显式选择，确认无误后才使用“使用上一个命令”。

脚本随后调用 npm run start。默认端口为 3000，端口变更时以终端输出为准。

2.4 建立浏览器到本地服务的代理链路#

本地联调使用 ZeroOmega 浏览器代理插件 + Whistle 代理服务 + 本地开发服务。三者职责如下：

Whistle 是基于 Node.js 的跨平台网络代理与调试工具，支持 macOS、Windows、Linux。日常使用它查看请求、代理页面和接口、mock 响应、模拟弱网以及调试移动端 H5。ZeroOmega 只负责代理选择，安装插件后还需要运行 Whistle。Whistle 项目说明

以 MY Test 的整站代理规则为例：

浏览器地址栏仍是业务域名，本地代码通过代理返回。页面 Cookie 和存储仍按浏览器中的域名使用；代理本身不会创建登录态。

安装 ZeroOmega 插件#

在 Chrome 中打开 Proxy SwitchyOmega 3（ZeroOmega）安装页，安装后进入插件设置，新建一个代理情景模式，例如命名为 Whistle。

将该 HTTP 代理设为默认代理，使目标 HTTP/HTTPS 请求都经过它；若界面分别配置 HTTP、HTTPS 请求代理，两者均指向上述代理服务。这里选择的 HTTP 是浏览器连接代理的方式，不代表目标业务页面必须使用 HTTP。

保存/应用设置。等 Whistle 启动后，再通过插件图标切换到 Whistle 模式。也可以在自动切换模式中仅让目标业务域名走此代理。

安装并启动 Whistle#

完成 Node 环境准备后，在终端执行：

# 安装命令行版
npm i -g whistle

# 启动并查看状态
w2 start
w2 status

打开 Whistle 本地管理后台。主要使用 Network 查看流量，使用 Rules 编辑代理规则。命令行版的常用管理命令如下：官方命令行文档

# 重启
w2 restart

# 停止
w2 stop

Whistle 也提供桌面客户端，可从官方安装说明进入；本指南统一以命令行版为例。同一套环境选择一种运行方式，避免两个实例竞争端口或误用另一套规则。

安装证书并开启 HTTPS 抓包#

业务页面使用 HTTPS 时，需要让 Whistle 解密请求，才能按页面路径代理并查看明文请求响应。完成以下设置：

1. 在 Whistle 管理界面打开 HTTPS，通过 Download RootCA 下载本机 Whistle 根证书。
2. 在操作系统中安装并信任该证书。macOS 可在“钥匙串访问”中导入并设置证书信任；也可使用下面的官方命令完成安装，按系统提示确认。
3. 在 Whistle HTTPS 设置中开启 Enable HTTPS (Capture Tunnel Traffic)。
4. 重新加载目标 HTTPS 页面，检查是否能看到具体 URL、请求头和响应内容。

w2 ca

证书安装与 HTTPS 解密开关需要同时完成。若只看到 Tunnel to 而无法查看目标请求内容，先检查解密开关、证书信任以及请求是否经过当前 Whistle 实例。HTTPS 设置说明、证书安装命令

配置目标市场的代理规则#

在 Whistle 的 Rules 中按市场与环境建立规则组，例如 nonmotor-my-test，粘贴规则、保存并启用。本地 3000 端口一次运行的是当前选择的应用/市场/环境；日常只启用本次需要的规则组。

以 MY Test 为例，团队材料使用整站转发，本指南整理为显式指定 HTTP 目标的写法：

# MY Test：保留请求路径，整站转发到本地开发服务
protection.test.shopee.com.my http://localhost:3000

它会将 /nonmotor/purchase5.html?... 转发到本地相同路径。已有整站规则时，指向相同服务、保留相同路径的 /ins、/nonmotor、/common、/ec、/static 规则可合并，避免重复维护。使用 http:// 明确目标是本地 HTTP 开发服务，URL 路径按规则自动拼接。Whistle HTTP 转发规则

整站转发也包含 /api，接口随后由 scripts/start.js 的开发代理决定最终后端目标。因此需要核对浏览器访问环境、Whistle 规则和本地启动环境。它不是只替换 HTML 的规则。

如果只想代理某个页面目录，可以使用下列规则替代整站规则；资源和其他请求的去向需要另外核对，不要与整站规则一起启用后误以为范围已缩小：

# 可选：仅把 nonmotor 路径转发到本地
protection.test.shopee.com.my/nonmotor http://localhost:3000/nonmotor

各市场的整站规则见附录 C。代理规则不会自动启动项目，也不会让未构建的应用页面出现：APP_NAME=nonmotor 时，其他应用入口是否可用仍取决于本地构建内容。

2.5 使用有效业务 URL 与登录态#

开发环境生成的 HTML 路径带应用前缀。例如，MY 的 purchase5 在默认端口下对应：

http://localhost:3000/nonmotor/purchase5.html?product_id=<目标产品ID>

这是路径示意，<目标产品ID> 必须替换成实际值，其他必要参数应从有效业务入口保留。该页依赖产品配置、登录态和前序流程数据时，应从产品详情进入；直接打开中间页不能替代完整链路验证。

完成第 2 章代理配置后，日常联调在浏览器打开对应环境的原始业务地址，例如 MY Test：

https://protection.test.shopee.com.my/nonmotor/purchase5.html?product_id=<目标产品ID>

浏览器通过 Whistle 获取本地页面，地址栏保持 MY Test 域名。直接访问 localhost 可用于检查本地页面服务，但两者的 Cookie/存储域不同，不能把 localhost 能打开视为业务域名登录已完成。

仓库旧 README 中的 /ins/ 和根路径示例不能直接套用到 nonmotor。开发路径依据 config/webpack.config.js，页面名单依据 config/nonmotor/{region}.json。

2.6 核对 API 环境与 PFB#

scripts/start.js 已包含开发代理：非 mock 环境根据 BUILD_ENV、REGION、ENV 等选择后端域名，并代理 /api 请求；mock 环境将 /api 指向本地 3001 端口。

启动后先查看终端输出的请求转发域名，再在浏览器 Network 面板核对具体请求。页面加载成功、代理目标正确、登录成功是三个不同检查点。

使用第 2 章的整站规则时，请求链路是“浏览器 → Whistle → 本地开发服务 → 开发 API 代理”。登录 Cookie 的域、环境和账号必须匹配当前打开的页面；后端使用 PFB 时，验证实际链路是否命中目标 PFB。

用户提供的浏览器域名与当前 scripts/start.js 的部分 API 目标存在差异：

此表记录材料和源码的差异，不据此认定域名不可用或需要替换。目标环境是否通过别名或迁移实现兼容，需要实际联调确认。浏览器域名正确仍不足以证明 API 目标正确，本次文档整理未修改代理源码。

2.7 首次启动的验收清单#

首次开发不以“终端没有报错”为结束，应完成以下检查：

1. Webpack 编译完成，目标 /nonmotor/*.html 可以打开。
2. 当前应用、市场、环境和产品与需求一致。
3. 页面能获取正确 Journey 或业务数据，接口没有登录失败。
4. 修改一处目标页面代码后，能够确认浏览器运行的是本地版本。
5. 至少完成目标产品的一段真实交互，核对请求和页面结果。

代理链路还应检查：

• ZeroOmega 已选中 Whistle 模式，Whistle Network 中能看到目标请求。
• HTTPS 请求能展开内容，规则已启用，本地服务确实返回目标页面。
• 在业务域名下刷新页面能看到本地改动，API 返回来自预期环境。
• 调试结束后恢复代理设置，浏览器和手机能够正常访问网络。

若 Whistle 看不到请求，先查插件模式和代理端口；能看到请求但页面未替换，查规则命中、缓存和本地路径；接口报登录错误则继续核对账号、Cookie 域和 API 目标，代理工具不会代替登录步骤。

3. 调试方式：浏览器、模拟器与真机#

本章解决“在哪里验证、用什么工具看问题”。第 2 章先跑通请求链路，本章再区分浏览器局部调试、App 内 H5 调试和完整业务自测。

3.1 按任务选择调试环境#

日常开发可以先在浏览器快速调试，再用模拟器检查 App 内行为，提测前优先在真机完成主流程自测。三种方式共享同一套业务代码，但运行环境和可验证的能力不同。

3.2 浏览器：日常开发与局部验证#

浏览器调试最轻量。完成代理和登录准备后，直接打开目标业务 URL，使用 Chrome DevTools 的 Elements、Console、Network、Sources、Application 等面板即可调试，不必同时运行模拟器。

图示：完成登录鉴权后，通过有效的业务 URL 打开 H5 页面；Console 查看日志，Network 查看请求，Elements 检查 DOM 与样式，Application 查看当前域名的 Local Storage、Session Storage 和 Cookie。截图中的 URL 和参数仅用于说明入口位置，实际调试请使用本次产品的有效入口。点击图片可放大查看。

适合先完成布局调整、文案检查、字段校验、接口响应处理等工作。浏览器的设备模拟模式可以辅助检查移动端尺寸，但页面仍运行在浏览器环境中，不会因此获得 Shopee App 的 Bridge、RN 或原生能力。

当前项目涉及 App 能力的完整下单流程，不能只在普通浏览器中验收。 按团队提供的场景，支付页面、OTP 验证页面、SP 统一的 address select 页面等需要跳转到 App 内的 RN/原生页面，浏览器无法复现这些跳转及返回链路。具体页面承载方式以目标市场和 App 版本为准。

遇到这些边界时，转到模拟器或真机继续验证。即使使用 mock 或模拟 Bridge 返回值，也只说明 H5 在指定返回数据下的处理正常，不能证明真实 App 跳转、回调和下单流程通过。

3.3 模拟器：安装 App 并配置代理#

本节适用于 macOS + Xcode 的 iOS 模拟器，用于验证 Shopee App 内的 H5 展示、返回与 Bridge 交互。安装入口和内部 App 下载方式来自团队提供的截图；截图中的设备、iOS 和 App 版本只是示例，选择时以当前测试要求和兼容性为准。

第一步：安装 Xcode 并启动模拟器#

1. 从团队材料中的 Xcode 下载目录获取适配当前 Mac 的 Xcode，完成安装及首次启动要求的组件安装。
2. 在 Xcode 中确认已安装目标 iOS Simulator runtime。如果没有可选的 iOS 设备，先在 Xcode 设置的运行时/组件管理界面下载所需版本；不同 Xcode 版本的菜单名称可能不同。Apple 运行时安装说明
3. 搜索并打开 Simulator.app，或通过 Xcode 的 Open Developer Tool → Simulator 打开。
4. 选择并启动一个目标 iPhone 模拟设备，等待进入 iOS 主屏幕。

Simulator 是 Xcode 自带的开发工具。仅有命令行工具不等于已经准备好完整的模拟器环境。Apple Simulator 说明

第二步：下载对应市场的 Simulator App 包#

进入团队 App 平台 app.sea.com，选择需要调试的 Shopee 市场 App。截图给出的示例为 Shopee ID App 页面，其他市场选择各自对应的 App。

在 iOS 版本列表中搜索 simula 或 simulator，找到团队要求的模拟器构建版本并下载。不要把截图中的历史版本号作为统一安装要求；也不要仅凭市场一致就选择任意 Native Feature Build，应使用本次测试约定的构建。

安装包需要明确支持 iOS Simulator，并与当前 Mac 架构及模拟器运行时兼容。普通真机安装包不能通过改扩展名变成 Simulator 包。

第三步：解压并安装 App#

1. 若下载的是可直接使用的 .app 应用包，直接进入安装步骤。
2. 若是压缩包，先解压。团队材料中的“改后缀为 .zip”适用于内容本身为 ZIP 归档、但下载扩展名不便解压的包；已经是 .zip 的文件直接解压即可。
3. 在解压目录中找到 .app 应用包，将它拖到已经启动的 Simulator 设备窗口中安装。
4. 等待主屏幕出现 App 图标，打开并检查能否正常启动。

如果安装失败，先核对是否误下真机包、市场/构建是否正确、Mac 架构及 runtime 是否兼容。App 安装完成后，再按团队测试账号流程登录；账号获取和登录操作另行补充。

第四步：为模拟器开启系统代理#

第 2.4 节的 ZeroOmega 控制 Chrome 请求，不能代替模拟器 App 的代理设置。按团队材料，模拟器联调通过 Whistle 设置 Mac 系统代理：

# 启动 Whistle
w2 start

# 设置 Mac 系统代理，指向运行中的 Whistle
w2 proxy

默认 Whistle 使用 127.0.0.1:8899。开启系统代理会影响使用该系统代理的其他应用，操作前保留原代理配置，结束后恢复。Whistle 系统代理命令

同时完成以下配置：

• 在 Whistle 启用目标市场/环境的规则组，启动对应的 nonmotor 本地服务。
• 在 Whistle 开启 HTTPS 解密，并在当前模拟设备内安装、信任该实例的根证书。可以通过模拟器 Safari 打开 Whistle 证书下载地址，再按 iOS 的描述文件安装与证书信任流程操作；不要仅凭 Mac 已信任证书就认定模拟器也已完成配置。iOS 的信任步骤见Whistle 移动端证书说明。
• 先在模拟器 Safari 打开目标 HTTPS 页面验证网络与证书，再在 Shopee App 中从实际业务入口打开目标 H5，验证 App 内行为。

浏览器 ZeroOmega、Mac 系统代理和实体手机 Wi-Fi 代理是不同的流量入口，按调试设备选择；三者可以指向同一个 Whistle 服务。

第五步：验证并结束调试#

在 Whistle Network 中观察请求，并核对：

若 Safari 请求可抓取、但目标 App 请求不可抓取，应继续检查 App 的网络及证书策略，不把浏览器验证结果当作 App 已通过。模拟器用于日常开发验证，依赖真实设备能力的场景仍需按验收要求在真机验证。

调试结束，或其他软件因系统代理出现网络问题时，关闭本次启用的系统代理：

w2 proxy 0

# 不再需要 Whistle 时再停止服务
w2 stop

截图使用 w2 proxy off，本文统一采用官方当前文档列出的 w2 proxy 0。若原来已有公司代理或其他网络工具，应恢复原设置；Chrome 的 ZeroOmega 若仍选着 Whistle 模式，也需要切回正常模式。Whistle 命令说明

团队安装材料截图#

截图中的内部下载地址作为团队提供的安装入口保留，本次未登录这些平台确认可下载版本，也未实际安装 Xcode、App、证书或修改系统代理。

3.4 Safari：检查 App 内的 H5#

模拟器负责运行 App，Mac 上的 Safari Web Inspector 负责查看和调试其中的 H5。可以把它理解为“给模拟器里的网页打开 F12”。

1. 打开 Mac 上的 Safari → Settings（设置）→ Advanced（高级），勾选 Show features for web developers（显示网页开发者功能）。旧版 Safari 的文案可能为“在菜单栏中显示开发菜单”。
2. 启动 iOS 模拟器，在 Shopee App 中进入要调试的 H5 页面，保持页面打开。
3. 在 Mac Safari 的 Develop（开发） 菜单中，找到正在运行的模拟设备，再选择对应 App 下的目标 H5 标题或 URL，打开 Web Inspector。
4. 在模拟器中操作页面，同时在 Mac 上查看日志、请求、DOM 与样式。页面跳到新 WebView 后，必要时重新选择当前页面。

图示：Safari → Develop → 当前模拟器或真机 → Shopee → 目标 H5 页面。截图中选中的是已连接的真机，模拟器入口位于同一菜单；选择页面后会打开下方的 Web Inspector。点击图片可放大查看。

模拟器的远程检查能力默认开启，无需照搬真机的 Web Inspector 开关步骤。菜单中能否出现具体 App 页面，还取决于该 App 构建是否允许检查 WebView。WebKit 启用 Web Inspector 说明

这里的“缓存”需要分清：表单数据可能在页面存储中，JS/CSS 等资源还可能命中 HTTP 缓存。先核对当前页面和数据来源，再决定清理哪一项；清理存储可能同时清掉登录态或前序投保信息。

如果 Develop 中没有目标页面，先确认 App 已打开 H5、选对设备和页面，再核对测试包是否开放 WebView 检查。能检查模拟器 Safari 中的网页，不代表一定能检查 Shopee App 内的 WebView；需要时由客户端同学确认构建配置。WebKit App 内容检查说明

Safari Web Inspector 主要检查选中的 H5 页面；Whistle 用于观察经过代理的网络流量和执行转发规则。两者配合使用。Safari 的 DOM/样式面板不能直接检查 App 的 RN 或原生页面内部实现。

3.5 真机：验证完整用户交互#

可以直观理解为“把电脑里的模拟设备换成手里的真实手机”。真机能更接近用户实际操作，尤其适合检查触摸、键盘遮挡、滚动、返回手势和 App 页面切换。提测前优先使用真机完成本次需求的主流程自测。

使用目标市场、环境和测试版本的 Shopee App，从实际业务入口进入页面。调试本地代码时，按第 3.6 节配置手机代理及证书，并确认手机请求确实经过电脑上的 Whistle。

需要检查 iPhone 内的 H5 时，在 iPhone 设置中找到 Safari → Advanced（高级）→ Web Inspector（网页检查器），开启后连接 Mac 并完成设备信任，再从 Mac Safari 的 Develop 菜单选择该设备与可检查的 H5；较新 iOS 的 Safari 设置可能位于“设置 → App”内。此方式同样要求 App 开放对应 WebView 检查。iOS 远程检查说明

自测重点包括：

• 从入口到目标页面、字段输入、确认和下单的完整链路，包含本次涉及的支付、OTP、地址选择及其返回结果。
• 弹出键盘后输入框和底部按钮是否可见，长页面是否能正常滚动，触摸和返回手势是否符合预期。
• 返回修改、取消操作、重新进入、切到后台再回来时，页面状态和数据是否正确。
• 本次影响的目标系统、App 版本和市场。只在一台 iPhone 上通过，不代表 Android 或其他 App 版本也已通过。

给 QA 的自测记录应写清设备/系统、App 版本、市场、环境、入口、执行场景和结果，区分浏览器验证、模拟器验证与真机验证。

3.6 Whistle 联调能力与代理收尾#

这些能力可以在不修改业务代码的情况下调整网络行为，规则使用后应关闭，避免影响下一轮真实接口验证。Whistle 快速上手

手机代理与证书#

手机调试时，手机与电脑需网络互通；将手机 Wi-Fi 的手动代理设为电脑的局域网 IP + 8899，不能填写手机自己的 127.0.0.1。手机也需要安装并信任该 Whistle 根证书，iOS 安装描述文件后还需开启完全信任。部分 App 的证书策略可能限制抓包，应以实际运行结果为准。移动端抓包说明

结束调试时，先将 ZeroOmega 切回原先的正常模式，再按需执行 w2 stop；手机或系统若设置了手动代理，也应恢复原配置。本文浏览器方案不要求同时开启系统代理，只有配置过的代理入口才需要恢复。

4. 接到需求：确认范围、配置与改动方案#

接到需求后，先确认目标产品与当前页面，再判断改动落在配置、接口还是共享组件。这个阶段要产出一份可执行的方案：改什么、在哪里改、影响谁、如何验证，以及交付时需要哪些配套配置。

确认范围与入口 → 核对当前数据 → 判断配置/代码边界 → 形成方案 → 在对应迭代开发。

4.1 确认业务范围与验收条件#

编码前，先确认以下信息：

接口有某个字段，并不意味着前端该直接展示或提交它。要同时确定展示规则、交互规则和业务含义。

4.2 查清当前页面的配置与数据#

打开目标页面后，按来源收集与本次需求相关的事实。后台配置和页面实际收到的数据要对得上，才能确定正确的改动点。

记录有效入口和获取时间，分享时遮蔽 URL 中的会话等敏感参数。团队提供的 SG PA 快照用于理解数据结构；实操仍要取得目标环境当前的响应。浏览器不能验证的 App 跳转、支付和返回行为，应明确留到模拟器或真机检查。

4.3 判断修改配置还是代码#

如果需求只涉及 Journey，也要验证运行时页面和接口行为；如果修改公共组件，回归范围要覆盖复用方。

4.4 形成实现方案#

小需求可以用一份简明方案说明目标页面、字段映射、改动文件和验收场景。复杂需求需要 TD，把页面、组件、接口、配置、缓存和发布依赖拆清楚。

开发顺序建议为：确认业务规则和契约 → 获取当前产品 Journey 与 PFC 生效值 → 判断配置/代码边界 → 给 AI 提供明确输入并检查产物 → 联调、自测 → Review、提测。接口尚未就绪时，可以用明确契约的 mock 并行开发，真实接口就绪后补齐联调。

4.5 在对应迭代分支开展工作#

团队在 Casement 中建立迭代，迭代分支命名为 release-v1.x.xxx；本地开发分支命名为 dev-v1.x.xxx，版本号与目标迭代保持一致。例如，release-v1.3.318 对应 dev-v1.3.318。

完整流程如下：

开始修改前检查工作区和当前分支，确认本次需求所属的迭代：

git status --short
git branch --show-current

在对应的 dev-v1.x.xxx 分支完成开发和 commit，本地开发、自测完成后推送分支并提交 MR。MR 的 source 选择 dev-v1.x.xxx，target 选择同版本的 release-v1.x.xxx。

提交 MR 前同步目标分支并处理冲突，不把无关工作区变更混入本次需求。确认 MR 已成功合入 release 并完成发布后，再进入 Casement 部署；只有本地 commit 或 MR 尚未合入时，release 版本还不包含本次改动。

Reviewer、审批要求及多人同时使用开发分支时的远端协作约定，按团队安排执行，具体规则待补充。

4.6 源码入口：需要改代码时查这里#

页面注册图展示的是查找机制：filename 对应浏览器中的 HTML 文件名，chunks 关联 entry 的 key，entry 的值指向 src/pages/ 下的源码。下图截自 MY 配置，用来解释关系；核对 SG 页面时应打开 config/nonmotor/sg.json，不能把 MY 截图当作 SG 的运行证据。

以当前 SG 的 factory-pdp6.html 为例，入口配置指向 factoryV2/pdp/index.tsx。找到入口后沿实际 import 阅读 App.tsx、Journey 请求和目标组件；同名目录不一定是当前页使用的实现。若修改共享组件，还要反查其他产品和市场的调用方。

config/nonmotor/ 是 nonmotor 应用的页面清单，config/common/ 是 common 应用的页面清单；src/pages/common/ 则只是源码目录。页面归属、源码路径和维护仓库是三个不同问题。按团队约定，nonmotor 应用页面在 nonmotor_h5 处理，common 应用页面在 ins_h5 处理。

5. 产品工厂：从 Journey 到页面与数据闭环#

本章聚焦产品工厂：先认识 Page → Block → Entry 与编辑界面，再用 SG PA 的真实 Journey 核对页面、字段和步骤，最后介绍配置导入、模板渲染与售中缓存。PFC 提供的开关与参数另在第 6 章独立说明；一项需求可能同时涉及两套配置和业务接口。

5.1 认识页面结构与编辑界面#

可以将其理解为“配置描述界面需要什么，代码提供可执行的组件能力”。配置写入了某个 component_name，还需要确认目标页面能够解析并加载该组件。

产品工厂分享从 Admin 操作侧解释了这三层：左侧组件树选择 Page/Block/Entry，中间画布预览真实 H5，右侧属性面板编辑文案、图片、联动和数据组装。Admin 产出配置 JSON；H5 的 useGenerateComponents 根据 block 查同步或异步组件，并通过 props 转换、blocks 后处理生成 React 树。后台预览适合定位节点，但正式验收仍要在目标环境核对运行时 Journey 和真实操作。

图 3：配置页面把结构、预览和文案并排展示。选中一个 Block 后，可以在右侧核对该区块的 EN/SG 文案、图片等 i18n props；截图中的 Apply & Preview 用于刷新中间预览，Save / Publish 是后续保存与发布动作。预览变化不等于目标环境已经生效，还要重新打开真实业务 URL 验证。

图 4：另一编辑视图展开到 fillInfo 的具体 Entry，可检查字段属性、Pure Props、I18n Props 与 Dependencies。Pure Props 是传给已实现组件的配置参数，组件支持的参数以其代码契约为准；I18n Props 用于需要按语言配置的文案。截图提示手动编辑后先 Apply，再 Save / Confirm。这些按钮属于当前编辑视图，操作时要检查差异和实际状态，不能把图 3 的 Publish 与这里的 Confirm 当作同一个按钮。

拿到需求后，先按组件能力分成三类：

判断依据是当前配置能否表达需求，以及当前组件是否已实现所需行为。只改文案、图片或现有参数时优先复用；新增 prop 时保留旧配置的默认行为；确实没有合适能力时才新增组件。给 AI 实现任务时一并提供组件代码位置、现有 props 契约、目标 Journey 节点和其他调用方，生成后仍要检查真实页面。

5.2 找到并核对当前 Journey#

以一个已经能打开的产品页面为起点，按下面的顺序查。产品工厂存在不同编辑视图，操作按钮见本章截图；实际权限、发布范围和审批仍按当前环境的团队约定核对。配置、运行时请求和仓库代码要交叉验证。

1. 锁定对象。 记录市场、环境、产品 ID、业务入口和页面名称。只给 AI 一张页面截图，无法确定这几个维度。
2. 取得配置。 在目标环境的产品工厂查该产品当前 Journey，保存修改前的配置与版本；在浏览器 Network 中对照 query_product_factory_journey 的实际响应，确认当前页面消费的是同一产品与页面。若两者不同，先排查环境、产品 ID、发布状态与缓存。
3. 找到改动点。 在 pages 中找到目标 page，再定位 block、entry、字段属性、依赖和步骤。检查现有组件是否支持需求；必要时沿第 4 章的页面入口和第 5.3 节的解析链路查代码。
4. 确定范围。 说明这次是只调整某个产品的配置，还是修改共享组件、接口或翻译；列出其他消费同一组件的产品与市场。
5. 验证结果。 在目标环境重新进入业务页面，核对 Journey 响应、页面展示、前后步骤、返回修改和最终请求。后台“保存成功”不能代替页面行为验收。

做完这一步，应留下产品与环境、配置前后差异、代码能力判断、影响范围、运行时证据。这些事实也构成给 AI 的任务输入。

用 SG PA 的真实 Journey 读一次配置#

下面取自团队提供的一份 query_product_factory_journey 响应快照：product_id=2044008389641503267、lang=EN、rollout_journey_version=c0c7a22cae194e726b53c14780c6b13f。快照未附请求环境、获取时间与完整业务 URL，因此它能证明这份响应包含什么，不能单独证明当前 UAT/线上仍使用同一版本。实操时先记录 Network 中的请求环境、产品 ID、响应版本与登录状态，再到目标产品的 Admin 配置交叉核对。

例如只拿到“调整 SG PA 的投保人邮箱校验”这个需求，定位路径是 product_id → pages.pdp → blocks.fillInfo → entries.Policyholder_Info.Email。这份数据已给出邮箱的组件、字段路径、缓存键和校验项；下一步应查 FillInfo/表单实现、当前环境下发值以及最终请求，而不是先修改一个通用表单控件。pages 中的 props、block/entry 的 props 在这份响应里是 JSON 字符串，分析前需要解析，不能把它们误当成已经展开的对象。

5.3 模板如何解析并渲染 Journey#

这里说的是前端把 Journey 结构解析并映射成 React 组件的运行机制。它包括页面容器、Journey 解析、区块组件注册、动态表单、步骤与路由处理；与 Webpack 生成 HTML 使用的 templateKey: appHtml 分属不同层次。

图 5：产品工厂描述页面需要什么，前端代码实现这些能力，接口提供业务数据与校验结果。不同模板版本的实现路径略有不同。

用 PDP6 和 Purchase5 可以看到完整机制：

1. 确认产品和页面。 URL 中的 product_id 标识产品；PDP6 默认调用 queryFactoryProductDetail('pdp') 获取对应 Journey，Purchase5 调用 queryFactoryProductDetail('purchase', true)。同一个 HTML 可以服务不同产品。
2. 解析页面配置。 parseFactoryProductDetail 从 pages 中取出对应页面，把页面/区块的 props、字段的 field_name、dependencies、constraints 等转换成前端消费的数据。
3. 生成业务区块。 PDP6 的 useGenerateComponents 遍历 blocks，根据 component_name（兼容 name）查找同步注册的组件，或加载对应异步组件。例如 Header、Coverage2、FillInfo、FAQ 都是已经实现的 React 能力。
4. 生成字段并执行交互。 FillInfo 等区块继续消费 entries，结合 InsEntry 表单能力处理输入、字段值、联动与校验。Journey 描述选用哪些字段和规则，组件代码负责执行；配置里写一个名字，并不会自动生成尚未实现的新功能。
5. 编排步骤和下一页。 Purchase5 根据 stepItems 建立步骤，并通过区块的 forkey 归入对应步骤，由 PurchaseStepBar 控制前进和返回。next_route 等配置参与跨页面导航；一个 HTML 内也可能包含多个投保步骤。
6. 闭合业务数据。 输入需要按实现完成校验、转换和缓存写回，供确认页与 Checkout 消费；页面能显示字段，并不代表后端已经能收到它。

PDP6 使用 factoryV2/model/queryProductFactoryJourney.ts 和 Factory V2 的生成 Hook；Purchase5、Confirmation 中仍有对 factory/model 或 factory/hooks 的引用。新旧实现共存，定位时应跟随实际 import，而不是根据文件夹名猜测。

Purchase5 在解析 Journey 时传入 true，entry 的运行时 name 使用 field_name。排查联动时应核对表单实际标识，而不只看 Admin 中的 entry 名称。

5.4 导入配置与本地 mock#

图 6：Import Pages 提供批量调整页面 JSON 的入口。左侧是原始 Pages Data，右侧输入新的 Pages Data，下方先预览差异。适合在已有页面结构上调整多个节点；提交前要核对产品、环境、修改过的字段和未预期的差异，避免用旧快照覆盖他人刚更新的配置。导入后的保存、确认或发布仍按所在编辑视图执行，再以运行时 Journey 响应核实生效内容。

当前项目约定：

• Admin/O 端 UserJourney_*.json 是配置事实来源。
• 对应的 *.admin.journey.view.ts 从配置源生成，用于可读性 Review 和本地 mock。
• 本地 Journey mock 从 view 生成，避免再维护一份独立响应快照。
• O 端配置声明 external dependency 的类型和 parser；模拟后端补充的依赖数据留在本地 mock 层。

修改 Journey 时要同步源配置和生成的 view。找不到当前产品的配置时，应先取得有效配置来源，不能根据页面外观拼出一份“看起来合理”的配置。

图片使用经过指定上传流程得到的 CDN 地址；不把 Figma 临时链接或本地路径当作正式 Journey 图片。产品差异优先通过配置表达，配置确实不能承接时再说明代码适配的原因与范围。

5.5 数据闭环要在当前步骤完成#

新增字段时，至少追踪：输入值 → 校验结果 → 缓存位置 → 下游读取 → 展示值 → 请求值。

每个步骤负责把自己的输出处理成下游可直接消费的结构。不要把前序步骤遗漏的字段转换、默认值和业务规则统一堆到最后创单时补救。

项目已有存储工具和 Road Cache helper。阅读具体产品时还要核对缓存 key 与产品、流程、续保等参数的关系。返回修改、切换产品和重新进入，都可能暴露只验证单次向前流程时发现不了的问题。

前端售中流程页面缓存把售中缓存的主要用途归为表单回填和向 Checkout 交付试算/创单参数：新单由前序页面随操作组装，续保还需结合 policy_id 与原保单数据；Checkout 读取当前流程缓存。资料还区分“进入下一步时写入”与“校验成功后实时写入”，并指出公共参数只做 merge 容易留下旧值。SG PA 的 pdp 页面 props 中实际有 cacheOnFormEntryValidated=true，邮箱 entry 也指定了上述 cacheKey，因此验证邮箱改动要覆盖校验通过后的写入、返回回填、修改后的覆盖、Checkout 使用的值。

缓存资料中的 INSURANCE_CACHE_KEY_{user_id}_{product_id} 是当时的说明；当前 src/module/storage/helper.ts 的 getCacheKey 默认 custom_userid=''，从 road_cache_key 或 product_id 取产品标识，续保时追加 policy_id，并保留旧用户 ID key 的兼容迁移。排障时以运行时实际 key 和当前代码为准，不按旧文档的格式直接删除或断言缓存。资料提及的默认 30 天有效期也应由目标调用与当前存储实现核实，不作为所有产品的统一保证。

6. PFC：配置下发、灰度与版本同步#

产品工厂决定页面结构，PFC 为已实现的代码提供配置片段、命中条件和发布版本。本章独立走完从 Key 到页面生效的流程；处理 Transify 页面文案时，再结合第 7 章使用 PFC 的相应功能。

6.1 认识入口与核心菜单#

PFC 菜单截图：菜单由权限控制；若看不到某项，先核对账号权限及所选服务，不要据此判断功能不存在。

从仓库看，菜单分别注册在 src/components/Layout/config.tsx；Page V2 详情按区域展示 Condition List 和 Fragment List，Condition 含 page_path、region、app_type、white_list_key、params。这些字段共同决定“某页面向某用户下发哪份值”，Fragment 存在不等于当前页面一定拿到它。

6.2 从代码中的 Key 找到实际生效值#

PFC 的使用从“页面里哪个行为受控”出发。先在源码中找 PFC.getPFC('key') 的消费位置，读清楚返回值结构、缺省值以及何时读取；再确认目标服务、环境、市场和产品实际拿到什么配置值。项目通过 scripts/pfc.js 生成构建配置，config/webpack.config.js 使用 PFCSWebpackPlugin 注入相关配置，其中包含 BUILD_ENV、ENV、REGION 等维度。运行时仍要看真实下发值，不能仅凭后台表单或本地 JSON 判断命中。

例如，src/pages/factoryV2/common/tempInstallment.ts 同时读取 temp_installment 和 temp_installment_off 的 product_ids：目标产品在开启列表且不在关闭列表时，才启用对应展示。这说明“配置了开启列表”仍不足以断定该产品已命中；需要连同覆盖配置和代码条件一起检查。此例只用于说明查法，实施其他需求时应以它自己的 PFC key 和消费代码为准。

一个可操作的顺序是：确认 key 与代码条件 → 记录当前值和作用范围 → 准备目标值 → 在约定环境按团队流程配置 → 刷新并检查实际命中 → 验证开启/关闭两条路径 → 整理发布与回退信息。三个环境的入口见本章开头；当前账号权限、目标服务和审批状态仍需在平台核对。

PFC 系统分享把 PFC 解释为 Page Fragment Configuration：Admin 端管理 Schema、Fragment、白名单与发布，H5 端消费配置。Fragment 可承载 JSON、Transify/Transify Page、JS/CSS；后台支持 Diff、历史和回滚，白名单可按用户或比例做灰度。资料说明页面配置可在 HTML 返回前通过服务端嵌入，Webpack 插件生成本地/构建兜底数据，H5 再通过 SDK 读取。因此修改后还要分清发布目标、灰度命中、页面实际加载的配置与兜底值，不能以后台已保存作为生效证据。分享材料没有提供这份 SG PA 响应对应的 PFC key 或当前值；它的 is_user_whitelist=true 也不能替代 PFC 命中验证。

6.3 一次配置需求怎样走完#

1. 定对象。 先在 H5 源码查读取位置、默认值和分支条件，记录 PFC Data Key；再确定 Test/UAT/Live、服务、市场和目标 Page Path。同名 Key 的其他环境值不能当作本次结果。
2. 看生效条件。 在 Fragment V2 查看配置类型、Publish Type（Only Page / Only CDN / Page And CDN）与 Condition；到 Page V2 对照页面绑定，涉及灰度时再到 White List V2 核对 User ID 或取模规则。用一个命中用户和一个未命中用户列出预期结果。
3. 准备差异。 编辑前保存当前已发布值和条件；修改后检查 Diff、数据结构、受影响页面和复用方。Schema Management 解决编辑复杂值的表单表现，不会替代码补出尚不存在的消费逻辑。
4. 按版本发布。 当前仓库的 Fragment V2 Submit 调用 publishConfig 保存发布快照；面向所选 Condition/Page 的 Batch Push 另调用 batchPushPage，按 Publish Type 还可能发布到 CDN。SPIN 服务的提交流程会选择版本；某些环境还可能有审批。应以界面状态、版本和发布结果为准，不能把“Save/Submit 成功”当成页面已生效。
5. 验证与回退。 打开目标 H5 的完整业务 URL，核对 HTML 中的配置、运行时读取值和最终页面行为；同时验证未命中路径。保留旧值、目标页面、名单和版本，出问题时按当前环境的历史/回滚流程恢复并重新验证。

6.4 为什么打开 H5 就能读到 PFC#

PFC 分享资料描述了页面发布路径：配置发布到页面值后，服务端通过 OpenResty、SSI 和 Lua 在返回静态 HTML 时嵌入对应片段。pfc 仓库的 src/common/utils.ts 会把 JSON 片段生成类似 <script>window.PFC.__savePFC__("key", value)</script> 的内容；外链类型则生成带 src 的脚本或样式标签。H5 启动前已拿到的片段会进入全局 PFC 实例，业务代码再调用 PFC.getPFC('key')。项目构建中的 PFCSWebpackPlugin 还涉及本地/构建兜底数据；不同发布类型不保证都以同一种内联脚本出现。

HTML 注入截图：在浏览器 Elements → head 可以看到 window.PFC.__savePFC__ 调用。截图中的 pcOn、ahTransify、userGlobal、nonmotorMigration 是该页面收到的配置 Key；看到某个 Key，只能说明它进入了页面，不能直接推断 SG PA 产品满足该 Key 的业务条件。

Console 检查截图：可查看 window.PFC 与 PFC.__store__ 来定位页面实际持有的数据；__store__ 是调试时观察到的内部结构，业务代码应继续使用 PFC.getPFC，不要直接依赖内部存储字段。

排障时按顺序查：① Elements 中是否有目标 Key 的注入脚本或外链；② Console 中读取 PFC.getPFC('key') 是否得到预期结构；③ 代码中的产品 ID、默认值和覆盖条件是否真正命中；④ 页面展示及请求是否随之改变。若后台值与 HTML 不同，优先核对环境、Page Path、发布类型、Condition、白名单、版本和页面缓存。SG PA Journey 的 is_user_whitelist 是产品工厂响应字段，不能据此证明 PFC White List V2 命中。

6.5 Version Center：配置怎样跟随版本进入下一环境#

PFC 的版本用来归集一次迭代提交的 Fragment 变更，并跟踪它们在环境间的同步状态。它与 Casement 的迭代及 H5 release-v1.x.xxx 分支需要对应核对，但PFC 同步配置不是部署 H5 代码。下图是 Version Center 的示例：上半部分按 Release Gantt 展示发布批次、Release Branch、包含的版本和同步摘要；展开后可以看每个版本的状态。下半部分是某个版本的 Fragment History 和同步前差异检查。

1. 在 Release Gantt 找到当前迭代的 Release Branch 和版本；也可用 Pending / All Versions 及 Version Name、Sync Status 筛选。批次可能包含多个版本，先确认目标版本，不要只看分支名。
2. 展开批次查看各版本的 Sync Status / Sync Result。Pending、Not Synced、Sync Partially 都不是全量同步成功；需要点开结果查未完成或失败的 Fragment。
3. 在非 Live 环境点击单版本 Sync 或批次 Sync Batch To 下一环境。弹窗按版本列出待同步 Fragment；先看 Step 1 当前环境版本前后对比，再看 Step 2 下一环境应用前后对比，最后检查可编辑的 Step 3 最终推送数据。共享配置或目标环境已有改动时，差异审核尤其重要。
4. 确认范围后用 Sync Current / Sync Selected / Sync All 同步当前、已选或全部 Fragment。Ignore 会将当前 Fragment 标为已处理但不推送；“同步白名单”开关也需要按需求决定。操作结束再检查每个 Fragment 的结果，并在目标环境重新打开页面验证 HTML 中的 PFC 值和文案。

截图中的版本号和状态仅用于理解界面，不代表当前迭代已同步。执行顺序仍是：确认迭代版本 → 提交与发布目标环境的 Fragment → 审差异并同步到下一环境 → 检查结果与真实页面；进入 Live 前遵循团队发布流程。

7. Transify：让多语言文案从 Key 走到页面#

接手一个“改文案”的需求，先分清 H5 调用、Transify 翻译值、PFC 页面下发 三件事。翻译人员在 Transify 填完文案，不表示用户页面已经更新；前端代码出现一个 Key，也不表示该页面的所有路径都会用到它。

7.1 H5 怎样取到翻译#

页面和组件里的可翻译文案使用 formatMsg。例如 PDP6 的标题有 formatMsg('factorypdp.productdetail') 兜底，其他组件也通过它获取按钮、提示和错误文案。需要插入变量时传第二个参数；翻译 value 中的 {name} 或 {{name}} 会按同名参数替换。

formatMsg('common.coupon.sgmaid', { discount: '30%' });

src/locales/index.ts 将 formatMsg 交给 src/locales/i18n.ts；后者读取 PFC 的通用 transify 和当前路径的 transify_page_${location.pathname}，页面级值覆盖通用值。查找时先尝试市场前缀 Key（如 SG.xxx、sg.xxx），再查原 Key。因此“Transify 平台有值”与“当前市场、页面拿到值”要分别核对。产品工厂 Journey 中配置的 Key 最终也需要由对应渲染逻辑取译文；不能仅凭配置字段的名字断定它已被翻译。

本项目的 H5 多语言文案应通过 formatMsg 接入。不要把某一市场的中文或英文直接写进共享组件，也不要用原始 Key 在页面上长期代替翻译。缺失翻译时，代码会按市场和环境回退成 Key、带方括号的 Key、末段名称或空串，页面“看起来有文字”并不能证明翻译已经下发。

7.2 本地打开自动采集#

在 ins_h5 仓库执行 npm run dev，交互项依次选择开发 → test（或目标 UAT）→ Transify usage 上报 on → 目标地区 → 目标服务。要调 Nonmotor 就选 nonmotor；若需要同时访问多个应用，可按场景选 all。下图是团队提供的启动示例，重点是第三项选 on。选择会写入本地 .env 的 TRANSIFY_REPORT，重新启动时检查当前值，不要只凭上一次终端选择记忆。

然后用已配置代理的完整业务 URL 打开目标页面，实际走到需要文案的交互分支。formatMsg 执行时，非 Live 的 Test/UAT 构建会记录该 Key；当 TRANSIFY_REPORT=on，且不是 Admin/自动化排除场景时，src/locales/report.ts 用 navigator.sendBeacon 向 PFC Test 的 /api/nologin/transify_usage/report 上报 Key、市场、location.pathname 和可能的版本号。它有去重与批量发送；只浏览首屏，不能采集尚未渲染的弹窗、错误提示或后续步骤。sendBeacon 返回成功只表示浏览器接受发送请求，仍应去 PFC 查记录。

7.3 从 Usage 到页面翻译 Fragment#

到 PFC 的 Transify Usage 菜单，用 Region、Path Name、Transify Key、Version 筛选刚访问的页面。这里展示的是使用记录，不是翻译 value。PFC 的同步流程按页面路径整理使用过的 Key，创建或更新该市场的 transify_page Fragment，显示名使用 [page_name]_auto_collect_transify_page 规则；实际生成逻辑会将路径中的 / 替换为 _、去掉 .html，因此查找时要同时核对原始 Page Path 与 Fragment 名。同步还与版本关联，访问页面后的 usage 记录和页面 Fragment 更新是两个阶段。

如果 Usage 已有 Key、Fragment 却没有，先检查市场、页面路径、版本和同步结果，不要在 Transify 平台重复造 Key。反过来，Fragment 中有 Key，也不保证这个分支在本次访问中执行过。

7.4 填写 value 后在 PFC 推送#

开发者或本地化负责人在 Transify 项目资源 补齐目标语言 value，保留与代码参数匹配的占位符。接下来先决定按 Fragment 处理，还是按页面刷新。下图上半部分以 _common_policy-list_auto_collect_transify_page 为例，下半部分以 /common/policy-list.html 为例；它们展示 PFC 的两种操作入口，不是 SG PA 页面的实际配置。

如果同一 Fragment 还绑定别的页面，页面级刷新会提示跨页面影响，需要先核对范围；没有绑定的 Transify Page Fragment 时无法刷新，应回到 8.3 节完成 Usage 到 Fragment 的同步。手动发布时也要检查所选页面条件，避免把共享 Fragment 推给非目标页面。

不要把“Transify value 已保存”“PFC Fragment 已更新”和“H5 已显示新文案”当作同一个状态。PFC 的目标环境、服务、页面路径、版本及当前用户看到的 HTML 都要一致；Live 还需遵循既定发布与审批流程；配置跨环境同步见第 6.5 节。

7.5 用一个页面验证整条链路#

以 SG PA 的 /nonmotor/factory-pdp6.html 为查找示例，先在代码中找到目标 formatMsg Key，再在页面实际触发它。依次检查：

1. 采集： 本地 TRANSIFY_REPORT=on，PFC Test 的 Transify Usage 能按 SG、该 Path Name、Key 查到记录；只出现使用记录时不要宣称 value 已发布。
2. 配置： 页面绑定的 transify_page Fragment 含该 Key，Transify 已填对应语言 value，PFC Page V2 的 Update Transify 已按目标 Region/版本完成且没有失败项。
3. 下发： 重新打开业务 URL，在 Elements 或 Console 检查该页面的 PFC 翻译数据；PFC.getPFC('transify') 与 PFC.getPFC('transify_page_' + location.pathname) 能帮助区分通用值与页面值。
4. 展示： 切到目标语言、触发目标分支，核对文案与占位符；同时检查同一共享组件的其他产品、市场是否受到影响。

页面内快速查 Key（非 Live）： 在页面的 PFB 调试入口打开 Select PFB 抽屉，截图中的 Transify Debug Mode 与 Transify Key Panel 是同一抽屉里的两个工具。前者开启后会刷新页面，把经 formatMsg 渲染的文案显示为 [key]，方便直接对照页面位置；它用当前会话的 transify_debug 标记控制，调试完成再点一次关闭并刷新。看到 [key] 是调试模式的预期效果，不能据此判断翻译缺失。

Transify Key Panel 可搜索、复制当前页面已执行的 formatMsg Key，并标出当前下发翻译中该 Key 是否有非空 value。它只统计实际走到的代码分支；弹窗、错误态和后续步骤要触发后再查看。这个面板用于定位 Key 和检查当前页面数据，仍需按上面的采集、Fragment、下发与目标语言展示四步确认需求完成。截图是调试状态，不代表正式用户看到的文案。

若页面仍是旧文案，优先按 Key/语言 → Usage → Fragment 与页面绑定 → 版本与推送结果 → HTML/PFC 实际值 → formatMsg 调用分支 逐层定位。动态拼接的 Key、未触发的分支和被产品工厂配置直接写死的展示文本，需要额外检查，不能仅依赖一次自动采集。

8. AI 协作：准备输入、选择 Skill 与检查产物#

ins_h5 和 nonmotor_h5 当前各有 50 个 .agents/skills/spin-fe-*/SKILL.md，名称与文件内容一致。它们把常见工作拆成可执行的任务流程：分析需求、查询产品配置、生成代码、准备与执行自测、排查监控、Review 和交付。接手 nonmotor 需求时，按任务选择当前仓库的 Skill；平台入口、产品事实和最终验收仍要由负责人确认。完整触发条件以当前仓库的 SKILL.md 为准。

8.1 给 AI 的输入要覆盖开发上下文#

可以使用下面的任务描述模板：

请在 nonmotor_h5 中协助完成以下需求。
市场、环境、构建环境：……
产品与完整页面入口：……
需求正文、设计来源：……
当前 Journey 来源、版本与修改前快照：……
相关 PFC key、当前生效值、目标值及命中范围：……
接口协议、字段与业务码：……
预期交互、错误和返回行为：……
影响范围与不应改动的部分：……
验收场景：……

先判断 Journey、PFC、翻译、接口与代码的改动边界，列出影响范围和数据流；
按仓库 AGENTS.md 与本地 Skills 实现，分别报告代码检查、实际运行验证和未解决项。

仓库已有需求分析、TD、代码生成、Journey 查询/更新、mock、UI 验证、Runbook 和代码 Review 等 Skills。根据任务选择相应入口，编码前仍需应用完整工程规范。开发者应亲自确认业务规则、Journey/PFC 的实际生效范围、App 内结果与发布依赖；AI 的代码生成和静态检查无法单独证明这些结论。

8.2 从需求到交付，怎样选择 Skill#

实际需求先确认产品和接口契约，用只读 Skill 查当前 Journey；需要设计时生成 Journey TD，再交给 AI 实现，并用目标产品的真实页面和请求验收。只有明确要更新 Admin Journey/i18n 时，才进入配置写入 Skill 的差异预检与发布流程。PFC 当前没有单独的 spin-fe-pfc-* Skill；按第 6.2 节从消费代码找 key、核对生效值与命中条件，代码变更继续遵循通用工程规范。

8.3 AI 产物需要检查哪些边界#

工程细节由当前仓库的规范 Skill 约束。开发者 Review 时，重点检查这些会直接影响需求交付的边界：

新增、生成或修改业务代码时，仍按仓库的完整工程规范执行。这里保留 Review 关注点，具体目录、React、样式和接口写法由相应 Skill 提供。

8.4 开发埋点并交接 BI#

埋点由开发在开发阶段主导，随功能代码一起实现。 项目代码生成规范已要求检查埋点：新增页面或改变组件、交互、展示行为时，按 spin-fe-tracking-development 核对页面初始化、每个用户点击和一级业务模块曝光；已有 TMS 定义时优先遵循已确认的名称与参数口径。页面入口只初始化一次；点击在对应回调中上报一次；曝光应稳定，避免重复渲染造成重复上报。page_type 和 URL 自动填充的公共字段不要在事件里重复传入。

这项工作从编码一直延续到 BI 接收，按以下顺序交付：

报告不能只列“本次新增的几条”：BI 需要看到受影响页面当前实际会产生哪些事件，也需要分清新埋点与已有埋点。埋点报告 Skill 规定了报告范围和格式；“开发输出 → BI Review → BI 录入 TMS”是当前团队交接流程。

性能链路按项目约定覆盖 JS_START、BEFORE_MAIN、AFTER_MAIN、RENDER。业务异常使用带稳定 unique_key 的日志，记录定位所需上下文，避免静默吞错或记录凭证、敏感表单原文。

9. 联调与排障：真实接口、App 流程与 Mock#

自测按“目标页面交互 → 真实接口 → App 主流程 → 复用方回归”逐步完成。检查范围由需求决定，已有证据通过后不必重复扩大测试。

9.1 先分清在哪一层失败#

先按第 3 章选择调试环境：浏览器用于快速定位 H5 问题，模拟器配合 Safari 检查 App 内 H5，真机优先用于完整主流程自测。涉及支付、OTP 或地址选择等 App 页面时，不能以浏览器验证代替 App 链路验收。

先复现并确认请求、响应和状态，再决定改动层次。不要因为错误出现在页面上就直接修改组件。

9.2 Mock 与真实联调#

Mock 用于接口未完成时的并行开发，以及稳定复现空数据、异常和特定分支。响应需要遵守真实契约，并把作用范围限定到目标接口/产品。

下面两种方法都在网络响应层临时替换接口返回，适合调试 query_product_factory_journey 这类请求；与第 5.4 节从 Journey 配置源生成的仓库本地 mock 不同，不会修改产品工厂或后端的真实数据。

用 Whistle 替换响应#

按第 2.4 节启动 Whistle，并确认浏览器或设备流量确实经过 127.0.0.1:8899。打开 http://127.0.0.1:8899/#network，在 Network 中找到目标请求，例如当前 SG PA 页面的 query_product_factory_journey，右键选择 +Rule → Response。在弹出的规则编辑器中核对 URL Pattern，勾选 Modify Response Body，选择 Replace Body，通过 + File 准备本地 JSON 响应，最后点击 Save As Rules。回到页面重新触发请求，在 Whistle Network 中确认命中该规则，检查返回体和页面行为。规则预览中通常可以看到对应的 resBody 映射；Whistle 响应体规则说明。

这条规则对经过 Whistle 且匹配 URL Pattern 的请求生效，因此可以用于已配置代理的浏览器、模拟器或真机。图中的 resBody 是收到后端响应后再替换响应体；如果接口尚无可用响应，需改用直接返回本地内容的 file 规则或项目已有的本地 mock 服务。匹配范围应尽量限定到目标环境、域名和接口；验证结束后停用或删除规则，避免后续联调继续读到旧数据。

用 Chrome DevTools 覆盖响应#

在 Chrome 打开目标页面和开发者工具，进入 Network → Fetch/XHR，找到目标请求并右键选择 Override content。首次使用时，按提示选一个存放 Overrides 的本地文件夹并授权；DevTools 会在 Sources → Overrides 打开该响应的副本。修改并保存 JSON 后刷新页面，回到 Network 的 Response 核对实际覆盖结果，再检查页面表现。Chrome 的本地覆盖说明也给出了 XHR/fetch 响应的操作步骤。

这种方式适合只在当前 Chrome 浏览器快速试一个返回值，无需改 Whistle 规则；它不会替代模拟器或真机里的请求。结束后到 Sources → Overrides 关闭 Local Overrides，避免下一次刷新仍使用本地副本。

无论选哪一种方式，都先保留原始响应，只改本次要验证的字段，保持 code、data、字段类型和嵌套结构符合接口契约。自测记录里注明被替换的接口、mock 文件/规则、验证场景和实际响应；接口可用后再关闭 mock，用真实请求复验。

验证记录应写清哪些结果来自 mock、哪些已经通过真实接口。Mock 成功只能证明页面在该响应下的行为；真实登录、网关、PFB、后端校验和 App 行为需要相应环境的证据。

10. 交付与发布：BI、MR、Casement 与验收#

本章接续第 4 章的迭代分支流程：本地自测完成 → 提交 MR → Review 与合入 → 按团队流程提测/发布 → Casement 部署 → 检查实际页面。代码、配置与接口是同一次交付的组成部分。

10.1 准备 MR 与 QA 交接资料#

MR 描述应包含业务问题、最终行为、影响页面/产品/市场、代码与配置改动，以及验证结果。涉及公共能力时列明调用方影响，涉及协议时说明字段变化。

涉及页面、组件或交互变化时，MR 还应链接开发生成的埋点文档，说明 BI Review、TMS 录入与实际上报验证的状态；未完成项明确负责人和后续动作，避免埋点代码已合入但定义与文档未对齐。

提交前检查：有无无关文件、临时日志、账号或凭证；新增类型与真实数据是否一致；配置与 mock 是否按约定同步；自测是否覆盖用户回退和错误路径。

给 QA 的交接资料应包含完整入口、市场/产品、环境与版本、账号获取方式、需求范围、验收场景、自测结果及已知限制。验证记录格式见第 9 章。

10.2 前端交付物不只有代码#

物料范围按实际产品和市场确定，不照搬 Admin 后端所有物料全地区同步的要求。

10.3 在 Casement 部署迭代版本#

部署前先完成第 4.5 节的开发、自测、MR 合入与发布流程。然后在 Casement 中选择 nonmotor_h5 应用，进入对应 release-v1.x.xxx 迭代，部署该迭代对应的分支代码版本。

图为用户提供的 release-v1.3.318 Test 环境示例。使用时替换为当前迭代和目标环境，不直接沿用截图中的版本、PFB 或部署状态。

操作顺序：

1. 在 My Application 中选择 nonmotor_h5，进入本次迭代的 release 页面。
2. 确认当前环境，并检查本次需求需要的配置、Release Note 等发布物料。
3. 在 Deployment → Service Deployment 中找到目标服务，使用 Deploy 进入部署操作，核对本次版本和目标环境后提交。
4. 在部署记录中核对 Region、Env 和 Parameters (Git/PFB/ImageTag)，确认版本、PFB 与本次联调或验证计划一致。
5. 观察 Status，必要时通过 Detail 查看详情。deploying 表示仍在部署，不能视为完成；部署成功后再验证目标页面及业务链路。

MR 合入、版本发布、部署成功和业务验收分别是不同检查点。部署记录中的 Git/版本、PFB 和镜像信息应与预期对应，避免代码已合入但实际验证的仍是其他版本。

部署负责人、审批要求，以及发布版本/Tag 的具体生成操作仍需按团队约定补充。截图中的 Rollback 是平台入口，实际回滚前仍需检查代码与配置的兼容关系。

10.4 构建产物与市场范围#

deploy/nonmotor.json 定义了 nonmotor 部署模块。deploy/space_build.sh 读取部署环境中的 CID 作为 REGION，并设置 APP_NAME 进行构建；产物目录为 dist/nonmotor，部署使用 /nonmotor/ 页面路径，静态资源路径也包含环境和市场信息。

这意味着发布时要核对目标市场与应用，不能仅凭某一次构建完成就认定所有市场都已覆盖。Casement 的一条部署记录可以包含多个 Region，也可以只包含一个市场；以本次选择和部署结果为准，不要求开发者机械地逐市场点击部署。

10.5 发布顺序与回退#

发布前把代码、配置和接口依赖放在一起 Review。例如，Journey 引用了新组件时，需要确保目标代码包能够加载它；接口字段变化时，需要确认前后端版本组合的兼容性。

回退方案也要覆盖配置和接口配套关系。不能只回退前端包，却保留仅新包能处理的 Journey。

上线后检查目标入口、主流程、资源加载、业务错误和关键埋点。监控与验收范围应对应本次改动的市场、产品和场景。

10.6 交付前的完成检查#

完成第一个需求时，逐项检查以下结果；“代码写完”只是其中一部分。

• 能说明目标产品的页面链路，并从 URL 定位到入口与业务代码。
• 找到当前产品实际生效的 Journey、相关 PFC key 与值，并明确配置、代码和接口各自的改动范围。
• 涉及多语言时，已核对目标语言 value、页面 Transify Fragment、实际下发与展示结果。
• 用户输入、校验、缓存、确认展示和最终请求相互一致。
• 正常、异常、返回、重进以及受影响产品已按范围验证。
• 类型、lint/格式和目标构建的结果已记录，阻塞项说明准确。
• 受影响页面的埋点已随代码实现并验证；埋点文档已交 BI Review，TMS 录入与复核状态清楚。
• MR、QA 验证资料和配置/翻译/图片等物料齐全。
• 已明确发布依赖与回退方式，Review 后按团队流程交付。

11. 补充内容#

前面的章节已经走完日常开发闭环。本章简要区分几个接需求时常遇到的控制点：市场和产品差异、灰度与放量、埋点与日志。具体命中范围仍以当前代码和目标环境的实际配置为准。

11.1 差异化开发#

市场差异：构建时选择代码。 下图是 src/pages/checkoutV2/App.tsx 的实际片段：/* #if (REGION == 'th' || REGION == 'ph' || REGION == 'sg' || REGION == 'id') */ 到 /* #end */ 之间的优惠券入口逻辑，只进入条件命中的市场构建产物。项目的 config/webpack/conditionLoader.js 在构建时根据 REGION 处理这些标记；它不是页面打开后再判断市场的运行时 if。修改这一块时，先确认目标市场是否在条件内，再检查对应市场的构建和实际交互；公共逻辑放在条件块外时，也要评估其他市场。

产品差异：同一市场下选择产品配置。 下图展示 src/pages/factoryV2/pdp/config/my/ 按产品 ID 拆分的文件，以及某个产品提供的 bottomBarConfig、queryUserInfoConfig。入口 config/my/index.ts 从 URL 的 product_id 加载对应文件，PDP 的 config/index.ts 再将市场/产品配置与基础配置合并，供共享组件消费。这类配置用于产品特有的数据预处理、接口查询或底部栏行为；若需求可以由 Journey 的 Page/Block/Entry 和现有 props 表达，应先走产品工厂配置，只有共享能力无法覆盖时才检查是否需要这种代码级差异。改动后要核对当前产品 ID、目标市场、默认配置及同市场其他产品的行为。

这两张图说明的是不同的选择时机：REGION 条件编译决定代码是否进入某市场的构建产物；按 product_id 加载的配置决定同一市场内某个产品如何使用共享 PDP 能力。截图中的产品文件只是代码结构示例，不代表所有产品都必须建专属配置文件。

11.2 配置与上线控制#

11.3 观测与排障#

这几类能力控制的对象不同：条件编译影响市场构建产物，产品配置影响某个产品的页面行为，灰度与放量影响开放范围；TMS 和 IDAP 分别帮助核对用户行为上报与运行问题。Transify 的操作链路见第 7 章。

附录 A：团队操作信息待补充#

这些信息影响实际操作，在确认前不将示例或历史约定作为当前流程：

附录 B：依据与维护范围#

主要核对文件：.nvmrc、package.json、scripts/prompt.js、scripts/start.js、scripts/create-template.js、config/bizConfig.js、config/paths.js、config/webpack.config.js、config/nonmotor/my.json、deploy/nonmotor.json、deploy/space_build.sh、deploy/space_install.sh。

页面与数据流依据：src/pages/factoryV2/purchase5/index.tsx、App.tsx、src/pages/factory/model/queryProductFactoryJourney.ts、src/common/request.ts、src/common/nonmotor.ts、src/module/storage/helper.ts、src/InsEntry/validate/email.ts。

页面入口介绍补充核对：config/nonmotor/my.json、config/nonmotor/sg.json、config/common/my.json、config/ec/my.json、config/bizConfig/my.json、src/pages/factoryV2/pdp/index.tsx、src/pages/factoryV2/pdp/App.tsx、src/pages/factoryV2/model/queryProductFactoryJourney.ts；配置组装和输出规则核对 config/bizConfig.js、config/webpack.config.js 与 config/paths.js。common 应用的仓库维护约定来自团队提供的页面注册截图。

项目介绍补充核对（2026-10-10）：Motor 流程基于 ins_h5 当前工作区的 config/bizConfig/{region}.json，以及 src/pages/id/motor/carPdp/components/GetQuoteBtn/index.tsx、quote/components/QuoteAddonPanel/index.tsx、quote/components/BottomBar/index.tsx、confirmPersonalInfo/components/ConfirmBtn/index.tsx；MY 的 carPdp/components/BottomBar、quoteList/App.tsx、common/components/QuoteCard、quoteDetail2/components/BottomBar；SG 的 carPdp/components/BottomBar、quoteList/components/QuoteCard、quoteDetail/components/BottomBar、quoteAddOn/components/BottomBar、applicationForm/App.tsx。上述 MY/SG 路径分别以 src/pages/my/、src/pages/sg/ 为前缀。

Nonmotor 复用机制基于 nonmotor_h5 当前工作区的七个 config/nonmotor/{region}.json、src/pages/factoryV2/hooks/useGenerateComponents.tsx、model/queryProductFactoryJourney.ts、pdp/syncComponents/index.ts、pdp/config/pdpConfig.tsx、purchase5/App.tsx、purchase5/config/index.ts、confirmInfo/App.tsx，以及 src/pages/factory/model/queryProductFactoryJourney.ts、src/pages/checkoutV2/App.tsx 和 model/{region}。Factory V2 的缩略路径均以 src/pages/factoryV2/ 为前缀。组织方式的业务原因结合团队本次说明整理；流程图是源码导航与配置的教学示意，未冒充所有市场产品的端到端实测结果。

PFC 使用路径补充核对（2026-10-14）：nonmotor_h5 的 scripts/pfc.js、config/webpack.config.js、src/common/pfc.ts、src/pages/factoryV2/common/tempInstallment.ts 和 src/pages/factoryV2/pdp/config/productConfig.ts；pfc 仓库的 src/components/Layout/config.tsx、src/common/utils.ts、Fragment/Page/Whitelist V2 页面、ConditionDetail、Version Center 与发布 service。PFC 三个入口及菜单、HTML 注入、Console、Version Center 截图由团队提供；测试环境网页在本机访问时被 Whistle 转发到未启动的本地服务，因此本文的菜单和流程依据源码与截图整理，没有把现场登录或发布结果当成已验证事实。

SG PA 示例与参考材料补充核对（2026-10-14）：团队粘贴的 query_product_factory_journey 响应快照（产品 2044008389641503267）、PFC 系统分享、产品工厂分享和前端售中流程页面缓存。缓存键另对照 nonmotor_h5/src/module/storage/helper.ts 与 constant.ts 的当前实现。响应快照未提供环境与获取时间，三篇分享材料也不证明 SG PA 当前 PFC 值或真实下单结果；这些仍需运行时核对。

开发规范依据：本仓库 AGENTS.md 及 .agents/skills/ 下的工程、Journey、Service、React、样式、MoneeDesign、运行时集成与埋点规范。后续维护应以当前源码和规范为准。

Transify 与版本流程补充核对（2026-10-14）：ins_h5/nonmotor_h5 的 scripts/prompt.js、src/locales/index.ts、i18n.ts、report.ts，以及 pfc 的 Transify Usage、src/app/service/transify/index.ts、Fragment V2 的 Submit/Publish、Page V2 Update Transify、pfc-version/page.tsx 与 PatchFragmentModal。Transify 平台链接、启动与更新截图，以及 PFC Version Center 截图由团队提供；本文没有登录 Transify 平台，也没有实际写入翻译、推送 PFC 配置或执行跨环境同步。

Skills 章节补充核对（2026-10-14）：逐一比较 ins_h5 与 nonmotor_h5 的 .agents/skills/spin-fe-*/SKILL.md，两边当前各有 50 个文件，文件名和内容一致。第 8 章仅介绍常用任务入口和职责边界；具体触发条件与执行限制以工作时所在仓库的 Skill 为准。

文档编排参考：admin后端开发流程，内容由用户提供的 HTML 读取。代理章节结合用户材料、ZeroOmega 安装页和随文引用的 Whistle 官方说明整理。本文未执行真实产品配置修改、业务操作或发布，也未代用户安装插件、根证书或切换代理。

分支及部署流程依据：用户确认的 dev-v1.x.xxx → release-v1.x.xxx → Casement 部署 流程，以及随文保存的 Casement 截图。截图仅用作操作位置说明，不作为当前部署结果或权限状态的证明。

模拟器流程依据：用户提供的模拟器安装截图，以及随文引用的 Apple 和 Whistle 官方说明；内部下载入口来自截图正文，版本与页面可用性未独立验证。

附录 C：市场代理规则#

以下按用户提供的域名整理，保留原有整站转发意图，目标统一为本地 HTTP 3000 服务；没有实际联网验证这些业务域名。每个市场/环境单独保存为规则组，按本次开发选择启用，不要把所有环境同时指向一套本地构建后混用。

# BR UAT
protection.uat.shopee.com.br http://localhost:3000

# TH Test
protection.test.shopee.co.th http://localhost:3000

# TH UAT
protection.uat.seainsurebroker.co.th http://localhost:3000

# SG Test
test.moneeinsureagency.sg http://localhost:3000

# SG UAT
uat.moneeinsureagency.sg http://localhost:3000

# MY Test
protection.test.shopee.com.my http://localhost:3000

# MY UAT
protection.uat.shopee.com.my http://localhost:3000

# VN Test
insurance.test.shopee.vn http://localhost:3000

# VN UAT
insurance.uat.shopee.vn http://localhost:3000

# ID Test
insurance.test.shopee.co.id http://localhost:3000

# ID UAT
insurance.uat.shopee.co.id http://localhost:3000

# PH Test
protection.test.moneeinsurebroker.com.ph http://localhost:3000

# PH UAT
protection.uat.moneeinsurebroker.com.ph http://localhost:3000

整理时处理了以下重复与不一致：

• PH Test 原材料中的整组规则重复出现，合并为一组。
• 已有整站转发时，保留路径的子目录规则合并到整站规则，覆盖原有 /ins、/nonmotor、/common、/ec 和 /static 等请求。
• PH UAT 原材料中 /ins/ 同时指向 /ins 和根路径，/common/ 也指向根路径。此处统一保留完整路径，与本地 /应用名/页面.html 的构建结构一致；不保留去掉应用前缀的目标。
• 目标显式补充 http://，源域名仍支持业务 HTTPS 请求经 Whistle 解密后转发到本地 HTTP 服务。

附录 D：Motor 市场流程与目录详解#

本附录供需要对照车险页面的同学深入阅读。第 1 章讲业务差异；这里保留 ID、MY、SG 的具体链路、团队目录截图，以及七个市场的入口示例。源码中存在历史与可选分支，表格不代表所有产品的固定步骤。

ID：车辆与报价逻辑分开，附加保障作为报价页分支#

当前 id/motor/ 的主链路可以沿以下页面阅读：

car-pdp.html → quote2.html → confirm-personal-info2.html → checkout.html

车辆品牌和地区选择也有独立入口，例如 car-information.html、region-code-selector.html。这些是用户操作触发的辅助页面，不是每次投保都要依次经过的主步骤。

MY：从车辆信息获取报价列表，再进入报价详情#

当前汽车报价路径可读作：

car-pdp.html / car-pdp2.html → quote-list.html → quote-detail2.html → checkout.html

PDP 的 my/carPdp/components/BottomBar 进行预检、请求报价卡片，并把车辆信息和报价结果写入缓存；my/quoteList/App.tsx 读取缓存并展示卡片；my/common/components/QuoteCard 进入报价详情；my/quoteDetail2/components/BottomBar 处理进入 Checkout 前的业务逻辑。

报价详情还可打开 vehicle-info.html 修改车辆信息。摩托车与部分历史路径存在分支，例如 motorcycle-quote-list.html、quote-detail.html，因此不能把汽车示例原样套到所有 MY Motor 产品。

SG：报价详情之后，按保障内容决定是否进入 Add-ons#

SG 的报价列表路径可读作：

car-pdp.html → quote-list.html → quote-detail.html → [quote-addon.html] → application-form.html → checkout.html

sg/quoteDetail/components/BottomBar 根据当前方案的可用附加保障计算 hasAddOns：有附加保障时进入 quote-addon.html，否则直接进入投保表单。PDP 还保留进入 quote.html 等路径，续保也有专属分支；上面的列表路径用于说明当前代码中的一种业务编排。

这类差异解释了为什么不能简单把某市场的 Motor 页面复制后只换翻译：页面拆分、字段、报价前提、附加保障、缓存结构与下一步条件都可能变化。

不同市场的入口目录#

团队提供的目录截图：src/pages/id/motor/ 集中放置 ID 的车险主流程页面；其他市场在各自目录维护。截图中同时能看到 factory、factoryV2 和 checkoutV2，分别对应产品工厂模板与收银台。

以下是当前 config/bizConfig/{region}.json 已登记的代表页面，不表示它们全部属于同一条顺序流程。