很多人做 AI 编程项目，一上来就让 AI 生成页面、接口和数据库。
这样做的最大问题不是“生成得不够快”，而是你还没想清楚第一版到底要做什么。
这次我做的是一个个人记账 App，目标用户是刚开始工作、想控制日常开销的年轻人。这个项目非常适合拿来讲 AI 编程，因为它不算大，但业务规则是真实存在的：
- 预算和账单是两类不同输入。
- 收入和支出要区分。
- 分类要能统计。
- 识别失败时要有提示。
- 第一版不能做成复杂财务软件。
这篇先讲第一步：如何让 AI 帮我把想法收敛成可以开发的 MVP。
为什么不能一开始就写代码
如果你只给 AI 一句话：
帮我做一个个人记账 App。
它大概率会直接开始生成：
- 登录页
- 记账页
- 统计页
- 用户表
- 分类表
- 图表组件
- 一堆接口
看起来很快，但问题马上就会出现：
- 是个人用，还是多人共享？
- 支持文字输入，还是语音输入？
- 第一版要不要自定义分类？
- 预算提醒是不是必须做？
- 统计做到什么程度才算够？
这些问题不先想清楚，AI 写得越多，返工越多。
我是怎么描述这个项目的
我给 AI 的输入不是“列功能”，而是先说背景：
我想做一个个人记账 App。目标用户是刚开始工作、想控制日常开销的年轻人。
他们的问题是：每月不知道钱花到哪里，也不想使用复杂的财务软件，只想通过语音或者文字输入来记录账单，不用填写复杂的表格。
请先不要写代码，帮我做需求分析。
这段描述里有 3 个关键点：
- 用户是谁
- 用户现在的痛点是什么
- 产品体验要避免什么
尤其最后一点很重要。
“不想使用复杂的财务软件”这句话，实际上会直接影响后面的产品方案。它意味着第一版不能做重表单、不能做很长的录入流程，也不应该一开始就塞太多配置项。
需求分析阶段，我重点让 AI 输出什么
这一步我只要求 AI 回答几个核心问题：
- 用户是谁
- 核心使用场景是什么
- 第一版必须做什么
- 哪些功能先不要做
- 核心流程怎么走
- 数据对象有哪些
换句话说，这一步的目标不是“写文档”，而是“先把边界画清楚”。
对于这个记账 App，最终梳理出的核心使用场景是：
- 用户输入“我这个月预算1000元”，系统自动创建当月预算。
- 用户输入“今天加油300元”，系统自动识别为交通支出。
- 用户说一段语音，先转成文字，再完成识别和保存。
- 用户查看本月各类支出，知道钱主要花在什么地方。
- 用户接近或超出预算时，得到明确提示。
这 5 个场景已经足够支撑第一版产品价值。
MVP 不是功能越少越好，而是只做验证核心价值的那一部分
这个项目的 MVP 最终被拆成三层：
必须做：
- 文本记账
- 语音转文字记账
- 月预算设置
- 账单结构化识别
- 数据库存储
- 账单列表查看
- 基础统计
- 基础异常提示
- 默认分类体系
可以后做：
- 自定义分类
- 编辑和删除账单
- 更丰富图表
- 更复杂的自然语言查询
- 更细预算提醒
暂时不做：
- 一句话拆分多笔账单
- AI 理财建议
- 家庭账本
- 银行卡或支付平台同步
- 专业财务报表
这里最关键的，不是“功能分组”本身，而是为什么这么分。
比如“自定义分类”这件事，很多人第一反应会觉得很基础，应该第一版就做。
但对这个项目来说，第一版的目标不是“让用户做完整财务管理”，而是验证一句话输入和自动识别这件事是否真的能降低记账门槛。只要默认分类够覆盖常见场景，自定义分类完全可以后放。
这就是 MVP 的意义：优先验证价值，而不是优先堆满功能。
flowchart LR
A["产品想法"] --> B["目标用户"]
B --> C["用户问题"]
C --> D["核心场景"]
D --> E["MVP 功能"]
E --> F["暂不做功能"]
F --> G["可开发方案"]
需求一旦收敛，核心流程就会变清楚
在这个项目里，最重要的核心流程其实只有一条：
输入一句话 -> 识别预算或账单 -> 确认结果 -> 保存数据库 -> 首页/账单页/统计页更新
一旦这个闭环被定义清楚，后面的很多设计都会跟着收敛。
比如：
-
为什么要把
parse和save分开？ 因为用户需要先看识别结果，再确认是否保存。 -
为什么要保留原始输入？ 因为识别错误时，后面需要复盘用户到底说了什么。
-
为什么异常提示是第一版必须做？ 因为自然语言输入天然有歧义，不做提示就会直接影响用户信任。
你会发现，很多技术决策其实是需求阶段就种下的。
这个项目里，我刻意避免了哪些“看起来很高级”的需求
AI 很容易在需求阶段把产品往复杂方向推。
比如你一提“语音”，它可能继续建议：
- 连续多轮对话记账
- 自动语义纠错
- 对历史账单做智能消费建议
- 根据行为自动生成月报
这些都不是不能做，而是不适合第一版。
如果第一版连“今天加油300元”这种输入都还没稳定打通，就去做更复杂的智能能力，风险非常高。
所以这个项目在需求阶段最重要的一个判断其实是：
第一版不追求“像 AI 助手”，而是先把“轻量记账工具”做好。
需求分析阶段的产出，后面能直接复用
这一步不是空转。
它后面会直接变成：
- PRD 的骨架
- MVP 范围说明
- 核心流程图
- 数据模型草案
- 接口设计输入
- 测试验收标准
这也是为什么我不建议跳过需求分析。
AI 写代码很快，但真正拖慢项目的通常不是写代码，而是前面需求没收敛，后面所有人都在返工。
一个适合直接复用的提示词模板
如果你也想用 AI 做类似项目，可以直接用这段：
我想做一个【产品名称】。
目标用户是：【用户是谁】。
他们的问题是：【当前痛点】。
我希望产品体验是：【希望达成什么效果】。
请先不要写代码，帮我做需求分析。
请输出：
1. 目标用户
2. 核心使用场景
3. MVP 功能范围
4. 可以后做的功能
5. 暂时不做的功能
6. 核心用户流程
7. 关键数据模型
8. 验收标准
9. 还需要我确认的问题
要求：
- 不要过度设计
- 第一版优先验证核心价值
- 每个结论说明理由
最后
这次做记账 App，我最深的感受不是“AI 帮我省了多少代码时间”，而是：只要需求收敛得足够早，后面的架构、开发、测试都会顺很多。
AI 编程不是从代码开始，而是从定义问题开始。
下一篇我会继续写：这个记账 App 的架构是怎么收敛出来的，以及为什么我最后选了 Vue 3 + FastAPI + PostgreSQL + 规则引擎，而不是更复杂的一套方案。
