PRD 与文档驱动开发
3.6 PRD编写规范
Tip
学会用Markdown写AI友好的PRD,用结构化的列表和代码块代替散文式描述。
1. 为什么要学这个?
你写了洋洋洒洒两千字的Word文档,AI读完后还是写出一堆垃圾代码。你很生气:"我写得这么细!"
原因:你的文档是给人看的,不是给AI看的。
人喜欢看起承转合、背景故事。AI喜欢看结构、列表、代码块。
关键问题:
- 怎么写AI能理解的文档?
- 为什么要用Markdown?
- PRD应该包含哪些内容?
Markdown是AI的母语,结构化比内容更重要。
2. 核心概念
2.1 散文 vs 表格
❌ 散文式(Bad):
"我们要个登录功能,最好酷一点,用户体验要好,颜色最好是那种五彩斑斓的黑..."
**AI反应:**提取不出结构化数据,开始瞎猜。
✅ 表格式(Good):
- Function: Login
- Input: Email, Password
- Validation: Password > 8 chars
- Color: #000000
- Animation: Fade-In (0.5s)
**AI反应:**精准提取Key-Value,生成代码。
2.2 为什么用Markdown?
- 结构清晰:
#表示层级,-表示列表,AI解析Token消耗最少 - 代码友好:天然支持```代码块
- 纯文本:没有Word那种乱七八糟的隐藏格式字符
3. PRD黄金模板
# Project Name: [项目名称]
## 1. Goals (目标)
- [核心目标1]
- [核心目标2]
## 2. User Stories (用户故事)
- As a [用户], I want to [做某事], so that [得到好处]
## 3. Tech Stack (技术栈)
- Frontend: Next.js + Tailwind
- Backend: Supabase
- DB: Postgres
## 4. Pages & Features (页面与功能)
### 4.1 Login Page
- **Path**: `/login`
- **Elements**:
- Input: Email
- Input: Password
- Button: "Login"
### 4.2 Dashboard
- **Path**: `/dashboard`
- **Data**: Fetch from user's table
4. 什么时候需要写文档?
| 🎯 场景 | 是否写文档 | 理由 |
|---|---|---|
| 临时脚本 | ❌ 不必 | "写个正则匹配邮箱",直接说就行 |
| 核心功能 | ✅ 必须 | "实现购物车逻辑",必须定义数据结构和交互步骤 |
| Bug修复 | ⚠️ 看情况 | 如果逻辑复杂,建议写个简单的Bug Report |
5. 避坑指南
| ❌ 不要这样做 | ✅ 应该这样做 | 为什么 |
|---|---|---|
| 用Word/PDF | 用Markdown(.md文件) | AI解析Markdown最快,Word容易丢失格式 |
| 大段文字描述 | 用列表(Bullet Points) | AI注意力分散,列表更清晰 |
| 中英文混杂 | 专业术语用英文,描述用中文 | Key-Value格式AI理解最快 |
6. 真实案例
Story
1977年,旅行者金唱片的通用语言
1977年,NASA发射旅行者号探测器,它将飞出太阳系。科学家们想带一封信给外星人,但外星人不懂英语、中文,甚至可能没有眼睛。怎么写这份"PRD"?卡尔·萨根团队没有写"你好",也没有画这画那,而是设计了一种基于氢原子跃迁周期(物理通用常数)的编码格式。唱片封面上刻画了如何解码音频、如何定位地球(利用脉冲星频率)。他们把信息转化成了全宇宙通用的结构化数据,只要外星人有基本的物理学知识,就能读懂。
Vibe心法:用结构化的列表和代码块定义需求——Markdown是AI的通用语言,列表优于段落。
7. 本章小结
- 📝 Markdown是AI母语:结构清晰、代码友好、纯文本
- 📋 结构>内容:用列表和表格,不要写散文
- ✅ 黄金模板:目标、用户故事、技术栈、页面功能
- 🎯 Key-Value格式:AI理解最快
- ⚠️ 避免Word/PDF:Markdown解析最高效