4. 文档头部信息
文档头部信息，说白了就是PRD的「身份证」。我见过太多团队，PRD写得天花乱坠，结果一翻到开头——版本号没有，修改记录空白，连谁写的都不知道。嗯，这种文档基本等于废纸。
我个人习惯，写PRD的第一件事不是写正文，而是先把头部信息填好。为什么？因为头部信息决定了这份文档的「可信度」和「可追溯性」。你想想看，一个连版本号都没有的文档，谁敢拿它去开发？
4.1 文档版本号：你的PRD「身份证」
版本号不是随便写的。我建议采用「主版本号.次版本号.修订号」的格式，比如v1.0.0。
- 主版本号：重大变更，比如产品方向调整、核心逻辑重写
- 次版本号：功能增减，比如新增一个模块、删除某个需求
- 修订号：小修小改，比如文案调整、字段名修改
重要原则：版本号一旦发布，禁止覆盖。每次修改都必须升版本，哪怕只是改了一个标点符号。
我在项目中遇到过一件事：有个产品经理改了一行文案，没升版本号，直接覆盖了原文档。结果开发拿着旧版本做了两周，最后发现需求对不上。嗯，从那以后，我们团队定了个死规矩——不改版本号就不准保存。
4.2 修改记录：谁在什么时候改了啥
修改记录是文档的「黑匣子」。它记录了每一次变更的痕迹。我个人习惯用表格来管理，清晰明了。
| 版本号 | 修改日期 | 修改人 | 修改内容 | 备注 |
|---|---|---|---|---|
| v1.0.0 | 2024-01-10 | 张三 | 初始版本 | 首次发布 |
| v1.1.0 | 2024-01-15 | 李四 | 新增用户登录模块 | 需求评审后补充 |
| v1.1.1 | 2024-01-16 | 张三 | 修改登录按钮文案 | UI反馈调整 |
| v2.0.0 | 2024-02-01 | 王五 | 重构支付流程 | 业务方向调整 |
小技巧：修改内容要写「做了什么」而不是「为什么做」。比如「修改登录按钮文案」就够了，不需要写「因为UI觉得颜色不好看所以改了文案」——原因可以写在备注里。
4.3 作者与评审人：责任到人
作者和评审人，这两个字段决定了「谁负责」和「谁把关」。
- 作者：PRD的撰写者，通常是产品经理。作者要对文档内容的准确性负责。
- 评审人：参与评审的相关方，包括开发、测试、设计、运营等。评审人要对文档的可行性负责。
我曾经见过一个项目，PRD的作者写了「产品部」，评审人写了「相关方」。结果出了问题，谁都不认账。说白了，这就是典型的「责任稀释」。我建议：作者写具体人名，评审人写具体人名+角色。
示例：
作者：张三（产品经理）
评审人：李四（后端开发）、王五（前端开发）、赵六（测试）、钱七（UI设计）
4.4 状态追踪：文档的「生命周期」
状态追踪，说白了就是告诉所有人「这份文档现在处于什么阶段」。我常用的状态有这几个：
- 草稿：还在写，别拿去做开发
- 待评审：写完了，请大家来挑刺
- 评审中：正在开会讨论，可能会有修改
- 已定稿：评审通过，可以开发了
- 已废弃：这个版本不用了，看新版本去
注意：状态为「草稿」或「待评审」的文档，开发人员可以直接无视。我曾经吃过这个亏——开发拿着草稿版就开始编码，结果需求全变了，白干两周。
我个人习惯，在文档头部加一个「状态标签」，用颜色区分：
- 草稿：灰色
- 待评审：黄色
- 评审中：橙色
- 已定稿：绿色
- 已废弃：红色
这样一眼就能看出来文档的「成熟度」。你想想看，如果一份PRD头部写着「已定稿」，那开发就可以放心地开始编码了。
4.5 一个完整的头部信息示例
说了这么多，不如直接看一个完整的例子。这是我个人比较喜欢的格式：
# PRD文档头部信息
## 文档信息
- 文档名称：用户中心PRD
- 文档编号：PRD-2024-001
- 当前版本：v1.2.0
- 文档状态：已定稿
- 创建日期：2024-01-10
- 最后更新：2024-02-15
## 作者与评审
- 作者：张三（产品经理）
- 评审人：李四（后端）、王五（前端）、赵六（测试）
## 修改记录
| 版本号 | 日期 | 修改人 | 修改内容 | 备注 |
|--------|------|--------|----------|------|
| v1.0.0 | 01-10 | 张三 | 初始版本 | - |
| v1.1.0 | 01-20 | 张三 | 新增注册流程 | 评审后补充 |
| v1.2.0 | 02-15 | 李四 | 修复登录逻辑 | 开发反馈调整 |
避坑指南：我曾经见过有人把修改记录写在文档末尾，结果每次都要翻到最后才能看到变更历史。我建议：修改记录一定要放在文档头部，紧跟在版本号后面。这样任何人打开文档，第一眼就能看到「这个文档经历了什么」。
嗯，文档头部信息看起来简单，但做好了能省很多事。说白了，它就是PRD的「门面」——门面干净了，里面的人才愿意认真看。