AI记账App联调避坑指南：5个真实踩坑经验

写AI编程内容时，最容易跳过的，就是联调这一环。

毕竟让AI写需求、写接口、写页面，看起来都很顺畅，但项目一旦进入真实联调，问题就从“代码能不能生成”切换成了“系统能不能真正跑起来”。

这次做记账App，联调过程中踩了几轮坑。回头看，最有价值的不是“最后跑通了”，而是中间那些真实的问题——它们基本都不是靠多写几段业务代码能解决的。

第一个坑：数据库没通时，别先怀疑业务代码

早期联调时，最直接的阻塞不是解析器，也不是接口实现，而是PostgreSQL根本没连通。

当时的现象很典型：

• 测试能过
• 前端能build
• 但真实联调走不下去

这类问题最容易让人误判成“是不是接口写错了”，其实先看环境更有效：

• 数据库服务是否真的启动
• 连接串是否正确
• 端口是否可达
• 账号密码是否能登录

这件事说明一个原则：

联调阶段先排环境，再排业务。

如果底层依赖都没通，继续让AI改业务代码，通常只会越改越乱。

第二个坑：迁移脚本不是“生成了就一定能用”

很多人会把migration当成半自动产物，觉得能生成就差不多了。

这次真实联调里，migration暴露了两个非常典型的问题：

1. 连接串里带%，Alembic配置解析会出问题
2. enum的创建逻辑重复，导致初始化冲突

这两个问题的共同点是：

• 单看ORM模型不一定能发现
• 不跑真实数据库很难暴露

所以现在对migration的态度会更保守：

• 模型设计是第一层
• migration草案是第二层
• 真库执行成功才算第三层

只有第三层过了，才算真的完成。

第三个坑：ORM枚举值和数据库枚举值，可能不是一回事

还有一个很容易被忽略的问题：

Python Enum默认写入的，未必就是想在PostgreSQL里保存的值。

比如代码里是EXPENSE、INCOME，但数据库枚举值可能定义成expense、income。

如果这件事没对齐，接口看起来都对，真正写库时就会报错。

这个坑很有代表性——很多问题不是“功能没写”，而是“系统边界没对齐”。

AI很会补代码，但边界对齐这件事，还是要靠人有意识地检查。

第四个坑：浏览器能打开前端，不等于前后端能联通

后面遇到的CORS，就是非常典型的一类联调坑。

前端页面明明起来了，后端接口也明明能调，但浏览器里就是报：

blocked by CORS policy
No 'Access-Control-Allow-Origin' header is present

这类问题本质上不是业务错误，而是运行方式问题。

尤其是本地开发时：前端127.0.0.1:5173，后端127.0.0.1:8000，只要不是同源，就要把跨域配置补上。

这也提醒我们，联调时要分清三层：

1. 服务是否启动
2. 接口是否可用
3. 浏览器是否允许访问

这三层不是一回事。

第五个坑：启动命令在本机能跑，不代表在自动化里也能跑

还有一个偏工程化、但很真实的问题：

Windows下用脚本起前端dev服务时，npm和npm.cmd的行为差异会直接影响能不能成功拉起进程。

这类问题特别容易被忽略——手工在终端里敲命令时可能没问题，但换成脚本、进程拉起或者自动化检查，行为就不一样了。

它背后的本质是：“人手执行成功”和“流程执行成功”不是同一个层级。

如果希望项目可重复启动、可重复验证，就不能只满足于“本地跑起来过一次”。

这5个坑有个共同点

回头看，这5个坑都不是那种“写错了一行业务逻辑”的问题。

它们更像是：

• 环境问题
• 边界问题
• 配置问题
• 运行方式问题

这也是为什么很多AI编程项目，前半段推进得特别快，后半段却卡很久。

因为前半段主要是在生成，后半段主要是在对齐。

而对齐这件事，比生成更接近真实工程。

现在怎么理解“联调”

以前很多人把联调理解成：前端调一下接口，返回数据就算完。

但这次做完以后，更愿意把联调理解成：

把代码、配置、环境、数据库、浏览器、启动方式全部接起来，看这个系统能不能稳定重复运行。

只有做到这一步，项目才从“看起来像能用”变成“真的能用”。

最后

这次记账App联调里最真实的5个坑，不是为了渲染“项目多难”，而是为了说明一件更实际的事：

AI可以把开发前半段大幅提速，但真正决定项目能不能落地的，往往是后半段这些看起来不性感的工程问题。

如果你也在用AI做项目，建议把联调当成一个独立阶段认真对待。

因为很多项目不是死在“写不出来”，而是死在“接不起来”。

来源：互联网