项目版本管理（Project Version Management）
Overview
为产品/研发类项目建立统一的文档版本管理体系，使 PRD、功能大纲、用户流程、UI/UX 设计、工业设计、硬件需求、软件需求、测试文档、会议决策等具备可追溯、可比较、可回滚、可协作、可审计五大属性。
核心铁律：已发布版本不可修改，只能创建新版本。 任何修改都必须回答 WHAT / WHY / WHEN / WHO / IMPACT / VERSION 六个问题。
详细可复制模板见 references/templates.md。
When to Use
在以下场景主动加载本技能：
- 新建任何项目文档，需要定版本号与文档头。
- 修改已有文档，需要决定 bump 哪一级版本号并补 Change Log。
- 到达里程碑（MVP 冻结、设计冻结、硬件冻结），需要执行 Freeze 规则。
- 冻结后又要改，需要走 Change Request 流程。
- 审计一个项目的版本纪律（文档头、变更日志、命名、状态是否齐全）。
- 新人接手项目，需要快速理解"项目为什么变成现在这样"。
Core Principles
- 禁止覆盖历史版本。 错误做法：
PRD最终版.docx、PRD最终版2.docx。正确做法：PRD_v0.3.md、PRD_v0.4.md、PRD_v1.0.md。已发布版本只读，变更一律生成新文件/新版本。 - 五属性目标。 每个版本都要能回答：可追溯（谁、何时、为何）、可比较（版本间 diff）、可回滚（旧版本可恢复）、可协作（多人不冲突）、可审计（决策有记录）。
- 修改必归类。 每次变化归入 Added / Changed / Removed / Deprecated / Fixed 之一，并写 Reason。
- 需求必溯源。 每条需求关联来源（用户调研 / 硬件限制 / 成本控制等），可双向追溯。
- 冻结后必走 CR。 冻结节点之后的任何改动，必须提交 Change Request、说明原因、评估影响、更新版本。
Version Numbering（Major.Minor.Patch）
格式：vX.Y.Z（例如 v1.2.3）。
- Major（主版本）
v1.0.0 → v2.0.0：重大方向变化。触发：产品定位变化、用户群变化、核心架构变化、MVP 重新定义、硬件平台变化。 - Minor（次版本）
v1.1.0 → v1.2.0：新增功能或较大调整。触发：新增一级功能、新增业务流程、新增模块、新增硬件能力。 - Patch（修订版本）
v1.2.1：小范围优化。触发：文档修正、UI 细节调整、参数修改、Bug 修复、描述优化。
项目阶段版本
产品项目按阶段推进，阶段对应版本前缀：
Concept → Research → PRD → Design → Prototype → Development → Testing → Release
- 0.x 阶段（探索）：需求未冻结，大量变化。例：
PRD_v0.3、Feature_Map_v0.5。 - 1.0 阶段（MVP 冻结）：第一次完整可交付版本。例：
Robot_MVP_v1.0。 - 2.0 阶段（正式升级）：增加 AI 动作纠正、社交功能、云端分析等。
示例（儿童运动机器人）： v0.x 儿童运动陪伴设备 → v1.0 家庭 AI 运动机器人。
File Naming Convention
统一格式：项目名_文档类型_版本号_状态
| 示例 | 说明 |
|---|---|
Robot_Feature_List_v0.3_Draft.md |
草稿 |
Robot_PRD_v1.0_Approved.md |
已批准 |
Robot_Hardware_REQ_v0.5_Review.md |
评审中 |
状态后缀取值：Draft / Review / Approved / Released。
Document Header Standard
所有项目文档头部必须包含以下字段（模板见 references/templates.md）：
Version: v0.3
Status: Draft / Review / Approved / Released
Owner: 负责人
Created: 2026-10-12
Updated: 2026-10-12
Previous Version: v0.2
Change Log Requirement
每个版本必须包含 Change Log，至少含 Added / Changed / Removed / Fixed / Reason 五段（Deprecated 可选）。格式与字段见 references/templates.md。
AI 辅助规则（修改文档时必输出）： 当前版本、修改内容、修改原因、影响范围、下一步建议。禁止直接覆盖旧版本。
Change Types
| 类型 | 含义 | 示例 |
|---|---|---|
| Added | 新增能力 | 新增运动排行榜 |
| Changed | 已有功能调整 | 运动结束页由弹窗改为独立页 |
| Removed | 删除功能 | 删除视频通话功能 |
| Deprecated | 准备废弃 | 旧任务系统将在下版移除 |
| Fixed | 问题修复 | 修复动作识别失败流程 |
Feature & Requirement Status
功能状态机
Idea → Research → Draft → Review → Approved → Development → Released → Deprecated
每个功能必须有状态，用功能表维护（见 references/templates.md）。
需求追踪
所有需求关联来源，用追踪表维护：
| 需求ID | 来源 | 功能 | 版本 |
|---|---|---|---|
| REQ001 | 用户调研 | 运动任务 | v0.3 |
| REQ002 | 硬件限制 | 取消 4G | v0.4 |
Freeze & Change Request
关键节点必须冻结，冻结后改动走 CR：
- Feature Freeze：
MVP Feature Freeze v1.0 - Design Freeze：
Industrial Design Freeze v1.0 - Hardware Freeze：
Hardware Freeze v1.0
Change Request 格式（编号 CR-001 起）：修改内容、原因、影响（硬件/软件/时间）、审批（PM / 硬件负责人 / 研发负责人）。完整模板见 references/templates.md。
Release Checklist
Release 前确认：
- 文档：PRD 更新、Feature List 更新、Change Log 填写。
- 设计：UI 版本同步、工业设计版本同步。
- 技术：API 同步、Hardware Spec 同步。
- 项目：已知问题记录、下一版本规划。
Recommended Directory Layout
Project/
├── Docs
├── Version_Control/
│ ├── CHANGELOG.md # 项目级总变更日志
│ ├── Version_History.md # 版本时间线
│ └── Change_Request/ # CR-001.md ...
├── PRD/
├── Feature/
├── Design/
├── Hardware/
├── Testing/
└── Archive/
├── v0.1/
├── v0.2/
└── v1.0/
Workflow（决策流）
- 新建文档 → 定
项目名_文档类型_v0.1_Draft.md，写文档头，状态Draft。 - 小修/ typo → bump
Patch（v0.1 → v0.1.1），补 Change Log 的 Fixed。 - 加功能/大改 → bump
Minor（v0.1 → v0.2），补 Added/Changed/Removed + Reason。 - 方向变化 → bump
Major（v0.x → v1.0），在 Version_History 记里程碑。 - 到冻结点 → 打 Freeze 标签，后续改动强制走 CR。
- 发版 → 跑 Release Checklist，状态置
Released，旧版本移Archive/<ver>/。 - 审计 → 抽查文档头、Change Log、命名、功能/需求状态是否齐全。
Resources
references/templates.md— 文档头、Change Log、CR、版本历史、功能状态表、需求追踪表、Release Checklist 的可复制模板。
