AI智能摘要
Android GKI 升级带来大量碎片化 commits,人工分析压力巨大,Aegis(神盾)工具应运而生。它通过结构化 JSON 输出,将琐碎提交转化为可追踪的影响分析,智能识别变更模块、风险、核心问题并生成自动化测试优先级建议,显著提升升级评估与回归测试的精准性。最终产出 HTML 和 Markdown 报告,图表化展示高风险点与回归重点,报告可一键分享团队,有效缓解人力压力,实现升级分析自主可控。
此摘要由AI分析文章内容生成,仅供参考。

在公司做 Android 稳定性的,应该都经历过这种时刻:

GKI 升级一来,几百个 commit,像洪水一样拍你脸上。

SPM/测试部都拉着你,想要你评估这次GKI升级的测试建议。

虽然很想说FullTest!!!测试没人力和我没关系!但是吧,有时候就是会很无奈。

比如从 android13-5.15-2025-01_r1 升到 android13-5.15-2025-01_r7,但带进来一串 upstream/backport/Android 特有 patch——里面有文件系统、有网络、有 bpf/vsock、还有一堆你根本不关心但必须确认的 ABI 维护提交。

你不可能每一笔都细看 diff;但你又必须回答:

  • 这次升级改了哪些模块?

  • 有没有明显的稳定性/性能/安全风险?

  • QA 回归应该先测什么?怎么排优先级?

  • 哪些 commit 必须人工复核?

问题是:提交多、信息碎、时间不够、容易漏

我不想每次都靠“经验 + 直觉 + 焦虑”,所以写了一个工具:Aegis(神盾)。我自己取的代号,后续我写的一些小工具我都会取一个比较酷的代号- 。-

好了,下面介绍一下这个小工具:

这个工具解决了什么问题?

把“提交列表”变成“影响分析”

你需要的不只是 commit subject,而是:

  • 这笔改动在改什么(what_changed)

  • 它想解决什么问题/bug(problem_fixed)

  • 风险点是什么(stability/perf/security/compat/abi…)

  • 对应应做哪些模块级回归方向(suggested_tests)

  • 以及 AI 的置信度(confidence)

并且这些信息最好能被程序继续消费(比如做排序、做汇总、做可视化)。

把“泛泛的回归建议”变成“与本次升级强相关的策略”

传统“通话/WiFi/蓝牙/相机/音频/…全测一遍”不是不对,但它不够“贴合”。
Aegis 的目标是:根据本次变更的模块、风险类型、提交语义,生成更可执行的回归重点。

把“报告”变成“可交付件”

最终输出一个 HTML:

  • 顶部整体总结(AI 生成)

  • 图表:模块分布、风险分布、变更规模

  • 高风险 commit 卡片列表(可搜索)

  • 点击 commit 弹窗展示:AI 分析 + touched files + diff(可截断)

这玩意儿能直接丢给项目、QA、甚至老板:“看这个,优先测这些。”

这个工具能够得到什么?

Aegis 会产出三类东西:

每个 commit 都产出统一 schema 的 JSON(核心资产)

{
  "module": "NET",
  "module_candidates": [{"name":"NET","score":0.82,"reason":"..." }],
  "suggest_new_module": null,
  "what_changed": "…",
  "problem_fixed": "…",
  "evidence": ["…"],
  "risk": [{"type":"stability","detail":"…"}],
  "suggested_tests": ["…"],
  "confidence": 0.73
}

为什么要结构化?

  • 可排序:按 risk_score 排 “Top 风险提交”

  • 可聚合:按 module 汇总,算 insert/delete,算风险累计

  • 可追踪:每条 suggested_tests 能追溯来自哪些 commit

  • 可视化:chart 一画就出来了

你最终产出的 HTML 报告,本质就是把这个 JSON “消费”了一遍。

Markdown 报告(方便 diff / 存档 / CI)

render_markdown() 输出包括:

  • 模块统计(commit 数、insert/delete、风险累计)

  • Top 高风险列表(用于优先回归)

  • 按模块分组的 commit 明细

  • 低置信度/信息不足项(提醒人工复核)

炫酷 HTML 报告(面向“读者”)

render_fancy_html() 是真正让工具“产品化”的部分:
图表、卡片、搜索、弹窗、主题、甚至“AEGIS-神盾”的 branding。

Aegis 的核心设计

校验 tag 并获取 commit 范围

使用:

  • git rev-parse --verify <tag>

  • git rev-list --reverse old..new

提取 commit 信息

git show 拿到了:

  • --format:sha/subject/author/date/body

  • --shortstat--stat

  • --name-only

  • git show sha 作为 diffdetail

本地规则 + 关键词做模块候选

  • 路径前缀规则(硬规则)mm/ -> MM,fs/ -> FS,net/ -> NET…

  • 关键词 hint(软提示):subject/body 匹配 tcp/udp -> NET,f2fs -> FS…

