transferiq (TransferIQ)

收录了 19 家服务商后，我研究了一家覆盖 300 多家服务商的同行

transferiq — Wed, 22 Jul 2026 07:13:30 +0800

最近，我重新研究了 TransferIQ 在国际汇款比较领域最值得参考的产品之一：Monito。

TransferIQ 是我独立开发的一款跨境转账比较工具。目前收录了 19 家服务商，比较的范围包括传统汇款公司、银行以及部分加密货币转账路径。

完成这些数据时，我觉得 19 家已经不少了。

但当我认真研究 Monito 后，才真正看到了差距。

Monito 的网站已经评测和收录了 300 多家金融服务商，应用中可以实时比较 100 多家汇款公司和银行，覆盖 200 多个国家和地区，同时还提供 11 种语言的评测和指南。

它的内容也不只是 “哪家汇款公司更便宜”。

它围绕海外生活用户建立了大量内容，包括：

不同国家之间的汇款路线汇款服务商评测海外银行账户 eSIM 比较留学、移民和海外生活指南

这些内容不仅服务于准备汇款的人，也能吸引移民、留学生、自由职业者、远程工作者和长期生活在海外的人。

作为一名独立开发者，看到这个规模，第一反应确实是压力很大。

19 家和 300 多家之间的差距，不只是多录入一些数据而已。背后还包括多年积累的合作关系、实时价格、国家覆盖、内容团队、SEO 和品牌信任。

如果把这些全部列入自己的开发计划，最后可能什么都做不完。

所以我重新思考了一个问题：

独立开发者研究大型同行，目的到底是什么？

我认为目的不应该是复制对方，而是弄清楚三件事：

这个市场已经验证了哪些需求？用户已经习惯了哪些功能？成熟产品仍然没有解决什么问题？

Monito 在传统国际汇款领域做得很深，而 TransferIQ 想探索的是另外一个方向：

把传统汇款、银行和加密货币转账路径放在同一个标准下比较。

现在很多比较网站只展示汇款手续费和汇率。

但如果使用稳定币或交易所完成跨境转账，真正的成本还包括：

买入和卖出价差交易手续费区块链网络费用入金与出金成本法币与稳定币之间的兑换成本最终提现到本地银行账户的费用

用户真正想知道的并不是 “手续费是多少”，而是：

完成所有步骤后，收款人最终能拿到多少钱？

这也是我目前认为 TransferIQ 可以继续深入的方向。

我无法在短时间内把 19 家服务商扩展到 300 多家，也无法独自复制一个已经运行多年的 SEO 体系。

但我可以先把一条跨境转账路线算清楚，把一种隐藏成本解释清楚，再逐步增加新的国家和服务商。

这次分析让我意识到，大型同行既会让独立开发者感到渺小，也可以成为一张免费的市场地图。

关键不是追赶它的全部规模，而是找到它没有覆盖清楚的那一部分。

也想请教各位独立开发者：

你们研究大型竞品时，会优先补齐自己的短板，还是优先寻找对方没有做好的细分方向？

做金融产品之后，我开始害怕 “看起来很完整”

transferiq — Tue, 21 Jul 2026 06:58:35 +0800

近在独立开发 TransferIQ，一个用来比较跨境汇款费用和汇率的工具。

刚开始时，我很在意产品看起来是否足够完整：平台数量够不够多、功能够不够丰富、页面是否像一个成熟产品。

后来我发现，金融比价产品最危险的状态，可能就是 “看起来很完整”。

跨境汇款的成本并不只是页面上显示的手续费。实际汇率、汇率差价、付款方式、收款方式、金额和更新时间，都会改变最终到账金额。

如果我快速接入很多平台，产品在数字上会显得更强大。但只要其中一些数据过期，或者比较条件不一致，用户看到的 “最低价格” 就可能没有实际意义。

这让我开始重新思考独立开发中经常遇到的一个问题：

产品应该先追求覆盖范围，还是先保证少量结果足够可信？

对于普通工具，偶尔出现误差也许只是体验问题。但在金融产品里，用户可能会根据结果直接转账或做出资金决定。一次错误就可能让他不再相信整个产品。

