我用 AI 做记账 App：从骨架搭建到前后端联调，应该怎么推进

前面两步做完以后，项目已经有了：

• 需求边界
• MVP 范围
• 技术方案
• 数据模型
• API 清单
• 规则引擎思路

接下来才进入真正的开发阶段。

很多人到了这一步，会忍不住让 AI 一次性把前后端全写出来。

我不建议这样做。

因为真实项目里，最容易翻车的不是"AI 不会写代码"，而是你给它的改动范围太大，最后根本不知道哪一步出问题。

这篇就讲这个记账 App 是怎么从骨架开始，一步步推进到前后端联调的。

我没有让 AI 一次性做完整 App

这个项目的开发顺序，并不是：

需求 -> 架构 -> 一次性生成完整项目

而是拆成了几个可以独立验证的小闭环：

1. 先做后端骨架和数据库迁移
2. 再做 /api/parse
3. 再做预算、账单、分类接口
4. 再做统计和提醒
5. 最后接前端页面和联调

这个顺序的好处非常明显：

• 每一步都能单独验证
• 出问题时定位更快
• AI 改动范围容易控制

后端骨架
/api/parse
预算/账单接口
统计/提醒接口
前端页面
前后端联调
问题修复
继续迭代

第一阶段：先把后端骨架立住

这个项目的后端骨架最终包含这些模块：

• api
• core
• models
• schemas
• repositories
• services
• parser

这里最重要的不是目录好看，而是职责要清楚。

比如：

• models 负责 ORM 模型
• schemas 负责请求响应结构
• repositories 负责数据访问
• services 负责业务编排
• parser 负责规则识别

这一层搭起来以后，后面 AI 再补功能时，至少知道代码应该放哪里。

第二阶段：先打通 parse，而不是先做全部保存接口

在这个项目里，最小主链路的起点其实不是 transactions，而是 parse。

因为这款产品的核心价值不是"用户能手动填表"，而是"用户输入一句话，系统能识别出结构化结果"。

所以开发顺序里我优先落地了：

• 文本预处理
• 意图识别
• 金额提取
• 日期提取
• 收支判断
• 分类映射
• 结果校验
• /api/parse

这样做的价值是：先把这条最核心、最容易出歧义的逻辑单独跑起来。

如果这一步不稳，后面再堆预算、统计、前端页面，意义都不大。

第三阶段：补预算、账单、分类这三条持久化链路

当 /api/parse 能稳定返回结构化结果以后，后面的保存逻辑就比较清楚了。

这个项目后端后续补齐的是：

• POST /api/budgets
• GET /api/budgets/current
• POST /api/transactions
• GET /api/transactions
• GET /api/categories

这一步最重要的一个原则是：

不要让前端去拼业务逻辑。

比如：

• 当前月份预算怎么取
• 相同月份预算是否覆盖
• 分类是否存在
• 哪些分类允许收入/支出使用

这些都应该在后端统一处理。

否则 AI 很容易在前端写一套判断，后端再写一套判断，最后两边口径不一致。

第四阶段：首页统计和提醒一定要后端统一聚合

这个项目的首页和统计页不是简单把数据列表展示出来，而是要给出用户真正关心的信息：

• 本月预算
• 总支出
• 总收入
• 结余
• 剩余预算
• 分类支出
• 预算提醒

所以我没有让前端自己算，而是专门补了：

• GET /api/stats/overview
• GET /api/stats/categories
• GET /api/alerts/current

这样做有两个好处：

1. 统计口径只保留一份。
2. 后续无论前端页面怎么变，核心业务结果都不会分散在多个地方。

这一步对 AI 编程特别重要。

因为如果不把聚合逻辑收进后端，AI 后面很容易在多个页面里复制相似但不完全相同的计算代码。

第五阶段：前端不是先做大而全，而是先做 4 个核心页面

这个项目的前端最终只保留了 4 个 MVP 页面：

• 首页
• 记一笔页
• 账单页
• 统计页

这个选择看起来很朴素，但它非常符合第一版目标。

尤其"记一笔页"是整个产品里最关键的页面，因为它要同时承接：

• 文字输入
• 语音输入
• 示例引导
• 识别结果展示
• 用户确认保存

后续联调过程中，这个页面也自然成了问题最容易暴露的地方。

联调阶段，真实暴露了哪些问题

真实项目联调和"AI 一把生成代码"最大的不同，就是它会逼你面对很多环境和边界问题。

这个记账 App 在联调和本地运行过程中，真实遇到过这些问题：

• PostgreSQL 不可达，导致服务无法连库
• Alembic 迁移和真实数据库状态不一致
• 前端开发环境跨域，浏览器被 CORS 拦截
• 前端生产默认 API 地址不合理，部署后会失效
• 本地服务进程能启动，但不会长期驻留

联调问题
代码问题
环境问题
部署问题
接口逻辑错误
统计口径不一致
数据库不可达
CORS 拦截
Docker 配置错误
进程未常驻

这些问题里，有些是代码问题，有些不是。

但它们有一个共同点：如果你只让 AI 生成代码而不真正联调，你根本不会知道它们存在。

为什么"加引导和示例"比继续堆规则更值

这个项目后面还有一个很关键的产品调整：在记一笔页增加了"可以这样输入"的示例引导。

示例被分成两组：

• 记账与预算
• 查询支出与收入

比如：

• 今天加油300元
• 我这个月预算1000元
• 这个月餐饮花了多少
• 最近7天交通和餐饮一共多少

这一步看起来不像"核心功能"，但实际上对产品可用性提升很大。

因为自然语言产品的一个真实问题是：系统支持什么，用户往往不知道。

与其一直追着"再加更多规则"，不如先让已经支持的能力可见。

这也是 AI 编程里一个很现实的经验：

并不是所有问题都应该靠继续写代码解决，有时候更好的做法是优化用户输入预期。

开发阶段，我最看重的不是"写得快"，而是"每一步都能验证"

这个项目的推进节奏，本质上是：

补一块能力 -> 立即验证 -> 再补下一块

比如：

• parser 能不能识别预算和账单
• 持久化接口能不能正常写入
• 统计口径是不是一致
• 前端是不是能真实显示识别结果
• 语音输入是不是至少能走通 MVP

这比一次性让 AI 写完整项目，然后最后统一验收，风险要小得多。

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

如果你想让 AI 参与真实项目开发，可以试试这个方式：

现在进入开发阶段。

请按下面方式工作：
1. 先阅读当前代码结构，不要修改
2. 说明这一阶段最小可交付目标
3. 把任务拆成 3-5 个小步骤
4. 先只实现第一个小步骤
5. 修改后说明验证方法

约束：
- 不做无关重构
- 每一步都必须可运行或可验证
- 优先复用已有结构
- 如果涉及联调，先说明依赖条件

最后

这次记账 App 的开发过程让我更确认一件事：

AI 写代码真正的效率，不在于它一次生成多少文件，而在于你能不能把项目拆成多个可验证的小闭环。

先把骨架立住，再把主链路打通，再做联调，再补体验和异常，这样推进既快，也更稳。

下一篇我会继续写这个项目的最后一段：测试、部署和上线检查到底怎么做，以及为什么"能跑通"和"能上线"中间还差了很多真实工作。

。