5.2.2 到底改了啥——更新记录格式
一句话破题
更新记录让你知道：这份文档和上次相比改了什么。
为什么需要更新记录
- 回溯变更：出问题时能追溯是哪次修改导致的
- 理解演进：新成员能快速了解需求的演变过程
- 对比版本：知道从哪个版本开始有了某个功能
更新记录的标准格式
markdown
## 更新记录
| 版本 | 日期 | 变更内容 | 作者 |
|------|------|----------|------|
| v1.2 | 2024-01-20 | 新增评论功能 | 李四 |
| v1.1 | 2024-01-15 | 优化搜索逻辑，支持模糊匹配 | 张三 |
| v1.0 | 2024-01-10 | 初版发布 | 张三 |版本号规范
采用语义化版本（Semantic Versioning）的简化版：
v主版本.次版本
主版本：重大改动、不兼容的变更
次版本：新增功能、向后兼容的变更示例：
v1.0→v1.1：新增了一个字段v1.1→v2.0：整个数据结构重构
变更内容的写法
好的写法：清晰、具体、可追溯
✅ 新增用户头像上传功能，支持 jpg/png 格式
✅ 修改登录接口，增加验证码验证
✅ 删除废弃的 getOldUser API差的写法：模糊、笼统
❌ 修改了一些问题
❌ 优化
❌ 更新与 Git 的关系
文档的更新记录和 Git 提交记录可以配合使用：
markdown
## 更新记录
| 版本 | 日期 | 变更内容 | Commit |
|------|------|----------|--------|
| v1.2 | 2024-01-20 | 新增评论功能 | [abc123](./commit-link) |但文档更新记录应该是业务视角的总结，而不是每个 Git commit 的复制。
简化方案
对于个人项目，可以简化为：
markdown
## 变更历史
- 2024-01-20: 增加评论功能
- 2024-01-15: 优化搜索
- 2024-01-10: 初版关键是有记录，格式可以根据项目规模调整。
对 AI 协作的影响
当文档有多个版本时，向 AI 说明版本信息：
请基于 v1.2 版本的 PRD 生成代码。
注意：v1.2 相比 v1.1 新增了评论功能。
[文档内容]