我有 8 年金融科技和加密货币行业经验，但几乎没有传统编程背景。
今年，我开始借助 AI 独立开发一个跨境汇款、外汇和加密货币路径比较工具。
今天本来计划继续增加功能。
结果，我几乎一整天都在修问题。
而且最麻烦的是：
网站版本运行正常。
Android 应用却出现了各种异常。
所以我最后做了一件非常简单的事：
把正常运行的网站放在一边，把 Android 应用放在另一边，逐项对照。
我开始把自己的网页版本，当成“标准答案”。
第一个问题看起来很小。
在 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
三个不同的服务商。
但上限全部是：
7,470.38 GBP
精确到小数点后两位都一样。
这看起来不像正常现象。
更重要的是：
网站版本没有这个问题。
于是我继续把 Web 和 Android 逻辑进行对照。
最后发现，移动端存在一个共享的 benchmark ceiling。
也就是说，不同服务商原本可以有不同的估算区间，但一旦超过某个共同上限，就会被强行截断。
结果就是：
不同服务商，看起来像是得出了同一个上限。
界面很正常。
数字也很专业。
甚至普通用户很可能完全看不出问题。
但内部逻辑并不正确。
这比一个按钮坏掉更让我担心。
因为明显的 UI Bug 很容易发现。
但“看起来非常合理的错误数字”，反而更危险。
然后我继续检查。
又发现两个本来应该被禁用的服务商重新出现在 Android 应用里。
代码里其实已经存在：
TorFX
Key Currency
的 disabled list。
但真正的筛选逻辑并没有使用这份列表。
也就是说：
“禁止名单存在”
不代表
“系统真的禁止了它们”。
接着，我又发现了加密货币 off-ramp 路径中的问题。
界面上可能显示：
USDT → BRL
USDC → BRL
BTC → BRL
ETH → BRL
但部分内部市场价格逻辑仍然可能固定引用 USDC。
换句话说，最坏的情况下可能出现：
界面显示 BTC → BRL
但内部 benchmark 的一部分却基于 USDC → BRL
对于普通应用来说，这已经是严重问题。
对于金融比较产品来说，更危险。
因为用户看到的不是“系统错误”。
用户看到的是一个看起来很可信的数字。
今天让我真正意识到的问题，不是某一个 Bug。
而是：
同一个产品的 Web 和 Android 版本，正在慢慢变成两个不同的系统。
一开始，这种差异很小。
Web 修一个问题。
Android 做一个 hotfix。
某个 provider 只在一边增加。
某个例外逻辑只在另一边修改。
某个 crypto route 的 source asset 只在一个版本更新。
每一次看起来都只是一个“小修改”。
但几周之后，就可能变成：
一个产品
两套实现
两套假设
两套例外规则
甚至两套不同的结果。
我之前一直以为，AI 编程最大的风险是：
AI 写出坏代码。
现在我越来越觉得，真正危险的是：
AI 写出“能运行、看起来也合理、但和系统其他部分已经不一致”的代码。
代码可以成功编译。
应用可以正常启动。
界面也可以很好看。
但结果仍然可能是错的。
今天我几乎没有增加任何新功能。
大部分时间都花在这些问题上：
为什么 Web 正常，Android 不正常？
为什么不同服务商出现相同的估算上限？
为什么已经禁用的 provider 又重新出现？
为什么用户选择的 crypto asset 和内部 rate source 可能不同？
为什么同一个产品，在两个平台上逐渐产生不同逻辑？
我现在正在考虑几件事：
-
把 quote engine 尽可能拆成真正共享的核心逻辑
-
Web 和 Android 使用完全相同的 JSON test fixtures
-
为主要货币走廊建立 golden tests
-
发布前自动比较 Web 和 App 的计算结果
-
检查 selected asset 和真实 market-rate source 是否一致
-
对 disabled provider 增加 regression check
我的项目叫 TransferIQ。
公开网站是：
Android 应用也已经在实际维护和发布中。
我提到它并不是想把这篇文章写成广告。
只是因为，当一个产品真正开始被别人使用以后，这些问题就不再是“学习编程时的小错误”。
它们会变成真实的产品风险。
所以我很想听听有经验的开发者、独立开发者和 AI coding 用户的意见：
如果是你，会优先做什么？
先统一 shared core？
先做 unit tests？
先做 E2E？
先做 Web/App parity tests？
还是先建立 CI regression checks？
尤其对于这种“金融计算结果必须跨平台一致”的产品，你们会怎么设计？
今天从表面上看，是非常低效的一天。
我没有发布重大新功能。
没有做漂亮的新页面。
也没有完成新的产品路线。
但我可能终于发现了一个比单个 Bug 更重要的问题：
同一个产品，如果没有持续约束，真的会在不同平台上慢慢变成两个不同的产品。
