研发阶段、GitLab 命名与按类型推进的规范建议

更新日期：2026-11-08。以下为可评审的公司规范建议，不是已部署的 GitLab 配置。 继承已有 Git 分支、Tag、MR 规范及用户确认的 GitLab SSOT、Multica 过程记录方式。 参考用户提供的两份 PDF、固定版本的 mattpocock/skills，以及 AWS/Kiro 官方原文。

先区分四件事

类型表示交付什么，阶段表示当前在哪一步，状态表示产物是否有效，版本表示依据哪一份内容。 PRD 是类型，不是所有 Issue 必须经历的阶段；accepted 是文档状态，不代表已经生产上线。 Issue/MR 的分类使用 Labels；Git Tag 用于标记代码发布版本，不能用 prd、review 之类的 Tag 表示流程。

建议统一阶段语义、证据和接口，允许团队裁剪路径。下面是端到端研发的常见活动， 不是要求每个任务依次走完的瀑布流程；设计、验证策划和实现可按依赖交错，失败可回到前序活动。

端到端阶段与退出条件

关闭用 GitLab 原生 open/closed，不再额外维护 phase:closed。 关闭时保留最后阶段和结束原因，便于区分“方案评审完成”与“运行观察完成”。 若部署已有满足这些语义的原生状态/看板，映射使用即可，避免另维护一套冲突状态。

阶段标签代表工作项当前的主活动，不是所有历史活动的标签集合。 一个 FEATURE 的阶段由整体验收责任人或受控聚合逻辑判断，不能把某个 DEV 的阶段自动复制给父任务。 阶段变化不等于通过验收；任务必须保留对应证据和判定结果。

最小标签体系：先实施少量稳定字段

所有名称为建议，优先映射公司已有标签。使用普通单冒号标签即可，不依赖特定付费功能。

初期只强制 kind、phase，文档再要求 state；风险作为接单合同必填字段，是否投影为标签由集成决定。 优先级沿用现有公司规则。缺陷严重度与业务优先级不是同一个量，不为了看板整齐混成一个 P0。 里程碑用 GitLab Milestone，责任人用 Assignee，版本与环境用结构化字段/证据， 不把人员、SHA、每次 run 或自由文本都制造成标签。

普通标签本身不提供互斥或门禁。建议由模板和受控集成校验单值维度只有一个当前值； 转换前读取最新内容，并发冲突时保留他人改动、重新计算，避免旧事件覆盖新状态。 自动化可在既有授权范围更新进展，业务意图、风险例外和生产发布仍由对应责任机制处理。

team 与 domain：组织责任和领域语义分开

本文将此前表示业务/能力领域的 area: 调整为 domain:，与 ai-wiki 的领域知识概念对应。 team 回答“哪个团队主责”，domain 回答“涉及哪个领域”，两者是多对多关系。 团队调整不应导致领域 ID 改名；一个领域也不必等于一个仓库、一个微服务或一个 DDD 限界上下文。

建议示例为 team:paas + domain:permission，或 team:crm-sfa + domain:customer。 示例 slug 需先与实际团队、领域词汇表核对，本文未声称这些标签已经在 GitLab 创建。 跨域 FEATURE 可标多个领域；影响独立交付时拆子 Issue，分别指定主责团队，并保留父任务整体责任。

前端、后端、Android、iOS 是技术侧分类，可在需要路由时用 stack:web、stack:java、 stack:android、stack:ios；开发、测试、产品、运维等岗位使用能力目录中的 role， 不混入 domain。repo/服务映射优先查询项目目录，避免复制出多套容易漂移的标签事实。

领域目录建议登记稳定 ID、中文名、边界、同义词、知识入口、关联仓库与主责/协作团队。 标签只引用该 ID；现有 domains/<group>/<repo> 是知识来源路径，不因改用 domain 标签而搬目录。 一个逻辑领域可以索引多个仓库目录，领域规则仍按明确 scope 与强制等级裁决， 不能因为添加了某个 domain 标签就自动获得写权限或覆盖公司规范。

如果已有 area:*，先盘点其语义：领域类映射到 domain:*，技术类映射到 stack 或项目元数据， 混合项人工拆分。逐项更新看板、搜索、订阅和自动路由后，再停止写入旧标签。 过渡期读端可识别旧别名，写端只维护新标签；没有历史消费者时直接采用新命名。

Issue、MR、分支与 Tag 的命名

Issue 标题：类型稳定，描述交付结果

格式：[TYPE] 业务主题 — 具体交付或待解决问题。 TYPE 采用统一大写词，正文可以中文；不要把“进行中/完成”、人员名或易变版本状态塞进标题。 同类型 Issue 允许多份，身份是实例/project/IID，不能把标题当数据库主键。