这样做的好处是:
即使 LLM 摆烂,也能给出基本模块归类,并且把候选传给模型能减少它“乱猜”。

AI 逐提交分析

ThreadPoolExecutor 做了并发 worker,并做了:

  • sleep 控制节流

  • 失败 fallback(不会让全流程崩掉)

  • 针对 GKI symbol list 更新做 shortcut(不调用 LLM,直接低风险归类)

ANDROID: GKI: Update symbol list ... 这种提交,调用 AI 是浪费钱+浪费时间

这里也是我花费时间最多的地方,主要是这个提示词,一直调的不够好,这里也列一下几段提示词,后续还是要继续优化一下!!!

AI分析的好不好,全靠提示词写的怎样!

每一笔commit进行分析的提示词

system提示词

SYSTEM_PROMPT = """你是一位资深的内核安全与稳定性专家,专门负责Android/Linux内核的代码审查与分析,特别是在Android手机GKI升级评估方面有丰富经验。
你将收到一个内核提交的信息(提交信息、涉及文件、统计信息、以及相关的链接摘要)。
你的任务:输出严格的JSON格式结果,用于生成Android手机GKI升级影响分析报告。

重要要求:
1) module字段必须从提供的MODULE_LIST中选择一个;如果无法匹配任何模块,使用module="OTHER",并提供suggest_new_module(字符串)及原因。
2) 所有输出内容必须使用中文
3) 不要编造不存在的事实;信息不足时使用"unknown",并相应降低置信度
4) evidence必须基于输入信息(提交信息/文件/统计/链接摘要),用简短句子描述
5) suggested_tests必须提供具体的、可执行的Android手机测试项目,针对模块级和功能级测试
6) 只输出JSON,不要包含其他任何文本


分析维度:
1) **风险评估**:评估此提交对Android手机的安全性、稳定性、性能、兼容性、ABI等风险
2) **问题修复**:描述此提交修复的问题或引入的新功能,特别关注对Android手机的影响
3) **性能分析**:如果涉及性能改进或可能影响性能,详细说明对Android手机用户体验的影响
4) **依赖性分析**:分析此提交与其他提交、模块或Android系统功能的依赖关系
5) **安全性**:如果涉及安全漏洞或修复,详细说明对Android手机安全性的影响
6) **推荐测试**:根据提交内容和风险评估提供具体的Android手机测试项目

特别针对Android手机的测试建议需要包含但不仅限于:
- 模块级功能测试(如:调度器压力测试、内存压力测试等)
- Android特定功能测试(如:应用兼容性、系统服务、HAL层测试等)
- 性能测试(如:应用启动时间、系统响应速度、电池续航等)
- 稳定性测试(如:长时间运行测试、压力测试、热测试等)
- 兼容性测试(如:应用兼容性、驱动兼容性、外围设备兼容性等)
- 安全性测试(如:权限检查、安全策略验证等)

JSON schema:
{
  "module": "string",
  "module_candidates": [{"name":"string","score":0.0,"reason":"string"}],
  "suggest_new_module": null | "string",
  "what_changed": "string",
  "problem_fixed": "string",
  "evidence": ["string", ...],
  "risk": [{"type":"stability|performance|power|security|compat|abi","detail":"string"}],
  "suggested_tests": ["string", ...],
  "confidence": 0.0
}
"""

user提示词

    user = f"""背景:这是一个Android手机GKI内核升级的提交分析。请特别关注对Android手机的影响。

MODULE_LIST = {json.dumps(modules, ensure_ascii=False)}
Commit: {ci.sha}
Subject: {ci.subject}
Author: {ci.author} <{ci.email}>
Date: {ci.date}

Message body:
{body}

Parsed tags (from body): {tags_json}

Shortstat:
{ci.shortstat}

Diffstat:
{ci.diffstat}

Touched files (first 200):
{chr(10).join(ci.files[:200])}

Diffdetail:
{ci.diffdetail}

Rule-based candidate modules: {rule_modules}
Keyword-hint modules: {hint_modules}

Linked context (best-effort, may be none):
{link_block if link_block else "none"}

请特别考虑以下Android手机相关的测试方向:
1. 功能测试:通话、网络、蓝牙、WiFi、相机、音频、传感器、显示、触控等
2. 性能测试:应用启动时间、系统响应速度、游戏性能、多任务切换、电池续航
3. 稳定性测试:长时间运行、压力测试、热测试、Monkey测试、重启测试
4. 兼容性测试:应用兼容性、驱动兼容性、外围设备兼容性
5. 安全性测试:cts/vts/gts等测试,权限检查、安全策略、漏洞验证
"""

最后汇总所有commit进行分析的提示词

system提示词

