深色模式
1.4 唯一的必修课，用 Markdown 写清需求
环境终于通了。Python 能叫出来，Node.js 能叫出来，npm install 也不再卡死。很多老师这时候会很自然地想：那我是不是可以直接让 AI 开始写系统了？
先别急。如果你只对 AI 说一句：
帮我做一个机房排座系统。
它当然会写。但它写出来的东西，八成不是你真正想要的。因为“排座系统”这四个字，对你来说有真实场景，对 AI 来说只是一个模糊词。
随口许愿，通常会返工
你脑子里想的是学校机房：有固定电脑编号，有不同年级、不同班级，有的学生需要固定座位，有的班级要轮换。你还希望老师能保存、查看、调整，最好能导出打印。
但你没有说出来，AI 就只能猜。它可能做成一个简单拖拽页面，也可能做成一个静态座位表，还可能把所有班级混在一起，完全没有数据保存。
不是 AI 故意偷懒，是你给它的输入太像一句愿望，而不像一份需求。Vibe Coding 最重要的基本功，不是背语法，而是把真实需求写成 AI 能理解、能执行、能持续迭代的结构化文本。
这就是 Markdown 的价值。
Markdown 不是排版工具，是需求骨架
Markdown 看起来很朴素：标题、列表、表格、任务清单，没什么花哨东西。但正因为它朴素，AI 很容易读懂。
它不像 Word 文档那样混着复杂格式，也不像聊天记录那样散。它更像一块干净的黑板：你用标题分层，用列表拆需求，用表格说明字段，用任务清单记录进度。
AI 看起来清楚，后续修改也方便。老师自己回头看，也不会在一堆聊天记录里翻半天。
一份最小 PRD 可以这样写
PRD 这个词听起来有点产品经理味。放到我们这里，它不用写得很重，你可以先把它理解成：给 AI 看的项目说明书。
一份最小可用的需求文档，可以从这几块开始：
markdown
# 机房排座系统 PRD
## 1. 使用场景
本系统用于信息科技老师管理机房座位。
机房电脑位置固定，但不同班级上课时需要使用不同座位表。
## 2. 使用对象
- 信息科技老师
- 需要查看座位安排的任课教师
## 3. 核心功能
- 创建班级
- 导入或录入学生名单
- 按机房布局显示座位
- 给学生分配座位
- 保存每个班级的座位表
- 查看和调整已有座位表
## 4. 暂不实现
- 学生登录
- 复杂权限管理
- 自动排课
- 手机端专门适配
## 5. 验收标准
- 老师能选择班级并看到该班座位表
- 每个学生只能占一个座位
- 每台电脑同一时间只能绑定一个学生
- 刷新页面后，已保存座位不丢失这份文档不长，但已经比一句“帮我做个系统”稳太多。因为 AI 至少知道：谁用、干什么、先做什么、暂时不做什么、做到什么才算完成。
标题负责分层
Markdown 里的 #、##、###，不是为了好看。它们是在告诉 AI：这份文档的结构是什么。
比如：
markdown
# 项目名称
## 使用场景
## 用户角色
## 核心功能
### 班级管理
### 学生管理
### 座位管理
## 验收标准结构清楚以后，AI 就不容易把“学生管理”和“座位管理”混在一起。这和老师写教案一样，教学目标、教学重点、活动设计、评价方式，如果全挤在一段话里，自己回头看都会累。
列表负责拆需求
列表适合把一件大事拆成几件小事。比如“座位管理”可以这样写：
markdown
## 座位管理
- 系统按机房真实布局显示座位。
- 每个座位显示电脑编号。
- 老师可以把学生分配到指定座位。
- 已分配学生的座位要高亮。
- 老师可以清空某个座位。
- 老师可以保存当前班级座位表。这段内容对 AI 很友好。每一条都可以变成一个功能点，也方便后面逐条验收。
不要小看这种拆分。很多返工，就是因为一开始没有把“到底要做哪些动作”拆清楚。
表格适合写规则和字段
如果你要说明数据字段，表格会比长段落清楚。比如学生信息：
| 字段 | 含义 | 示例 |
|---|---|---|
| 姓名 | 学生姓名 | 张三 |
| 班级 | 所属班级 | 七年级 1 班 |
| 学号 | 校内编号或座号 | 12 |
| 座位号 | 绑定的机房座位 | A03 |
表格不需要很复杂，只要能让 AI 明白数据大概长什么样，就已经很有用。如果后面要让 AI 设计数据库，这些字段会直接变成它理解数据结构的依据。
任务清单负责控制进度
AI 开发最怕一口吃太多。你可以用任务清单控制节奏：
markdown
## 开发任务
- [ ] 创建项目基础结构
- [ ] 完成机房座位布局页面
- [ ] 完成班级列表
- [ ] 完成学生录入
- [ ] 完成座位分配
- [ ] 完成数据保存
- [ ] 完成功能测试每完成一项，就打一个勾。这对老师也有好处：你不用一直问“项目做到哪了”，打开文档就能看到当前进度。
需求文档到开发，可以形成闭环
Markdown 不是写完就放着。它应该贯穿整个开发过程。
flowchart TD
A[真实校园需求] --> B[Markdown PRD]
B --> C[AI 审阅需求<br/>发现遗漏和歧义]
C --> D[补充边界与验收标准]
D --> E[生成技术方案]
E --> F[拆成开发任务]
F --> G[AI 编写或修改代码]
G --> H[人工测试与确认]
H --> I{是否符合 PRD}
I -->|不符合| D
I -->|符合| J[更新文档与进度]
这就是为什么我说 Markdown 是必修课。它不是为了写得漂亮，而是让 AI、项目和老师自己，都围绕同一份清楚的文字工作。
别写成语法大全
学 Markdown，不需要把所有语法都背下来。对 Vibe Coding 来说，先掌握四样就够了：
- 标题：负责分层。
- 列表：负责拆功能。
- 表格：负责说明字段和规则。
- 任务清单：负责记录进度。
会这四样，你就能写出一份足够 AI 使用的需求文档。剩下的语法，用到再查。
今天就能做的一件事
现在就打开一个 Markdown 文件，写下你最想做的校园小工具。不要写大作文，就写这五块：
markdown
# 项目名称
## 使用场景
## 使用对象
## 核心功能
## 暂不实现
## 验收标准尤其要写“暂不实现”。这四个字很重要，它能防止 AI 一上来把项目做得又大又散，也能提醒你先做最小可用版本。
环境打通以后，Markdown 就是你和 AI 之间最稳定的沟通纸面。需求写清楚，还不等于 AI 一定能做对。下一篇，我们继续把校园里的业务流程，翻译成 AI 能听懂的人话、流程和伪代码。
封面