Vibecoding 开发前，要怎么去写一份面向Ai的需求文档

做 Vibecoding 相册清理工具之前，我也做了四五款产品，其中大部分都是：

想到哪做到哪
一路加需求
工期越拖越长

这次我刻意换了一种方式：先把产品文档写清楚，再写一行代码。

回头看，这对项目节奏有个很大的改善，但还是有不少问题（问题主要原因是执行出了点问题），这算是一个经验分享贴和我的复盘贴。

**这篇主要想聊Vibecoding，在正式开干之前，怎么写产品文档。主要就是六个部分，对应下面六个小节。每一个部分你都可以跟ChatGPT仔细讨论，我直接把一个对话聊上限了。

说明一下产品的定位；
产品框架；主要菜单，菜单下有什么功能页面建议是代码格式的树状图，md格式不太好识别表格，然后标注一下什么是一期要做的，什么是二期做的
梳理系统操作流程；针对一期要做的核心功能，梳理操作流程。
梳理功能详细需求说明；说明一下这些核心功能的页面结构，功能逻辑，效果。如果可以的话，可以都加上这些功能的核心业务场景。
跟AI讨论你的UI风格；可以找参考图、或者让ai帮你输出。文字版的即可。主要是定义主题色、页面框架
讨论技术实现方案；上面的核心功能，挨个问一下ai，讨论出一个大概的技术实现方案

01. 为什么要在开发前写文档？

不讲大道理，只讲我自己踩过的坑和好处。

1）防止"想到哪做到哪"

以前我开发过程是这样的：

今天觉得加个功能很帅 → 明天又想加个入口 → 过几天发现结构乱了 → 一期上线时间一拖再拖。

但当我把文档写出来之后，项目变成这样：

先确定一期要解决的"最小闭环"
把所有可能的功能先挂在"整体框架"里
一期、二期、三期分层标出来

后续所有的"灵感功能"，我只问一个问题：
"这个是一期刚需吗？不是就扔到后面。"

2）大项目拆成可以按期上线的小版本

Vibecoding 是一个相册清理工具，如果一上来就想把"清理 + 整理 + 回忆 + 作品 + 会员"全做完，再发布，那我大概率又会烂尾。

文档写好之后，我发现可以这么拆：

一期：只做"核心清理能力 + 基础查看能力"，能真实帮用户清掉一批照片以及核心的差异点：相册整理、分组管理、简单回顾
后面：再加更"花"的功能，比如故事作品、拼图、回忆氛围等等

项目从"一个巨石"变成了"几块可以搬动的小石头"。

现在看来其实还是可以拆的再细一点。

02. 先讲清楚产品定位：给谁、在什么场景下解决什么问题？

文档里第一块，我会写得非常朴素，但一定要具体。

🎯 给谁用？

我给 Vibecoding 的用户画像是：

手机里有大量照片，但不太会整理的人
清理相册经常纠结，不知道该删哪张的人
对"批量一键清理"不放心，想自己"看清楚再决定"的人

不需要很花哨的标签，只要你一想到这些人，就能立刻脑补出他们的相册长什么样就够了。

🎯 在什么场景下解决什么问题？

我会列极少数几个非常具体的场景，比如：

相似照片很多，纠结删谁
- 拍同一个景色好几张，每一张都差一点点
- 现在的相册清理工具只给一个"建议保留"，但我总觉得哪张更好看
截图堆积如山，但只能一张张删
- 截商品、聊天记录、验证码......堆到看不到照片
只想保留"关键瞬间"，但没有好用的对比工具
- 想精简相册，留下"简历用照片、朋友圈封面、值得回顾的照片"，其它删掉

最后我会写一句"自用型"的定位总结：

Vibecoding 是一款"更适合纠结症用户"的相册清理工具，让你可以多选、放大、对比之后，再安心决定删谁留谁。

这句话后面会被我用在：公众号介绍、产品页、自我复盘里。

03. 用"代码树状图"把产品框架画出来

这一步特别关键，也最接近我们之前 PRD 的结构，但这里我会刻意模糊一些内部命名和实现细节，只保留对外可以公开的那一层。

我在文档里是这么画 Vibecoding 的整体结构的：

text 复制代码

Vibecoding
├── 清理区（一期）
│   ├── 相似照片清理
│   ├── 截图清理
│   ├── 连拍照片清理
│   └── 其他可选清理入口
│
├── 整理区（一期核心 + 后续扩展）
│   ├── 按时间线查看与管理
│   ├── 简单标签 / 备注整理（后续）
│   └── 批量调整、批量操作（后续）
│
├── 回顾区（后续）
│   ├── 日常回顾（例如某天的历史照片）
│   ├── 旅行 / 活动回顾
│   └── 故事合集（给加过备注的照片做一个入口）
│
├── 查看器（一期）
│   ├── 单张查看
│   ├── 多选 + 放大对比
│   └── 删除 / 保留 / 移动等操作
│
└── 个人中心（一期基础形态）
    ├── 订阅与配额
    ├── 隐私与基础设置
    └── 后续的会员权益

这里可以看出几个"脱敏处理"：

不写内部模块代号、不贴数据库结构
不展开每个小功能下的所有细节，只写到"普通用户读了能理解"的层级
重点是告诉读者：如何通过一张树状图，把一个复杂 App 拆成可控的模块

在文档里，我会用简单标记：

[一期必做]
[一期候选]
[二期及以后]