所以最近我没有急着增加更多功能，而是在反复思考：

数据多久更新一次才算合理？预估价格和实际报价应该如何区分？数据不确定时，是展示出来还是暂时隐藏？是否应该明确告诉用户，手续费低不代表最终到账更多？

我现在更倾向于：宁愿先做好 20 个平台，也不要急着展示 100 个平台。

但这样做也有代价。覆盖范围太小，用户可能根本找不到自己需要的服务，甚至不会给产品第二次机会。

如果是你，会怎么选择？

先做一个覆盖广但结果只能参考的产品，还是做一个覆盖较少但每条数据都尽量可靠的产品？

想听听做过数据产品、比价工具或金融产品的朋友怎么处理这个问题。

做了汇款比较工具后，我发现用户并不想 “比较手续费”

transferiq — Sun, 19 Jul 2026 12:07:45 +0800

最近在重新整理 TransferIQ 的产品逻辑时，我发现自己一开始可能理解错了用户的需求。

我原本以为，用户需要的是更多数据：不同汇款公司、交易所和区块链的手续费、汇率与转账速度。

但用户真正想知道的其实只有一个问题：

“我支付这笔钱之后，对方最后能收到多少？”

手续费最低的路线，不一定是最便宜的路线。较差的汇率、买卖价差、提现费和兑换成本，都可能让最终到账金额变少。

这也让我意识到，数据越多不一定代表产品越好。好的工具不应该让用户自己计算，而应该把复杂的信息整理成一个可以直接做决定的答案。

作为独立开发者，我们很容易把 “继续增加功能” 当成产品进展。但有时候，减少不重要的信息，把核心答案说清楚，可能比再增加一个功能更有价值。

你在做产品时，有没有发现用户真正需要的东西，和你最初以为的完全不同？

这个周末，我重新整理了 TransferIQ 的加密货币比较功能，并完成了 Google Play 内部测试

transferiq — Wed, 15 Jul 2026 07:54:28 +0800

这个周末，我继续更新了 TransferIQ。

我之前在这里写过，平日我尽量不开发这个项目，主要利用周末集中处理产品问题。

这次的重点不是增加一个小功能，而是重新整理整个加密货币比较结构。

现在 Crypto 页面被分成四个部分：

Spot / Conversion / P2P / Card

其中最花时间的是 Spot。

之前系统有一个问题：

如果某家交易所的价格 API 暂时失败，这家交易所可能会直接从结果中消失。

但价格暂时获取不到，不代表这家交易所不支持这个交易对。

所以我把两个判断彻底分开了：

这家交易所是否支持这个交易对当前是否能获取实时价格

现在的逻辑是：

官方 API 能用，就使用官方数据官方 API 不稳定，就使用 CoinGecko 或其他市场数据如果价格暂时获取不到，仍然保留已经确认的交易对再根据交易手续费和价差计算预计成本每个结果尽量直接连接到实际交易页面，而不是交易所首页

这次也重新整理了韩国、日本、巴西和全球交易所。

用户选择不同的法币和加密货币后，可以看到哪些交易所实际支持对应交易对。

例如：

KRW 与 USDT、USDC、BTC、ETH JPY 与 BTC、ETH，以及实际存在的稳定币交易对 BRL 与 USDT、USDC、BTC、ETH USD、EUR、GBP 等全球法币交易对

我还把交易链接和推荐注册链接分开处理。

之前这两个链接有可能相互覆盖。

现在：

“交易” 按钮进入实际交易市场 “注册” 按钮使用推荐链接推荐链接不会被普通官网链接覆盖

另一个问题是数据标签。

我之前为了区分数据来源，增加了一些新的标签。

但后来发现，这会让用户更难理解。

所以这次删除了额外的标签，只保留原本的标签体系。

能够从官方市场数据确认的内容，统一使用现有的 Live 类标签。

无法获得实时价格，但可以根据手续费、价差和市场基准计算的数据，继续使用 benchmark 类标签。

完成这些调整以后，我也完成了 Google Play 内部测试，并上传了新的 Android 版本。

这次内部测试主要检查了：

