AI记账App开发全流程从骨架搭建到前后端联调详解

当需求边界、MVP范围、技术方案、数据模型、API清单和规则引擎思路都明确之后，项目才算真正进入了开发阶段。

很多人到了这一步，会倾向于让AI一次性生成前后端所有代码。但这其实是个陷阱。在真实项目中，最容易导致项目失控的往往不是“AI写不出代码”，而是你一次性让它修改的范围太大，导致问题层层叠加，最终连定位问题根源都变得异常困难。

这篇文章就来拆解一下，那个记账App是如何从搭建骨架开始，一步步推进到前后端联调的。

摒弃“一次性生成”的幻想

这个项目的开发路径，并非简单的“需求 -> 架构 -> 一次性生成完整项目”。取而代之的，是将整个工程拆解为几个可以独立验证的闭环：

1. 搭建后端骨架与数据库迁移
2. 实现核心的 /api/parse 接口
3. 补充预算、账单、分类等持久化接口
4. 完成统计与提醒功能
5. 最后接入前端页面并进行联调

这种顺序的优势显而易见：每一步都可以单独验证和测试，一旦出现问题，定位和修复的速度会快得多，同时AI的修改范围也被控制在了一个清晰的边界内，避免了“牵一发而动全身”的混乱。

第一阶段：构筑坚实的后端骨架

项目的后端骨架最终包含了几个核心模块：api、core、models、schemas、repositories、services 以及 parser。

这个阶段的关键不在于目录结构多么漂亮，而在于职责划分必须清晰。例如：

• models 专注于ORM模型定义
• schemas 负责请求与响应的数据结构验证
• repositories 处理数据访问逻辑
• services 编排核心业务流
• parser 则承载了最核心的规则识别引擎

先把这层骨架立起来，后续无论AI补充什么功能，代码都应该有明确的归属地，这为整个项目的可维护性打下了基础。

第二阶段：优先打通核心解析链路

在这个记账App中，最小可行产品的核心价值并非“用户能手动填写表单”，而是“用户输入一句话，系统就能准确识别出结构化结果”。因此，整个主链路的起点不是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 (当前提醒)

这带来了两个核心好处：一是统计口径在服务端保持唯一，确保数据一致性；二是无论前端页面如何迭代变化，核心的业务计算逻辑都集中在一处，不会分散。这对于AI编程尤为重要，能有效避免它在多个页面中复制粘贴那些相似却可能出错的计算代码。

第五阶段：前端聚焦核心页面，而非大而全

项目的前端MVP最终只保留了四个核心页面：首页、记一笔页、账单列表页和统计页。这个选择看似朴素，却精准地服务于第一版的核心目标。

其中，“记一笔页”是整个产品的关键枢纽，它需要同时承载文字输入、语音输入、示例引导、识别结果展示以及用户确认保存等一系列交互。在后续的联调过程中，这个页面也自然成为了问题最集中、最需要打磨的地方。

联调阶段：暴露的真实环境问题

真实的项目联调，与“AI一次性生成代码”的理想场景最大的不同在于，它会迫使你面对各种环境和边界问题。在这个记账App的联调与本地运行过程中，就真实遭遇了以下挑战：

• PostgreSQL数据库连接失败，导致服务无法启动
• Alembic数据库迁移脚本与当前数据库状态不一致
• 前端开发环境跨域请求被浏览器CORS策略拦截
• 前端生产环境配置的API地址不合理，部署后必然失效
• 本地服务进程能够启动，但缺乏守护机制，不会长期驻留

这些问题中，有些属于代码缺陷，有些则是环境配置或部署策略问题。但它们都有一个共同点：如果你只让AI生成代码而不进行真实的集成与调试，你根本不会意识到它们的存在。

优化引导：比堆砌规则更重要的体验提升

项目后期进行了一个关键的产品调整：在“记一笔”页面增加了“可以这样输入”的示例引导。示例被分为“记账与预算”和“查询支出与收入”两组，例如：“今天加油300元”、“我这个月预算1000元”、“这个月餐饮花了多少”、“最近7天交通和餐饮一共多少”。

这一步看似不属于“核心功能”，但对产品可用性的提升是巨大的。自然语言交互产品的一个普遍痛点是：用户并不清楚系统到底支持什么指令。与其无止境地优化识别规则，不如先让已支持的能力清晰可见。这也揭示了AI编程中的一个现实经验：并非所有问题都需要通过编写更多代码来解决，有时优化用户的输入预期和引导，能取得事半功倍的效果。

核心开发哲学：可验证的渐进式推进

回顾整个开发过程，最看重的并非“写得快”，而是“每一步都能验证”。项目的推进节奏本质上是：补充一块能力 -> 立即验证 -> 再补充下一块。

例如，解析器（parser）能否准确识别？持久化接口能否正确写入数据？前后端的统计口径是否一致？前端能否真实展示识别结果？语音输入链路能否走通MVP？这种小步快跑、持续验证的方式，远比一次性让AI生成全部代码，最后再进行整体验收的风险要低得多，可控性也更强。

一个可直接复用的协作提示词模板

如果你也希望在真实项目开发中引入AI协作，可以尝试以下提示词框架：

现在进入开发阶段。请按下面方式工作：
1. 先阅读当前代码结构，不要修改
2. 说明这一阶段最小可交付目标
3. 把任务拆成 3-5 个小步骤
4. 先只实现第一个小步骤
5. 修改后说明验证方法约束：
- 不做无关重构
- 每一步都必须可运行或可验证
- 优先复用已有结构
- 如果涉及联调，先说明依赖条件

最后

通过这次记账App的开发，一个结论变得更加清晰：AI编程真正的效率，不在于它一次性能生成多少行代码或多少个文件，而在于你是否能将一个复杂项目拆解成多个可独立验证的小闭环。

遵循“先立骨架，再通主脉，后做联调，终补体验”的推进顺序，项目不仅进展更快，稳定性也更高。在接下来的部分，将会探讨这个项目的最后环节：测试、部署与上线检查，并解释为什么“能跑通”和“能上线”之间，往往存在着大量容易被忽略的实际工作。