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

transferiq(TransferIQ) · 2026年07月08日 · 28 次阅读

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

我做产品、运营、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 产品。

至少要分成三个问题:

  1. App 能不能打开?
  2. 功能能不能运行?
  3. 结果是否依然正确?

这三个完全不同。

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

在 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,我会检查具体业务场景。

例如:

  1. USDT → BRL

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

有没有 undefined?

  1. Crypto → KRW

Upbit 是否被错误分类为 P2P?

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

  1. 10,000 USD → BRL

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

  1. Partner Link

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

  1. 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 回归问题” 的?

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请 注册新账号