第2章：状态命名规范 – 命名规则、缩写标准、版本后缀
1. 适用场景
本章规范适用于以下三类场景：
- 原型状态定义：当产品经理首次为 IoT 硬件原型创建状态标识时，需要按照统一规则命名，确保跨团队（硬件、固件、测试、产品）无歧义。
- 状态变更通知：原型从“设计验证”进入“工程验证”或“小批量试产”时，命名中的版本后缀必须同步更新，以便追溯。
- 多源协同开发：当多个供应商或内部团队并行开发同一原型的不同模块时，缩写标准可防止状态字段混乱。
2. 前置条件
- 已确定原型的产品代号（如
SMART-SENSOR-V2）。 - 已明确当前所处的研发阶段（EVT/DVT/PVT/MP）。
- 团队已约定缩写词典，确保每个缩写有唯一释义。
- 版本管理工具（如 Git、SVN 或 PLM 系统）已就绪，可记录命名历史。
3. 操作步骤
- 确定产品代号：从产品路线图中提取唯一代号，例如
SMART-LOCK-G3。 - 选择状态前缀：根据原型当前所处的里程碑，从缩写标准表中选取对应的英文缩写（见表1）。
- 附加版本号：采用主版本.次版本.修订号格式，其中主版本对应重大重构，次版本对应功能增减，修订号对应缺陷修复。
- 拼接完整状态名：按顺序组合为
产品代号_状态前缀_版本号，例如SMART-LOCK-G3_EVT_1.2.0。 - 登记与公示：将最终状态名写入《原型状态登记表》，并通过项目协同工具周知所有干系人。
关键检查点：每次状态变更必须同时更新登记表和版本后缀，禁止仅口头通知。
4. 输入输出物
| 类型 | 名称 | 描述 | 模板/示例 |
|---|---|---|---|
| 输入 | 产品代号表 | 由产品线维护的代号清单，包含产品全称、代号、代际 | SMART-SENSOR-V2 |
| 输入 | 缩写词典 | 团队约定的状态缩写与中文释义对照表 | EVT → 工程验证测试 |
| 输出 | 原型状态命名登记表 | 记录每个原型的历史状态名、变更人、时间戳 | SMART-LOCK-G3_EVT_1.2.0 |
| 输出 | 状态命名公告 | 通过项目管理工具发送的通知，含新旧状态名对比 | 邮件/飞书/钉钉消息 |
5. 责任边界
- 产品经理：负责维护产品代号表，批准缩写词典的增删改。
- 项目经理：监督状态命名流程的执行，确保每个节点都有记录。
- 开发/测试负责人：根据实际进展提议状态变更，并验证命名与实物状态一致。
- 配置管理员：在版本管理系统中创建标签时，必须使用经过审批的完整状态名。
6. 记录材料
- 《原型状态登记表》（Excel 或在线表格）：包含字段：产品代号、状态前缀、版本号、变更人、变更日期、审批人。
- 《缩写词典》（共享文档）：列出所有允许使用的缩写及其全称、适用范围、启用日期。
- 状态命名公告记录：消息截图或系统日志，留存至少一个项目迭代周期。
7. 异常处理
| 异常场景 | 处理措施 | 输出物 |
|---|---|---|
| 缩写冲突（同一缩写被不同团队定义为不同含义） | 由产品经理召集仲裁会议，重新定义唯一缩写，并更新缩写词典 | 缩写词典更新记录 |
| 版本后缀遗漏或格式错误 | 退回命名申请，要求提交人补充正确的版本号后再走审批 | 状态修正通知 |
| 产品代号已废弃但仍被使用 | 立即停止该命名，改用最新产品代号，并在登记表中标注废弃代号的有效期 | 代号废弃公告 |
| 同一原型出现多个不同状态名 | 以版本管理系统中打 tag 的状态名为准，其他状态名一律作废并归档 | 状态名统一确认单 |
8. 验收标准
- 命名完整性：所有 IoT 原型的状态名必须同时包含产品代号、状态前缀、版本号，缺一不可。
- 缩写合规性：状态前缀必须来自当前有效版本的《缩写词典》，禁止使用自造缩写。
- 版本可追溯：每个状态名对应的版本号能在版本管理系统中找到匹配的 tag 或 commit。
- 登记及时性：状态变更发生后 2 个工作日内，登记表必须完成更新，且公告已发出。
- 一致性校验：随机抽查 5 个原型，其状态名与实物状态、登记表、版本 tag 三者完全一致。
常见返工原因：缩写风格不统一（大小写混用）、版本号缺少修订位、产品代号中带空格或特殊字符。验收时会对这三项做硬性检查。