适用场景：Android / Kotlin 移动端团队协作。
在 Android 中大型团队协作开发中，代码质量无法单纯依靠开发者个人自觉维系。单靠口头约束、事后复盘的管理模式，很难应对多人并行开发、高频版本迭代、线上紧急修复等复杂协作场景。
成熟的技术团队，核心思路都是：
- 流程标准化
- 规则工具化
- 门禁自动化
也就是将 Git 分支管理、Commit 提交规范、Code Review 审核机制、本地自动化门禁、CI/CD 流水线、版本发布链路深度绑定，形成一套闭环的工程治理体系。
本文结合移动端架构落地经验，分享一套适配原生 Android、Kotlin、Jetpack Compose 项目的标准化 Git 工作流，同时拆解落地难点、取舍判断、反模式和 AI 辅助提效方案，帮助团队从工程层面解决协作乱象与代码质量隐患。
需要提前说明一点：Git 工具流不是分支命名规范，而是代码入库治理体系。分支只是表象，真正有价值的是把"谁能合并、合并前必须通过什么检查、失败后谁负责修复、发布后如何追溯"这些工程规则固化下来。
一、为什么 Android 团队必须搭建专属 Git 工具流？
Android 项目相较于后端项目，具备一些特殊属性：
- 多环境打包
- 资源文件冲突
- UI 兼容性问题
- 本地编译耗时久
- 机型适配风险高
- 多渠道包、签名、混淆、灰度发布链路复杂
多人协作模式下，极易出现以下典型痛点：
| 问题 | 典型表现 | 直接后果 |
|---|---|---|
| 分支管理混乱 | 开发、提测、修复代码混杂 | 迭代末期冲突频发，无法区分 BUG 来源 |
| 提交信息无规范 | 大量 update、fix bug、wip |
线上问题难以追溯 |
| 合并权限无管控 | 可以直接 Push 到主干 | 劣质代码污染稳定分支 |
| 环境一致性问题 | 本地能跑，CI 失败 | 主干构建不稳定 |
| 发布分支不可控 | release 分支临时插需求 | 版本稳定性失控 |
| 热修复链路缺失 | hotfix 只合 main，忘记合 develop | 下个版本旧问题复现 |
| 质量检测靠人工 | Lint、测试、格式检查靠自觉 | 漏检、忘检成为常态 |
这些问题本质并非人员责任心问题，而是工程体系缺失。单纯依靠制度约束、口头强调治标不治本，只有通过标准化流程和自动化工具建立全链路门禁，才能从根本解决问题。
Git 工具流的核心目标有三个：
- 规范化：统一全团队协作语言，降低跨成员、跨小组沟通成本。
- 自动化：工具替代人工完成格式校验、代码扫描、编译检测，拦截低级错误。
- 可控化：全版本变更可追溯、可回滚，发布流程标准化，保障线上版本稳定。
二、基础层：标准化分支模型
结合移动端版本迭代特性，可以在传统 GitFlow 的基础上做轻量化优化，兼顾灵活性与稳定性，覆盖常规迭代、紧急发版、线上热修复三种场景。
推荐分支模型：
text
main 生产稳定分支
develop 日常集成分支
feature/* 功能开发分支
release/* 预发布分支
hotfix/* 线上热修分支2.1 分支角色与职责
| 分支 | 分支级别 | 核心作用 | 代码来源 | 合并目标 | 权限管控 |
|---|---|---|---|---|---|
main |
永久主干 | 存储线上正式稳定版本 | release/*、hotfix/* |
无 | 仅允许 MR 合并，禁止直接 Push |
develop |
永久开发 | 日常迭代集成分支 | feature/*、release/* |
release/* |
仅允许 MR 合并，禁止直接 Push |
feature/* |
临时功能 | 新功能、需求迭代、功能优化 | develop |
develop |
开发者可自由推送 |
release/* |
临时预发布 | 版本提测、BUG 修复、版本固化 | develop |
main + develop |
仅允许合并阻断性 BUG 修复 |
hotfix/* |
临时热修 | 线上紧急崩溃、致命 BUG 修复 | main |
main + develop |
仅允许修复线上致命问题 |
2.2 分支命名规范
统一命名格式，方便自动化脚本识别、筛选与治理。
text
feature/模块名-功能描述
release/主版本.次版本.补丁版本
hotfix/版本号-问题简述示例：
bash
feature/login-password-register
feature/order-cart-refactor
release/1.8.0
release/1.9.1
hotfix/1.8.1-app-crash
hotfix/1.8.0-pay-fail2.3 分支流转避坑
- 临时分支完成合并、版本发布后，统一由负责人删除，避免分支冗余。
feature/*开发周期建议控制在 3-7 天，长期未合并容易产生大规模冲突。release/*严禁新增需求，仅允许修复阻断上线的 BUG。- 临时分支必须定期同步上游主干代码，每周至少 2 次，提前化解合并冲突。
2.4 架构师视角：什么时候不用完整 GitFlow？
很多团队照搬 GitFlow 后，流程会变重，最终出现"分支很多、质量没变好"的问题。Android 团队选择分支模型时，应该看交付节奏，而不是看规范是否完整。
| 团队场景 | 推荐模型 | 原因 |
|---|---|---|
| 1-5 人小团队，发布频繁 | main + feature/* + hotfix/* |
降低分支维护成本，避免流程大于收益 |
| 6-20 人常规迭代团队 | main + develop + feature/* + release/* + hotfix/* |
平衡研发集成、提测冻结、线上热修 |
| 多团队共建、周级发布 | 轻量 GitFlow + 强 CI 门禁 | 需要隔离发布节奏，避免主干被半成品污染 |
| 高频灰度、服务端驱动能力强 | Trunk-Based Development + Feature Flag | 通过功能开关控制发布，而不是长期维护大量分支 |
三、规范层：统一 Commit 提交日志
Commit 信息是代码变更的唯一日志，劣质提交信息会直接增加故障排查和代码交接成本。
团队建议强制落地 Conventional Commits 规范，并结合 Git Hook 做提交信息校验。
3.1 标准提交格式
text
<type>(<scope>): <subject>字段说明：
type：变更类型，用于区分本次提交的行为属性。scope：影响模块，填写 Android 业务或技术模块名，例如login、order、network、compose。subject：简短描述，不超过 50 字，直白说明变更内容。
3.2 Android 项目常用 type
| 类型 | 释义 | 适用场景 |
|---|---|---|
feat |
新增功能 | 新增业务功能、新增通用工具类、新增 UI 页面 |
fix |
缺陷修复 | 修复线上或测试 BUG、兼容机型适配问题 |
docs |
文档变更 | 注释补充、接口文档更新、开发手册修改 |
style |
格式调整 | 代码格式化、换行缩进、删除冗余空格，无逻辑变更 |
refactor |
代码重构 | 代码结构优化、架构调整，不改变原有业务逻辑 |
perf |
性能优化 | 启动速度优化、内存泄漏修复、卡顿优化 |
test |
测试相关 | 新增或修改单元测试、UI 自动化测试 |
chore |
辅助变更 | 依赖升级、脚本调整、资源替换 |
build |
构建变更 | AGP、Gradle、打包脚本、多渠道配置修改 |
ci |
流水线变更 | GitHub Actions、Jenkins 配置更新，门禁规则调整 |
revert |
提交回滚 | 撤销历史某次提交 |
3.3 标准示例与禁止项
合规示例：
bash
feat(login): 新增手机号验证码登录功能
fix(order): 修复商品价格小数精度丢失问题
refactor(network): 统一封装全局 API 请求客户端
perf(startup): 优化冷启动第三方组件初始化时机强制禁止：
text
update code
fix bug
wip
test
修改代码优质 Commit 至少能回答三个问题：
- 改了什么？
- 影响哪个模块？
- 为什么需要修改？
四、门禁层：Git Hook 本地自动化拦截
质量检测不能后置到 MR 合并阶段，必须在开发者本地提交、推送代码时完成第一轮拦截，提前过滤格式错误、低级 BUG 和不规范提交。
Android 团队推荐使用 Lefthook 统一管理 Git Hook。相较于原生 Hook 或 Husky，Lefthook 配置更简洁，支持并行执行，也更适合 Gradle 项目。
4.1 本地核心检测项
| 工具 | 作用 |
|---|---|
| ktlint | 统一 Kotlin 代码格式 |
| detekt | Kotlin 静态代码扫描 |
| Android Lint | Android 官方质量检查 |
| Unit Test | 推送前保障核心逻辑可用 |
| Commitlint | 校验提交信息，强制执行 Commit 规范 |
4.2 Lefthook 配置
在项目根目录新建 lefthook.yml：
yaml
# 提交前：并行执行轻量质检，快速拦截格式与基础代码问题
pre-commit:
parallel: true
commands:
ktlint-format:
run: ./gradlew ktlintFormat
detekt:
run: ./gradlew detekt
# 推送远端前：做二次快速校验，重型任务交给 CI
pre-push:
commands:
ktlint-check:
run: ./gradlew ktlintCheck
# 提交信息校验：拦截不规范 commit
commit-msg:
commands:
commitlint:
run: npx commitlint --edit {1}4.3 落地补充规则
不建议一刀切禁止所有跳过 Hook 的行为。大型项目里确实会遇到紧急热修、临时调试、环境异常等特殊情况，更合理的做法是"允许跳过，但必须留痕"。
推荐规则：
- 本地 Hook 可以在紧急场景下跳过，但必须在 MR 描述里说明原因。
- CI 流水线不允许跳过，所有入库代码必须通过 CI。
- 技术负责人定期复盘跳过记录，识别是个人习惯问题，还是 Hook 配置过重。
- 对频繁跳过 Hook 的模块，优先优化检测耗时，而不是简单批评开发者。
更关键的是：本地 Hook 不能过重 。如果一次 git commit 要等 5 分钟，团队一定会绕过它。推荐策略是：
| 阶段 | 应该跑什么 | 不建议跑什么 |
|---|---|---|
pre-commit |
快速格式修复、轻量静态扫描 | 全量 Lint、全量单测、完整打包 |
commit-msg |
Commit 信息校验 | 业务逻辑检查 |
pre-push |
二次格式校验、必要时跑受影响模块测试 | 多渠道全量构建、UI 自动化全量回归 |
| CI | 全量 Lint、全量测试、构建、报告归档 | 依赖开发者本地环境的检查 |
Hook 的目标是"尽早反馈"，不是"把 CI 搬到本地"。本地门禁越快，执行率越高。
五、审核层：MR 合并机制
本地 Hook 只是辅助门禁，所有代码禁止直接 Push 至 develop、main 两大受保护分支，必须 100% 通过 Merge Request 完成合并。
5.1 统一 MR 模板
markdown
## 变更内容
- 【需求/BUG编号】：
- 【变更简述】：简要说明本次代码变更目的与核心改动点
## 影响范围
- 【涉及模块】：登录/订单/支付/首页等
- 【兼容性说明】：最低适配版本、机型特殊适配
## 测试情况
- [ ] 新增/补充对应单元测试
- [ ] 完成多机型手动功能测试
- [ ] 完成 UI 界面适配测试
- [ ] 完成关联业务回归测试
## 风险点
- 【潜在风险】：阐述改动可能引发的副作用
- 【降级方案】：出现问题后的回滚/修复方案
## 附件
- 测试截图/录屏：5.2 MR 合并硬性规则
- 普通需求至少 1 名审核人，核心模块至少 2 名审核人。
- 所有 CI 检测任务必须全部通过。
- 所有审核意见必须解决并标记完成。
- 单个 MR 核心代码行数建议控制在 300-500 行以内。
- 统一使用 Squash Merge，保持主干提交日志整洁。
- 永久禁止向
main、develop分支直接推送代码。
5.3 Android Code Review 重点
审核者应聚焦业务与移动端专属风险点，而不是纠结代码格式。
- 业务逻辑是否符合需求文档，边界场景是否完整。
- 是否违背项目架构分层原则，是否跨层调用。
- 是否存在主线程 IO、内存泄漏、频繁创建对象、冗余绘制。
- Android 低版本、折叠屏、特殊机型适配是否完整。
- 网络异常、空数据、权限拒绝等异常场景是否兜底。
- 核心业务逻辑是否补充对应单元测试。
六、流水线层：CI/CD 自动化门禁
本地 Hook 受开发者设备环境影响，存在一定局限性。CI 流水线作为团队终极门禁，不受本地环境干扰，每次 MR 提交、代码推送自动触发全量检测，只有全部通过才可完成合并。
6.1 CI 必执行任务
- 代码拉取、环境初始化。
- JDK 17 + Gradle 缓存加速。
- ktlint 代码格式校验。
- detekt 静态代码扫描。
- Android Lint 全量检测。
- Debug 单元测试。
- 完整 Debug 包构建。
- 上传检测报告。
6.2 GitHub Actions 配置
yaml
name: Android Standard CI Check
on:
pull_request:
branches: [ develop, main ]
jobs:
android-full-check:
runs-on: ubuntu-latest
steps:
- name: Checkout 代码拉取
uses: actions/checkout@v4
- name: Setup JDK 17
uses: actions/setup-java@v4
with:
distribution: temurin
java-version: 17
cache: gradle
- name: 授予执行权限
run: chmod +x gradlew
- name: Kotlin 代码格式校验
run: ./gradlew ktlintCheck
- name: Kotlin 静态代码扫描
run: ./gradlew detekt
- name: Android 全量 Lint 检测
run: ./gradlew lintDebug
- name: 执行单元测试
run: ./gradlew testDebugUnitTest
- name: 构建 Debug 安装包
run: ./gradlew assembleDebug
- name: 上传检测报告
uses: actions/upload-artifact@v4
with:
name: android-quality-report
path: |
build/reports/
**/build/reports/6.3 CI 性能优化：别让门禁变成团队瓶颈
Android CI 最容易失败在两个地方：一是检查不够，主干质量不稳定；二是检查太慢，团队开始绕过流程。
建议按"快慢分层"设计流水线：
| 流水线类型 | 触发时机 | 目标 | 检查内容 |
|---|---|---|---|
| Fast Check | 每次 MR 更新 | 10-15 分钟内反馈 | ktlint、detekt、受影响模块单测、assembleDebug |
| Full Check | 合并前或夜间 | 覆盖主干质量 | 全量 Lint、全量单测、覆盖率、完整构建 |
| Release Check | release 分支 | 保障发版稳定 | 混淆构建、签名校验、渠道包、安装包体积、冒烟测试 |
Gradle 项目还需要重点优化：
- 开启 Gradle Build Cache 和 Configuration Cache。
- CI 固定 JDK、AGP、Gradle Wrapper 版本，避免环境漂移。
- 大项目按模块拆分任务，优先跑受影响模块。
- 将 Lint、Test、Assemble 拆成并行 Job，最后统一汇总结果。
- 缓存
.gradle、~/.gradle/caches，但要避免缓存污染导致偶发失败。
真正成熟的 CI 不是"跑得最多"，而是"在合理时间内发现最关键的问题"。
七、发布层：标准化版本发布与热修复流程
规范的发布流程是版本稳定性的核心。需要严格区分常规迭代发布与线上热修两条链路，避免版本混乱和 BUG 遗留。
7.1 常规版本发布流程
bash
git checkout develop
git pull
git checkout -b release/1.8.0发布流程：
develop分支功能全部开发完成，同步主干最新代码。- 从
develop创建release/1.8.0。 - 更新
versionCode、versionName，编写版本更新日志。 - 测试团队全量回归，仅修复阻断性 BUG。
- 发布无问题后，分别合并至
main与develop。 - 在
main分支打版本标签。 - 删除废弃
release/*临时分支。
打 Tag 示例：
bash
git checkout main
git merge release/1.8.0
git tag v1.8.0
git push origin main --tags
git checkout develop
git merge release/1.8.0
git push origin develop7.2 线上 Hotfix 热修复流程
bash
git checkout main
git pull
git checkout -b hotfix/1.8.1-crash热修流程：
- 基于线上稳定
main创建hotfix/*分支。 - 修复致命 BUG，并补充对应测试用例。
- 创建 MR，经过 Code Review 和 CI 门禁后合并至
main。 - 更新版本标签。
- 强制同步至
develop，避免下个版本旧 BUG 复现。 - 删除废弃
hotfix/*分支。
八、工具层：Android 全套质量工具栈
标准化工具链可以补齐规范与门禁短板，搭建全方位代码质量体系。
| 能力维度 | 必备基础工具 | 进阶升级工具 |
|---|---|---|
| 代码格式化 | ktlint | Spotless |
| 静态代码扫描 | detekt + Android Lint | 自定义 Lint、Sentry 代码检测 |
| 单元测试 | JUnit4/5 + MockK | Turbine |
| UI 自动化测试 | 按需引入 | Espresso、Compose UI Test |
| 测试覆盖率 | JaCoCo | Kover |
| 依赖治理 | 基础 Gradle 约束 | Gradle Versions Plugin、依赖漏洞扫描 |
| 自动打包分发 | 原生 Gradle | Fastlane + 蒲公英/fir.im |
团队质量底线组合：
text
ktlint + detekt + Android Lint + Unit Test + CI Merge Gate这套组合成本低、收益高，几乎所有 Android 项目都值得落地。
8.1 深一层：用工具约束架构边界
普通团队的质量门禁通常停留在"格式是否正确、测试是否通过"。但中大型 Android 项目真正容易失控的是架构边界。
建议增加以下约束：
| 约束目标 | 推荐方式 | 能解决的问题 |
|---|---|---|
| 模块依赖方向 | Gradle convention plugin、自定义依赖规则 | 防止 app、feature、core 互相乱依赖 |
| 禁止跨层调用 | 自定义 Lint 或 Detekt Rule | 防止 ViewModel 直接访问数据库、UI 层直接调网络 |
| 依赖膨胀治理 | Gradle dependency-analysis | 发现未使用依赖、错误依赖、传递依赖污染 |
| API 变更控制 | Binary compatibility validator 或 API dump | 防止公共模块随意破坏接口 |
| 敏感能力约束 | 自定义 Lint | 禁止随意使用定位、文件、权限、反射等高风险能力 |
例如多模块项目可以约定：
text
app -> feature-* -> domain -> data -> core
ui 不能直接依赖 data
feature 之间不能互相依赖
core 不能反向依赖业务模块这类规则只靠 Code Review 很难长期守住，必须逐步工具化。 
九、落地层：分阶段推进路线
不要一次性落地全部规则，否则很容易引发团队抵触。建议按阶段推进，每个阶段解决一个核心问题。
阶段一：基础规范，1 周
- 敲定并公示分支流转规则。
- 落地 Conventional Commits。
- 配置主干分支保护，禁止直接 Push。
- 统一团队 MR 模板与基础审核规则。
阶段二：本地自动化门禁，2 周
- 接入 Lefthook 统一管理 Git Hook。
- 集成 ktlint、detekt。
- 开启 commit-msg 校验。
阶段三：CI 流水线门禁，3 周
- 搭建 Android CI 检测流水线。
- 绑定 MR 合并规则，CI 不通过禁止合并。
- 优化 Gradle 缓存，降低 CI 编译耗时。
阶段四：自动化发布，4-5 周
- 接入 Fastlane 实现自动打包。
- 上传测试分发平台。
- 自动生成版本更新日志。
- 自动打 Tag。
- 构建完成后自动通知团队群。
阶段五：质量体系升级，长期
- 制定单元测试覆盖率基线。
- 自定义 Lint 规则，约束项目架构红线。
- 新增依赖安全扫描、启动性能监控。
十、常见落地反模式
一套规范能不能真正落地，通常不取决于文档写得多漂亮，而取决于有没有避开以下反模式。
| 反模式 | 表现 | 正确做法 |
|---|---|---|
| Hook 过重 | commit 一次等几分钟，开发者开始 --no-verify |
本地只跑快速检查，重检查放 CI |
| release 变成第二个 develop | 提测后继续塞新需求 | release 只允许修阻断 BUG，新需求进下个迭代 |
| hotfix 忘记回合 develop | 当前线上修好了，下个版本又复现 | hotfix 合 main 后必须同步 develop，并写入发布清单 |
| CI 太慢 | 一个 MR 等 40 分钟才反馈 | 拆 Fast Check、Full Check、Release Check |
| 只看覆盖率数字 | 测试覆盖率高，但核心逻辑没测到 | 核心模块设覆盖率基线，普通模块按风险分级 |
| CR 变成格式讨论 | Review 大量讨论缩进、换行、命名 | 格式交给工具，Review 聚焦架构、性能、业务风险 |
| 分支长期不合并 | feature 分支开发半个月，合并冲突爆炸 | 小步提交，小 MR，定期同步 develop |
| 规范没有负责人 | 规则写完没人维护，慢慢失效 | 指定工程效率负责人，定期复盘门禁数据 |
判断一套 Git 工具流是否健康，可以看三个指标：
- MR 从提交到首次反馈的平均时间是否可控。
- 主干分支是否长期保持可构建、可测试、可发布。
- 线上问题是否能快速追溯到 Commit、MR、版本 Tag 和责任模块。
十一、全链路最终完整工作流
整合所有规范、工具、流程后，标准化 Android 协作链路如下：
- 开发者基于
develop创建feature/*功能分支。 - 本地小步高频提交代码，遵循 Conventional Commits。
- 提交代码时，
pre-commit自动执行格式校验、静态扫描。 - 推送远端前，
pre-push自动执行单元测试与全量 Lint。 - 功能开发完成后，填写标准化 MR 模板，提交至
develop。 - CI 自动触发全量检测，输出质量检测报告。
- 团队成员完成 Code Review，闭环所有审核问题。
- 审核和 CI 双通过后，使用 Squash Merge 合并至
develop。 - 迭代末期从
develop拉出release/*，完成提测与 BUG 修复。 - 验收通过后，合并
release/*至main并打 Tag，同步更新develop。 - 线上出现致命 BUG 时，从
main创建hotfix/*，修复后同步main与develop。
十二、AI 辅助提效：适合小团队的轻量方案
对于 3-15 人的小型 Android 团队，往往没有专职架构、测试平台或工程效率团队。此时不建议一开始就做复杂的 AI 私有化部署，也不建议把 AI 审查直接接入 CI 作为强门禁。
更现实的做法是：把 AI 定位为个人辅助工具，而不是团队强制门禁。
AI 适合做这些事情：
- MR 提交前的基础 Code Review 自检。
- 快速发现空指针、异常兜底、主线程阻塞、协程滥用等常见问题。
- 为纯逻辑类、工具类、Repository、ViewModel 生成单元测试草稿。
- 帮助新人理解模块代码、补充注释和重构建议。
AI 不适合直接替代这些事情：
- 核心业务逻辑决策。
- 架构边界判断。
- 发布风险评估。
- 安全合规审查。
- 线上事故定责。
12.1 场景一：提交 MR 前做 AI 自检
建议开发者在提交 MR 前，选中本次核心变更代码，让 AI 做一次轻量 Code Review。注意不要让 AI 重复检查格式问题，格式已经交给 ktlint、detekt、Lint 处理。
可直接使用下面的 Prompt：
plain
你是资深 Android Kotlin 架构师，请对下述代码做轻量 Code Review：
1. 不输出格式类建议，项目已通过 ktlint、detekt、Android Lint 自动检查；
2. 重点排查空指针风险、主线程阻塞、内存泄漏、协程滥用、权限误用、异常兜底缺失；
3. 关注 Compose 冗余重组、资源重复加载、状态管理不合理问题；
4. 区分问题等级：高危必须修改，建议项酌情优化；
5. 输出简体中文，结论简洁，不要冗余话术；
6. 如果没有明显问题，请直接说明"未发现高危问题"。
待评审代码：团队规则可以很轻：
- 所有 MR 提交前，开发者自行完成 AI 自检。
- AI 标记的高危问题必须处理或在 MR 中解释原因。
- 低危建议不强制，避免流程变重。
- AI 结论不能替代人工 Code Review。
12.2 场景二：用 AI 生成单元测试草稿
小团队不适合盲目追求全量测试覆盖率。更合理的策略是先覆盖高收益代码：
| 推荐生成单测 | 不建议优先生成单测 |
|---|---|
| 工具类、扩展函数 | Activity / Fragment 表层 UI |
| 数据转换逻辑 | 简单数据 Bean |
| Repository 数据层 | 第三方 SDK 简单封装 |
| 纯逻辑 ViewModel | 弹窗、动画、纯展示组件 |
| 金额、时间、状态机等核心逻辑 | 临时实验性代码 |
单元测试生成 Prompt：
plain
请为下方 Android Kotlin 代码生成轻量单元测试：
1. 技术栈使用 JUnit5 + MockK；
2. 用例优先级：边界值 > 异常场景 > 常规场景；
3. 每个核心方法最多生成 3-5 个有效用例，拒绝冗余测试；
4. 重点验证业务逻辑、状态转换、异常兜底；
5. 遵循 Kotlin 空安全规范，不做无意义断言；
6. 代码注释保持简洁，标明每个用例的测试目的。
待测试代码：落地建议：
- 新增核心逻辑类时，优先用 AI 生成基础单测。
- 存量代码不追求一次性补齐，只补高风险模块。
- 覆盖率指标不要一刀切，数据层、工具层、核心业务层可以先设 60% 基线。
- AI 生成的测试必须人工检查，禁止不读代码直接合并。
12.3 AI 落地避坑
| 反模式 | 问题 | 建议 |
|---|---|---|
| 把 AI 接入 CI 强制阻断 | 容易增加 MR 耗时，也可能误杀正常代码 | 小团队先用 IDE 辅助自检 |
| 盲目相信 AI 结论 | AI 可能误判业务语义 | 高危问题人工复核 |
| 要求 100% 修复 AI 建议 | 团队抵触，流程变重 | 只强制处理高危问题 |
| 用 AI 重复检查格式 | 浪费时间，建议噪音大 | 格式统一交给 ktlint、detekt |
| 上传敏感代码到未知平台 | 存在泄密风险 | 涉密项目优先使用企业合规工具或私有化方案 |
AI 的价值不在于替代工程规范，而是降低执行规范的成本。对小团队来说，它最适合承担"初筛"和"生成草稿"的工作。
总结
Android 团队代码质量治理的核心逻辑是：
弱化人的主观约束，强化流程与工具的客观强制。
更准确地说，这不是一套"Git 分支命名规范"，而是一套面向 Android 团队的代码入库治理体系：通过分支隔离、提交约束、本地门禁、CI 合并门禁和发布回溯，把代码质量从个人自觉转移到工程机制上。
优化后的整套 Git 工作流，本质是八大能力的闭环：
- 标准化分支流转
- 规范化 Commit 日志
- 本地 Git Hook 门禁
- 人工 Code Review 审核
- 自动化 CI/CD 流水线
- 版本发布管控
- 全方位质量工具支撑
- AI 辅助提效
对于 Android 团队，最低成本、最高收益的落地组合是：
text
基础规范：Git 分支模型 + Conventional Commits
本地门禁：Lefthook + ktlint + detekt
主干门禁：Android Lint + Unit Test + CI Merge Gate
发布追踪：release / hotfix / tag / changelog
AI 提效：MR 前自检 + 单元测试草稿当团队完成这套体系搭建，就能系统性解决分支混乱、代码质量参差不齐、线上问题难以追溯、发布风险不可控等痛点，实现协作高效化、质量自动化、版本可控化，从工程层面支撑业务长期稳定迭代。
欢迎收藏/点赞/关注，长期分享 AI 指令、安卓架构、AI 全栈 实战内容，不错过每一份硬核干货。关注我: github.com/brycegao