和AI讨论需求，从0做一个项目

用 AI 写代码很快，但方向错了就全白写。真正花时间的不是敲代码，而是前期把需求想清楚、把文档写明白。这篇文章记录我用 AI 从 0 开始做一个项目时摸索出来的完整流程：立项 → 需求讨论 → 文档拆解 → demo 验证 → 开发计划 → 开发与验收循环。

立项阶段

让AI对产品有基本认知，了解项目类型，目标用户，核心问题和主要流程
让AI帮助完善想法，查漏补缺

如何讨论

理清产品需求：

我准备做一个什么类型的产品，大概功能是什么，你觉得这个产品的核心设计应该是什么。
让AI追问，拆分功能，判断第一版应该做什么
如果方向模糊，让AI帮助梳理项目应该怎么做，分析用户场景，核心功能，判断项目价值，拆分MVP，梳理数据流，推演用户使用流程
项目清楚后，让AI搜索和分析类似产品，找竞争品，开源方案，差异点和机会

长期规划：

核心MVP：第一版功能
迭代扩展：后续版本扩展内容
延后需求：哪些功能后面再做（非当前必要模块）
功能裁剪：哪些功能现在不做（明确舍弃的边界）
预留边界：哪些模块提前留好边界（模块化接口设计）

立项阶段不能写代码！！

告诉AI：当前阶段只做产品讨论和立项设计，不要写代码

明确产品定位，核心功能，首版范围，项目边界，技术路线，验收标准

立项文档（这个功能大概做什么）

生成一份产品文档，后面让AI写代码，拆任务，设计数据库，做前端页面，规划后端接口都可以根据这份文档找依据

立项文档应包含：

产品概述（解决什么问题/受众是谁）
目标用户，谁会使用这个产品
核心功能边界（第一版必须做vs暂时放弃）
产品交互路径（用户体验流程和数据流动）
页面结构（列出所有主要页面和功能）
验收规则标准（可检查的客观交付指标）
技术栈选型（产品形态，前端，后端，数据库用什么，主要框架和SDK，为什么这么选，哪些技术不用，什么情况下需要重新评估技术路线）

后续随着讨论，开发和验证，文档可以不断更新

功能清单（把立项文档拆细）

项目拆解三种维度：

按角色拆（普通用户，商家，管理员）
按流程拆（下单与支付，发货与物流，确认与评价）
按模块拆（账号安全模块，商品管理模块，订单处理模块）

每一个功能要包含：

交互要素（使用角色，输入参数）
逻辑层级（输出结果，流程链路，遇到异常和边界处理）
涉及权限
正常流程

复杂功能单独写成一份文档，在功能清单里留一个索引指过去

制作demo

先别急着搭架构，用最低成本把产品的样子做出来。找一些符合审美的设计风格，截图给AI。提示词：

结合这张风格参考图，参考其中的设计风格和配色，以及前面的产品文档，做一个产品的静态demo，展示主要页面和最核心的状态，能够呈现产品的设计配色和功能模块，不用做具体的逻辑

demo反馈模板：

我在哪个页面
我发现了什么问题
我希望应该怎么改

反复看demo，反复提反馈，直到产品的样子符合预期。这一步改的是静态页面，成本极低；等写完逻辑再改方向，代价就大了。

UI设计文档

demo 定稿后，让AI把样式沉淀成规范。提示词：

请根据我们刚才制作的demo整理一份UI设计规范文档，包括配色方案，字体规范，字体层级，卡片样式，组件样式，按钮样式等等，用来规范后续的开发，确保第一个版本和demo的样式一致

开发计划文档

demo 和文档都齐了，最后让AI把开发过程本身也规划好。提示词：

请根据 PRD 文档和静态 demo 帮我制定一份详细的开发计划，要求：

把整个开发任务拆分成独立步骤，每一步完成一个可验证的功能模块

每一步标注要实现的功能涉及的文件和完成标准，怎么判断这一步做完了

按依赖关系排列顺序，先基础功能再高级功能

每一步描述要足够完整，让新的AI会话能独立理解，因为每步会新开会话

最后附一个项目技术栈总览，用了什么框架库，部署方式

技术栈

技术栈在立项文档里已经定过一次，这一步是把它落实成具体的环境搭建清单：

运行环境（Node 版本、JDK 版本、包管理器等）
前后端框架及主要依赖库的版本号
数据库、缓存、消息队列等基础设施
部署方式（服务器、容器、静态托管等）

把这份清单交给AI生成初始化命令和配置文件。版本号要明确写死，避免AI使用最新版导致依赖冲突。

搭项目架构

有了开发计划和技术栈清单，让AI按计划的第一步搭建项目骨架：

目录结构（前后端分层、模块划分）
基础配置（路由、数据库连接、环境变量）
统一规范（接口返回格式、错误处理、命名约定）

骨架搭完先跑通一个最小闭环：比如一个接口从页面点击 → 后端处理 → 数据库读写 → 返回页面展示。闭环通了再往里填功能，出了问题也容易定位是哪一层。

开发与验收循环

后续开发就是不断重复这个循环：

开会话：每一步新开一个AI会话，把开发计划、当前步骤、相关文档发给它
实现：让AI按步骤描述写代码，涉及已有文件时让它先读再改
验收：对照该步骤的”完成标准”逐条检查，功能能跑、边界情况能处理才算过
记录：验收通过后，让AI更新开发计划文档（标记完成）和遇到的新问题，作为下一步会话的上下文

两个实用经验：

AI写错时，不要模糊地说”不对，重写”，用demo反馈模板的方式说清楚：哪里不对、期望是什么
每完成一步就提交一次代码（git），AI改崩了随时能回退

写在最后

这套流程的本质是：把人的思考成本花在文档上，把AI的执行力用在代码上。文档写得越清楚，AI越不容易跑偏；每一步验收越严格，返工越少。AI负责干活，你负责决定干什么活。