创始人手记
一个难以料想的项目
2026年9月
2026 年 2 月，我有了做 Health Mirror 的想法。
一周后，它就已经能在我的手机上从头跑到尾了。
我当时想：啊，真的可以！
真的不可以。但是我当时还不知道。:)
其实，那一个星期让我明白了一件可能更加重要的事：
从一个想法，到真的动手把它做出来，中间的距离忽然变短了。
当时，我是一名首席产品经理。
我的工作通常是回答做什么和为什么。 至于把它怎么变成现实，往往需要整个研发团队， 以及 IT、运营等许多人的共同参与。
大语言模型（LLM）改变了这件事。我忽然有了一个 AI 搭档， 可以陪我走进那些不熟悉的领域。虽然后来才知道走的也不是什么直线。:)
Health Mirror 成了我的一个实验——这种新的开发模式， 究竟能把我带到多远的地方？
一周速成的 App 遭遇现实
Health Mirror 的最初版是把所有功能都集成在手机上的，包括 AI 推理。
我很满意这个架构。在本地拍照，本地处理图像，本地运行模型，本地保存结果。
干净，简单，重要的是从隐私保护角度看非常漂亮。
接下来，我需要把它变成一个真正能在 iOS 和 Android 上运行的 App。
之后的一个月，我都在打地鼠——打移动端技术栈依赖链版的地鼠。:)
解决一个依赖冲突，另一个冒出来。升级一个组件，别的地方又坏了。
这样折腾了差不多一个月，我的 AI 搭档终于说出： “我没有更多建议了。这套移动端生态还在快速发展，也许到年底会变得可行。”
我们认输了。
我的项目笔记也写得相当决绝：
## ⚠️ Known Constraints & Decisions
### ❌ Abandoned Approach
* TensorFlow.js + React Native (Expo)
* Reason: incompatible with modern RN/Expo architecture
还有：
## 🧠 Key Lessons Learned
* On-device AI with Expo + TFJS is not viable (current ecosystem)
* Native/runtime layer matters more than JS layer for ML
...
我升级了团队
我找来了第二个 AI 搭档。
三个碳基、硅基搭档凑在一起，终于组成了一个比较像样、 可以进行头脑风暴的团队。很快，一个变成了我的架构师， 另一个变成了我的程序员。
差不多这个时候，我发现了一个尴尬的问题。:)
初版模型使用 softmax——适合在多个类别中做一个排他性的选择。 之后，我把它改成了自己以为的 sigmoid——更适合处理多个独立并存的舌象信号。
只是，我用的并不是真正的 sigmoid，而是一个基于 softmax 模拟出来的 sigmoid。
于是我们重新训练模型。
然后为了优化输出，再重新训练。
然后，再训练。:)
到了 4 月，我们已经不再试图修补原来的单机方案。
我们开始彻底的架构转向。
这个 App 的功能里，哪一个最适合离开手机？
这个问题是重构的关键。
如果不再坚持把拍摄、图像解码、张量准备和机器学习推理全部塞进一套 必须同时兼容 iOS 和 Android 的移动端依赖链里呢？
最小可行的改变，其实只需要把一个功能移出去：
AI 推理。
其他功能还是可以全部留在用户手机上——一个在我心里不完美， 但接近完美的配置。
最初的重构方案还是需要把原始图片发送去推理服务， 在这个基础上做最大网络安全与隐私保护的优化。 当时的项目笔记是这样的：
## 🔐 Privacy Design (MVP)
* Images sent to server for inference
* No persistent storage of images
* Processing done in-memory
* HTTPS required for production
## 🧭 Future Considerations (Post-MVP)
...
* Possible future migration: ONNX Runtime (on-device AI)
后来，我们成功把 AI 张量准备独立出来保留在移动端， 并且没有再次破坏那条相当脆弱的移动端依赖链。 于是，原始图片也不需要离开手机了。
离开手机的只有数值张量。
云端服务运行模型，返回一组预测置信度。
剩下的一切，都由手机完成。
技术方案做了重大转变。
技术原则没有变。
我想把网络安全与隐私保护写进第一行代码
我很喜欢网络安全、隐私保护和合规这个领域。
它们有趣。
对，的确有人真心喜欢这个。:)
我甚至考过了 CISSP（Certified Information Systems Security Professional， 注册信息系统安全专家）。它涵盖八大网络安全知识领域，应试者通常是在 网络安全与 IT 界的专业人员，而不是软件产品经理。
但凡有做产品的机会，我就觉得有责任把安全设计进去。
在企业环境里工作多年，有一种通行范式经常触到我有点烦：
先把系统建起来。把东西都连起来。把数据都采集起来。
隐私和安全再说。
到了那个时候，很多重要决定已经做完并开始执行。 再去做这种底层改变，代价只会越来越高， 有时甚至高到失去经济上的可行性。
Health Mirror 倒是给了我一个机会出这口气：从第一行代码开始， 把安全设计进底层，也终于有机会把我一直相信的一件事做出来—— 安全与隐私越早成为设计的一部分，往往越安全，也越经济。
执行从一个很简单的问题开始：
我们切实需要哪些数据去实现云端功能？
上线之前，我们还做了一次隐私和安全自查。 没人要求我们这么做，我只是要确保技术实现、隐私原则， 以及我们许诺用户的，三者之间没有分歧。
以那几个月的做事方式，我们非常相信这方面的一致性。 但最后再查一次，确保没有被忽略的细节。
重构我的“一周速成 App”花了六个月
从第一个产品原型到 App 正式上线，中间当然还有很多波折。
但最刷新我认知的，大概是这个：
AI 不是魔术师，也没有预设好的完美答案。 但它让我非常、非常、非常超速地走向下一个问题。
我学了刚刚好的机器学习知识，足以明白第一个模型出了什么问题。 学了刚刚好的移动端开发知识，足以明白第一个原型为什么还不够成为真正的 App。 也学了刚刚好的架构知识，知道什么时候必须改变一个自己很喜欢的设计。
遇到我们三个搞不清楚的方向，就一起调查讨论、一起质疑预设， 头脑风暴，之后再来。
六个月以后——这期间我仍在全职工作——那个“一周就能跑”的 Health Mirror， 终于变成了可以从 App 平台下载使用的产品。
我的 softmax 变成了 sigmoid。
一个 AI 搭档变成了两个。
那个完全运行在手机上的架构，多了一个最小化的云端服务。
而我的实验，变成了一个产品。
这和我在今年 2 月时以为自己要走的路，相当不一样。
还好当时还不知道后面会发生什么。:)