团队协作规范总览

团队规模与节奏：1-5人，小步快跑，Kanban 拉动式交付，主干开发 + 短期功能分支。
目标：
- 以主干（main）为单一事实来源，减少分支漂移。
- 通过标准化提交、审查与发布，消除“发布流程混乱”与“文档缺失”。
- 借助托管平台自带 CI 与统一容器编排，提高自动化水平。
核心原则：
- 小批量改动、短周期合并（功能分支 ≤ 3 天存活）。
- 全面使用 Conventional Commits，自动生成变更日志与语义化版本。
- 发布使用可审计的标签（tag）与单一制品（artifact）在环境间提升，确保可回滚。
- 受控的紧急修复允许直接从主干发布，并在 24 小时内回补至开发分支（见下文“dev 环境分支”）。
- “文档即交付”：PR 必须包含测试影响范围、风险评估与回滚方案，必要时补充变更文档/ADR。

分支管理策略

为兼顾主干开发与环境管理，采用“主干 + 短期功能分支 + 环境镜像分支”的极简模型。

主要分支说明

main（受保护，默认分支）
- 用途：单一事实来源；所有功能分支均以 main 为基线创建并合并回 main。
- 部署：
  - 合并至 main：自动部署到“开发环境（dev）”用于快速验证。
  - 创建预发布标签（vX.Y.Z-rc.N）：自动部署到“测试环境（test）”。
  - 创建发布标签（vX.Y.Z）：经批准后部署到“生产环境（prod）”。
- 保护规则（在仓库设置中启用）：
  - 禁止直接推送，仅允许经合并请求（MR/PR）。
  - 必须通过状态检查：单元测试、静态检查、构建成功、提交规范校验。
  - 必须使用线性历史（推荐 Squash merge）。
  - 最少 1 名审查人通过；高风险变更需 2 名。
  - 分支需为最新（需 Rebase/更新后再合并）。
dev（环境镜像分支，非默认，禁止作为 PR 目标）
- 用途：仅用于持续运行“开发环境”的稳定基线，便于外部联调或长链路验证。
- 同步策略：每次 main 合并成功后，由机器人或脚本自动将 main 快进（fast-forward）到 dev；若 fast-forward 不可行，使用自动合并（保持与 main 内容一致）。
- 紧急修复要求：若发生从 main 直接发布的紧急修复，必须在 24 小时内将 main 同步回 dev（详见“发布与热修复流程”）。

注：日常开发仅从 main 拉分支与合并回 main；dev 不接受 PR，只作为环境镜像存在，以满足“回补到开发分支”的约束且不破坏主干开发模式。

功能开发分支规则