App 是否可以正常启动 Spot / Conversion / P2P / Card 是否正常显示不同交易对是否可以正常切换本地交易所是否会正确出现交易链接和推荐链接是否正确多语言内容是否同步广告和其他原生模块是否影响运行

这次更新之后，TransferIQ 不再只是显示一个汇率数字。

它正在逐渐变成一个资金路径比较工具。

用户真正需要知道的是：

哪里可以完成这笔兑换？

需要支付多少手续费和价差？

最终实际能收到多少钱？

这是我这次周末更新的主要目标。

App 上线后一点就闪退，我折腾了一整天，最后发现问题根本不在代码里

transferiq — Mon, 13 Jul 2026 12:37:32 +0800

最近，我把自己做的 App 更新到了 Google Play。

这个 App 叫 TransferIQ，是一个比较外汇、跨境汇款和加密货币兑换路线的工具。

我本身不会写代码，整个产品主要是借助 AI，一边学习、一边修改、一边上线。

原本以为这次更新只是增加一个底部广告，应该不会有太大问题。

结果新版本发布后，我点击 App 图标，启动画面刚出现，应用就直接关闭了。

再打开，还是一样。

点击图标 → 出现启动画面 → 立即闪退。

那一刻真的很崩溃。

因为这个 App 的主文件已经接近 9000 行。我第一反应就是：一定是最近修改功能时，把某个地方弄坏了。

于是我开始检查整个文件。

我怀疑过很多地方：

新增加的广告代码汇率转换功能为交易所数据增加的代理请求变量是不是在声明前被使用某个功能是不是在 App 启动时立即执行生产环境和测试环境是否存在差异

我甚至专门建立了一个测试环境，模拟正式版本启动时执行整个文件。

检查结果却很奇怪。

代码语法没有问题。

App 的第一次画面加载也没有问题。

我以为会出错的地方，一个个检查下来都没有真正导致闪退。

期间我反复修改、重新构建、重新上传。

每次构建都要等待，结果安装以后还是闪退。

我一度怀疑，是不是自己用 AI 做出来的这个 App 从根本上就不稳定。

后来，我终于查看了 Android 的崩溃日志。

日志里最关键的两行是：

Invalid application ID MobileAdsInitProvider.attachInfo

看到这两行以后，调查方向终于变了。

问题根本不在那接近 9000 行的主文件里。

真正的问题在 app.json 生成的 Android 原生配置中。

我增加了 Google AdMob 广告，但 AdMob 的 App ID 没有被正确写入最终的 Android 配置。

结果就是：

Android 在启动 App 时，会先初始化广告服务。

广告服务发现 App ID 无效，便直接让整个应用崩溃。

这个过程发生在 JavaScript 代码开始运行之前。

所以，即使我在代码里写了错误处理，也完全没有作用。

因为 App 在执行到那些代码之前，就已经关闭了。

这里还有一个很容易弄错的地方。

AdMob 有两种看起来非常相似的 ID：

App ID: ca-app-pub-xxxxxxxxxxxxxxxx~yyyyyyyyyy

Banner Ad Unit ID: ca-app-pub-xxxxxxxxxxxxxxxx/zzzzzzzzzz

两者最大的区别是：

App ID 中间使用 ~ 广告单元 ID 中间使用 /

App ID 是整个应用的广告配置。

广告单元 ID 则是具体某个 Banner 或其他广告位置的编号。

如果填错位置，或者 App ID 没有正确进入 Android 的最终配置，项目仍然可能：

成功构建成功生成安装包成功上传 Google Play 但用户点击图标后立即闪退

最后，我重新整理了 app.json 中的 AdMob 配置，确认 App ID 和广告单元 ID 没有混用，然后重新构建版本。

问题终于解决了。

这次经历让我学到了几件事。

App 一打开就闪退，不一定是页面代码的问题

如果连首页都还没有显示，应用就直接关闭，应该先检查原生配置、第三方 SDK 和系统日志。

不要像我一样，一开始就盯着几千行代码反复查。

构建成功，不代表 App 一定能正常运行

能够生成安装包，只说明构建流程完成了。

