聊天讨论 网站正常，Android 应用却出了问题：我才发现同一个产品正在慢慢变成两套系统
今天我几乎没有开发任何新功能。
我花了大半天时间，排查一个让我越来越不安的问题：
同一个产品，Web 版本运行正常，但 Android 应用却开始出现不同的结果。
我不是传统开发者。
我在金融科技和加密货币行业工作了大约 8 年，今年开始借助 AI 独立开发 TransferIQ——一个用于比较跨境汇款、外汇和加密货币路径的产品。
本来今天只是想继续改进功能。
结果打开 Android 应用后，先看到一个很明显的问题。
USDT 和 USDC 的图标变成了类似这样：
US DT
US D C
BTC 和 ETH 却完全正常。
一开始我以为只是图片加载问题。
后来检查代码才发现，应用引用了：
USDT: LOGOS.usdt USDC: LOGOS.usdc
但实际的 logo 对象里并没有对应的 key。
于是 fallback 文本被强行塞进一个很小的图标区域，最后显示成纵向断裂的文字。
这个问题还算简单。
接下来我发现了更奇怪的事情。
几个完全不同的跨境汇款服务商，预计到账金额的上限竟然完全一样：
OFX 7,431.91 ~ 7,470.38 GBP
Key Currency 7,424.44 ~ 7,470.38 GBP
TorFX 7,419.86 ~ 7,470.38 GBP
三个不同的服务商。
但 upper bound 全部是：
7,470.38 GBP
精确到小数点后两位都一样。
这看起来非常可疑。
更重要的是：
Web 版本没有这个问题。
所以我今天做了一件很简单但非常有效的事：
把正常运行的 Web 版本放在一边， 把 Android 应用放在另一边， 然后逐项对照。
某种意义上，我开始把自己的 Web 产品当成 “标准答案”。
结果越查越多。
我发现移动端存在一个共享 benchmark ceiling。
不同 provider 原本可以有不同的估算区间，但一旦超过某个共同上限，就会被截断。
于是不同服务商最后显示出相同的 upper bound。
界面看起来正常。
数字也很专业。
甚至普通用户可能完全看不出问题。
但逻辑已经错了。
然后我又发现：
两个本来应该被禁用的 provider，重新出现在 Android 应用里。
代码里其实有 disabled list：
TorFX Key Currency
但真正的过滤逻辑并没有正确使用这份列表。
也就是说：
“禁用名单存在”
不代表
“系统真的禁用了它们”。
继续检查后，我在 crypto off-ramp 部分发现了更让我担心的问题。
界面上用户可以选择：
USDT → BRL USDC → BRL BTC → BRL ETH → BRL
但部分内部 market-rate 逻辑仍然可能固定引用 USDC。
最坏的情况下，可能出现：
界面显示 BTC → BRL
但内部 benchmark 的一部分却基于 USDC → BRL
对于金融比较产品来说，这种问题比应用崩溃更危险。
应用崩溃，用户马上知道。
按钮失效，用户马上知道。
图标坏掉，也很容易看到。
但错误的数字如果看起来 “很合理”，用户不知道，我自己也可能忽略。
例如：
51,200 BRL
和
51,600 BRL
从界面上看都很像真实结果。
但用户不知道内部到底用了什么 rate source。
今天真正让我意识到的问题，并不是某一个 bug。
而是：
同一个产品的 Web 和 Android 版本，正在慢慢变成两个不同的系统。
一开始只是很小的差异：
Web 修一个问题 → App 没有同步
App 做一个 hotfix → Web 逻辑不同
增加一个 provider → 只更新了一边的 filter
修改 crypto route → 只更新了一边的 source asset
增加一个例外条件 → 另一端继续使用旧规则
每一次修改看起来都很小。
可能只是几行代码。
应用也能正常启动。
构建也能成功。
但几周之后，就可能变成：
一个产品
两套实现
两套例外规则
甚至两套不同的计算结果。
我之前一直认为，AI 编程最大的风险是：
AI 写出明显的坏代码。
现在我越来越觉得，真正危险的是：
AI 写出 “能运行、看起来合理、但和系统其他部分已经不一致” 的代码。
今天我几乎没有增加新功能。
大部分时间都在问：
为什么 Web 正常，Android 不正常？
为什么不同 provider 出现相同的估算上限？
为什么已经禁用的 provider 又重新出现？
为什么用户选择的 crypto asset 和内部 rate source 可能不同？
为什么同一个产品会慢慢变成两个系统？
我现在正在考虑下一步：
把 quote engine 尽可能拆成共享 core
Web 和 Android 使用完全相同的 JSON test fixtures
为主要货币路径建立 golden tests
发布前自动比较 Web / App 的计算结果
检查 selected asset 与实际 market-rate source 是否一致
对 disabled provider 增加 regression check
我的项目叫 TransferIQ。
目前 Android 应用已经实际发布：
https://play.google.com/store/apps/details?id=com.jkim1285.TransferIQMobile
我把链接放在这里，不只是为了推广。
主要是因为这已经不是一个理论上的 coding exercise。
当真实用户开始使用产品以后，“看起来合理的错误数字” 就会变成真实的产品风险。
所以我非常想听听这里有经验的开发者和独立开发者的意见：
如果是你，会优先做什么？
先拆 shared core？
先做 unit tests？
先做 E2E？
先做 Web / App parity tests？
还是先建立 CI regression checks？
尤其是对于这种 “金融计算结果必须跨平台一致” 的产品，你们会怎么设计？
今天从表面看，非常低效。
我没有发布重大新功能。
没有做新页面。
也没有完成新的路线。
但我可能发现了一个比单个 bug 更重要的问题：
如果没有系统性约束，同一个产品真的会在不同平台上慢慢变成两个不同的产品。