Options Wise 的存在，是因为我们厌倦了在收盘后看不清自己的持仓。
我们一直深度参与期权交易——管理一个小规模基金，同时在做量化工具。分析基础设施是有的：一个 Python CLI，能算 GEX 分布、Max Pain、Put/Call 压力位、Gamma 翻转点。但我们缺少一个简单的东西来回答每天下午四点之后的问题：我的持仓现在到底值多少，风险敞口是什么样的？
我们找过各种解决方案。要么需要登录券商账户，要么把持仓上传到某个服务器，要么是给机构设计的、定价也是机构价格。没有一个是为在香港和新加坡持有几个美股多腿期权头寸的零售交易者准备的。
所以我们决定自己做。
第一版是错的
第一次尝试叫 OptionsPulse。前端是 React Native，后端是 Python FastAPI，数据来源是 yfinance。纸面上看起来合理。
实际上：yfinance 不可靠。它是一个逆向工程的爬虫，随时可能无预警地坏掉。在它上面做产品，意味着你的用户会遇到你无法预测也无法修复的故障。Python 后端需要一台服务器——意味着要维护基础设施、关注可用性、承担持续的成本。React Native 则不断提醒我们，“一次编写，到处运行”是一个经不住 Android 平台考验的承诺。
做到一半，我们意识到自己在解错误的问题。架构在和我们作对。
重来
我们停下来，把真正重要的东西写下来，然后从头开始。
三个决定驱动了重建：
只做原生 Android。 我们更熟悉 Android 开发流程，已有 Google Play 开发者账号，上线后可以立刻把 App 分享出去。放弃跨平台的约束，让我们可以好好写 Kotlin、正经用 Jetpack Compose，不再和框架较劲。
用户数据不上服务器。 持仓用 Room 存在设备本地。没有任何内容被上传。不需要账号，不需要注册。这一开始是隐私决策，后来变成了产品特性——这是用户第一眼就能注意到的东西，它消除了一整类信任问题。
自己掌控数据层。 我们用部署在 Cloudflare Workers 上的自建市场 API 取代了 yfinance。接口、缓存、可用性，都在我们自己手里。Black-Scholes 定价引擎直接用 Kotlin 写在 App 里。不依赖第三方定价服务，不需要在每次估值时多一跳网络请求。
九个工作日
重建进展很快。难的部分我们已经想清楚了——数据模型应该是什么样的、哪些希腊字母重要、多腿持仓如何聚合。第一版是错误的答案，但是有信息量的错误答案。
任务清单有 83 条。上线时完成了 80 条。
这九天覆盖了：Black-Scholes 定价核心及其单元测试、市场数据 API 和汇率接口、持仓 CRUD 和估值循环、带盈亏平衡点的到期收益图、多货币显示（USD/HKD/SGD/MYR/CNH/JPY）、基于 WorkManager 的后台刷新，以及 Play Store 的提交流程。
国际化从第一天就做了，不是后来加的。四种语言：英文、繁体中文、简体中文、日文。我们要打的市场不全是英文用户，而国际化如果在后期加入会非常痛苦，所以我们把它列为第零天的约束。
现在是什么
Options Wise 已经在 Android 上线。你把期权腿逐一录入——标的、到期日、行权价、方向、数量、权利金——App 获取盘后报价和隐含波动率，用 Black-Scholes 计算理论估值。你能看到：理论净值、以显示货币计的浮盈亏，以及跨所有腿聚合的净 Delta、Gamma、Theta、Vega。还有一张到期日收益图，带盈亏平衡点标注。
在消费级 App 里，不需要登录券商账户就能看到多腿组合的聚合希腊字母。这个功能至今仍然难找。
付费功能的路线图是有的——但第一优先级是把核心体验做对、交到真实用户手里。等我们知道人们真正在用什么，再决定什么值得收费。
先做工具再做产品
我们之前构建的量化工具——期权压力分析器、基金净值追踪系统——直接影响了 App 里放什么、不放什么。我们知道收盘后你真正会看哪些数字，哪些是噪音。我们知道到期收益图对大多数决策来说比原始希腊字母更有用。我们知道多货币显示对于在美国之外做美股期权的人来说是真实的痛点。
当一个问题已经让你付出代价，你会把产品做得更准确。