很多 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 测试保证提醒规则可控

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

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

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

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

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

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

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

1. 后端测试

真实执行过的命令包括：

.\.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. 前端生产构建

npm run build

结果：

• 构建通过

3. 服务级 smoke

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

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

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

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

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

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

这些问题有一个共同点：

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

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

为什么部署骨架必须留痕

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

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

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

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

这就是交付感。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

当前功能已经基本完成。

请继续帮我做交付收尾。

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

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

最后

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

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

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

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

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