做 AI 编程项目时，很多人容易陷入两个极端。
一个极端是完全不做架构设计，直接让 AI 开写。另一个极端是让 AI 给出一套非常“豪华”的方案：微服务、消息队列、缓存、监控、Kubernetes，什么都上。
这两个极端都不适合第一版产品。
这次个人记账 App 的目标很明确：做一个轻量、可用、能验证核心价值的 MVP。所以架构设计的标准不是“技术上多先进”，而是：
- 能不能快速落地
- 能不能稳定维护
- 能不能支持后续继续迭代
这篇讲我怎么用 AI 把这个项目的技术方案收敛下来。
架构设计阶段，我先让 AI 回答什么问题
对这个记账 App，我没有一开始就让 AI 直接选技术栈。
我先让它回答 5 个问题：
- 前端用什么形态承接输入和展示
- 后端怎么组织识别、预算、账单和统计逻辑
- 数据库存哪些核心对象
- 语音怎么接，不要把链路做复杂
- 第一版用什么部署方式最稳
这几个问题其实都指向一个核心原则：第一版不要为了未来可能性过度设计。
为什么最后不是做成“纯前端本地 App”
如果只是一个更简单的练手项目，其实完全可以先做成：
- 前端页面
- 本地 localStorage
- 无后端
但这次项目没有这么做，原因有 3 个：
- 这个产品的核心不是表单录入，而是“识别后再保存”。
- 预算、统计、提醒这些逻辑更适合在服务端统一口径。
- 后续还要支持语音转文字、查询类自然语言和数据库留存。
如果第一版就把数据和识别逻辑都放在前端，虽然也能跑，但后面演进到真正可持续的产品形态时，会有明显重构成本。
所以这个项目需要一个后端，但不需要一个重后端。
最后收敛出的技术栈
这次最终确定的技术栈是：
- 前端：Vue 3 + Element Plus
- 后端：Python + FastAPI
- 数据库：PostgreSQL
- 识别：规则引擎
- 语音：现成语音转文字服务
- 架构：单体应用 + 模块化分层
这个组合的重点不在于“最流行”，而在于它和目标匹配。
flowchart LR
A["Vue3 + Element Plus"] --> B["FastAPI"]
B --> C["Parser 识别模块"]
B --> D["Budget 预算模块"]
B --> E["Transaction 账单模块"]
B --> F["Stats 统计模块"]
B --> G["Alert 提醒模块"]
D --> H["PostgreSQL"]
E --> H
F --> H
G --> H
为什么前端选择 Vue 3 + Element Plus
前端这块，目标是尽快把 4 个核心页面做出来：
- 首页
- 记一笔页
- 账单页
- 统计页
这个项目的 UI 难点不是复杂交互，而是：
- 录入要轻
- 信息要清楚
- 移动端也能正常用
Vue 3 的优势在于：
- 上手快
- 页面型应用开发效率高
- 组合式 API 适合小中型项目
Element Plus 不是最“潮”的移动端方案，但它足够成熟，组件可复用程度高，用来搭记账 App 的首版 Web MVP 很合适。
这里有一个现实判断：第一版重点是验证功能闭环，不是做设计语言创新。
为什么后端选择 FastAPI
这个项目的后端并不复杂，但它有清晰的模块边界：
- 预算模块
- 账单模块
- 分类模块
- 统计模块
- 提醒模块
- 识别模块
FastAPI 很适合这种场景，原因也很直接：
- API 开发快
- Schema 定义清楚
- 和 Pydantic、SQLAlchemy 配合自然
- 很适合先把接口跑通，再逐步补强
相比一上来用更复杂的企业级框架，FastAPI 在这个项目阶段的性价比更高。
为什么数据库直接选 PostgreSQL
很多第一版项目喜欢先用 SQLite。
如果只是一个本地工具，这样没问题。但这次项目一开始就明确了几个需求：
- 数据要长期存储
- 后端要和真实数据库联调
- 预算、账单、统计都要有一致口径
- 后面要考虑部署
所以直接用 PostgreSQL 更合理。
它带来的好处是：
- 关系型数据天然适合预算、分类、账单这种模型
- 迁移工具链成熟
- 后面做聚合统计也更自然
这个项目最终的核心表也比较清晰：
userscategoriesmonthly_budgetstransactions
为什么识别先用规则引擎，而不是直接上大模型
这个点是很多 AI 产品最容易误判的地方。
一看到“自然语言记账”，很多人会默认应该用 LLM 去做解析。
但这个项目的第一版没有这么做，而是选择：
规则引擎优先。
原因很现实：
- 成本低
- 结果更稳定
- 容易做单元测试
- 对高频表达覆盖已经够用
比如这些输入：
我这个月预算1000元今天加油300元昨天晚上吃饭花了58今天收到工资5000元
这类表达用规则引擎完全可以做出稳定结果。
第一版先把高频表达识别稳定，比一开始追求“什么都能理解”更重要。
为什么语音单独拆成“转文字”能力
语音链路很容易被设计复杂。
但这次我刻意把它拆得很干净：
语音输入 -> 语音转文字 -> 走同一套文本解析链路
这样做的好处非常明显：
- 语音和文字只共用一套解析逻辑
- 后端不需要单独维护两套识别分支
- 后续替换语音服务时，不会影响预算/账单识别规则
这个决策其实是在给未来降成本。
项目最终采用的是“单体应用 + 模块化分层”
这个项目没有拆微服务，也没有为了“架构好看”做很多抽象层。
最终保留的是这种结构：
apiservicesrepositoriesmodelsschemasparser
这是一个很典型的模块化单体结构。
它的好处是：
- 每层职责清楚
- 对 AI 来说也更容易理解和修改
- 后面继续加功能时，不容易写散
对于这种规模的项目，这种结构已经足够。
这一版架构真正解决了什么问题
如果把这套方案总结成一句话，它解决的是：
如何用尽量少的复杂度，把一句话输入、识别、保存、统计和提醒这条链路打通。
具体来说：
- 前端负责输入、确认和展示
- 后端负责规则识别、数据校验和业务聚合
- PostgreSQL 负责真实存储
- 规则引擎负责第一版的高频语义解析
- 语音只作为文本输入的上游，不污染核心业务链路
这就是一个“够用且能持续迭代”的第一版架构。
一个适合直接复用的提示词模板
如果你也想让 AI 帮你做类似的架构设计，可以这样问：
下面是当前产品的 MVP 需求：
<粘贴需求分析结果>
请帮我做第一版技术架构设计。
要求：
1. 优先简单可维护
2. 不要过度设计
3. 给出推荐技术栈和理由
4. 说明前端、后端、数据库、识别、部署分别怎么做
5. 输出推荐模块划分
6. 标出未来扩展点
约束：
- 第一版优先验证核心价值
- 不要为了未来功能提前做复杂抽象
- 技术选型以交付速度和维护成本为先
最后
AI 很会给出“看起来很强”的方案，但真正有价值的架构设计，不是名词越多越好，而是它能不能匹配项目阶段。
这个记账 App 的架构收敛过程让我更确定一件事：
第一版产品最需要的不是大架构，而是能支撑主链路跑通的小架构。
下一篇我会继续写：这个项目的数据库、接口和规则引擎是怎么拆出来的，以及为什么自然语言产品第一版一定要把“识别结果确认”这一步保留下来。
如果你最近也在做 AI 项目选型，纠结该不该一开始就上复杂架构，或者你手里已经有一套方案，但不确定是不是过度设计了，可以直接私信我。我最近在系统整理 AI 编程实战案例，也在做 AI 代码审查、单元测试补齐和 AI 编程流程咨询。
