本项目并非一次单纯的 App 翻译或页面国际化改造，而是围绕现有家用健康类智能硬件产品体系， 在国际化适配、智能硬件集成与数据合规架构三个方向上同步推进的综合建设工程。 本章先建立对项目背景、建设目标、项目范围与首发市场及目标时间的整体认知， 后续章节再对三个项目分别展开完整方案。

1.1项目背景

家用健康类智能硬件与配套 App 已成为慢病管理与家庭健康监测的重要入口。 现有飞利浦灵析家用医疗设备 APP（以下简称「飞利浦灵析 APP」）已在国内完成开发并上架应用市场，面向家庭用户， 通过蓝牙连接血压计、体温计等智能医疗设备，将设备检测数据同步至 App， 并完成健康数据的展示、记录与管理。现阶段产品已完成以下核心能力的建设：

• 账户能力：用户注册与登录、用户资料与账户体系；
• 设备能力：智能设备连接、设备绑定与管理、设备检测数据同步；
• 数据能力：血压、体温等健康数据的展示、记录与历史查询；
• 家庭能力：家庭账户、家庭成员数据查看；
• 智能能力：AI 健康助手；
• 内容能力：产品及设备信息展示；
• 运营能力：管理后台与基础运营数据统计。

随着品牌方国际化战略推进，需要将国内版核心能力延伸至海外市场，第一阶段面向 中国香港、中国澳门、中国台湾地区（以下统称“港澳台地区”），并具备向东南亚等市场延展的架构基础。 首发版本规划支持简体中文、繁体中文与英文三种语言，首发阶段完成 5 款智能医疗设备的连接适配， 后续扩展至 13 款或更多设备型号。

与此同时，智能硬件产品线的持续扩展带来两项新的技术要求。 其一，可孚孚探动态血糖监测产品线已具备独立的设备端数据能力（以 SDK 形式提供设备连接与数据传输）， 需要嵌入主 App，形成统一的家庭健康数据入口；该场景要求约 10 秒级的数据上传频率， 并需支撑约 50 万注册用户、4,000–5,000 并发的规模，对数据链路与并发架构提出明确要求。 其二，海外业务带来数据存储、跨境数据使用与合规架构方面的技术要求：业务面向海外， 用户与设备数据需在海外落地存储，同时国内运营团队与 AI 研发需要以合规方式使用相关数据， 形成“数据落地海外、运营位于国内”的双向技术要求。

1.2项目建设目标

基于上述背景，本项目设定以下建设目标：

1.3项目范围

本项目分为三个正式项目，各自独立成章，同时共享部分技术底座与实施资源。

1.4首发市场及目标时间

需要明确的是，10 月底是目标时间节点而非承诺节点。该节点能否达成， 直接取决于源代码与设备协议资料的可获得性、设备样机的可测试性、孚探 SDK 的完整度， 以及应用商店审核周期等外部因素。本文档在第 2.12、3.12、4.13 及第五章分别给出客观的可行性评估。

项目一是本次合作的主干项目。其目标不是重新开发一款 App，而是在既有国内版能力基线之上， 完成面向港澳台地区的功能边界判定、多语言适配、账户体系改造、设备接入适配与后台能力调整。 项目的难点集中在三个方面：哪些能力可以直接复用、哪些能力必须改造、哪些能力在目标市场不可用。 这三个问题都需要以技术资料审查结果为前置条件。

2.1背景分析

现有飞利浦灵析家用医疗设备 APP 主要面向家庭用户场景，用于连接血压计、体温计等智能医疗设备， 将设备检测数据同步至 App，并进行健康数据的展示、记录与管理。产品已完成国内版本开发并上架应用市场， 具备相对完整的功能基线。现有能力主要包括：

海外版本的整体规划如下：

• 产品策略：基于国内版核心能力进行国际化适配，不做全量重写；
• 首发市场：中国香港、中国澳门、中国台湾地区；
• 时间目标：10 月底完成首发版本交付与上线准备；
• 语言支持：简体中文、繁体中文、英文；
• 设备支持：首发阶段适配 5 款设备，后续扩展至 13 款或更多设备型号；
• 界面策略：一期不进行大规模 UI 重做，按照既有 UI 规范完成必要的页面与交互调整。

2.2当前基础和建设现状

现阶段项目的建设基础可归纳为“功能已就绪、资料待移交、边界待判定”三项特征。 国内版本的功能开发已基本完成并完成内部测试，具备可参照的产品形态； 但面向海外版本改造所需的技术资料尚未完成移交，功能边界亦未完成判定。

