很多 AI 编程案例到“页面能打开”就结束了。但真实项目不是这样。页面能打开通常只代表一件事它大概能演示。而一个项目能不能真正交付还要看后面的三件事核心能力有没有测试保护本地和真实环境有没有跑通过部署和上线检查是否说得清楚这篇就讲这个个人记账 App 最后一段工作测试、部署和上线准备。为什么我不把“能运行”当成“能交付”这个项目做到中后期时其实已经具备这些能力了预算设置一句话记账账单保存首页统计分类支出预算提醒查询类自然语言语音录入 MVP如果只看功能演示已经挺完整。但如果要问现在这个项目能不能交付给别人继续维护或者能不能往线上放答案就不能只看页面。因为后面还要回答这些问题识别规则有没有测试统计逻辑有没有测试异常提示有没有测试数据库迁移能不能执行默认数据能不能初始化前端生产构建能不能通过部署方式有没有说明这些才是真正决定项目是否可交付的部分。这个项目里测试首先保护的是规则和统计自然语言记账项目最脆弱的地方其实不是 UI而是parser 规则统计口径提醒逻辑因为这些地方一旦错了用户很难第一时间发现但影响会直接传递到数据和结论上。所以这个项目后面优先补齐的是test_parser_service.pytest_api_integration.pytest_stats_service.pytest_alert_service.pyParser 测试主链路稳定API 集成测试Stats/Alert 测试前端构建验证这种测试结构的好处是很清楚的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 passed2. 前端生产构建npm run build结果构建通过3. 服务级 smoke这个项目还额外做过一轮非常有价值的验证临时数据库迁移seed 默认用户和分类启动后端调预算、账单、查询、统计、提醒接口数据库迁移Seed 初始化Health 检查Smoke 验证上线准备完成这一步的意义在于它验证的不是“某个函数对不对”而是“主链路组合在一起能不能工作”。联调和部署阶段真实问题才会暴露出来这个项目在真实联调和上线准备过程中陆续暴露出过这些问题PostgreSQL 目标地址不可达Alembic 和真实数据库状态不一致前端本地开发被 CORS 拦截前端默认 API 地址在生产环境下不合理Docker 构建路径有问题本地后台进程会被执行环境回收这些问题有一个共同点如果你只停留在“代码已经生成”是看不到它们的。所以我越来越觉得AI 编程真正的分水岭不是生成代码而是你有没有把项目往“真实运行环境”再推一层。为什么部署骨架必须留痕这个项目后面补了几类部署相关文件backend/Dockerfilefrontend/Dockerfiledeploy/docker-compose.ymldeploy/.env.backend.examplenginx 代理配置这类文件的价值不只是为了“某天能上线”更重要的是让后面接手的人一眼知道前后端怎么启动数据库怎么注入迁移什么时候执行默认数据怎么初始化前端怎么访问后端这就是交付感。很多 AI 项目看起来代码不少但没有这些留痕文件别人几乎接不下去。“完整测试”和“真正上线”之间还差什么这次项目的一个很真实的结论是完整测试可以做完但正式上线不一定能在同一时间完成。因为上线除了代码和测试还依赖目标服务器运行方式域名与 HTTPS数据库白名单日志和监控进程守护方式这些都不是 AI 单靠仓库代码就能凭空解决的。所以我更推荐一个务实的说法测试通过部署骨架就绪上线条件已明确真正发布依赖目标环境能跑通页面能打开接口能返回功能能演示能交付测试通过迁移可执行部署方式明确已知风险可说明后续可维护这种表达比“已经可上线”更专业也更真实。如果你要把 AI 项目做成交付物至少要留这些东西以这个记账 App 为例我认为至少要有需求和 MVP 文档技术方案说明数据模型和 API 设计开发迭代留痕测试结果部署方式说明已知限制和阻塞项这些东西不是“为了写文档而写文档”而是为了让项目可以继续演进、可以交给别人维护、可以在出问题时快速定位。一个适合直接复用的提示词模板如果你已经把功能做出来了下一步想让 AI 帮你进入交付阶段可以直接这样问当前功能已经基本完成。 请继续帮我做交付收尾。 请输出 1. 测试清单 2. 需要补的自动化测试 3. 本地验证步骤 4. 部署需要的文件 5. 上线前 checklist 6. 已知风险和阻塞项 要求 - 区分“代码问题”和“环境问题” - 优先保证可运行、可验证、可说明 - 不要假装已经上线成功最后这次记账 App 做到最后我最大的感受是AI 编程的真正价值不是把“写代码”这一步加速而是把从需求、架构、开发、测试到上线准备的整个闭环都跑通。如果你只看代码生成AI 当然很强。但如果你真的想做项目后面的测试、联调、部署和留痕才是把“一个 Demo”变成“一个可交付项目”的分水岭。下一次如果你准备拿 AI 做小项目不妨不要只问“能不能写”也问一句做完以后我能不能验证、能不能部署、能不能交给别人继续做。