很多 AI 编程翻车，不是因为代码生成能力差，而是因为需求一开始就是糊的。
你说“做一个记账 App”，AI 就会开始生成页面、接口、数据库表。看起来效率很高，但很快会遇到问题：
- 记账是个人用还是多人用？
- 支出分类能不能自定义？
- 是否需要预算提醒？
- 是否支持多账户？
- 数据能不能导出？
- 第一版到底做到哪里算完成？
如果这些问题没想清楚，AI 写得越快，返工越快。
所以我建议：正式写代码前，先让 AI 做需求分析。
需求分析不是写长文档
很多程序员一听需求分析，就想到几十页 PRD。
这不是我们要的。
AI 编程里的需求分析，目标很简单：把一个模糊想法变成可以开发、可以验证、可以取舍的任务。
最少要回答 6 个问题：
- 用户是谁？
- 用户遇到什么问题？
- 核心流程是什么？
- 第一版必须做什么？
- 哪些先不做？
- 做完以后怎么验收？
只要这 6 个问题清楚，后面架构设计和代码开发都会稳很多。
第一步：先描述背景，不要直接列功能
不要一上来就说：
我要做一个记账 App，帮我列功能。
更好的方式是描述真实场景：
我想做一个个人记账 App。
目标用户是刚开始工作、想控制日常开销的年轻人。
他们的问题是：每月不知道钱花到哪里，也不想使用复杂的财务软件。
请先不要写代码，帮我做需求分析。
这段话比“做记账 App”强很多，因为它给了用户、问题和产品方向。
第二步：让 AI 输出 MVP 范围
MVP 的意思不是“功能越少越好”，而是第一版只做能验证核心价值的功能。
可以这样问：
请输出这个产品的 MVP 范围。
要求：
1. 分成必须做、可以后做、暂时不做
2. 每个功能说明为什么放在这个优先级
3. 避免一开始就做复杂功能
AI 通常会输出类似：
必须做：
- 记录收入和支出。
- 设置分类。
- 按月查看统计。
- 编辑和删除记录。
可以后做：
- 预算提醒。
- 多账户管理。
- 数据导出。
暂时不做：
- 多人共享账本。
- 股票基金资产管理。
- 自动识别账单。
这个结果的价值是帮你砍需求。
很多项目失败，不是因为做得太少，而是第一版做得太散。
第三步：让 AI 画出核心流程
功能列表还不够，你还要知道用户怎么走。
提示词：
请基于 MVP 范围，整理核心用户流程。
输出格式：
1. 用户进入应用后的第一步
2. 新增一笔支出的完整流程
3. 查看月度统计的流程
4. 编辑或删除记录的流程
5. 每个流程的异常情况
这一步会暴露很多细节。
比如新增支出时：
- 金额为空怎么办？
- 金额为负数怎么办？
- 分类未选择怎么办？
- 日期默认今天还是必须选择？
- 保存失败是否保留表单内容？
这些问题如果不提前想，最后都会变成开发中的返工。
第四步：让 AI 提取数据模型
需求分析阶段不需要设计完整数据库，但要知道核心数据有哪些。
可以这样问：
请根据上面的需求，提取核心数据模型。
要求：
1. 只输出业务字段，不写具体数据库代码
2. 标明必填字段和可选字段
3. 说明字段之间的关系
4. 指出还不确定的问题
可能得到：
- Transaction：金额、类型、分类、日期、备注、创建时间。
- Category：名称、类型、颜色、排序。
- MonthlySummary：月份、总收入、总支出、结余。
注意这里有一个关键要求：指出还不确定的问题。
好用的 AI 不是只给答案，也应该帮你发现问题。
第五步：让 AI 输出验收标准
很多需求最大的问题是“做完”没有定义。
你可以要求：
请把 MVP 功能整理成验收标准。
每条使用这种格式：
当……时，用户应该能够……
同时列出至少 5 个边界场景。
例如：
- 当用户输入金额、分类和日期时，应该能够成功保存一笔支出。
- 当金额为空时，应该提示用户填写金额，不能保存。
- 当用户删除一笔记录时，月度统计应该同步更新。
- 当没有任何记录时，统计页应该显示空状态。
这些验收标准后面可以直接变成测试用例。
第六步：让 AI 反问你
这是很多人忽略的一步。
不要只让 AI 回答，也要让它提问：
请站在产品经理和技术负责人角度，列出 10 个必须确认的问题。
这些问题如果不确认，可能影响后续设计或开发。
AI 可能会问：
- 是否需要登录？
- 数据只保存在本地，还是同步到云端？
- 是否需要多端同步？
- 分类是否允许删除？
- 删除分类后历史记录怎么办？
- 统计按自然月还是自定义周期？
这些问题就是需求风险。
你不一定要全部回答，但必须知道哪些暂时不做，哪些必须现在决定。
一个完整提示词模板
你可以直接复制下面这段：
我想做一个【产品/功能名称】。
背景是：【用户是谁，遇到什么问题】。
目标是：【希望解决什么问题】。
请先不要写代码，帮我做需求分析。
请输出：
1. 目标用户
2. 核心使用场景
3. MVP 功能范围
4. 暂时不做的功能
5. 核心用户流程
6. 关键数据模型
7. 验收标准
8. 边界情况
9. 还需要我确认的问题
要求：
- 不要过度设计
- 优先保证第一版可落地
- 每个结论都说明理由
最后
AI 编程不是从写代码开始，而是从定义问题开始。
需求越清楚，AI 越像工程助手；需求越模糊，AI 越像随机代码生成器。
如果你要做一个新功能，建议先让 AI 产出需求分析，再让它做架构设计，最后才进入代码开发。
下一篇我会继续写：如何让 AI 帮你做架构设计，以及如何避免一上来就把项目做复杂。