2.3需求分析

项目一的需求围绕十五个方向展开，按功能域归为「账户与权限 / 设备与数据 / 系统与合规 / 上线与智能」四组，每一项均需依据技术资料审查结果完成「可复用 / 需改造 / 需替换」判定。

2.4功能方案

项目一的功能方案遵循“结构不动、语言补齐、边界收敛、接入统一”四项原则：

功能方案按四个层次组织：账户与权限层、设备接入层、业务功能层与智能服务层。 四层之间的依赖关系如下：

2.5功能清单

下表为项目一的完整功能清单。第三列标注了各功能在首发版本中的建议归属： 首发版本建议纳入 首发版本可选 建议后续阶段建设

2.6AI 健康助手模块

AI 健康助手归属于项目一，作为独立功能模块进行分析。现阶段对接现有第三方 AI 服务接口，并配套既有知识库，承担健康知识问答、产品与设备使用问答等职责。该模块的核心问题不在于功能实现，而在于区域可用性、数据流向与输出边界三项判定。

2.7关键问题及影响分析

以下十二项为项目一在方案成立前需要完成核验或判定的关键事项，按「对工期的影响程度」标注等级。各项的核验资料清单统一列于第 6 章《项目实施所需输入资料》，本节不再重复。

2.8主方案

项目一的主方案为“基线复用 + 双层新增 + 边界收敛”方案，即在既有国内版能力基线上， 新增统一设备接入层与统一 AI 服务层，并按目标地区可用性完成功能边界收敛。

2.9备用方案

针对首发时间紧张或资料不足的情形，提供以下三套备用方案，按对首发范围的影响程度由小到大排列。

2.10实施内容和交付成果

项目一的实施内容按十二个阶段组织，各阶段的交付成果如下：

2.11初步排期

项目一的排期按三种推进强度分别给出：快速推进（资源加配、并行度提高）、 正常推进（标准资源配置）与资料或技术条件不足（前置资料延迟到位）。 排期以“技术资料到位”为起点计算，各单位为自然周。

2.1210 月底上线可行性

以下就十个具体问题给出评估结论。评估基于当前已明确的条件，未考虑尚未到位的资料所带来的正向或负向影响。

项目二的目标是将可孚孚探动态血糖监测能力嵌入主 App，形成统一的家庭健康数据入口。 与项目一相比，项目二的技术特征完全不同：数据由设备端持续主动产生，上传频率高、数据量持续累积， 对系统吞吐、存储与稳定性构成长期压力。因此项目二的方案重心在于 数据链路设计与并发架构，而非界面功能开发。

3.1背景分析

现有可孚孚探动态血糖监测产品已具备独立的设备端数据能力，以SDK 形式提供设备连接与数据传输能力， 并配有独立的应用形态。该产品与主 App 在用户体系、健康数据模型与设备管理逻辑上高度重合， 因此规划将其能力嵌入主 App，避免用户在两个应用之间重复注册与重复管理设备。

项目规划要点如下：

• 功能嵌入方式：将孚探功能嵌入主 App，通过独立入口或首页卡片进入孚探功能；
• 账户复用：复用主 App 的用户、账户与基础资料体系，去除重复的注册、登录等基础功能；
• 页面适配：对孚探相关页面进行重新适配，使其在视觉与交互上与主 App 保持一致；
• 数据能力：实现孚探数据的实时传输、展示与记录；
• 上传频率：孚探数据约每 10 秒上传一次，属于持续高频写入场景；
• 规模目标：支持约 50 万注册用户；
• 并发目标：支持约 4,000–5,000 并发；
• 时间目标：初步目标为 10 月底完成交付。

3.2当前基础和建设现状

3.3需求分析

3.4功能方案

项目二的功能方案遵循“能力嵌入不重建、账户复用不重复、链路独立不耦合、架构预留不重构”四项原则。

3.5功能清单

3.6技术架构方案

孚探数据链路属于典型的持续写入型负载。其技术特征为：写入频率固定且持续、单条数据体积小、 数据只增不改、查询以时间范围为主。针对这些特征，架构设计采用 “接入无状态化 + 队列削峰 + 写入批量化 + 存储分层 + 查询缓存化”的组合策略。

3.7关键问题及影响分析

以下十四项为项目二在方案成立前需要完成核验或判定的关键事项，主要围绕孚探 SDK 的能力边界、并发与存储架构、以及供应商配合机制。各项的核验资料清单统一列于第 6 章，本节不再重复。

3.8主方案

项目二主方案为“模块嵌入 + 账户复用 + 独立链路 + 架构预留”方案。