并不代表每一个配置都正确，也不代表应用在真实手机上一定能启动。

一条崩溃日志，比反复猜测有效得多

我花了很长时间检查代码。

但真正帮助我找到问题的，只是日志中的两行文字：

Invalid application ID MobileAdsInitProvider

如果一开始就看日志，可能几个小时的折腾都可以避免。

使用 AI 做产品，真正困难的不是生成代码

AI 可以帮助写代码、检查问题、修改功能。

但当问题涉及正式版本、Android 原生配置、第三方服务和构建环境时，必须把实际日志和准确的配置一起检查。

否则不同的 AI 也可能不断猜测，让问题变得越来越复杂。

最让人崩溃的问题，往往只是一个很小的配置错误

我一直以为，问题一定藏在那接近 9000 行的文件里。

结果真正让我浪费一整天的，是文件外面的一个配置项。

对专业开发者来说，这可能只是一个很普通的问题。

但对一个没有编程背景、靠 AI 一步一步把产品做出来的人来说，这种问题真的会让人怀疑自己到底能不能继续做下去。

不过，至少这次我没有放弃。

折腾了一整天，最后还是把原因找了出来，也把版本修好了。

这款 App 叫 TransferIQ，主要用于比较外汇、跨境汇款和加密货币兑换路线。

感兴趣的话，可以直接在 Google Play 商店搜索 TransferIQ。

大家有没有经历过类似的情况？

花了几个小时检查代码，最后却发现问题根本不在代码里。

成功故事听了很多，但从没人告诉我中间那段"什么都不对"的日子该怎么过

transferiq — Mon, 13 Jul 2026 00:57:53 +0800

标题：成功故事听了很多，但从没人告诉我中间那段"什么都不对"的日子该怎么过

先说结论：我现在不是成功者。我是一个正在挣扎的独立开发者，今天写这篇不是来教你什么，是来说实话的。

我是谁

在巴西的韩国人，做了 8 年加密货币交易所运营（Upbit、Klook、TerraFarm），会韩语、英语、葡萄牙语。不会写代码，一行都不会。

6 周前用 Claude + GPT Codex 从零做了一个跨境汇款比较 App——TransferIQ（https://transferiq.orgWise、Revolut 这些传统汇款和 USDT）。把 P2P 这些加密路线放在一起比，告诉用户"你到底能收到多少钱"。

上架了 Google Play，建了静态网站，写了 SEO 页面，做了 UTM 追踪，在十几个社区发了帖。

到今天，三周了。

真实数据，不美化

新用户：175 回访用户：11 转化：0 Google 自然搜索点击：1 次（搜索词是"transferiq"——大概率是我自己搜的）收入：0

用户来源全是我自己手动发链接：solo.xin 28 次，Indie Hackers 18 次，okky 9 次，sideprojectors 8 次，google 7 次。

没有一分钱收入。没有一个用户给过反馈。没有一个人跟我说"这个功能有问题"或者"这个功能很好"。

我每天在干什么？

修 Bug。

不是用户报的 Bug，是我自己发现的。

流程是这样的：打开 App → 发现一个小问题 → 花半天修 → 修完发现另一个地方坏了 → 再修 → 看了竞品 → "我也该加这个功能" → 又花一天 → 周末推更新 → 周一看数据：还是 175 个用户。

最夸张的一次：我让 Codex"简化"网页版的汇款卡片 UI，它把 Wise 的手续费算成了 56.47%（实际不到 2%），把汇率范围显示从区间变成了单一数字，还把信任标签和路线徽章全部删掉了。我花了一整天排查四个根因才修好。

我很忙。每天都在 commit 代码。感觉很充实。

但用户数没动过。

我听过很多成功故事

"我做了一个 SaaS，第三个月 MRR 到了 $5K" "我的 side project 被 Product Hunt 推荐了" "我辞职全职做独立开发，半年实现了自由"

这些故事很激励人。但它们有一个问题：它们跳过了中间那段最难的部分。

没人告诉你：上线之后、用户来之前那段时间该干什么。

没人告诉你：每天看着不动的数据，同时还要说服自己"这是正常的，SEO 需要时间"有多难。