分支命名
- feat/-
- fix/-
- refactor/-
- chore/-
- docs/-
- hotfix/-（仅紧急修复）
- scope 取值建议：web、api、build、ci、infra、docs、shared、auth、payments 等。
创建与生命周期
- 从 main 创建；首日内提交首个 PR 草稿（Draft/WIP），确保早反馈。
- 每日 Rebase main，避免长时间分叉；分支存活 ≤ 3 天为宜。
- 功能拆分为可独立发布的小增量；必要时使用特性开关（feature flags）隐藏未完成功能。
预览环境（可选）
- 对 feat/* 分支启用临时预览（Preview）环境，用于前端/后端联调与业务验收，PR 关闭即销毁。

发布与热修复流程

版本与标签
- 采用语义化版本（SemVer）：MAJOR.MINOR.PATCH。
- 标签格式：
  - 预发布（测试环境）：vX.Y.Z-rc.N
  - 正式发布（生产环境）：vX.Y.Z
- 变更日志：基于 Conventional Commits 自动生成，随 Release 一并产出。
标准发布流水线（推荐每周至少一次或按需）
1. 准备：确保 main 绿色（CI 全通过），必要时合并“Release PR”（仅包含版本号与变更日志更新）。
2. 预发布：创建预发布标签 vX.Y.Z-rc.N，CI 构建单一制品（前端构建产物与 Node 服务镜像），部署到测试环境。
3. 验证：业务回归、端到端检查、性能与关键路径验证。
4. 正式发布：创建发布标签 vX.Y.Z，CI 从同一制品仓库提取构建产物，部署到生产环境（需要人工批准步骤）。
5. 回滚策略：如需回滚，选择上一个稳定标签 vX.Y.(Z-1) 重新部署；数据库迁移需“向后兼容”或具备双向迁移脚本。
紧急修复（允许从主干直接发布）
- 准入条件：生产故障、严重安全问题或关键交易链路受阻。
- 流程：
  1. 从 main 创建 hotfix/- 或在极端情况下直接在 main 上提交紧急修复 PR（标记“Emergency”）。
  2. 要求至少 1 名审查人快速审阅；CI 必须通过；允许跳过非关键检查但需在 PR 中说明豁免原因。
  3. 合并至 main 后，立即创建补丁版本标签（vX.Y.(Z+1)），部署至生产环境。
  4. 回补：在 24 小时内将 main 同步回 dev；同时通知所有开放的功能分支作者，尽快 Rebase。
  5. 事后复盘：记录根因、补救与预防措施，补齐测试与文档。

代码提交规范

提交信息格式标准

采用 Conventional Commits 并强制校验（本地与 CI 一致）：
- 基本格式：type(scope): subject
- 可选内容：body、BREAKING CHANGE: 描述
常用 type：feat、fix、refactor、docs、test、chore、build、ci、perf、revert
示例：
- feat(web): add search box with debounce
- fix(api): handle null userId in auth middleware
- refactor(shared): extract http client and add retry
- chore(ci): enable commit message linting
- feat(api)!: switch id from int to uuid BREAKING CHANGE: update database schema and client contracts
规则：
- subject 使用祈使句、≤ 72 字符；英文建议用小写；
- 关联任务/需求请在 body 中引用；
- 合并策略使用 squash merge 时，确保 PR 标题即为规范化的提交信息。

提交频率和规模指南

小步提交，每次提交保持可构建、可回滚。
单次 PR 规模建议：
- 代码行数变更（加减合计）≤ 400 行为宜；超过需拆分或明确说明原因。
- 新增功能应包含相应单元测试/契约测试与必要的文档变更。
避免在一个提交中混合重构与功能开发；重构请独立 PR。

代码审查机制

审查流程说明

角色与时效：
- 作者：创建 Draft PR（当日内），在 CI 绿灯后转为 Ready。
- 审查者：工作时段内尽量在 4 小时内响应，最迟不超过 1 个工作日。
审查人数：
- 常规变更：至少 1 名审查者通过。
- 高风险（涉及安全、数据结构、核心交易路径、BREAKING CHANGE）：至少 2 名通过。
PR 模板（必须完整填写）：
1. 变更摘要（what/why）
2. 测试影响范围（受影响模块、回归范围、是否需要 E2E）
3. 风险评估（功能开关、流量影响、性能/安全/合规风险）
4. 回滚方案（如何快速回滚、数据/配置回退计划）
5. 文档与迁移（需要更新的文档、API 契约、迁移脚本）
6. 截图/接口示例（前端 UI 或 API 示例）
自动检查：
- 语法/风格：Lint 与格式化（例如 eslint/tsc/prettier）
- 单元测试：覆盖率阈值约束（例如语句/分支 ≥ 80%，团队可按情况调整）
- 构建：前端打包、Node 服务构建通过
- 安全/依赖检查：基础的依赖审计
- 提交信息校验：Conventional Commits

审查标准和质量要求

正确性：功能符合需求，边界条件与异常路径已覆盖。
可测试性：新增/变更点有相应的测试；对外 API 需契约测试或模拟。
可维护性：命名清晰、单一职责、无重复代码；必要的注释与 ADR 更新。
性能与安全：关键路径有基本性能考量；输入校验、鉴权、敏感信息处理到位。
文档：README/模块说明/接口说明更新；如有配置/迁移，附执行说明。
回滚可行性：变更设计支持快速回滚与“向后兼容”迁移。

合并请求处理

合并条件和验证

必须条件：
- CI 全部通过（包括提交规范、lint、测试、构建）。
- PR 模板条目齐全，且获得所需数量审查通过。
- 与 main 无冲突并已 Rebase 至最新 main。
- 文档与变更日志（若适用）已更新。
合并方式：
- 默认使用 Squash merge，保持主干线性历史。
- Squash 提交信息采用符合规范的 PR 标题与描述（自动生成变更日志的来源）。
依赖管理：
- 升级依赖需附变更说明与影响面；锁定文件（lockfile）需一致。
产物生成：
- 构建制品（前端包、容器镜像）在 CI 中生成并推送至制品仓库，作为各环境唯一来源。

冲突解决方案

优先使用 Rebase，将功能分支 Rebase 到最新 main 后解决冲突；避免在功能分支中引入“合并提交”污染历史。
冲突处理步骤：
1. git fetch && git rebase origin/main
2. 本地解决冲突并运行全量测试与构建
3. 交互式 Rebase 清理无意义提交（如“fix lint”）
4. 强制推送更新功能分支（git push -f）
复杂冲突建议结对解决；必要时将重构与功能拆分为独立 PR，降低耦合。
若紧急修复已进入 main，所有未合并分支需在 24 小时内完成一次 Rebase。

实施与优化建议

环境与容器编排（本地与 CI 统一）
- 提供根目录下的容器化配置：
  - /frontend/Dockerfile（多阶段：依赖安装、构建、产物导出）
  - /api/Dockerfile（多阶段：依赖安装、构建、运行）
  - docker-compose.yml（本地：前端、后端、数据库/缓存、反向代理）
  - .env.example（统一环境变量定义）
- CI 使用相同 Dockerfile 构建，确保“在我机上可用 = 在 CI 可用”。
- 提供 Makefile 或任务脚本（如 make dev/test/build/up/down）统一命令。
CI/CD 基线流水线（示意）
1. 触发：
  - 分支推送（feat/、fix/）：运行 Lint+Test+Build；可选部署预览环境
  - PR：运行全套检查
  - main 合并：构建并推送镜像与前端产物，部署到 dev 环境
  - 标签 vX.Y.Z-rc.N：部署到 test 环境
  - 标签 vX.Y.Z：人工批准后部署到 prod
2. 阶段：
  - Setup（检出、缓存依赖、设置 Node 版本等）
  - Lint/TypeCheck/UnitTest
  - Build（产物与镜像）
  - 安全/依赖审计（基础）
  - 发布（推送制品、部署到对应环境）
3. 审批与门禁：
  - test->prod 升级需人工批准与变更记录
  - 热修复路径启用“紧急发布”审批流
变更日志与版本自动化
- 通过 commit 信息自动计算版本（如存在 feat -> MINOR，fix -> PATCH，BREAKING -> MAJOR）
- 生成 CHANGELOG.md，随 Release 一并提交；标签由流水线或发布脚本创建。
文档与知识沉淀
- 代码库内 docs/ 目录存放：
  - 架构图与 ADR（架构决策记录）
  - 接口契约与示例（OpenAPI/接口文档）
  - 运行手册（启动、配置、排错）
  - 发布手册（RC、生产、回滚）
- Definition of Done 增加“文档更新已完成”。
质量与度量（建议每两周回顾）
- 关注四项指标：变更前置时间、部署频率、变更失败率、平均恢复时间。
- 约束建议：单元测试覆盖率阈值、关键模块门禁测试、端到端冒烟。
人员与入职
- 新成员入职清单（Day 1-5）：
  1. 完成开发环境搭建（容器编排一键运行）
  2. 通过示例仓库熟悉 Conventional Commits 与 PR 流程
  3. 提交一个 docs/chore 类小 PR（含完整模板）
  4. 在一周内完成首个功能/修复 PR（含测试与文档）
- 结对/导师制度：首两周每个 PR 均有固定导师审查。
冲突与发布秩序治理
- 每日主干健康检查：若 main 红灯，优先修复再合并新功能。
- 发布日历与冻结窗口：可在重大活动前设短期冻结（仅允许 hotfix）。
- 高风险变更采用特性开关与分阶段放量；默认关闭，生产验证后逐步开启。

示例 PR 模板（片段）

标题: feat(scope): concise summary

变更摘要
- 背景/目标：
- 主要改动点：

测试影响范围
- 受影响模块：
- 回归范围/用例：
- 是否需要 E2E/手动验收：

风险评估
- 兼容性/性能/安全：
- 特性开关：是/否（名称/默认值）

回滚方案
- 回滚方法（tag/版本）：
- 数据/配置回退步骤：

文档与迁移
- 文档更新位置：
- API/契约变更：
- 数据库迁移（向后兼容/双向脚本）：

截图/接口示例
- （可选）

常见问答
- 问：为何保留 dev 分支但不接受 PR？
  - 答：dev 仅承载“开发环境”的自动部署基线，始终镜像 main，满足“紧急修复 24 小时回补”要求，同时不破坏主干开发。
- 问：如何快速回滚？
  - 答：以版本标签为单位回滚，部署上一稳定版本；数据库迁移需可逆或兼容；变更前需在 PR 填写回滚方案。

以上规范以“简单、可审计、可回滚”为核心，避免过度流程化。团队可在双周回顾中根据数据（发布频率、故障恢复时间等）迭代阈值与门禁，持续优化协作效率与交付质量。

团队协作规范总览

适用范围：6–15人中型团队；单仓多模块（iOS/Android/Java后端）项目；Scrum 双周迭代；自建 Git 与 CI/CD；部署到开发/测试/预发布/生产环境。
目标：降低合并冲突、提升评审效率、统一环境与发布流程，确保2小时生产故障SLA。

核心原则

以主干为中心（Trunk-based with short-lived branches），发布列车（固定节奏）+ 候选版本（RC）机制。
严格的分支保护与代码所有者机制；至少2名审阅者（含代码所有者与跨端评审）通过方可合并。
语义化版本与统一命名，双周发布列车；每周两次合流，避免长期分叉。
配置中心统一环境差异；敏感配置通过密钥管理；内建灰度与回滚剧本。
移动端签名与工件管理标准化；埋点与隐私合规。

成功度量（落地后持续跟踪）

平均PR周期≤2天；每次合流冲突率下降50%；回滚演练通过率100%；生产SLA内恢复率≥95%。

分支管理策略

采用“主干+发布分支+短期特性分支+热修复分支”的轻量策略，配合每周两次合流与双周发布列车。

主要分支说明

main（主干，受保护）
- 仅通过合并请求（MR/PR）合入；禁止直接推送。
- 始终保持可发布状态；合入即自动部署到开发和测试环境。
release/x.y（发布分支，受保护）
- 每个发布列车周期创建一次，用于稳定与候选版本（RC）测试。
- 仅接受修复、风险可控的变更；RC 通过后打正式版本标签。
hotfix/x.y.z（热修复分支）
- 针对生产紧急问题从对应 release/x.y 或主干切出。
- 修复后回合到 release/x.y 与 main，保持历史一致。

命名规范（统一、语义化）

版本标签：vMAJOR.MINOR.PATCH，如 v1.4.0、v1.4.0-rc.1
发布分支：release/1.4
热修复分支：hotfix/1.4.1
功能分支：feature/-<简述>（跨端变更可加 scope 如 feature/-api-rename）
缺陷修复：bugfix/-<简述>
其他维护：chore/-<简述>、refactor/-<简述>

功能开发分支规则

生命周期：< 5 个工作日，避免长期存活；每周二、周五进行合流（建议固定14:00与17:00前完成 PR 更新）。
同步策略：在合并前必须基于最新 main 进行 rebase，保持线性历史与最小冲突面。
变更范围：单一主题、可回滚；跨模块大改动拆分为多PR，使用特性开关隔离未完成功能。
跨端协作：涉及 API 契约、数据模型或埋点变更，必须同时提交更新 OpenAPI/协议文档与跨端变更说明。

发布与热修复流程

发布列车（双周）

切分支：在冲刺第10个工作日从 main 切 release/x.y 并冻结新功能。
候选版本：在 release/x.y 上打标签 vX.Y.0-rc.N，进入测试/预发布；移动端生成 RC 安装包分发内测渠道。
修复进入：仅允许 bugfix/chore 级别修复；每次合入自动生成新的 RC。
正式版：RC 全量通过，打 vX.Y.0 标签，部署生产；移动端进入正式发布轨道。
回合：release/x.y 合并回 main；必要时 cherry-pick 至后续 release 分支。

热修复（SLA 2小时）

0–15分钟：分级、启用灰度开关/降级、回滚至上个稳定工件（后端）；移动端通过远程配置关闭问题功能。
15–60分钟：从 release/x.y 或 main 切 hotfix/x.y.z，修复→快速评审（≥2人）→CI 优先级构建→部署生产小流量验证→全量。
60–120分钟：完成稳定性监控观察与事后复盘记录；同步回合 main 与相关 release 分支。

代码提交规范

提交信息格式标准

采用 Conventional Commits，驱动语义化版本与自动变更日志。

格式：type(scope)!: short summary
- body（动机/方案/影响）
- footer（关联任务/破坏性变更说明/关闭问题）
常用 type：feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
示例：
- feat(api)!: remove legacy v1 login endpoint
  - BREAKING CHANGE: client must use v2 /auth/login
- fix(android): handle null pointer in image loader
- chore(ios): bump swift package versions
- docs(analytics): add event spec for checkout

语义化版本映射

feat → MINOR+1（若无破坏性）
fix → PATCH+1
带“!”或含 BREAKING CHANGE → MAJOR+1

提交频率和规模指南

小步提交，原子性：每次提交聚焦单一修改点。
PR 规模：新增/修改行数总计≤400行为宜；>800行需拆分或引入专门审查会。
禁止将格式化与逻辑变更混杂；格式化单独 PR。
附带：必要的测试、文档与配置迁移脚本。

代码审查机制

审查流程说明

PR 必填内容：变更说明（What/Why/How/Risk/Rollback）、影响范围、测试证明（截图/日志/覆盖率）、跨端影响点。
自动分配审查者：依据代码所有者规则（CODEOWNERS 或等价机制）+ 跨端必审人（后端↔移动端）。
审阅人数：≥2（含至少1位代码所有者；涉及 API/协议/埋点需包含对应跨端所有者）。
SLA：工作日4小时内首次响应，24小时内完成一轮；逾期由模块负责人升级提醒。
变更后再审：任何新增提交自动撤销通过状态并触发重新审查（必要时仅对受影响文件）。

审查标准和质量要求

正确性与可读性：无显著技术债；复杂逻辑需注释/设计说明。
兼容性：后端接口遵循向后兼容策略；移动端处理旧数据与离线状态。
安全性：输入校验、鉴权、敏感信息脱敏；禁用明文密钥/令牌；第三方依赖风险扫描通过。
性能：关键路径复杂度与内存/线程使用可接受；UI流畅度与冷启动指标无明显退化。
测试与覆盖率：核心逻辑单测≥80%（后端），模块级≥60%（移动端）；新增公共方法需测试。
文档与契约：OpenAPI/Proto/埋点规范同步更新；迁移指南到位（如配置、DB）。
风险与回退：提供 Feature Flag/灰度方案；后端 DB 迁移采用 expand-contract 模式并可回滚。
规范检查：静态代码扫描、格式检查、许可证合规、提交信息符合规范全部通过。

合并请求处理

合并条件和验证

分支保护：main、release/* 强制 MR、强制线性历史、强制成功的 CI、强制评审人数与代码所有者同意、禁止跳过检查。
合并策略：
- 对 feature/bugfix/chore → Squash merge（减少噪音，保留规范化信息）
- release 回合 main → merge commit（保持发布里程碑信息）
- hotfix → squash 合入 release 与 main，并打 tag
必要门禁：
- 所有相关流水线通过：构建/单测/集成测试/静态分析/安全扫描/签名校验/制品上传
- 覆盖率阈值达标；无高危漏洞；依赖许可证合规
- 基于最新 main rebase，无冲突；PR 描述完整
- 变更规模合理；如超过阈值需附评审计划或拆分

环境与部署约束（自动化）

main 合入：自动部署开发/测试环境；打 nightly tag 可触发预发布候选构建。
release/x.y：打 vX.Y.0-rc.N → 部署预发布；vX.Y.0 → 生产。
所有环境配置经配置中心下发；敏感信息通过密钥管理系统注入。

冲突解决方案

预防

每周二/五固定合流；合并前 rebase 到最新 main。
模块路径明确与代码所有者边界清晰；避免跨模块大规模重命名。
锁文件（依赖锁定）与代码变更分开；公共接口改动先发迁移 PR，再发清理 PR。处理步骤

本地更新：git fetch && git checkout feature/... && git rebase origin/main
逐个文件解决冲突；运行全量构建与测试。
使用记录式冲突解决（如启用 rerere）减少重复冲突。
Rebase 成功后强推分支（仅限个人开发分支）：git push -f
CI 通过后继续评审与合并；必要时安排“合流时间窗”由模块负责人协助。

实施与优化建议

实施里程碑（建议两周完成基础落地）

第1周
- 建立分支保护规则与代码所有者文件（目录级 OWNER，后端/Android/iOS/客户端公共层/共享库/基础设施）。
- 配置 CI 流水线骨架与质量门禁：构建→单测→静态分析→制品→环境部署→通知。
- 搭建制品仓库分层：后端（Maven/容器镜像）、移动端（AAB/IPA/符号表/映射文件）、共享库（版本目录）。
- 建立配置中心与密钥管理对接；声明配置架构（schema）与启动校验。
第2周
- 上线发布列车流程（release/x.y、RC 标签、预发布自动化）。
- 灰度与回滚剧本演练（后端金丝雀/蓝绿、移动端远程开关/强制降级策略）。
- 规范培训与评审模板启用；度量看板上线（PR 周期、重试率、合流冲突率、回滚次数、SLA）。

CI/CD 参考设计（自建平台，可对接现有执行器/Runner）

触发策略：按路径过滤只构建受影响模块，缓存与依赖加速。
阶段
1. 检出与依赖缓存
2. 质量前置：格式校验、静态分析、安全扫描、许可证检查
3. 构建与测试：
  - 后端：单测、集成测试、契约测试（基于 OpenAPI/契约用例）
  - Android：单测、UI/仪表测试、打包（Debug/Release）
  - iOS：单测、UI测试、打包（Debug/Release）
4. 签名与制品：签名后上传制品仓库；生成 SBOM 与哈希校验
5. 部署与验证：按环境推进；运行健康检查与回归用例
6. 通知与变更日志：基于 Conventional Commits 自动生成 release notes
质量阈值：编译零警告（或白名单内）、后端核心覆盖率≥80%、移动端模块≥60%、无高危漏洞。

单仓多模块与依赖统一

目录组织：/backend/services/、/mobile/android/、/mobile/ios/、/shared/、/infra/*
版本统一：
- 后端：集中依赖清单（如 BOM/版本清单文件）
- Android：集中版本目录（版本表/版本目录文件）
- iOS：统一包管理（SPM/Pods）+ 锁定文件；公共版本表
依赖升级：每双周开1个升级 PR（可分平台），自动兼容性测试与回滚预案。
仅允许通过集中文件更新依赖版本，禁止在模块内各自为政。

环境与配置

配置中心：按 profile（dev/test/preprod/prod）管理；应用启动校验配置 schema。
密钥管理：签名证书/keystore、API 密钥、令牌等仅存于密钥管理；CI 按最小权限按需注入；定期轮换。
移动端运行时配置：远程配置读取灰度阈值、开关、端上降级策略；禁止硬编码密钥。

打包、签名与制品管理

Android
- keystore 安全存放于密钥管理；CI 解密使用；启用 v2+ 签名方案。
- 构建：生成 AAB/APK、ProGuard/R8 映射文件；产物与符号表入制品仓库。
iOS
- 证书/描述文件安全托管；CI 动态拉取；构建 IPA 与符号表（dSYM）。
- 自动递增构建号，区分内测与发布配置。
后端
- 生成应用包/容器镜像；镜像/包进行签名或哈希校验；保留最近 N 个版本。
制品仓库
- 分仓与权限分级（只读/发布/管理员）；元数据记录（提交哈希、构建号、变更日志、SBOM）。

埋点与隐私合规

事件规范：统一命名（domain.action.result），字段有 schema 与数据类型，版本化管理。
合规要求：最小化采集；敏感数据匿名/去标识化；获取用户同意（告知目的与退订）；提供可删除与导出机制。
环境隔离：测试/预发布数据隔离；默认脱敏；开关控制采样率。
移动端：首启隐私弹窗与同意记录；可随时撤回；崩溃/性能日志内敏感信息脱敏。
后端：访问控制与审计日志；数据保留与清理策略明确。
评审清单：新增/变更埋点必须附 schema、隐私评估与数据流图。

API 契约与向后兼容

变更流程：先增不减（expand → migrate → contract）；旧字段/接口淘汰期≥2个版本；标注废弃信息。
契约管理：OpenAPI/IDL 作为唯一事实来源；契约测试纳入 CI；移动端/后端双方评审通过后才能合并。

灰度与回滚剧本（关键以满足2小时SLA）

后端
- 灰度：按实例/流量百分比逐步放量；监控关键指标（错误率、延迟、TPM）。
- 回滚：一键回滚至上个稳定制品；数据库采用可逆迁移（向后兼容字段保留，清理延后）。
移动端
- 灰度：内测/灰度渠道分发，逐步提升比例；远程配置开关控制高风险功能。
- 回退：无法立即“回滚”已发布版本时，使用服务端开关降级/禁用；紧急修复走快速审核通道并强制升级提示。
剧本清单（最少包含）
- 触发条件、决策人、变更停止、回滚命令/流程、验证检查清单、通信与公告模板、复盘模板。

度量与持续改进

指标：PR 周期、变更失败率、平均恢复时间（MTTR）、每周合流冲突率、测试覆盖率、未解决高危漏洞数。
例会：每个迭代回顾会上审视指标；每月一次发布流程演练（含回滚）。

团队职责与沟通

角色：模块负责人（代码所有者）、发布经理、CI/CD 维护者、隐私合规联系人、应急值班。
通知：PR/构建/部署状态自动通知至团队频道；高危变更需预告。

模板与示例（建议在仓库 .github/ 或等价目录）

PULL_REQUEST_TEMPLATE：What/Why/How/Risk/Tests/Docs/Config/FeatureFlag/Rollback
ISSUE_TEMPLATE：Bug/Feature/Task 区分
CODEOWNERS（或等价机制）：按路径配置后端/Android/iOS/共享层所有者
CONTRIBUTING.md：提交规范、分支策略、评审清单
RELEASE.md：列车节奏、RC 流程、灰度与回滚

附：每周两次合流建议安排

周二与周五固定时间窗；在窗前1小时冻结新 PR，仅处理更新/冲突与合并；由模块负责人值守，集中解决跨模块冲突与环境验证。

以上规范结合团队现状，确保流程轻量可执行，同时覆盖从开发到发布与运维的关键环节，可立即落地并随指标持续优化。

团队协作规范总览

适用对象：30人以上、多团队协作的企业级软件/DevOps基础设施/后端服务(API)团队，采用Git、微服务与基础设施共治、GitOps部署，生产多区域多集群，蓝绿/金丝雀发布，发布列车与GitFlow并行，服务级版本独立。全流程遵循信息安全与审计留痕要求，提交与合并必须签名，变更需两级审批，覆盖SAST、许可证合规、依赖漏洞检查。

协作目标：

降低代码冲突与沟通成本，提升自动化水平与变更可追溯性
兼容微服务独立版本与统一发布列车（Release Train）节奏
标准化跨时区异步协作（模板化、留痕、强制变更说明与会议纪要）
明确回滚策略、灾备演练与发布门禁指标阈值，保障生产安全

角色与职责（通用）：

开发者(Dev)：按规范开发、提交、补充测试与文档
代码审查者(Reviewer)：同域Peer审查，负责技术正确性
二级审批者(Approver)：组件Owner/技术负责人/发布经理之一，负责上线风险与合规
SRE/平台工程(Ops)：发布策略、环境与门禁、回滚与演练
安全/合规(Security)：安全与许可证策略、审计
发布经理(Release Manager)：列车发车、版本冻结与协调
变更经理(Change Manager，可兼任)：变更窗口/冻结/会议纪要与审计

工作节奏（建议）：

发布列车：每周或每两周固定时刻“发车”，跨服务统一发布窗口；服务可独立版本，但列车只携带通过门禁的稳定版本
灾备/回滚演练：每月至少一次；生产冻结窗口前后避免变更堆积
审查SLA：工作时区24小时内完成一级审查，48小时内完成二级审批（遇冻结窗口或高风险需加会）

环境定义：

开发(dev) → 测试(test) → 预发布(staging) → 生产(prod) → 其他(sandbox/DR/性能压测等)
GitOps环境仓库按环境目录分层，采用覆盖策略（overlays）

审计与合规基线：

所有提交/合并/标签均需加密签名；启用服务端钩子强制验证（pre-receive/push rules）
PR必须关联工作项/工单，包含变更说明、风险评估、回滚方案、会议纪要链接
变更两级审批：同域Peer + Owner/Release Manager/SRE之一
必经检查：SAST、许可证合规、依赖漏洞（含阈值与例外流程），生成SBOM并归档

分支管理策略

采用“GitFlow + 发布列车 + GitOps”混合模型，兼容微服务独立版本。

主要分支说明

main（保护分支，签名标签）：始终指向最新稳定发布（生产对应的清单/版本）
develop（保护分支）：集成分支，承载下一轮列车候选功能
release/：列车冻结分支，接受仅限修复（bugfix）与发布必要调整
hotfix/：生产紧急修复，从main分出，修复后回合main与develop（及必要的release分支）
feature/<service|infra>/-：功能/变更分支，从develop分出
infra/*：基础设施类变更（可与feature同规范，但scope为infra）

命名规范：

示例：2025.02-w23 或 2025.02.1（年.月.列车序号）
使用服务/组件规范化名（kebab-case）
引用需求/缺陷编号，便于审计

标签策略（签名强制）：

服务级版本：@vMAJOR.MINOR.PATCH（语义化版本）
列车标签（可选）：train/
发布工件标签与GitOps清单引用保持一致，确保可回滚

多仓库与清单：

服务仓：代码与Docker构建定义
平台/基础设施仓：集群/网络/存储/策略等
GitOps环境仓：按环境目录管理所有服务/基础设施的版本清单与参数覆盖（如：envs/{dev,test,staging,prod}/kustomization.yaml）
列车清单：train.yaml（列车携带服务及目标版本列表）

功能开发分支规则

从develop创建 feature//-
小步提交，至少每日与develop同步（rebase优先，避免长分叉）
功能开关优先（向后兼容），避免一次性大改动；涉及DB变更需两阶段迁移
跨仓变更：以“变更集”协调（同一ticket），在列车合并窗口前完成联动验证
关闭条件：通过PR检查、两级审批、CI门禁后以“Squash & Merge”合入develop（保留清晰历史）
大型特性：使用长期feature分支 + behind feature flag，且每周与develop对齐；避免超过2周未合

发布与热修复流程

发布列车流程：

切分支：由develop切出 release/（列车冻结）
冻结策略：仅允许bugfix/文档/配置微调；新功能进入下轮列车
候选版本：各服务在release分支上打RC标签 @vX.Y.Z-rcN，完成集成/回归/性能与安全门禁
生成列车清单：更新train.yaml与GitOps staging清单
发布到staging：金丝雀或蓝绿，门禁观测通过后升级到prod（分区域/分集群分批）
正式发布：在main打签名标签 @vX.Y.Z 与可选 train/；GitOps prod指向该版本
合回：release/ 合并回 develop，清理分支

热修复流程（优先级最高）：

从main创建 hotfix/
最小改动、快速PR：同域Peer与二级审批加急；通过所有安全与回归门禁（可走“紧急安全门禁集”）
生产金丝雀/蓝绿 + 加强观测
合并：hotfix分支合回 main 与 develop（必要时合入活跃的 release/*）
事后回顾：72小时内完成Root Cause、回滚验证、改进项并记录在变更纪要

代码提交规范

提交信息格式标准

采用Conventional Commits（强制），含签名与工单关联：

标题：
(
):
- type：feat | fix | perf | refactor | chore | docs | test | build | ci | revert
- scope：服务或组件名（如 user-service、infra、api-gateway）
- subject：不超过72字符，使用祈使句，描述做了什么
正文（必填，模板）：
- 背景/动机：
- 变更内容：
- 风险与影响：
- 测试与验证：
- 回滚方案：
- 关联工单/需求ID：
页脚（按需）：
- BREAKING CHANGE: 描述
- Signed-off-by: 实名与邮箱（DCO）
提交与标签必须加密签名（例如gpg/ssh签名；在仓库端强制验证）

示例： feat(user-service): add rate limiting for login

背景/动机：防止暴力破解，满足安全策略
变更内容：新增令牌桶限流，默认阈值5r/s
风险与影响：潜在误限；提供开关与白名单
测试与验证：单元+集成+e2e金丝雀验证
回滚方案：禁用特性开关或回滚容器镜像tag
关联工单：SEC-1234 Signed-off-by: Alice alice@example.com

提交频率和规模指南

单次提交聚焦单一逻辑，变更行数建议≤400行
每日至少一次可集成提交；WIP提交仅保留在个人分支
重命名/大规模格式化与功能提交分离
需要破坏性变更必须显式标注BREAKING CHANGE并提供迁移指南

代码审查机制

审查流程说明

PR目标分支：feature→develop，bugfix→release/* 或 develop，hotfix→main
PR描述模板（强制）：
- 变更背景与目标
- 设计与实现摘要（架构图/时序图可选）
- 风险评估与影响面（含DB、兼容性）
- 测试结果（覆盖率、性能/压测摘要、手工验证要点）
- 安全与合规（SAST结果、依赖/许可证扫描摘要、SBOM链接）
- 发布计划（列车或热修复）、回滚计划
- 观测指标与门禁阈值
- 会议纪要/异步决策记录链接
审批要求（两级审批）：
- 1级：同域Peer审查至少1人
- 2级：组件Owner/技术负责人/Release Manager/SRE中1人
- 影响基础设施/跨服务接口变更需额外SRE或安全团队确认
SLA：工作日24小时内完成一级审查，48小时内完成二级审批；逾期自动提醒与升级

审查标准和质量要求

构建通过、单元/集成测试通过，语法/风格/秘密扫描无阻断项
SAST、依赖漏洞、许可证合规通过；高危(Critical/High)必须修复或经批准的例外并限期
文档齐备（README/变更说明/运维手册/迁移步骤）
性能影响评估与结果（关键路径p95/p99、资源占用）
回滚方案可执行且已在非生产验证
与架构契约一致（API契约/事件Schema/后向兼容）
变更规模与复杂度合理；避免“巨型PR”，必要时拆分

合并请求处理

合并条件和验证

必须满足：

提交与PR均为签名状态；标签为签名标签
关联工单与变更记录完整；模板项不缺失
所有必需检查通过：构建、测试、SAST、依赖与许可证、镜像扫描（如有）、SBOM生成
两级审批完成；受影响代码目录的代码所有者(CODEOWNERS)同意
无生产冻结冲突；若处于冻结窗口，需走变更例外流程并记录纪要
分支最新同步目标分支（避免陈旧基线）；推荐在合并前rebase一次
合并策略：
- feature→develop：Squash & Merge（保持develop历史清晰）
- release→main：保留合并提交（保留版本线索）
- hotfix→main：保留合并提交；随后cherry-pick或merge回develop/release
- 禁止在受保护分支上直接推送

冲突解决方案

预防：
- 每日至少一次rebase feature分支
- 按域划分目录与代码所有权，减少同文件并发修改
- 功能开关与向后兼容减少大规模重构
处理：
- 由发起人负责解决；如为跨团队冲突，召集相关Owner异步决策（24小时内）
- 保留语义冲突审查：单测/契约测试覆盖冲突处
- 解决后重新触发全部CI，保持签名有效（rebase后需重新签名）
记录：
- 冲突原因在PR备注中简述，便于后续改进统计

实施与优化建议

实施步骤（首月计划）：

基线落地
- 启用保护分支（main/develop/release/*）、强制签名提交/标签、禁止直接推送
- 配置服务端钩子/策略：提交信息格式校验、DCO、禁止含敏感信息、强制PR模板
- 启用CODEOWNERS或等效机制，明确目录所有权
CI/CD与门禁
- 分层流水线：
  - pre-commit：lint/格式化/秘密扫描/提交信息检查
  - PR：构建+单测+SAST+依赖/许可证扫描+SBOM生成
  - 合并到develop：契约测试、集成测试、基础性能回归
  - release分支：回归套件、镜像与制品签名、staging部署演练
  - main：分区/分批到prod（金丝雀/蓝绿），观测门禁
- 门禁阈值（默认，可按服务调整）：
  - 错误率(5xx) 增量 ≤ 0.5% 绝对/10%相对，取较严格者
  - p95延迟增量 ≤ 10%
  - 关键事务失败率 ≤ 0.2%
  - 资源使用（CPU/内存）增量 ≤ 20%
  - 日志错误新增告警为0个高优先级
  - 安全扫描：禁止Critical/High；Medium需评估
GitOps目录结构（示例）
- envs/
  - dev/
  - test/
  - staging/
  - prod/
- 每个环境包含清单与覆盖；train.yaml记录列车服务版本集合
- 部署策略文件定义蓝绿/金丝雀参数（分流比例、观察时长、回退阈值）
发布列车
- 确定节奏（周/双周固定时间）
- 建立列车看板：服务候选版本、阻塞项、风险清单
- 发布前评审会（可异步）：仅当跨团队影响大时召开；会议纪要入库
冻结与例外
- 冻结窗口：重大节假日前后/财报期/大促前
- 例外流程：热修复或最高优先级安全修复，经Owner+SRE+变更经理同意
回滚与演练
- 一键回滚：GitOps回滚到上一个签名标签清单
- 数据库回滚策略与双写/影子表方案；两阶段迁移脚本模板
- 每月DR演练：跨区域切换、备份恢复、RPO/RTO验证并留痕
跨时区协作
- 模板化：PR模板、变更记录模板、会议纪要模板、事后回顾模板
- 异步优先：所有决策在PR/Issue中留痕；约定可合时间窗（例如UTC 06:00–14:00）
- 审查负载均衡：轮值Reviewer、自动分配规则

度量与持续改进：

指标面板：变更失败率、平均变更前置时间、平均恢复时间(MTTR)、回滚率、审查SLA达成率、冲突率
每月回顾：基于指标调整门禁阈值、列车频率与测试覆盖目标
经验库：高频问题与最佳实践沉淀为Checklists与脚手架

安全与合规细则：

强制签名策略：提交(-S)、合并、标签均需签名；服务端验证未签名即拒收
SBOM生成与归档；许可证策略白/黑名单与例外流程
策略即代码（Policy as Code）：在CI与CD阶段统一执行（如配置漂移、策略违规阻断）

模板清单（建议纳入仓库根目录/.templates/）：

PR模板.md：按审查流程说明的各项
变更记录模板.md：目的、影响面、风险、门禁指标、回滚、会议纪要链接
事后回顾模板.md：时间线、根因、检测延迟、影响、行动项与负责人
DB迁移模板.sql/.md：向后兼容步骤、回滚脚本与验证

回滚与发布策略细化：

金丝雀步骤：5%→25%→50%→100%，每步观察≥15分钟，门禁任一不达标则自动回滚
蓝绿策略：切换后保留前版本至少1小时可快速切回
多区域/多集群：区域分批（例如 1区→3区→全量），区域间至少间隔30–60分钟观测

兼容微服务独立版本与列车：

服务自由发布至dev/test；进入列车需在release/上通过门禁
列车携带的服务版本写入train.yaml；prod仅接受列车清单或热修复清单
服务间契约变更需先向后兼容两轮列车周期，提供双栈兼容与特性开关

紧急修复与审计：

热修复通道独立、加急门禁、安全审计优先
72小时内完成事后回顾与验证，结论与行动项入库
全流程留痕：签名提交、PR审查记录、会议纪要、门禁报告与发布工单关联

以上规范可直接执行，默认稳态适配超大型多团队、微服务与基础设施共治、跨时区协作及严格合规要求，并可根据团队指标在月度回顾中进行微调与持续优化。

解决的问题

用最少准备和最短时间，为技术负责人与项目经理智能生成一套“可直接执行”的团队开发协作规范。系统将基于团队规模、项目类型、现有流程与特殊要求，自动定制分支策略、提交与评审规则、合并与冲突处理方案以及发布与紧急修复路径。目标是帮助团队快速达成统一标准，减少冲突与返工，提高代码质量与交付效率，缩短新人上手周期，并为新项目启动、流程升级、团队扩编与跨团队协作提供即插即用的规范底座，最终推动试用转化为长期付费与团队标准化建设。

适用用户

技术负责人/研发经理

在短时间内搭建团队统一协作规程，一键落地提交、审查与发布流程，减少返工与线下对齐成本，显著提升迭代节奏与交付稳定性。

初创公司CTO/技术合伙人

新项目立项前快速成型最小可行规范，避免无序协作与重复开发，随团队扩张自动升级策略，确保人效与质量同步增长。

DevOps/工程效率负责人

结合现有工具生成可执行检查清单与合并前校验项，建立标准化通道，减少人工干预，形成持续改进的闭环。

特征总结

• 按团队规模与项目类型，轻松生成可落地的分支策略与协作规范，开箱即用。

• 一键制定提交信息格式与频率建议，自动约束粒度，减少回滚与历史难读问题。

• 内置代码审查流程模板，自动匹配团队节奏，明确角色职责与通过条件，提效降漏。

• 提供发布与热修复闭环方案，自动生成步骤清单与风险提示，保障线上稳定。

• 一键输出结构化规范文档，涵盖总览、流程、校验清单，可直接纳入团队手册。

• 根据现有工具与流程自动适配，避免过度复杂化，逐步落地不扰乱当前节奏。

• 内建冲突预防与解决指引，提供常见场景示例与处理话术，降低合并阻力。

• 持续优化建议自动生成，跟踪执行效果，给出下一步调整方案与团队培训计划。

• 支持多项目多环境协作场景，灵活切换模板与参数，满足新建与存量项目共管。

如何使用购买的提示词模板

1. 直接在外部 Chat 应用中使用

将模板生成的提示词复制粘贴到您常用的 Chat 应用（如 ChatGPT、Claude 等），即可直接对话使用，无需额外开发。适合个人快速体验和轻量使用场景。

2. 发布为 API 接口调用

把提示词模板转化为 API，您的程序可任意修改模板参数，通过接口直接调用，轻松实现自动化与批量处理。适合开发者集成与业务系统嵌入。

3. 在 MCP Client 中配置使用

在 MCP client 中配置对应的 server 地址，让您的 AI 应用自动调用提示词模板。适合高级用户和团队协作，让提示词在不同 AI 工具间无缝衔接。

开发文生文 AI提示词

团队开发规范定制生成器

幂简官方

211

Dec 11, 2025

本提示词专为软件开发团队设计，可根据团队规模、项目类型、开发流程等核心参数，智能生成包含分支策略、代码审查、提交规范等完整模块的团队协作规范文档。生成的规范兼具行业最佳实践与团队特性，能有效提升代码质量与协作效率，适用于新项目启动或流程优化场景。

查看提示词内容

AI开发者

产品经理

商业分析师

电商运营人员

法律从业者

财务规划师

市场营销人员

品牌营销人员

新媒体运营

提示词工程

数据分析

写作

内容创作

内容营销

SEO

工具

商业战略

策略

DeepSeek

OpenAI

Claude

Gemini

Grok

Qwen

Kimi

团队协作规范总览

分支管理策略

主要分支说明

功能开发分支规则

发布与热修复流程

代码提交规范

提交信息格式标准

提交频率和规模指南

代码审查机制

审查流程说明

审查标准和质量要求

合并请求处理

合并条件和验证

冲突解决方案

实施与优化建议

团队协作规范总览

分支管理策略

主要分支说明

功能开发分支规则

发布与热修复流程

代码提交规范

提交信息格式标准

提交频率和规模指南

代码审查机制

审查流程说明

审查标准和质量要求

合并请求处理

合并条件和验证

冲突解决方案

实施与优化建议

团队协作规范总览

分支管理策略

主要分支说明

功能开发分支规则

发布与热修复流程

代码提交规范

提交信息格式标准

提交频率和规模指南

代码审查机制

审查流程说明

审查标准和质量要求

合并请求处理

合并条件和验证

冲突解决方案

实施与优化建议

示例详情

解决的问题

适用用户

技术负责人/研发经理

初创公司CTO/技术合伙人

DevOps/工程效率负责人

特征总结

如何使用购买的提示词模板

1. 直接在外部 Chat 应用中使用

2. 发布为 API 接口调用