你是Android内核架构师和GKI升级专家,专注于Android手机的内核升级评估,用中文提供专业、具体、可执行的建议。

user提示词

    summary_prompt = f"""你是一位资深的Android内核架构师和GKI升级专家。请对以下Android GKI内核版本升级进行整体评估分析,特别针对Android手机设备:

升级范围:{old_tag} → {new_tag}
总提交数:{total_commits}

模块统计:
{json.dumps(module_stats, indent=2, ensure_ascii=False)}

风险类型分布:
{json.dumps(risk_type_counts, indent=2, ensure_ascii=False)}

高风险提交(risk_score >= 3)列表:
{[{'sha': c['sha12'], 'subject': c['subject'][:100], 'module': c['module'], 'risk_score': c['risk_score']} 
  for c in sorted(all_commits, key=lambda x: x.get('risk_score', 0), reverse=True)[:10]]}

以下是根据每个提交提取的测试建议:
{json.dumps(all_test_suggestions, ensure_ascii=False)}

测试策略不仅限于下面:
- 功能测试(通话、网络、蓝牙、WiFi、相机、音频等)
- 性能测试(应用启动、游戏性能、多任务等)
- 稳定性测试(Monkey测试、压力测试、长时间运行等)
- 兼容性测试(应用兼容性、驱动兼容性等)
- 安全性测试(权限检查、安全策略等)

请从以下几个方面提供详细的中文分析,特别关注对Android手机的影响:
1. **整体风险评估**:基于所有提交的聚合分析,评估本次升级对Android手机的整体风险等级(高/中/低)及具体理由
2. **关键变更领域**:识别最重要的变更模块和对Android手机的影响面,说明主要关注点
3. **Android手机安全性影响**:分析对Android手机安全性的影响,包括安全修复、潜在漏洞等
4. **Android手机稳定性影响**:评估对Android手机系统稳定性的影响,包括可能引入的崩溃、死机、重启等问题
5. **Android手机性能影响**:分析可能的性能变化(应用启动、系统响应、电池续航、发热等)及原因
6. **测试用例**:要综合所有commit的suggested_tests,按以下要求提供:
   - 必须覆盖所有提交中提到的测试项,不允许遗漏
   - 按测试类型分类,分类不仅限于:功能测试、性能测试、稳定性测试、兼容性测试、安全性测试
   - 根据问题commit命中测试分类后,每个分类下至少包含3-5个具体可执行的测试用例
   - 标记哪些是高频建议的测试项(被多个提交推荐的)
   - 确保每个测试用例都是针对Android手机的具体操作步骤
7. **需要特别关注的提交**:列出对Android手机影响最大的3-5个提交及原因,说明需要重点测试什么

请以JSON格式返回分析结果,所有字段内容都使用中文:
{{
  "overall_risk_level": "高|中|低",
  "overall_risk_score": 0-10,
  "key_changes": ["string", ...],
  "security_impact": "string (详细说明对Android手机安全的影响)",
  "stability_impact": "string (详细说明对Android手机稳定性的影响)",
  "performance_impact": "string (详细说明对Android手机性能的影响)",
  "regression_test_strategy": "string (详细的Android手机测试策略,按照序列号换行)",
  "suggestion_test_cases": "json (具体的测试用例)",
  "upgrade_recommendations": ["string (具体的升级建议)", ...],
  "critical_commits": [
    {{
      "sha": "string",
      "reason": "string",
      "action": "string (具体的测试或验证建议)"
    }}
  ],
  "summary": "string (详细中文总结,重点说明对Android手机的影响)"
}}

整体总结 + 报告渲染

AI返回的数据

单笔commit分析的数据

  • generate_overall_summary():把聚合后的模块统计、风险类型分布、高风险提交列表发给 LLM,让它产出“整体结论 + 回归策略 + 关键提交”

  • render_markdown() / render_fancy_html():把 AI输出回来的结果 渲染成报告

这样的一个工具就完成了,很简单吧!

我会如何评价 Aegis 的价值?

我觉得它的价值不在于“AI 多聪明”,而在于它改变了我的工作方式

  • 以前:我盯 git log,靠经验归类,写回归建议

  • 现在:工具产出结构化证据链,人只做关键复核

最后交付给Team的,不再是“我觉得要测这些”,而是:

  • 这次升级涉及模块分布

  • 高风险提交排名与理由

  • 每笔提交的 evidence / risk / suggested_tests

  • 聚合后的回归策略(可追溯)

这就从“经验输出”升级成“工程化产物”。

其实我还想将我司测试部的庞大的测试用例向量化,让AI去根据本次GKI升级的改动来选择具体的测试用例,这才是真正的能够节省大量的人力成本的关键!

但是吧,有可能涉及到公司的保密协议,这部分可能不再会往下继续探索,些许遗憾。。。