没人告诉你：当你发现自己花了一整周修了一堆没人会看到的 Bug 时，那种空虚感。

我现在就在这个阶段。

我到底搞明白了什么

昨天我终于想通了一件事：

我在一个没有观众的舞台上调灯光。

那些 Bug，只有在有人用的时候才重要。没人打开 Wise 的报价页，那 56% 的手续费就不是一个 Bug——它是一棵倒在无人森林里的树。

我的瓶颈不是代码质量，不是 UI 细节，不是功能缺失。

是没有人知道这个东西存在。

而我把 100% 的时间花在了代码上，0% 花在了让人知道它的事上。

我现在打算怎么做

定了一个规则，很极端，但我觉得有必要：

周一到周五不碰代码。只写内容，只做分发。代码只在周末改，只改用户反馈的问题——不是我自己发现的问题。

具体：

针对"韩国→巴西汇款"写韩语 SEO 长文，发到网站博客继续在各个社区写 building in public 的帖子（就像这篇）收入靠已经接入的 8 个交易所推荐链接，不再追汇款公司的 CPA（申请全被拒了，因为"你是比较网站，我们不跟比较网站合作"）不再看竞品然后加功能

为什么写这篇

因为我觉得独立开发社区里缺少一种声音：正在挣扎、还没找到答案的人的声音。

成功故事很重要，它给我们方向。但过程中的真实记录也很重要——它让我们知道，那些不确定的日子不是只有自己在经历。

我不知道 TransferIQ 最终会不会成。也许三个月后我会回来更新说"SEO 终于起效了，月活到了 1000"。也许我会回来说"我放弃了，学到了这些教训"。

不管哪种，我都会如实记录。

如果你也在经历类似的阶段——上线了，但什么都还没发生——我想听听你是怎么熬过来的。或者你也正在熬，咱们一起。

技术栈：React Native + Expo SDK 54 / Supabase / Netlify 产品：https://transferiq.org Google Play：已上架开发工具：Claude + GPT Codex（全程 AI 辅助，本人零代码基础）

我用 AI 独立做了一个跨境汇款和加密货币汇款比较工具

transferiq — Sat, 11 Jul 2026 12:59:54 +0800

大家好，我是一个非专业开发者。

我过去在金融科技和加密货币行业工作了大约 8 年，做过交易所运营，也接触过 Binance、Bybit、OKX、Bitget 等交易所的 broker / partnership 相关工作。

现在我住在巴西圣保罗，自己也经常需要做跨境汇款。

在这个过程中我发现一个问题：

很多人比较汇款成本时，只看手续费。
但真正重要的不是手续费，而是收款人最后实际收到多少钱。

因为里面还包括：

汇率差价
隐藏 spread
固定费用
本地银行费用
加密货币 on-ramp / off-ramp 成本
P2P 或交易所提现限制

尤其是 USDT / USDC 汇款，很多人会说 “链上手续费很低”，这句话只说对了一半。
链上转账可能很便宜，但从法币换成加密货币，再从加密货币换回本地货币的过程里，仍然会产生很多成本。

所以我做了一个小工具，叫 TransferIQ。

它的作用是把：

传统汇款服务
银行汇款
P2P
加密货币汇款路线
本地 off-ramp 路径

放在同一个 mid-market rate 基准下比较，尽量显示用户最终可能收到的实际金额，而不是只看表面手续费。

网站：

https://transferiq.org

Android App：

https://play.google.com/store/apps/details?id=com.jkim1285.TransferIQMobile

这个项目目前还在很早期。
我不是专业开发者，主要是靠 AI 辅助开发，所以过程中也踩了很多坑。

比如最近我发现 web 版本和 Android app 的部分计算逻辑开始出现差异。
这让我意识到，对于金融类计算工具来说，UI 可以不同，但核心 quote engine 必须统一。

接下来我准备重点做几件事：

把 web / app 的计算逻辑统一成 shared quote engine
增加 golden test
增加 web / app parity test
检查 provider filter 和 crypto rate source
避免同一个输入在不同平台出现不同结果

目前这个项目没有大团队，也没有融资，就是一个人边做边学。

