研发编号规则约束

问题从哪来

多人协作里，需求、任务、缺陷和文档如果各用一套简称或临时编号，沟通里会出现「那个 001」「上次改过的 PRD」这类歧义；追踪、归档和 Git 分支/提交也很难和工单一一对应。编号本质是团队的通用语言，需要分段、可解析、全项目一致的规则，而不是事后补文档。

技能如何约束编号

本规则定义统一骨架：项目标识（2～4 位大写字母）+ 对象类型 + 模块/分类（2 位数字）+ 序号（3 位起）+ 可选版本/后缀；段间用 -，WBS 层级用 .，字母大写、无空格。

核心对象类型包括 REQ（需求）、TSK（任务）、BUG、VER（版本）、DOC（文档）、ADR、API、ENV、CFG 等，并给出各类型示例与衍生规则，例如：

• 需求变更：原编号不变，末尾追加 -V[版本号]；优先级用 S/A/B/C 标签，不写进编号
• 需求驱动任务：UMS-REQ-01-001.T1；非需求驱动任务：UMS-TSK-06-001
• 版本：语义化 V主.次.修，阶段后缀 -alpha.N / -beta.N / -rc.N，内部构建号 +build.N 由 CI 生成
• 文档：类型缩写（PRD、SRS、TSD 等）与文件名 [编号]_[简称].md 的对应关系
• Git：feature/、bugfix/ 等前缀，分支名含任务编号；提交类型 feat/fix/docs 等，描述含编号、≤50 字

管理原则强调 不回收、不跳号补号、废弃只改状态、规则变更下一迭代生效且不回溯已有编号。

适用边界

模块编号（如 01 用户、02 订单）需在项目启动时自行定义并全局唯一；技能不提供具体项目的模块表，只给常见映射示例。严重等级、Bug 来源、需求优先级等用标签表达，不嵌入编号字符串。