对高不确定性工作可选 [MAP]、[DECISION]、[RESEARCH]，分别对应决策地图、待裁决问题和事实调查。 不要让一个类型同时表示需求正文、执行步骤和调度状态。 正式可独立验收的工作用 Issue；纯执行步骤留 Multica，避免三处重复维护 tasks。

MR 标题：沿用当前仓库规范

本项目现行《Git 分支规范》要求 MR 标题遵循提交日志格式，示例 feat(cart): 购物车结算优化。 建议继续使用 feat(permission): 增加字段级权限校验、fix(permission): 修复缓存路径漏检， 不把 Issue 的 [PRD] 分类前缀强加给代码 MR。

MR 描述保留目的/原因、实现范围、风险、测试与扫描结果、关联 Issue/验收标准、当前 SHA 和证据链接。 文档型 Issue 本身不要求 MR；若需要更新仓库里的 ADR、契约或长期文档，则对应变更仍走仓库 MR 流程。 不把未通过必需检查的变更伪装成可合并状态。

分支与 Git Tag：继承已有治理，不另起一套

代码分支沿用项目适用的 feature/、fix/、hotfix/ 等类型前缀及现有基线规则。 在项目规则允许时，可用 feature/123-field-permission 把 Issue IID 加进可读名称； 跨仓身份在 MR 正文用完整引用，不依赖分支里的数字。文档型 Issue 不必建分支。

现行 Tag 规范采用 vMAJOR.MINOR.PATCH，如 v26.10.2，发布 Tag 不可删除、复用或重新指向。 本建议不改动现有打 Tag 时机、责任或分支策略。kind:prd、phase:review 是 Labels，绝不是 Git Tag。 多仓发布用 RELEASE Issue 记录 repo → tag/SHA → 制品摘要 → 环境的版本矩阵。

本轮规范读取快照为 ai-wiki ef46c42925d44bb3e733cb12fb09def189451926， 区别于报告早期调研快照。 现行 Git 分支、Tag 与 MR 规范 及Git Group 与仓库治理规范 是本节继承的公司基线，Issue 新标签/类型为建议增补。

当前规范既有“只基于 main 的 tag 发布”，也有“存量分支发布逐步迁移”的表述； 执行时按仓库适用 profile 和现行授权核验，不在此宣称所有工程已完成 Tag 发布改造。 现行 MR 描述还提及 TAPD story/bug；保留这些来源关联，当前任务权威入口按用户确认使用 GitLab Issue。

按类型选择路径，不强制所有 Issue 走满十个阶段

完整 FEATURE 按已选交付集合验收；只要求设计交付的 FEATURE 不必等上线， 要求生产效果的 FEATURE 则不能在代码合并时关闭。 事故的缓解动作可能先于完整 RCA，不能把上表当作阻止紧急响应的串行门槛。 紧急修复可以压缩沟通环节，但关键验证、生产权限与事后记录按既有政策执行。

Issue 模板与阶段回写契约

所有类型最小共享模板：

类型与本次交付：
目标 / 待回答的问题：
范围与非目标：
约束、风险与责任人：
当前采用输入：Issue/文档链接 + 版本或内容摘要
验收 / 完成条件：
依赖与阻塞：
当前结论、未决项和产物引用：
Multica issue / topic / run：
证据与变更记录：

PRD 补场景和 验收标准；DESIGN 补关键状态与设计版本；TECH 补接口/数据、选项取舍、测试及回退； DEV/BUG 补复现或适用 验收标准、改动边界和验证矩阵；VERIFY 补版本/环境/数据与 verdict； RELEASE 补制品矩阵、执行责任、批准和回退/观察标准。

阶段回写建议格式：[阶段] 结论｜输入版本｜产物与证据｜缺口/下一步｜Multica 过程链接。 重大范围变化更新当前正文，评论只保存摘要和审计，不能把关键决定埋在历史回复里。 同一事件回写要去重；回写失败应显示待同步，不能把平台执行完成当作 GitLab 合同已更新。

Wayfinder 与 grill 技能：实际实现和适配边界

核对仓库 mattpocock/skills，固定提交： 4ae2317ddb22b046e26455e4f9c9b3aaaf62212d。 本次找到当前技能名 grill-with-docs，而非同名 grill-me-with-docs；以下仅依据已读版本。

已核实的上游做法

• wayfinder 默认解决决策问题，先得到可实施路线，不默认执行整个项目。
• 地图是 wayfinder:map Issue，只存目标、使用说明、已决策摘要/指针、尚未细化问题和范围外事项。
• 子 Issue 是决策问题，类型为 wayfinder:research、prototype、grilling、task。 研究可独立执行，grilling/prototype 要真人参与；不能由 Agent 自问自答冒充人的决策。
• 先读取地图，再按需读取当前可处理的问题；关闭问题时写 resolution comment 并回填地图摘要。
• GitLab 适配明确 issues/specs 存 GitLab，使用关联 Issue 和 Part of 表达归属； 原生阻塞能力不可用时以正文 Blocked by 约定回退。上游另有 GitHub 和本地 Markdown 适配。
• grill-with-docs 调用 grilling 与 domain-modeling；后者将术语和重要 ADR 写入仓库文件， 并非把所有内容存 GitLab。ADR 只用于有真实取舍、难逆转、缺背景会令人困惑的重要决定。

