当时是什么情况
早期三端各自算分位：桌面用 C# 的 LINQ 排序，Web 用 JS 的 sort，小程序为了省流量只取近 60 日。同一个「IV 分位」在三个地方差了 2–6 个百分点。客户群里有人贴了三张截图问「到底哪个是对的」——那一刻我们没有任何回答是体面的。
我们怎么判断，怎么改
- 01不选「以桌面为准」
最省事的做法是宣布桌面端是标准，另两端「仅供参考」。但那只是把不一致藏起来：客户仍会看到三个数，而我们已经放弃了回答。
- 02把计算下沉成纯函数，三端共用同一份源码
分位、成本、合成价差、集中度这类纯计算抽到 `src/Shared/`，服务端与客户端用**源码链接**引入（不是复制）。改一处，两端编译期就同步；不存在「忘了改另一边」。
- 03窗口参数也进单一真源
「展示用 250 日 / 信号用 250 日」原本散落在三处常量里，后来统一到 `PercentileWindows`。只统一算法不统一参数，等于留下第二个漂移点。
- 04把「怎么算」写进产品里
每个派生指标在口径登记表里登记定义、公式、数据源、更新时点与已知坑；页面顶部直接给出这些说明，而不是藏在文档里。
放弃了什么
- 放弃「三端各自优化」的自由：Web 不能为了省流量只取 60 日样本，桌面也不能为了快改用近似分位。
- 放弃一部分灵活性：新增指标必须先写纯函数 + 单测，不能再在页面里就地算。
- 共享源码让三端耦合变紧：改一个签名要同时改三处调用（这是有意的，它逼我们想清楚再改）。
你可以自己核对
这篇里的判断都能被验证 —— 不是"效果很好"这种话，而是能点开的页面与能跑的命令。
一句话 一致不是靠约定，是靠"只有一份实现"这个结构性约束。