这样后面规划 roadmap 的时候，所有人一眼就知道哪些是"上线必须有"，哪些是"可以先别碰"。

04. 针对"一期核心功能"梳理用户操作流程

这一步，我只会选 一期里最关键的 1--2 条流程 ，写得足够清楚。

比如 Vibecoding 里，我会重点写：

从打开 App 到完成一组相似照片清理的完整链路。

在文档里，我会写成这样：

text 复制代码

启动 App
→ 等待首次扫描（后台进行，可边用边扫）
→ 进入【清理区】
→ 选择「相似照片」分组
→ 查看相似照片小卡片（看到数量、预览）
→ 点进某一组，进入多选 + 放大对比界面
→ 用户在对比中做出保留/删除的选择
→ 操作完成后，界面给出简单反馈（释放了多少空间之类）
→ 自动回到分组列表，方便继续下一组

这里我刻意不写任何"内部实现方式""用的是什么框架""如何做聚类"等细节，

只聚焦在一个问题上：用户的手，是怎么在这个产品上"走完一圈"的。

05. 给核心功能写"简版需求说明"：结构 + 逻辑 + 场景

在 PRD 里我会写得很细，但对外分享时，我就只保留三件事：

页面大致长什么样（结构）
用户大概怎么操作（逻辑）
对应解决的是哪类真实场景（场景）

以"相似照片清理"为例，我在分享时会写成这种级别：

5.1 页面结构（简版）

text 复制代码

相似照片清理页
├── 顶部：分组的筛选条件（按时间、相似程度等）
├── 中部：相似照片分组列表（每组显示一张代表图 + 数量）
└── 底部：必要的操作入口（进入多选对比 / 返回等）

5.2 功能逻辑（不涉及内部细节的那种）

系统会自动扫描并归类相似照片
用户看到的是一组一组的"待处理任务"
点进某一组，就进入"挑选和决策"的界面
最终结果是：留下几张最喜欢的，其余删掉或做压缩处理

5.3 典型业务场景（对外可以讲的那一层）

例如：

场景 S1：纠结症用户想"看清楚再决定"

→ 所以需要多选 + 放大对比，而不是只给一个"系统建议"。
场景 S2：想高效一点，不想来回切换

→ 所以清理完成后要自动回到"下一组"，形成清理节奏。

在分享中，我只讲"为什么要这么设计""解决谁的痛点"，

而不把内部更细的约束和策略全摊出来。

06. UI 风格：用文字把"感觉"说清楚就够了

这一块，内部文档会更细（包括色号、间距、各种状态），

但对外我只保留三件事：整体氛围、核心颜色方向、布局倾向。

例如：

整体氛围：干净、安静、不打扰用户决策
颜色方向：偏冷的低饱和色系 + 少量点亮色
布局倾向：信息层级清晰、留白足够、重要操作按钮显而易见

我会在文档里写类似这样的话：

我希望用户在清理相册时，不会被五颜六色的视觉抢走注意力，而是能把焦点放在照片本身上。

然后我会把这些文字喂给 AI，让它帮我扩展一些 UI 参考描述、甚至生成简单的线框思路。

整个过程只讨论"风格"，不暴露具体设计稿或内部 UI 规范。

07. 技术实现：用"问问题"的方式挨个过一遍

技术实现这块，我在实际 PRD 里会写得更具体，

但在对外分享时，我只讲一个方法论：

把每一个一期核心功能，拆成一个一个可以问 AI 的技术问题。

比如：

"如何在相册工具里高效扫描本地照片？"
"如何实现多选 + 放大对比的交互，而不会卡顿或界面跳动？"
"如何做基础的空间统计和清理反馈？"

AI 给的答案里，真正用到的只是其中一部分思路。

在文章里，我也不会贴代码，只会讲到这个层级：

先用小图占位，保证界面先出来
大图加载后只替换内容，不改变布局
清理过程可以异步，但用户的操作反馈要及时

这样既能 分享"如何借助 AI 快速搭建技术方案"的经验 ，

又不会把内部实现细节原样暴露出去。

08. 小结：写文档是独立开发者性价比最高的一件事

这次做 Vibecoding，我最大的感受是：

当你把产品文档写清楚，

其实你已经做完了这个项目的 50%。

写文档帮我做了这几件事：

把一个大项目拆成了可以按期上线的小版本
让"一期要做什么、二期再做什么"变得非常清楚
避免了很多"边做边改架构"的返工
也让我在和 AI 讨论时，有了清晰的问题和上下文

如果你现在也在做一个自己的产品，

我非常建议你试试这一套方式：

先写定位：给谁用，在什么场景下解决什么问题
用树状图把整个产品框架画出来，并标注版本优先级
针对一期核心功能，写清楚用户操作流程
给核心功能做简版需求说明：结构 + 逻辑 + 场景
用文字定义 UI 风格和氛围
最后再用这些文档，去跟 AI 一起推演技术方案

当你愿意花 1～2 天把这些写完，后面节省的时间，远远不止这两天。

现在再说一下，文档写了就要去执行，我这次其实还是踩了一个坑，我同时开了Cursor、Antigravity、Vscode（claude code+codex），同时有这么多Ai，我就不想让每一个都闲着，所以就没有严格按照我自己的规划去做。所以有个bug卡了差不多一个礼拜。还是吃了不懂代码的亏。。。。

这个具体的卡点下次再分享，下一章先分享怎么去做一个美观的设计稿或者初版前端页面！