WAVE 从一个网页项目长成 Cloud / Client / App 三端

7 月底以前，我一直把 WAVE 当成一个“网页上的 AI 工程平台”来推进。数据集、标注、TrainStudio、算力市场、测试、部署、Workflow 和 Agent 都往同一个 Web 产品里堆。

这种结构在原型阶段很自然，但功能越往后做，几个原本可以含糊的问题开始不能再含糊：用户的数据到底放在哪里？本地训练和云训练是不是同一种信任模型？手机端应该拥有多少能力？如果企业或实验室根本不允许敏感数据离开电脑，WAVE 还能不能用？

7 月 30 日，WAVE-client 真正跑起来之后，我开始把这个项目看成三个产品，而不是一套页面的三个壳：Cloud、Client、App。

Client 不是给 Cloud 换一个“离线主题”

WAVE-client 最初的要求很直接：只允许本地算力，所有训练数据、模型、数据库和日志留在本机，不调用云算力，也不把敏感数据发到远程服务；核心使用体验则尽量和 Cloud 保持一致。

真正实施时，这意味着不能简单复制前端再隐藏几个按钮。安全边界必须落在后端。

所以 Client 的本地模式会主动拒绝云算力、远程部署、云存储和需要联网的服务；网页只从本机回环地址访问后端，数据和运行产物落在本地目录。那天还实际跑了一条 RTX 4050 的训练链：本地数据进入训练，产出模型，再导出 ONNX 并完成本地推理。

这件事让我意识到，所谓“隐私版”最重要的不是写一句“数据不上云”，而是让代码路径证明：即使用户点错了，也没有一条偷偷绕出去的远程执行链。

到 8 月 4 日再做 Cloud / Client 对齐时，核心文件绝大多数已经能保持一致，真正保留下来的差异主要就是这些本地策略。这个结果比维护两套完全分叉的代码健康得多。

8 月 1 日，HarmonyOS 端从 Cloud 仓库里正式抽出来，WAVE-app 开始成为独立仓库。

手机端和 Client 的逻辑又不一样。它不是把训练服务器塞进手机，而更像 WAVE 的移动控制台：看项目状态、上传或采集数据、触发允许的操作、接收训练和部署结果。

一旦决定把它做成真正的应用，而不只是比赛截图，很多“网页项目里可以以后再说”的问题突然变得具体：首次启动隐私同意、用户协议、数据删除、Release 构建、签名、第三方登录、生产 API、审核账号、应用市场材料。

8 月 3 日第一次把 WAVE-app 按 AppGallery 的要求收紧时，我最明显的感受是：能在模拟器里打开，和能作为一款应用交出去，中间隔着一整套产品责任。

与此同时，WAVE 开始准备通信、医学、交通、化工、集成电路和反无人机六个跨学科 Demo。

这些案例很有用，因为它们会逼平台回答真实问题：检测之外怎么训练分割？分类数据怎么组织？跟踪为什么需要跨帧状态？Workflow 的输出最后怎样变成一个业务结果？

通信案例原本计划使用一个公开数据集，但下载源长期受共享配额限制，最后换成了实际可获得的 2.4 GHz 频谱检测数据。到 8 月 2 日，六个案例的数据、固定划分、TaskSpec 和实施材料被整理成约 29 GB 的分发包，并逐个做了归档完整性检查。

这一步很像“准备齐了”。但几天后的一次复盘把我从这个错觉里拉了出来。

8 月 5 日我重新按真实执行能力核验六个 Demo，结果并不好看：

平台确实已经有一条本地 YOLO 小样例闭环，但它不属于六个正式案例，也不能替分类、分割和跟踪证明什么。

当时的缺口也很具体：通用训练 runner 仍偏检测；分割的 mask 数据和部署输出没有完整接通；跟踪需要视频状态机；分类还缺更完整的训练与评估路径；一些 Workflow 节点仍然只是模拟或透传。

这次核验对三端架构反而很重要。它提醒我，Cloud / Client / App 的拆分是产品边界进步，不等于底层 AI 工程能力已经自动成熟。

现在我更愿意这样理解 WAVE：

Cloud 面向共享资源、远程计算和协作；Client 面向本地算力和敏感数据；App 面向移动访问和轻量控制。它们可以共享项目模型、Workflow 思路、Agent 交互和核心业务逻辑，但每一端都有不同的信任边界。

接下来最难的工作仍然很朴素：把检测之外的训练、测试、部署和 Workflow 真正一条条补齐。

三端架构让 WAVE 看起来比以前大了很多，但 8 月 5 日的 0/6 也提醒我，项目应该用“真实跑过什么”衡量，而不是用“仓库有几个、页面有多少”衡量。

这大概是 WAVE 在这个阶段最重要的一次变化：从继续往一个网页里加功能，变成开始认真定义一套 AI 工程平台在不同设备和不同隐私要求下应该怎样存在。