如果你们平时有跨境汇款、外汇、USDT/USDC 汇款、off-ramp 或 fintech 产品相关经验，欢迎给我一些建议。

也欢迎直接试试看这个工具。
如果发现结果不合理、国家/币种支持不对、或者 UI 有问题，也可以告诉我。

一个不会写代码的人，终于在 AdMob 上赚到了第一笔收入

transferiq — Fri, 10 Jul 2026 01:11:44 +0800

老实说，这个数字真的很小。

预计收入只有 0.06 美元，广告展示次数也只有 83 次。

对很多人来说，这可能根本不算什么。

但对我来说，它有一点不一样。

我原本并不是开发者，也不会写代码，甚至一开始连怎么发布应用都不知道。

但借助 AI，我一步一步做出了网站，开发了 Android 应用，完成了 Google Play 的发布流程，今天又终于把 Google AdMob 广告横幅真正接入到了应用里。

过程并不轻松。

为了一个广告横幅，我重新构建应用、重新生成 AAB 文件，也处理了不少配置问题。

最后，虽然收入非常微薄，但它真的出现了。

我觉得最重要的并不是 0.06 美元本身。

而是这个数字意味着：

真的有用户进入过我的应用。广告真的出现在了用户的屏幕上。我做出来的东西，开始在现实世界里运转。

这还只是一个非常小的开始。

但从什么都没有，到做出网站、发布应用、接入广告，再看到真实用户留下的痕迹和第一笔收入。

对我来说，这已经是一个很有意义的起点。

这不是什么巨大的成功。

但至少，我已经开始做出一个 “真正能够运行的东西”。

网站正常，Android 应用却出了问题：我才发现同一个产品正在慢慢变成两套系统

transferiq — Thu, 09 Jul 2026 06:43:55 +0800

今天我几乎没有开发任何新功能。

我花了大半天时间，排查一个让我越来越不安的问题：

同一个产品，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 更重要的问题：

如果没有系统性约束，同一个产品真的会在不同平台上慢慢变成两个不同的产品。

产品手记｜App 上线后我才发现：AI 编程最难的不是生成代码，而是防止它破坏已经正常的功能

transferiq — Wed, 08 Jul 2026 05:09:47 +0800

两个月前，我还是一个几乎不会写代码的人。

我做产品、运营、FinTech 和 Crypto 很多年，但我不是软件工程师。

后来因为一个很简单的想法，我开始用 AI 做自己的产品。

这个产品叫 TransferIQ。

最开始，我只是想解决一个自己真实遇到的问题：

跨境汇款时，大家总是在比较 “手续费”，但真正重要的其实是：

对方最后到底能收到多少钱？

于是我开始做。

从一个简单的 idea，到 Web，再到 Android App，最后真的上线 Google Play。

第一篇产品手记里，我写了一个零基础的人，如何靠 AI 一步一步把产品做出来。

但产品上线以后，我发现了一个更大的问题。

我现在越来越觉得：

AI 编程最危险的地方，不是它写不出代码。

而是它会在修复一个问题的时候，悄悄破坏另一个已经正常工作的功能。

一、AI 修好了新 Bug，但旧 Bug 又回来了

这是我最近真实遇到的问题。

TransferIQ 需要比较不同国家、货币、金额区间、汇款服务商和 Crypto 路径。

表面上看只是：

输入金额选择 USD 选择 BRL 查看结果

但实际逻辑远比 UI 复杂。

例如，高金额转账和新兴市场货币的 spread，不能简单使用同一个参数。

我发现当金额达到 10,000 以上时，某些路线的估算结果过于乐观。

于是我增加了一套逻辑：

CORRIDOR_SPREAD_FLOOR

简单来说，就是根据：

国家/市场类型
金额区间
Provider 类型

设置最低 spread floor。

经过实际报价对比后，结果明显更接近真实市场。

问题解决了。

然后我让 AI 修改另一个功能。

它也修改成功了。

但几天后，我突然产生了一个问题：

“等等……之前那个 spread floor 逻辑还在吗？”

我去检查代码。

从那一刻开始，我意识到一个很现实的问题：

