我用 AI 做记账 App：测试、部署和上线检查，才是项目能不能交付的分水岭

很多 AI 编程案例到"页面能打开"就结束了。

但真实项目不是这样。

页面能打开，通常只代表一件事：它大概能演示。

而一个项目能不能真正交付，还要看后面的三件事：

核心能力有没有测试保护
本地和真实环境有没有跑通过
部署和上线检查是否说得清楚

这篇就讲这个个人记账 App 最后一段工作：测试、部署和上线准备。

为什么我不把"能运行"当成"能交付"

这个项目做到中后期时，其实已经具备这些能力了：

预算设置
一句话记账
账单保存
首页统计
分类支出
预算提醒
查询类自然语言
语音录入 MVP

如果只看功能演示，已经挺完整。

但如果要问：现在这个项目能不能交付给别人继续维护，或者能不能往线上放？

答案就不能只看页面。

因为后面还要回答这些问题：

识别规则有没有测试
统计逻辑有没有测试
异常提示有没有测试
数据库迁移能不能执行
默认数据能不能初始化
前端生产构建能不能通过
部署方式有没有说明

这些才是真正决定项目是否可交付的部分。

这个项目里，测试首先保护的是规则和统计

自然语言记账项目，最脆弱的地方其实不是 UI，而是：

parser 规则
统计口径
提醒逻辑

因为这些地方一旦错了，用户很难第一时间发现，但影响会直接传递到数据和结论上。

所以这个项目后面优先补齐的是：

test_parser_service.py
test_api_integration.py
test_stats_service.py
test_alert_service.py

Parser 测试
主链路稳定
API 集成测试
Stats/Alert 测试
前端构建验证

这种测试结构的好处是很清楚的：

parser 测试保证识别规则不会随便回归
API 集成测试保证主链路能打通
stats 测试保证预算、支出、收入、结余口径一致
alert 测试保证提醒规则可控

为什么这个项目的测试是高价值测试，而不是形式测试

AI 很容易写出很多"看起来覆盖率不错"的测试，但真正有价值的测试，是它能保护最可能出问题的地方。

这个项目里，高价值场景包括：

预算输入能否识别成当月预算
账单输入能否识别为正确分类
最近 N 天、本周、上周查询是否返回正确结果
预算已用、预算剩余是否口径一致
预算接近阈值和超预算时，提醒是否正确

这些测试一旦存在，后面继续改 parser 或统计逻辑时，心里会稳很多。

本地验证，不能只跑单元测试

除了测试，这个项目还做了几轮不同层次的验证：

1. 后端测试

真实执行过的命令包括：

powershell 复制代码

.\.venv\Scripts\python.exe -m pytest tests/test_parser_service.py tests/test_api_integration.py tests/test_stats_service.py tests/test_alert_service.py

结果是：

69 passed

2. 前端生产构建

powershell 复制代码

npm run build

结果：

构建通过

3. 服务级 smoke

这个项目还额外做过一轮非常有价值的验证：

临时数据库迁移
seed 默认用户和分类
启动后端
调预算、账单、查询、统计、提醒接口

数据库迁移
Seed 初始化
Health 检查
Smoke 验证
上线准备完成

这一步的意义在于：它验证的不是"某个函数对不对"，而是"主链路组合在一起能不能工作"。

联调和部署阶段，真实问题才会暴露出来

这个项目在真实联调和上线准备过程中，陆续暴露出过这些问题：

PostgreSQL 目标地址不可达
Alembic 和真实数据库状态不一致
前端本地开发被 CORS 拦截
前端默认 API 地址在生产环境下不合理
Docker 构建路径有问题
本地后台进程会被执行环境回收

这些问题有一个共同点：

如果你只停留在"代码已经生成"，是看不到它们的。

所以我越来越觉得，AI 编程真正的分水岭不是生成代码，而是你有没有把项目往"真实运行环境"再推一层。

为什么部署骨架必须留痕

这个项目后面补了几类部署相关文件：

backend/Dockerfile
frontend/Dockerfile
deploy/docker-compose.yml
deploy/.env.backend.example
nginx 代理配置

这类文件的价值不只是为了"某天能上线"，更重要的是让后面接手的人一眼知道：

前后端怎么启动
数据库怎么注入
迁移什么时候执行
默认数据怎么初始化
前端怎么访问后端

这就是交付感。

很多 AI 项目看起来代码不少，但没有这些留痕文件，别人几乎接不下去。

"完整测试"和"真正上线"之间还差什么

这次项目的一个很真实的结论是：

完整测试可以做完，但正式上线不一定能在同一时间完成。

因为上线除了代码和测试，还依赖：

目标服务器
运行方式
域名与 HTTPS
数据库白名单
日志和监控
进程守护方式

这些都不是 AI 单靠仓库代码就能凭空解决的。

所以我更推荐一个务实的说法：

测试通过
部署骨架就绪
上线条件已明确
真正发布依赖目标环境

能跑通
页面能打开
接口能返回
功能能演示
能交付
测试通过
迁移可执行
部署方式明确
已知风险可说明
后续可维护

这种表达比"已经可上线"更专业，也更真实。

如果你要把 AI 项目做成交付物，至少要留这些东西

以这个记账 App 为例，我认为至少要有：

需求和 MVP 文档
技术方案说明
数据模型和 API 设计
开发迭代留痕
测试结果
部署方式说明
已知限制和阻塞项

这些东西不是"为了写文档而写文档"，而是为了让项目可以继续演进、可以交给别人维护、可以在出问题时快速定位。

一个适合直接复用的提示词模板

如果你已经把功能做出来了，下一步想让 AI 帮你进入交付阶段，可以直接这样问：

text 复制代码

当前功能已经基本完成。

请继续帮我做交付收尾。

请输出：
1. 测试清单
2. 需要补的自动化测试
3. 本地验证步骤
4. 部署需要的文件
5. 上线前 checklist
6. 已知风险和阻塞项

要求：
- 区分"代码问题"和"环境问题"
- 优先保证可运行、可验证、可说明
- 不要假装已经上线成功

最后

这次记账 App 做到最后，我最大的感受是：

AI 编程的真正价值，不是把"写代码"这一步加速，而是把从需求、架构、开发、测试到上线准备的整个闭环都跑通。

如果你只看代码生成，AI 当然很强。

但如果你真的想做项目，后面的测试、联调、部署和留痕，才是把"一个 Demo"变成"一个可交付项目"的分水岭。

下一次如果你准备拿 AI 做小项目，不妨不要只问"能不能写"，也问一句：做完以后，我能不能验证、能不能部署、能不能交给别人继续做。