很多人写 AI 编程内容时，最容易省略的一段，就是联调。

因为前面让 AI 写需求、写接口、写页面，看起来都很顺。

但项目一旦进入真实联调，问题就会从“代码能不能生成”变成“系统能不能真正跑起来”。

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

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

早期联调时，最直接的阻塞不是 parser，也不是接口实现，而是 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 做项目，建议你把联调当成一个独立阶段认真对待。

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