3.9备用方案

3.10实施内容和交付成果

3.11初步排期

3.1210 月底上线可行性

项目三输出的是技术层面的数据合规与架构方案，用于约束并支撑项目一与项目二的数据存储位置、 数据流向与权限模型。本方案的核心矛盾在于：业务面向海外，用户与设备数据需在海外落地存储； 而运营团队与 AI 研发位于国内，需要以合规方式使用相关数据。因此方案的目标不是“禁止数据流动”， 而是在明确数据分类分级的基础上，设计可审计、可控制、可替代的数据使用路径。

4.1背景分析

第一阶段面向港澳台地区建设海外版本，东南亚市场作为后续阶段。系统需要支持海外用户使用 App、 连接设备并记录健康数据，同时需要满足以下七项并行要求：

4.2数据处理现状

4.3需求分析

项目三的需求围绕二十个方向展开，可按「数据对象 — 数据行为 — 数据环境 — 数据使用 — 数据安全」五个维度归并：前两者确定保护范围与处置规则，后三者确定存储位置、使用边界与安全体系。

4.4数据架构方案

数据架构采用“海外落地、国内聚合、通道受控、全程留痕”的设计原则。核心结构如下：

4.5数据隔离与脱敏方案

（1）四层隔离设计

（2）脱敏与聚合处理规则

4.6国内运营访问方案

运营团队位于国内，需要在不建立常设数据通道的前提下获得必要的业务可见性。方案按“能看什么、怎么看、留下什么”三层设计：

4.7AI 数据使用方案

4.8关键问题及影响分析

4.9主方案

项目三主方案为“海外落地 + 分类分级 + 脱敏聚合 + 受控回流 + 全程留痕”方案。

1. 海外数据环境：首发在中国香港部署完整数据环境，独立于国内环境，具备独立账号体系与网络边界。
2. 数据分类分级：建立双维度分级标准，对全量字段完成标注，形成可派生规则的分类清单。
3. 数据脱敏与聚合：在海外环境内完成去标识化与分组聚合，设置最小分组规模阈值。
4. 数据传输加密：链路加密 + 字段级加密，跨境通道采用受控出口与白名单数据项。
5. 数据访问权限：角色权限 + 数据范围 + 跨区域单独授权三层叠加。
6. 数据审计：访问全留痕，重点操作实时告警，日志独立存储且限制修改。
7. AI 数据使用：通过统一 AI 服务层控制输入范围，研发使用聚合指标与知识内容。
8. 国内运营访问：聚合指标常设可见，明细数据按工单逐次授权并具时效性。

4.10备用方案

4.11实施内容和交付成果

4.12初步排期

4.1310 月底可行性

三个项目在实施上并非串行关系：项目三的架构结论约束项目一与项目二的部署方案， 项目一与项目二共享账户体系、设备接入层与数据底座，设备评估与 App 开发可并行推进。 本章给出整体执行顺序、阶段性安排以及首发版本的范围建议。

5.1总体实施路径

整体执行路径按“先评估、后定界、再开发、最后上线”的顺序推进，具体如下：

5.2阶段性实施安排

5.310 月底首发版本建议

基于三个项目的可行性评估结论，建议首发版本采用如下范围：

5.4二期及后续扩展建议

5.5东南亚市场扩展建议

东南亚市场属于第二阶段，不纳入本次核心开发范围。但从架构角度，首发阶段即可为后续扩展预留能力， 避免二次重构：

• 多语言框架扩展性：语言资源采用独立的语言包机制，新增语言仅需增加资源文件，不改动代码；
• 多区域部署能力：数据环境与访问入口按区域可配置，新增区域时通过配置扩展而非代码改造；
• 数据分区设计：数据模型预留区域标识维度，支持按区域分区存储与查询；
• 合规策略可配置：数据采集项、授权项与展示内容按区域可配置，便于适配不同地区要求；
• 设备接入层复用：统一设备接入层与区域无关，新增区域无需重复适配。

5.6后续 AI 智能体平台合作方向

本次正式开发不包含企业级 AI 智能体平台、AI Agent SaaS 平台与企业 AI 转型服务内容。 以下作为后续合作方向单独说明，供双方评估长期合作空间。

以下为项目实施所需输入资料清单。资料的到位情况直接决定评估结论与排期的准确性。 建议按“必选 / 优先”两档组织移交节奏：必选资料用于启动评估，优先资料用于完成验证与开发。

本章汇总全部待核验事项，并逐项说明其对功能与工期的影响。 以下事项的核验结论将作为实施规划与排期调整的依据。