结合公司环境后的建议

这些是适配建议，未安装运行上游技能、未验证其 CLI 命令在公司 GitLab 的执行结果。 上游维护说明也指出主要使用 GitHub；GitLab 模板存在不等于你们部署的全部功能已验收。

来源：

• Wayfinder 源码
• GitLab tracker 适配
• Grill with docs
• Domain modeling

《Vibe 时代的软件工程》如何改变我们的工程约定

用户提供材料共 39 个 PDF 页面，封面标“2026 年·初版”。以下页码均为 PDF 页面序号， 不是正文印刷页码。重点核对了成本/验证鸿沟、核心循环、模块化、安全网和规模化相关页面。 书中案例和概率数字是材料的论证或示例，不作为公司实测收益或实际可靠率。

书中的若干表述需要结合你们规模适配：

• “两次修不好就回滚重来”取其有界重试与清理上下文的原则，具体次数按风险和团队合同配置； 先保留失败证据和已有有效工作，不对共享分支或他人改动执行无条件 reset。
• “不许改测试”应落实为本轮验收基准受保护，基准变更需独立确认； 不能禁止正常维护测试，也不能要求 250 人逐条人工重读所有低风险自动生成断言。
• “模型没有跨会话记忆”针对模型自身；Multica、GitLab、知识库和 harness 可以提供持久记忆， 关键是来源、权限、版本、过期和可恢复，而不是把所有历史重新注入上下文。
• 独立概率相乘、贝叶斯示例和编码占比 40% 的加速上限依赖假设， 检查器可能共享盲区，不能把这些数字直接转为公司的通过概率或收益承诺。
• 分支/worktree 隔离的是工作副本，不是进程、凭据和网络安全边界；运行权限沿用部门 VM 的隔离合同。

AWS 材料：系统规格、任务规格与知识回流

用户提供的《AWS案例_知识库在软件研发全流程中的应用》共 10 页， 材料标注 2026-10、部分来源为脱敏内部资料，最后一页也说明对纷享现状的推断需确认。 本报告将其作为用户提供的研究材料，不把其中内部数值或产品清单当成本轮独立核实的 AWS 官方事实。

最有用的组织方式是 p6 的两类规格：

报告其余可采用做法：p4 的先接现有来源、限制默认工具与上下文预算； p7 的从需求/不变量形成验证基准；p8 的复盘行动转成上线检查和技能； p9–10 的来源、加工、存储、访问、消费者链路，以及知识效果用任务成功率/返工衡量。 对应公司就是 code-search + ai-wiki + fs-ai-hub + Multica + repo-wiki 增量更新， 不因参考 AWS 就要求迁云或新增同功能平台。

材料所述个人身份工具访问不能直接照搬到部门长期无人值守 Agent； 已有凭据网关与服务身份应显式区分人的授权、runtime 权限和审计主体。 材料的“≤4 个默认工具”、各项提效数字只作为其建议/案例，不能替代你们按任务测得的工具预算与收益基线。

本轮另核对两份一手资料：

• AWS AI-DLC： 提出 Inception、Construction、Operations 三大阶段，AI 规划并请求关键澄清、人参与重要决策； 原文将 plans/requirements/design 保存于项目仓库。这与本文的 GitLab 文档 Issue 落点不同， 我们借鉴活动和上下文连续性，通过显式引用/快照适配，不宣称 AWS 采用本公司的 Issue 存储路线。
• Kiro Specs： 明确 requirements/bugfix、design、tasks 文件和三阶段工作流； 可以映射到本公司 PRD/BUG、TECH、执行任务，但使用文件型工具时须定义输入快照和状态回写， 避免 GitLab、Multica、tasks.md 三套活动状态同时维护。

AWS 的三大阶段适合管理层总览；本章的十种 phase 用于工程活动与路由。 不能机械一一对应：技术设计在 AI-DLC Construction 中也可能发生，文档评审可早于编码。

建议先在一个团队验证的最小闭环

选一项真实小需求、一项只交付技术方案的任务、一项可复现 Bug： 确认类型与完成条件 → 当前输入可定位 → Multica 按类型执行 → GitLab 留结论和证据 → 按合同收尾。 验收至少覆盖：文档不误建代码任务；取消的依赖不误解锁；旧版 PRD 不继续指挥新 run； VERIFY 完成但 FAIL 不让 FEATURE 通过；MR 不误关文档；发布版本与实际运行一致。

推广到更多团队前，再用相同标签字典/模板做映射，保留团队 profile 差异。 本轮未创建 Issue、标签或 MR，也未修改 CI、运行平台或分享原始 PDF。