3D扫描App开发

项目背景

这是足部健康方向的 3D 扫描应用，5 个仓库，最后提交时间从 2024 年 10 月到 2026 年 4 月。核心是用 Swift 做的两代足部健康与 3D 扫描 App，另外有 JavaScript 做的视觉能力验证 Demo，用于验证指纹与足型评估相关的能力。两代产品并存，说明这个方向经历过一次技术方案的迭代。

客户当时的状态

足部扫描的难点是「扫描结果好坏取决于用户怎么拍」。手机摄像头做三维采集，用户站姿、距离、光照、转动速度都会影响结果；说明写得再清楚，实际使用中仍然会有人拍歪。另一个问题是硬件形态：如果配专用扫描设备，App 要和设备对接；如果没有，就得靠普通摄像头凑合。这个前提一开始就不确定，会直接影响技术方案。另外，足型数据到推荐之间还有一个问题：推荐口径由谁定。如果业务方没有明确规则，系统只能给出原始数据，推荐就无从谈起。

我们的做法与取舍

第一个取舍是把引导做成流程的一部分，而不是写在说明里。扫描过程分步提示、即时反馈，让用户在拍的时候就知道这一步行不行，而不是拍完才发现重来。

第二个取舍是先做能力验证 Demo，再决定产品形态。指纹与足型评估这类视觉能力，先确认在目标设备上能不能稳定做到，再谈 App 怎么做。跳过这步直接做产品，风险太大。

第三个取舍是两代产品都保留，而不是直接把旧版本推倒。不同的使用场景对精度和操作成本的要求不一样，保留两代可以分别对应。

系统怎么承载这条链路

链路是「扫描 → 足型数据 → 推荐结果」。扫描端负责采集与质量判断，足型数据是中间产物，推荐的鞋垫与鞋型基于它得出。视觉能力验证 Demo 独立于产品之外，作用是在方案定稿前把不确定的部分先验证掉。

交付状态与边界

代码处于维护状态，最近一次提交在 2026 年 4 月，最早可追溯到 2024 年 10 月。边界说明：扫描精度与用户拍摄姿势直接相关，软件无法完全消除这一变量；我们做的是采集与数据环节，不涉及鞋垫、鞋型产品的制造与销售；推荐结果基于足型数据得出，不构成医疗或健康诊断意见。如果后续接入专用扫描硬件，其选型与采购不在开发范围内。