AI 可以非常快速地修改大型文件。

但在重构、替换函数、整理代码的时候，它也可能删除一个你花了很多时间验证的旧逻辑。

最危险的是：

App 依然可以正常启动。

没有报错。

按钮也能点击。

但业务结果可能已经错了。

二、“App 能打开” 和 “产品正常” 完全是两回事

以前我的测试方式很简单：

App 启动 ↓ 页面正常 ↓ 按钮能点 ↓ 没有红色报错 ↓ 完成

现在我觉得这种方式很危险。

尤其是 FinTech 产品。

至少要分成三个问题：

App 能不能打开？
功能能不能运行？
结果是否依然正确？

这三个完全不同。

最近我还遇到另一个真实问题。

在 Crypto off-ramp 页面里：

USDT → BRL

应该显示巴西本地交易所。

但修改后，一些字段突然变成：

undefined

一开始看起来像 UI Bug。

实际上不是。

真正的问题是：

新的数据结构和旧组件期待的字段格式不同。

最后我增加了一层适配逻辑：

adaptOffRampRow

它负责把不同来源的数据转换成 UI 能理解的统一格式。

问题解决。

但我马上又想到：

“下一次 AI 大规模修改这个文件时，它会不会把 adaptOffRampRow 删掉？”

三、我开始不再相信 “已修复”

以前 AI 告诉我：

“问题已经修复。”

我会很高兴。

现在 AI 告诉我：

“问题已经修复。”

我的第一反应是：

“那你这次又破坏了什么？”

听起来像玩笑。

但现在已经变成我的真实工作流程。

以前：

描述问题 ↓ AI 修改 ↓ 视觉确认 ↓ 继续开发

现在：

定义问题 ↓ 先确认哪些旧逻辑绝对不能消失 ↓ AI 修改 ↓ 检查关键函数是否还存在 ↓ 测试真实业务场景 ↓ 与实际数据对比 ↓ 最后才 Build

四、我甚至开始使用非常原始的方法

没有什么高级技术。

有时候我只是直接搜索关键代码是否还存在。

例如：

CORRIDOR_SPREAD_FLOOR

adaptOffRampRow

或者某些不能被删除的 Partner Link。

在 Windows 里，我甚至会用这种简单方法：

findstr /C:"CORRIDOR_SPREAD_FLOOR" App.js

findstr /C:"adaptOffRampRow" App.js

这当然不能代替自动化测试。

也不是什么优雅的工程方案。

但对一个人开发、同时大量使用 AI 的 Solo Builder 来说，它很实用。

我现在的原则是：

不要只确认 “新代码有没有进来”。

还要确认：

“重要的旧代码有没有消失。”

五、我开始测试真实场景，而不是只测试按钮

现在每次准备新的 Android Build，我会检查具体业务场景。

例如：

USDT → BRL

Mercado Bitcoin、Bitso 等本地交易所是否正常显示？

有没有 undefined？

Crypto → KRW

Upbit 是否被错误分类为 P2P？

还是正确显示为本地直接交易路径？

10,000 USD → BRL

估算结果是否和实际观察到的市场报价差距太大？

Partner Link

修改代码后，注册链接有没有被 AI 悄悄替换或删除？

Light Mode

代码没报错不代表用户看得清。

文字颜色是否真的有足够对比度？

这些问题都不是：

“代码能不能运行？”

而是：

“产品是不是仍然正确？”

六、多个 AI 一起使用时，问题更明显

我会同时使用多个 AI 工具。

一个 AI 修 Bug。

另一个 AI 重构。

另一个 AI 改 UI。

另一个 AI 帮我分析数据。

然后会出现一种非常荒谬的情况。

AI A：

“这个函数非常重要，必须保留。”

AI B：

“这个函数看起来重复，我已经删除。”

AI C：

“检测到旧功能丢失，我已经恢复。”

而我坐在中间。

最后真正要判断产品是否正确的人，还是我。

七、AI 没有消灭工程，它只是改变了困难的位置

我依然不是软件工程师。

这一点没有改变。

但两个月做完并上线一个真实产品以后，我越来越确定：

