两个月前，我还是一个几乎不会写代码的人。
我做产品、运营、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 回归问题」 的？