AI 的确大幅降低了 “写代码” 的门槛。

以前最难的问题可能是：

“这个代码怎么写？”

现在越来越像：

“这个修改会不会破坏旧功能？”

“这个结果真的符合业务逻辑吗？”

“AI 为什么删除这个函数？”

“另一个 AI 是否推翻了之前已经验证的决定？”

“代码能运行，但产品真的正确吗？”

这可能就是 Prototype 和 Real Product 最大的区别。

Prototype：

只需要成功一次。

Real Product：

下一次修改后还要继续工作。

再下一次修改后也要继续工作。

然后再下一次。

八、现在我的习惯变了

每次 AI 说：

“修复完成。”

我都会问自己：

“这次它可能破坏了什么？”

老实说，这个问题比我学习更复杂的 Prompt 技巧更有帮助。

因为 Prompt 可以让 AI 更快地产生代码。

但流程，才决定一个产品能不能长期活下去。

目前 TransferIQ 还在持续更新。

Web：

https://transferiq.org

Android：

https://play.google.com/store/apps/details?id=com.jkim1285.TransferIQMobile

如果你对跨境汇款、FX、Crypto off-ramp 有兴趣，可以直接试试。

这是一个真实在线运行的产品，不是 Demo。

我也非常欢迎直接的反馈：

哪个地方难理解
哪个结果看起来奇怪
哪个 UI 不好用
哪个国家或货币应该增加

最后也想问问其他使用 AI 编程的 Solo Builder：

你们遇到过这种情况吗？

AI 修复了一个 Bug，但同时让一个几天前已经解决的问题重新出现。

你们是怎么管理这种 “AI 回归问题” 的？

两个月，零基础，一个人：我用 AI 把一个 idea 做成了上线的 App（附踩坑记录）

transferiq — Tue, 07 Jul 2026 07:54:08 +0800

先说结论：我不会写代码，但我用 AI 在两个月里做出了一个 Web + Android 双端、已经上线的产品。这篇不吹方法论，只讲我真实的流程和踩过的坑。

背景：我在金融科技和加密货币行业干了 8 年，交易所运营、跨境支付、FX 这些懂，但代码一直是我的短板。今年投了 100 多份简历几乎全被拒，我不想再空口解释自己能做什么，就决定直接做个东西出来证明。

做的是 TransferIQ——一个跨境汇款比较工具。它不碰你的钱、不做兑换，只在你正式下单前，帮你把汇款、FX、加密货币、稳定币这些路线按"最终到手金额"排出来对比。这个领域我懂，缺的只是把它变成产品的能力，而这块我用 AI 补上了。

我的技术栈和分工：

App：React Native / Expo；Web：HTML；后端与分析：Supabase
核心是一个共享的报价引擎（quoteEngine.js），Web 和 App 共用一套逻辑，避免两端算出不同结果
三个 AI 分角色：Claude 管架构和调试，Codex 写代码，GPT 做交叉验证

从 0 到 Google Play 内测大概 1 周，从 0 到真正上线大概 2 个月。

真正让我抓狂、而且我在任何地方都没搜到过的一个坑：我的 App.js 只要经过 Google Drive 中转，UTF-8 就会损坏。文件本地好好的，同步一圈回来某些字符就悄悄坏了，App 直接崩。更坑的是，我用 Codex 修好之后，它会在后面某个 session 里又悄悄把修复改回去。我修一次，它退一次。

最后的应对很土但有效：定了一条铁律——任何编辑之前先 grep 一遍文件，确认没被改回去，绝不相信"上次已经修好了"。这条规矩救了我很多次。

其他坑（EAS 构建的 Kotlin 版本冲突、Google Play 身份验证反复被拒）都花了时间，但那些能搜到、能解决，就不展开了。

我知道它现在还很粗糙，是个早期产品。但作为一个不写代码的人，能靠 AI 把想法做到上线，两个月前我是不敢想的。

想问问同样在用 AI 做独立开发的各位：你们觉得非开发者用 AI，天花板到底在哪？哪些部分 AI 已经够用，哪些还是绕不开真的懂代码？

（产品：transferiq.org）